U-Boot version issue
adam at os.inf.tu-dresden.de
Fri Oct 16 00:22:50 CEST 2015
On Tue Oct 13, 2015 at 16:52:16 +0200, ba_f wrote:
> Am 2015-10-12 00:01, schrieb Adam Lackorzynski:
> >On Wed Oct 07, 2015 at 18:59:17 +0200, ba_f wrote:
> >>i have an issue with different U-Boot versions, and i have no clue
> >>the problem.
> >>Maybe someone's got an idea?
> >>Working on Xilinx' ARM Platform i use U-Boot version
> >>u-boot-xlnx-xilinx-v14.6.01, and it's all good with that one and lower
> >>But, using u-boot-xlnx-xilinx-v14.7 or higher results in serious CPU
> >>uboot> fatload mmc 0 0x00ffffc0 bootstrap.uimage
> >>reading bootstrap.uimage
> >>6139968 bytes read in 528 ms (11.1 MiB/s)
> >>uboot> go 0x01000000
> >>## Starting application at 0x01000000 ...
> >>undefined instruction
> >>pc : [<01000004>] lr : [<3ff74bc0>]
> >>sp : 3fb51e08 ip : 00002802 fp : 00000000
> >>r10: 3fb572d8 r9 : 00000002 r8 : 3fb51f40
> >>r7 : 3ffaff50 r6 : 01000000 r5 : 3fb572dc r4 : 00000002
> >>r3 : 01000000 r2 : 3fb572dc r1 : 3fb572dc r0 : 00000001
> >>Flags: nZCv IRQs off FIQs off Mode SVC_32
> >>Resetting CPU ...
> >>Unfortunately, the DIFF between v14.6 and v14.7 is 60'000 lines...
> >>Is there any chance to fix that?
> >The pc where it traps is (shall be) a NOP and definitely not an
> >undefined instruction. You could check after the fatload whether the
> >contents in memory (via md in u-boot) and in the binary are the same at
> >that location (0x01000004).
> The newer u-boot got dcache support for certain ARMs.
> So, i have to do 'u-boot> dcache off' to make it run successful.
Interesting, and thanks for the info.
Given that it seems to reject the second instruction in bootstrap it
looks like the icache is stale. Could you try an 'icache flush' and see
if that works too?
Adam adam at os.inf.tu-dresden.de
More information about the l4-hackers