[PATCH 1/2] firmware-utils: zytrx: Add support for ZyXEL LTE3301-Plus
Andre Valentin
avalentin at marcant.net
Mon May 17 01:55:06 PDT 2021
Am 15.05.21 um 12:00 schrieb Bjørn Mork:
> André Valentin <avalentin at marcant.net> writes:
>
>> This adds a new device id to the image tools.
>>
>> Signed-off-by: André Valentin <avalentin at marcant.net>
>> ---
>> tools/firmware-utils/src/zytrx.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/tools/firmware-utils/src/zytrx.c b/tools/firmware-utils/src/zytrx.c
>> index 302efc6010..b3bbbe3c69 100644
>> --- a/tools/firmware-utils/src/zytrx.c
>> +++ b/tools/firmware-utils/src/zytrx.c
>> @@ -96,6 +96,7 @@ static struct board_t {
>> uint32_t modelid;
>> } boards[] = {
>> { "MT7621A", "NR7101", 0x07010001 },
>> + { "MT7621A", "LTE3301-PLUS", 0x03030001 },
>> {}
>> };
>
>
> Great!
>
> But I winder if my initial implementation was a bit on the stupid
> side. We might want to move those two fields out of the code and just
> provide them directly as input parameters instead of this indirect
> mapping. What do you think?
It think we should move it outside. I expect ZyXEL to produce more of this stuff.
>
> Anyway, good to know that the remaining fields are constant. In
> particular the magic code "3 6035 122 0\n". This was identical in your
> stock firmware image? I wonder what it means...
It is. But a real test with a transition from original firmware has to be done yet. Verified is replacement with update via bootloader.
>
> As you might have noticed, I guessed a lot when writing this tool :-)But the right guess :-) Thank you for your effort in this.
>
> I got the GPL source drop for the NR7101 from ZyXEL a while later. But
> that didn't help much as the image header tool was provided only as
> binary. Pretty much expected, and nothing to complain about. They are
> still among the best by providing code that will build a complete
> working image, and including source for all the GPL parts AFAICS.
Yes, that's the reason why we use ZyXEL devices. The always provide full source, but with a locked image builder binary.
That's why I could release this so quick after your commit. I just waited for someone able to implement the image builder.
Kind regards,
André
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openwrt.org/pipermail/openwrt-devel/attachments/20210517/062560a3/attachment.sig>
More information about the openwrt-devel
mailing list