Date: Sat, 9 May 2020 13:05:25 +1000 From: Brian Scott <bscott@bunyatech.com.au> To: freebsd-arm@freebsd.org Subject: Re: X on RPi3 lately Message-ID: <b1591e2a-78a9-5950-e879-d9fa4f54819b@bunyatech.com.au> In-Reply-To: <9316ed0f-1c2e-b18e-d2f3-9b4981db86b8@bunyatech.com.au> References: <c573170c-6342-a2e0-a729-45b071daad52@bunyatech.com.au> <9316ed0f-1c2e-b18e-d2f3-9b4981db86b8@bunyatech.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Created bug https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246319 since nobody could tell me I was doing something stupid. Cheers, Brian Scott On 17/4/20 3:29 pm, Brian Scott wrote: > On 17/4/20 2:55 pm, Brian Scott wrote: >> 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 >> >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >> > Hi, > > Following up my own email with more information (as you do), my very old > system was 12.0 RELEASE. The fb messages at startup were identical (i.e. > indicating 24bpp because that's all the code can show). > > For the giggles, I tried doing some mix and match with kernels. My setup > has the boot and kernel on the SD card and everything else on a USB > connected drive. So... > > 12.0 RELEASE kernel + 12.1 STABLE world + packages etc - Same result. > Invalid bpp in X. > > 12.1 STABLE kernel + 12.0 RELEASE + a bunch of very outdated packages - > Works perfectly. Nice looking X display. > > I was amazed that both booted and ran as well as they did. > > What it did tell me is that the problem isn't in the kernel, u-boot or > the firmware. Rather, it is in X11 somewhere, possibly in reaction to > something that was changed at the lower levels. I don't know where the > linux folk would have hidden their kluge to make this work or how that > would impact FreeBSD. > > Thanks for reading, > > Brian >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b1591e2a-78a9-5950-e879-d9fa4f54819b>