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,