Post- GTA02

Paul Jimenez pj at place.org
Wed Mar 19 19:19:49 CET 2008


On Wednesday, Mar 19, 2008, Andy Green writes:
>Somebody in the thread at some point said:
>> On Wednesday 19 March 2008 17:28, Andy Green wrote:
>>>> To my opinion if you are willing to spend more than 4 hours writing a
>>>> bootloader bigger than 4k and with SD Card boot feature (vfat?) you
>>>> better switch to u-boot. It is more robust. It has all stuff we need
>>>> from a bootloader.
>>> What I would have done here is dump the registers for the CPU after
>>> U-Boot initialized them, and diff them against a dump after my
>>> bootloader had started Linux.
>> It sounds simple: just a diff of registers.
>> What about the memory controller, NAND controller, serial ports
>> or other registers memory based? In that case you will miss them.
>
>They're all memory mapped, clock, NAND, memory controller, UART, GPIO
>the lot.  You can dump them from U-Boot with the memory dump commands
>and add some code to your bootloader to dump them from there: if this
>made the problem you should find it.
>
>If the problem is somehow somewhere else (not sure where since not much
>else is inherited by Linux that isn't the kernel image in memory, or in
>the peripheral / CPU register settings) you at least get to rule
>register settings out as the problem :-)
>
>- -Andy


-1 for writing our own bootloader

If U-boot is bloated and big, we should certainly look into why that's
so and slim it down, but IMO we should avoid reinventing the wheel and
stick with what works.

If we want to do the boot-straight-to-kernel thing, that's fine too.

The main thing in either case is that we get to leverage other work
being done that might be helpful (like drivers, etc) and don't have to
spend resources keeping up-to-date.


My $.02,

  --pj





More information about the openmoko-kernel mailing list