Action Item #687

Build refresh

Added by Hammel 9 months ago. Updated 6 days ago.

Status:In ProgressStart date:04 Feb 2019
Priority:ImmediateDue date:
Assignee:Hammel% Done:

80%

Category:00 - Basic Build Issues
Target version:1.1.0 - Upgrades
Severity:01 - Critical

Description

This issue will be used when I'm refreshing the build to make sure all URLs and meta builds are working properly.

Associated revisions

Revision f01f7066
Added by Hammel 9 months ago

RM #687: Build refresh: fix broken urls in Buildroot packages.

Revision 4ee8c27c
Added by Hammel 8 months ago

RM #687: Build refresh: Add ubsan.c patch to allow gcc 7.x or higher to build linaro toolchain for rpi1 build.

Revision a47b90b4
Added by Hammel 8 months ago

RM #687: Remove devmem2 from buildroot. It's not being used and the upstream is not reachable.

Revision 46059f2c
Added by Hammel 7 months ago

RM #687: Remove outdated Busybox configurations.

Revision cd45bed8
Added by Hammel 7 months ago

RM #687: Remove ipv6 controls since we don't use ipv6 in PiBox.

Revision db51c5a0
Added by Hammel 7 months ago

RM #687: Fix some boot time errors with Alsa and bluetooth.

Revision 68562a27
Added by Hammel about 1 month ago

RM #687: Add missing include dir for dbus/dbus.h to makefile config.

Revision b6a17fcf
Added by Hammel about 1 month ago

RM #687: Bump back up to master branch to pick up fixes for use with glibc > 2.7 (PiBox is bumped to 2.9).

Revision 6cd583c3
Added by Hammel about 1 month ago

RM #687: Refresh PiBox core development components: xcc 1.24.0, Buildroot 2019.05.01. Drop xcc 1.15.2 and 1.18.0, and custom kernel 4.19.y config (use defconfig instead).

Revision f51ecdc5
Added by Hammel 16 days ago

RM #687: xeon needs to use the same kernel name as rpi1 in mkinstall.sh.

Revision cd2f6666
Added by Hammel 6 days ago

RM #687: Add upstream patch to handle changes to dhcpd installation.

Revision 574296bf
Added by Hammel 6 days ago

RM #687: Add upstream patch to handle changes to dhcpd shared libs installation.

History

#1 Updated by Hammel 9 months ago

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

2018-02-04: Buildroot needs patches (available from upstream) for broken URLs.

#2 Updated by Hammel 8 months ago

I think everything is working now for both RPi and RPi2 builds. I need to verify this once for each before closing issue.

#3 Updated by Hammel 8 months ago

  • % Done changed from 50 to 70

HW=rpi verified working after removing devmem2 (can't reach upstream), which wasn't being used anyway.

#4 Updated by Hammel 7 months ago

  • Status changed from In Progress to Closed
  • % Done changed from 70 to 100

Builds tested on both RPi and RPi2 boards. Refresh includes bump in kernel to 4.19.y.

All changes pushed.
Closing issue.

#5 Updated by Hammel 3 months ago

  • Status changed from Closed to In Progress
  • % Done changed from 100 to 80

August 2019

Re-opened for the following updates.
  • Bump Crosstool-NG to 1.24.0
  • Bump Buildroot to 2019.05.1

Kernel and other RPi components don't need a refresh.

#6 Updated by Hammel 3 months ago

Builds completed for both RPi 1 and 2 (which includes Xeon).

  • RPi 1 needs testing with Xeon.
  • RPi 2 needs testing with media system and kiosk.

#7 Updated by Hammel about 1 month ago

RPI2 build tested on RPi 2 and 3. Both work fine in development mode. Media center plays video but doesn't not support keyboard exit, FF, etc. I'm guessing this is because omxplayer changed their FIFO command usage. I need to investigate this by
  1. Verifying commands are being sent to the FIFO via the video player.
  2. omxplayer release I'm using supports FIFO.

I just checked the PiBox omx git tree used by the build and it's set to a specific commit (and older one to permit proper builds, no doubt). So it should still be supporting the FIFOs.

That means something else is happening where the videofe program is getting the keystrokes or not sending them properly to omxplayer. I can verify this by starting the app from the UI then ssh'ing into the node and manually checking for the FIFO, sending commands through it manually if necessary.

#8 Updated by Hammel about 1 month ago

Looks like no key presses are getting to videofe once omxplayer is started. I don't know who is blocking this. Neither the HOME key nor any omxplayer keys (FF, etc.) are being honored. It looks like the xterm is capture the keystrokes maybe? I could try switching to a different VT.

#9 Updated by Hammel about 1 month ago

This might be the problem for omxplayer: https://github.com/popcornmix/omxplayer/issues/649
I'll have to patch omxplayer itself to fix this, or bump ahead to a more recent version.

Hmmm. Just noticed that RM #656 pushed omxplayer to master, yet the wrapper build is using commit a3ae908. That was done because of this commit which is related to this response. So I need to test omxplayer using the HEAD of master and the latest firmware. Note that popcornmix's response was in Nov and I ran into the problem in August, so maybe this will "just work" now.

That may get me past why omxplayer is not responding but it may not address why the HOME key is not exiting the player.

#10 Updated by Hammel about 1 month ago

I'm now starting to think this isn't a problem with videofe, but solely a problem with omxplayer. I'm testing the refresh with glibc 2.29, which would show the problem having come from 2.25. And the exit from omxplayer is NOT handled by videofe when using the keyboard. It's directly handled by omxplayer.

So I need to rev omxplayer to master and make sure it's working again.

#11 Updated by Hammel about 1 month ago

Verified - bumping omxplayer back up to the master branch (commit id f543a0d0e707ab56415f17b0ca6d397394ee8b63) fixed the keyboard problems. Media player is working fine now on Raspberry Pi 2 Model B Rev 1.2.

Since I've bumped all my demos to use either RPi 2 or 3 except for Xeon (which runs on a Pi Zero W, which is equivalent to RPi 1), I can now test the refresh on the Xeon.

#12 Updated by Hammel about 1 month ago

Ugh. Picam is not working correctly. It works fine if I run it from the command line. If I launch it from the launcher it doesn't show a picture. Not sure what problem this may be but it's possible that mjpeg-streamer is not starting fast enough for omxplayer.bin to connect to - I noticed in earlier tests that omxplayer seems to start much faster now. I may need to synchronize this better.

Update: Just tested running the picam command manually: xterm -display :0.0 -fullscreen -fg black -bg black -e omxplayer.bin --live --fps 10 -o hdmi -r http://192.168.101.17:9090/?action=stream
That worked. I got the webcam on the monitor. So the problem is (likely) that the http port is not available when omxplayer is started.

I need a sync'ing method. I can either add a message to piboxd to tell me if the port is in use or I can test it manually in picam. The latter seems easier.

#13 Updated by Hammel about 1 month ago

Picam's problem were not as bad as I thought. There were two problems. 1: permissions - I had mucked up permissions first on omxplayer.bin and then on picam itself while testing. Those don't require any fixes if we install from the packages. 2: permissions - picam can no longer switch VTs because it's not privileged. I don't know why that is happening now but I have verified it. The fix is to append /usr/bin/picam to /etc/appmgr.priv on package installation, if the entry does not already exist.

After I fix that I need to test the rest of the apps and make sure they are working before moving on to testing Xeon.

#14 Updated by Hammel about 1 month ago

All media center apps seem to be working now except pixm, which has a different problem: ttyUSB0 is not found unless the device is connected at boot. So that's not really a build refresh problem and I'll deal with it later.

I'm going to push the updates for pibox and then build a Xeon (rpi1) release to test it.

#15 Updated by Hammel 14 days ago

Xeon is not working because the update includes a change to xf86DisableRandR() - drivers should not be using this anymore but the xfturbo driver is. Fortunately it is only called in one place. So the fix is to remove that call, apparently, or stub in a fake xf86DisableRandR() function that does nothing. Either would work, it seems.

This bug doesn't show up on media servers, kiosks or Ironman because none of them use "option Rotate CCW". Only Xeon has this problem.

I need to fix this with a patch in my PiBox build, then submit it upstream to Buildroot and/or the fbturbo driver repo.

#16 Updated by Hammel 11 days ago

This is fixed in the pibox repo and the commit is pushed upstream.

Another bug was exposed once we got past this one. The shadowUpdateRotatePackedWeak() and shadowUpdatePackedWeak() functions don't work unless you have the following code added to the xorg.conf:

Section "Module" 
        Load    "shadow" 
EndSection

Without this code the driver fails to load. This has been added to the xeoncfg package (committed and pushed). The X interface now comes up but the touch interface is not working because the touch coordinates are wrong. I'll fix that separately from this as xeon was never quite stable anyway.

I still need to test Ironman - I've only managed to bring it back up to where it was before. Now I need to test the updated code on it.

#17 Updated by Hammel 6 days ago

Ironman fails because the 2019.05 release of Buildroot has a bug in the dhcp installation. The version of dhcp was bumped to 4.4.1 but this version requires installing the binary from the src/.libs directory. Buildroot wasn't doing that so I got the libtool script for dhcp instead. The result is that configuration mode doesn't work because dhcpd is not started at boot.

There is already a patch for this so I grabbed it and integrated it into the build. That worked the first time I applied the patch and rebuilt so I now have a proper dhcpd binary under /usr/sbin. I can now continue testing Ironman.

Also available in: Atom PDF