Re: 13.1R problems on Pi3
- Reply: Karl Denninger : "Re: 13.1R problems on Pi3"
- In reply to: bob prohaska : "13.1R problems on Pi3"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
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