Hi Sascha, > Hm, yes, you said so in your mail, I misread it. Then I don't see what > could be the problem. Does bootm -v give some valuable output? here is the output of bootm -v <image> (fixed version): barebox:/ bootm -v /mnt/emmc0/boot/uImage Image Name: Linux-3.10.14.vd2 Created: 2015-08-06 10:13:02 UTC OS: Linux Architecture: ARM Type: Kernel Image Compression: uncompressed Data Size: 2929528 Bytes = 2.8 MiB Load Address: 10008000 Entry Point: 10008000 Loading U-Boot uImage '/mnt/emmc0/boot/uImage' OS image not yet relocated Passing control to ARM Linux uImage handler no initrd load address, defaulting to 0x18000000 commandline: console=ttymxc2,115200n8 Starting kernel at 0x10008000, oftree at 0x18000000... > Could it be that the device tree blob is inside the Kernels bss segment? According to System.map bss ends at offset 0x0567b04. So bss will overwrite the device-tree blob, because currently the oftree is placed at 0x103d4000. I've played with the oftree-offset a little bit, and I need at least 6MB offset from the end of the kernel image in order to get the system booting. Hubert 2016-02-23 13:04 GMT+01:00 Sascha Hauer <s.hauer@xxxxxxxxxxxxxx>: > On Tue, Feb 23, 2016 at 12:29:41PM +0100, Hubert Feurstein wrote: >> Hi Sascha, >> >> I use an *uncompressed* kernel image. So the kernel is loaded once >> without any relocation (LoadAddress == StartAddress). > > Hm, yes, you said so in your mail, I misread it. Then I don't see what > could be the problem. Does bootm -v give some valuable output? > Could it be that the device tree blob is inside the Kernels bss segment? > > Sascha > > > -- > Pengutronix e.K. | | > Industrial Linux Solutions | http://www.pengutronix.de/ | > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ barebox mailing list barebox@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
