piCore15.0 Beta

[Pengo]

Hi Rich,

I am using the 64 bit version (which is ok for the piZero2W)
The repository of the 64 bit version does not have a screen.tcz (and the 32 bit version will not work)

[Paul_123]

Screen 4.9.1 has autotools/configure problems finding ncurses.  But 4.9.0 works just fine.

I compiled and uploaded the extension for aarch64.  Mostly untested, since I don't use screen.

[Pengo]

Thanks for helping out Paul!

It looks like screen is working.

I recognize the ncurses compilation issue. More software has problems finding the ncurses header files and libraries. 
It seems the include directory name has changed to ncursesw (from the top of my head)

[Paul_123]

I just pushed up Beta2 images, only changes are updating the kernel to 6.6.34 and fixing the compiled in fonts.

In my opinion, the TER16x32 font is too big, but the SUN12x22 font looks horrible.   But I suppose, its just a console font.

[Juanito]

Works fine for me 

The kernel automatically selects TER16x32 for the monitor's native resolution of 3840x2160, it looks good and is just the right size to read easily.

In x or wayland I set the screen to 1920x1080 to be able to read it easily with the default fonts.

[Juanito]

I just updated to piCore15.0 Beta armhf by copying over files to an sd card containing piCore-13.x running on an RPi3.

piCore-15.x booted and after copying over xorg-server (for the vc4 snippet) and graphics-KERNEL, the gui started.

I then updated all the extensions (due to the change in squashfs block size they are all marked for update) and now the gui will not start.

* I added the missing cairo dep to the harfbuzz dep file
* I created the missing llvm15-lib dep file containing gcc_libs, libzstd, ncurses and libxml2
* cairo-sphinx is missing a dep on pcre (this will probably disappear if compiled without pcre present).

There are no errors in Xorg.0.log, it looks like a normal startup - xorg does not start from boot due to the race condition loading modules, but starts with startx to a blank screen.

Strangely the screen comes up at 2048x1152, when I would have expected it to come up at 4khd or hd, but perhaps that's a limitation of the RPi3. If I add a snippet to set the screen to 1920x1080, it still comes up blank.

dmesg gives this:

Code: [Select]

dmesg | grep vc4
[    7.330096] vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops [vc4])
[    7.338553] rc rc0: vc4-hdmi as /devices/platform/soc/3f902000.hdmi/rc/rc0
[    7.339287] input: vc4-hdmi as /devices/platform/soc/3f902000.hdmi/rc/rc0/input0
[   17.755263] vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops [vc4])
[   17.757370] rc rc0: vc4-hdmi as /devices/platform/soc/3f902000.hdmi/rc/rc0
[   17.757667] input: vc4-hdmi as /devices/platform/soc/3f902000.hdmi/rc/rc0/input1
[   17.766294] input: vc4-hdmi HDMI Jack as /devices/platform/soc/3f902000.hdmi/sound/card1/input2
[   17.767677] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops [vc4])
[   17.768153] vc4-drm soc:gpu: bound 3f004000.txp (ops vc4_txp_ops [vc4])
[   17.768499] vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops vc4_crtc_ops [vc4])
[   17.768826] vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops vc4_crtc_ops [vc4])
[   17.769153] vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops vc4_crtc_ops [vc4])
[   17.769413] vc4-drm soc:gpu: bound 3fc00000.v3d (ops vc4_v3d_ops [vc4])
[   17.775203] [drm] Initialized vc4 0.0.0 20140616 for soc:gpu on minor 0
[   17.778549] vc4-drm soc:gpu: [drm] Cannot find any crtc or sizes
Any ideas?

[Paul_123]

Can you check to make sure I added the vc4.conf file?

[Juanito]

Yes, it’s there

[Juanito]

After some more investigation, including burning the beta2 image to a new sd card, I found Xorg and wayland (weston) will start a gui, but not Xorg-3d.

The above would seem to indicate the problem is with graphics-KERNEL, but weston uses that too. What's puzzling me is that when I used mostly piCore-14.x extensions, but piCore-15.x graphics-KERNEL and xorg-server, Xorg-3d worked.

The above is using an RPi3 - Xorg-3d works on piCore64 using an RPi4.

Edit: Xorg.0.log attached

[Rich]

Hi Juanito

... xorg does not start from boot due to the race condition loading modules, but starts with startx to a blank screen. ...

I dealt with that by adding this to the beginning of .xsession:

Code: [Select]

# Wait for the video card to be detected so that
# Xorg can find it.
while [ $Timeout -lt 40 ]
do
        [ -e /dev/dri/card0 ] && break
        Timeout=$(($Timeout + 1))
        sleep 0.25
done

[Juanito]

Sure, but I’m loading Xorg-3d after booting and verifying that /dev/dri/card0 is present - you can see it is found in the xorg log attached to the previous post.

[Paul_123]

I dont think the pi4 and pi5 have issues with the race conditions, but the pi3 might.   But in your log, you started X well after boot, and the gpu was found straight away.   I think the first thing I would probably try is updating Mesa.

[Rich]

Hi Juanito

Sure, but I’m loading Xorg-3d after booting and verifying that /dev/dri/card0 is present - ...

I was not aware of that.

... you can see it is found in the xorg log attached to the previous post.

Yes, I saw that. That's what reminded me of what I did to get rid of the
"Failed in wait for X" error when booting.

[Juanito]

I updated mesa, but the problem persists - 2d works, but 3d has a blank screen.

Information is being transmitted because if I change the screen resolution with an xorg snippet, the monitor reports the correct resolution is connected.

Still no errors in the xorg log

[Paul_123]

I just see notes about vc4/v3d compatibility issues with old videocore IV devices, but no real suggestions or solutions.