[PATCH 1/2] firmware-utils: zytrx: Add support for ZyXEL LTE3301-Plus

[Bjørn Mork]

Andre Valentin <avalentin at marcant.net> writes:
> Am 15.05.21 um 12:00 schrieb Bjørn Mork:
>
>> 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.

Yes.  I do have an LTE5398 flashed with LTE7490 firmware and it is almost
identical to the NR7101.  I'll change the zytrx tool when adding support
for that. And I just got a Coverity report pointing out some bad error
handling.  Will fix that too.

But I'll wait until your patches go in so you don't have to rebase.

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

>From what I could tell on the NR7101, the only difference in validation
was related to the ZyXEL version string.  And that seemed almost
unintentional: My first attempts with a free form string made the web
update tool go into an infinite loop after loading the image.  That's
why I made the initramfs version string slighly different.  But it's
still far from the original so it could cause problems..

There wasn't any other differences in the validation between stock and
bootloader.  In particular, neither verifies the strange "kernelChksum"
field. It's just reported by the bootloader.  I still have no idea how
to compute it.  Could not make any reasonable checksum match the samples
I have.  Not that another checksum would be reasonable at all - there
are too many as it is:-)

Just wondering: Did your stock firmware also come with that DebugFlag
lock-down thing?  Seems quite risky to me.  Definitely not something we
can have along with a writable rootfs.


Bjørn