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:

1. 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?

2. 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

On 15/11/2012 16:51, Lukasz Majewski wrote:

Hi Stefano,

Hi Lucasz,

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.

I do not know what you are meaning. When the feature flew into mainline (after several versions, maybe the reason it is not yet strongly modified), there was at least one board (the twister) with this feature. After that, the devkit8000 was added, and recently I saw a MPC5200 board.

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?

This is right. The reason is to have "spl export" not specialized for each media, and let the user to save persistently its result: spl export writes the kernel parameters / fdt on the RAM, exactly as the bootm command does.

The user is then responsible to save the data, and automatically, we have support for all media we are able to manage under u-boot. If after spl export you run a "mmc write" instead of "nad write", you have out of the box the way to use this feature (again: the generation of the kernel parameters / fdt) with all media.

And everyone can add a script to simplify the process, calling in sequence "spl export" and then "nand write", "mmc write", "sf write.."

Since you stated, that Falcon mode is only (now) supported on NAND memory,

I confess I have tested only on NAND: this is the reason I am saying that only NAND is supported. devkit8000 uses NAND, too, but a3m071 is based on powerpc and uses NOR:

http://patchwork.ozlabs.org/patch/193395/

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?

No, I do not think it is duty of spl export. As you see, there are a lot of cases. After "spl export", you can decide yourself where to put the parameters. I would say that what you want is already supported ;-)

I can imagine a following scenario:

1. 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.

Right:

spl export .... mmc init mmc write ...

2. Use SPL (second stage bootloader) to parse this blob, place ATAGS or

FDT accordingly, read uImage and pass execution to it.

SPL does not parse the blob, else we lose the goal : to be faster. Parsing is done by the "spl export" command that creates a snapshot for the kernel. SPL loads both kernel and "prepared" parameters into RAM and starts the kernel. SPL does not check at all inside the parameters.

This means that, each time you change a parameter, you need to run again "spl export", saving the result into your media, else the kernel boots with the old values.

Best regards, Stefano