Re: RPi4 Status and xorg behavior

On 2021-Mar-7, at 17:10, bob prohaska <fbsd at www.zefox.net> wrote:


> In the interests of exploration, I tinkered a bit more with
> my Pi4 running the latest -current snapshot. Here are a few
> observations:

You may want to be explicit about the build version
involved (last commit involved on what branch).

My notes below are from a non-debugt build based on
main bad9fa56620e (CommitDate: 2021-03-06 21:46:28
+0000). Used on a RPi4B 8GiByte.

> Screen resolution seems to be about 30 lines by 90 columns,
> on a commonplace Dell 1920 by 1080 HDMI display. Mouse and
> keyboard work correctly.

My boot sequence for the RPi4B 8 GiByte shows (when I have
the HDMI display attached, which I usually do not):

EFI framebuffer information:
addr, size     0x3e2fe000, 0x7e9000
dimensions     1920 x 1080
stride         1920
masks          0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000
. . .
fb0: <BCM2835 VT framebuffer driver> on simplebus0
fb0: keeping existing fb bpp of 32
fbd0 on fb0
WARNING: Device "fb" is Giant locked and may be deleted before FreeBSD 14.0.
VT: Replacing driver "efifb" with new "fb".
fb0: 1920x1080(1920x1080@0,0) 32bpp
fb0: fbswap: 1, pitch 7680, base 0x3e2fe000, screen_size 8355840
. . .

I use:

if [ -x /usr/bin/resizewin ] ; then /usr/bin/resizewin -z ; fi

in various ~/.profile files and after logging-in doing a
"stty -a" shows as its first line:

speed 9600 baud; 67 rows; 240 columns;

Thus figures seem accurate.

I doubt that it matters but /boot/loader.conf does have:

boot_multicons="YES"
boot_serial="YES"


> Boot countdown timers run five to ten times slower than actual time.

For the 10 down to zero countdown in the loader
prompt it takes about a minute here.

How about shutdown timers? "shutdown +10sec" takes about
10sec here. "shutdown +1" (so in 1 minute) takes about 1
minute. I've not tried absolute times.

But I've a network connection and use:

# Nice if you have a network, else annoying.
ntpd_enable="YES"
ntpd_sync_on_start="YES"
ntpd_user="root"

That is not involved at the loader prompt's count down's
time frame.

> Boot seems to stall until enter is hit at a couple of points, the
> first I think was after displaying
> EFI console

I've never observed such a hang requiring input.
(I do have a serial console set up.) If it does
not really hang, how long does it take at each
pause when there is no input? The 10 down to 0
already mentioned earlier is the pause that I
noticed and have explicitly timed.

I assume that "EFI console" here is a reference to
the "Consoles: EFI console" text shortly after
"Booting /efi\boot\bootaa64.efi". (My wording ignores
escape sequences that are in the character sequence.)

> Wired ethernet worked through a wireless bridge without intervention.
> How it connected without being told the password for the access point
> remains a puzzle. Maybe it inherited a DHCP session left over from
> RaspiOS, which was shut down a few minutes previously.
> 
> Xorg and Firefox installed as packages without difficulty, but Xorg
> persists in using the very low resolution inherited from the boot 
> display. Running X -configure reports no devices to configure. That
> seems the first thing worth fixing, any hints greatly appreciated!

I normally do not use X11 but I do sometimes build
lumina as part of building ports for aarch64, more
as I general test of how builds go than for use.

X11 and Firefox and the like are outside my range of
use. So I'm not of much help here.

> Firefox spews errors on the controlling terminal but seems to run
> and produce a reasonable display, given the low screen resolution.

I've no clue why you end up with something other
than 67 lines x 240 characters on a 1920 x 1080
display.

May be displays have a built-in default font that
varies from model to model and that default is
implicitly used by FreeBSD?


FYI:
On the ThreadRipper I do control things explicitly
via /boot/loader.conf having:

screen.textmode="0"
screen.font="8x16"

but the context is a 2560 x 1440 display and there
is no serial console set up for this context. I've
not investigated such things on any other type of
context. "stty -a" ends up reporting:

speed 9600 baud; 75 rows; 240 columns;

(System built from same sources as the RPi4B's
system was, also non-debug style.)


> Altogether I'm very impressed. If this isn't Tier 1 behavior it's
> mighty close.... 



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

_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[email protected]"