RPi4 Status and xorg behavior

Mark Millard marklmi at yahoo.com
Mon Mar 8 20:44:17 UTC 2021


> On 2021-Mar-8, at 12:24, Mark Millard <marklmi at yahoo.com> wrote:
> 
> On 2021-Mar-8, at 12:02, Klaus Küchemann <maciphone2 at googlemail.com> wrote:
> 
>> 
>>> Am 08.03.2021 um 20:47 schrieb Mark Millard <marklmi at yahoo.com>:
>>> 
>>> 
>>> FYI the 2021-Mar-04 snapshot:
>>> 
>>> FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20210304-483c6da3a20-257149.img……………
>>> ….. 
>>> 
>>> and so is not yet based on the 1.20210303 tagged
>>> firmware:
>>> 
>> 
>> Yes, thank you ,I know(´ve tested both with & without 1.20210303 with 483c6da3a20-257149.img 
>> on the 8GB-model )
>> e.g. unplugging the keyboard leads.. to the  crash reported here at boot time  :
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253981#c16
>> ( xhci-ring.c:498 ) if  1.20210303 is used…
> 
> I get no such crashes from my non-debug build based
> on main 14 bad9fa56620e (CommitDate: 2021-03-06
> 21:46:28 +0000) on a Rpi4B 8 GiByte:
> 
> ugen0.3: <vendor 0x05e3 USB2.0 Hub> at usbus0 (disconnected)
> uhub2: at uhub1, port 3, addr 2 (disconnected)
> ugen0.4: <vendor 0x04d9 RPI Wired Keyboard 4> at usbus0 (disconnected)
> ukbd0: at uhub2, port 1, addr 3 (disconnected)
> ukbd0: detached
> uhid0: at uhub2, port 1, addr 3 (disconnected)
> uhid0: detached
> uhub2: detached
> ugen0.3: <vendor 0x05e3 USB2.0 Hub> at usbus0
> uhub2 on uhub1
> uhub2: <vendor 0x05e3 USB2.0 Hub, class 9/0, rev 2.00/32.98, addr 2> on usbus0
> uhub2: MTT enabled
> uhub2: 4 ports with 4 removable, self powered
> ugen0.4: <vendor 0x04d9 RPI Wired Keyboard 4> at usbus0
> ukbd0 on uhub2
> ukbd0: <vendor 0x04d9 RPI Wired Keyboard 4, class 0/0, rev 2.00/1.40, addr 3> on usbus0
> kbd1 at ukbd0
> uhid0 on uhub2
> uhid0: <vendor 0x04d9 RPI Wired Keyboard 4, class 0/0, rev 2.00/1.40, addr 3> on usbus0
> 
> the USB keyboard works fine when plugged in. Things
> work no matter if it is plugged in or not, booting
> and normal operation.
> 
> Is the crash only present for debug builds?
> If so, then non-debug may be doing some
> bad things internally, despite not crashing.
> 
> At this point I've no clue what the context
> difference that matters is.
> 
>> 
>> .. (other issues came up)….
>> If you want, you could test that… 
>> I fixed that by replacing known working fw-file-combinations 
> 
>> while 1 thing is still unclear:
>> The time-counter delay from kernel-bootup reported by Bob,
>> maybe that’s a change in 14-current…
> 
> That timescale difference in the loader prompt
> timeout sequence I do see in my build.
> 
>> ...no fun testing all that on different hw and OS-versions ;-)
> 
> 

I tried 13.0-RC1 with the rpi-firmware updated:

# uname -apKU
FreeBSD generic 13.0-RC1 FreeBSD 13.0-RC1 #0 releng/13.0-n244639-60e8939aa85: Fri Mar  5 06:52:59 UTC 2021     root at releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC  arm64 aarch64 1300139 1300139

root at generic:~ # strings /boot/msdos/start4.elf | grep VC_BUILD_ID_
VC_BUILD_ID_USER: dom
VC_BUILD_ID_TIME: 12:10:40
VC_BUILD_ID_VARIANT: start
VC_BUILD_ID_TIME: Feb 25 2021
VC_BUILD_ID_BRANCH: bcm2711_2
VC_BUILD_ID_HOSTNAME: buildbot
VC_BUILD_ID_PLATFORM: raspberrypi_linux
VC_BUILD_ID_VERSION: 564e5f9b852b23a330b1764bcf0b2d022a20afd0 (clean)

Again: boots fine, no crashes, keyboard works fine,
including unplugging and plugging back in.

Note: It does get the large font display.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)



More information about the freebsd-arm mailing list