[Ltib] RE: the RFS image address problem

[Makhija, Neha (IE10)]

Hi Stuart

As suggested by the Vijay, I made a change in the struct mtd_partition
to the desired value and it is working now. In this offset value has
been changes to the 0xFFC000 instead of 0x1000000.

When the NAND Flash is empty at that time to program the area with
rootfs.jffs2 image the parameters which are being passed is 

 set cl mac0=00:08:ee:00:9b:b0 noinitrd root=/dev/nfs
 nfsroot=192.168.10.20:/tftpboot/rootfs ip=192.168.10.20:
 192.168.10.20: 192.168.10.20:255.255.255.255::eth0:off

And to make the board boot, the parameters being passed is 

set cl mac0=%s noinitrd rootfstype=jffs2 root=/dev/mtdblock/0 rw

so that the board looks for the image in the NAND Flash and not for NFS.

Thanks to Vijay and you for the support!!!

Regards,
Neha

-----Original Message-----
From: Stuart Hughes [mailto:address@hidden 
Sent: Thursday, January 29, 2009 3:30 PM
To: Makhija, Neha (IE10)
Cc: ltibext; address@hidden; Vijay Nikam
Subject: RE: the RFS image address problem

Hi Neha,

I don't really follow this.  It look to me that your booting an NFS
image, I don't see where JFFS2 comes into it.

Can you give a more complete sequence (e.g the actual command your run)
you are trying and what you'd like to change this to.

Regards, Stuart

On Thu, 2009-01-29 at 12:29 +0530, Makhija, Neha (IE10) wrote:
> Thanks Vijay for the reply!
> 
>  
> 
> Yes I am sure that only for once we are using NFS to take the image
> and then it is programming it on the board.
> 
> Below is the Kernel parametets value which is being passed to it.
> 
> set cl mac0=00:08:ee:00:9b:b0 noinitrd root=/dev/nfs
> nfsroot=192.168.10.20:/tftpboot/rootfs ip=192.168.10.20:
> 192.168.10.20: 192.168.10.20:255.255.255.255::eth0:off
> 
>  
> 
>  
> 
> Can you send the printenv log? - what is printenv log?
> 
>  
> 
> ~Neha
> 
>  
> 
>                                    
> ______________________________________________________________________
> From:address@hidden
> [mailto:address@hidden 
> Sent: Thursday, January 29, 2009 12:20 PM
> To: Makhija, Neha (IE10)
> Cc: Stuart Hughes; ltibext; Vijay Nikam
> Subject: Re: the RFS image address problem
> Importance: High
> 
> 
>  
> 
> Hello Neha,
> 
> you can use MTD subsytem and do this partition where the RFS image
> must be loaded and use nand writ.jffs2 command to write rfs at that
> location ... and then according to that you can change the
> bootargs ...
> 
> > After this if te board is reseted then it is able to boot the board
> as per our requirement. This time the RFS image is present in the NAND
> > Flash and kernel is not using the NFS to bring the board up.
> 
> Are you sure at the next reset or reboot nfs is not used ... as I
> think the nfs is just copying the image to target RAM and executes
> everything in RAM the same goes for RFS ... so at the next reset or
> reboot it should use nfs ...
> 
> Can you send the printenv log ... perhaps it would be better to
> answer ... thanks ...
> 
> Kind Regards,
> Vijay Nikam
> 
> -----"Makhija, Neha (IE10)" <address@hidden> wrote: -----
> 
> To: "Stuart Hughes" <address@hidden>
> From: "Makhija, Neha (IE10)" <address@hidden>
> Date: 29/01/2009 11:34AM
> cc: "ltibext" <address@hidden>, "Vijay Nikam"
> <address@hidden>, <address@hidden>
> Subject: the RFS image address problem
> 
> Hi All
> 
> Using ltib, I have generated the kernel image and the RFS image for my
> Coldfire board. The RFS image is in jffs2 format and my board first
> takes kernel image through tftp and then it gives the control to
> kernel.
> While doing this the parameters are passed saying that it has to take
> the RFS image from the NFS (root=/dev/nfs). The kernel takes the image
> from NFS and programs it at the location 0x01000000 in the NAND Flash.
> After this if te board is reseted then it is able to boot the board as
> per our requirement. This time the RFS image is present in the NAND
> Flash and kernel is not using the NFS to bring the board up.
> 
> Now the requirement is to change this RFS start location to
> 0x00FFC000.
> I have no idea where to change this address in the ltib so that it
> gets
> reflected in the kernel and then kernel is able to program the RFS on
> this new location (0x00FFC000) and later on resetting the board, it
> should be able to read from that location and start the process as
> mentioned in it.
> 
> Plz suggest the changes needed for this!!
> 
> Thanks and Regards,
> Neha
> 
> -----Original Message-----
> From: Stuart Hughes [mailto:address@hidden
> Sent: Thursday, July 10, 2008 3:50 PM
> To: Makhija, Neha (IE10)
> Cc: ltibext; Vijay Nikam; address@hidden
> Subject: RE: [Ltib] RE: Reg ltib
> 
> 
> On Thu, 2008-07-10 at 10:20 +0530, Makhija, Neha (IE10) wrote:
> > Hi Stuart
> >
> > Sorry I confused everything.
> >
> > Let me tell you again.
> > First I tried to enable the native GDB so that the program which is
> > debugged is on the system where the gdb is running ie on the target
> I
> > wanted to run native gdb. After configuring with ./ltib -m config
> and
> > selecting the option as
> >  -> package list
> >       -> gdb
> >           -> gdb to run natively on the target
> > I gave
> >  ./ltib -p gdb
> >
> > And this generated the gdb exe in the ltib/rpm/BUILD/<GDB->/gdb/gdb
> > I copied this gdb on the target board. and then I gave ldd gdb on
> the
> > target board. It showed all the libraries needed for the gdb. One
> > library was missing, so I copied it from /ltib/rootfs/lib/ folder to
> the
> > target board's /lib folder and then when I ran the ./gdb, it gave me
> > error saying "BUS ERROR".
> >
> 
> This is incorrect.  Select 'gdb to run natively on the target' and
> then
> run:
> 
> $ ./ltib
> 
> This will build all the dependency package *and* install everything
> including gdb in rootfs/.... for the target.  You should never need to
> copy stuff by hand into the target area.
> 
> What platform are you trying to run on and what version of ltib do you
> have (was it from an ISO, if so which one)?
> 
> Regards, Stuart
> 
> Email Disclaimer:
> ---------------------------
> 
> This e-mail and any files transmitted with it are for the sole use of
> the
> intended recipient(s) and may contain confidential and privileged
> information. Computer viruses can be transmitted via email.The
> recipient should check this email and any attachments for the presence
> of viruses.
> The company accepts no liability for any damage caused by any virus
> transmitted by this email.
> 
> 
> 
> Using Symantec Hosted Mail Outbound Server