Hi,
Thanks a lot for working on getting ODROID support upstream in uboot. I'm testing with v4 of your patches on uboot 2014.07 and ODROID-U2.
I'd like to understand the SPL/BL2 situation a bit better. README.odroid says that we should use the blob from hardkernel. However, as far as I can see, this blob is generated by taking the first 14kb of hardkernel's u-boot.bin from 2012 and signing it.
So, the suggestion of using hardkernel's bl2 (which I am following) seems odd. That means we run some early code from hardkernel's 2012 uboot and then magically jump into uboot-2014.07? That sounds fragile, unless this magic 14kb division is somehow represented in the output uboot binary too?
I'm also curious that these patches run the SoC at 1000MHz. Isn't the SoC on these boards clocked at 1.7GHz? Does this 1000MHz carry over into Linux once booted, or does Linux re-clock it at a faster speed?
Onto the testing - uboot loads and detects my u2 as a u3 (good). Booting into Linux, works but not quite - loads of memory corruption is detected during early boot.
Easiest way to reproduce this is to take linux-next from today, then: # make exynos_defconfig
Now enable CONFIG_DEBUG_PAGEALLOC and CONFIG_BLK_DEV_DRBD. Boot with exynos4412-odroidu3.dtb from the same kernel tree. During boot this happens:
13800000.serial: ttySAC0 at MMIO 0x13800000 (irq = 84, base_baud = 0) is a S3C6400/10 13810000.serial: ttySAC1 at MMIO 0x13810000 (irq = 85, base_baud = 0) is a S3C6400/10 console [ttySAC1] enabled brd: module loaded loop: module loaded pagealloc: memory corruption ffc10000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ ffc10010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <<snip long memory dump>> CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.16.0-rc5-next-20140716-dirty #310 [<c0013f14>] (unwind_backtrace) from [<c00111f8>] (show_stack+0x10/0x14) [<c00111f8>] (show_stack) from [<c043c938>] (dump_stack+0x80/0xc0) [<c043c938>] (dump_stack) from [<c00b5314>] (kernel_map_pages+0x18c/0x1a0) [<c00b5314>] (kernel_map_pages) from [<c0086134>] (get_page_from_freelist.isra.73+0x27c/0x5d0) [<c0086134>] (get_page_from_freelist.isra.73) from [<c0086f8c>] (__alloc_pages_nodemask+0x128/0x978) [<c0086f8c>] (__alloc_pages_nodemask) from [<c05f1c28>] (drbd_init+0x278/0x418) [<c05f1c28>] (drbd_init) from [<c00088b0>] (do_one_initcall+0x8c/0x1c4)
I don't think this is a DRBD problem because: - same kernel binary works on hardkernel uboot - with my actual product kernel, with DRBD disabled, I still get a load of memory corruption during early boot coming from other areas
Any ideas? Can you reproduce?
Thanks! Daniel