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