[U-Boot] Problem converting da850evm to generic board and use libfdt
Peter Howard
pjh at northern-ridge.com.au
Tue Dec 2 22:59:10 CET 2014
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?
--
Peter Howard <pjh at northern-ridge.com.au>
More information about the U-Boot
mailing list