* [U-Boot] [SPL mode] Question
2012-11-15 15:51 [U-Boot] [SPL mode] Question Lukasz Majewski
@ 2012-11-15 16:32 ` Andreas Bießmann
2012-11-16 10:59 ` Lukasz Majewski
2012-11-15 16:43 ` Stefano Babic
1 sibling, 1 reply; 4+ messages in thread
From: Andreas Bießmann @ 2012-11-15 16:32 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 4+ messages in thread* [U-Boot] [SPL mode] Question
2012-11-15 15:51 [U-Boot] [SPL mode] Question Lukasz Majewski
2012-11-15 16:32 ` Andreas Bießmann
@ 2012-11-15 16:43 ` Stefano Babic
1 sibling, 0 replies; 4+ messages in thread
From: Stefano Babic @ 2012-11-15 16:43 UTC (permalink / raw)
To: u-boot
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
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================
^ permalink raw reply [flat|nested] 4+ messages in thread