[U-Boot] Problem converting da850evm to generic board and use libfdt

Wed Dec 10 01:45:25 CET 2014

Hi Peter,

On 9 December 2014 at 17:13, Peter Howard <pjh at northern-ridge.com.au> wrote:
>
> On Wed, 2014-12-03 at 14:20 -0800, Simon Glass wrote:
> > Hi Peter,
> >
> > On 3 December 2014 at 13:53, Peter Howard <pjh at northern-ridge.com.au> wrote:
> > > On Wed, 2014-12-03 at 06:38 -0700, Simon Glass wrote:
> > >> Hi Peter,
> > >>
> > >> On 2 December 2014 at 14:59, Peter Howard <pjh at northern-ridge.com.au> wrote:
> > >> >
> > >> > I'm trying to make two changes to building u-boot for the da850evm.
> > >> >       * Use the generic board code to get rid of the warning, and
> > >> >       * Enable libfdt to allow booting of linux with a standalone dtb
> > >> >         image.
> > >> >
> > >> > The first part appears to be simple.  Just adding
> > >> >
> > >> >         #define CONFIG_SYS_GENERIC_BOARD
> > >> >
> > >> > in include/configs/da850evm.h works with no obvious side-effects.
> > >> >
> > >> > However, adding
> > >> >
> > >> >         #define CONFIG_OF_LIBFDT
> > >> >
> > >> > is a different story.  It appears to introduce memory corruption when
> > >> > loading the environment.  On first boot it gives the "bad CRC!" warning
> > >> > and uses the default environment.  If you *don't* save the environment
> > >> > you can boot fine (including manual editing of the environment). However
> > >> > if you save the environment via saveenv bad things happen on the next
> > >> > boot.  An example log:
> > >> >
> > >> > U-Boot SPL 2015.01-rc1 (Nov 27 2014 - 14:30:26)
> > >> >
> > >> >
> > >> > U-Boot 2015.01-rc1 (Nov 27 2014 - 14:30:26)
> > >> >
> > >> > I2C:   ready
> > >> > DRAM:  64 MiB
> > >> > WARNING: Caches not enabled
> > >> > MMC:   davinci: 0
> > >> > SF: Detected M25P64 with page size 256 Bytes, erase size 64 KiB, total 8 MiB
> > >> > In:    serial
> > >> > Out:   serial
> > >> > Err:   serial
> > >> > SF: Detected M25P64 with page size 256 Bytes, erase size 64 KiB, total 8 MiB
> > >> > Warning: Invalid MAC address read from SPI flash
> > >> > Net:   DaVinci-EMAC
> > >> > Error: DaVinci-EMAC address not set.
> > >> >
> > >> > U-Boot > help
> > >> > data abort
> > >> > pc : [<c108ffd8>]          lr : [<c10900b4>]
> > >> > sp : c3e5f838  ip : 00000000     fp : c3e5fda4
> > >> > r10: c10b1f28  r9 : c3e5ff08     r8 : 0000000e
> > >> > r7 : c10b22c4  r6 : c10aa2a0     r5 : 00000000  r4 : 0000001b
> > >> > r3 : c10b8f70  r2 : 00000001     r1 : c3e5f840  r0 : ffffffff
> > >> > Flags: Nzcv  IRQs off  FIQs off  Mode SVC_32
> > >> > Resetting CPU ...
> > >> >
> > >> > If I rebuild  with CONFIG_OF_LIBFDT removed again from da850evm.h the
> > >> > problem disappears.  And you can see that the saveenv worked (i.e. the
> > >> > environment is what was saved before the reboot and data abort).
> > >> >
> > >> > I've traced the problem as far as the inline version of console_puts()
> > >> > in common/console.c.  The table dispatch there and the fact that the
> > >> > problem appears only when you load the environment makes me think it's
> > >> > memory corruption.
> > >> >
> > >> > Note: if you do *not* specify CONFIG_SYS_GENERIC_BOARD you still get the
> > >> > data abort, however it takes a bit more effort to trigger (like actually
> > >> > looking at the environment :-)  )
> > >> >
> > >> > (Note: This is building against the u-boot-2015.01-rc1 tree)
> > >> >
> > >> > Suggestions?
> > >>
> > >> In case it helps, I got the same symptom (help crashes) and it was due
> > >> to BSS not being cleared. Stefan (on cc) found this problem - he said
> > >> something to do with GDT calculation or handling. However it is just a
> > >> guess and probably has nothing to do with your issue.
> > >
> > > I may be missing something, but the GDT appears to be x86-specific
> > > whereas I'm building for ARMv5.
> >
> > OK for some reason I thought this was PPC!
> >
> > Maybe you can find your pc in System.map and work out where it is
> > going wrong? Are you hitting some image size limit?
> >
> > pc : [<c108ffd8>]
>
>
> Sorry, been distracted on other stuff for a few days.
>
> First, I now understand the global descriptor a bit better.  For ARMv5
> It's stored in r9 and still looks sane.  The relevant info:
>
> (gdb) print/x *((gd_t *)$r9)
> $1 = {bd = 0xc3e5ffb0, flags = 0x183, baudrate = 0x1c200, cpu_clk = 0x0,
>   bus_clk = 0x0, pci_clk = 0x0, mem_clk = 0x0, have_console = 0x1,
>   env_addr = 0xc10a8fcc, env_valid = 0x1, ram_top = 0xc4000000,
>   relocaddr = 0xc3f80000, ram_size = 0x4000000, mon_len = 0x6ffb0,
>   irq_sp = 0xc3e5fef0, start_addr_sp = 0xc3e5fee0, reloc_off = 0x2f00000,
>   new_gd = 0xc3e5ff08, fdt_blob = 0x0, new_fdt = 0x0, fdt_size = 0x0,
>   jt = 0xc3e601c0, env_buf = {0x31, 0x31, 0x35, 0x32, 0x30, 0x30,
>     0x0 <repeats 26 times>}, cur_i2c_bus = 0x0, timebase_h = 0x0,
>   timebase_l = 0x0, arch = {timer_rate_hz = 0x16e360, tbu = 0x0,
>     tbl = 0x4cc62, lastinc = 0x0, timer_reset_value = 0x0,
>     tlb_addr = 0xc3ff0000, tlb_size = 0x4000}}
>
>
> The pc is definitely bogus.  The reloc address is 0xc3f80000 whereas
> that would be a pre-reloc address (starting at 0xc1080000).  And it's
> definitely relocated by the time of failure.  The only other bit of
> information I have right now is that adding CONFIG_OF_LIBFDT drops the
> reloc address from 0xc3f85000 to 0xc3f80000.
>
> Don't know if any of that gives additional insight.  Meanwhile I
> continue tracing.

Yes, continue tracing.

If ram_size is 0x40000000 and ram_top is 0xc4000000 then your RAM
presumably starts at 0xc0000000. Then the relocation address actually
seems reasonable to me.

I don't know why the reloc address changes when you add CONFIG_OF_LIBFDT.

You can add '#define DEBUG' at the very top of board_f/r.c to see addresses.

Regards,
Simon