Re: Raspberry Pi Zero W almost useless (TL-WN725N very good!)
netbsd-raspa# ifconfig urtwn0 urtwn0: flags=0x8843 mtu 1500 ssid MiFibra-3422 nwkey 65536:"",0xc8000336c6e2b40b047cd2f5ef44,"","" powersave off bssid 60:8d:26:32:34:24 chan 1 address: e4:fa:c4:52:ac:4c media: IEEE802.11 autoselect (OFDM54 mode 11g) status: active inet6 fe80::e6fa:c4ff:fe52:ac4c%urtwn0/64 flags 0 scopeid 0x1 inet 192.168.1.230/24 broadcast 192.168.1.255 flags 0 netbsd-raspa# I have been downloading many times the same 3.6 GB file from the internet with no failures just for testing. I have made a CVS checkout of the base system source and pkgsrc source fine. Also have watched a 1h 30 m film using minidlna server in VLC over the local network with no failures at all. With bwfm driver that was just impossible. Great work! Regards. Hello, After a week using the driver I can say that it works well downloading files massively but I noticed I have lost ssh connection two times (both 04:00 to 05:00 in the morning when the system was not doing anything but sending 15s interval pings) (I left a 15 s interval ping script that logged it in a file).Also investigating the logs of my other Zero W with Raspbian I could see that at the precise time the network was lost in the NetBSD ZeroW, the Raspbian ZeroW recorded an association event to the router. Investigating further I noticed that they could be related to router WIFI channel change. "service network restart" a few times luckly restores connection but not always works. I tried also ifconfig urtwn0 up and down manually with no luck. "service wpa_supplicant" restart does not work either. I have systematically reproduced the problem forcing a WIFI channel change from the router and network is always lost after that. If you return the router to the original channel it returns working sometimes. (Raspbian ZeroW always negociate ok channel changes) Leaving the router at a fixed channel could be a "dirty" fix. A channel change seems to be not very frequent, so the rebooting script when network fails could make sense...I do not know. A bit tired of testing and out of ideas... Regards. Ramiro.
Re: Raspberry Pi Zero W almost useless (TL-WN725N very good!)
El 9/2/24 a las 15:20, Michael escribió: Hello, On Fri, 9 Feb 2024 06:25:56 +0100 Ramiro Aceves wrote: I have also the same problem that I had with the chineese 8188FTV, as soon I connect it to the raspberry pi it reboots inmediately. In the next reboot it works fine. It occurs the same in another Zero W that I own with Raspbian and a different power supply. So I doubt that the culprit is the power supply. The Zero W seems to be a very flaky device in terms of power supply. A powered hub should fix that, when a device is plugged directly into the raspberry pis usb (IIRC only 300mA is available) it can cause reboots. Oh yes, that would be a right technical fix for the problem but it's a bit of an aberration in terms of cost and size to use a powered HUB with its own power supply to fix a little thing like the ZeroW, you know ;-) Just use the hub to power the Pi. I used to do that wit the Pi1 and 2. have fun Michael Hello. Just want to share with you that TP-LINK TL-WN725N works very well with the raspberrypi Zero W. netbsd-raspa# uname -a NetBSD netbsd-raspa 10.0_RC3 NetBSD 10.0_RC3 (RPI) #0: Tue Jan 16 08:28:51 UTC 2024 mkre...@mkrepro.netbsd.org:/usr/src/sys/arch/evbarm/compile/RPI evbarm netbsd-raspa# netbsd-raspa# dmesg |grep urtwn [ 1.710793] urtwn0 at uhub0 port 1 [ 1.710793] urtwn0: Realtek (0x0bda) 802.11n NIC (0x8179), rev 2.00/0.00, addr 2 [ 1.770890] urtwn0: MAC/BB RTL8188EU, RF 6052 1T1R, address e4:fa:c4:52:ac:4c [ 1.770890] urtwn0: 1 rx pipe, 2 tx pipes [ 1.740843] urtwn0 at uhub0 port 1 [ 1.740843] urtwn0: Realtek (0x0bda) 802.11n NIC (0x8179), rev 2.00/0.00, addr 2 [ 1.800940] urtwn0: MAC/BB RTL8188EU, RF 6052 1T1R, address e4:fa:c4:52:ac:4c [ 1.800940] urtwn0: 1 rx pipe, 2 tx pipes netbsd-raspa# netbsd-raspa# ifconfig urtwn0 urtwn0: flags=0x8843 mtu 1500 ssid MiFibra-3422 nwkey 65536:"",0xc8000336c6e2b40b047cd2f5ef44,"","" powersave off bssid 60:8d:26:32:34:24 chan 1 address: e4:fa:c4:52:ac:4c media: IEEE802.11 autoselect (OFDM54 mode 11g) status: active inet6 fe80::e6fa:c4ff:fe52:ac4c%urtwn0/64 flags 0 scopeid 0x1 inet 192.168.1.230/24 broadcast 192.168.1.255 flags 0 netbsd-raspa# I have been downloading many times the same 3.6 GB file from the internet with no failures just for testing. I have made a CVS checkout of the base system source and pkgsrc source fine. Also have watched a 1h 30 m film using minidlna server in VLC over the local network with no failures at all. With bwfm driver that was just impossible. Great work! Regards.
Re: Raspberry Pi Zero W almost useless
El 9/2/24 a las 10:22, Michael van Elst escribió: ea1...@gmail.com (Ramiro Aceves) writes: Oh yes, that would be a right technical fix for the problem but it's a bit of an aberration in terms of cost and size to use a powered HUB with its own power supply to fix a little thing like the ZeroW, you know ;-) RPI0-3 models all have issues with power. Especially on the original RPI1 and RPI0 variants you shouldn't consider USB as being "hot pluggable". For the other models hot-plugging low power USB devices (i.e. using 100mA or less) should be fine. Unfortunately that might rule out things like many gaming keyboards and also some WLAN dongles. Thanks for the explanation Michael.
Re: Raspberry Pi Zero W almost useless
El 9/2/24 a las 15:20, Michael escribió: Hello, On Fri, 9 Feb 2024 06:25:56 +0100 Ramiro Aceves wrote: I have also the same problem that I had with the chineese 8188FTV, as soon I connect it to the raspberry pi it reboots inmediately. In the next reboot it works fine. It occurs the same in another Zero W that I own with Raspbian and a different power supply. So I doubt that the culprit is the power supply. The Zero W seems to be a very flaky device in terms of power supply. A powered hub should fix that, when a device is plugged directly into the raspberry pis usb (IIRC only 300mA is available) it can cause reboots. Oh yes, that would be a right technical fix for the problem but it's a bit of an aberration in terms of cost and size to use a powered HUB with its own power supply to fix a little thing like the ZeroW, you know ;-) Just use the hub to power the Pi. I used to do that wit the Pi1 and 2. have fun Michael It is a good idea, I never thought it could work. Many thanks
Re: Raspberry Pi Zero W almost useless
Hello, On Fri, 9 Feb 2024 06:25:56 +0100 Ramiro Aceves wrote: > >> I have also the same problem that I had with the chineese 8188FTV, as > >> soon I connect it to the raspberry pi it reboots inmediately. In the > >> next reboot it works fine. It occurs the same in another Zero W that I > >> own with Raspbian and a different power supply. So I doubt that the > >> culprit is the power supply. The Zero W seems to be a very flaky device > >> in terms of power supply. > >> > > A powered hub should fix that, when a device is plugged directly into the > > raspberry pis usb (IIRC only 300mA is available) it can cause reboots. > > > > Oh yes, that would be a right technical fix for the problem but it's a > bit of an aberration in terms of cost and size to use a powered HUB with > its own power supply to fix a little thing like the ZeroW, you know ;-) Just use the hub to power the Pi. I used to do that wit the Pi1 and 2. have fun Michael
Re: Raspberry Pi Zero W almost useless
ea1...@gmail.com (Ramiro Aceves) writes: >Oh yes, that would be a right technical fix for the problem but it's a >bit of an aberration in terms of cost and size to use a powered HUB with >its own power supply to fix a little thing like the ZeroW, you know ;-) RPI0-3 models all have issues with power. Especially on the original RPI1 and RPI0 variants you shouldn't consider USB as being "hot pluggable". For the other models hot-plugging low power USB devices (i.e. using 100mA or less) should be fine. Unfortunately that might rule out things like many gaming keyboards and also some WLAN dongles.
Re: Raspberry Pi Zero W almost useless
El 9/2/24 a las 1:41, Nat Sloss escribió: On Fri, 9 Feb 2024 06:05:46 Ramiro Aceves wrote: El 8/2/24 a las 16:48, Nat Sloss escribió: Hi, There's a little more required to add support for the FTV variant judging by changes made to openbsd's if_urtwn.c. There's new firware that needs to be uploaded to the device. And new power on and rssi functions (It seems judging by the changes they've made it some what is similar to the 8188EUS). I'm going to see if I can get one of these adaptors on ebay. I't will be awhile though before I try to get it working. This is best done on the new wifi stack, so I doubt it will get backported to -10. In the meantime if you search for an 8192eu variant that will work with -10 and -9. Best regards, Nat Hello Nat, Thanks for your great explanation, I understand. I then abandon the tests with the 8188FTV and wait for your improvements. They will be appreciated. I cannot fix anything, the driver world seems to be a hell! :-) I have just received today from Amazon a TL-WN725N USB WIFI adaptor and it just work in the raspberry Pi Zero W: [ 1.710793] urtwn0 at uhub0 port 1 [ 1.710793] urtwn0: Realtek (0x0bda) 802.11n NIC (0x8179), rev 2.00/0.00, addr 2 [ 1.770890] urtwn0: MAC/BB RTL8188EU, RF 6052 1T1R, address e4:fa:c4:52:ac:4c [ 1.770890] urtwn0: 1 rx pipe, 2 tx pipes netbsd-raspa# ifconfig urtwn0: flags=0x8843 mtu 1500 ssid MiFibra-3422 nwkey 65536:"",0xc8000336c6e2b40b047cd2f5ef44,"","" powersave off bssid 60:8d:26:32:34:24 chan 1 address: e4:fa:c4:52:ac:4c media: IEEE802.11 autoselect (OFDM54 mode 11g) status: active inet6 fe80::e6fa:c4ff:fe52:ac4c%urtwn0/64 flags 0 scopeid 0x1 inet 192.168.1.230/24 broadcast 192.168.1.255 flags 0 lo0: flags=0x8049 mtu 33176 status: active inet6 ::1/128 flags 0x20 inet6 fe80::1%lo0/64 flags 0 scopeid 0x2 inet 127.0.0.1/8 flags 0 bwfm0: flags=0x8802 mtu 1500 ssid "" nwkey 65536:"","","","" powersave off address: b8:27:eb:ed:85:47 media: IEEE802.11 autoselect status: no network netbsd-raspa# I have also the same problem that I had with the chineese 8188FTV, as soon I connect it to the raspberry pi it reboots inmediately. In the next reboot it works fine. It occurs the same in another Zero W that I own with Raspbian and a different power supply. So I doubt that the culprit is the power supply. The Zero W seems to be a very flaky device in terms of power supply. A powered hub should fix that, when a device is plugged directly into the raspberry pis usb (IIRC only 300mA is available) it can cause reboots. Oh yes, that would be a right technical fix for the problem but it's a bit of an aberration in terms of cost and size to use a powered HUB with its own power supply to fix a little thing like the ZeroW, you know ;-) I am going to test it during several days to see if it works better than the flaky bwfm driver for the built in WIFI. I do not know if I have to disable the bwfm driver to avoid any interaction or I can leave it as is. You shouldn't have to disable bwfm(4) just dont bring up it's interface. Thanks, I will let it as is now. Many thanks for all, I'm learning a lot of things along the way. Regards. Ramiro. Thanks so much. Ramiro. Best regards, Nat
Re: Raspberry Pi Zero W almost useless
On Fri, 9 Feb 2024 06:05:46 Ramiro Aceves wrote: > El 8/2/24 a las 16:48, Nat Sloss escribió: > > Hi, > > > > There's a little more required to add support for the FTV variant judging > > by changes made to openbsd's if_urtwn.c. > > > > There's new firware that needs to be uploaded to the device. And new > > power on and rssi functions (It seems judging by the changes they've > > made it some what is similar to the 8188EUS). > > > > I'm going to see if I can get one of these adaptors on ebay. > > > > I't will be awhile though before I try to get it working. > > > > This is best done on the new wifi stack, so I doubt it will get > > backported to -10. > > > > In the meantime if you search for an 8192eu variant that will work with > > -10 and -9. > > > > Best regards, > > > > Nat > > Hello Nat, > > Thanks for your great explanation, I understand. I then abandon the > tests with the 8188FTV and wait for your improvements. They will be > appreciated. I cannot fix anything, the driver world seems to be a hell! > :-) > > I have just received today from Amazon a TL-WN725N USB WIFI adaptor and > it just work in the raspberry Pi Zero W: > > [ 1.710793] urtwn0 at uhub0 port 1 > [ 1.710793] urtwn0: Realtek (0x0bda) 802.11n NIC (0x8179), rev > 2.00/0.00, addr 2 > [ 1.770890] urtwn0: MAC/BB RTL8188EU, RF 6052 1T1R, address > e4:fa:c4:52:ac:4c > [ 1.770890] urtwn0: 1 rx pipe, 2 tx pipes > > > > netbsd-raspa# ifconfig > urtwn0: flags=0x8843 mtu 1500 > ssid MiFibra-3422 nwkey > 65536:"",0xc8000336c6e2b40b047cd2f5ef44,"","" > powersave off > bssid 60:8d:26:32:34:24 chan 1 > address: e4:fa:c4:52:ac:4c > media: IEEE802.11 autoselect (OFDM54 mode 11g) > status: active > inet6 fe80::e6fa:c4ff:fe52:ac4c%urtwn0/64 flags 0 scopeid 0x1 > inet 192.168.1.230/24 broadcast 192.168.1.255 flags 0 > lo0: flags=0x8049 mtu 33176 > status: active > inet6 ::1/128 flags 0x20 > inet6 fe80::1%lo0/64 flags 0 scopeid 0x2 > inet 127.0.0.1/8 flags 0 > bwfm0: flags=0x8802 mtu 1500 > ssid "" nwkey 65536:"","","","" > powersave off > address: b8:27:eb:ed:85:47 > media: IEEE802.11 autoselect > status: no network > netbsd-raspa# > > I have also the same problem that I had with the chineese 8188FTV, as > soon I connect it to the raspberry pi it reboots inmediately. In the > next reboot it works fine. It occurs the same in another Zero W that I > own with Raspbian and a different power supply. So I doubt that the > culprit is the power supply. The Zero W seems to be a very flaky device > in terms of power supply. > A powered hub should fix that, when a device is plugged directly into the raspberry pis usb (IIRC only 300mA is available) it can cause reboots. > I am going to test it during several days to see if it works better than > the flaky bwfm driver for the built in WIFI. > > I do not know if I have to disable the bwfm driver to avoid any > interaction or I can leave it as is. You shouldn't have to disable bwfm(4) just dont bring up it's interface. > > Thanks so much. > Ramiro. Best regards, Nat
Re: Raspberry Pi Zero W almost useless
El 8/2/24 a las 16:48, Nat Sloss escribió: Hi, There's a little more required to add support for the FTV variant judging by changes made to openbsd's if_urtwn.c. There's new firware that needs to be uploaded to the device. And new power on and rssi functions (It seems judging by the changes they've made it some what is similar to the 8188EUS). I'm going to see if I can get one of these adaptors on ebay. I't will be awhile though before I try to get it working. This is best done on the new wifi stack, so I doubt it will get backported to -10. In the meantime if you search for an 8192eu variant that will work with -10 and -9. Best regards, Nat Hello Nat, Thanks for your great explanation, I understand. I then abandon the tests with the 8188FTV and wait for your improvements. They will be appreciated. I cannot fix anything, the driver world seems to be a hell! :-) I have just received today from Amazon a TL-WN725N USB WIFI adaptor and it just work in the raspberry Pi Zero W: [ 1.710793] urtwn0 at uhub0 port 1 [ 1.710793] urtwn0: Realtek (0x0bda) 802.11n NIC (0x8179), rev 2.00/0.00, addr 2 [ 1.770890] urtwn0: MAC/BB RTL8188EU, RF 6052 1T1R, address e4:fa:c4:52:ac:4c [ 1.770890] urtwn0: 1 rx pipe, 2 tx pipes netbsd-raspa# ifconfig urtwn0: flags=0x8843 mtu 1500 ssid MiFibra-3422 nwkey 65536:"",0xc8000336c6e2b40b047cd2f5ef44,"","" powersave off bssid 60:8d:26:32:34:24 chan 1 address: e4:fa:c4:52:ac:4c media: IEEE802.11 autoselect (OFDM54 mode 11g) status: active inet6 fe80::e6fa:c4ff:fe52:ac4c%urtwn0/64 flags 0 scopeid 0x1 inet 192.168.1.230/24 broadcast 192.168.1.255 flags 0 lo0: flags=0x8049 mtu 33176 status: active inet6 ::1/128 flags 0x20 inet6 fe80::1%lo0/64 flags 0 scopeid 0x2 inet 127.0.0.1/8 flags 0 bwfm0: flags=0x8802 mtu 1500 ssid "" nwkey 65536:"","","","" powersave off address: b8:27:eb:ed:85:47 media: IEEE802.11 autoselect status: no network netbsd-raspa# I have also the same problem that I had with the chineese 8188FTV, as soon I connect it to the raspberry pi it reboots inmediately. In the next reboot it works fine. It occurs the same in another Zero W that I own with Raspbian and a different power supply. So I doubt that the culprit is the power supply. The Zero W seems to be a very flaky device in terms of power supply. I am going to test it during several days to see if it works better than the flaky bwfm driver for the built in WIFI. I do not know if I have to disable the bwfm driver to avoid any interaction or I can leave it as is. Thanks so much. Ramiro.
Re: Raspberry Pi Zero W almost useless
Hi, There's a little more required to add support for the FTV variant judging by changes made to openbsd's if_urtwn.c. There's new firware that needs to be uploaded to the device. And new power on and rssi functions (It seems judging by the changes they've made it some what is similar to the 8188EUS). I'm going to see if I can get one of these adaptors on ebay. I't will be awhile though before I try to get it working. This is best done on the new wifi stack, so I doubt it will get backported to -10. In the meantime if you search for an 8192eu variant that will work with -10 and -9. Best regards, Nat
Re: Raspberry Pi Zero W almost useless
Hello Martin, Thanks so much for the tip! Kernel compilation was ok now I rebooted with the new kernel and I could see the new urtwn0 interface! I wanted to test the interface but I have lost ssh connection (I am at work and the machine is at home, using ethernet driver). netbsd-nuc# ifconfig wm0: flags=0x8843 mtu 1500 capabilities=0x7ff80 capabilities=0x7ff80 capabilities=0x7ff80 enabled=0 ec_capabilities=0x17 ec_enabled=0x2 address: 1c:69:7a:0a:83:9d media: Ethernet autoselect (1000baseT full-duplex,flowcontrol,rxpause,txpause) status: active inet6 fe80::1e69:7aff:fe0a:839d%wm0/64 flags 0 scopeid 0x1 inet 192.168.1.200/24 broadcast 192.168.1.255 flags 0 urtwn0: flags=0x8802 mtu 1500 ssid "" powersave off address: 00:ff:38:30:32:2e media: IEEE802.11 autoselect status: no network lo0: flags=0x8049 mtu 33624 status: active inet6 ::1/128 flags 0x20 inet6 fe80::1%lo0/64 flags 0 scopeid 0x3 inet 127.0.0.1/8 flags 0 netbsd-nuc# ifconfig urtwn0 up ^[[B^[[A I logged in again and: NetBSD 10.0_RC3 (MYKERNEL) #0: Thu Feb 8 13:19:32 CET 2024 Welcome to NetBSD! This is a release candidate for NetBSD. Bug reports: https://www.NetBSD.org/support/send-pr.html Donations to the NetBSD Foundation: https://www.NetBSD.org/donations/ netbsd-nuc$ su Password: netbsd-nuc# ifconfig wm0: flags=0x8843 mtu 1500 capabilities=0x7ff80 capabilities=0x7ff80 capabilities=0x7ff80 enabled=0 ec_capabilities=0x17 ec_enabled=0x2 address: 1c:69:7a:0a:83:9d media: Ethernet autoselect (1000baseT full-duplex,flowcontrol,rxpause,txpause) status: active inet6 fe80::1e69:7aff:fe0a:839d%wm0/64 flags 0 scopeid 0x1 inet 192.168.1.200/24 broadcast 192.168.1.255 flags 0 ^C And it hangs there. Entering again: Welcome to NetBSD! This is a release candidate for NetBSD. Bug reports: https://www.NetBSD.org/support/send-pr.html Donations to the NetBSD Foundation: https://www.NetBSD.org/donations/ netbsd-nuc$ su Password: netbsd-nuc# dmesg | grep urtwn [ 9.228818] urtwn0 at uhub7 port 4 [ 9.228818] urtwn0: Realtek (0x0bda) 802.11n (0xf179), rev 2.00/0.00, addr 14 [ 9.318814] urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R, address 00:ff:38:30:32:2e [ 9.318814] urtwn0: 1 rx pipe, 2 tx pipes [ 576.771445] urtwn0: autoconfiguration error: timeout waiting for firmware readiness [ 616.782378] urtwn0: cannot assign link-local address I will play at home in front of the machine. Thanks! Ramiro El jue, 8 feb 2024 a las 12:33, Martin Husemann () escribió: > > On Thu, Feb 08, 2024 at 12:06:51PM +0100, Ramiro Aceves wrote: > > Hello, > > > > > > I started playing tweaking usbdevs file in the Intel Nuc 8i7BEH > > NetBSD-10_RC3 amd64- I added the line: > > > > product REALTEK RTL8188FTV 0xf179 RTL8188FTV > > You need to regnerate a few files after changes in sys/dev/usbdevs. > Try something like: > > cd src/sys/dev/usb > make -f Makefile.usbdevs USETOOLS=never > > or use nbmake-$arch from $TOOLDIR instead and remove the USETOOLS=... part. > > Martin
Re: Raspberry Pi Zero W almost useless
On Thu, Feb 08, 2024 at 12:06:51PM +0100, Ramiro Aceves wrote: > Hello, > > > I started playing tweaking usbdevs file in the Intel Nuc 8i7BEH > NetBSD-10_RC3 amd64- I added the line: > > product REALTEK RTL8188FTV 0xf179 RTL8188FTV You need to regnerate a few files after changes in sys/dev/usbdevs. Try something like: cd src/sys/dev/usb make -f Makefile.usbdevs USETOOLS=never or use nbmake-$arch from $TOOLDIR instead and remove the USETOOLS=... part. Martin
Re: Raspberry Pi Zero W almost useless
Hello,
I started playing tweaking usbdevs file in the Intel Nuc 8i7BEH
NetBSD-10_RC3 amd64- I added the line:
product REALTEK RTL8188FTV 0xf179 RTL8188FTV
then tried adding a line in if_urtwn.c file just to see what happened:
#define URTWN_DEV(v,p) { { USB_VENDOR_##v, USB_PRODUCT_##v##_##p }, 0 }
#define URTWN_RTL8188E_DEV(v,p) \
{ { USB_VENDOR_##v, USB_PRODUCT_##v##_##p }, FLAG_RTL8188E }
#define URTWN_RTL8192EU_DEV(v,p) \
{ { USB_VENDOR_##v, USB_PRODUCT_##v##_##p }, FLAG_RTL8192E }
static const struct urtwn_dev {
struct usb_devnodev;
uint32_tflags;
#define FLAG_RTL8188E __BIT(0)
#define FLAG_RTL8192E __BIT(1)
} urtwn_devs[] = {
URTWN_DEV(ABOCOM, RTL8188CU_1),
...
...
URTWN_DEV(REALTEK, RTL8188FTV),
...
...
};
#undef URTWN_DEV
#undef URTWN_RTL8188E_DEV
#undef URTWN_RTL8192EU_DEV
...
...
Started kernel compilation and ended with error:
...
...
# compile MYKERNEL/if_urtwn.o
gcc -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -mno-avx
-msoft-float -mindirect-branch=thunk -mindirect-branch-register
-ffreestanding -fno-zero-initialized-in-bss
-fno-delete-null-pointer-checks -g -O2 -fno-omit-frame-pointer
-fstack-protector -Wstack-protector --param ssp-buffer-size=1
-fstack-usage -Wstack-usage=3584 -fno-strict-aliasing -fno-common
-std=gnu99 -Werror -Wall -Wno-main -Wno-format-zero-length
-Wpointer-arith -Wmissing-prototypes -Wstrict-prototypes
-Wold-style-definition -Wswitch -Wshadow -Wcast-qual -Wwrite-strings
-Wno-unreachable-code -Wno-pointer-sign -Wno-attributes
-Wno-type-limits -Wextra -Wno-unused-parameter -Wold-style-definition
-Wno-sign-compare -Walloca -Wno-address-of-packed-member -Damd64
-Dx86_64 -I. -I../../../../external/mit/xen-include-public/dist/
-I../../../../external/bsd/libnv/dist
-I../../../../external/bsd/acpica/dist
-I../../../../../common/lib/libx86emu
-I../../../../../common/lib/libc/misc -I../../../../../common/include
-I../../../../arch -I../../../.. -nostdinc -DCOMPAT_UTILS
-D__XEN_INTERFACE_VERSION__=0x3020a -DCOMPAT_44 -D_KERNEL
-D_KERNEL_OPT -std=gnu99
-I../../../../lib/libkern/../../../common/lib/libc/quad
-I../../../../lib/libkern/../../../common/lib/libc/string
-I../../../../lib/libkern/../../../common/lib/libc/arch/x86_64/string
-I../../../../lib/libkern/../../../common/lib/libc/arch/x86_64/atomic
-I../../../../lib/libkern/../../../common/lib/libc/hash/sha3
-D_FORTIFY_SOURCE=2 -I../../../../external/isc/atheros_hal/dist
-I../../../../external/isc/atheros_hal/ic
-I../../../../../common/include
-I../../../../external/bsd/acpica/dist/include
-I../../../../external/bsd/libnv/dist -c
../../../../dev/usb/if_urtwn.c -o if_urtwn.o
../../../../dev/usb/if_urtwn.c:122:44: error:
'USB_PRODUCT_REALTEK_RTL8188FTV' undeclared here (not in a function);
did you mean 'USB_PRODUCT_REALTEK_RTL8188CTV'?
122 | #define URTWN_DEV(v,p) { { USB_VENDOR_##v, USB_PRODUCT_##v##_##p }, 0 }
|^~~~
../../../../dev/usb/if_urtwn.c:187:2: note: in expansion of macro 'URTWN_DEV'
187 | URTWN_DEV(REALTEK, RTL8188FTV),
| ^
../../../../dev/usb/if_urtwn.c:187:2: error: missing initializer for
field 'ud_product' of 'struct usb_devno'
[-Werror=missing-field-initializers]
In file included from ../../../../dev/usb/if_urtwn.c:72:
../../../../dev/usb/usbdi.h:234:11: note: 'ud_product' declared here
234 | uint16_t ud_product;
| ^~
cc1: all warnings being treated as errors
*** Error code 1
Stop.
make: stopped in /usr/src/sys/arch/amd64/compile/MYKERNEL
303.39 real 258.65 user27.95 sys
netbsd-nuc#
soon realized that usbdevs.h file was not automatically updated as I
thought and I did not found the #define line of the chip I added in
usbdevs file.
Reading usbdevs.h said that make -f Makefile.usbdevs should be executed:
netbsd-nuc# cd /usr/src/sys/dev/usb
netbsd-nuc# make -f Makefile.usbdevs
/bin/rm -f usbdevs.h usbdevs_data.h
/usr/src/tooldir.NetBSD-10.0_RC3-amd64/bin/nbawk -f
/usr/src/sys/dev/usb/../devlist2h.awk usbdevs
make: exec(/usr/src/tooldir.NetBSD-10.0_RC3-amd64/bin/nbawk) failed
(No such file or directory)
*** Error code 1
Stop.
make: stopped in /usr/src/sys/dev/usb
netbsd-nuc#
I am stuck now. Perhaps should I build everything, userland and
kernel? I think I am missing many things :-(
Thanks.
Ramiro.
El mié, 7 feb 2024 a las 19:21, Rhialto () escribió:
>
> On Wed 07 Feb 2024 at 10:44:04 +0100, Ramiro Aceves wrote:
> > The problem is to change /usr/src/dev/usb/if_urtwn.c without knowing
> > what I am exactly doing ;-)
>
> I don't know either, but I spot a list of these USB ids (starting with
>
> } urtwn_devs[] = {
> URTWN_DEV(ABOCOM, RTL8188CU_1),
> URTWN_DEV(ABOCOM, RTL8188CU_2),
> ). You could add yours to the list (it has 3 parts so maybe you have to
> apply some guesswork in which part it fits best). If you're lucky and
> your interface isn't
Re: Raspberry Pi Zero W almost useless
On Wed 07 Feb 2024 at 10:44:04 +0100, Ramiro Aceves wrote:
> The problem is to change /usr/src/dev/usb/if_urtwn.c without knowing
> what I am exactly doing ;-)
I don't know either, but I spot a list of these USB ids (starting with
} urtwn_devs[] = {
URTWN_DEV(ABOCOM, RTL8188CU_1),
URTWN_DEV(ABOCOM, RTL8188CU_2),
). You could add yours to the list (it has 3 parts so maybe you have to
apply some guesswork in which part it fits best). If you're lucky and
your interface isn't too different from the others, then it might work.
> Ramiro
-Olaf.
--
___ Olaf 'Rhialto' Seibert
\X/ There is no AI. There is just someone else's work. --I. Rose
signature.asc
Description: PGP signature
Re: Raspberry Pi Zero W almost useless
Try adding product AB0COM RTL8188FTV 0xf179 RTL8188EU to /usr/src/sys/dev/usb/usbdevs It might work, you have nothing to lose. If not RTL8188EU then RTL8188CU Sent with Proton Mail secure email. On Wednesday, February 7th, 2024 at 3:44 AM, Ramiro Aceves wrote: > Hello Lwazi, > > Thanks for the tip. I know how to recompile a kernel but I doubt I > could do such modification in the source with chances of success > without knowing the internals of driver programming. ;-) Only know the > basics of C. > > I have been watching /usr/src/dev/usb/usbdevs and it seems easy to > change. Then it says that usbdevs.h will be regenerated automatically. > > I believe that I have to add the following line with the RTL8188FTV > product ID (Realtek vendor ID is ok in the usbdevs file): > > product REALTEK RTL8188FTV 0xf179 Realtek RTL8188FTV > > The problem is to change /usr/src/dev/usb/if_urtwn.c without knowing > what I am exactly doing ;-) > > Another thing I am thinking about is the firmware... > > Too few chances of success, I think. > > > Thanks. > Ramiro > > El mar, 6 feb 2024 a las 19:27, Lwazi Dube (lwa...@gmail.com) escribió: > > > On Mon, 5 Feb 2024 at 06:51, Ramiro Aceves ea1...@gmail.com wrote: > > > > > Hello, > > > I bought two of other seller, rtl8188 but I think it is not supported
Re: Raspberry Pi Zero W almost useless
Hello Lwazi, Thanks for the tip. I know how to recompile a kernel but I doubt I could do such modification in the source with chances of success without knowing the internals of driver programming. ;-) Only know the basics of C. I have been watching /usr/src/dev/usb/usbdevs and it seems easy to change. Then it says that usbdevs.h will be regenerated automatically. I believe that I have to add the following line with the RTL8188FTV product ID (Realtek vendor ID is ok in the usbdevs file): product REALTEK RTL8188FTV 0xf179 Realtek RTL8188FTV The problem is to change /usr/src/dev/usb/if_urtwn.c without knowing what I am exactly doing ;-) Another thing I am thinking about is the firmware... Too few chances of success, I think. Thanks. Ramiro El mar, 6 feb 2024 a las 19:27, Lwazi Dube () escribió: > > On Mon, 5 Feb 2024 at 06:51, Ramiro Aceves wrote: >> >> >> Hello, >> I bought two of other seller, rtl8188 but I think it is not supported. >> I have two problems. As soon as I connect it the raspberry inmediatly >> reboots. I think it has something to do with some inrush current. In >> raspbian also it reboots inmediatley. >> >> Once the system reboots, it finds the dongle but cannot be configured: >> Feb 4 21:58:55 netbsd-raspa /netbsd: [ 1.7408840] ugen0 at uhub0 port 1 >> Feb 4 21:58:55 netbsd-raspa /netbsd: [ 1.7408840] ugen0: Realtek >> (0x0bda) 802.11n (0xf179), rev 2.00/0.00, addr 2 >> Feb 4 21:58:55 netbsd-raspa /netbsd: [ 1.7408840] uhub0: >> autoconfiguration error: illegal enable change, port 1 >> Feb 4 21:58:55 netbsd-raspa /netbsd: [ 1.7408840] swwdog0: software >> watchdog initialized >> Feb 4 21:58:55 netbsd-raspa /netbsd: [ 1.7609300] WARNING: 1 error >> while detecting hardware; check system log. >> >> I have googled and perhaps it is rtl8188FTV, I think it is not >> supported by the driver. >> > The RTL8188FTV product id seems to be missing in usbdevs and if_urtwn.c. You > need to add the id and rebuild the kernel before you test.
Re: Raspberry Pi Zero W almost useless
On Mon, 5 Feb 2024 at 06:51, Ramiro Aceves wrote: > > Hello, > I bought two of other seller, rtl8188 but I think it is not supported. > I have two problems. As soon as I connect it the raspberry inmediatly > reboots. I think it has something to do with some inrush current. In > raspbian also it reboots inmediatley. > > Once the system reboots, it finds the dongle but cannot be configured: > Feb 4 21:58:55 netbsd-raspa /netbsd: [ 1.7408840] ugen0 at uhub0 port 1 > Feb 4 21:58:55 netbsd-raspa /netbsd: [ 1.7408840] ugen0: Realtek > (0x0bda) 802.11n (0xf179), rev 2.00/0.00, addr 2 > Feb 4 21:58:55 netbsd-raspa /netbsd: [ 1.7408840] uhub0: > autoconfiguration error: illegal enable change, port 1 > Feb 4 21:58:55 netbsd-raspa /netbsd: [ 1.7408840] swwdog0: software > watchdog initialized > Feb 4 21:58:55 netbsd-raspa /netbsd: [ 1.7609300] WARNING: 1 error > while detecting hardware; check system log. > > I have googled and perhaps it is rtl8188FTV, I think it is not > supported by the driver. > > The RTL8188FTV product id seems to be missing in usbdevs and if_urtwn.c. You need to add the id and rebuild the kernel before you test.
Re: Raspberry Pi Zero W almost useless
El jue, 25 ene 2024 a las 11:28, Matthew Widup () escribió: > > I use one of these > https://www.ebay.com/itm/113774031117?mkcid=16=1=711-127632-2357-0=HZuLHORZQWm=4429486=rkGEi8qyQi6=_ver=artemis=COPY > > which is nearly as small as possible, and ridiculously cheap. I don't > normally advocate buying cheap things. > > Granted I don't use it with a Pi. I use it with my Pinebook Pro (actually > multiples of them). But it should work for the Pi just the same. > Hello, I bought two of other seller, rtl8188 but I think it is not supported. I have two problems. As soon as I connect it the raspberry inmediatly reboots. I think it has something to do with some inrush current. In raspbian also it reboots inmediatley. Once the system reboots, it finds the dongle but cannot be configured: Feb 4 21:58:55 netbsd-raspa /netbsd: [ 1.2002810] ld0: 60874 MB, 7760 cyl, 255 head, 63 sec, 512 bytes/sect x 124669952 sectors Feb 4 21:58:55 netbsd-raspa /netbsd: [ 1.2002810] ld0: 4-bit width, High-Speed/SDR25, 50.000 MHz Feb 4 21:58:55 netbsd-raspa /netbsd: [ 1.3004040] sdmmc1: 4-bit width, 50.000 MHz Feb 4 21:58:55 netbsd-raspa /netbsd: [ 1.3004040] bwfm0 at sdmmc1 function 1 Feb 4 21:58:55 netbsd-raspa /netbsd: [ 1.3104370] (manufacturer 0x2d0, product 0xa9a6) at sdmmc1 function 2 not configured Feb 4 21:58:55 netbsd-raspa /netbsd: [ 1.7408840] ugen0 at uhub0 port 1 Feb 4 21:58:55 netbsd-raspa /netbsd: [ 1.7408840] ugen0: Realtek (0x0bda) 802.11n (0xf179), rev 2.00/0.00, addr 2 Feb 4 21:58:55 netbsd-raspa /netbsd: [ 1.7408840] uhub0: autoconfiguration error: illegal enable change, port 1 Feb 4 21:58:55 netbsd-raspa /netbsd: [ 1.7408840] swwdog0: software watchdog initialized Feb 4 21:58:55 netbsd-raspa /netbsd: [ 1.7609300] WARNING: 1 error while detecting hardware; check system log. I have googled and perhaps it is rtl8188FTV, I think it is not supported by the driver. Thanks.
Re: Raspberry Pi Zero W almost useless
Hello again: El 27/1/24 a las 13:29, Bartek Krawczyk escribió: On 25.01.2024 11:05, Ramiro Aceves wrote: I see that WIFI bwfm driver works the same as bad as in 10.0_RC1. I have read that WIFI drivers are not very stable but I do not know whether what I am experiencing is normal or not. My system is doing nearly "nothing", at 30 minutes interval cron runs a wget command to download a little 2 byte file from https://ipv4.cloudns.net/ just to inform the DDNS system of my actual IP address. From time to time I loose network and I cannot longer have ssh access. In order to overcome that, I wrote a service that reboots the operating system when network does not work (better than nothing). The service registers in a file the uptime just before issuing the reboot command: Earlier I experienced the same on a Raspberry PI 3 however not sure if it was as often as every 30mins. https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=57308 Hi again. I have tried to restart wpa_supplicant service but it does not resurrect network. "bwfm: could not set mpc" message goes out of the kernel. I have transcribed manually the information on the TV screen: netbsd-raspa# service wpa_supplicant restart Stopping wpa_supplicant. Jan 17 16:15:17 netbsd-raspa wpa_supplicant[293]: ioctl[SIOCS80211, op=20, val=0, arg_len=7]: Can't assign requested address Starting wpa_supplicant. netbsd-raspa#Jan 27 16:15:08 netbsd-raspa wpa_supplicant[1304]: ioctl[SIOCG80211, op=16, arg_len=0:Inappropiate ioctl for device. [687.4366422] bwfm: could not set mpc Thanks Ramiro.
Re: Raspberry Pi Zero W almost useless
El 27/1/24 a las 13:29, Bartek Krawczyk escribió: On 25.01.2024 11:05, Ramiro Aceves wrote: I see that WIFI bwfm driver works the same as bad as in 10.0_RC1. I have read that WIFI drivers are not very stable but I do not know whether what I am experiencing is normal or not. My system is doing nearly "nothing", at 30 minutes interval cron runs a wget command to download a little 2 byte file from https://ipv4.cloudns.net/ just to inform the DDNS system of my actual IP address. From time to time I loose network and I cannot longer have ssh access. In order to overcome that, I wrote a service that reboots the operating system when network does not work (better than nothing). The service registers in a file the uptime just before issuing the reboot command: Earlier I experienced the same on a Raspberry PI 3 however not sure if it was as often as every 30mins. https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=57308 Thanks Bartek for the tips. Here I do not use dhcpcd, I use static IP address. I think in the past I tried to reload wpasupplicant service with no luck but I do not remember well. I think I can try it know. I am going to try "service wpa_supplicant restart" trick and see what happens. Ramiro.
Re: Raspberry Pi Zero W almost useless
On 25.01.2024 11:05, Ramiro Aceves wrote: I see that WIFI bwfm driver works the same as bad as in 10.0_RC1. I have read that WIFI drivers are not very stable but I do not know whether what I am experiencing is normal or not. My system is doing nearly "nothing", at 30 minutes interval cron runs a wget command to download a little 2 byte file from https://ipv4.cloudns.net/ just to inform the DDNS system of my actual IP address. From time to time I loose network and I cannot longer have ssh access. In order to overcome that, I wrote a service that reboots the operating system when network does not work (better than nothing). The service registers in a file the uptime just before issuing the reboot command: Earlier I experienced the same on a Raspberry PI 3 however not sure if it was as often as every 30mins. https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=57308 -- Regards Bartłomiej Krawczyk
Re: Raspberry Pi Zero W almost useless
El 25/1/24 a las 11:28, Matthew Widup escribió: I use one of these https://www.ebay.com/itm/113774031117?mkcid=16=1=711-127632-2357-0=HZuLHORZQWm=4429486=rkGEi8qyQi6=_ver=artemis=COPY which is nearly as small as possible, and ridiculously cheap. I don't normally advocate buying cheap things. Granted I don't use it with a Pi. I use it with my Pinebook Pro (actually multiples of them). But it should work for the Pi just the same. Hello Matthew, Thanks for the suggested wifi interface. I have ordered two of them (from another seller with lower shipping charges) and we'll see what happens. They are so cheap that I think it makes sense to try. The only problem is that Zero W has only 1 USB port and I will not be able to connect a keyboard at the same time. I normally do not use the keyboard, I think I will be able to do config it. Thanks so much. Ramiro. Sent with Proton Mail secure email. On Thursday, January 25th, 2024 at 4:05 AM, Ramiro Aceves wrote: Hello, I have upgraded my raspberry pi Zero W board operating system to NetBSD-10.0_RC3 using sysupgrade for the sets. Previously I manually upgraded the kernel, firmware and dtbs (a bit tricky). No problem at all with that, but do you know if there are plans in the future to do kernel, dtb and firmware easier upgrades without having to vndconfig the installation image, mounting it and copy manually the files? Just curious... I see that WIFI bwfm driver works the same as bad as in 10.0_RC1. I have read that WIFI drivers are not very stable but I do not know whether what I am experiencing is normal or not. My system is doing nearly "nothing", at 30 minutes interval cron runs a wget command to download a little 2 byte file from https://ipv4.cloudns.net/ just to inform the DDNS system of my actual IP address. From time to time I loose network and I cannot longer have ssh access. In order to overcome that, I wrote a service that reboots the operating system when network does not work (better than nothing). The service registers in a file the uptime just before issuing the reboot command: netbsd-raspa# cat /root/network_conn_test.log |grep day 4:01AM up 3 days, 12:10, 0 users, load averages: 0.00, 0.00, 0.00 12:43PM up 4 days, 23:43, 1 user, load averages: 1.00, 1.00, 0.91 4:01AM up 1 day, 15:18, 0 users, load averages: 0.00, 0.00, 0.00 11:28AM up 1 day, 7:27, 1 user, load averages: 0.24, 0.32, 0.16 2:01AM up 2 days, 22:33, 0 users, load averages: 0.00, 0.02, 0.00 3:01AM up 1 day, 1 hr, 0 users, load averages: 0.03, 0.05, 0.02 5:01AM up 2 days, 2 hrs, 0 users, load averages: 0.00, 0.00, 0.00 2:01AM up 2 days, 20:59, 0 users, load averages: 0.00, 0.00, 0.00 2:01AM up 1 day, 0 users, load averages: 0.00, 0.00, 0.00 5:01AM up 4 days, 2:59, 0 users, load averages: 0.00, 0.00, 0.04 5:02AM up 2 days, 0 users, load averages: 0.00, 0.00, 0.00 2:43PM up 1 day, 9:41, 0 users, load averages: 0.02, 0.05, 0.02 4:01AM up 2 days, 10:57, 0 users, load averages: 0.00, 0.00, 0.00 9:25AM up 1 day, 5:23, 0 users, load averages: 0.08, 0.11, 0.05 4:01AM up 3 days, 11:27, 0 users, load averages: 0.00, 0.00, 0.00 2:01AM up 2 days, 22 hrs, 0 users, load averages: 0.00, 0.00, 0.00 5:01AM up 2 days, 3 hrs, 0 users, load averages: 0.00, 0.00, 0.00 12:01PM up 1 day, 7:49, 1 user, load averages: 0.10, 0.14, 0.13 System do not last more than 4 days without loosing network. Sometimes it breaks in a few minutes: netbsd-raspa# cat /root/network_conn_test.log |grep min 3:28AM up 2 mins, 0 users, load averages: 0.38, 0.24, 0.10 9:30AM up 5 mins, 1 user, load averages: 0.03, 0.08, 0.04 12:18PM up 49 mins, 0 users, load averages: 0.00, 0.00, 0.00 4:11AM up 2 mins, 0 users, load averages: 0.20, 0.16, 0.07 12:04PM up 3 mins, 1 user, load averages: 0.23, 0.21, 0.09 1:28PM up 20 mins, 1 user, load averages: 0.22, 0.40, 0.25 netbsd-raspa# It is difficult to download big files from the internet. If you try to download a for example 1 GB file, it is very probable that it breaks before 1/3 of the file transfer. That can be solved using wget -c option but it is very annoying. It is very difficult to find a useful task for this board using NetBSD. For example I would like to setup a minidlna server to watch films but I have done that and it breaks after a few minutes. If you setup a lighttpd WEB server it will be anoying for the user if it reboots on the middle of WEB surfing... I do not see anything useful in dmesg. Only the messages that follow the forced reboot issued by mi service: ... ... [ 1.410723] bwfm0: Found NVRAM file: brcmfmac43430-sdio.raspberrypi,model-zero-w.txt [ 1.410723] bwfm0: CLM file default: brcmfmac43430-sdio.clm_blob [ 1.410723] bwfm0: CLM file model-spec: brcmfmac43430-sdio.raspberrypi,model-zero-w.clm_blob [ 3.132473] bwfm0: CHIPACTIVE [ 3.232559] bwfm0: address b8:27:eb:ed:85:47 [ 3.232559] bwfm0: wl0: Oct 23 2017 03:55:53 version 7.45.98.38 (r674442 CY) FWID 01-e58d219f [ 14.405464] wsdisplay0: screen 4 added (default, vt100 emulation) [
Re: Raspberry Pi Zero W almost useless
I use one of these https://www.ebay.com/itm/113774031117?mkcid=16=1=711-127632-2357-0=HZuLHORZQWm=4429486=rkGEi8qyQi6=_ver=artemis=COPY which is nearly as small as possible, and ridiculously cheap. I don't normally advocate buying cheap things. Granted I don't use it with a Pi. I use it with my Pinebook Pro (actually multiples of them). But it should work for the Pi just the same. Sent with Proton Mail secure email. On Thursday, January 25th, 2024 at 4:05 AM, Ramiro Aceves wrote: > Hello, > > I have upgraded my raspberry pi Zero W board operating system to > NetBSD-10.0_RC3 using sysupgrade for the sets. Previously I manually > upgraded the kernel, firmware and dtbs (a bit tricky). No problem at > all with that, but do you know if there are plans in the future to do > kernel, dtb and firmware easier upgrades without having to vndconfig > the installation image, mounting it and copy manually the files? Just > curious... > > > I see that WIFI bwfm driver works the same as bad as in 10.0_RC1. I > have read that WIFI drivers are not very stable but I do not know > whether what I am experiencing is normal or not. My system is doing > nearly "nothing", at 30 minutes interval cron runs a wget command to > download a little 2 byte file from https://ipv4.cloudns.net/ just to > inform the DDNS system of my actual IP address. From time to time I > loose network and I cannot longer have ssh access. In order to > overcome that, I wrote a service that reboots the operating system > when network does not work (better than nothing). The service > registers in a file the uptime just before issuing the reboot command: > > netbsd-raspa# cat /root/network_conn_test.log |grep day > > 4:01AM up 3 days, 12:10, 0 users, load averages: 0.00, 0.00, 0.00 > 12:43PM up 4 days, 23:43, 1 user, load averages: 1.00, 1.00, 0.91 > 4:01AM up 1 day, 15:18, 0 users, load averages: 0.00, 0.00, 0.00 > 11:28AM up 1 day, 7:27, 1 user, load averages: 0.24, 0.32, 0.16 > 2:01AM up 2 days, 22:33, 0 users, load averages: 0.00, 0.02, 0.00 > 3:01AM up 1 day, 1 hr, 0 users, load averages: 0.03, 0.05, 0.02 > 5:01AM up 2 days, 2 hrs, 0 users, load averages: 0.00, 0.00, 0.00 > 2:01AM up 2 days, 20:59, 0 users, load averages: 0.00, 0.00, 0.00 > 2:01AM up 1 day, 0 users, load averages: 0.00, 0.00, 0.00 > 5:01AM up 4 days, 2:59, 0 users, load averages: 0.00, 0.00, 0.04 > 5:02AM up 2 days, 0 users, load averages: 0.00, 0.00, 0.00 > 2:43PM up 1 day, 9:41, 0 users, load averages: 0.02, 0.05, 0.02 > 4:01AM up 2 days, 10:57, 0 users, load averages: 0.00, 0.00, 0.00 > 9:25AM up 1 day, 5:23, 0 users, load averages: 0.08, 0.11, 0.05 > 4:01AM up 3 days, 11:27, 0 users, load averages: 0.00, 0.00, 0.00 > 2:01AM up 2 days, 22 hrs, 0 users, load averages: 0.00, 0.00, 0.00 > 5:01AM up 2 days, 3 hrs, 0 users, load averages: 0.00, 0.00, 0.00 > 12:01PM up 1 day, 7:49, 1 user, load averages: 0.10, 0.14, 0.13 > > System do not last more than 4 days without loosing network. Sometimes > it breaks in a few minutes: > > netbsd-raspa# cat /root/network_conn_test.log |grep min > 3:28AM up 2 mins, 0 users, load averages: 0.38, 0.24, 0.10 > 9:30AM up 5 mins, 1 user, load averages: 0.03, 0.08, 0.04 > 12:18PM up 49 mins, 0 users, load averages: 0.00, 0.00, 0.00 > 4:11AM up 2 mins, 0 users, load averages: 0.20, 0.16, 0.07 > 12:04PM up 3 mins, 1 user, load averages: 0.23, 0.21, 0.09 > 1:28PM up 20 mins, 1 user, load averages: 0.22, 0.40, 0.25 > netbsd-raspa# > > > It is difficult to download big files from the internet. If you try to > download a for example 1 GB file, it is very probable that it breaks > before 1/3 of the file transfer. That can be solved using wget -c > option but it is very annoying. > > It is very difficult to find a useful task for this board using > NetBSD. For example I would like to setup a minidlna server to watch > films but I have done that and it breaks after a few minutes. If you > setup a lighttpd WEB server it will be anoying for the user if it > reboots on the middle of WEB surfing... > > I do not see anything useful in dmesg. Only the messages that follow > the forced reboot issued by mi service: > > ... > ... > > [ 1.410723] bwfm0: Found NVRAM file: > brcmfmac43430-sdio.raspberrypi,model-zero-w.txt > [ 1.410723] bwfm0: CLM file default: brcmfmac43430-sdio.clm_blob > [ 1.410723] bwfm0: CLM file model-spec: > brcmfmac43430-sdio.raspberrypi,model-zero-w.clm_blob > [ 3.132473] bwfm0: CHIPACTIVE > [ 3.232559] bwfm0: address b8:27:eb:ed:85:47 > [ 3.232559] bwfm0: wl0: Oct 23 2017 03:55:53 version 7.45.98.38 > (r674442 CY) FWID 01-e58d219f > [ 14.405464] wsdisplay0: screen 4 added (default, vt100 emulation) > [ 1197.386358] syncing disks... done > [ 1197.436478] unmounting file systems... > [ 1197.436478] unmounted tmpfs on /var/shm type tmpfs > [ 1197.436478] unmounted procfs on /proc type procfs > [ 1197.436478] unmounted ptyfs on /dev/pts type ptyfs > [ 1197.436478] unmounted /dev/ld0e on /boot type msdos > [ 1.00] Copyright (c)
Re: Raspberry Pi Zero W almost useless
On Thu, Jan 25, 2024 at 11:06 AM Ramiro Aceves wrote: > I see that WIFI bwfm driver works the same as bad as in 10.0_RC1. I > have read that WIFI drivers are not very stable but I do not know > whether what I am experiencing is normal or not. I never had any luck with bwfm Wi-Fi on NetBSD, unfortunately. The PineBook Pro is just the same. I bought a cheap USB Wi-Fi to use instead, and that works well. The symptom I get with bwfm is: either it stops receiving data after a while, or the system locks up hard. Not great. -- Benny
Raspberry Pi Zero W almost useless
Hello, I have upgraded my raspberry pi Zero W board operating system to NetBSD-10.0_RC3 using sysupgrade for the sets. Previously I manually upgraded the kernel, firmware and dtbs (a bit tricky). No problem at all with that, but do you know if there are plans in the future to do kernel, dtb and firmware easier upgrades without having to vndconfig the installation image, mounting it and copy manually the files? Just curious... I see that WIFI bwfm driver works the same as bad as in 10.0_RC1. I have read that WIFI drivers are not very stable but I do not know whether what I am experiencing is normal or not. My system is doing nearly "nothing", at 30 minutes interval cron runs a wget command to download a little 2 byte file from https://ipv4.cloudns.net/ just to inform the DDNS system of my actual IP address. From time to time I loose network and I cannot longer have ssh access. In order to overcome that, I wrote a service that reboots the operating system when network does not work (better than nothing). The service registers in a file the uptime just before issuing the reboot command: netbsd-raspa# cat /root/network_conn_test.log |grep day 4:01AM up 3 days, 12:10, 0 users, load averages: 0.00, 0.00, 0.00 12:43PM up 4 days, 23:43, 1 user, load averages: 1.00, 1.00, 0.91 4:01AM up 1 day, 15:18, 0 users, load averages: 0.00, 0.00, 0.00 11:28AM up 1 day, 7:27, 1 user, load averages: 0.24, 0.32, 0.16 2:01AM up 2 days, 22:33, 0 users, load averages: 0.00, 0.02, 0.00 3:01AM up 1 day, 1 hr, 0 users, load averages: 0.03, 0.05, 0.02 5:01AM up 2 days, 2 hrs, 0 users, load averages: 0.00, 0.00, 0.00 2:01AM up 2 days, 20:59, 0 users, load averages: 0.00, 0.00, 0.00 2:01AM up 1 day, 0 users, load averages: 0.00, 0.00, 0.00 5:01AM up 4 days, 2:59, 0 users, load averages: 0.00, 0.00, 0.04 5:02AM up 2 days, 0 users, load averages: 0.00, 0.00, 0.00 2:43PM up 1 day, 9:41, 0 users, load averages: 0.02, 0.05, 0.02 4:01AM up 2 days, 10:57, 0 users, load averages: 0.00, 0.00, 0.00 9:25AM up 1 day, 5:23, 0 users, load averages: 0.08, 0.11, 0.05 4:01AM up 3 days, 11:27, 0 users, load averages: 0.00, 0.00, 0.00 2:01AM up 2 days, 22 hrs, 0 users, load averages: 0.00, 0.00, 0.00 5:01AM up 2 days, 3 hrs, 0 users, load averages: 0.00, 0.00, 0.00 12:01PM up 1 day, 7:49, 1 user, load averages: 0.10, 0.14, 0.13 System do not last more than 4 days without loosing network. Sometimes it breaks in a few minutes: netbsd-raspa# cat /root/network_conn_test.log |grep min 3:28AM up 2 mins, 0 users, load averages: 0.38, 0.24, 0.10 9:30AM up 5 mins, 1 user, load averages: 0.03, 0.08, 0.04 12:18PM up 49 mins, 0 users, load averages: 0.00, 0.00, 0.00 4:11AM up 2 mins, 0 users, load averages: 0.20, 0.16, 0.07 12:04PM up 3 mins, 1 user, load averages: 0.23, 0.21, 0.09 1:28PM up 20 mins, 1 user, load averages: 0.22, 0.40, 0.25 netbsd-raspa# It is difficult to download big files from the internet. If you try to download a for example 1 GB file, it is very probable that it breaks before 1/3 of the file transfer. That can be solved using wget -c option but it is very annoying. It is very difficult to find a useful task for this board using NetBSD. For example I would like to setup a minidlna server to watch films but I have done that and it breaks after a few minutes. If you setup a lighttpd WEB server it will be anoying for the user if it reboots on the middle of WEB surfing... I do not see anything useful in dmesg. Only the messages that follow the forced reboot issued by mi service: ... ... [ 1.410723] bwfm0: Found NVRAM file: brcmfmac43430-sdio.raspberrypi,model-zero-w.txt [ 1.410723] bwfm0: CLM file default:brcmfmac43430-sdio.clm_blob [ 1.410723] bwfm0: CLM file model-spec: brcmfmac43430-sdio.raspberrypi,model-zero-w.clm_blob [ 3.132473] bwfm0: CHIPACTIVE [ 3.232559] bwfm0: address b8:27:eb:ed:85:47 [ 3.232559] bwfm0: wl0: Oct 23 2017 03:55:53 version 7.45.98.38 (r674442 CY) FWID 01-e58d219f [14.405464] wsdisplay0: screen 4 added (default, vt100 emulation) [ 1197.386358] syncing disks... done [ 1197.436478] unmounting file systems... [ 1197.436478] unmounted tmpfs on /var/shm type tmpfs [ 1197.436478] unmounted procfs on /proc type procfs [ 1197.436478] unmounted ptyfs on /dev/pts type ptyfs [ 1197.436478] unmounted /dev/ld0e on /boot type msdos [ 1.00] Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, [ 1.00] 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, [ 1.00] 2014, 2015, 2016, 2017, 2018, 2019, 2020, 2021, 2022, 2023, [ 1.00] 2024 [ 1.00] The NetBSD Foundation, Inc. All rights reserved. [ 1.00] Copyright (c) 1982, 1986, 1989, 1991, 1993 [ 1.00] The Regents of the University of California. All rights reserved. [ 1.00] NetBSD 10.0_RC3 (RPI) #0: Tue Jan 16 08:28:51 UTC 2024 [ 1.00]
