[U-Boot] uboot/odroid test report

[Daniel Drake]

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