[U-Boot] uboot/odroid test report

[Marek Szyprowski]

Hello Daniel,

On 2014-07-17 14:31, Daniel Drake wrote:
> 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?

Frankly right now I'm using the bl1, bl2 and secure firmware which came
on eMMC together with my Odroid (I've just replaced uboot with fastload
flasher). We will check if binaries differ from those linked by
Przemyslaw.

> 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?

Linux will reclock to higher clocks once cpufreq module is activated,
however right now cpufreq is not aware of 1.7GHz, so it will clock up
to 1.4 (like older Exynos4 SoCs).

> 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?

The only idea I have is that V4 of uboot patches reported whole 2GiB of 
memory,
while the last 1MiB is not really accessible. Although I've fixed total 
memory in
DTS files, but similar fixes are needed in ATAGS passed from uboot to 
kernel.

Przemyslaw will send updated v5 patches soon.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland