public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
* [U-Boot] [SPL mode] Question
@ 2012-11-15 15:51 Lukasz Majewski
  2012-11-15 16:32 ` Andreas Bießmann
  2012-11-15 16:43 ` Stefano Babic
  0 siblings, 2 replies; 4+ messages in thread
From: Lukasz Majewski @ 2012-11-15 15:51 UTC (permalink / raw)
  To: u-boot

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. 

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?

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?

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.

2. Use SPL (second stage bootloader) to parse this blob, place ATAGS or
FDT accordingly, read uImage and pass execution to it.

What is your opinion?


-- 
Best regards,

Lukasz Majewski

Samsung Poland R&D Center | Linux Platform Group

^ 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-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

* [U-Boot] [SPL mode] Question
  2012-11-15 16:32 ` Andreas Bießmann
@ 2012-11-16 10:59   ` Lukasz Majewski
  0 siblings, 0 replies; 4+ messages in thread
From: Lukasz Majewski @ 2012-11-16 10:59 UTC (permalink / raw)
  To: u-boot

Hi Andreas,

> 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

Thanks for clarification. This is what I was missing.

-- 
Best regards,

Lukasz Majewski

Samsung Poland R&D Center | Linux Platform Group

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2012-11-16 10:59 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox