Re: [U-Boot] uboot/odroid test report

2014-07-18 Thread 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.marc...@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 RD Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] uboot/odroid test report

2014-07-17 Thread 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:

1380.serial: ttySAC0 at MMIO 0x1380 (irq = 84, base_baud = 0)
is a S3C6400/10
1381.serial: ttySAC1 at MMIO 0x1381 (irq = 85, base_baud = 0)
is a S3C6400/10
console [ttySAC1] enabled
brd: module loaded
loop: module loaded
pagealloc: memory corruption
ffc1: 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 RD Institute Poland

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] uboot/odroid test report

2014-07-17 Thread 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:

1380.serial: ttySAC0 at MMIO 0x1380 (irq = 84, base_baud = 0)
is a S3C6400/10
1381.serial: ttySAC1 at MMIO 0x1381 (irq = 85, base_baud = 0)
is a S3C6400/10
console [ttySAC1] enabled
brd: module loaded
loop: module loaded
pagealloc: memory corruption
ffc1: 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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] uboot/odroid test report

2014-07-17 Thread Daniel Drake 
On Thu, Jul 17, 2014 at 2:00 PM, Marek Szyprowski
m.szyprow...@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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] uboot/odroid test report

2014-07-17 Thread Daniel Drake 
On Thu, Jul 17, 2014 at 2:20 PM, Daniel Drake dr...@endlessm.com wrote:
 On Thu, Jul 17, 2014 at 2:00 PM, Marek Szyprowski
 m.szyprow...@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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] uboot/odroid test report

2014-07-17 Thread Daniel Drake 
Hi,

Sorry for last blank mail.

On Thu, Jul 17, 2014 at 2:20 PM, Daniel Drake dr...@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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] uboot/odroid test report

2014-07-17 Thread Daniel Drake 
On Thu, Jul 17, 2014 at 2:38 PM, Daniel Drake dr...@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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] uboot/odroid test report

2014-07-17 Thread 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:

1380.serial: ttySAC0 at MMIO 0x1380 (irq = 84, base_baud = 0)
is a S3C6400/10
1381.serial: ttySAC1 at MMIO 0x1381 (irq = 85, base_baud = 0)
is a S3C6400/10
console [ttySAC1] enabled
brd: module loaded
loop: module loaded
pagealloc: memory corruption
ffc1: 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 RD Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] uboot/odroid test report

2014-07-17 Thread Przemyslaw Marczak 

On 07/17/2014 04:30 PM, Daniel Drake wrote:

On Thu, Jul 17, 2014 at 2:38 PM, Daniel Drake dr...@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 RD Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] uboot/odroid test report

2014-07-17 Thread 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 dr...@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 RD Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] uboot/odroid test report

2014-07-17 Thread Daniel Drake 
On Thu, Jul 17, 2014 at 3:59 PM, Przemyslaw Marczak
p.marc...@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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot