[U-Boot] uboot/odroid test report

[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

[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

[U-Boot] uboot/odroid test report

[Daniel Drake]

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

[U-Boot] uboot/odroid test report

[Daniel Drake]

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

[U-Boot] uboot/odroid test report

[Daniel Drake]

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

[U-Boot] uboot/odroid test report

[Daniel Drake]

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

[U-Boot] uboot/odroid test report

[Przemyslaw Marczak]

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,
-- 
Przemyslaw Marczak
Samsung R&D Institute Poland
Samsung Electronics
p.marczak at samsung.com

[U-Boot] uboot/odroid test report

[Przemyslaw Marczak]

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,
-- 
Przemyslaw Marczak
Samsung R&D Institute Poland
Samsung Electronics
p.marczak at samsung.com

[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

[U-Boot] uboot/odroid test report

[Daniel Drake]

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

[U-Boot] uboot/odroid test report

[Przemyslaw Marczak]

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,
-- 
Przemyslaw Marczak
Samsung R&D Institute Poland
Samsung Electronics
p.marczak at samsung.com