[U-Boot] uboot/odroid test report

[Przemyslaw Marczak]

Hello Daniel,

On 07/17/2014 02:31 PM, 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.
>
Thank you for testing this.
>
> 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?
>

We can use bl1/bl2 binaries from hardkernel because those are some 
independent bootloader parts, the same like SPL in current u-boot.
Each binary has its own job to do, so:
- BL1 - is some kind of a public key - it is used by iROM
- BL2 - is a low level initialization - CPU, DRAM, and also
         tzsw and u-boot loading from eMMC/SD - it is also used by iROM

So BL1, BL2 are running in iRAM(required small size), and u-boot is 
running from a RAM.

The main reason for using existing BL1 and BL2 binaries is
that bl1 and bl2 are just working proper.
>
> 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?
>

Hardkernels u-boot also sets the CPU frequency to 1000 MHz.

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

I've tested this u-boot with tizen.org kernel on a Debian and also with 
the ubuntu14.04 LTS image with ramdisk - both works fine on odroid U3 
and X2.

Now I tested todays kernel 3.16.0-rc5-next-20140717 and it looks fine 
with the ubuntu (console).

Thanks,
-- 
Przemyslaw Marczak
Samsung R&D Institute Poland
Samsung Electronics
p.marczak at samsung.com