Date: Fri, 17 Apr 2020 15:29:30 +1000 From: Brian Scott <bscott@bunyatech.com.au> To: freebsd-arm@freebsd.org Subject: Re: X on RPi3 lately Message-ID: <9316ed0f-1c2e-b18e-d2f3-9b4981db86b8@bunyatech.com.au> In-Reply-To: <c573170c-6342-a2e0-a729-45b071daad52@bunyatech.com.au> References: <c573170c-6342-a2e0-a729-45b071daad52@bunyatech.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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?9316ed0f-1c2e-b18e-d2f3-9b4981db86b8>