[PATCH 1/2] realtek: Add generic zyxel_gs1900 image definition

[Hauke Mehrtens]

On 2/25/21 6:10 PM, Bjørn Mork wrote:
> Stefan Lippers-Hollmann <s.l-h at gmx.de> writes:
>> On 2021-02-24, Hauke Mehrtens wrote:
>>> Add a new common device definition for the Zyxel GS1900 line of
>>> switches.
>> [...]
>>> -define Device/zyxel_gs1900-10hp
>>> +define Device/zyxel_gs1900
>>>     SOC := rtl8380
>>>     IMAGE_SIZE := 6976k
>>>     DEVICE_VENDOR := ZyXEL
>>>     DEVICE_MODEL := GS1900-10HP
>>>     UIMAGE_MAGIC := 0x83800000
>>> +  KERNEL_INITRAMFS := kernel-bin | append-dtb | gzip | zyxel-vers AAHI | uImage gzip
>>> +endef
>>
>> I'm wondering if this attempt to deal the gs1900 switch family really
>> improves the situation for these devices. While IMAGE_SIZE and
>> UIMAGE_MAGIC might indeed by rather generic to most (all?) members of
>> the gs1900 family, SOC might not be (GS1900-24, GS1900-24E, GS1900-24HP
>> are RTL8382M, GS1900-48 and GS1900-48HP are RTL8393 - admittedly, I do
>> not know how different the resulting DTS would need to be, as these
>> devices are not supported yet) and zyxel-vers is different for every
>> single model (aside from GS1900-8HPv1 && GS1900-8HPv2):
>>
>> GS1900-8:	AAHH
>> GS1900-8HPv1:	AAHI
>> GS1900-8HPv2:	AAHI
>> GS1900-10HP:	AAZI
>> GS1900-16:	AAHJ
>> GS1900-24:	AAHL
>> GS1900-24E:	AAHK
>> GS1900-24EP:	ABTO
>> GS1900-24HP:	AAHM
>> GS1900-24HPv2:	ABTP
>> GS1900-48:	AAHN
>> GS1900-48HP:	AAHO
>> GS1900-48HPv2:	ABTQ
>>
>> Most of these should be supportable by OpenWrt.
> 
> Note that it is techincally possibly to build images which support more
> than one "zyxel-vers", or even all of them, That's what the stock
> firmware does.
> 
> The only reason I opted for one specific "zyxel-vers" per device is that
> we use a device specific DTS.  Having a matching "zyxel-vers" prevents
> flashing the wrong OpenWrt image from stock.


I used the wrong AAHI magic and it was possible to falsh the image over 
the Web UI, buit the image did not boot, it was unable to find the root 
fs for me.

Where is this check done?

I was unable to extract the original firmware with binwalk which would 
be nice to get some more information about how it is structured.

Hauke
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x93DD20630910B515.asc
Type: application/pgp-keys
Size: 9895 bytes
Desc: not available
URL: <http://lists.openwrt.org/pipermail/openwrt-devel/attachments/20210227/b9138043/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openwrt.org/pipermail/openwrt-devel/attachments/20210227/b9138043/attachment.sig>