> To make things simple for users, there's standard layout. It's actually at
> sector 2048 btw.
Got that.
> That's what happens internally, it's just that some pieces (like sector
> offset
> of the partition!) need to be filled into the bootstream header by the
> mxsboot
> utility -- see mxsboot -h for how to change that.
You're completely right! This sector needs to be know build-time because it is
specified in the Boot Stream Block of the Boot Stream header. I forgot about
that, because I hid that in a script some time ago. That script was basically a
rewritten version of the broken one that was supplied with the SDK.
Come to think of it, it's a bit weird that the sector the BSB is located in, is
specified in the BSB: When reading it, it already knows this sector, because
that's the sector it is reading from at that moment...
> The 2048 sector offset was chosen because that's standard in Linux now for
> first
> partiiton.
Agreed.
> What do you mean?
What I meant to ask was how you solved the paradoxic problem that U-Boot needs
to initialize SD-RAM before it can be loaded (and obviously U-Boot needs to be
loaded before it can initialize SD-RAM).
Freescale solved this problem by putting multiple bootlets in their bootstream.
The first one is small enough to fit SRAM and it enables the PMIC's LDOs to
power up all power domains. The second one too is small enough to fit SRAM.
Loading it overwrites the first one and running it initializes SD-RAM. The
third one is either U-Boot or a Kernel and is directly loaded into the now
initialized SD-RAM.
I figured that your solution links U-Boot in a clever way that the lower part
fitting SRAM will initialize the PMIC and SD-RAM, after which U-Boot will load
the remainder of itself from MMC into SD-RAM.
> You can adjust that, see above.
Understood.
Cheers,
Robert.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
