[U-Boot] [PATCH v2 15/21] Refactor the bootm command to reduce code duplication

[Tom Rini]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/27/2013 03:51 PM, Simon Glass wrote:
> Hi Stefan,
> 
> On Thu, Jun 27, 2013 at 6:40 AM, Stefan Roese <sr at denx.de 
> <mailto:sr at 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 at chromium.org
> <mailto:sjg at 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 at ubuntu-2012 u-boot ((983c72f...)|BISECTING)]$ git bisect
> good 35fc84fa1ff51e15ecd3e464dac87eb105ffed30 is the first bad
> commit commit 35fc84fa1ff51e15ecd3e464dac87eb105ffed30 Author:
> Simon Glass <sjg at chromium.org <mailto:sjg at chromium.org>> Date:
> Tue Jun 11 11:14:47 2013 -0700
> 
> Refactor the bootm command to reduce code duplication
> 
> 
> I 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 at 8' configuration Trying
> 'kernel at 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 at 8' configuration Trying 'fdt at 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...

Or FIT images?  I couldn't come up with a working FIT image here
(since my DDR starts at offset 0x80000000 not 0x0 and it was dumping
to much lower than my base, despite the entry/load in the .its file),
but a simple uImage fails to work.

- -- 
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRzJudAAoJENk4IS6UOR1WZkkQALHEtAd978EYUggvCMv7mZM3
iMLXbug7qhbTQe0PsEvkuQggwrZDGUpArqe3TRrNy6GPP9wvVHDI5D0WFQ0zPb3B
42W/Sejes5DvbCcjpSyoo113PCieoVH+csXODXWOb4Dp4+xIGDckmaQVs1yoK1j4
1/ofXihmSzdw8lHRZrTYTCSk6MxCYZYqjRv5hHGn6KZIptnSb/Koh7JXTuq+zPbV
rJxpS8q7wKC43LPxLJr4VlGmUex/SoAhVbUvdt05ZU/xIiI9qXcLlI0mgPQOpGEP
Zamqk6rZ6Kq2PxLuL/J81aiE1/cHwpMvDf7T++quSRP/4rX03wfvRhj9zJQbhlwB
8vcVx6kyBYWgBqX9bQUig81ij/oVE7huaGm0lhguO4TqmT490X8JMLeefT6N7bhr
3e8QJwOB0ZrnVBhi4Q7JyKZR1xNvNU0sgFBPGsdpHNcJDbscEs2puJtSuCYxTTbw
QN7aHWOumdA1fT+OE+jj0HTO2tHh7sCGDOPpTQlnYAtSxz3yvgpJRHxJsAlbTa+l
wpxmqa2s+cKqtQfra+SMMkXU6XiGnK8cqqH7ydpHJ8+5qZNBzn4QNU2xz9E7DJA9
lH7X980h+XQP69ClWkIHpshDVlLPoi8oiwBf828LAB13zJd/MgtL1L2K4bYSS2tK
/jopfv09h/7xbUKhOi5j
=2yZU
-----END PGP SIGNATURE-----