On Wed, 2011-11-30 at 15:37 +0000, Dave Martin wrote: > > This results in a uImage which is a bit broken if using a normal u-Boot > configured for vexpress-v2p-ca9, because the bootloader makes some > memory map assumptions, and anyway we don't expect the kernel to work > unless it's loaded at the start of RAM: > > > ## Booting kernel from Legacy Image at 62000400 ... > Image Name: Linux-3.2.0-rc3+ > Image Type: ARM Linux Kernel Image (uncompressed) > Data Size: 2464984 Bytes = 2.4 MiB > Load Address: 80008000 > Entry Point: 80008000 > Verifying Checksum ... OK > ## Loading init Ramdisk from Legacy Image at 80ffffc0 ... > Image Name: > Image Type: ARM Linux RAMDisk Image (uncompressed) > Data Size: 2216523 Bytes = 2.1 MiB > Load Address: 81000000 > Entry Point: 81000000 > Verifying Checksum ... OK > ## Flattened Device Tree blob at 80ffc000 > Booting using the fdt blob at 0x80ffc000 > Loading Kernel Image ... OK > OK > Loading Ramdisk to 7fcd3000, end 7fef024b ... OK > Loading Device Tree to 7fcce000, end 7fcd2779 ... OK > > Starting kernel ... > > Uncompressing Linux... done, booting the kernel. > Booting Linux on physical CPU 0 > Initializing cgroup subsys cpuset > Linux version 3.2.0-rc3+ (davem@e103592) (gcc version 4.5.2 (Ubuntu/Linaro > 4.5.2-8ubuntu3) ) #12 SMP Wed Nov 30 15:10:19 GMT 2011 > CPU: ARMv7 Processor [410fc091] revision 1 (ARMv7), cr=10c53c7d > CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache > Machine: ARM Versatile Express, model: V2P-CA9 > bootconsole [earlycon0] enabled > Ignoring RAM at 60000000-7fffffff (vmalloc region overlap). > Ignoring RAM at 60000000-9fffffff (vmalloc region overlap). > INITRD: 0x7fcd3000+0x0021d24b is not a memory region - disabling initrd > Memory policy: ECC disabled, Data cache writeall > Cheers > ---Dave > > > oc > > <HANG>
Yes, this is known problem with U-boot. Could you try again with "mem=512M" parameter? > If I strip the uImage and rebuild it with -a 0x60008000 -e 0x60008000 > and no other changes, that's sufficient to give me a fully booting > kernel. I can also boot a single image on v2p-ca9 both with and without > a dtb in this configuration. > > I'm using a Linaro u-Boot from a couple of releses ago; it's possible > things have changed since. > > Do you know of any specific u-Boot version which shouldn't have these > problems? > > Was the hard-coded uImage load address/entry point problem ever fixed? > (It totally defeats loading a single uImage on multiple board variants.) I simply don't use U-boot at all, what solves the problem "systematically" ;-) I wonder if it was possible to override the load/entry address in the runtime? Cheers! Paweł _______________________________________________ devicetree-discuss mailing list [email protected] https://lists.ozlabs.org/listinfo/devicetree-discuss
