Definitive(?) MLO limitations with PandaBoard
Jon Masters
I've previously posted about MLO limitations imposed on BeagleBoard:
http://groups.google.com/group/beagleboard/browse_thread/thread/ae8e64e6be02baae
In that thread it was stated my Vladimir Pantelic that:
"With regards to the 255/63 cargo cult, it is correct that it is
not needed for the rom code to boot, in fact the rom code does not
care for the C/H/S value at all. It might stem from the fact that MLO
aka x-loader had a hard coded start of partition 1 at sector 63, but
never versions do not have this limitation any more."
So I guess it's the 63 offset that's biting me, but I would like to note
for the achieve that after spending the night writing code to parse out
MBR and BS records, and comparing cards, I can confirm that the best way
to format an SD(HC) Card for the PandaBoard is as follows:
1). Ensure that you force heads to 255, sectors per track to 63
(in Linux fdisk, "x" (expert), "h", and s")
2). Ensure that you mark the partition type correctly
(I had previously favored FAT16, but 0xc FAT32 seems good)
3). Ensure that the partition is marked as active (very much required)
4). Ensure that you create an *even* sized FAT16 filesystem
(enter expert mode and verify the size during partitioning)
5). After making the filesystem, use the Linux "file" command:
file -s /dev/<device>
file -s /dev/<device><partition>
Verify that the filesystem is even and starts at sector 63.
I'm writing a much more complete utility inspired by Vladimir's earlier
post that decodes the MBR and various FAT structures and verifies that
the image will boot on a PandaBoard since this has been driving me nuts.
But I think if one follows all of the above, that seems to cover it too.
Jon.
Måns Rullgård
> Hi Folks,
>
> I've previously posted about MLO limitations imposed on BeagleBoard:
>
> http://groups.google.com/group/beagleboard/browse_thread/thread/ae8e64e6be02baae
>
> In that thread it was stated my Vladimir Pantelic that:
>
> "With regards to the 255/63 cargo cult, it is correct that it is
> not needed for the rom code to boot, in fact the rom code does not
> care for the C/H/S value at all. It might stem from the fact that MLO
> aka x-loader had a hard coded start of partition 1 at sector 63, but
> never versions do not have this limitation any more."
>
> So I guess it's the 63 offset that's biting me, but I would like to note
> for the achieve that after spending the night writing code to parse out
> MBR and BS records, and comparing cards, I can confirm that the best way
> to format an SD(HC) Card for the PandaBoard is as follows:
>
> 1). Ensure that you force heads to 255, sectors per track to 63
> (in Linux fdisk, "x" (expert), "h", and s")
The CHS settings DO NOT MATTER AT ALL. No code in ROM, x-loader, or
u-boot ever looks at them.
> 2). Ensure that you mark the partition type correctly
> (I had previously favored FAT16, but 0xc FAT32 seems good)
The partition type does not matter at all. Nothing ever looks at it.
> 3). Ensure that the partition is marked as active (very much required)
This is correct.
> 4). Ensure that you create an *even* sized FAT16 filesystem
> (enter expert mode and verify the size during partitioning)
Recent fdisk versions are in sector mode by default. Not quite as
recent ones print a very visible message urging you to switch to this
mode. There is no need to use the "expert" mode.
> 5). After making the filesystem, use the Linux "file" command:
> file -s /dev/<device>
> file -s /dev/<device><partition>
> Verify that the filesystem is even and starts at sector 63.
The start sector does not matter if using an x-loader dated after March
2010. Nobody should be using older ones. If they do, they get what
they deserve.
> I'm writing a much more complete utility inspired by Vladimir's earlier
> post that decodes the MBR and various FAT structures and verifies that
> the image will boot on a PandaBoard since this has been driving me nuts.
> But I think if one follows all of the above, that seems to cover it too.
Please stop perpetuating this cargo cult further.
--
Måns Rullgård
ma...@mansr.com
Jon Masters
> Jon Masters <jona...@jonmasters.org> writes:
> > 1). Ensure that you force heads to 255, sectors per track to 63
> > (in Linux fdisk, "x" (expert), "h", and s")
>
> The CHS settings DO NOT MATTER AT ALL. No code in ROM, x-loader, or
> u-boot ever looks at them.
That's a fair comment. And in fact if somehow you could actually change
the geometry this way, it would be unfortunate. But by setting this
geometry, the sector offset will (for example) be correct for the first
partition containing the MLO binary, so the outcome is correct.
> > 2). Ensure that you mark the partition type correctly
> > (I had previously favored FAT16, but 0xc FAT32 seems good)
>
> The partition type does not matter at all. Nothing ever looks at it.
Fair enough. Where is that documented? You get to complain, but only if
it's documented (by TI) in public and I should have seen that first ;)
> > 5). After making the filesystem, use the Linux "file" command:
> > file -s /dev/<device>
> > file -s /dev/<device><partition>
> > Verify that the filesystem is even and starts at sector 63.
>
> The start sector does not matter if using an x-loader dated after March
> 2010. Nobody should be using older ones. If they do, they get what
> they deserve.
Unfortunately, that doesn't really make for a very supportable set of
generic installation instructions:
person A: "Hi, I'm really excited and I'd like to help out!"
person B: "Great, look at these install instructions"
person A: "It doesn't work"
person B: "You deserve to not have a working system"
Yes, that's an exaggeration of your reply. I don't mean to criticize you
too much, since I realize we can just supply a newer MLO binary, etc.
However, older stuff is out there and I don't really see a problem with
ensuring things will work with that. Backward compatibility means that
once you ship something, people will (rightly or not) rely upon it.
> > I'm writing a much more complete utility inspired by Vladimir's earlier
> > post that decodes the MBR and various FAT structures and verifies that
> > the image will boot on a PandaBoard since this has been driving me nuts.
> > But I think if one follows all of the above, that seems to cover it too.
>
> Please stop perpetuating this cargo cult further.
So it doesn't directly use C,H,S and nor does anything else written this
millennium and we can kill that off properly if you want for the
archive, but the impact is still there in some cases. Or I might be
imagining what happened on Friday night when I tried to format and use a
brand new SDHC card that did not have the conventional 63 sectors, 255
heads being reported to fdisk during partitioning. Actually, I don't
think I imagined wasting a number of hours reading up on MBR/BS layouts
because I'm pretty sure that did happen.
Jon.
DJ Delorie
> I'm writing a much more complete utility inspired by Vladimir's earlier
> post that decodes the MBR and various FAT structures and verifies that
> the image will boot on a PandaBoard since this has been driving me nuts.
> But I think if one follows all of the above, that seems to cover it too.
I added these checks to a program I had already written to test some
of these, and put the result here: