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


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