All of lore.kernel.org
 help / color / mirror / Atom feed
* [U-Boot] Info on NAND-SPL
@ 2011-02-26 11:34 Hatim Ali
  2011-02-27 18:11 ` Wolfgang Denk
  2011-03-01  5:53 ` Aneesh V
  0 siblings, 2 replies; 5+ messages in thread
From: Hatim Ali @ 2011-02-26 11:34 UTC (permalink / raw)
  To: u-boot

Hello, 
?
I was trying to understand how NAND-SPL works. What I could understand after seeing the code is that 
1) NAND-SPL is a standalone application which will load the U-boot in the main memory. 
2) After doing the clock and DRAM initialization it will relocate itself in the DRAM. 
3) Then it will copy the u-boot from the nand into the RAM and execute the u-boot. 
?
If my understanding is proper, then I have one doubt 
1) Since the nand_spl is making use of the same Start.S and lowlevel_init.S, the u-boot code will also perform relocation? So is it not a overhead doing relocation twice? 
?
Also is there any similar implementation for MMC-SPL? 
?
Thanks 
Hatim 

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

* [U-Boot] Info on NAND-SPL
  2011-02-26 11:34 [U-Boot] Info on NAND-SPL Hatim Ali
@ 2011-02-27 18:11 ` Wolfgang Denk
  2011-02-28 11:43   ` Albert ARIBAUD
  2011-03-07 22:02   ` Scott Wood
  2011-03-01  5:53 ` Aneesh V
  1 sibling, 2 replies; 5+ messages in thread
From: Wolfgang Denk @ 2011-02-27 18:11 UTC (permalink / raw)
  To: u-boot

Dear Hatim Ali,

In message <96382.60182.qm@web95116.mail.in2.yahoo.com> you wrote:
>
> I was trying to understand how NAND-SPL works. What I could understand after
> seeing the code is that 
> 1) NAND-SPL is a standalone application which will load the U-boot in the main memory. 

You probably mean the right thing, but use inappropriate terms.

In U-Boot context, a "standalone application" is a program that runs
under control of U-Boot, using U-Boot provided features like I/O
functions.

^The nand_spl code is no such application. It is a minimzed
configuration of U-Boot code.

> 2) After doing the clock and DRAM initialization it will relocate itself in
>  the DRAM. 

I'm not sure what you mean - the code does not relocate itself (keep
in mind that relocation and copying are two different things).

> 3) Then it will copy the u-boot from the nand into the RAM and execute the
> u-boot. 

This is the actual purposse.

> If my understanding is proper, then I have one doubt 
> 1) Since the nand_spl is making use of the same Start.S and lowlevel_init.S
> , the u-boot code will also perform relocation? So is it not a overhead doing
> relocation twice? 

nand_spl loads the U-Boot code into RAM, and then relocates it (which
includes copying it to the final location). There is no relocation
done twice, only the copying, and this cannot be avoided as the
bootstrap loader cannot determine the final position of the image
yet.  If you are sure that you have a static system with a fixed
memory map you can configure nand_spl such that it copies U-Boot to
the final location, one copy operation can be saved (you still need
the relocation, though).

> Also is there any similar implementation for MMC-SPL? 

Not yet. Patches welcome.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Suffocating together ... would create heroic camaraderie.
	-- Khan Noonian Singh, "Space Seed", stardate 3142.8

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

* [U-Boot] Info on NAND-SPL
  2011-02-27 18:11 ` Wolfgang Denk
@ 2011-02-28 11:43   ` Albert ARIBAUD
  2011-03-07 22:02   ` Scott Wood
  1 sibling, 0 replies; 5+ messages in thread
From: Albert ARIBAUD @ 2011-02-28 11:43 UTC (permalink / raw)
  To: u-boot

Hi Wolfgang,
Le 27/02/2011 19:11, Wolfgang Denk a ?crit :

> nand_spl loads the U-Boot code into RAM, and then relocates it (which
> includes copying it to the final location). There is no relocation
> done twice, only the copying, and this cannot be avoided as the
> bootstrap loader cannot determine the final position of the image
> yet.  If you are sure that you have a static system with a fixed
> memory map you can configure nand_spl such that it copies U-Boot to
> the final location, one copy operation can be saved (you still need
> the relocation, though).

Note that in the case of ARM -- don't know about other archs -- if the 
final U-Boot location is known in advance, then one could try linking 
U-boot to that final location, in which case the relocation would not be 
needed either and should normally be skipped by the code currently in 
start.S.

Amicalement,
-- 
Albert.

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

* [U-Boot] Info on NAND-SPL
  2011-02-26 11:34 [U-Boot] Info on NAND-SPL Hatim Ali
  2011-02-27 18:11 ` Wolfgang Denk
@ 2011-03-01  5:53 ` Aneesh V
  1 sibling, 0 replies; 5+ messages in thread
From: Aneesh V @ 2011-03-01  5:53 UTC (permalink / raw)
  To: u-boot

Hello Hatim,

On Saturday 26 February 2011 05:04 PM, Hatim Ali wrote:
> Hello,
>
> I was trying to understand how NAND-SPL works. What I could understand after seeing the code is that
> 1) NAND-SPL is a standalone application which will load the U-boot in the main memory.
> 2) After doing the clock and DRAM initialization it will relocate itself in the DRAM.
> 3) Then it will copy the u-boot from the nand into the RAM and execute the u-boot.
>
> If my understanding is proper, then I have one doubt
> 1) Since the nand_spl is making use of the same Start.S and lowlevel_init.S, the u-boot code will also perform relocation? So is it not a overhead doing relocation twice?

As Albert mentioned in another mail, image copying and relocation can
be suppressed by using your linked address as the target address when
you call relocate_code.

This is easier to achieve in SPL because we have a custom and simpler
board_init_f. This is much more difficult to achieve in regular U-Boot
because the target address is calculated at run-time in board_init_f
and also depends on the U-Boot size.

>
> Also is there any similar implementation for MMC-SPL?

You might want to have a look at the series I posted yesterday for
OMAP4. Please note that relocation and image copying has been
suppressed in this SPL.

Br,
Aneesh

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

* [U-Boot] Info on NAND-SPL
  2011-02-27 18:11 ` Wolfgang Denk
  2011-02-28 11:43   ` Albert ARIBAUD
@ 2011-03-07 22:02   ` Scott Wood
  1 sibling, 0 replies; 5+ messages in thread
From: Scott Wood @ 2011-03-07 22:02 UTC (permalink / raw)
  To: u-boot

On Sun, 27 Feb 2011 19:11:28 +0100
Wolfgang Denk <wd@denx.de> wrote:

> Dear Hatim Ali,
> 
> In message <96382.60182.qm@web95116.mail.in2.yahoo.com> you wrote:
> > 2) After doing the clock and DRAM initialization it will relocate itself in
> >  the DRAM. 
> 
> I'm not sure what you mean - the code does not relocate itself (keep
> in mind that relocation and copying are two different things).

The SPL does relocate itself, at least on 83xx/85xx, so it can continue
running after copied to RAM (which must happen before it loads anything more
from NAND).

It's not "done twice", though -- it's done once each on two different
images.

-Scott

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

end of thread, other threads:[~2011-03-07 22:02 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-02-26 11:34 [U-Boot] Info on NAND-SPL Hatim Ali
2011-02-27 18:11 ` Wolfgang Denk
2011-02-28 11:43   ` Albert ARIBAUD
2011-03-07 22:02   ` Scott Wood
2011-03-01  5:53 ` Aneesh V

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.