All of lore.kernel.org
 help / color / mirror / Atom feed
* [U-Boot] iminfo and zImages
@ 2018-03-12 14:03 Andy Rea
  2018-03-12 14:59 ` Tom Rini
  2018-03-18 19:35 ` Wolfgang Denk
  0 siblings, 2 replies; 3+ messages in thread
From: Andy Rea @ 2018-03-12 14:03 UTC (permalink / raw)
  To: u-boot

Is it just not possible for the zImages in RAM to be decoded as per the
uImages ?

 

If I simply use mkimage to convert the image back as a uImage ( essentially
take off the first 64 bytes ? ) then iminfo will display the kernel info

 

The uImage file is only 64 bytes smaller so hasn't fundamentally been
uncompressed but also offsetting the iminfo by the 64 bytes makes no odds
either

 

Did I miss the point somewhere?!

 

 

 

 

=> tftp 82000000 uImage

done

Bytes transferred = 7954944 (796200 hex)

=> iminfo

 

## Checking Image at 82000000 ...

   Legacy image found

   Image Name:   Linux kernel

   Image Type:   ARM Linux Kernel Image (uncompressed)

   Data Size:    7954880 Bytes = 7.6 MiB

   Load Address: 82000000

   Entry Point:  82000000

   Verifying Checksum ... OK

 

=> tftp 82000000 zImage

done

Bytes transferred = 7954880 (7961c0 hex)

## Checking Image at 82000000 ...

Unknown image format!

=> iminfo 82000040

 

## Checking Image at 82000040 ...

Unknown image format!

=>

 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5546 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180312/cd716185/attachment.bin>

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [U-Boot] iminfo and zImages
  2018-03-12 14:03 [U-Boot] iminfo and zImages Andy Rea
@ 2018-03-12 14:59 ` Tom Rini
  2018-03-18 19:35 ` Wolfgang Denk
  1 sibling, 0 replies; 3+ messages in thread
From: Tom Rini @ 2018-03-12 14:59 UTC (permalink / raw)
  To: u-boot

On Mon, Mar 12, 2018 at 02:03:54PM +0000, Andy Rea wrote:

> Is it just not possible for the zImages in RAM to be decoded as per the
> uImages ?

Well, in short, "patches welcome".  Part of the problem is that the
Linux Kernel ARM zImage doesn't contain a ton of info.  That's less true
of say the aarch64 Image format.  And both of these are architecture
specific.  If you can come up with a patch that does something useful
for iminfo for zImage, I don't see a problem in theory with that.
Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180312/96167900/attachment.sig>

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [U-Boot] iminfo and zImages
  2018-03-12 14:03 [U-Boot] iminfo and zImages Andy Rea
  2018-03-12 14:59 ` Tom Rini
@ 2018-03-18 19:35 ` Wolfgang Denk
  1 sibling, 0 replies; 3+ messages in thread
From: Wolfgang Denk @ 2018-03-18 19:35 UTC (permalink / raw)
  To: u-boot

Dear Andy,

In message <MM1P123MB126008DA9E9DF7F8F08BB81EB2D30@MM1P123MB1260.GBRP123.PROD.OUTLOOK.COM> you wrote:
> 
> Is it just not possible for the zImages in RAM to be decoded as per the
> uImages ?

You can decode only the information that is in there.  uImage adds
an extra 64 byte header with informnation I considered useful to
have, like names, timestamp, checksum.

> If I simply use mkimage to convert the image back as a uImage ( essentially
> take off the first 64 bytes ? ) then iminfo will display the kernel info

You confuse things here.  mkimage _adds_ a 64 byte header to create
the uImage file from zImage (or similar).  iminfo displays this
uImage header.  Similar when using FIT images.

> The uImage file is only 64 bytes smaller so hasn't fundamentally been
> uncompressed but also offsetting the iminfo by the 64 bytes makes no odds
> either

Wrong, uImage has 64 bytes header _added_ - and all this has
nothing to do with compression at all.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
panic: kernel trap (ignored)

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2018-03-18 19:35 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-03-12 14:03 [U-Boot] iminfo and zImages Andy Rea
2018-03-12 14:59 ` Tom Rini
2018-03-18 19:35 ` Wolfgang Denk

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.