Re: Do I want to debootstrap Debian armhf on my iMX53 board?
On Fri, Aug 19, 2011 at 12:51:35PM -0400, Lennart Sorensen wrote:
> I am pretty sure I saw another document that indicated what each dip
> switch position did for boot config, but I saw that yesterday and can't
> seem to find it today. Reading through all of that PDF seems to give
> an idea what most of the dip switch settings do, although it does not
> make clear if you have to change any of the existing resistors to make
> all the dip switch settings usable.
>
> I especially like "After initial testing of the Quick Start board,
> the optimum BOOT_CFG settings for flexibility and ease of use were
> determined."
>
> Well my life and ease of use would have been improved by having SATA boot,
> but now I can't have that. So they clearly determined wrong. Also
> anyone using this as a reference board to develop their own board would
> almost certainly have prefered having simple ways to actually test the
> configuration they intended to use. I think freecale clearly messed
> up here. Oh well. Not sure how removing options is considered optimum
> flexibility.
>
> Of course direct SATA boot does have a problem too. You can't possibly
> use GPT as your partition format if you want direct SATA boot since the
> u-boot location has to be at 1k, and GPT requires the first 33 sectors
> of the device. Only really a problem for large disks, or for people that
> like a better partition format. U-boot on the microsd wouldn't have a
> problem with that of course.
While I am being "whiny" about these things I do want to say I am very
pleased that freescale made this thing boot from removable media rather
than needing to flash an eeprom with boot code. Makes it impossible to
brick the thing. That is very nice.
The GPT issue I think can be worked around.
GPT uses sector 0 for a legacy partition table.
sector 1 is the header.
sector 2 is where partition entries start, each 128 bytes long, and up
to 128 of them.
In a partition entry, the first thing is a 16byte GUID type identifier.
I am thinking it shouldn't be hard to make 16 bytes of anything one wants
be arm code that simply jumps forward by 16KB or so, to just after the
partition table. If u-boot is compiled with a base address higher by
that much, that should solve it. The only thing it would leave is that
the first partition entry in GPT is not a partition at all, but instead
jump code for u-boot. I just might have to go try that out for fun,
even though I don't have a disk large enough to require GPT for
partitioning yet.
--
Len Sorensen
Reply to: