Date: Fri, 17 Apr 2020 14:55:43 +1000 From: Brian Scott <bscott@bunyatech.com.au> To: freebsd-arm <freebsd-arm@freebsd.org> Subject: X on RPi3 lately Message-ID: <c573170c-6342-a2e0-a729-45b071daad52@bunyatech.com.au>
next in thread | raw e-mail | index | archive | help
Hi,
I don't know if anyone else has hit this but I was just refreshing the
system on my RPi3 with a recent 12 snapshot and found that I can't get X
to start up.
The problem appears to come down to (extract from Xorg.0.log):
[ 52819.563] scfb: PreInit 0
[ 52819.563] (II) scfb(0): Using: depth (24), width (1280), height
(1024)
[ 52819.563] (EE) scfb(0): Specified fbbpp (24) is not a permitted value
[ 52819.563] (II) UnloadModule: "scfb"
[ 52819.563] (EE) Screen(s) found, but none have a usable configuration.
I've experimented with different values for Depth and FbBpp (and
Default...) in xorg.conf with very little changing.
I have seen recent reference[1] to the same error (except for FBTURBO)
on linux recently due to changed firmware where the problem would seem
to be including an incorrect parameter framebuffer_depth=24 in their
config.txt file and the fix was to remove the offending line.
Unfortunately I didn't have a framebuffer_depth= parameter in mine so I
tried adding one with a value of 32. This didn't have any effect. In
both cases the boot messages for the framebuffer show the messages:
fb0: <BCM2835 VT framebuffer driver> on simplebus0
fbd0 on fb0
VT: Replacing driver "efifb" with new "fb".
fb0: 1280x1024(1280x1024@0,0) 24bpp
fb0: fbswap: 1, pitch 3840, base 0x3e83a000, screen_size 3932160
The fdt doesn't appear to have much of an opinion on the matter other
than the format looks like 32 bits (8 alpha(ignored), 8 red, 8 green,
and 8 blue):
framebuffer@3e6fa000 {
format = "a8r8g8b8";
stride = <0x1400>;
height = <0x400>;
width = <0x500>;
reg = <0x3e6fa000 0x500000>;
compatible = "simple-framebuffer";
status = "okay";
};
I've had a little dig around in the code and can't see any recent
changes, much less any smoking guns of work in this sort of area. I
should qualify that by saying that I'm definitely no expert and won't
have hit the whole chain by any stretch.
xf86-video-scfb hasn't changed significantly for a while. It seems to
take what it is given by the underlying framebuffer and passes it back
to X. The error message: "Specified fbbpp (24) is not a permitted value"
isn't generated by this driver but I'm guessing by X when the 24bpp is
passed back.
sys/arm/broadcom/bcm2835/bcm2835_fb.c on stable/12 hasn't changed in any
relevant way recently but does include some interesting things:
#define FB_DEPTH 24
and later on:
fb.bpp = FB_DEPTH;
between calls to bcm2835_mbox_fb_get_w_h and bcm2835_mbox_fb_init.
This is followed shortly after by sc->depth = fb.bpp; setting up what is
then retrieved by the X driver.
Neither bcm2835_mbox_fb_get_w_h or bcm2835_mbox_fb_init change the bpp
value but _fb_init uses it in a request to the firmware:
msg.depth.body.req.bpp = fb->bpp;
I haven't tinkered around with this at all because I'm comprehensively
out my depth at this point and building new kernels is a very slow way
to experiment.
The snapshots that I've tried are
FreeBSD-12.1-STABLE-arm64-aarch64-RPI3-20200326-r359308.img.xz and
FreeBSD-12.1-STABLE-arm64-aarch64-RPI3-20200409-r359721.img.xz.
The system I had been running before I trashed it was
FreeBSD-12.1-RELEASE-arm64-aarch64-RPI3.img.xz. I have an older system
laying about that I have tried (possibly more that a year old) and have
verified that the fdt for the framebuffer hasn't changed. I should have
checked other details like boot messages etc but didn't. I may follow up
this email with those details later.
So does anyone have any clues? Am I the only one to try bringing up the
recent snapshots with X11? Is this a problem that the linux folk have
fixed in a way that impacts FreeBSD, i.e. worked around the firmware
change with a change in the kernel or the X driver? I couldn't see any
changes in the X driver when I went looking but see previous disclaimer.
Thanks for reading the long rant...
Brian Scott
[1] https://github.com/raspberrypi/firmware/issues/1338
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c573170c-6342-a2e0-a729-45b071daad52>