<aparcar[m]>
Grommish_: what's the good word on rust?
philipp64 has joined #openwrt-devel
philipp64 has quit []
victhor has quit [Ping timeout: 480 seconds]
philipp64 has joined #openwrt-devel
philipp64 has quit []
<digitalcircuit>
NBG6817 eMMC clock update - as shown in logs on https://github.com/openwrt/openwrt/pull/3954#issuecomment-948108446 , it looks like mmci-pl18x (drivers/mmc/host/mmci.c) might be getting the wrong values..? I suspect it's time to throw pr_debug("debug stuff here") messages throughout the entirety of "drivers/mmc/host/mmci.c"...
<digitalcircuit>
host->f_min should definitely not be into the MMC High Speed region, as it's used before HS is even negotiated.
<digitalcircuit>
That said, it still doesn't boot after forcibly overwriting "host->f_min" and "host->f_init", though I set those to 400 kHz. Maybe I needed to set it to 200 kHz (I only found the real minimum afterwards).
<digitalcircuit>
Alternatively, just drop-in replace drivers/mmc/host/[mmci.c|mmci.h] from v5.4 into kernel v5.10 and see if it compiles and boots.
* digitalcircuit
shall try that
<slh>
good idea, I just hope there aren't too man API changes in the way
<digitalcircuit>
slh: Fingers crossed! And I'm willing to / try / to kludge things if it fails to compile, but I'm not going to spend too long on it (my next approach would be to insert pr_debug()s everywhere on both 5.4 and 5.10).
<digitalcircuit>
Thankfully MMC is an older standard, so it's not seen a ton of development (unlike, say, the amdgpu driver).
Andi_ has quit [Remote host closed the connection]
Andi_ has joined #openwrt-devel
valku has joined #openwrt-devel
Tusker has quit [Quit: Hey! Where'd my controlling terminal go?]
danitool has quit [Ping timeout: 480 seconds]
Tusker has joined #openwrt-devel
thosmos has quit [Quit: Leaving]
<digitalcircuit>
Wat. Just replacing mmci.c and mmci.h in v5.10's kernel with the older files from v5.4's drivers/mmc/host/[mmci.c|mmci.h] resulted in a successful compilation. I have NOT yet tested this on the router though.
dedeckeh has joined #openwrt-devel
<slh>
that certainly helps in regards to trying to bisect it -- assuming that this frankenstein boots up (big 'if')
<slh>
more because of the question if the issue is actually caused by changes in the mmc subsystem (and not caused by seemingly unrelated arch changes), than actual API issues
decke has joined #openwrt-devel
clayface has joined #openwrt-devel
clayface_ has quit [Ping timeout: 480 seconds]
valku has quit [Remote host closed the connection]
rmilecki has joined #openwrt-devel
Tusker has quit [Ping timeout: 480 seconds]
Tapper has joined #openwrt-devel
pmelange has joined #openwrt-devel
Tusker has joined #openwrt-devel
tpk007__ has joined #openwrt-devel
danitool has joined #openwrt-devel
Acinonyx__ is now known as Acinonyx
dangole has joined #openwrt-devel
zarzarzar has joined #openwrt-devel
<zarzarzar>
Hi! I'm not sure I understand the concept of SDK in OpenWrt environment. In my opinion, it should contain all the libraries and header files from packages installed to my image (=all the files that were installed through Build/InstallDev targets), but it doesn't. Is it possible to generate "SDK" with all target libraries included?
dangole has quit [Remote host closed the connection]
<aparcar[m]>
zarzarzar: what do you want to do? SDK is for package building, ImageBuidler for image building
eduardo010174 has joined #openwrt-devel
goliath has joined #openwrt-devel
<zarzarzar>
aparcar[m]: I want to use OpenWrt as a general purpose embedded distro for our new device. I've generated image for this device and I want to share SDK (based on this image) with our developers. They'll use it to develop and build new software. So, because of it I need a relocatable cross-toolchain with all libraries and header files :)
<aparcar[m]>
zarzarzar: you should be able to use the SDK and then use the image builder to bake everything together into an installable firmware image
eduardo010174 has quit [Quit: Leaving]
pmelange1 has joined #openwrt-devel
pmelange has quit [Read error: Connection reset by peer]
pmelange has joined #openwrt-devel
hitech95 has quit [Quit: Page closed]
pmelange1 has quit [Ping timeout: 480 seconds]
<zarzarzar>
aparcar[m]: OK, I'll try to explain it from another side. I mark "libgpiod" to be installed to my image and I also generated SDK. My colleague want to build a simple C program that uses libgpiod. So I'll give my built SDK to him and I expect that he'll be able to build his program. But the problem is that SDK doesn't contain neither gpiod.h nor libgpiod.{so,a}. So... my question is how to put these files into SDK? I see that they are installed
<zarzarzar>
into staging_dir but not in SDK.
Andi_ has quit [Ping timeout: 480 seconds]
Andi_ has joined #openwrt-devel
danitool has quit [Ping timeout: 480 seconds]
victhor has joined #openwrt-devel
<karlp>
iirc, he uses the sDK to build libgpiod himself...
pmelange has quit [Read error: Connection reset by peer]
pmelange has joined #openwrt-devel
<zarzarzar>
karlp: but of course it'll create incompatibilities with actual image (e.g. libgpiod versions could be different in my image and in colleague's build setup)
<karlp>
then it's image builder?
<rsalvaterra>
hauke: I'm giving up on the 32-bit NEON mvebu split. WireGuard and cryptsetup performance is the exact same. OpenSSL is slower(!). This should pretty much settle it, once and for all. :)
<karlp>
I've not used it much, but in our team we just have a branch of openwrt in git, and we keep our extra configs and scripts in git too,
<karlp>
so instead of copying an SDK, yu just clone the repo and build like normal
<karlp>
yes, this is nominally slower for the first time, but it's also "normal" as far as how to use it goes.
<rsalvaterra>
And I get 268 Mb/s with WireGuard. Not great, not terrible.
<stintel>
haha, I used that to evaluate a candidate :D
<rsalvaterra>
Yeah, this was a bit of a Gaston Lagaffe moment for me. :P
<rsalvaterra>
Now, where to document this? The wiki is a possibility, but I feel it's a bit more user-oriented… and this would be a developer warning.
<stintel>
iirc there have been heated discussions about this before, because users really wanted this and we said no
<stintel>
maybe we should create a wiki page dedicated to the subject of optimizations, why we don't micro-optimize for each CPU arch, etc
<stintel>
and next time someone wants to go there, we link them to that page, where we clearly state that if we don't get benchmark results with at least 2 digits percentage improvement, we'll simply ignore the subject
<rsalvaterra>
tmn505: The takeout is that NEON on the Cortex-A9 is terrible. :/
<stintel>
that being said, I do think we should offer a way to make it easy for the user to build with his own marc/mcpu flags, which should reflect in the directory name in {build,staging}_dir
Tapper has quit [Ping timeout: 480 seconds]
<stintel>
because I've done this once via CONFIG_TARGET_OPTIMIZATION or CONFIG_EXTRA_OPTIMIZATION, and then if you have two different devices you build for (like intel and amd), shit seriously hits the fan
<tmn505>
rsalvaterra: yep, and even if the benchmarks are shown some people will call the target crippled
<rsalvaterra>
tmn505: I was one of them. It was hard to believe the implementation is really *that* bad.
<zarzarzar>
karlp: it's a good option to just build OpenWrt once from scratch on each developer PC but I want also to save all SDKs for each our software release and use these SDKs in the future in case someone would rebuild some part of software for any old release. I'm from Yocto/Buildroot world and here it is very popular practice to archive all images and SDK :)
<karlp>
yeah, I' mbuilding the sdk and image builder and archiving them too, but tagging the git repos and using versions in the feed configurations means you end up being equally able to rebuild things reliably later,
<karlp>
sorry I don't have better answers on how to just use the sdk/image buidler as they are.
<tmn505>
rsalvaterra: the good is that now, we have core member that has seen things, so no more advocating for a split, unless some other reasons.
<rsalvaterra>
tmn505: Oh, I've seen things, indeed. :)
<stintel>
heh, was checking https://git.openwrt.org/301301 since we're on the subject of benchmarking, can't get anywhere near those speeds atm
<stintel>
sqm disabled, iperf3 test < 70Mbps, hitting 25% sirq (so filling one core on the apu2)
<stintel>
same test over the m300 gets ~250Mbps
<stintel>
I should keep an eye on ebay too :P
<stintel>
moar M300 kthxbai!
<rsalvaterra>
WTF, the APU is a tragedy…! o_O
<stintel>
maybe some recent regression, dunno
<rsalvaterra>
stintel: Wait, is that just routing? I thought you were talking about WireGuard, but then I remembered you don't use it.
pmelange has quit [Read error: Connection reset by peer]
<zarzarzar>
karlp: It should work like that in theory, but I don't think that we would be able to reproduce the same SDK after 5 years of release. I can try to build, for example, 15.05.1, but in my opinon it'll fail even though all package versions are fixed.
<zarzarzar>
karlp: but thank you for your answers!
<karlp>
hrm, IME, someone's old sdk tarball is even less likely to be useable :)
<rsalvaterra>
stintel: That's even worse, the CPU supports AES-NI!
<karlp>
the sdk _shoujld_ be useful for things, I've just not used it enough to giveyou more concrete answers sorry
<stintel>
rsalvaterra: it does, as proven by that commit message
pmelange1 has left #openwrt-devel [#openwrt-devel]
<stintel>
ok it seems the APU2 now manages about 100Mbps, with iperf3 running on the apu2 instead of host behind it. with iperf3 on the M300 it's again ~250Mbps
<rmilecki>
hauke: stintel: mrkiko: I compiled kernel 5.10 for bcm47xx using Buildroot and it boots fine
<rmilecki>
then I copied kernel config from OpenWrt to Buildroot - it resulted in kernel *not* booting anymore
<rmilecki>
so that is clearly related to the kernel config
<rmilecki>
I found Buildroot kernel diff that makes the difference: CONFIG_BLK_DEV_INITRD - see https://pastebin.com/UN3Hp6L9
<rmilecki>
now, the problem: disabling CONFIG_BLK_DEV_INITRD in OpenWrt doesn't make kernel boot
<rmilecki>
so there are two options:
<rmilecki>
1. it's about kernel size
<rmilecki>
2. it's about CONFIG_BLK_DEV_INITRD and another config too
rua has quit [Ping timeout: 480 seconds]
<stintel>
rmilecki: good find
minimal has joined #openwrt-devel
<hauke>
rsalvaterra: could you please send a mail with your results regarding NEON to the mailing list, to document your results somewhere
<hauke>
rsalvaterra: this is still an intresting result
<hauke>
rmilecki: interesting, if you haven't fixed it at the weekend I will also have a look
<rsalvaterra>
hauke: My testing was conclusive, albeit a bit rushed, yesterday. I want to get more definitive numbers today. For example, giving openssl speed 5 seconds, like I did, is a bit too low, some tests were extended because of it. I'll retest with 10 seconds.
<hauke>
rsalvaterra: ok
<hauke>
if this discussion comes up again in 2 years it would be nice to have the findings documented somewhere
<rsalvaterra>
And I was only able to set up the WireGuard tunnel this morning. :)
<karlp>
jow: there's no replacement for the old file/directory cbi validators is there?
<rmilecki>
hauke: stintel: mrkiko: I took OpenWrt's kernel 5.10 config again (without CONFIG_BLK_DEV_INITRD but still broken)
<rmilecki>
I put it in my Buildroot setup and confirmed it doesn't work
<rmilecki>
I dropped some symbols - it didn't help
<rmilecki>
I dropped two more: CONFIG_INET and CONFIG_NETFILTER - kernels *boots* now
<rmilecki>
these symbols can't affect kernel's booting
<rmilecki>
so i think it's kernel size related after all
<stintel>
bummer
<karlp>
jow: also, there doesn't seem to be a way to use the datatype validators by hand? I've got a field that has a host:port, and I used to be able to call datatypes:host(parts[0]) and datatypes:port(parts[1]) on the split string, but I don't seem to be able to access that after 'require validation' ?
<karlp>
I can acess validation.parseIPV4 and things, but those aren't quite the same.
<rmilecki>
Starting program at 0x80001000
<rmilecki>
[ 0.000000] Linux version 5.10.72 (rmilecki@localhost.localdomain) (mipsel-openwrt-linux-musl-gcc (OpenWrt GCC 11.2.0 r17774-43c64ffa74) 11.2.0, GNU ld (GNU Binutils) 2.37) #0 Wed Oct 20 09:57:09 2021
Tusker has quit [Quit: Time wasted on IRC: 8 hours 23 minutes 31 seconds]
<karlp>
hrm, I've got a package named mosquitto-next, in another feed, that I sometimes use for testing newer versions of mosquitto. It has a PROVIDES:= mosquitto, and the core mosquitto package in packages feed is also called mosquitto-ssl or mosquitto-nossl, and PROVIDES:= mosquitto too.
<karlp>
so far so good,
<karlp>
but if the mosquitto-next package is _installed_ from the feed, but not enabled.
<karlp>
it still tries to build it anyway.
<karlp>
I get a line that look suspicious in the build log: make[2]: Circular package/feeds/owrt_pub_feeds/mosquitto-next/compile <- package/feeds/packages/mosquitto/compile dependency dropped.
<karlp>
but I can't figure out where that comes from.
<karlp>
suspciously, mosquitto-next is neither =y or "is unset" in the .config?
<karlp>
I normally fix this by just ./scripts/feeds uninstall mosquitto-next, but there must be something else wrong?
<karlp>
I've even marked it as broken, and if I enable broken packages in advanced, I do get a "# CONFIG_PACKAGE_mosquitto-next is not set" but it still builds
mirko has quit [Remote host closed the connection]
<karlp>
jow: hrm, not sure what's going on with "long" validation though I get the field text going red/black based on fs.stat() calls,but the tooltip is busted? https://paste.jvnv.net/view/LoHNR
Andi_ has quit [Read error: Connection reset by peer]
Andi_ has joined #openwrt-devel
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
guidosarducci_ has joined #openwrt-devel
guidosarducci has quit [Ping timeout: 480 seconds]
guidosarducci_ is now known as guidosarducci
Tapper has quit [Ping timeout: 480 seconds]
Tapper has joined #openwrt-devel
<hauke>
rmilecki: nice
<hauke>
rmilecki: how big is the uncompressed kernel image?
<hauke>
I think the loader overwrite itself while uncompressing the kernel
<hauke>
rmilecki: when it starts it copies the loader code to BZ_TEXT_START
<hauke>
and at the end jumps into this code to do the decompression
<PaulFertser>
hauke: have you figured out the e8450 problem you had?
guidosarducci has quit [Quit: ZNC 1.7.5+deb4 - https://znc.in]
<hauke>
PaulFertser: not yet
guidosarducci has joined #openwrt-devel
<hauke>
do you have some more information about the calibration?
<PaulFertser>
hauke: the factory flashes calibration data without ECC and old driver ignored ECC errors while the new doesn't and returns read errors.
<hauke>
I will find the code and add some prints into it
<PaulFertser>
hauke: so the solution is to reflash the calibration data (with either driver)
<PaulFertser>
hauke: it's a well known issue discussed on the installer ticket and the forum or something like that.
<hauke>
ok thanks
<PaulFertser>
hauke: you can just try reading the calibration data from userspace with new driver (cat from /dev/mtd<something) and you'll see the i/o errors.
<PaulFertser>
kmod-mtd-rw can be used to allow flashing
<hauke>
PaulFertser: I do not get any IO errors when reading the mtds
<PaulFertser>
hauke: hm, that might be a different issue then
<hauke>
rmilecki: the loader is copied 6287360 bytes on top of the beginning of the image
<hauke>
rmilecki: the kernel 5.4 is probably smaller than that value
<mrkiko>
hauke: yes, it's required to to re-run the linksys e8450 installer
<mrkiko>
hauke: stintel: rmilecki: I'll try to test bcm47xx with 5.10 kernel and let you know
<rmilecki>
mrkiko: i found cause + workaround / fix, did you see?
victhor_ is now known as victhor
<mrkiko>
rmilecki: oh, I understood the problem was lzma-loader that couldn't handle 5.10 kernel, but I miss the rest of the picture. The problem was the loader reloacting in the stack?
<rmilecki>
mrkiko:the problem are offsets lzma-loader uses that result in overwriting in memory
<mangix>
rmilecki: interesting commit changing to B53 DSA. You think it's feasible for mpc85xx?
dedeckeh has quit [Remote host closed the connection]
<rmilecki>
mangix: no idea
Strykar has quit [Remote host closed the connection]
pmelange has joined #openwrt-devel
<aparcar[m]>
philipp64: ping
<aparcar[m]>
anyone thoughts on the wolfssl 3.8 upgrade for 21.02.1? Anyone using OCSP?
Tapper has quit [Ping timeout: 480 seconds]
Andi_ has quit [Remote host closed the connection]
Andi_ has joined #openwrt-devel
Tusker has joined #openwrt-devel
pmelange has left #openwrt-devel [#openwrt-devel]
rmilecki has quit [Ping timeout: 480 seconds]
Tapper has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
SamantazFox has joined #openwrt-devel
gladiac is now known as Guest3722
gladiac has joined #openwrt-devel
Guest3722 has quit [Ping timeout: 480 seconds]
<Grommish_>
aparcar[m]: Rust is fine except for the cluster that is arm and how it reports in the build system :D I'm still trying to wade thru the best way to split armv7 out from the rest of them because it matters to the toolchain
Grommish_ is now known as Grommish
<Grommish>
aparcar[m]: it's all divied out by the FEATURES rather than by ARCH