Hi Stefan,
I can create something with or without compression and I cannot see the failure. Tom is seeing it though. I will see if I can get another board to try. If you have any ideas please let me know.
scanning bus 0 for devices... 2 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found scanning usb for ethernet devices... 1 Ethernet Device(s) found Waiting for Ethernet connection... done. BOOTP broadcast 1 *** Unhandled DHCP Option in OFFER/ACK: 2 *** Unhandled DHCP Option in OFFER/ACK: 176 *** Unhandled DHCP Option in OFFER/ACK: 35 *** Unhandled DHCP Option in OFFER/ACK: 208 *** Unhandled DHCP Option in OFFER/ACK: 242 *** Unhandled DHCP Option in OFFER/ACK: 101 *** Unhandled DHCP Option in OFFER/ACK: 119 *** Unhandled DHCP Option in OFFER/ACK: 42 *** Unhandled DHCP Option in OFFER/ACK: 2 *** Unhandled DHCP Option in OFFER/ACK: 176 *** Unhandled DHCP Option in OFFER/ACK: 35 *** Unhandled DHCP Option in OFFER/ACK: 208 *** Unhandled DHCP Option in OFFER/ACK: 242 *** Unhandled DHCP Option in OFFER/ACK: 101 *** Unhandled DHCP Option in OFFER/ACK: 119 *** Unhandled DHCP Option in OFFER/ACK: 42 DHCP client bound to address 172.22.83.47 Using asx0 device TFTP from server 172.22.83.1; our IP address is 172.22.83.47 Filename '/var/lib/tftpboot/image.plain'. Load address: 0x40008000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ###################################### 4.4 MiB/s done Bytes transferred = 8183088 (7cdd30 hex) Using asx0 device TFTP from server 172.22.83.1; our IP address is 172.22.83.47 Filename '/var/lib/tftpboot/exynos5420-peach-pit-rev3.dtb'. Load address: 0x41000000 Loading: ### 640.6 KiB/s done Bytes transferred = 43298 (a922 hex) * kernel: cmdline image address = 0x40008000 ## Booting kernel from Legacy Image at 40008000 ... Image Name: plain Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 8183024 Bytes = 7.8 MiB Load Address: 20008000 Entry Point: 20008000 Verifying Checksum ... OK kernel data at 0x40008040, len = 0x007cdcf0 (8183024) ## Flattened Device Tree blob at 41000000 Booting using the fdt blob at 0x41000000 Loading Kernel Image ... load_buff=20008000, image_buf=40008040, image_len=7cdcf0 OK OK kernel loaded at 0x20008000, end = 0x207d5cf0 load_end = 207d5cf0 Loading Device Tree to 3ffed000, end 3ffff921 ... OK boot_kernel.c: ft_board_setup: warning: g_crossystem_data is NULL
Starting kernel ...
Regards, SImon
On Thu, Jun 27, 2013 at 12:51 PM, Simon Glass sjg@chromium.org wrote:
Hi Stefan,
On Thu, Jun 27, 2013 at 6:40 AM, Stefan Roese sr@denx.de wrote:
Hi Simon,
On 06/11/2013 08:14 PM, Simon Glass wrote:
At present the bootm code is mostly duplicated for the plain 'bootm' command and its sub-command variant. This makes the code harder to maintain and means that changes must be made to several places.
Introduce do_bootm_states() which performs selected portions of the
bootm
work, so that both plain 'bootm' and 'bootm <sub_command>' can use the same code.
Additional duplication exists in bootz, so tidy that up as well. This is not intended to change behaviour, apart from minor fixes where the previously-duplicated code missed some chunks of code.
Signed-off-by: Simon Glass sjg@chromium.org
Simon, this patch breaks bootm (at least on powerpc), while booting an compressed uImage (with DT). It just hangs while decompressing the kernel image:
## Booting kernel from Legacy Image at 01000000 ... Image Name: Linux-3.5.7 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 2203312 Bytes = 2.1 MiB Load Address: 00000000 Entry Point: 00000000 ## Flattened Device Tree blob at 01800000 Booting using the fdt blob at 0x1800000 Uncompressing Kernel Image ...
I bisected mainline and this patch is the one that breaks booting:
[stefan@ubuntu-2012 u-boot ((983c72f...)|BISECTING)]$ git bisect good 35fc84fa1ff51e15ecd3e464dac87eb105ffed30 is the first bad commit commit 35fc84fa1ff51e15ecd3e464dac87eb105ffed30 Author: Simon Glass sjg@chromium.org Date: Tue Jun 11 11:14:47 2013 -0700
Refactor the bootm command to reduce code duplicationI already looked what might be wrong but I couldn't find any problem upon a quick glance. You know this code may better. Perhaps you could take look at it and give it a try as well.
I thought I had a repro, but it turned out to be that I was using kernel_noload so it was decompressing onto itself:
Uncompressing Kernel Image (no loading done) ... LZO: uncompress or overwrite error -6 - must RESET board to recover
When I give a load address, it seems to work:
Bytes transferred = 3953092 (3c51c4 hex) ## Loading kernel from FIT Image at 40008000 ... Using 'conf@8' configuration Trying 'kernel@1' kernel subimage Description: unavailable Type: Kernel Image Compression: gzip compressed Data Start: 0x400080c8 Data Size: 3633253 Bytes = 3.5 MiB Architecture: ARM OS: Linux Load Address: 0x20008000 Entry Point: 0x20008000 Verifying Hash Integrity ... OK ## Loading fdt from FIT Image at 40008000 ... Using 'conf@8' configuration Trying 'fdt@8' fdt subimage Description: exynos5420-peach-pit-rev3.dtb Type: Flat Device Tree Compression: uncompressed Data Start: 0x403b19e0 Data Size: 43298 Bytes = 42.3 KiB Architecture: ARM Hash algo: sha1 Hash value: 097dda51183eed6948ab942c57b14581c77ea22f Verifying Hash Integrity ... sha1+ OK Booting using the fdt blob at 0x403b19e0 Uncompressing Kernel Image ... OK Loading Device Tree to 3ffed000, end 3ffff921 ... OK
So I think it might be something to do with the load address. I'm going to fall back to code inspection...
Regards, Simon