[U-Boot] Debugging why my kernel won't start

[Rogan Dawes]

On 2010/08/17 5:38 PM, Albert ARIBAUD wrote:

> Ok, so u-boot is now out of the way of the linux image load area.
> 
>> Now to figure out why I'm not getting any further than this. (And why
>> the vendor ramdisk is giving me CRC errors).
> 
> What is the actual command you use for booting your kernel? IIUC (and if 
> I trust the few experiments I did on edminiv2 with ramdisks) you need to 
> pass the ramdisk address to the bootm command, e.g. bootm ff820000 
> ff8xxxxx (where xxxxx is your ramdisk's location in flash (I'm assuming 
> your ramdisk image is in flash as your kernel image is). You did an 
> 'iminfo' on both images to verify their integrity, didn't you?
> 
> Amicalement,

Well, there are two approaches. The vendor u-boot uses two parameters to
pass the address of the ramdisk to the kernel.

Without that parameter, the kernel should still boot, and show the
initial messages, until it tries to mount its root filesystem, at which
point it should panic.

I'm not passing the second parameter at this stage, because the ramdisk
is failing the CRC32 check for some reason. It may be that the CRC32
calculation has changed between 1.1.1 which was the base for the vendor
u-boot, and mainline. e.g. rather than being calculated over the precise
length of the data, it is calculated over the entire block. Just a
guess, of course.

But until I can get the standard firmware to boot from my replacement
U-boot, I'll keep trying.

The hints I'm getting from googling for <u-boot "done, booting the
kernel"> are suggesting that the problem is likely a machid mismatch.

And indeed, that WAS the problem.

I had been led to believe that it was possible to override the compiled
in mach type by setting a "machid" environment variable. This would give
me the best of both worlds - a u-boot compiled according to mainline
registered numbers, with the ability to boot vendor firmware by simply
setting an environment variable.

Unfortunately, this did not work for me :-(

-#define MACH_TYPE_DNS323               1542
+#define MACH_TYPE_DNS323               526

Making the above change results in a booting kernel, until the root fs
can not be found.

Am I mistaken in expecting the machid environment variable trick to work?

Thanks

Rogan