[OpenWrt-Devel] [PATCH] build: add mkrasimage

Christian Lamparter chunkeey at gmail.com
Fri Aug 17 15:04:32 EDT 2018


On Thursday, August 16, 2018 12:31:38 PM CEST David Bauer wrote:
> On 8/16/18 3:12 AM, Karl Palsson wrote:
> > 1) how bad are the portability issues that you felt
> > reimplementing in _C_ was the best path? 2) if it's that bad, why
> > keep it? How will future people knwo what to use. Either get rid
> > of it, or fix it.
> 
> Regarding 1)
> The portability issue seems to be affecting older bash versions.
> Christian described and also fixed the issue in the forums [1]. I'm not
> sure about what systems correctly are affected (definitely older MacOS X
> and the OS of the buildbots).
Oh, that "MacOS X" there was meant that I used a iBook G4 (BigEndian PowerPC)
with MacOS X 10.5.8 to test and fix the portability of the make-ras.sh script.
I also tested it on the ZyXEL NBG6617 itself running the busybox sh: If someone
wants to look, here's the program from back in the day.
<https://github.com/chunkeey/LEDE-IPQ40XX/blob/staging/target/linux/ipq40xx/image/make-ras.sh>

> The C implementation originated from when i worked on the device before
> finding Christians tree. Honestly i also think the readability of the
> current script is not really that great but honestly i don't think we
> can substantially improve that.
I wrote the bash version because of issues in the past with C implementations
of firmware packers for the Meraki routers (mkmerakifw.c and mkmerakifw-old.c).
The issue there was that the main dev was coming from a sysadmin background
and as with many OpenWrt users he had problems with C (endiannes!).

As for what implementation is better. Why not let Karl Palsson (or any
other commentor that wants to join ;) ) decide?

The "magic" that needs to be done to create the ras.bin images is as follow:

1. They start with an 2KiB header (later aligned to 64KiB) that starts with
#   4 bytes:  checksum of the rootfs image (System V checksum - big endian)
#   4 bytes:  length of the contained rootfs image file (big endian)
#  32 bytes:  Firmware Version string (NUL terminated, 0xff padded)
#   4 bytes:  checksum over the header partition (System V checksum - big e.)
#  32 bytes:  Model (e.g. "NBG6617", NUL termiated, 0xff padded)
#   4 bytes:  checksum of the kernel partition (System V checksum - big e.)
#   4 bytes:  length of the contained kernel image file (big endian)
#      rest:  0xff padding
#
# The checksum for the header is calculated over the first 2048 bytes with
# the rootfs image checksum as the placeholder during calculation.

2. followed by the rootfs image

3. followed by the kernel image

4. Done (pack it all in one big file)

Note: The NBG6617 isn't the only device from ZyXEL that utilize the ras image.
In fact, the "original" version of the notes above was written by Benjamin Berg
and can still be found as a rather long comment in the NBG6616 image generation
code under /target/linux/ar71xx/image/generic.mk [0]. (And there is at least
one more device that can make use of ras: the NBG6817). 

So chances are, there that whatever "wins" will need to be updated to support
those routers as well.

Regards,
Christian

[0] <https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ar71xx/image/generic.mk;h=3b320814c5ab091c8c8ac8ff91c40e18df446f44;hb=HEAD#l1069>




_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel



More information about the openwrt-devel mailing list