[U-Boot] uboot/odroid test report
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
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
On Thu, Jul 17, 2014 at 2:00 PM, Marek Szyprowski m.szyprowski@samsung.com wrote:
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.
They probably don't.
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.
Not sure if this would be expected even in that case, but it also reproduces with mem=256m passed as a kernel arg.
Przemyslaw will send updated v5 patches soon.
Great! Please CC me.
Thanks Daniel
On Thu, Jul 17, 2014 at 2:20 PM, Daniel Drake drake@endlessm.com wrote:
On Thu, Jul 17, 2014 at 2:00 PM, Marek Szyprowski m.szyprowski@samsung.com wrote:
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.
They probably don't.
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.
Not sure if this would be expected even in that case, but it also reproduces with mem=256m passed as a kernel arg.
Przemyslaw will send updated v5 patches soon.
Great! Please CC me.
Thanks Daniel
Hi,
Sorry for last blank mail.
On Thu, Jul 17, 2014 at 2:20 PM, Daniel Drake drake@endlessm.com wrote:
Not sure if this would be expected even in that case, but it also reproduces with mem=256m passed as a kernel arg.
With v5 there are no more corruption errors, thanks!
I'm getting some new errors though, and my initramfs fails to switch to real root, I'll get back to you with more details if this is something other than a problem this side.
Daniel
On Thu, Jul 17, 2014 at 2:38 PM, Daniel Drake drake@endlessm.com wrote:
I'm getting some new errors though, and my initramfs fails to switch to real root, I'll get back to you with more details if this is something other than a problem this side.
Silly error this side. Now things are fine. Thanks, great work!
I'm still curious to understand how this SPL/BL2 thing works, given that with our setup it is basically running the first 14kb of an old uboot version during early boot? If either of you know..
Also, I didn't manage to get the initramfs to be loaded in the v5 patch, which does:
setenv image_addr ${kerneladdr} - ${fdtaddr} bootz ${image_addr} ${ramdisk_addr}
Guessing, but I think the problem here is that we end up passing 4 args to bootz, which is not how it is documented. Instead the ramdisk addr should be passed where the - is in image_addr.
Daniel
On 07/17/2014 04:30 PM, Daniel Drake wrote:
On Thu, Jul 17, 2014 at 2:38 PM, Daniel Drake drake@endlessm.com wrote:
I'm getting some new errors though, and my initramfs fails to switch to real root, I'll get back to you with more details if this is something other than a problem this side.
Silly error this side. Now things are fine. Thanks, great work!
I'm still curious to understand how this SPL/BL2 thing works, given that with our setup it is basically running the first 14kb of an old uboot version during early boot? If either of you know..
Please look into my first reply.
Also, I didn't manage to get the initramfs to be loaded in the v5 patch, which does:
setenv image_addr ${kerneladdr} - ${fdtaddr} bootz ${image_addr} ${ramdisk_addr}
Guessing, but I think the problem here is that we end up passing 4 args to bootz, which is not how it is documented. Instead the ramdisk addr should be passed where the - is in image_addr.
Daniel
I will check it tomorrow but it has works on Ubuntu. The bootz command takes only 2 arguments here -> ${image_addr} ${ramdisk_addr} which are the numbers set by: "run check_dtb" and "run check_ramdisk"
Thank you,
Hi,
On 07/17/2014 03:38 PM, Daniel Drake wrote:
Hi,
Sorry for last blank mail.
On Thu, Jul 17, 2014 at 2:20 PM, Daniel Drake drake@endlessm.com wrote:
Not sure if this would be expected even in that case, but it also reproduces with mem=256m passed as a kernel arg.
With v5 there are no more corruption errors, thanks!
That's great.
I'm getting some new errors though, and my initramfs fails to switch to real root, I'll get back to you with more details if this is something other than a problem this side.
Daniel
As I wrote in a previous email - this was tested with Ubuntu image. Please check your ramdisk load address .
Thanks,
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,
On Thu, Jul 17, 2014 at 3:59 PM, Przemyslaw Marczak p.marczak@samsung.com wrote:
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.
Fair enough, I was just a bit worried/curious that bl2 is only working "by accident", and we have some strange mashup of 2 uboot versions involved in the boot process.
I will check it tomorrow but it has works on Ubuntu. The bootz command takes only 2 arguments here -> ${image_addr} ${ramdisk_addr} which are the numbers set by: "run check_dtb" and "run check_ramdisk"
Maybe I made a mistake in my testing then, either way I've moved onto a custom boot script now.
But just to clarify the bootz usage..
image_addr is defined as: setenv image_addr ${kerneladdr} - ${fdtaddr};
so with bootz ${image_addr} ${ramdisk_addr};
you are actually passing bootz ${kerneladdr} - ${fdtaddr} ${ramdisk_addr};
Maybe it works for you, although the documentation suggests its usage is not quite like that: static char bootz_help_text[] = "[addr [initrd[:size]] [fdt]]\n" " - boot Linux zImage stored in memory\n" "\tThe argument 'initrd' is optional and specifies the address\n" "\tof the initrd in memory. The optional argument ':size' allows\n" "\tspecifying the size of RAW initrd.\n" #if defined(CONFIG_OF_LIBFDT) "\tWhen booting a Linux kernel which requires a flat device-tree\n" "\ta third argument is required which is the address of the\n" "\tdevice-tree blob. To boot that kernel without an initrd image,\n" "\tuse a '-' for the second argument. If you do not pass a third\n" "\ta bd_info struct will be passed instead\n" #endif ""; #endif
Daniel
Hello Daniel, On 07/17/2014 05:35 PM, Daniel Drake wrote:
On Thu, Jul 17, 2014 at 3:59 PM, Przemyslaw Marczak p.marczak@samsung.com wrote:
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.
Fair enough, I was just a bit worried/curious that bl2 is only working "by accident", and we have some strange mashup of 2 uboot versions involved in the boot process.
I will check it tomorrow but it has works on Ubuntu. The bootz command takes only 2 arguments here -> ${image_addr} ${ramdisk_addr} which are the numbers set by: "run check_dtb" and "run check_ramdisk"
Maybe I made a mistake in my testing then, either way I've moved onto a custom boot script now.
But just to clarify the bootz usage..
image_addr is defined as: setenv image_addr ${kerneladdr} - ${fdtaddr};
so with bootz ${image_addr} ${ramdisk_addr};
you are actually passing bootz ${kerneladdr} - ${fdtaddr} ${ramdisk_addr};
Maybe it works for you, although the documentation suggests its usage is not quite like that: static char bootz_help_text[] = "[addr [initrd[:size]] [fdt]]\n" " - boot Linux zImage stored in memory\n" "\tThe argument 'initrd' is optional and specifies the address\n" "\tof the initrd in memory. The optional argument ':size' allows\n" "\tspecifying the size of RAW initrd.\n" #if defined(CONFIG_OF_LIBFDT) "\tWhen booting a Linux kernel which requires a flat device-tree\n" "\ta third argument is required which is the address of the\n" "\tdevice-tree blob. To boot that kernel without an initrd image,\n" "\tuse a '-' for the second argument. If you do not pass a third\n" "\ta bd_info struct will be passed instead\n" #endif ""; #endif
Daniel
You were right. I made a mistake, but even that - the ramdisk for ubuntu was loaded - because of kernel without fdt. Thank you for testing, I will fix this and send the patches again.
Regards,
participants (3)
-
Daniel Drake -
Marek Szyprowski -
Przemyslaw Marczak