Loading RootFS via Uboot TFTP

This forum is for users of Microchip MPUs and who are interested in using Linux OS.

Moderator: nferre

sephers2
Posts: 6
Joined: Mon Mar 05, 2018 12:28 am

Loading RootFS via Uboot TFTP

Thu Sep 06, 2018 9:58 am

Hi,

I'm trying to load in the Linux RootFS to the SAMA5D27-SOM1-EK via TFTP and Uboot but I can't find too much information about it. I have managed to load the Kernel and DTB via TFTP no problem by setting the bootcmd as:

Code: Select all

sf probe 0; tftp 0x21000000 dtb.dtb; tftp 0x22000000 zImage.bin; bootz 0x22000000 - 0x21000000
and at present I have a MicroSD card with an EXT3 partition with my RootFS on it, programmed by Etcher according to the Linux4SAM instructions - note for this to work my bootargs is set to:

Code: Select all

console=ttyS0,115200 earlyprintk root=/dev/mmcblk1p2 rw rootwait
However, I want Uboot to pull in the RootFS via TFTP. I can see 2 ways of doing this, either pull the RootFS into SRAM which would be quite easy as I simply need to add another command similar to the above but with a different location in SRAM - if so what locaiton? Or if this isn't advised then I need to pull the RootFS over the network and re-write the MicroSD card - but I'm not sure if Uboot has this functionality?

Does anyone know a way to do this, as the Linux4SAM website mentions "On a development system, it is useful to get the kernel and root file system through the network. U-Boot provides support for loading binaries from a remote host on the network using the TFTP protocol.", but like I said I can't find much more info on it with regard to SAM devices.

Thanks in advance.

George.
blue_z
Location: USA
Posts: 1767
Joined: Thu Apr 19, 2007 10:15 pm

Re: Loading RootFS via Uboot TFTP

Fri Sep 07, 2018 11:45 pm

sephers2 wrote: However, I want Uboot to pull in the RootFS via TFTP.
Why? You already have a rootfs stored on the SDcard.
Where is this downloaded rootfs supposed to reside?

sephers2 wrote: ... either pull the RootFS into SRAM which would be quite easy as I simply need to add another command similar to the above but with a different location in SRAM - if so what locaiton?
You're not clear as to what this operation is supposed to do.
The only SRAM on that board is the internal SRAM of the SAMA5D27 SIP, and there's only 128 Kbytes of it.
That's insufficient space to hold a rootfs, or it's unnecessarily small for a transfer buffer.


sephers2 wrote: Or if this isn't advised then I need to pull the RootFS over the network and re-write the MicroSD card - but I'm not sure if Uboot has this functionality?
If you transfered an image of the rootfs, then U-Boot could write that image to the SDcard, assuming that U-Boot is configured with that capability (i.e. the `mmc write` command).
Since your target board only has a total of 128 Mbytes of main memory, the rootfs image would probably have to be transferred and written in several segments.
U-Boot will not be able to deal with a tarball archive of a rootfs.

BTW you can always remove the SDcard from the target, and update it on the development host.


sephers2 wrote: I can't find much more info on it with regard to SAM devices.
Maybe because this really isn't an issue specific to Microchip/Atmel devices.
For kernel development, the fastest test cycle is probably build and then boot the kernel with dtb using TFTP as you describe.
If the rootfs is being changed (and it's not too large), then an initramfs (using an archive linked into the kernel image) offers the fastest test cycle.
Instead of rewriting the rootfs on non-volatile storage on the target board, a network-based rootfs is an alternative.
Otherwise if the rootfs isn't being changed, then it can reside on non-volatile storage.

Regards
sephers2
Posts: 6
Joined: Mon Mar 05, 2018 12:28 am

Re: Loading RootFS via Uboot TFTP

Sat Sep 08, 2018 3:46 pm

Hi blue_z,

Thanks for your insight. Essentially I just want to be able to develop on the SAMA5D2-SOM without having to remove the memory card, write to it on the host and re-boot the board. By pulling everything from a remote host, I can simply re-build the rootfs/kernel/dtb and then hit reset on the board.
blue_z wrote:
Fri Sep 07, 2018 11:45 pm
sephers2 wrote: However, I want Uboot to pull in the RootFS via TFTP.
Why? You already have a rootfs stored on the SDcard.
Where is this downloaded rootfs supposed to reside?
As mentioned above, pull the rootfs from TFTP and store it on the SD Card since QSPI flash is too small.
blue_z wrote:
Fri Sep 07, 2018 11:45 pm
sephers2 wrote: ... either pull the RootFS into SRAM which would be quite easy as I simply need to add another command similar to the above but with a different location in SRAM - if so what locaiton?
You're not clear as to what this operation is supposed to do.
The only SRAM on that board is the internal SRAM of the SAMA5D27 SIP, and there's only 128 Kbytes of it.
That's insufficient space to hold a rootfs, or it's unnecessarily small for a transfer buffer.
If SRAM is too small then that solves that. I wasn't entirely sure if the RootFS is copied to SRAM like the kernel is, but as I'm writing this I realise that outright wouldn't work.
blue_z wrote:
Fri Sep 07, 2018 11:45 pm
sephers2 wrote: Or if this isn't advised then I need to pull the RootFS over the network and re-write the MicroSD card - but I'm not sure if Uboot has this functionality?
If you transfered an image of the rootfs, then U-Boot could write that image to the SDcard, assuming that U-Boot is configured with that capability (i.e. the `mmc write` command).
Since your target board only has a total of 128 Mbytes of main memory, the rootfs image would probably have to be transferred and written in several segments.
U-Boot will not be able to deal with a tarball archive of a rootfs.

BTW you can always remove the SDcard from the target, and update it on the development host.
This is the sort of thing I was thinking but it seems again it's not practical for Uboot to do this with a small amount of memory and a large RootFS to write.
blue_z wrote:
Fri Sep 07, 2018 11:45 pm
sephers2 wrote: I can't find much more info on it with regard to SAM devices.
Maybe because this really isn't an issue specific to Microchip/Atmel devices.
For kernel development, the fastest test cycle is probably build and then boot the kernel with dtb using TFTP as you describe.
If the rootfs is being changed (and it's not too large), then an initramfs (using an archive linked into the kernel image) offers the fastest test cycle.
Instead of rewriting the rootfs on non-volatile storage on the target board, a network-based rootfs is an alternative.
Otherwise if the rootfs isn't being changed, then it can reside on non-volatile storage.
I think this is the way to go, I know it's possible to mount the RootFS from a remote location, rather than copy it across and store it locally. It's obviously not practical for production but it'll do just fine for development purposes.

Thanks very much for you help, I will investigate mounting the RootFS from a remote location.

Return to “LINUX”

Who is online

Users browsing this forum: Google [Bot] and 3 guests