RPi4 Status and xorg behavior

[Mark Millard]

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 ;-)



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