Dear Lukasz Majewski,
On 15.11.2012 16:51, Lukasz Majewski wrote:
Hi Stefano,
I've got some questions about Falcon mode and spl export command.
I've looked into the ./common/cmd_spl.c at master branch SHA1: 59852d03867108217fe88e3bfc3e1e9cedfe63c5
Correct me if I'm wrong (or I've overlooked something). It looks that, this file version is a very early version.
It is.
After reading "Falcon" mode README - I'd expect, that "spl export" will write either ATAGS or FDT to NAND (or any other memory). For this file it doesn't do that. Am I missing some additional patches?
No, the 'spl export' does not write to a storage media at all, the 'spl export' command is intended to save the prepared information in RAM. This information must then be transferred to a final destination where the SPL will load it. The destination is defined at compile time (CONFIG_CMD_SPL_NAND_OFS for NAND).
Since you stated, that Falcon mode is only (now) supported on NAND memory, I'd like to ask if it is acceptable to extend cmd_spl.c to write ATAGS/FDT image to eMMC or (better) to partition formatted as EXT4 of FAT?
So far only NAND is implemented, if you plan to implement another mode you need to extend the SPL by some mechanism to get the required data ('configuration BLOB' either ATAGS or FDT) and kernel from that media. The 'configuration BLOB' generated by the 'spl export' command should then be saved by other existing u-boot commands to its final destination. I think the spl command do not need to know about the storage media used. I personally think a 'spl export ..; nand write ...;' is fine, for more convenience this could also be scripted. In a perfect world you will do this only once, but the complexity of spl command will be carried always.
I can imagine a following scenario:
- Use u-boot to generate ATAGS (from bootcmd args defined for board
or cmd line parameters) or FDT blob with "spl export". Store it on a partition or eMMC.
Well, the FDT blob will not be generated by the 'spl export' (or did I get this wrong?). You will need a FDT blob to generate the stuff that is handed to the kernel. In fact the existing FDT is encapsulated by some header, isn't it that way?
- Use SPL (second stage bootloader) to parse this blob, place ATAGS or
FDT accordingly, read uImage and pass execution to it.
SPL should not parse but copy the prepared data to RAM and branch the kernel.
Best regards
Andreas Bießmann