Project

General

Profile

Actions

Action Item #687

closed

Build refresh

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

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

100%

Estimated time:
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.

Actions #1

Updated by Hammel about 5 years 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.

Actions #2

Updated by Hammel about 5 years ago

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

Actions #3

Updated by Hammel about 5 years ago

  • % Done changed from 50 to 70

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

Actions #4

Updated by Hammel about 5 years 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.

Actions #5

Updated by Hammel over 4 years 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.

Actions #6

Updated by Hammel over 4 years 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.
Actions #7

Updated by Hammel over 4 years 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.

Actions #8

Updated by Hammel over 4 years 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.

Actions #9

Updated by Hammel over 4 years 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.

Actions #10

Updated by Hammel over 4 years 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.

Actions #11

Updated by Hammel over 4 years 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.

Actions #12

Updated by Hammel over 4 years 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.

Actions #13

Updated by Hammel over 4 years 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.

Actions #14

Updated by Hammel over 4 years 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.

Actions #15

Updated by Hammel over 4 years 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.

Actions #16

Updated by Hammel over 4 years 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.

Actions #17

Updated by Hammel over 4 years 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.

Actions #18

Updated by Hammel over 4 years ago

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

Ironman is effectively working except I found some bugs in both libpnc and imwww. I can't test this any further till those are fixed but I think it's proof enough that the bits required of the build refresh are there and are not causing these problems.

Xeon also comes up but has multiple problems. None of these are related to the build refresh. Xeon is still in early development and bugs are being tracked separately.

This issue can therefore be closed.

Actions

Also available in: Atom PDF