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

Wed Dec 10 23:17:55 CET 2014

On Tue, 2014-12-09 at 17:45 -0700, Simon Glass wrote:
> 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.

I'm not sure what you meant by board_f/r.c as that file doesn't seem to
exist.  I whacked '#define DEBUG' in da850evm.h and got a wealth of
output.  However, the only new bit of information I've gleaned is that
the lower that the reloc address goes, the faster things die.  It goes
lower in -rc3 (0xc3f7f000), and it doesn't make it to the prompt on a
reset after saving the environment.  Likewise with '#define DEBUG';
after saving the environment it doesn't get back to the prompt on the
next reset.  All the addresses printed seem reasonable.

The only thing that doesn't look right is that the command function
pointers all look to be pre-reloc addresses.  Though I don't see how
this change would cause a failure that wouldn't happen already.

So it seems that _something_ is being overwritten by the environment
load, but I'm yet to get an idea of what.

-- 
Peter Howard <pjh at northern-ridge.com.au>