|Status:||Closed||Start date:||03 Feb 2020|
|Category:||00 - Basic Build Issues|
|Target version:||1.1.0 - Upgrades|
|Severity:||03 - Medium|
Need to reverify all builds since it's been a while since I've done that. This is to make sure no upstream packages are missing and the build still works for the currently configured versions of Crosstool-NG, Busybox, Buildroot and RPi specific components.
RM #736: Fix mtd and evtest builds in Buildroot. Fix generation license files as well.
RM #736: Don't copy in busybox skeleton directory (during build of initramfs.gz) because there isn't one.
mtd was broken. Buildroot has a patch that fixes it.
legal-info build was broken. I fixed that within the buildroot build.
evtest is not downloading. It's not just the version but the download site is giving 400 response codes. It might be down for now. Will try again later.
- % Done changed from 10 to 20
The problem is that the URL changed by freedesktop. The new format is
This change also caused a change in the download hash. It's questionable that the hash change is correct, but for now I'm got a patch for it.
The patch worked to get evtest downloaded. The build is currently running.
It died again. w_scan's domain is no longer valid so there is no place to download it.
I can either drop w_scan from the defualt build or push w_scan to the muse archives. I think I should do both, in case I want it later but the web site never comes back.
Pushed a copy of the w_scan archive to muse site. Build got past that point and is now running again. Will disable w_scan in buildroot's config after the build completes.
Build completes but while working on another project (webcam to watch the dogs) I discovered that the latest RPi 3 Model B+ no longer uses the same firmware for the wifi. I had been using
but it now seems to want
Also, the associated .txt originally was
There is no matching .txt for the new 43455. I believe all I need to do is load the new .bin. But the real fix, to support any Raspberry Pi, is pull the whole tree from
But that adds 41M to the rootfs. And I don't even know if it's meaningful. I need to grab latest Raspbian and see what it has in it's firmware tree for brcm.
I checked Raspbian but it didn't really tell me anything. I then checked the site I was downloading the original .txt file from and found the .bin and .txt for 43455 at the same site. I'm going to test those next. If those work to get the wifi running then I'll just add them to the fw.cfg file (as with the original 43430 .txt file) and be done with it.
- % Done changed from 20 to 30
So the wifi firmware and driver act like they work but I haven't been able to get them to connect to the AP. Since I don't really care that much (and there are lots of reports of the wifi on the 3's not working very well) I'll just add the firmware to the build and call it good.
Changes for Buildroot pushed. Moving on with build test.
- % Done changed from 30 to 50
Continued build completed successfully. Cleaned build and started again.
Full build, from scratch, completed successfully.
Now I need to test the build with the PiBox Media System apps to make sure the build still works as expected. If that works, I can close this issue.
Testing with the new build failed to boot. There was no indication of what the problem is, however.
A similar problem happened with an older build that had been working. I had added some new firmware but other than that it was a working build. Both failures were with the overlay configuration. I tried the old build without overlay and it booted. More than once the usb hub I placed the SD card into lost connection (it's the same hub my wireless keyboard/mouse are connected to). So I'm currently thinking this is a hardware problem on writes to the SD card. I could use a good validation tool.
I did a sum of the SD contents and the pkg tree and they seemed okay. So maybe it isn't hardware.
Re-running overlay test with old build first.
Found it: I used to run mkinstall as sudo but this time I'm running it as a normal user. There is a line added to config.txt if we're doing the overlay that tells the bootloader to use the initramfs. Adding that line was failing because it wasn't being run as sudo, so there was no initramfs and thus the overlay couldn't be booted.
I've fixed that. Testing again. If this works, I can test with the apps next.
- % Done changed from 50 to 70
I need to rebuild the rpi4 tree with all fixes from the rpi1 tree pulled. Then test once more in dev platform mode. I expect this to work with the rpi4 tree.
Then I can build and test the apps with the rpi4 tree.
Assuming that works, this will be done.
- % Done changed from 70 to 50
Ugh. Now ntp isn't matching the hash. Looks like the upstream release file size has indeed changed, or at least the downloaded size has (maybe there is a MitM?). Anyway, I pushed a local copy to my archive site and now the build is running. Again.
Also, the generated build didn't boot on hardware. I have no idea why this time. So I started the build from scratch again, just to make sure it was clean.
Boy, this is taking a lot longer than I expected.
The full rebuild worked mostly, but X11 did not start. Turns out that 7f6f3021 now needs to be the default, where xorg.conf needs to add
Previously only xeoncfg did this in the postinst script. Now we need to do it always. That means:
- Add it to the default xorg.conf
- Take it out of xeoncfg's postinst script
- Status changed from In Progress to Closed
- % Done changed from 70 to 100
Verified working with both RPi 2 and 3, with the latter tested with standard monitor and touchscreen display.
Apps were also tested to be working, in general.
All changes committed and pushed.