Missing /dev/io on rpi3 running 12-stable

[Mark Millard]

On 2020-May-20, at 19:25, bob prohaska <fbsd at www.zefox.net> wrote:
> 
> Which list is the appropriate forum, -ports, -arm or something else?
> If there is a better problem description I'll use it.  ISTR xorg 
> compiling and running without a hitch on -current previously, ~ 
> a year ago.

Does not look like I can match the RPi3 context
as a cross check. (I tried.) At best a RPi4.

I do not normally use a display but I normally do
build lumina and what it requires as part of checking
the build environment. (head -r360311 contexts
currently.)

I tried to see what I could do on the RPi3 and RPi4. The
surprise: RPi4 output worked fine at all stages and the
RPI3 got no video output at all at any time, not even the
RPi3's own early-stage test-output. (Same HDMI display
used for both.)

Both the RPi3 and RPi4 do report the following
when the display is connected:

EFI framebuffer information:
addr, size     0x3e513000, 0x6d8c00
dimensions     1824 x 984
stride         1824
masks          0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000
. . .
VT(efifb): resolution 1824x984

Without the HDMI connection the RPi3 shows:

EFI framebuffer information:
addr, size     0x3eaf7000, 0x103000
dimensions     592 x 448
stride         592
masks          0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000
. . .
VT(efifb): resolution 592x448

Back to with the HDMI connection . . .

Both RPi*'s show:

fb0: <BCM2835 VT framebuffer driver> on simplebus0
fb0: keeping existing fb bpp of 32
fbd0 on fb0
WARNING: Device "fb" is Giant locked and may be deleted before FreeBSD 13.0.
VT: Replacing driver "efifb" with new "fb".
fb0: 1824x984(1824x984 at 0,0) 32bpp
fb0: fbswap: 1, pitch 7296, base 0x3e513000, screen_size 7237632

It leaves me wondering if the RPi3 has a hardware
problem. (No display output even before u-boot is
involved, unlike normal.)


As for the RPi4: I do not see any attempt at a
/dev/io reference or any additional kernel modules
loaded. It does:

. . .
[   137.989] (II) Loading /usr/local/lib/xorg/modules/extensions/libglx.so
. . .
[   138.129] (II) Loading /usr/local/lib/xorg/modules/drivers/modesetting_drv.so
. . .
[   138.136] (II) Loading /usr/local/lib/xorg/modules/drivers/scfb_drv.so
. . .
[   138.141] (II) Loading /usr/local/lib/xorg/modules/libshadow.so
. . .
[   138.144] (II) Loading /usr/local/lib/xorg/modules/libfb.so
. . .
[   140.068] (II) Loading /usr/local/lib/xorg/modules/input/libinput_drv.so
. . .

and kldstat shows:

# kldstat
Id Refs Address                Size Name
 1    6 0xffff000000000000  112dbf8 kernel
 2    1 0xffff00000112e000    257c8 umodem.ko
 3    2 0xffff000001154000    28658 ucom.ko

My ports builds are based on ports head -r533162 . I
explicitly build the following related to lumina
for the aarch64 contexts:

x11-drivers/xf86-video-scfb
x11/lumina
x11/xorg-minimal
x11/xterm

These, of course, lead to much more building. I built
with default options for them all.

No mouse or usb keyboard input to use lumina with on
the RPi4 so I can not claim anything about past its
initial display.

In my context, startx is tied to:

# more ~/.xinitrc 
exec start-lumina-desktop

# ls -laT /etc/X11/
total 8
drwxr-xr-x   2 root  wheel   512 Mar 30 05:23:44 2020 .
drwxr-xr-x  27 root  wheel  2560 Apr 29 13:52:48 2020 ..

(Yep: empty.)

That is all I have. I'm not so sure any of it will
happen to help.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)