0

occurs here:

reading initfs.image.gz

data abort

pc : [<3ff5ae10>] lr : [<3ff7c38c>]

reloc pc : [<04024e10>] lr : [<0404638c>]

sp : 3f314a78 ip : 00000000 fp : 00000000

r10 : 000f0447 r9 : 3f315ee8 r8 : 00000030

r7 : 000018c0 r6 : 00000020 r5 : 3f314a9c r4 : 3f3164f8

r3 : 000000a0 r2 : 000f0447 r1 : f3a900e3 r0 : 89a18e56

Flags : nZCv IRQs off FIQs off Mode SVC_32

Resetting CPU ...

resetting ...

Don't really know what that the data abort error implies.

What was happening before this was Uboot is supposed to be copying the kernel image, device tree, and ramdisk into memory before calling bootm to those.

It looks like the kernel image and devicetree both were read fine, its when it gets to this 3rd thing that things go south.

After resetting, the startup goes just the same, gets to this point, and throws data abort again.

Community
  • 1
Zephyr
  • 371
  • 1
  • 5
  • 14
  • Is the boot image maybe damaged? Could you maybe try to unpack it, see [How to extract files from uImage?](http://unix.stackexchange.com/q/113827/117599) – phk Jun 28 '16 at 19:21
  • The uboot image does not seem to be damaged. I am working with 2 uramdisk.image.gz files, one of which boots properly, the other of which does not. The one that isn't working is supposed to be the same as the first ramdisk, but with a couple of added utilities and kernel modules which will be needed. So something is apparently wrong with the second ramdisk which is preventing it from being copied, but I don't know what. – Zephyr Jun 28 '16 at 19:27
  • Maybe something about the compression? – phk Jun 28 '16 at 20:00
  • maybe? But I tried recompressing it, and compared it to the one that works with "file" and they both are the same, cpio archives. – Zephyr Jun 28 '16 at 20:09
  • Of the newc type? – phk Jun 28 '16 at 20:24
  • PLease post a full log that includes the commands you're running, and since it sounds like you have a "works" and "doesn't work' case, include both. Thanks! – Tom Rini Jun 28 '16 at 21:11

0 Answers0