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>