isak has quit [Read error: Connection reset by peer]
isak has joined #openwrt-devel
<schmars[m]>
if i were to look into /etc file change history over time (while the device is running) would i go for supprting jffs2, ubifs, f2fs, or all of them? is this a choice that simple depends on each device, or is one of them a standard that all openwrt is gravitating towards and that eventually most supported devices will be based on?
<schmars[m]>
(i feel like historic diffs would be a very nice addition to the way openwrt and luci handle config changes)
<slh>
the filesystem (mostly-) depends on the target flash technology used, spi-nor (jffs2), NAND (ubi), block storage (ext4 or f2fs, depending on the storage size), more is very much imaginable (e.g. the OpenWrt derived TurrisOS uses btrfs)
<schmars[m]>
got it, super helpful :-) thank you
<slh>
e.g. on NAND, ubi pretty much has no alternative, as its the layer doing the much needed ECC and wear levelling on this rare (and faulty) NAND
<slh>
but by far not everything is NAND
<schmars[m]>
i think i might be lucky in that i can focus on jffs2
<schmars[m]>
love it, first prior art i found is a jffs2 transaction extractor written in erlangscript
<schmars[m]>
found jefferson, cool, i'm all set. thanks again
janvenekamp has quit [Remote host closed the connection]
lmore377 has quit [Remote host closed the connection]
<karlp>
with that fstools in place, can I just not pass a root= parameter from uboot, and just mark gpt partitions with the well known uuids for linux rootfs for arm32 for instance? or is it not that magical
<robimarko>
That wont work with OpenWrt
<robimarko>
You need the kernel to find and mount rootfs before anything can be done
<karlp>
ok, was just reading too much into the comments in fstools then :)
<karlp>
all this "just use uuids and labels, don't rely on assumed ordering of mmc blocks" isn't very convenenient when "oh yeah, now you need an initrd to find the labels"
<robimarko>
I would shorten that to use UUID-s
<robimarko>
Are you using a boot script or?
<karlp>
I am at the moment, and I've added aliases for mmc0/mmc1 as apparently that was allowed after all in the end,
<karlp>
just trying to do the "right" "modern" thing.
<karlp>
but so far it still only comes up nicely if I give it root=/dev/mmcblock0p2, or root=PARTUUID=blah.
<robimarko>
Well, that has been my experience as well
<\x>
whats the expected sqm cake bw on 60xx robimarko
<\x>
seems it can route gigabit on codel
<robimarko>
\x: No idea
<\x>
i cant test cake it seems, it weirds out
<robimarko>
Havent even tried networking on it
<robimarko>
To put it mildly, its low-low priority
<\x>
so all of those issues where wifi doesnt get dhcp on dumb ap mode and i cant get sqm working is easily fixable by disabling all of those nss scripts on boot
<f00b4r0>
robimarko: looks like I'll finally be getting my MochaBIN next week :)
<\x>
and theres cpu usage now when routing once all those nss shit is disabled
janvenekamp has joined #openwrt-devel
<\x>
wifi sucks though in lean's qsdk mishmash, stock does 700/500, here its the reverse 450/700, 450 down like wtf its like ac wifi perf
<\x>
and downgrading the connection to ac doesnt even go past 300 in downloads
goliath has joined #openwrt-devel
<\x>
but yeah so far thats fine with me, thats usable, dont care much on wireless, my services, nlbwmon, unbound, adblock, runs fine, stays arounf < 200M memory usage, ill deply this soon as my gateway
<\x>
<robimarko> \x: There is no way that thing routes, let alone shapes 1G with that low CPU usage
<karlp>
so, chasing the logs, nbd just declared 100MB to be the point where you should make f2fs instead of ext4, in 2016? https://git.openwrt.org/?p=project/fstools.git;a=commit;h=fe514c9a20365ba00232c2c981463f43a4a41a7d but I'm still not sure what led to that choice?
felix has quit [Read error: Connection reset by peer]
<karlp>
anyone have any objection to me removing the CONFIG_SUNXI_SD_BOOT_PARTSIZE (from 2016) and moving to the generic USES_BOOT_PART/Features=boot-part that everyone else uses since 2018?
Obi-Wan has quit [Remote host closed the connection]
torv has joined #openwrt-devel
<stintel>
karlp: looks like I confused things, legacy-sdcard is also a feature, but it's used on the device for sysupgrade, not to generate the sdcard image in buildroot
Vaughn has quit [Read error: No route to host]
zx2c4 has quit [Read error: No route to host]
Vaughn has joined #openwrt-devel
chder has quit [Remote host closed the connection]
zx2c4 has joined #openwrt-devel
Obi-Wan has joined #openwrt-devel
arnd has quit [Read error: No route to host]
<karlp>
ok, yeah, I found quite a few variations of "gen_sdcard" under various targets, all with various differences that are probably important, not going down that path right now...
arnd has joined #openwrt-devel
chder has joined #openwrt-devel
grid has quit [Ping timeout: 480 seconds]
grid has joined #openwrt-devel
Ansuel has quit [Read error: Connection reset by peer]
<stintel>
karlp: yeah, I think I made the same decision
<stintel>
but ideally we come up with a generic script with some switches that makes it usable for all targets
<stintel>
huge potential for breakage though :)
borek has joined #openwrt-devel
<karlp>
I'm more interested in just making a new "emmc that's not jsut a sdcard" script rather than trying to unify all the platform differences on sd card layouts :)
<robimarko>
karlp: What features do you see in a emmc specific script?
<robimarko>
eMMC and SD cards are pretty much the same to U-boot and Linux, expose a GPT table and thats it
<karlp>
I want uboot on emmc boot partition 1, not on a separate "boot" partition at the front of the user partition.
<karlp>
uboot env I don't have a strong preference, end of the boot partition 1, or on boot partition 2..
<f00b4r0>
rmilecki: it's unclear to me what the status of GT-AX6000 is in 21.02 following this commit of yours: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=28ab4f395541ad4b969879042f58fd19d13a596a, could you shed some light? (preparing release notes)
<robimarko>
karlp: Thats nothing really eMMC specific
<karlp>
ok, got a fit image on board, but it gives me "lzma compressed: uncompress error 7" when it starts uncompressing kernel image, what am I missing for that?
<karlp>
robimarko: well, it kinda is, the emmc boot partition 1 is the fixed 4MB hardware partitions,
<karlp>
you can't just "copy the img to the disk" like you can with the sdcard boot partition setup.
<robimarko>
Error 7 was read error if my memory serves me
<robimarko>
karlp: good point on hw partitions
Ansuel has joined #openwrt-devel
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<rmilecki>
f00b4r0: unsupported
<rmilecki>
f00b4r0: wip
<f00b4r0>
rmilecki: ok. Shouldn't it be marked BROKEN := y then?
<f00b4r0>
otherwise we'll have images built and people trying them
<rmilecki>
f00b4r0: "TARGET_DEVICES" line is commented out
<f00b4r0>
oh
<rmilecki>
we went back and forth with BROKEN vs. commenting out TARGET_DEVICES few times I got lost what is correct solutin
<f00b4r0>
indeed.
<f00b4r0>
sorry I missed that :)
<rmilecki>
n
<rmilecki>
np
<Ansuel>
IMHO broken should be the correct one... much quicker to check broken package than inspect the akefile and fine commended targets
<Ansuel>
broken targets*
<rmilecki>
Ansuel: i'm ok with any option, whatever you agree on
<Ansuel>
i would use BROKEN
<rmilecki>
e9f7923a1d4b327ef4b9ac25fbe197f2b4ea61d7 ("treewide: mark devices as BROKEN instead of commenting out") (by ynezz)
<rmilecki>
ah, we also had DEFAULT := n for some time 504000d520ac8699137bd6b8dbd55f723f34bfbe ("treewide: use DEFAULT := n to disable non-broken devices") (by ynezz)
<Ansuel>
soo as you can see commeting them out is ALWAYS a bad practice
<rmilecki>
but then we also had someone commeting out as an addition to the BROKEN:=y see fd67908647390b916470501c88b4f5258123da95 ("scripts: mkits.sh: Allow legacy @ mode for dts creation")
<rmilecki>
so I really got lost ;)
* f00b4r0
is poring through GH issues looking for regressions. Dear lord, the headache ;P
<Ansuel>
rmilecki well the all 3 accomplish the same thing
<Ansuel>
stop building image by default
<rmilecki>
right
<Ansuel>
sooo it's really how someone decided to do it... IMHO broken should be the general rule
<rmilecki>
Ansuel: so the question I believe is: BROKEN vs. DEFAULT:=n ?
<Ansuel>
default:= should be used for device that have no tester if they actually work and require manual compilation
<rmilecki>
Ansuel: ah, ok
<rmilecki>
sounds good & sane
<Ansuel>
broken should be used for device that needs to be converted or won't compile at all
<Ansuel>
99% of the time broken should be the correct flag IMHO
<rmilecki>
understood
<rmilecki>
i will follow that rule
<robimarko>
f00b4r0: Our prayers are with you. GH regressions are not funny
<f00b4r0>
robimarko: the SNR in the issues section is also not funny ;P
<robimarko>
f00b4r0: Not disagreeing there
<f00b4r0>
heh
<f00b4r0>
looks like we've given up using tags too, sadly
<Ansuel>
mhhh what regression are we talking about?
<Ansuel>
or i'm merging this (souds like a threat)
<robimarko>
Ansuel: I am not seeing the issue
<robimarko>
I hope it isnt build vs built
<Ansuel>
i added extra text about the wiki download page
<Ansuel>
since it's not my main language wonder if there is a better form to describe it
<robimarko>
LGTM, I dont find it confusing
dangole has joined #openwrt-devel
valku has joined #openwrt-devel
<f00b4r0>
a lot of issues appear completely stale and/or outdated. Maybe we do need a stalebot ;P
<Ansuel>
90% of the issue will be flagged as stale
borek1 has joined #openwrt-devel
snh_ has joined #openwrt-devel
madwoota has quit [Ping timeout: 480 seconds]
snh has quit [Ping timeout: 480 seconds]
GNUmoon2 has quit [Ping timeout: 480 seconds]
borek has quit [Ping timeout: 480 seconds]
borek1 is now known as borek
<f00b4r0>
Ansuel: is that a problem? Point being: let's close them and improve SNR on issues that need attention
<Ansuel>
some issue may be still relevant but just stalled :(
<f00b4r0>
I see issues related to 19.07 still open. That's just noise at this point
<stintel>
maybe stalebot can skip some labels
snh_ has quit [Remote host closed the connection]
GNUmoon2 has joined #openwrt-devel
<stintel>
the thing is, looking at the issues and seeing 1.7k is not very confidence inspiring for users, and demotivating for developers
<Ansuel>
yes 1.7k issue is a real problem...
madwoota has joined #openwrt-devel
<f00b4r0>
stintel: +1
<Ansuel>
stintel what tag were you thinking ?
<stintel>
dunno
<stintel>
was just an idea
<karlp>
just because things were reported against 1907 doesn't make them automatically noise...
snh has joined #openwrt-devel
<f00b4r0>
karlp: yes it does. The answer to such reports is "please check if applies to current releases and reopen" + autoclose
<karlp>
you can say that, and you'll be in grand company of all the othe rgeneric software companies over the years, it still doesn't make it automatically noise
<stintel>
problem is that users cannot reopen issues iirc
<Ansuel>
they can leave comments tho
<karlp>
making users continually retest, repaste a version number and go, "yep, still a problem, which you'd know if you followed my recreation steps"...
<f00b4r0>
stintel: s/reopen/submit a new one/ :)
<karlp>
I know most of them are,
<stintel>
no
<stintel>
submit is even worse
<stintel>
submit new*
<karlp>
but i'm tired of (as a user) seeing my issues get reported, then closed as "old" without ever getting looked at.
<stintel>
yeah, or even worse, PRs
<f00b4r0>
karlp: 1.7k issues is simply unmanageable. Nobody's looking. We might as well disable issues reporting at that point :P
<stintel>
I just closed one :P
* karlp
feels taht 1.7k is nothign...
<f00b4r0>
stintel: o/
<f00b4r0>
karlp: feel free to triage then
<Habbie>
1.7k issues on the wall, take one down, 1.7k issues on the wall
<robimarko>
BTW, what was the issue with NAND, ADM rework?
<Ansuel>
good old sizeof pointer instead of value
<robimarko>
I have a feeling that compiler was screaming as well
<Ansuel>
adm was the culprit but nandc made the kernel panic as the value was wrongly checked
<Ansuel>
nope no scream the code itself was correct problem was the logic
<Ansuel>
(about the topic tsens patch reviwed but still nobody picked them....)
<robimarko>
The first patch wasnt reviwed, maintainer said he would pick them once Bjorn reviewed the first one
<robimarko>
As he had a comment that was addressed but Bjorn being Bjorn nothing happened
<robimarko>
Mailbox, APCS and rest of DTS patches got ignored as well
<Ansuel>
they will be picked for 6.3 :D
<robimarko>
Maybe
<[Pokey]>
Not at all wanting to be pushy here, but seeing as theres been metions of PRs getting updated, how long does it usually take for a device support PR to be reviewed?
<robimarko>
That can be everything from hours to months and to never
* [Pokey]
considers the meaning of life, the universe and everything
<[Pokey]>
Okay :P
<[Pokey]>
I shall be patient and optimistic!
<robimarko>
Device target seems to matter the most
<robimarko>
As some targets are rather popular and active while some are rather obscure at this point
<[Pokey]>
being am MT7621 probably makes it "ugh heres another one"
<Ansuel>
robimarko i wonder if the user on the xiaomi topic are collaborative...
<Ansuel>
also wonder if you want to test the patch about the timeout issue...
<Ansuel>
will prepare it later in the evening
borek has quit [Remote host closed the connection]
borek has joined #openwrt-devel
<robimarko>
Ansuel: Yeah, I can test it
<robimarko>
Had to remove the AP today before I could test single band for timeouts
<Ansuel>
is it a day enough time repro the error?
<robimarko>
Yeah, its usually couple of hours max
<Ansuel>
wow couple of hours NICE!
<Ansuel>
so you had the error with single band?
<robimarko>
No, I had to turn the AP before I could test
<Ansuel>
rip
<Ansuel>
on second tought i'm still convinced it may be a problem with multiple interface handling packet
<Ansuel>
as you never notice MSDU error
<Ansuel>
and you don't use WDS
<Ansuel>
(these 2 are the only way to trigger a counter imbalance)
<Ansuel>
my idea is to move the make the counter per interface but i need to check if it's doable
<Ansuel>
(btw yes the flush is called per interface, i tested that yesterday)
<Ansuel>
(but we need proof that the problem is in the fact that the thing timeouts are more packets comes)
noltari has joined #openwrt-devel
<karlp>
on master, (at least?) I've some packages getting generated with the opkg info showing "Version: 1" and the ipk filenames likewise. on 21.x and before, it should show the contents of my PKG_VERSION field? it seems to be now showing the PKG_RELEASE field? but.. not for all packages? seems to be doing it for packages that have their souce within the package definition?
Ansuel has quit [Read error: Connection reset by peer]
Ansuel has joined #openwrt-devel
noltari_ has quit [Ping timeout: 480 seconds]
<robimarko>
Ansuel: I am going a bit crazy on SPI here
rua has quit [Ping timeout: 480 seconds]
<robimarko>
SPI and DMA drivers have minimal changes and nothing looks suspicous
<robimarko>
Even confirmed that pinctrl is actually set with a script
gladiac has joined #openwrt-devel
<karlp>
ok, weirder. if I have a package in a feed that is src-link, it fails to run the PKG_REV:=$(shell git describe --long --dirty) line somehow and PKG_VERSION:=$(PKG_REV) ends up empty, and I get PKG_RELEASE as the only thing int he name.
<karlp>
(even though that local src-link is a git repo, and this used to work)
<karlp>
if the same package, same code is in a feed with src-git, it correctly generates the PKG_VERSION?
rua has joined #openwrt-devel
<karlp>
ok, this is apparently, "feeds: use git-src-full to allow Git versioning"
borek has quit [Quit: borek]
<karlp>
if we've converted teh entire feeeds.conf.default to src-git-full, it doesn't sound like the shallow version is really getting us anywhere...
<karlp>
bah, I can't see how this has only broken just now, they've been --depth=1 since 2012.
Ansuel has quit [Ping timeout: 480 seconds]
Ansuel has joined #openwrt-devel
<robimarko>
Ansuel: Figured it out, its the damn CS GPIO
<Ansuel>
they changed something or??
<robimarko>
No idea
<robimarko>
But if I allow QUP to drive the pin it works
<robimarko>
I always though that it was broken, but its broken only onv1
<robimarko>
Other versions just use the force function to set CS level
<Ansuel>
Mangix ping?
<Ansuel>
robimarko at least you know the cause and bisect wasn't needed
<robimarko>
Yeah, I am gonna see if binding changed or something like that
gladiac has quit [Quit: k thx bye]
<Ansuel>
btw did ath11k mess the debugfs directory naming ?
<Ansuel>
aside from the name in debugfs ath11k stuff is under ipq8074 hw2.0
<Ansuel>
(bridg idea to put space in the naming)
<robimarko>
No idea, but it was kind of stupid from the start
<robimarko>
They moved some of the FW stats out of debugfs recently
<robimarko>
Ansuel: Well, they are not even getting the CS GPIO
<robimarko>
Yeah, looks like they just convert the currency
<stintel>
robimarko: ~EUR61
<Ansuel>
yep it's ipq806x
<Ansuel>
LOL
<stintel>
my favorite :P
<Ansuel>
but they changed that new device are not openwrt based
<robimarko>
The forewer kind of semi-broken SoC
<robimarko>
I had an idea to try and hook the kernel offloading to NSS FW via driver
<robimarko>
I had to slap myself after that idea
<Ansuel>
the other day with nss crypto
<Ansuel>
today with offload
<Ansuel>
you really want to use the bin ehehehhe
<Ansuel>
remember that with wifi offload i reached 3.2 gbps of wifi traffic :P
<Ansuel>
and require only nss-drv
csrf1 has joined #openwrt-devel
<robimarko>
bps are getting left on the table so its annoying me
bluew has joined #openwrt-devel
<robimarko>
FW is redistributable
<robimarko>
So my thinking is why not hook onto it from one of the standard kernel interfaces rather than from that nss mess
<Ansuel>
well it's all payload and magic values
<robimarko>
exactly
<Ansuel>
at the very end to make the payload work on the fw
<Ansuel>
they just have to match struct size nothing else
<robimarko>
like, how hard could it be to offload tcp
<Ansuel>
so we can somehow make that configurable
<robimarko>
pppoe and basic stuff like that
<Ansuel>
it depends how much you want to offload
xback has quit [Remote host closed the connection]
<Ansuel>
big task would be make everything works with a clean and custom driver
<Ansuel>
but first thing would be load and setup the fw and check if it works with the qsdk module
<robimarko>
considering the mess and amount of components it currently requires rewrite seems easier
<robimarko>
crypto would be rather easy for anybody that ever did kernel crypto drivers
<robimarko>
in the ends its eip197
<Ansuel>
well the real offload aka ecm is not sustainable so yes that will be easier to rewrite than add all the patch
<Ansuel>
but things like wifi offload would require just the required api to fill the various payload
<Ansuel>
i guess same for crypto
xback has joined #openwrt-devel
<Ansuel>
main problemfor tcp offload is all the logic to receive packet from nss
<robimarko>
Crypto looks to be the easiest to tackle
<robimarko>
As its self-contained
<robimarko>
But at the same time, I know nothing of crypto and let alone kernel crypto
<Ansuel>
well for this kind of stuff we can't rush thing or we will end up with nothing working and no idea why
<Ansuel>
mhhh we should ask cote
<robimarko>
cote?
<robimarko>
There isnt much that you can mess up with crypto
<robimarko>
Its EIP197 engine, has its FW
<robimarko>
But doesnt look like its compatible with the upstream EIP driver
<Ansuel>
cotequeiroz
<robimarko>
Oh yeah
<Ansuel>
have some openssl engine written
<Ansuel>
and to me it seems the right guy for this kind of thing
<Ansuel>
upstream EIP is a modified variant than the real one
<Ansuel>
also if i understand how pricey these fw are
<Ansuel>
they totally have some internal thing to validate the fw
<Ansuel>
well time to debug ath11k... pls someone save me
<robimarko>
Aint no rest for the wicked
<robimarko>
Ansuel: Ok, so the upstream EIP driver and the mini FW
<robimarko>
Are basically using the EIP197 in EIP97 compatibility mode as no advanced features are used
Borromini has quit [Quit: leaving]
mrnuke_ has joined #openwrt-devel
mrnuke has quit [Read error: Connection reset by peer]
<Mangix>
HW crypto. Sounds useless.
<Mangix>
My understanding of it is the context setup kills any speedup you'll getm
<robimarko>
Well, kind of
<Mangix>
Unless doing bulk operations.
<Mangix>
Which is does when???
<Mangix>
*done
<robimarko>
Never
<slh>
bulk would be mostly disk encryption, which isn't the most common task on the typical router target
<Ansuel>
i just killed a mosquito with 2 finger... think i'm too focused...
<Mangix>
Sure. I've heard of OpenVPN being another user. Don't most people use wireguard?
<robimarko>
Crypto is plenty fast on this thing anyway
<robimarko>
But shit networking driver is killing it
<robimarko>
It doesnt even implement checksum offloading
<Mangix>
Sure.
<Mangix>
Neither does ag71xx actually...
<slh>
just that it doesn't hurt that much on ath79, as the SOC wouldn't do 'fast' anyways, as it does on the plenty fast ipq807x which does ship with 2.5/5/10 GBit/s interfaces
<robimarko>
Well, aint nobody expecting ath79 do route 10G and do AX on the side
<Mangix>
Sure, it struggles with 1G too
<Mangix>
Looks like some stuff should be backported
<slh>
it's been a while since I last tested it, but ~600 MBit/s on ipq8071a/ 1.4 GHz (xiaomi ax3600)
<robimarko>
You can do better,but with SW offloading and IRQ balancing
<robimarko>
Which is still not good with 2x 10G
<slh>
I'm not benchmarking with software flow-offloading (as it's meaningless for performance comparisons), but, yes
<robimarko>
NSS is so weird
<robimarko>
NSS-DRV loads the FW and acts like a central point
<Ansuel>
nss-drv expose api
<robimarko>
Well
<robimarko>
It actually registers a netdev driver
<robimarko>
Like a full blown ethernet driver
<Ansuel>
yes
<Ansuel>
as with nss loaded
bluew has quit [Quit: Leaving]
<robimarko>
And somehow attaches the existing netdevs
<Ansuel>
everything pass to the nss cores
<robimarko>
Yeah
<Ansuel>
the nss-dp have slowpath and fastpath
<Ansuel>
nss-drv overwrite the ops
<dwfreed>
oh, I think the warranty has expired on my nbg6817; I should crack it open and get serial set up
<robimarko>
That is how it suddenly every possible standard netdev offloading
<Ansuel>
it's ""handy""
<robimarko>
Ansuel: I am interested would just having NSS-DRV with FW loaded get us better performance
<robimarko>
Looks like it could
<Ansuel>
as I said some week ago it can as nss have more interrupts so it can be that handled the packet in a better way
<robimarko>
I know that TIP actually has threaded NAPI enabled on the NSS-DRV netdev
<Ansuel>
also could be that nss itself supports offload feature (timestamp and checksum)