I received a BB-XM today and it works fine
with the supplied SD card.
Then, I tried to use our SD card that works fine on a C4
board but I just get a "60" message on the serial interface.
I.e. U-Boot is not even starting.
What I had expected is that at least U-Boot is starting
(we use a version that already contains code to detect
the D-type model and should set the different PinMux
and clock).
But are there also differences in MLO so that the C4 MLO
does completely fail on XM?
Nikolaus
The changed title should be more precise what my question
is about (was a short night).
To be even more precise in the hope that someone can shed light on it:
The SRM says on page 147 (takes a while to get there):
UBoot does not start, and no activity on the RS232 monitor.
If a 60 is displayed over the serial cable, processor is booting. Issue could be the SD/MMC card.
Make sure the SD/MMC card is installed all they way into the connector.
Make sure the card is formatted correctly and that the MLO file is the first file written to the SD card.
I get the "60", but the card is formatted in a way that it works
perfectly in a BB-C4.
So I am still trying to understand what has changed between
BB-C4 and BB-XM (in formatting or MLO)?
Has the definition of what is "correct" with respect to formatting
changed? E.g. different number of cylinders, different
minimum FAT partition size?
Or is the old C4-MLO binary simply incompatible to the BB-XM?
If that is the reason - does the XM-MLO work on a C4 board?
Tnx for any hints,
Nikolaus
The -xM has a different processor than the C4. Most importantly, the memory is different on the -xM. So, the MLO on the C4 will not work on the -xM. Supposedly, the new -xM MLO should work on C4, but I have not heard anyone say that they have tried it.
Gerald
So far the old -xM MLO works just fine on my Bx, Cx's.. 
Regards,
That is good news! I wonder if the latest one does? It may even be the one you are using.
http://beagleboard-validation.s3.amazonaws.com/deploy/201008201549/sd/list.html
Gerald
The -xM has a different processor than the C4. Most importantly, the memory is different on the -xM. So, the MLO on the C4 will not work on the -xM. Supposedly, the new -xM MLO should work on C4, but I have not heard anyone say that they have tried it.
It works on my B6, C3 and C4 and xM rev A beagles 
for pedantry's sake, are all current -xM boards being shipped
officially version "A"? until there's an obvious upgrade?
rday
Actually, there was a P1, P2, P3, P4, P5, P6, P7, P8 , A, A1, and A2. Rev A2 is the shipping version.
Gerald
I was making the distinction since I worked with P7 and P8 xM boards, which might not work with the current MLO. I'll leave the rev A question to Gerald 
regards,
Koen
Yeah they should all be "A2's" and i think it's useful for
documentation purposes... Unless you want to repeat the u-boot usb
fiasco last year with the C4 boards cause people were using a "Cx"
u-boot that wasn't setting the ehci power rail on "C4" boards..
Regards,
which conveniently matches the designation on the current SRM. ok.
so i'm going to assume that, until there is another major announcement
of a board upgrade, simply referring to the -xM should be sufficient
to identify the officially shipped board, yes? or should we be more
specific than that in all of our discussions? it's subtle
distinctions like that that sometimes get us into trouble.
rday
Trust me. You better refer to it as the Rev A2.
Gerald
okey dokey.
rday
I tried the MLO downloaded from the link below - and compare to the
one on the SD card that came with the BB-XM-A2. They are binary
equivalent.
But neither MLO works when copied onto my SD card. The SD card works
fine in a BB-C4.
I now start to suspect that the MLO isn't used at all on the C4. Maybe
I should delete it to verify... Yes, it still boots. So the C4 is
running the
MLO from flash and just loads U-Boot from the SD-Card.
The last idea I have is about formatting (which is done using fdisk
according to the standard instructions, and MLO is the first file
copied to
the FAT partition). Maybe we have a bug in our formatting script and
never noticed because the C4 board did hide it.
Regards,
Nikolaus
Did you hold down the user button... On the C4 (Bx/Cx) the board will
always start/default to NAND (then a bunch of specific things) for
MLO, unless you hold down the user button, which puts the MMC card
before NAND..
Regards,
Ah, I need a new "eye-opener"
Yes, I did *not* press the User button on the C4 board. So it never
tried to read
the MLO from there and since NAND flash has one this bug never became
visible
on the C4 board.
Now back to the real problem. It appears to be a slightly bad
formatted SD card.
1. here the fdisk of the Angstrom demo image that came with the BB-XM-
A2
Disk /dev/sdb: 3959 MB, 3959422976 bytes
255 heads, 63 sectors/track, 481 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sdb1 * 1 15 120456 c W95 FAT32
(LBA)
/dev/sdb2 16 16 8032+ 83 Linux
2. here the fdisk of my SD card
Disk /dev/sdb: 4072 MB, 4072669184 bytes
255 heads, 63 sectors/track, 495 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sdb1 * 1 2 16033+ c W95 FAT32
(LBA)
/dev/sdb2 3 495 3960022+ 83 Linux
It has the right number of heads / secors, but a higher
number of cylinders. That is strange since both are 4GB cards.
And, I found a note on http://code.google.com/p/beagleboard/wiki/LinuxBootDiskFormat
that goes in the same direction:
"Also, for unknown reasons, after the first fdisk on a SanDisk? 2GB SD
Card (about the most common card you can find) the total bytes shows
up under fdisk as 1977614336 and not the full 2GB. When you do the
calculation above, you end up with number of cylinders = 240, not 245.
My resulting SD Card was not recognized by the X-Loader until I
corrected this."
I.e. the number of cylinders is very important.
Anyone who knows more about this aspect?
Nikolaus
> > I now start to suspect that the MLO isn't used at all on the C4. Maybe
> > I should delete it to verify... Yes, it still boots. So the C4 is
> > running the
> > MLO from flash and just loads U-Boot from the SD-Card.> > The last idea I have is about formatting (which is done using fdisk
> > according to the standard instructions, and MLO is the first file
> > copied to
> > the FAT partition). Maybe we have a bug in our formatting script and
> > never noticed because the C4 board did hide it.
Ok,
I now succeeded in getting a SD card where MLO is loaded
on the BB-XM-A2 by using the sfdisk based script on
Since I found reports that sfdisk is more correct and reliable, I
suspect that
my fdisk is doing something that is not compatible with the Boot ROM.
Therefore, I can recommend to everyone who has problems formatting the
SD
card(s) to try "sfdisk".
But now I have the next problem. My self-compiled U-Boot does not
start.
It works perfectly on a C4 board (just swapping the card to the C4
board).
The messages I get on the BB-XM are:
Texas Instruments X-Loader 1.4.4ss (Aug 19 2010 - 02:49:27)
Beagle xM Rev A
Reading boot sector
Loading u-boot.bin from mmc
I.e. no console from U-Boot...
My U-Boot is based on all the U-Boot recommendations from this list
and contains all "D" and "XM" patches I have seen being discussed.
Maybe something in Pin-Mux / RS232 or other hardware control is
missing.
So my next question is where I can find the latest/official U-Boot
sources for the BB-XM to check/sync with?
Nikolaus
The shipping sources are part of Angstrom. You can find the recipe at
http://cgit.openembedded.net/cgit.cgi/openembedded/tree/recipes/u-boot/u-boot_git.bb.
Note the currently long list of patches and fairly old u-boot
starting point. 
I did the latest patch development for that on this git tree:
http://gitorious.org/beagleboard-validation/u-boot/commits/validation-20100818
Currently, I'm trying to rebase u-boot onto a set that Steve Sakoman
is submitting upstream and I'm dealing with a lot of directory changes
and altered patches. Once I get aligned with Steve and close to
mainline, I'll start submitting the patches to the u-boot mailing
list. I copied this list in some of the earlier and more potentially
controversial patches and not all the comments got addressed.
Notably, there was a request to alter u-boot to have a command to read
the environment from the flash and to alter u-boot to not use the
environment from the flash by default unless the default bootcmd read
it and tried to use it. That change will be very important for Rev
Bx/Cx flash recovery. We are hoping to have that in a Rev C5, which
would just be a C4 with an updated and aligned u-boot with xM Rev Ax
so that we could be on one set of validation instructions.