<PaulFertser>
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.
<PaulFertser>
(beginning of it is usually for MACs and then at 0x1000 you get caldata)
<nick[m]3>
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.
<nick[m]3>
PaulFertser: already searched for it :) my wifi mac is at 3 positions
<nick[m]3>
lets see what is the correct position ^^
<PaulFertser>
nick[m]3: existing boards use either 0x5000 offset for ath10k data.
<PaulFertser>
s/either//
<nick[m]3>
the call is: caldata_extract "art" 0x5000 0x844
<nick[m]3>
if I try that manual, it fails with: caldata: failed to extract calibration data from /dev/mtd7
<nick[m]3>
maybe I'm doing something wrong?
<nick[m]3>
so the offset looks correct
urjaman has quit [Quit: WeeChat 3.0]
urjaman has joined #openwrt-devel
<nick[m]3>
PaulFertser: or did I misunderstood something? the call should work, or?
goliath has joined #openwrt-devel
<nick[m]3>
whups, I forgot to set env variable firmware. now it works
danitool has joined #openwrt-devel
zatwai has quit [Quit: ZNC 1.8.2+deb2~bpo10+1 - https://znc.in]
<nick[m]3>
thanks a lot for your help
zatwai has joined #openwrt-devel
decke has joined #openwrt-devel
ashkan has joined #openwrt-devel
ashkan has quit [Client Quit]
ivanich has joined #openwrt-devel
SamantazFox has joined #openwrt-devel
galak has quit [Read error: Connection reset by peer]
arnd has quit [Read error: Connection reset by peer]
Tsesarevich has quit [Read error: Connection reset by peer]
galak has joined #openwrt-devel
arnd has joined #openwrt-devel
Tsesarevich has joined #openwrt-devel
<PaulFertser>
nick[m]3: :)
sbrown has quit [Remote host closed the connection]
sbrown_ has joined #openwrt-devel
lmore377 has quit [Quit: No Ping reply in 180 seconds.]
lmore377 has joined #openwrt-devel
glyph has quit [Read error: Connection reset by peer]
glyph has joined #openwrt-devel
glyph has quit [Client Quit]
Tapper has joined #openwrt-devel
glyph has joined #openwrt-devel
wigyori has joined #openwrt-devel
wigyori has quit [Changing host]
<dwmw2_gone>
rsalvaterra: surely we should actually build the jffs2 images with the same compression algorithm we want to use at runtime?
<dwmw2_gone>
Rather than compressing the image with zlib and then using zstd for writes?
<dwmw2_gone>
Or is that irrelevant because we don't really use jffs2 for the real fs images; only for overlay?
<rsalvaterra>
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).
<Habbie>
if you'll allow me to butt in to this topic - do i understand correctly that /rom is compressed and /overlay is not?
<dwmw2_gone>
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.
<karlp>
they'r eboth compressed with whatever the filesystem in use there uses...
<dwmw2_gone>
We are discussing the compression algorithm to use on the latter.
<Habbie>
dwmw2_gone, very good, i'll follow with interest :)
<dwmw2_gone>
jffs2 can use zlib
<dwmw2_gone>
OpenWrt has patches to make it use lzma (adding that to the kernel since it isn't there already)
<rsalvaterra>
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. :)
<dwmw2_gone>
rsalvaterra is now proposing the addition of zstd
<dwmw2_gone>
yeah, the patches look sane enough. I was just not entirely sure anyone had really shown any *benefit*
<dwmw2_gone>
since we can only ever compress a 4KiB page at a time, the compressors have a slightly different task
<mangix>
jffs2 is indeed mostly dead
<mangix>
any alternatives?
<rsalvaterra>
dwmw2_gone: I also thought about bumping zstd compression priority in jffs2 to the top, but I haven't done so.
<karlp>
dead/stable... ;)
<karlp>
upstream don't care about our little devices....
<Namidairo>
did anyone bench startup times when ubifs got switched over
<rsalvaterra>
karlp: I do care… I'm a bit obsessive in that regard, admittedly. :P
<mangix>
i wonder why nilfs2 is also seemingly dead
<karlp>
because it's vendor backing went away I suspect.
<dwmw2_gone>
jffs2 basically works; we're reluctant to add new features.
<rsalvaterra>
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.
<dwmw2_gone>
Sure, but why did we even have *that*?
<mangix>
because lzma
<karlp>
probably the same reason as zstd, "everything must be better compressed, because reasons!"
<Namidairo>
storage is precious.
<karlp>
storage is _sometimes_ precious
<rsalvaterra>
Especially precious when you only have 8 MiB of it, total.
<mangix>
4MB routers
<dwmw2_gone>
This storage is rarely written and slow to write. So compress with -z9 :)
<karlp>
so... the original commit will clearly have metrics right? ;)
<dwmw2_gone>
adding a new algo and still using -z3 is a bit weird.
<rsalvaterra>
mangix: Not 4 MiB yet, but I'm trying. ;)
<dwmw2_gone>
hahaha
<karlp>
this is an easy answe? right? ;)
<karlp>
oh, that's right, these sorts of things ar emostly done on religion....
<rsalvaterra>
dwmw2_gone: Noted. I can increase the compression ratio, but that will use more RAM. ;)
<Namidairo>
nobody talk about that 100hz patch
<dwmw2_gone>
only as we're writing it.
<mangix>
doesn't decompression also use more RAM?
<dwmw2_gone>
nah, decompression is simple
<dwmw2_gone>
compression builds up a history buffer of what has gone before, so that we can say "repeat that bit"
<rsalvaterra>
Namidairo: The 100 Hz patch was an eager merge by ldir, but I will get some numbers on it ASAP.
<dwmw2_gone>
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.
<rsalvaterra>
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… :/
<Namidairo>
it's all fairly inconsequential to me but I'm sure some sort of boot time aficionado will love it.
<dwmw2_gone>
That's one 329-line file
<rsalvaterra>
Why is everyone so worried about boot times, especially in OpenWrt? It's supposed to be a boot-up-and-forget system, no? :P
<mangix>
rsalvaterra: because downtime sucks
<Namidairo>
it adds up because we're flashing images all day /s
<rsalvaterra>
mangix: Yeah, but does it cost money? If so, you need redundancy, not faster boot. ;)
<dwmw2_gone>
Even when I had redundant lines I had a single OpenWrt box terminating them both :)
<mangix>
pff, YOLO computing
<dwmw2_gone>
It's why OpenWrt has the teql support :)
<stintel>
heh :P I have a single line and redudant openwrt routers :P
<dwmw2_gone>
I suppose I do have a spare lantiq box here which could be put back into service if my hh5a blows up :)
<dwmw2_gone>
not *quite* a hotswap spare but close
<rsalvaterra>
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).
<dwmw2_gone>
I like it; does the job nicely for VDSL and wifi on both bands
<dwmw2_gone>
The Lantiq usb sucks though; both boxes I've had just seem to suffer random crashes when I plug anything interesting in
<dwmw2_gone>
so the Domoticz home automation now lives on a wndr3800 which is a bit underpowered for the job but at least it stays up
<rsalvaterra>
Is it only VDSL? Does it support Annex A ADSL2+?
<dwmw2_gone>
yeah it'll do that too.
<rsalvaterra>
Nice. We don't have vectoring here, only plain-old ADSL2+.
<mangix>
in master I silently set domoticz to BROKEN. Oh well.
<dwmw2_gone>
hm, why?
<mangix>
doesn't build
<dwmw2_gone>
There's a new release; I was just about to try to update