**** BEGIN LOGGING AT Mon Apr 26 03:00:18 2021 Apr 26 08:07:13 could someone give me a hint how to find the correct memory in the art mtd block, for the caldata extraction? Apr 26 08:09:43 nick[m]3: usually you just inspect hexdump -C output Apr 26 08:10:34 PaulFertser: already did but not sure what I search for Apr 26 08:10:50 nick[m]3: and you can check existing dumps from https://github.com/pepe2k/ar9300_eeprom/ for comparison Apr 26 08:10:54 nick[m]3: and use that tool etc Apr 26 08:11:13 PaulFertser: thanks! :) Apr 26 08:20:07 nick[m]3: btw, at least on many ath9k devices the idea is that art is the very last sector of SPI flash (no matter what size it is) and the wifi driver looks at the beginning of it. Apr 26 08:20:48 (beginning of it is usually for MACs and then at 0x1000 you get caldata) Apr 26 08:21:25 PaulFertser: it is about the ath10k driver. and I copied the PR from the powerbeam ac5. but when I do test the calibration data extraction, it just fails. Apr 26 08:21:41 PaulFertser: already searched for it :) my wifi mac is at 3 positions Apr 26 08:21:49 lets see what is the correct position ^^ Apr 26 08:22:46 nick[m]3: existing boards use either 0x5000 offset for ath10k data. Apr 26 08:22:54 s/either// Apr 26 08:23:30 the call is: caldata_extract "art" 0x5000 0x844 Apr 26 08:23:44 if I try that manual, it fails with: caldata: failed to extract calibration data from /dev/mtd7 Apr 26 08:23:52 maybe I'm doing something wrong? Apr 26 08:23:58 so the offset looks correct Apr 26 08:28:50 PaulFertser: or did I misunderstood something? the call should work, or? Apr 26 08:44:09 whups, I forgot to set env variable firmware. now it works Apr 26 08:46:42 thanks a lot for your help Apr 26 09:38:29 nick[m]3: :) Apr 26 10:18:07 rsalvaterra: surely we should actually build the jffs2 images with the same compression algorithm we want to use at runtime? Apr 26 10:18:21 Rather than compressing the image with zlib and then using zstd for writes? Apr 26 10:18:57 Or is that irrelevant because we don't really use jffs2 for the real fs images; only for overlay? Apr 26 10:21:00 dwmw2_gone: It's a possibility, yes. I was only tackling the jffs2 overlay use case, however (since I've never seen a jffs2-based rootfs, only squashfs). Apr 26 10:21:37 if you'll allow me to butt in to this topic - do i understand correctly that /rom is compressed and /overlay is not? Apr 26 10:21:45 https://openwrt.org/docs/techref/flash.layout tells me that, but perhaps it's outdated Apr 26 10:22:29 depends on the media but if it's flash, /rom will be *better* compressed because it's a precompressed blob, than /overlay which is jffs2 and dynamically compressed as it's written. Apr 26 10:22:30 they'r eboth compressed with whatever the filesystem in use there uses... Apr 26 10:22:41 We are discussing the compression algorithm to use on the latter. Apr 26 10:22:44 ah i see now on https://openwrt.org/docs/techref/filesystems Apr 26 10:22:46 thanks Apr 26 10:22:54 dwmw2_gone, very good, i'll follow with interest :) Apr 26 10:23:13 jffs2 can use zlib Apr 26 10:23:44 OpenWrt has patches to make it use lzma (adding that to the kernel since it isn't there already) Apr 26 10:23:53 dwmw2_gone: Since jffs2 seems to be mostly dead (or in very light maintenance mode), I tried to implement zstd compression in the least invasive way possible. :) Apr 26 10:23:56 rsalvaterra is now proposing the addition of zstd Apr 26 10:24:12 yeah, the patches look sane enough. I was just not entirely sure anyone had really shown any *benefit* Apr 26 10:24:32 since we can only ever compress a 4KiB page at a time, the compressors have a slightly different task Apr 26 10:24:45 jffs2 is indeed mostly dead Apr 26 10:24:50 any alternatives? Apr 26 10:24:59 dwmw2_gone: I also thought about bumping zstd compression priority in jffs2 to the top, but I haven't done so. Apr 26 10:25:11 dead/stable... ;) Apr 26 10:25:26 upstream don't care about our little devices.... Apr 26 10:25:43 did anyone bench startup times when ubifs got switched over Apr 26 10:25:45 karlp: I do care… I'm a bit obsessive in that regard, admittedly. :P Apr 26 10:26:19 i wonder why nilfs2 is also seemingly dead Apr 26 10:26:35 because it's vendor backing went away I suspect. Apr 26 10:26:58 jffs2 basically works; we're reluctant to add new features. Apr 26 10:26:59 dwmw2_gone: Compression ratio will probably be a wash with zstd. But being able to kill that God-awful lzma patch would be a benefit in itself. Apr 26 10:27:09 Sure, but why did we even have *that*? Apr 26 10:27:20 because lzma Apr 26 10:27:29 probably the same reason as zstd, "everything must be better compressed, because reasons!" Apr 26 10:27:34 storage is precious. Apr 26 10:27:43 storage is _sometimes_ precious Apr 26 10:27:53 Especially precious when you only have 8 MiB of it, total. Apr 26 10:27:54 4MB routers Apr 26 10:28:05 This storage is rarely written and slow to write. So compress with -z9 :) Apr 26 10:28:16 so... the original commit will clearly have metrics right? ;) Apr 26 10:28:19 adding a new algo and still using -z3 is a bit weird. Apr 26 10:28:19 mangix: Not 4 MiB yet, but I'm trying. ;) Apr 26 10:28:20 hahaha Apr 26 10:28:24 this is an easy answe? right? ;) Apr 26 10:28:38 oh, that's right, these sorts of things ar emostly done on religion.... Apr 26 10:28:52 dwmw2_gone: Noted. I can increase the compression ratio, but that will use more RAM. ;) Apr 26 10:28:58 nobody talk about that 100hz patch Apr 26 10:29:01 only as we're writing it. Apr 26 10:29:27 doesn't decompression also use more RAM? Apr 26 10:29:44 nah, decompression is simple Apr 26 10:29:58 compression builds up a history buffer of what has gone before, so that we can say "repeat that bit" Apr 26 10:30:10 Namidairo: The 100 Hz patch was an eager merge by ldir, but I will get some numbers on it ASAP. Apr 26 10:30:36 If we're actually doing to do some *testing* of images sizes and RAM usage and CPU time, this might be worth a look too: http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/lzs.c Apr 26 10:31:07 I spent a while optimising that. It's for VPN packet compression but the use case is fairly similar to page-sized chunks of files. Apr 26 10:32:03 dwmw2_gone: My idea was to only use an already upstream algorithm, which could also be used for other purposes (zram). I don't think lzs is even upstream… :/ Apr 26 10:32:25 it's all fairly inconsequential to me but I'm sure some sort of boot time aficionado will love it. Apr 26 10:32:27 That's one 329-line file Apr 26 10:33:11 Why is everyone so worried about boot times, especially in OpenWrt? It's supposed to be a boot-up-and-forget system, no? :P Apr 26 10:33:45 rsalvaterra: because downtime sucks Apr 26 10:33:57 it adds up because we're flashing images all day /s Apr 26 10:34:28 mangix: Yeah, but does it cost money? If so, you need redundancy, not faster boot. ;) Apr 26 10:35:06 Even when I had redundant lines I had a single OpenWrt box terminating them both :) Apr 26 10:35:08 pff, YOLO computing Apr 26 10:35:18 It's why OpenWrt has the teql support :) Apr 26 10:36:09 heh :P I have a single line and redudant openwrt routers :P Apr 26 10:36:47 I suppose I do have a spare lantiq box here which could be put back into service if my hh5a blows up :) Apr 26 10:36:55 not *quite* a hotswap spare but close Apr 26 10:38:31 dwmw2_gone: I've been eyeing the HH5a, it's a neat little device (even though xDSL is mostly gone here in Portugal, we only have it in remote rural areas, everything is cable/fiber now). Apr 26 10:38:57 I like it; does the job nicely for VDSL and wifi on both bands Apr 26 10:39:18 The Lantiq usb sucks though; both boxes I've had just seem to suffer random crashes when I plug anything interesting in Apr 26 10:39:37 so the Domoticz home automation now lives on a wndr3800 which is a bit underpowered for the job but at least it stays up Apr 26 10:39:37 Is it only VDSL? Does it support Annex A ADSL2+? Apr 26 10:39:43 yeah it'll do that too. Apr 26 10:40:07 Nice. We don't have vectoring here, only plain-old ADSL2+. Apr 26 10:40:13 in master I silently set domoticz to BROKEN. Oh well. Apr 26 10:40:20 hm, why? Apr 26 10:40:26 doesn't build Apr 26 10:40:29 There's a new release; I was just about to try to update Apr 26 10:40:32 dwmw2_gone: Because cable/fiber. :) Apr 26 10:40:47 I reported the issue to upstream. Apr 26 10:40:48 FTTH, not FTTC. Apr 26 10:40:53 mangix: got a link? Apr 26 10:41:17 dwmw2_gone: https://github.com/domoticz/domoticz/issues/4751 Apr 26 10:41:25 thanks Apr 26 10:42:54 let me guess, you replaced minizip with a newer version? and just marked broken anything that used the old one? :) Apr 26 10:43:13 gotta keep those version numbers absolutely bleeding... Apr 26 10:44:16 nah, not just a newer version but 'minizip-ng' :) Apr 26 10:44:18 maybe it's related to https://github.com/openwrt/packages/blob/38f01ad2c9738c6c5a5dbda85019bb9cf5bc10f8/libs/minizip/Makefile#L29 Apr 26 10:44:51 dwmw2_gone: the previous URL redirects to the new one Apr 26 10:45:16 Did I not add minizip to openwrt specifically for the purpose of building Domoticz without having to use its own built-in one? Apr 26 10:45:26 "pacakge x didnt' have commits in 6 hours, so I've marked it as dead and have switched to the active fork...." Apr 26 10:45:27 Is there anything else actually using minizip in openwrt? Apr 26 10:45:46 did we upgrade the library and break its *only* user? Apr 26 10:45:56 hmm good question Apr 26 10:46:10 no no, that's irrlevant, the version numbers _must_ be latest!!!!11! Apr 26 10:46:33 :) Apr 26 10:47:34 maybe it's just the compat that needs to be flipped on. Apr 26 13:24:06 can i see the compressed size of a file on jffs2? Apr 26 15:44:03 nick[m]3: If you need to look at ath9k eeproms, also consider https://github.com/rsa9000/atheepmgr which is very mature Apr 26 15:44:43 hurricos: thanks for the hint Apr 26 15:45:12 That is the one I used to experiment with radios :^) Apr 26 15:45:33 The general advice to "not demand more of your radios than your hardware advertises" is almost always perfectly reasonable Apr 26 15:45:50 *but* sometimes it pays to tweak the curves e.g. for a high-density deployment ;) Apr 26 15:46:22 s/curves/curves *downwards*,/ Apr 26 20:51:04 This will hopefully settle most of the worries about the 100 Hz change… :) https://github.com/openwrt/openwrt/commit/3326b5e75c277b4fac21bffd2085df4aa40d2775#commitcomment-49996662 Apr 26 20:57:51 make package/system/usign/compile Apr 26 20:57:56 gives me a usign for the target system Apr 26 20:58:00 make package/system/usign/host-compile Apr 26 20:58:02 is not defined Apr 26 20:58:05 how do i build a host usign? Apr 26 20:58:22 (oh, I see now I asked this before - but nobody answered at the time) Apr 26 22:39:48 mangix: ping Apr 26 22:43:58 pong Apr 26 23:33:30 mangix: what exactly is the fallout of this dbus/cmake thing you did some time ago? Apr 26 23:33:34 is it now all fine again? Apr 26 23:33:48 I don't want a whole lot of software end up in openwrt.git Apr 27 01:47:36 [120143.211763] do_page_fault(): sending SIGSEGV to ip for invalid write access to 00001fc8 Apr 27 01:47:39 [120143.220161] epc = 00402421 in ip-tiny[400000+38000] Apr 27 01:47:41 [120143.225263] ra = 00402419 in ip-tiny[400000+38000] **** ENDING LOGGING AT Tue Apr 27 02:59:56 2021