It might be uboot doesn't support bzip or zip that could account for the wrong image
You could be getting an illegal instruction error if you overwrote part of uboot with the
kernel image ie the partitions won't hold the data. then you are calling for bits that
And the device tree stuff changes things too.
I ran into those issues with the pogoplugs.
I forgot the uboot commands off the top of my head but check the size of your partitions
vs the size of what you are loading. Uboot will work even if you overwrote some of the
bits if you don't call those sections of the code.
I ended up repartitoning and changing all of the memory addresses. Which is kind of a
I hope that helps a little.
Steven Falco <stevenfalco(a)gmail.com> wrote:
On 09/16/2013 07:55 PM, Jonathan Masters wrote:
If someone can capture a full backtrace then I will look. I will also
aim to reproduce myself a few more times. I am told there is a JTAG option but have not
looked further since the weekend yet.
I've tried, but I think what I've already posted is all the
backtrace I can get.
Here is the strange thing. It looks like this is happening
while still in u-boot, but it appears to be dependent on
the kernel being loaded.
I realize that that doesn't make much sense, but here are my
reasons for that conclusion.
1) One of the failure cases prints "Wrong Image Format for",
which comes from u-boot/common/cmd_bootm.c
2) If the boot sequence gets as far as printing:
Starting kernel ...
then it will always boot successfully (for me, anyway). That
message comes from u-boot/arch/arm/lib/bootm.c
3) Another failure case prints:
MAYBE you should read doc/README.arm-unaligned-accesses
That comes from u-boot/arch/arm/lib/interrupts.c
I cannot explain why the specific kernel matters, unless the
size of the kernel matters. The uImage from Tapani's tree is
around 2 MB, while the Fedora one is closer to 5 MB.
I don't know if this makes it any easier to track down, but it
is the best data I've got right now.
arm mailing list