Migration from dylan to daisy (and dizzy)

Migration from dylan to daisy (and dizzy)

[Laszlo Papp]

Dear OpenEmbedded Community,

I have been trying to migrate over from dylan to daisy (and dizzy,
fwiw), but my own kernel would not boot. It used to work just fine
with dylen. It is kernel 3.2 with our BSP changes on top of it, which
are unfortunately not upstream. Either way, dylan was using 4.7 and I
tried to build the kernel with gcc 4.8 from daisy and gcc 4.9 from
dizzy.

I suspect that it is a toolchain and/or kernel issue, definitely not
Yocto as I can reproduce this with some Linaro binaries for arm
gnueabi. Still, I hope that some may have some ideas while working in
scenarios like this?

Jtag with openocd and gdb shows the following backtrace, where
foo_map_io comes from our board description. As you can see it is
fundamentally broken as it gets stuck at the early register access,
even before printk could be used! I tried using early_prink by
enabling debug_ll, but it did not work out for me. Like I wrote, this
is a really early stage of the booting process.

Has anyone experienced similar issues? I would like to update our
Yocto, but it is becoming very difficult as I do not possess the
corresponding gcc and linux expertise, unfortunately. :(

Thank you in advance!

    (gdb) bt
    #0  0xc0016f40 in davinci_psc_config ()
    #1  0xc00164b8 in __clk_enable ()
    #2  0xc00165cc in clk_enable ()
    #3  0xc03aa8b0 in davinci_clk_init ()
    #4  0xc03ab2ec in davinci_common_init ()
    #5  0xc03ab52c in da850_init ()
    #6  0xc03ac360 in foo_map_io ()
    #7  0xc03aa2d4 in paging_init ()
    #8  0xc03a8640 in setup_arch ()
    #9  0xc03a6590 in start_kernel ()
    #10 0xc0008040 in stext ()
    (gdb)

Ys, L.

Re: Migration from dylan to daisy (and dizzy)

[Gary Thomas]

On 2015-04-29 12:17, Laszlo Papp wrote:
> Dear OpenEmbedded Community,
>
> I have been trying to migrate over from dylan to daisy (and dizzy,
> fwiw), but my own kernel would not boot. It used to work just fine
> with dylen. It is kernel 3.2 with our BSP changes on top of it, which
> are unfortunately not upstream. Either way, dylan was using 4.7 and I
> tried to build the kernel with gcc 4.8 from daisy and gcc 4.9 from
> dizzy.
>
> I suspect that it is a toolchain and/or kernel issue, definitely not
> Yocto as I can reproduce this with some Linaro binaries for arm
> gnueabi. Still, I hope that some may have some ideas while working in
> scenarios like this?
>

You may need a couple of patches to the Linux kernel to use GCC > 4.7.1
   From 455bd4c430b0c0a361f38e8658a0d6cb469942b5 Mon Sep 17 00:00:00 2001
   From: Ivan Djelic <ivan.djelic@parrot.com>
   Date: Wed, 6 Mar 2013 20:09:27 +0100
   Subject: [PATCH] ARM: 7668/1: fix memset-related crashes caused by recent GCC (4.7.2) optimizations

   From 418df63adac56841ef6b0f1fcf435bc64d4ed177 Mon Sep 17 00:00:00 2001
   From: Nicolas Pitre <nicolas.pitre@linaro.org>
   Date: Tue, 12 Mar 2013 13:00:42 +0100
   Subject: [PATCH] ARM: 7670/1: fix the memset fix

> Jtag with openocd and gdb shows the following backtrace, where
> foo_map_io comes from our board description. As you can see it is
> fundamentally broken as it gets stuck at the early register access,
> even before printk could be used! I tried using early_prink by
> enabling debug_ll, but it did not work out for me. Like I wrote, this
> is a really early stage of the booting process.
>
> Has anyone experienced similar issues? I would like to update our
> Yocto, but it is becoming very difficult as I do not possess the
> corresponding gcc and linux expertise, unfortunately. :(
>
> Thank you in advance!
>
>      (gdb) bt
>      #0  0xc0016f40 in davinci_psc_config ()
>      #1  0xc00164b8 in __clk_enable ()
>      #2  0xc00165cc in clk_enable ()
>      #3  0xc03aa8b0 in davinci_clk_init ()
>      #4  0xc03ab2ec in davinci_common_init ()
>      #5  0xc03ab52c in da850_init ()
>      #6  0xc03ac360 in foo_map_io ()
>      #7  0xc03aa2d4 in paging_init ()
>      #8  0xc03a8640 in setup_arch ()
>      #9  0xc03a6590 in start_kernel ()
>      #10 0xc0008040 in stext ()
>      (gdb)
>
> Ys, L.
>

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------