Open jas4711 opened 5 months ago
A few comments here:
All that said, can you let me know what the goal is for packaging the firmware into Debian?
Please let me know how you'd like to proceed, and maybe we can come up with an option that works for you and isn't difficult to support / maintain.
Just to clarify the custom compiler comment, the upstream RE effort has a wrapper around clang that does enable the upstream compiler by disabling specific passes and has more details. Something like this could be done, but... I'd still want to validate the specific compiler version.
(note that it also is could be possible to emulate the missing instructions, which might be another good alternative)
Thanks for followup! A wrapper script like that seems like a good approach. My only goal is to package this in Debian so that it gets built using the Debian build infrastructure and can take advantage of all QA related efforts that go into Debian. If it doesn't result in the exact same hash as you get, there is good reason to debug that -- and I agree that the build should compare hash value and fail on mismatches. I have some Talos II machines to test things on.
As you may guess, this is not a serious problem -- but just cleaning up the build process and get continuous testing of the build via Debian. I worry that in 10 years reproducing the same binary we get today will no longer be that easy.
Hi. Thanks for this project. To allow easier rebuilding of the firmware blob, it would be nice if it was possible to compile it using some mainline compiler. My goal is to offer a Debian package that rebuilds the blob (without including a patched llvm in the bcm5719 firmware source package). Is this likely to ever be possible?