[PATCH] realtek: fix ZyXEL initramfs image generation

[Sander Vanheule]

Hi Bjørn,

On Thu, 2021-06-24 at 23:04 +0200, Bjørn Mork wrote:
> The current rule produces empty trailers, causing the OEM firmware
> update application to reject our images.
> 
> The double expansion of a makefile variable does not work inside
> shell code.  The second round is interpreted as a shell expansion,
> attempting to run the command ZYXEL_VERS instead of expanding the
> $(ZYXEL_VERS) makefile variable.
> 
> Fix by removing one level of variable indirection.
> 
> Fixes: c6c8d597e183 ("realtek: Add generic zyxel_gs1900 image definition")
> Signed-off-by: Bjørn Mork <bjorn at mork.no>
> ---
> I got myself another brand new GS1900-10HP and used the opportunity to
> verify the console-less installation procedure.  And of course, it didn't
> work....

I wanted to verify that your patch fixes OpenWrt flashing, but V2.60(AAHH.4) on my
GS1900-8 actually accepts images with bogus trailers. That being said, an image
produced with your patch applied, thus a correct trailer, can also be flashed and the
trailer is recognized by the stock firmware.

So I guess I can already provide this:
 
Tested-by: Sander Vanheule <sander at svanheule.net>

I also have one small question below.

> The reason is that we currently build images with a bogus trailer,
> lacking the crucial hardware version info the OEM firmware looks
> for.
> 
> This needs to be backported yto 21.02 as well.  I dowloaded the
> initramfs images from downloads.openwrt.org and verified that they have
> the same issue:
> 
>  $ hexdump -C openwrt-21.02.0-rc3-realtek-generic-zyxel_gs1900-10hp-initramfs-
> kernel.bin |tail -4
>  005b7240  ca 0f 86 61 cc 1b 7d 0a  0b 09 45 88 fc 06 fd ac  |...a..}...E.....|
>  005b7250  f6 82 7e 5d 7d 13 5a 56  8c 14 fe 7f 55 bf 19 d4  |..~]}.ZV....U...|
>  005b7260  ea 2d d7 00 56 45 52 53  0a                       |.-..VERS.|
>  005b7269
> 
> 
> A proper image should have a trailer similar to this:
> 
>  $ hexdump -C openwrt-initramfs.bin |tail -4
>  005746d0  10 e1 d2 0c 73 0a ff 07  eb 12 c6 f1 0a eb ca 00  |....s...........|
>  005746e0  56 45 52 53 0a 56 39 2e  39 39 28 41 41 5a 49 2e  |VERS.V9.99(AAZI.|
>  005746f0  30 29 20 7c 20 30 36 2f  32 34 2f 32 30 32 31 0a  |0) | 06/24/2021.|
>  00574700
> 
> The last one is the actual image I used to my initial install from OEM.
> It worked.
> 
> 
> Bjørn
> 
>  target/linux/realtek/image/Makefile | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/target/linux/realtek/image/Makefile
> b/target/linux/realtek/image/Makefile
> index ebc0c0a78480..38b4d5e441cc 100644
> --- a/target/linux/realtek/image/Makefile
> +++ b/target/linux/realtek/image/Makefile
> @@ -10,7 +10,7 @@ DEVICE_VARS += ZYXEL_VERS
>  
>  define Build/zyxel-vers
>         ( echo VERS;\
> -       for hw in $(1); do\
> +       for hw in $(ZYXEL_VERS); do\
>                 echo -n "V9.99($$hw.0) | ";\
>                 date -d @$(SOURCE_DATE_EPOCH) +%m/%d/%Y;\
>         done ) >> $@

Would it be worthwile to make zyxel-vers fail if $(ZYXEL_VERS) is not defined/empty?
A user could still define a wrong value of course, but at least they would know to
provide something.

Best,
Sander

> @@ -117,7 +117,7 @@ define Device/zyxel_gs1900
>    IMAGE_SIZE := 6976k
>    DEVICE_VENDOR := ZyXEL
>    UIMAGE_MAGIC := 0x83800000
> -  KERNEL_INITRAMFS := kernel-bin | append-dtb | gzip | zyxel-vers $$$$(ZYXEL_VERS)
> | \
> +  KERNEL_INITRAMFS := kernel-bin | append-dtb | gzip | zyxel-vers | \
>         uImage gzip
>  endef
>