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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot