as i understand it, here are the first steps in the BB boot
sequence, starting from power up:
* onboard boot ROM (unchangeable)
* TI x-loader
* u-boot
first, am i correct that the very first step is the onboard boot
ROM, which is *not* the same as the x-loader? as i read it, that boot
ROM is fixed, you can't mess with that, while the x-loader is the
first step that you can, in fact, reprogram in flash if you want to
update it (same with u-boot).
so when i power up a new C3 BB with no SD card inserted, i'm not
surprised to see this:
...
Texas Instruments X-Loader 1.4.2 (Feb 19 2009 - 12:01:24)
Loading u-boot.bin from nand
U-Boot 2009.01-dirty (Feb 19 2009 - 12:22:31)
...
the above clearly represents the x-loader and u-boot that are shipped
with new BBs.
now here's where i got confused this morning. if i populate an SD
card with a much newer MLO (x-loader), u-boot.bin and uImage, insert
it, power cycle but do *not* press the USER button while this is
happening, i thought that the boot sequence would remain unchanged
(still from NAND). that's clearly not what's happening since i just
did that and here's what i got via minicom:
...
Texas Instruments X-Loader 1.4.2 (Feb 19 2009 - 12:01:24)
Reading boot sector
Loading u-boot.bin from mmc
U-Boot 2009.06-rc2 (Sep 09 2009 - 13:12:40)
...
what just happened there? at what point did the boot sequence
switch over to the SD card? as i read it, the same (NAND-based)
x-loader is running, but it clearly went to the SD card for the newer
u-boot image. why? i thought that required manual intervention on my
part, unless i've just been mistaken about that all along (a distinct
possibility).
and i just power-cycled using the USER button to get:
...
Texas Instruments X-Loader 1.4.2 (Sep 9 2009 - 09:20:15)
Reading boot sector
...
so that obviously forced the boot ROM to read the x-loader off of the
SD card.
so ... i'm still confused. if i don't intervene and power up the
BB, it seems like the onblard x-loader will be invoked, but that
x-loader will, if one exists on the SD card, invoke u-boot off of the
card, even if one exists in flash. is that correct?
rday
--
========================================================================
Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Kernel Pedantry.
Web page: http://crashcourse.ca
Twitter: http://twitter.com/rpjday
========================================================================
> apparently, everything i used to think about the BB boot sequence is
> not entirely true, so i'll publicly humiliate myself and ask someone
> to clarify where i've gone wrong.
... snip ...
here's a short followup, an explanation posted here:
http://e2e.ti.com/forums/p/4501/16475.aspx
"The OMAP3530 contains a boot ROM starting at location 0x00000000.
When powered on, the PC register jumps there. The boot ROM then looks
at the sys_boot pins to determine boot order. For NAND booting, the
x-loader is located at offset 0 in NAND. Actually the first two words
in NAND are the length of the x-loader and the address in internal RAM
to load it. The boot ROM then reads the x-loader from NAND into
internal RAM and jumps to that. The x-loader configures the clocks
and SDRAM and then reads u-boot from NAND into SDRAM. After u-boot is
in SDRAM, the x-loader jumps to u-boot and u-boot starts to run."
that's what i thought -- that without user intervention, the
x-loader would load u-boot "from NAND into SDRAM." but that's not
what's happening. unless i'm misreading this horribly, what i'm
seeing is
boot ROM -> NAND-based x-loader -> SD-based u-boot
with no user intervention on my part. so why does the x-loader go to
the SD card for u-boot? that *is* what's happening below, no?
...
Texas Instruments X-Loader 1.4.2 (Feb 19 2009 - 12:01:24)
Reading boot sector
Loading u-boot.bin from mmc
U-Boot 2009.06-rc2 (Sep 09 2009 - 13:12:40)
...
> at what point did the boot sequence
> switch over to the SD card?
It goes something like this:
* ROM looks for x-load in NAND unless you mess with SYSBOOT pins using
the USER button *and* it has a fallback to sd, serial and usb
* x-load looks for u-boot.bin on SD then falls back to looking for u-
boot.bin in NAND
* u-boot does its thing.
So if you have u-boot on your SD card it will generally get used.
regards,
Koen
>
> On Thu, 22 Oct 2009, Robert P. J. Day wrote:
>
>> apparently, everything i used to think about the BB boot sequence is
>> not entirely true, so i'll publicly humiliate myself and ask someone
>> to clarify where i've gone wrong.
>
> ... snip ...
>
> here's a short followup, an explanation posted here:
>
> http://e2e.ti.com/forums/p/4501/16475.aspx
>
> "The OMAP3530 contains a boot ROM starting at location 0x00000000.
> When powered on, the PC register jumps there. The boot ROM then looks
> at the sys_boot pins to determine boot order. For NAND booting, the
> x-loader is located at offset 0 in NAND. Actually the first two words
> in NAND are the length of the x-loader and the address in internal RAM
> to load it. The boot ROM then reads the x-loader from NAND into
> internal RAM and jumps to that. The x-loader configures the clocks
> and SDRAM and then reads u-boot from NAND into SDRAM. After u-boot is
> in SDRAM, the x-loader jumps to u-boot and u-boot starts to run."
That only applies to ancient x-load versions. Recent versions prefer SD.
regards,
Koen
thanks for clarifying that, that's a fairly critical tidbit of info
of which i was obviously unaware. that also tells me that, if i'm
perfectly happy with the on-board x-loader, i need populate my SD card
with only a newer u-boot and uImage.
it also suggests that, no matter how badly you've messed up your BB,
as long as your onboard x-loader is fine, there's not much reason to
ever use the USER button during power up, is there?
is there a URL with a recent description of x-loader functionality?
thanks.
rday
p.s. while i'm aware of *how* to upgrade the x-loader in NAND, has
there been any compelling reason to do that recently?