On 07/10/2013 20:59, Simon McVittie wrote:
Package: abootimg
Version: 0.6-1
Severity: wishlist
Tags: upstream patch
abootimg currently fills header.id (unique image ID) with zero bytes in
its output, with no way to do otherwise.
The Android mkbootimg tool uses the (raw binary) SHA-1 of various
bits of the image, zero-padded at the end, as the image's unique ID.
I am not aware of any devices that require this, but you never know.
It's an abootimg feature :)
As I've never encountered devices requesting a valid signature in this
field, to keep things simple I've never bothered to fill it.
Rockchip devices like the RK3188 have their own variant image format
in which the end of the header is also included in the SHA-1,
resulting in a different ID. These devices' bootloader *does*
verify the hash, so an ordinary mkbootimg or abootimg will not
produce a bootable kernel.
This modified mkbootimg produces that SHA1, for instance:
https://github.com/naobsd/cm_system_core/tree/ics-rockchip-naobsd/mkbootimg
I attach a rather untested patch. I'll test it on a Rockchip device
soon, but with a suitable bootimg.cfg and "--id rockchip", it does produce
the same image as the modified mkbootimg.
The patch does not include the Debian packaging bits to add a gcrypt
dependency.
It would be fine to swap gcrypt for some other GPL-compatible
crypto library (libnettle, libtomcrypt, etc.) or even a copy/pasted
SHA1 implementation if desired, but gcrypt is Priority: standard so
it seemed good enough :-)
I will consider adding support for it.
Thanks,
Gilles.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
