PiBox

Crosstool-ng domains are restored. I can start retesting the builds again.

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.

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.

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

brcmfmac43430-sdio.bin

but it now seems to want

brcmfmac43455-sdio.bin

Also, the associated .txt originally was

brcmfmac43430-sdio.txt

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

https://github.com/OpenELEC/wlan-firmware/tree/master/firmware/brcm

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.

Verified - the 43455 firmware works on the RPi 3 Model B+.

Also, the rootfs build completed successfully. Continuing with the rest of the build.

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.

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

Load "shadow"

right after

Load "dri"

Previously only xeoncfg did this in the postinst script. Now we need to do it always. That means:

1. Add it to the default xorg.conf
2. Take it out of xeoncfg's postinst script