Re: 13.1R problems on Pi3

From: Mark Millard <marklmi_at_yahoo.com>
Date: Mon, 04 Jul 2022 02:22:56 UTC

On 2022-Jul-3, at 17:36, bob prohaska <fbsd@www.zefox.net> wrote:

> A clean install of 13.1R on a Pi3 still exhibits three long-standing
> problems also seen on a Pi3 which started from 13.1RC4
> 
> Attempts to saveenv under uboot running from microSD fail.
> As it happens, I need to set usb_pgood_delay to a larger
> value to let the machine find the USB hard disk. Thus far
> the workaround has been to manually editenv on the console.

So far as I know, U-Boot's saveenv has never worked for any
RPi*'s. This is not specific to your context or to recent
times. Possibly not even specific to FreeBSD's U-Boot port
builds. (Fedora? OpenBSD? . . .)

We have exchanged messages before about building U-Boot
with the required changes built in, providing an extra
file that the build would use. Below I gave the example
of what I use:

/usr/ports/sysutils/u-boot-rpi-arm64/files/patch-include_configs_rpi.h

that looks like:

# more /usr/ports/sysutils/u-boot-rpi2/files/patch-include_configs_rpi.h
--- include/configs/rpi.h.orig	2022-01-22 06:03:55.862541000 -0800
+++ include/configs/rpi.h	2022-01-22 06:03:05.435341000 -0800
@@ -210,6 +210,8 @@
 	ENV_DEVICE_SETTINGS \
 	ENV_DFU_SETTINGS \
 	ENV_MEM_LAYOUT_SETTINGS \
+	"usb_pgood_delay=2000\0" \
+	"usb_ready_retry=5\0" \
 	BOOTENV
 
 

I have also added the file as an attachment, which may be easier
to deal with since I also Email you driectly.

You can, of course, change the 2000 and/or the 5 as appropriate
or adjust other aspects of the "+" lines. Changing the number of
"+" lines gets into making the "@@" line match. Currently it
indicates to replace 6 lines by 8 lines. (There are 2 lines
with just 1 leading space after the "BOOTENV" line, those
are the last 2 of the 6 non-"+" lines.)

I picked providing u-boot-rpi-arm64 material because that
is what the modern images for aarch64 RPi*'s are based on
as I understand. It works on a wider range of devices.

> Inbound ping requests are not answered except for a few
> seconds around the time ntp runs.
> 
> Inbound ssh connects prompt for a password and then time out.
> 
> The ping and ssh problems can be worked around by starting an
> outbound ping process. A few seconds after doing so both ping
> and ssh are answered, erratically but usably.
> 
> The problem seems to be confined to the Pi3s. Four Pi2s and a Pi4
> on the same network branch exhibit no such problems. Only the
> pair of Pi3s seem to be affected, under 13.1 and -current.
> 
> The network is started with these lines in /etc/rc.conf:
> 
> hostname="www.zefox.org"
> ifconfig_ue0="inet 50.1.20.28 netmask 255.255.255.0"
> defaultrouter="50.1.20.1"
> sshd_enable="YES"

Is that only one of the RPi3*'s? Multiple machines with
that exact text would conflict with each other, all
such trying to use 50.1.20.28 and www.zefox.org as
identification.

Has whatever provides DHCP and such been configured to
reserve 50.1.20.28 and to associate that with the right
ethernet address? If you do not have control of such,
then, as far as I know, you should not be trying to use
what are effectively static IP addresses --unless you
have been assigned the static IP addresses by your ISP.

> Reference to DHCP has been removed.

Why? If you use DHCP on the others, can you check the
behavior of using DHCP on these? Does it match the
others --or does end up being distinct/problematical?

(This testing may not be able to cover the intended
use, depending on why you avoid DHCP.)

Reminder: I'm no networking expert.

> Could that be a source
> of mischief? It seems not to cause problems on other hosts.
> 

That reads like you might have tried not using DHCP on
the RPi2*'s and RPi4* . Did you?


===
Mark Millard
marklmi at yahoo.com