Omega2+ reproducible builds
-
Hi,
I have a project where I need to understand how the firmware build system works. So, the first task I took was to reproduce the firmware provided by Onion before I can go around modifying it.
I cloned the sources from https://github.com/OnionIoT/source, switched branch to lede-17.04, created a docker container and inside that docker container ran "make" command.
The problem is that wifi is not working on that build. As interfaces such as apcli0 and ra0 are not present, even wifisetup is unable to identify any wifi networks.
And of course, I haven't changed any configuration and didn't run "make menuconfig". So, that's out of question.Am I missing anything, any pointers would be appreciated?
Thank you.
-
Amen to that.
If Debian are pushing to 100% reproducible builds I think LEDE should where it can and save some binary blobs which can be checksummed should have everything easily checked.
-
@T-NT off-topic in some respects but i'd point out that you can learn a bit about onion as a company and the "vision" they have as expressed in this forum and the comments section of the new kickstarter page. anyway, i get it when they now say that they never said they were open source and that what we got as a contributor was the hardware and build "b160" and earlier. and those constituted what onion was responsible for. i'm left with the impression that onion has done everything to date that is planned and anything else would be a bonus. so yeah it would be great but i seriously doubt they will release a reproducible build package that has all pieces and works. my take of onion is they don't see that as part of the omega2 campaign at this point. they are concerned about an alarm clock radio that gets its time from the internet via wifi at a bunch of strange motel/hotel/etc wifi systems. and they probably won't try to release the new wifi driver subsystem
-
Well the main issue I have with onion builds is the keep slipping behind the LEDE tree and so you end up with mismatched kernels constantly meaning rolling in driver changes is next to impossible unless you are building the firmware yourself, which brings up back to the point about reproducible builds because if we cannot build what onion builds then how can we update it to make custom builds?
In some respects I really wish Onion would just decide to track LEDE completely and upstream any custom changes that need to be made for a particular devices. As it stands now though I am terrified to do any sort of update on my omegas because there is a high probability it will break something. Even just being able to upgrade the kernel as a package would go a long way to making building for a target easier.
-
@Douglas-Kryder said in Omega2+ reproducible builds:
"... anyway, i get it when they now say that they never said they were open source and that what we got as a contributor was the hardware and build "b160" and earlier. and those constituted what onion was responsible for. i'm left with the impression that onion has done everything to date that is planned and anything else would be a bonus. ..."While b160 is the latest working build, my concern with having to remain at b160 is that we will be unable to implement any critical security fixes into the firmware binary. The IoT landscape in general is already littered with many insecure devices that are eventually recruited into bot armies through their unpatched/unpatchable vulnerabilities and if we can't secure our O2's against future threats, I feel that we'll just be contributing to that cause.
I too would like a reproducible build that I could tweak when it becomes necessary.
-
Just curious how the open source aspect works...
If Onion is modifying open source drivers, doesn't that make those changes a derived work and therefore subject to the same open source license? And if that is the case, doesn't Onion have an obligation to make the source available if a customer requests it?
-
@Chris-Ouellette from what i read it mostly depends on the license in place on the work they modify. additionally, the new wi-fi driver if in fact it exists was supposedly a complete rewrite and thus not modified from some other code and not subject to open source. i recently read a comment by someone from onion, i think it was in the comments section of the new kickstarter campaign, that no one from onion ever said that onion was an open source company.
-
@Shreyansh-Jain, to add the WiFi drivers, I first did 'scripts/feeds update', then 'script/feeds install ralink-wifi-mt76x8', then in 'make menuconfig' select the Ralink APSoC wifi driver in Onion->Ralink, and then build.
-
@wdu And once you load the firmware into the O2/+ does the wifi work?
For my part, I can build the source successfully, but whether I compile the Ralink APSoC into the kernel, or build it as a module and insmod it into the running kernel, I can't get working wifi.
Indeed, Onion on their readme page for the github source repo say:
Due to incompatibilities with recent kernel updates, building a firmware with the Ralink APSoC WiFi SoftAP driver will cause a kernel panic during boot This can be fixed by reflashing the Omega's firmware using the Omega's Bootloader and Ethernet Expansion We are working on a new implementation of the WiFi driver, will be arriving in Q3 2017! Stay tuned!
-
@cas we have not seen that problem. WiFi seems to work as good as with Omega's original firmware.
-
@wdu That is fantastic news.
Would you be willing to post a step-by-step detailing the source download, build options selected and compilation steps so that we could try and achieve the same result?[edit]
I'm going to try a build based on a fresh clone of the source repo and incorporate what you posted previously, choosing no other build options and see if I can reproduce.
[/edit]
-
@cas sorry, time does not permit that now. I did not install extra packages or feeds apart from what I described above. On the other hand, I made quite some changes to the spi driver, dts files, ... which may or may not have an impact on the good operation of the WiFi driver.
