From owner-freebsd-arm@freebsd.org Fri Apr 17 04:56:01 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id ED12D2A9AF9 for ; Fri, 17 Apr 2020 04:56:01 +0000 (UTC) (envelope-from bscott@bunyatech.com.au) Received: from ppp221-139.static.internode.on.net (2001-44b8-4170-0a00-0000-0000-0000-0002.static.ipv6.internode.on.net [IPv6:2001:44b8:4170:a00::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "150.101.221.139", Issuer "Bunya Technology Certification Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 493P1V71sdz4XfR for ; Fri, 17 Apr 2020 04:55:57 +0000 (UTC) (envelope-from bscott@bunyatech.com.au) X-Clacks-Overhead: GNU Terry Pratchett Received: from DHCP.tawonga.bunyatech.com.au (DHCP.tawonga.bunyatech.com.au [10.0.1.106] (may be forged)) (authenticated bits=0) by cope.tawonga.bunyatech.com.au (8.15.2/8.15.2/MSA) with ESMTPSA id 03H4th2h084637 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Fri, 17 Apr 2020 14:55:44 +1000 (AEST) (envelope-from bscott@bunyatech.com.au) To: freebsd-arm From: Brian Scott Subject: X on RPi3 lately Message-ID: Date: Fri, 17 Apr 2020 14:55:43 +1000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 Content-Language: en-US X-Rspamd-Queue-Id: 493P1V71sdz4XfR X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of bscott@bunyatech.com.au designates 2001:44b8:4170:a00::2 as permitted sender) smtp.mailfrom=bscott@bunyatech.com.au X-Spamd-Result: default: False [0.69 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; SH_EMAIL_ZRD(0.00)[0.0.0.0]; FROM_HAS_DN(0.00)[]; SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[0.0.0.0]; R_SPF_ALLOW(-0.20)[+ip6:2001:44b8:4170:a00::/56]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[bunyatech.com.au]; NEURAL_SPAM_MEDIUM(0.05)[0.050,0]; URI_COUNT_ODD(1.00)[3]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(0.26)[asn: 4739(1.28), country: AU(0.01)]; TO_DN_ALL(0.00)[]; NEURAL_HAM_LONG(-0.42)[-0.415,0]; MIME_BASE64_TEXT(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:4739, ipnet:2001:44b8::/32, country:AU]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2020 04:56:02 -0000 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: 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