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: RC4 still gives me trouble with i915
On 08/02/2024 16:08, Jörn Clausen wrote: Hello! For the last RCs, I've tested the live image for amd64 on my desktop machine, that has been running 9.x with X for years now. Whenever I start X11, either via "startx" or "/etc/rc.d/xdm onestart", the display gets unusable. I see fragments of ctwm and an Xterm in the first case, and parts of the login display in the second, but the sessions are otherwise broken. Is this expected behaviour with the live image, or should the correct configuration get picked up? I see no warning in the Xorg.log, everything seems to get detected fine. Please let me know if someone needs debug information beyond the following: The CPU is cpu0: "Intel(R) Celeron(R) CPU J1900 @ 1.99GHz" cpu0: Intel Atom E3000, Z3[67]00 (686-class), 2000.22 MHz cpu0: family 0x6 model 0x37 stepping 0x8 (id 0x30678) These are some parts from the messages log: [ 5.009976] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 5.009976] [drm] Driver supports precise vblank timestamp query. [ 5.009976] i915drmkms0: interrupting at msi4 vec 0 (i915drmkms0) [ 5.079724] [drm] Initialized i915 1.6.0 20200114 for i915drmkms0 on minor 0 [ 5.099724] intelfb0 at i915drmkms0 [ 5.099724] [drm] DRM_I915_DEBUG enabled [ 5.099724] [drm] DRM_I915_DEBUG_GEM enabled [ 5.099724] intelfb0: framebuffer at 0xc002, size 1280x1024, depth 32, stride 5120 I had a similar problem but the fix that resolved it for me went in just before RC3 so RC4 should have it. However I do know it didn't fix the issue for everyone as it depends just exactly what Intel display chip you have. If you can grap the /var/log/Xorg.log output that often identifies the chip. Mine for example says: [361580.187] (II) intel(0): SNA initialized with Haswell (gen7.5, gt2) backend This is with the intel driver. The modesetting driver which is the alternative is less helpful in this respect. Mike
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
RC4 still gives me trouble with i915
Hello!
For the last RCs, I've tested the live image for amd64 on my desktop
machine, that has been running 9.x with X for years now. Whenever I start
X11, either via "startx" or "/etc/rc.d/xdm onestart", the display gets
unusable. I see fragments of ctwm and an Xterm in the first case, and parts
of the login display in the second, but the sessions are otherwise broken.
Is this expected behaviour with the live image, or should the correct
configuration get picked up? I see no warning in the Xorg.log, everything
seems to get detected fine. Please let me know if someone needs debug
information beyond the following:
The CPU is
cpu0: "Intel(R) Celeron(R) CPU J1900 @ 1.99GHz"
cpu0: Intel Atom E3000, Z3[67]00 (686-class), 2000.22 MHz
cpu0: family 0x6 model 0x37 stepping 0x8 (id 0x30678)
These are some parts from the messages log:
[ 5.009976] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 5.009976] [drm] Driver supports precise vblank timestamp query.
[ 5.009976] i915drmkms0: interrupting at msi4 vec 0 (i915drmkms0)
[ 5.079724] [drm] Initialized i915 1.6.0 20200114 for i915drmkms0 on
minor 0
[ 5.099724] intelfb0 at i915drmkms0
[ 5.099724] [drm] DRM_I915_DEBUG enabled
[ 5.099724] [drm] DRM_I915_DEBUG_GEM enabled
[ 5.099724] intelfb0: framebuffer at 0xc002, size 1280x1024, depth
32, stride 5120
When I use startx, I get this:
[60.798137] heartbeat bcs0 heartbeat {prio:-2147483645} not ticking
[60.798137] heartbeat Awake? 4
[60.798137] heartbeat Barriers?: no
[60.798137] heartbeat Latency: 86us
[60.798137] heartbeat Heartbeat: 3000 ms ago
[60.798137] heartbeat Reset count: 0 (global 0)
[60.798137] heartbeat Requests:
[60.798137] heartbeat On hold?: 0
[60.798137] heartbeat MMIO base: 0x00022000
[60.798137] heartbeat RING_START: 0x7fff5000
[60.798137] heartbeat RING_HEAD: 0x1f40
[60.798137] heartbeat RING_TAIL: 0x1f40
[60.798137] heartbeat RING_CTL: 0x3001
[60.798137] heartbeat RING_MODE: 0x0200 [idle]
[60.798137] heartbeat RING_IMR:
[60.798137] heartbeat ACTHD: 0x_1f40
[60.798137] heartbeat BBADDR: 0x_00f21070
[60.798137] heartbeat DMA_FADDR: 0x_7fff6f40
[60.798137] heartbeat IPEIR: 0x
[60.798137] heartbeat IPEHR: 0x
[60.798137] heartbeat PP_DIR_BASE: 0x7fdf
[60.798137] heartbeat PP_DIR_BASE_READ: 0x
[60.798137] heartbeat PP_DIR_DCLV: 0x
[60.798137] heartbeat HWSP:
[60.798137] warning:
/usr/src/sys/external/bsd/drm2/dist/drm/i915/gt/intel_engine_cs.c:1234:
WARN_ON_ONCE(hex_dump_to_buffer(buf + pos, len - pos, rowsize, sizeof(u32),
line, sizeof(line), 0) >= sizeof(line))
[60.798137] heartbeat []
[60.798137] 0
[60.798137] heartbeat *
[60.798137] heartbeat [0100] 0f00
[60.798137] 0
[60.798137] heartbeat [0120]
[60.798137] 0
[60.798137] heartbeat *
[60.798137] heartbeat Idle? yes
[60.798137] i915drmkms0: notice: Resetting chip for stopped heartbeat
on bcs0
[66.818107] heartbeat bcs0 heartbeat {prio:-2147483645} not ticking
[66.818107] heartbeat Awake? 4
[66.818107] heartbeat Barriers?: no
[66.818107] heartbeat Latency: 74us
[66.818107] heartbeat Heartbeat: 3000 ms ago
[66.818107] heartbeat Reset count: 0 (global 1)
[66.818107] heartbeat Requests:
[66.818107] heartbeat active 4:13* @ 6000ms: X[697]
[66.818107] heartbeat ring->start: 0x7fff5000
[66.818107] heartbeat ring->head: 0x2578
[66.818107] heartbeat ring->tail: 0x2dd0
[66.818107] heartbeat ring->emit: 0x2dd0
[66.818107] heartbeat ring->space: 0x3768
[66.818107] heartbeat ring->hwsp: 0x2100
[66.818107] heartbeat [head 2578, postfix 25f0, tail 2790, batch
0x_00f21000]:
and finally
[66.818107] i915drmkms0: notice: Resetting chip for stopped heartbeat
on bcs0
[66.818107] i915drmkms0: notice: X[697] context reset due to GPU hang
and later a slight variation
[ 461.076135] i915drmkms0: notice: Resetting chip for stopped heartbeat
on rcs0
[ 461.076135] i915drmkms0: notice: X[338] context reset due to GPU hang
During one of these tests I also had a panic:
[ 301.888540] uvm_fault(0xd4fe33680b28, 0x0, 2) -> e
[ 301.888540] fatal
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
