| steev | c0rnelius: i'd recommend reverting the hunk at 2940 in the 001-bcm2711-brcm-5ghz-wifi patch - it's probably just me but i detest dmesg being spammed with useless info (and the power save state every 5-10 minutes is pointless) | 17:05 |
|---|---|---|
| c0rnelius | steev: are you referring to the new direct firmware load error thats in 5.15.y now? | 17:15 |
| steev | c0rnelius: maybe i have the wrong person but i'm referring to https://github.com/pyavitz/debian-image-builder/blob/feature/patches/broadcom/001-bcm2711-brcm-5ghz-wifi.patch#L40 | 17:16 |
| steev | that hunk there causes things like https://bpa.st/4R3A | 17:17 |
| c0rnelius | Oh. Yeah thats always been there I thinks on the pi. Tells you if its enabled or disabled. | 17:17 |
| steev | yeah i'm aware | 17:17 |
| steev | oh | 17:17 |
| c0rnelius | I don't ever see it pop more than once though? | 17:18 |
| steev | am i misreading the patch? | 17:18 |
| c0rnelius | Maybe | 17:18 |
| steev | that changes it from a debug only print, to an info print | 17:18 |
| c0rnelius | If ur seeing it come up every 10 minutes or so then something must be wrong? | 17:18 |
| steev | well it happens on every single pi, so.... | 17:18 |
| c0rnelius | Kali? | 17:19 |
| steev | yeah | 17:19 |
| steev | i patched it to go back to the old way | 17:19 |
| steev | but haven't tested it | 17:19 |
| c0rnelius | Maybe there is something going on in Kali? | 17:19 |
| steev | we don't want or need to know that it's enabled every 10 minutes | 17:19 |
| steev | unlikely, but possibly | 17:19 |
| c0rnelius | Kali disables a bunch of services by default don't they? | 17:20 |
| steev | any network services, yeah | 17:20 |
| c0rnelius | Maybe one of those services is making it trigger like that. | 17:20 |
| steev | i doubt that | 17:20 |
| c0rnelius | Well... Its not happening to me on Debian, Devuan or Ubuntu. | 17:21 |
| c0rnelius | Or lack of one of those services I should say? | 17:21 |
| steev | you're running now with that patch applied? | 17:21 |
| c0rnelius | dmesg | grep "brcmf_cfg80211_set_power_mgmt" | 17:22 |
| c0rnelius | [ 8.890528] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled | 17:22 |
| c0rnelius | [ 11.622701] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save disabled | 17:22 |
| c0rnelius | Thats been running for a few days. | 17:23 |
| steev | but that patch just changed yesterday? | 17:23 |
| c0rnelius | Thats the foundation broadcom patch. I just use it for mainline in the debian builder or else 5GHz is wonky. | 17:23 |
| c0rnelius | Yeah the patch changes every branch. | 17:24 |
| c0rnelius | That one you posted is 5.10.y, the one in the edge folder is for 5.15.y | 17:25 |
| c0rnelius | Here is the new 5.15.y error I've seen for all boards using broadcom. | 17:27 |
| c0rnelius | brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43436-sdio.raspberrypi,model-zero-2-w.bin failed with error -2 | 17:27 |
| c0rnelius | Not sure why its looking for the *.bin of the same name instead of the *.txt file, but its pretty annoying. | 17:27 |
| steev | that's definitely odd | 17:28 |
| c0rnelius | Yeah | 17:28 |
| c0rnelius | Happens on the NanoPC and NanoPi too | 17:28 |
| steev | especially since it's 433436s | 17:28 |
| steev | bleh, i can't type today | 17:28 |
| steev | 43436s | 17:28 |
| c0rnelius | I know. The foundation still hasn't gotten that right. | 17:28 |
| c0rnelius | and its missing the clm_blob | 17:29 |
| steev | oh this is the foundation kernel? | 17:29 |
| steev | clm blob isn't *required* | 17:29 |
| c0rnelius | Well one I compiled from the github yeah | 17:29 |
| steev | it's an optional thing for adding additional channels and such | 17:29 |
| steev | The firmware for WICED devices includes information regarding regulatory constraints. For certain devices this information is kept separately in a binary form also known as CLM blob. | 17:30 |
| c0rnelius | https://github.com/raspberrypi/linux/commit/f71d77d11ea3a0cc391030b6c4eb5a0b22e9e787 | 17:30 |
| steev | oof | 17:31 |
| steev | aka "we dunno which chip is actually used" | 17:31 |
| c0rnelius | Yeah | 17:31 |
| c0rnelius | And they changed the dts name, but only for arm for some reason? | 17:32 |
| c0rnelius | I don't think they know what they are gonna do yet. | 17:32 |
| c0rnelius | steev: and that patch you posted is actually kinda old. I just renamed it when I updated the other patch for 5.15.y. Check the date. | 17:56 |
| steev | the arm64 side of things just "symlink" (really it's an include) the arm ones | 17:57 |
| c0rnelius | It still applies fine on mainline so I didn't bother updating it. | 17:57 |
| c0rnelius | Yeah I know. But shouldn't there be a name to represent the new dtb created under arch/arm64? | 17:58 |
| steev | they don't usually add it until someone requests it since their main focus is still 32bit | 17:58 |
| c0rnelius | I'm sure someone over at Arch will say something. They usually do. | 17:59 |
| steev | with only 512MB of ram, i don't really see the advantage of running arm64 on it | 18:00 |
| steev | mine arrives later today though, so i'll see then | 18:00 |
| c0rnelius | Depends what ur using it for I guess? If you need userland then yeah arm64 is not the road to go down. | 18:00 |
| c0rnelius | I added it to my packaging patch just in case -> https://github.com/pyavitz/rpi-img-builder/commit/d0b80d3ebddbfac71036358c8b36493225ed67b6 | 18:02 |
| c0rnelius | Very confusing. I was just like ok whatever. | 18:02 |
| steev | there are a number of things missing really, the 64bit pi2 wasn't available for a really long time and if you'd run 64bit on it, you'd end up only being able to access 1 cpu instead of all 4, i finally opened an issue and they put in the 64bit | 18:04 |
| c0rnelius | I've personally never seen one in the wild. I just added it to the packaging patch just in case. The pi2 I have someone sent for the builder, which was suppose to be a 64bit model according the site, but turned out to be the 32bit model. | 18:36 |
| c0rnelius | Either way, good to have for testing purposes, so I very much appreciated it. | 18:36 |
| c0rnelius | I still don't have any of the generation one models. But I guess that doesn't matter much at this point. | 18:39 |
| c0rnelius | Personally I find it more enjoyable playing with other SoCs. The Pi stuff gets kinda boring and being limited to that fat partition gets on my nerves. | 18:47 |
| steev | the pi2 64bit says v1.2 on it, if it doesn't say 1.2 it's not | 18:56 |
| c0rnelius | Yeah | 18:56 |
| c0rnelius | mine is 1.1... advertised as 1.2. | 18:56 |
| c0rnelius | Typical Amazon. | 18:57 |
| steev | oof | 18:58 |
| steev | i need to gather up all my systems, and my SO wants me to get rid of a few (she says 200+ is too many), so i might have some to spare | 18:58 |
| c0rnelius | Well let me know. I'm always happy to help some one out :) | 19:06 |
| steev | c0rnelius: btw, could you skip doing raspberrypi-sys-mods on a kali install? we have it packaged elsewhere and it causes conflicts and failure | 19:30 |
| steev | s/install/build | 19:31 |
| c0rnelius | I've been wondering that myself actually and I think, yes. | 19:35 |
| steev | upstream-wise (debian) at least in unstable/testing, bluez-firmware has the firmwares for the rpis, so that's good, i believe we (kali) fork pi-bluetooth and do the 99-com.rules and other things as well | 19:36 |
| c0rnelius | Pretty sure the only things that matter are some of the udev rules and what have you | 19:37 |
| steev | https://gitlab.com/kalilinux/packages/pi-bluetooth | 19:37 |
| c0rnelius | I forked that too, but I did it at 1.13 as I didn't like the changes they made. | 19:38 |
| c0rnelius | As for bluez you don't even need to patch that. Just create a symlink from /lib/firmware to /etc/firmware and drop in the needed firmware. | 19:40 |
| steev | why drop firmware in etc??? | 19:40 |
| steev | this ain't android | 19:41 |
| c0rnelius | This is what the foundation and ubuntu do -> https://github.com/pyavitz/pi-bluetooth/blob/bluez-patches/bluez-raspi-support.patch | 19:41 |
| c0rnelius | To work around it just create the symlink and problem solved. | 19:42 |
| steev | how is the problem solved if the files aren't installed there? | 19:42 |
| c0rnelius | Well because ur installing the firmware under /lib/firmware, but bluez is looking under /etc... hence the link. | 19:43 |
| steev | steev@vincenzo:/etc$ ls firmware | 19:44 |
| steev | ls: cannot access 'firmware': No such file or directory | 19:44 |
| steev | oh, i see what you mean | 19:44 |
| steev | yeah we apply that patch too to look in /lib/firmware instead of etc, and, meh, sophie maintains it so *shrug* no work for me | 19:45 |
| c0rnelius | I actually take it a step further. The kernel by default looks under /lib/firmware/updates first. Thats where I install my brcm firmware. I take it a step further and place in the cmdline `firmware_class.path=/lib/firmware/updates/brcm` | 19:45 |
| steev | UGH | 19:47 |
| steev | i broke my neo4 | 19:47 |
| steev | well, broke booting | 19:48 |
| c0rnelius | Lucky! I don't have one to break yet. | 19:48 |
| steev | i *love* the neo4 | 19:48 |
| c0rnelius | uboot breakage or kernel? | 19:48 |
| steev | its trying to load uInitrd and saying the initrd is corrupt, i just need to fix it, i'm just lazy | 19:49 |
| c0rnelius | I thought you didn't like uInitrd :) | 19:49 |
| c0rnelius | As for the conflicts and failures I suspect it has something to do with the systemd service it installs and enabled. Have you guys tried just disabling them? | 19:50 |
| steev | i hate it | 19:51 |
| c0rnelius | Pretty sure those services are for lcd panels and dumb shit. | 19:51 |
| steev | but... i'm too lazy to get it working myself, and just used armbian u-boot/kernel | 19:51 |
| c0rnelius | Oh | 19:51 |
| steev | but i removed their thing that generates the uinitrd after kernel install | 19:51 |
| c0rnelius | Problem #1 | 19:51 |
| steev | somewhere i have a fork of debian's u-boot with the support added for it, just, haven't sent the merge request | 19:52 |
| c0rnelius | I use my own I found somewhere online -> https://github.com/pyavitz/debian-image-builder/blob/feature/files/scripts/99-uboot | 19:52 |
| steev | https://salsa.debian.org/steev/u-boot/-/commit/bfaa0ea1c9515b787bc44aacf2e39a3c904c21dc | 19:52 |
| c0rnelius | never had any problems with it | 19:52 |
| steev | yeah, i just didn't notice :) | 19:53 |
| c0rnelius | Thats vendor uboot? | 19:53 |
| steev | no, that's debian u-boot | 19:53 |
| steev | which is mainline | 19:53 |
| c0rnelius | oh yes | 19:55 |
| c0rnelius | I only use the u-boot.itb idbloader.img, but I rename it to idbloader.bin because I'm silly. | 19:56 |
| c0rnelius | Well looks like a fun board. Overclocked it yet? | 19:57 |
| steev | honestly, i just copy pasta'd the others | 19:57 |
| steev | i have! | 19:57 |
| c0rnelius | nice | 19:57 |
| steev | it does work at 2GHz pretty stable | 19:57 |
| c0rnelius | Thats awesome | 19:57 |
| steev | especially for its size :D | 19:57 |
| steev | sad about the ram though | 19:57 |
| c0rnelius | It happens. I don't think it was meant to change the world anything :) | 19:58 |
| c0rnelius | or anything* | 19:58 |
| c0rnelius | steev: What kind of problems is sys-mods creating exactly on Kali? | 20:12 |
| c0rnelius | I from time to time debootstrap it and I don't recall any sys-mod specific errors. | 20:12 |
| c0rnelius | On the Pi4 mind you also running mainline. | 20:13 |
| steev | c0rnelius: building the image fails because 99-com.rules is in raspberrypi-sys-mods, and pi-bluetooth on kali, so dpkg errors because the file exists in 2 packages | 20:30 |
| c0rnelius | I actually include my own 99-com.rules in my images and I've never seen a conflict. Actually I'm not seeing it in pi bluetooth? | 20:40 |
| c0rnelius | I'm not sure how you stage ur builds, but you could set a if there rm and just include ur own after the fact? Or if there remove after said install of whatever gets installed last? | 20:43 |
| c0rnelius | If you get my drift. | 20:43 |
| steev | i'm just running make in your sources | 20:44 |
| steev | the *kali* pi-bluetooth package has it | 20:44 |
| c0rnelius | Or just not install sysmods :) and only include udev rules it includes. | 20:45 |
| c0rnelius | I don't see why kali needs sysmods | 20:45 |
| steev | i don't either | 20:45 |
| steev | https://github.com/pyavitz/debian-image-builder/blob/feature/scripts/broadcom-stage2#L164 | 20:45 |
| c0rnelius | As matter of fact nor does Devuan I just haven't removed it yet. | 20:45 |
| steev | i was just playing with it to test it on the 02W when it arrives | 20:46 |
| steev | actually, i don't think it's gonna arrive today, it's not even in my city yet even though it says its scheduled to be delivered today | 20:47 |
| c0rnelius | I would use this one -> https://github.com/pyavitz/rpi-img-builder | 20:47 |
| c0rnelius | that debian builder is for mainline stuff | 20:47 |
| c0rnelius | Only supports what mainline dts is available and functional uboot. Pi wise anyway. | 20:48 |
| steev | ah, fair | 20:48 |
| c0rnelius | Its pretty much the same, but... specific to pis | 20:49 |
| steev | makes sense | 20:51 |
| c0rnelius | I keep getting asked to merge it all into one builder, but it would be such a pain in the ass. | 20:54 |
| c0rnelius | Although I don't think I ever added Kali as a secret option to the rpi img builder? I could. | 20:59 |
| c0rnelius | But Kali kills so many services, so I need to then create a force service start script to ssh in headless. | 21:00 |
| c0rnelius | Which in the end defeats the purpose I guess? Probs why I didn't bother. | 21:01 |
| steev | nah | 21:18 |
| steev | just include the ssh service | 21:18 |
| steev | https://gitlab.com/kalilinux/build-scripts/kali-arm/-/blob/master/bsp/services/rpi/enable-ssh.service | 21:19 |
| steev | that lets you do just like raspiOS and touch ssh/ssh.txt on the boot partition to enable it | 21:19 |
| steev | but yeah, in our build scripts, we enable ssh during the build of all arm images | 21:20 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!