[PATCH] realtek: fix ZyXEL initramfs image generation

[Bjørn Mork]

Sander Vanheule <sander at svanheule.net> writes:

> 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.

This is so strange.  I just went through my notes from the experiments
on my first GS1900-10HP, and they confirmed what I suspected: I did
upgrade the OEM firmware on it to V2.60(AAZI.2) before trying to load
OpenWrt via the web GUI.

My first attempt installing an OpenWrt image from the V2.60(AAZI.2) GUI
failed with the message

 "Device only can support firmware from V2.10(AAZI.0) and later version"

I guess ZyXEL could have intentionally relaxed this between V2.60(*.2)
and V2.60(*.4), but I really don't see any good reason for them to do
that...

Note in particular the minimum OEM version requirement.  This is
hardware specific value coded into their turnkey/install/board_conf.ko
module.  AFAICS, this is required to prevent anyone from trying to
install an older image on new hardware, since they use unified images
for this family and have added some models later.

Another more likely explanation could be that the OEM GUI doesn't care
about the version trailer on hardware where the minimum version is
V1.00(*.0).  To ZyXEL, this means that any firmware is acceptable on
that hardware.  So it would make some sense to just allow anything
regardless of trailer.

This would explain why you see that on the GS1900-8 since board_conf.ko
lists it as (simply using strings to "analyze" the hardware table in the
binary): 

 GS1900-8
 RTL8380M
 V1.00(AAHH.0)
 V2.60(AAHH.2)

(The last version number is 2.60.2 because this is a binary from that
release).

If this theory is correct, then any of the following hardware might work
without a valid trailer:

model        hwver  mim OEM ver
GS1900-8     V1.0   V1.00(AAHH.0)
GS1900-8HP   V1.0   V1.00(AAHI.0)
GS1900-16    V1.0   V1.00(AAHJ.0)
GS1900-24E   V1.0   V1.00(AAHK.0)
GS1900-24    V1.0   V1.00(AAHL.0)
GS1900-24HP  V1.0   V1.00(AAHM.0)
GS1900-48    V1.0   V1.00(AAHN.0)
GS1900-48HP  V1.0   V1.00(AAHO.0)

But these, and any newer models, would require a matching trailer:

model        hwver    mim OEM ver
GS1900-8HP   V2.0   V2.10(AAHI.0)
GS1900-10HP  V1.0   V2.10(AAZI.0)
GS1900-24EP  V1.0   V2.60(ABTO.0)
GS1900-24HP  V2.0   V2.60(ABTP.0)
GS1900-48HP  V2.0   V2.60(ABTQ.0)

One very interesting candidate for testing is the GS1900-8HP, which uses
the same four-letter code for both hardware revisions but with different
minimum firmware versions.

A final question: Did you try to install an image *without* any trailer
at all? I was hoping we could use the trailer to prevent users from
trying to flash a sysupgrade image from OEM.  That would still work if
the OEM firmware requires some trailer.

> 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>

Thanks.

>>  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.

We could do that, but I don't think that sort of failsafe coding is
common in our image make rules.  They are not intended for end users
anyway.  If you add a new device, then you're supposed to know what you
do.

Let's see of we can get this fix in there first so that OpenWrt becomes
installable again on the supposedly supported devices.



Bjørn