Project

General

Profile

Actions

Feature #736

closed

Retest builds

Added by Hammel almost 5 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
Immediate
Assignee:
Category:
00 - Basic Build Issues
Target version:
Start date:
03 Feb 2020
Due date:
% Done:

100%

Estimated time:
Severity:
03 - Medium

Description

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.

Actions #1

Updated by Hammel over 4 years ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 10

Crosstool-ng was down yesterday so I wasn't able to retry the dev platform build. Appears it's still a problem. Apparently Yann's domain was not renewed or similar.

Actions #2

Updated by Hammel over 4 years ago

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

Actions #3

Updated by Hammel over 4 years ago

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.

Actions #4

Updated by Hammel over 4 years ago

  • % Done changed from 10 to 20

The problem is that the URL changed by freedesktop. The new format is

https://gitlab.freedesktop.org/libevdev/evtest/-/archive/evtest-$(EVTEST_VERSION)

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.

Actions #5

Updated by Hammel over 4 years ago

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.

Actions #6

Updated by Hammel over 4 years ago

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.

Actions #7

Updated by Hammel over 4 years ago

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.

Actions #8

Updated by Hammel over 4 years ago

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

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

Actions #9

Updated by Hammel over 4 years ago

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

Actions #10

Updated by Hammel over 4 years ago

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

Actions #11

Updated by Hammel over 4 years ago

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.

Actions #12

Updated by Hammel over 4 years ago

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.

Actions #13

Updated by Hammel over 4 years ago

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

Actions #14

Updated by Hammel over 4 years ago

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

Actions #15

Updated by Hammel over 4 years ago

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
Actions #16

Updated by Hammel over 4 years ago

  • % Done changed from 50 to 70

That fix seems to work just fine on a RPi2 with a standard HDMI monitor. I need to test it with RPi3, both with a standard monitor and with the touchscreen.

Actions #17

Updated by Hammel over 4 years ago

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

Closing issue.

Actions

Also available in: Atom PDF