**** BEGIN LOGGING AT Fri Jun 05 02:59:57 2020 Jun 05 03:35:10 build #140 of bcm27xx/bcm2710 is complete: Failure [failed kmodconfig] Build details are at http://buildbot.openwrt.org/master/images/builders/bcm27xx%2Fbcm2710/builds/140 blamelist: DENG Qingfang , Felix Fietkau Jun 05 04:01:14 objcopy doesn't seem to like the uncompressed kernel. I added CONFIG_MIPS_ELF_APPENDED_DTB=y to my target/linux/ath79/config-4.14 file, recompiled.. but when I use the objcopy --update-section .appended_dtb= command, it fails with a "objcopy: Unable to recognise the format of the input file `tplink_eap245v3-kernel.bin'... Despite it being a proper ELF file I think: "tplink_eap245v3-kernel.bin: Jun 05 04:01:20 ELF 32-bit MSB executable, MIPS, MIPS32 rel2 version 1 (SYSV), statically linked, stripped" Jun 05 04:21:05 build #435 of at91/sam9x is complete: Failure [failed kmodconfig] Build details are at http://buildbot.openwrt.org/master/images/builders/at91%2Fsam9x/builds/435 blamelist: DENG Qingfang , Felix Fietkau Jun 05 04:22:22 build #433 of ipq806x/generic is complete: Failure [failed defconfig dltar] Build details are at http://buildbot.openwrt.org/master/images/builders/ipq806x%2Fgeneric/builds/433 blamelist: DENG Qingfang , Felix Fietkau Jun 05 05:45:37 oh right I need to use the mips-openwrt-linux-objcopy tool :) Jun 05 05:51:13 now it's another ".appended_dtb not found" error. I'll see why it's not being created Jun 05 06:12:21 running add-section successfully added it to the elf, but my board still wouldn't boot. Same "fdt: No valid device tree found" error Jun 05 06:22:01 isnt that a bootloader message - i know that u-boot on arm has a "fdt" command that loads a dtb to a memory address Jun 05 06:22:37 it's definitely linux :) Jun 05 06:22:38 [ 0.000000] Initrd not found or empty - disabling initrd Jun 05 06:22:38 [ 0.000000] OF: fdt: No valid device tree found, continuing without Jun 05 06:23:14 Will continue on it tomorrow. I'm sure it's not going to be too difficult to fix though Jun 05 07:05:08 dwmw2_gone: ping Jun 05 07:05:21 dwmw2_gone: there is a avm fritzbox 7530 Jun 05 07:05:33 it has the vrx618 vdsl chip in it Jun 05 07:05:45 the host cpu is a qca dakota Jun 05 07:05:57 the unit comes up and gets synced but data flow fails Jun 05 07:06:15 problem being after some investigation, that the pci/e driver is designware based Jun 05 07:06:26 but the dakota hooks are missing MSI Jun 05 07:06:40 the driver does however have MSI support and plenty other qca socs already use it Jun 05 07:06:48 most likely 10 lines copy pasta missing Jun 05 07:07:13 once that is done the dsl driver can be pointed at those MSI irqs and in theory should then get irqs to pick data out the pipe Jun 05 07:07:27 dwmw2_gone: this might be a good alternative to what you have right now Jun 05 07:07:40 and they weigh in at ~150 quid a pop Jun 05 07:11:02 morning Jun 05 07:14:09 jow: hi Jun 05 07:15:12 blogic: did you see that procd service shutdown patch on the list? Jun 05 07:16:39 http://lists.infradead.org/pipermail/openwrt-devel/2020-June/023786.html Jun 05 07:17:04 I'm not sure the approach is correct, iirc it needs to be a vlist delete/flush cycle, right? Jun 05 07:19:51 was going to reply Jun 05 08:01:09 blogic: hm, nice. Thanks. Jun 05 08:01:22 precurse: are you sure you've enabled that config option with kernel_menuconfig? Jun 05 08:02:09 still not entirely sure I'm blaming the XRX268 switch. I've plugged *everything* in through the main house switch now, off a single port of the lantiq, and the gremlins are still there sometimes. Jun 05 08:02:12 I haven't worked it out. Jun 05 08:03:04 Stopping the new AP from using the main (802.11r) SSID hides the problem but probably only because hosts aren't really roaming very much. Jun 05 08:03:27 either they're on the wifi of the main router, or they're on the other AP which is on the wired network. NEver *elsewhere* on the wired network. Jun 05 08:13:13 precurse: CONFIG_MIPS_ELF_APPENDED_DTB=y is mutually exclusive with CONFIG_MIPS_RAW_APPENDED_DTB=y Jun 05 08:13:17 you need to unset the latter Jun 05 08:14:52 and to make sure objcopy is dealing with the correct elf file you you might want to check the output of mips-openwrt-linux-readelf | grep appended_dtb Jun 05 08:16:31 The section should also be visible in bootloader output. bootelf lists all the loaded sections. Jun 05 08:16:44 indeed Jun 05 08:26:18 readelf -l* Jun 05 09:41:32 so, I'm trying to create a page on the wiki to document recent findings on routerboot but the "Create this page" link is disabled: expected? Jun 05 09:42:34 ha. Nevermind, i clicked create this page in the toolbar and that worked Jun 05 10:13:44 matteosilex: hey :) any news? btw, can you probably give a link to something reasonably simple explaining BT coex? In what real-life cases is it essential? Jun 05 11:04:37 i can't fully understand how packaging kernel modules work Jun 05 11:04:51 for example: CONFIG_PACKAGE_kmod-ledtrig-default-on=y Jun 05 11:05:05 this package requires following .ko files: Jun 05 11:05:06 FILES:=$(LED_TRIGGER_DIR)/ledtrig-default-on.ko Jun 05 11:05:32 trying to find it gives me nothing: find ./build_dir/ -name ledtrig-default-on.ko Jun 05 11:05:44 it's because I've it built-in Jun 05 11:06:11 grep TRIGGER_DEFAULT_ON build_dir/target-arm_cortex-a9_musl_eabi/linux-bcm53xx/linux-4.14.180/.config Jun 05 11:06:13 CONFIG_LEDS_TRIGGER_DEFAULT_ON=y Jun 05 11:06:48 so how did OpenWrt build ./bin/targets/bcm53xx/generic/packages/kmod-ledtrig-default-on_4.14.180-1_arm_cortex-a9.ipk ? Jun 05 11:09:14 it's not like I *really* want to understand it, but whatever it is, doesn't seem to work for me with kernel 5.6 (i'm trying to build it) Jun 05 11:09:36 ERROR: module '/home/rmilecki/openwrt/build_dir/target-arm_cortex-a9_musl_eabi/linux-bcm53xx_generic/linux-5.6.16/drivers/leds/trigger/ledtrig-default-on.ko' is missing. Jun 05 11:09:37 make[3]: *** [modules/leds.mk:84: /home/rmilecki/openwrt/bin/targets/bcm53xx/generic/packages/kmod-ledtrig-default-on_5.6.16-1_arm_cortex-a9.ipk] Error 1 Jun 05 11:15:22 oh boy, iconv.. what the actual fuck - man page wrong for is core function signature Jun 05 11:16:03 and they have a build variant, where they changed the default Jun 05 11:16:07 iconv.h.in: Jun 05 11:16:08 extern size_t iconv (iconv_t cd, @ICONV_CONST@ char* * inbuf, size_t *inbytesleft, char* * outbuf, size_t *outbytesleft); Jun 05 11:16:11 jow, karlp: hi, when you have time, could you review https://github.com/openwrt/luci/pull/4130 ? it's the first part of my student's work Jun 05 11:16:42 const char ** as 2nd arg vs char ** Jun 05 11:16:48 still WIP and need improvement (hence the review) but it should basically work Jun 05 11:22:11 mirko: its one of these very dark corners of the gnu ecosystem :) Jun 05 11:22:21 like autoconf, m4sh, libtool Jun 05 11:23:01 arcane, obscure abonimations from hell Jun 05 11:23:36 libtool is the worst Jun 05 11:24:46 but this iconv fuckup is really a triple-mess right now. 'm just having a discussion within the Qt project about which reveals its implications: https://bugreports.qt.io/browse/QTBUG-84708 Jun 05 11:26:16 mirko: :D Jun 05 11:28:30 PaulFertser: hey hey. Some news, but not great Jun 05 11:29:18 PaulFertser: I'm still struggling to get coexistence to work, but at least now I have a fighting chance because I can play around with the parameters Jun 05 11:30:17 PaulFertser: the real world use case for coexistence is usually boards where you have more than one radio in the same band Jun 05 11:31:03 PaulFertser: commercially, the most common situation is b/g/n wifi+bluetooth. Wifi uses a subchannel (20 or 40MHz wide) of the 2.4 ISM band Jun 05 11:31:04 matteosilex: sharing an antenna? Or is it essential for two independent modules located nearby? How near is near? Jun 05 11:32:05 PaulFertser: BT will jump around the 2.4 spectrum, so you can't just select "non overlapping" channels as you do to minimise interference between 2 wifi radios Jun 05 11:32:32 matteosilex: yes, that I understand. Frequency hopping on the same ISM band, that I understand. Jun 05 11:32:45 PaulFertser: so, even with two seprate antennas, you will have issues from the two radios accessing the air medium at the same time and corrupting each other's tTXs Jun 05 11:32:50 matteosilex: but BT should start skipping the wifi channels that are "too busy". Jun 05 11:33:43 PaulFertser: "should" being the keyword. There are a lot of situations where the "too busy" info is reset, changes or otherwise doesn't do its job Jun 05 11:34:34 matteosilex: ok, so what if I have two laptops sitting close on the table. Or not so close but in the same room? And one is streaming A2DP. Jun 05 11:34:51 PaulFertser: if you google around, you will find a lot of people complaining about bad wifi transmission when streaming BT EDR audio (or viceversa, skipping audio when wifi uses a lot of bandwidth) Jun 05 11:35:31 PaulFertser: two laptops in the same room are not usually an issue, and they are beyond what coexistence protocols can fix Jun 05 11:36:01 PaulFertser: what the PTA coexistence is meant for are boards where you have both antennas a few centimeters away from each other Jun 05 11:36:06 matteosilex: but why is it usually not problematic? How is 1 m of a distance playing a role? Jun 05 11:36:50 Or is it about some resonance effect between the antennas themselves? Jun 05 11:37:15 PaulFertser: I'm not sure about the physics of it, but you usually have this kind of interference when you're in the range of a few centimeters Jun 05 11:37:57 PaulFertser: what PTA does is use 3 lines between the 2 radios to mutex the access to the air medium Jun 05 11:38:33 PaulFertser: a radio is slave, the other is master (usually wifi is master because it has the highest duty cycle among wifi, BT, Thread, Zigbee...) Jun 05 11:39:03 matteosilex: so what you're seeing with an LA, is setting those nvram parameters just ignored and the three wires remain silent? Jun 05 11:39:12 PaulFertser: the slave can assert a REQUEST line to ask for transmission time. Optionally it can assert the PRIORITY line to make the REQUEST urgent Jun 05 11:39:52 PaulFertser: when it sees fit (usually as soon as it's done transmitting the current frame) the master can respond by asserting the GRANT line, which tells the slave it can go ahead Jun 05 11:40:08 PaulFertser: when the slave is done transmitting, it will deassert the REQUEST line. Fin. Jun 05 11:41:07 PaulFertser: what I am seeing is... hard to interpret. Frist, a bit of context: I'm not doing wifi-BT coexistence, but rather wifi-Thread (802.15.4) coexistence Jun 05 11:41:49 PaulFertser: which is even more of a lottery, because Thread does not hop: it chooses a channel at network formation time, and keeps it forever (more or less, there are exceptions, but they're not straightforward) Jun 05 11:42:31 PaulFertser: which means you CAN choose channels that are not overlapping, but then if the AP changes channel, it can land squarely in the middle of the Thread band and completely fuck you up Jun 05 11:42:53 PaulFertser: now, to answer your question about what I see Jun 05 11:43:59 PaulFertser: initially (with default NVRAM) I saw the Thread radio doing its thing (asserting the REQ and PRIO lines when needed), but the wifi always keeping the GRANT asserted (which is the default behaviour when coexistence is not being used) Jun 05 11:44:56 PaulFertser: that meant that the EFR32 (i.e. thread radio) doing the request was not avoiding interference, because the= requests were always instantly granted anyway, from its point of view, whether the wifi was TXing or not Jun 05 11:46:37 PaulFertser: now, I have set the parameters that Cypress suggests for enabling coexistence in their application note, The problem is that the values are a bit random, because they DO NOT document these parameters anywhere (they don't say what they do, there is just a generic format) and they just tell you "set this values for our demo board" Jun 05 11:47:55 PaulFertser: the result I get from those parameters is that the GRANT line is no longer asserted by default (which suggests coexistence is now enabled wifi side) but the requests are almost never granted (they are, once in a while, maybe 1% of the time) Jun 05 11:49:36 matteosilex: have you checked with a 'scope to make sure it's not e.g. using OD when you expect push-pull or something like that? Jun 05 11:59:12 matteosilex: or probably your GRANT signal got inverted? Jun 05 12:08:13 PaulFertser: the scope was my first step , that's howI saw the EFR32 always having its requests granted Jun 05 12:08:13 Huh https://community.cypress.com/thread/50009?start=0 do I understand it right that Cypress basically just tells their users to fuck off and die? Not answering an explicit and meaningful question on purpose? Jun 05 12:08:27 PaulFertser: yes Jun 05 12:08:34 PaulFertser: you understand right Jun 05 12:08:51 PaulFertser: I managed to talk to a FAE over the phone, and this is their position: Jun 05 12:09:21 PaulFertser: if you order million+ pcs/year, we can consider having a support contract with you Jun 05 12:09:27 PaulFertser: otherwise, use a module Jun 05 12:09:49 PaulFertser: if you use a module, don't come to us for support, go to the module manufacturer Jun 05 12:10:05 matteosilex: so broadcom were arseholes, and cypress now is no better :( Jun 05 12:11:02 PaulFertser: in a way, I understand them. They are huge, they have distributors and module manufacturers to deal with the small fishes Jun 05 12:11:05 matteosilex: probably it's all in the firmware so nexmon tools plus possibly some help from them might get you rolling after reversing enough of the stupid binaries. Jun 05 12:11:27 matteosilex: sharing documentation costs nothing though Jun 05 12:11:37 PaulFertser: but they are proper arseholes when you say, like we did, "we'll do all the work, just given us the docs" Jun 05 12:11:45 PaulFertser: exactly Jun 05 12:12:22 matteosilex: are you sure an idea that they invert GRANT line with the parameters you tried is not right? Jun 05 12:13:08 PaulFertser: I find it especially ridiculous that they go through the ceremony of publishing an application note about "how to do coexistence", and then it contains just the "magic formula" for their demo board without giving you the info to modifi it for YOUR board Jun 05 12:14:46 PaulFertser: I'm quite sure about GRANT. or a series of reasons: they say it's active low by default, and I actually verified that high is its idle state. Second, it does go low ofter SOME requests. Jun 05 12:14:50 matteosilex: guess there're no schematics for the demo board either? Jun 05 12:15:30 matteosilex: if it's inverted (by non-default settings) and wifi is mostly idle then it would rarely go low. Jun 05 12:16:28 PaulFertser: there is not even a part number for the board =) They just say "A 4343W card" Jun 05 12:16:48 they do have a generic "block diagram pinout" Jun 05 12:16:59 PaulFertser: you can see for yourself here https://www.cypress.com/file/298336/download Jun 05 12:17:15 sections 7 and 8 Jun 05 12:17:46 the thing that driver me mad is when they tell you to set "zbcxgcigpio=0x123" Jun 05 12:19:11 PaulFertser: and the only thing you can extrapolate about this param is that given its name, those are the pads for GCI GPIO Jun 05 12:20:51 PaulFertser: and GCI seems to be a DIFFERENT coexistence protocol, proprietary to Cypress, which is based on serial communication and should have nothing to do with PTA... Jun 05 12:23:04 PaulFertser: about GRANT: why would it rarely go low when wifi is idle? It's not supposed to be asserted when wifi is idle, unless there is a request Jun 05 12:25:33 "The Wi-Fi device asserts a GRANT signal when Wi-Fi is not busy transmitting or receiving. " https://www.silabs.com/community/wireless/bluetooth/knowledge-base.entry.html/2017/11/07/enabling_coex_featur-l6mQ implies that it might be asserted even without a request. Jun 05 12:27:09 matteosilex: https://git.congatec.com/yocto/meta-fsl-arm-extra/blob/c92573efffe0ef19d72f08d6083e77913cd57d3c/recipes-bsp/broadcom-nvram-config/files/wandboard/brcmfmac4330-sdio.txt some of the boards mentioned might have schematics available Jun 05 12:37:27 PaulFertser: mmm... that's not the behaviour I think I see on the GRANT line. interesting Jun 05 12:38:52 PaulFertser: I can;t really use the 4330 or similar as a reference, because they are combo wifi+BT chips, for which coexistence is fully internal. See those btc_param* lines? they are for the in-chip arbitratino between wifi and BT, they have nothing to do with my case, I think Jun 05 12:39:16 matteosilex: makes sense Jun 05 12:39:31 PaulFertser: the application note does not mention btc_param* at all Jun 05 12:40:03 matteosilex: I'd do more testing scoping GRANT line while actively pushing and not pushing wifi traffic and probably permanently pulling the REQUEST line in different states etc. Who knows, probably you get lucky. Jun 05 12:44:37 PaulFertser: yes, that's what I'll do now Jun 05 12:45:58 PaulFertser: thanks for all the advice, by the way Jun 05 13:52:31 Hauke: do you know what could break kernel booting on BCM47094? it happened between 4.19 and 5.4 Jun 05 13:52:55 it hangs at [ 0.000000] Memory policy: Data cache writealloc Jun 05 13:57:15 build #141 of bcm27xx/bcm2710 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/bcm27xx%2Fbcm2710/builds/141 Jun 05 14:04:51 rmilecki: FYI there are some gcc issues on ath79, 8.4.0 is borken Jun 05 14:05:14 maybe you're affected as well by some variation? Jun 05 14:07:30 probably unlikely as switching between 4.19 and 5.4 using the same gcc makes differnce Jun 05 14:07:44 unless kernel introduced some gcc 8.4.0 incompatible change Jun 05 14:10:08 in 5.2 Jun 05 14:10:10 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94506 Jun 05 14:10:31 oh, that is interesting Jun 05 14:10:32 thanks ynezz Jun 05 14:11:28 btw I've just flashed my edgerouterx with latest snapshot Jun 05 14:11:42 and I'm surprised, that there is no wan anymore Jun 05 14:12:02 5acd1ed0be0d78847cd7d9d5599526f59babaf4d Jun 05 14:13:40 eth0 used to be wan, any pointers/discussion where it was decided to have everything bridged to lan by default? Jun 05 14:14:25 I don't care about naming, but this changes wan/lan functionality I'm used to :) Jun 05 14:14:35 seems like nonsense to me Jun 05 14:16:07 updated names seem to match labels which sounds good Jun 05 14:16:27 that no-wan seems a bit weird Jun 05 14:27:02 jow: do you see any reason not to make GLIBC and BUILD_NLS mutually exclusive? Jun 05 14:27:30 like, make BUILD_NLS depend on !USE_GLIBC ? Jun 05 14:27:50 mirko: no, fine with me Jun 05 14:41:45 build #436 of at91/sam9x is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/at91%2Fsam9x/builds/436 Jun 05 14:49:50 jow: hm, ok, that doesn't work :) Jun 05 14:50:22 are the variables ICONV_FULL / INTL_FULL actually used enywhere? within the core repo i can't find anything Jun 05 15:10:48 build #434 of ipq806x/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/ipq806x%2Fgeneric/builds/434 Jun 05 15:13:19 Thanks f00b4r0 and PaulFertser . I'm seeing Loading .appended_dtb @ 0x8054ef9c during boot now :) It's still not reading the dtb that I injected with objcopy, but I'll work on that. Thakns! Jun 05 15:15:04 precurse: do you have that kernel config option set? Jun 05 15:16:06 I do. I unset CONFIG_MIPS_RAW_APPENDED_DTB and set CONFIG_MIPS_ELF_APPENDED_DTB. make config set it properly as well Jun 05 15:16:23 which is why I'm seeing the .appended_dtb section on my elf now Jun 05 15:17:07 precurse: it'd be interesting to know why it's not seeing it then Jun 05 15:17:12 I'm running objcopy manually on the right file, and it's no longer failing to copy the dtb. It's just the bootup still isn't seeing it Jun 05 15:17:15 yeah me too Jun 05 15:17:40 I'll have some time later today to work on it Jun 05 15:47:20 oh boy, i really shouldn't have touched the NLS stuff. Turns out, ICONV_DEPENDS and INTL_DEPENDS - used in package Makefiles as part of DEPENDS - of course don't get re-evaluated once NLS settings change Jun 05 15:47:43 can i force re-evaluation of dependencies, triggered by certain config changes? Jun 05 15:58:05 delete the tmp folder might do the trick Jun 05 16:00:39 it does, however that's not a feasible strategy Jun 05 16:06:02 ynezz: err, having no WAN on a 5-ports router is non-sense... Jun 05 16:06:05 I remember some people were pushing for this for consistency with the stock firmware Jun 05 16:07:27 zorun: is this about the ubiquiti mail? Jun 05 16:08:39 Borromini: which ubiquiti email? Jun 05 16:09:03 this was about 16:11 < ynezz> btw I've just flashed my edgerouterx with latest snapshot Jun 05 16:10:04 zorun: oh. there's a mailing list thread going on as well: https://lists.openwrt.org/pipermail/openwrt-devel/2020-June/023798.html Jun 05 16:10:22 oh ok Jun 05 16:10:24 thanks Jun 05 16:25:07 jow: re single lzma-loader location in tree, see this commit: http://git.openwrt.org/c57e182b56 :) These changes were never forwarded to ramips (and generic/relocate is on an even older version) Jun 05 16:31:41 i just figure it's the same with switching between libc's oder targets - package dependencies need to be re-evaluated here as well, so how does it happen there (if at all)? Jun 05 16:52:13 rmilecki: I have no idea why it does not boot any more Jun 05 16:52:35 but I haven't followed arm or BCM changes in the last year Jun 05 16:53:16 I think there was a problemn with some caches on this SoC Jun 05 16:53:37 I am not sure, I have to check my mails from 7 years ago ;-) Jun 05 16:54:18 I think CFE activates the L1 cache and this should be deactivated Jun 05 16:54:21 or something like this Jun 05 16:54:44 at least Linux expected it diffeerntly, I think you get a warning about this in the kernel Jun 05 17:27:20 Hm, I suppose this is the point at which I request commit access... Jun 05 18:09:34 PaulFertser: so... the 3 wire PTA is working =) Jun 05 18:10:24 PaulFertser: in the end the last piece that was missing was that one of the "mystery parameters" given in the application note was wrong Jun 05 18:11:02 PaulFertser: or, at least, it was wrong for the 43143 specifically Jun 05 18:23:07 matteosilex: congrats! how did you manage to figure it out? Jun 05 18:28:16 PaulFertser: there is this parameter called zbcxfnsel. They only say to set it to 0x233. Jun 05 18:28:45 PaulFertser: the AN says that each byte is the "PAD fnsel" Jun 05 18:28:58 PaulFertser: so, I guessed it was some type of pin muxing Jun 05 18:30:06 PaulFertser: in the 43143 datasheet, the pin functions are listed in order. It doesn't say specifically which value corresponds to each function, but it's always 4 functions and the PTA was always the 3rd in the list Jun 05 18:30:26 PaulFertser: so I decided to try a value of 0x333 and... magic happened =) Jun 05 18:30:40 PaulFertser: so I would say that it was an educated guess? =) Jun 05 18:31:14 matteosilex: yes, a rather reasonable educated guess Jun 05 18:32:31 PaulFertser: now I'm wondering... do you thing this is too specific to go to the wiki? There is a lot of guesswork and it might be completely specific to the 43143... Jun 05 18:32:37 do you think* Jun 05 18:34:07 PaulFertser: also, this behaviour might be working just because of a happy accident with the specific firmware binary I am patching... Jun 05 18:34:13 Hi people Jun 05 18:34:20 matteosilex: the "nvram" modding is not specific of course; the PTA functionality worth sharing too but I have no idea how it make it properly visible to the public. Jun 05 18:34:42 What files do I have to re do in my config when flashing my new build for mvebu: . Jun 05 18:34:54 After the switch to dsa Jun 05 18:35:23 matteosilex: is it an OSHW device by any chance? In that case probably an article on hack-a-day might get accepted Jun 05 18:36:47 PaulFertser: it's not OSHW, but the company that makes it is generally non-paranoid (and I've published as FOSS other firmware I wrote for them) so they might be open to it Jun 05 18:38:33 matteosilex: were you modding some factory USB device or was it your own design? Jun 05 18:39:36 PaulFertser: own design, but as a freelance (so I don't own the IP, if that's where you were going to) Jun 05 18:40:04 matteosilex: no, I meant it might be of interest to a general public if it was a "hack/mod". Jun 05 18:41:15 PaulFertser: ah. well, you can't do this over just USB, so it would mean at least wiring the 3 BRCM pins to your board... it's not something that's very useful on consumer hardware. Jun 05 18:41:30 PaulFertser: I guess it can be interesting for people designing devices though Jun 05 18:41:49 PaulFertser: as finding a wifi chip that supports this AND has FOSS drivers is hell Jun 05 18:42:49 (essentially, this and old 2.4Ghz Atheros were the only viable option for me Jun 05 18:43:17 PaulFertser: PTA is becoming a lot less common due to the success of wifi+BT chips Jun 05 18:43:22 matteosilex: I think it's worth describing your experience in a blog post indexed by search engines, adding generic "nvram" information to the kernel wiki, and probably writing a short post to the cypress forums would be the reasonable way to get information available to the wider audience. Jun 05 18:44:29 Tapper: switch config should only matter for /etc/config/network Jun 05 18:44:30 PaulFertser: probably, yes. I need to document this anyway (future self will be grateful!) Jun 05 18:45:13 PaulFertser OK thanks Jun 05 18:45:53 matteosilex: I guess you'll have to refrain from cursing in the cypress forum post though :( Jun 05 18:58:44 PaulFertser: the temptation is real Jun 05 19:14:27 PaulFertser: my customer just offered to send chocolates to you guys =) Jun 05 19:17:46 matteosilex: :) hard to disseminate chocolate over IRC Jun 05 19:19:12 🍫 Jun 05 19:24:12 PaulFertser: technology is still so limited! =) Jun 05 19:26:35 matteosilex: probably they'll consider basing their next project on openwrt Jun 05 19:53:07 PaulFertser: they already based this one on it, I don't see why they wouldn't =) Jun 05 20:12:20 jow: can you live with the ~500 bytes that fmemopen() adds to firewall3? Jun 06 01:56:05 hmmz, rpi0w sta with encryption 'psk2' does no longer connect to a psk2 network. if I change the sta to psk3+mixed it works **** ENDING LOGGING AT Sat Jun 06 02:59:57 2020