<Ansuel>
but i assume also bsd-compat-headers if we are in macos?
<Mangix>
don't remember
<Mangix>
should try without
<Mangix>
bsd-compat-headers are specific to musl
<Mangix>
note that OpenWrt's toolchain/musl includes them
<Ansuel>
so we may require them ?
<Ansuel>
and yep elfutils broken... god damn
<Mangix>
well, for base OpenWrt they might be optional. But for certain host packages like libtirpc, they are needed
<Mangix>
so, probably need a check in prereq-build.mk for them as well.
<Ansuel>
any idea how to check if they are installed?
<Mangix>
yeah
<Mangix>
gcc -include sys/queue.h -x -c
<Mangix>
that's one of them
<Mangix>
the most important one actually
<Mangix>
oh it's the only one toolchain/musl includes
<Ansuel>
even better
<Ansuel>
also lets add some comments just to give some context about it
<Mangix>
this docker thing is quite convenient
<Mangix>
better than my nspawn containers
<Ansuel>
now i'm really curious if there is a way to fix elfutils...
<Mangix>
Ansuel: you're in for some pain unfortunately
<Ansuel>
oh no...
<Mangix>
the first obstack error is easy to fix. The second libintl.h error is not
<Ansuel>
btw wth we install all the manual for libressl...
<Mangix>
?
<Ansuel>
just junk files in the host tool staging dir
<Mangix>
oh
<Mangix>
also as far as gettext is concerned, the selinux crap is also affected
goliath has quit [Quit: SIGSEGV]
<Mangix>
adding musl-libintl to apk add is not enough to fix. they use custom makefiles with no proper checks for libc gettext or external
<Mangix>
elfutils uses garbage automake stuff that can't deal with it either.
<dangole>
anyone knows how to find the cause of cpu freeze? i'm trying to port ethernet driver for mt7981 soc and one of the two CPU cores just dies when eth0 is being brought up (eth1 works fine).
<Ansuel>
sounds like a dead lock ?
<Ansuel>
does it print cpu stall after a while?
<Ansuel>
if it's a lock there are some debug config to bisect locking problem AFAIK
<Ansuel>
configure: error: failed to find argp_parse LOVE IT
<Ansuel>
this should be the easy problem to fix right?
<hauke>
Ansuel: argp_parse is not supported by musl
<hauke>
use argp-standalone
<hauke>
dangole: activating all the lock debugging from the kernel is a good idea
<dangole>
Ansuel: i also suspected locking first, and spend days verifying locking, using lock proving debug options, ...
<Mangix>
oh yeah there's that too
<hauke>
dangole: it could be that the system busg hangs
<hauke>
*bus
<Ansuel>
hauke if that's the case it's a PITA to debug
<Mangix>
I blame stintel for these issues :)
<hauke>
dangole: do you have jtag?
<dangole>
hauke: no, the board may have jtag on test points, but i didn't wire it up yet
<dangole>
hauke: but kgdb/kdb works fine over serial
<hauke>
dangole: could you compare the clock and reset settings with a working driver
<hauke>
with a working system
<dangole>
hauke: thing is just that it won't help because when entering says "KGDB: Timed out waiting for secondary CPUs." and then what ever is happening on that CPU is invisible
<hauke>
maybe you forgot to activate some clock and then something acceses this IP core and the system hangs
<dangole>
hauke: yes, i suspect something like that
<Ansuel>
it's probably that or the opposite
<Ansuel>
aka some clock are disabled and the system goes crazy
<dangole>
hauke: strange enough is that eth1 works fine, only eth0 has this problem
<dangole>
hauke, Ansuel: ie. if i want to boot the system "normally" without any hangs i just deliberately break phylink in DTS for eth0 so it won't come up...
<Ansuel>
eth1 is secondary and eth0 share some clock with the core or the entire system?
<Ansuel>
just putting some idea on the table
<Ansuel>
or a reset is doing something fancy?
<Ansuel>
also worth to mention the problem may be in a clock driver and probing the eth driver just triggers it by enabling the clock?
<Ansuel>
configure: error: failed to find fts_close OHHH FFS -.-
<Mangix>
Ansuel: LOL. alpine has a musl-fts package
<hauke>
dangole: If you have the vendor FW running too, please do a rgister dump of the clock and reset controller and compare it to your system
<dangole>
hauke: i got working stock firmware, to have /dev/mem i will have to build mtk sdk from source, but it's doable.... was hoping to get around that...
<Ansuel>
i'm compiling elfutils directly in docker build... extra lazy....
<Ansuel>
musl-fts didn't fix the fts_close error
<Mangix>
yes, because you need to add -lfts :P
<Ansuel>
checking for library containing argp_parse... -largp
<Ansuel>
checking for library containing fts_close... no
<Ansuel>
FUN
<Mangix>
oh that's surprising
<hauke>
dangole: do you have the Gl int devices?
<Ansuel>
Mangix it's not detected I guess
<Mangix>
Ansuel: I think you should give up on Alpine honestly
<dangole>
hauke: yes, it's mt3000 board, gl-inet provided a free sample some month ago, just didn't have much time to play with it earlier...
<hauke>
nice, I just read about it
<hauke>
does it really need the fan?
<dangole>
hauke: i only got the bare board, also looks like an early pre-production version, has v0.1 printed on it...
<Mangix>
Ansuel: wonder how easy it is to set up nix
<dangole>
hauke: none of the ICs get hot at all, all below 40degC at ~ 19degC room temperature
<Ansuel>
do you think we would have less problem with nix? ahahah
<rmilecki>
Matrix: Check Kernel patches jobs failed with:
<rmilecki>
Error response from daemon: manifest unknown
<rmilecki>
Error: Docker pull failed with exit code 1
<rmilecki>
anyone with idea why?
<jayk>
ruh roh
goliath has joined #openwrt-devel
Tapper has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
cbeznea has joined #openwrt-devel
goliath has joined #openwrt-devel
<Znevna>
is there a script that cleans just old stuff from the build_dir ?
<oliv3r[m]>
rm -rf :D
<Znevna>
:P
<Znevna>
obviously
gch981214 has joined #openwrt-devel
gch981213 has quit [Ping timeout: 480 seconds]
hexagonwin has quit [Quit: [ Quitting client ]]
gch981214 has quit [Ping timeout: 480 seconds]
cbeznea has quit [Quit: Leaving.]
robimarko has joined #openwrt-devel
Ryncewynd has joined #openwrt-devel
bluew has quit [Ping timeout: 480 seconds]
cbeznea has joined #openwrt-devel
<f00b4r0>
ynezz: care to review my reply to Brian? I think you opened a can of worms here ;)
<robimarko>
Like you pointed out, individually changing busybox options wont work
bbezak4 has quit []
bbezak has joined #openwrt-devel
<f00b4r0>
robimarko: that's my understanding but the fact that ynezz (who knows a thing or two about our build infra) suggested differently made me doubt myself, tbh
<ynezz>
you're correct f00b4r0, I was wrong, I'll reply to that mail later, thanks for catching this
<f00b4r0>
ynezz: np, thanks for confirming. I think the AWK solution is the simplest. This doesn't even need to be packaged, it can be dropped in the subtarget files.
<ynezz>
if its reliable, then yes
<ynezz>
other option might be ubox/base64decode which would use bas64_decode from libubox/base64.c
<f00b4r0>
awk is certainly reliable, and base64 is nothing complicated: if Brian can confirms that it works for him I think we should be golden :)
<ynezz>
perhaps ucode could work as well
borek has joined #openwrt-devel
<f00b4r0>
ynezz: btw since you're here, I'm still hoping that you can test buildbot monomaster ;)
* f00b4r0
runs
<ynezz>
there is a progress, I've the ansible part prepared, need to deploy it and run test it
<f00b4r0>
ah ha! excellent ;)
<f00b4r0>
ynezz: fwiw I should be able to bring my machines back online no latter than Jan 22. At which point I should also be able to setup more machines.
goliath has quit [Quit: SIGSEGV]
goliath has joined #openwrt-devel
borek has quit [Quit: borek]
<hauke>
rmilecki: for my gcc update I run tests on all targets also with testing kernel and saw these problems
<robimarko>
f00b4r0: Have you used the check for initramfs in syuspgrade recently?
<f00b4r0>
robimarko: nope. Is it broken again? ;P
<robimarko>
Looks like it
<f00b4r0>
*sigh*
<Znevna>
x.x
<robimarko>
I was adding ubiformat for Xiaomi devices on ipq807x to make sure its clean
<robimarko>
And its happily running even when not initramfs
<robimarko>
But the thing is that by the time platform_do_upgrade is invoked
<robimarko>
We are already running from tmpfs
vicencb has left #openwrt-devel [#openwrt-devel]
<f00b4r0>
neat
danitool has joined #openwrt-devel
<robimarko>
No idea how are MTik devices working with a similar check
<f00b4r0>
robimarko: technically it's not causing any particular harm tho? Only slowing down the process
<robimarko>
f00b4r0: Actually its breaking sysupgrade
<f00b4r0>
they're probably getting fully erased at every sysupgrade and we're none the wiser
<f00b4r0>
is it?
<f00b4r0>
how so
<robimarko>
We are merging the rootfs on Xiaomi devices
<robimarko>
As otherwise rootfs is crazy small on a 256 NAND
<robimarko>
And their dual FW relies on the kernel itself to switch the rootfs thats used
<robimarko>
So, currently we are relying on UBI attach failing on the new rootfs partition
<robimarko>
That will trigger a ubiformat on it before anything else
<robimarko>
However, I got pointed out that is a bit flimsy, so I wanted to run ubiformat on the kernel and rootfs
<robimarko>
Whenever we are running from initramfs to make sure they are clean
<f00b4r0>
ha, you were a bit greedy ;)
<robimarko>
I mean, the fact that ubiformat on kernel fails doesnt make sysupgrade fail
<f00b4r0>
if sysupgrade switches to tmpfs before do_upgrade runs, I'm not sure how we're supposed to distinguish initramfs from regular sysupgrade :(
<robimarko>
But its damn wastefull to ubiformat 90% of the NAND every sysupgrade
<f00b4r0>
yeah
<robimarko>
I have no idea as well, cause it clearly switches to ramdisk first and only then platform_do_upgrade runs
<f00b4r0>
although unless I'm mistaken, for areas that weren't written to, it's a NOOP
<robimarko>
Actually no
<robimarko>
ubiformat should wipe it clean
<f00b4r0>
i don't know how ubifs works tbh. On SPI NOR it doesn't hurt since once the bits are set, they're set until written to. So there's no "wear", only wasted time.
<robimarko>
Can we do something like add a /etc/image-type
<robimarko>
And just store regular or sysupgrade
<robimarko>
And then that can be copied to ramfs before sysupgrade
rua has quit [Remote host closed the connection]
rua has joined #openwrt-devel
dangole has joined #openwrt-devel
Ansuel has joined #openwrt-devel
<Znevna>
<dangole> Znevna: it's the other way around: all devices with switch ICs (or SoC-integrated switches like MT7621) are capable of bridge offloading. [...]
<Znevna>
no, I was talking about the two exceptions from that commit
<Znevna>
[ 0.420004] OF: /ethernet@1e100000/mac@0: could not get #nvmem-cell-cells for /nand@1e003000/partitions/partition@1e0000/macaddr@4
<Znevna>
ok, this is new
<Znevna>
x.x
<Ansuel>
Mangix ping?
romany00 has joined #openwrt-devel
romany0 has quit [Remote host closed the connection]
romany00 is now known as romany0
<dangole>
Znevna: the two exceptions are for devices which do not have ANY software-controlled LEDs other than the switch-port ones. in this case it is more important to have any indication (ie. blink at boot, fast blink at failsafe, sysupgrade, ...)
<\x>
shouldve done this with those ASUS spider routers where it crawls under your bed, yeah man, router moves closer to the client bruh
<\x>
none of that roomba shit, spider router is what the future will be
<robimarko>
Pretty much everything BE should be IPQ957x for now
<robimarko>
But yeah, the design as ugly AF
<\x>
robotic wifi bro
<damex>
mrnuke: i see that you did openwrt flashing on your switch. your bootloader version seem to be different from mine. i have had them on 2022 bootloader timestamp. maybe something did change? i am not sure that it is good idea to try updating on my last 3.20 switch without being able to revert back
<damex>
i tested on previous switch and it didn't came back up with logs posted on openwrt forums.
<Ansuel>
tested with the docker build file and works correctly with detecting missing header
<[Pokey]>
I know this is a little bit generic and not too specific to OpenWRT right now, but when adding an SDHCI section to a device tree, how do you generally work out all of the options like reg and interrupts? I'm looking at datasheets and just... not having a good time, plus I'm getting sdhci@20060000:reg: property has invalid length (8 bytes) (#address-cells == 2, #size-cells == 2) warnings and generally not getting far with my basicaly
<[Pokey]>
nonexistent experience
gch981213 has joined #openwrt-devel
gch981213 has quit []
gch981213 has joined #openwrt-devel
gch981213 has quit []
minimal has joined #openwrt-devel
gch981213 has joined #openwrt-devel
<gch981213>
[Pokey]: According to that message you need to put 4 numbers in the reg property: 2 for address and 2 for size.
<robimarko>
[Pokey]: Whats the platform?=
<[Pokey]>
gch981213: I see
<[Pokey]>
robimarko: A new one, BL808 from Bouffalo, RISC-V
<[Pokey]>
This thing has very minimal linux support, it is brand new and the upstream stuff hasn't even been accepted into kernel yet
<[Pokey]>
Currently using a patched kernel
<[Pokey]>
the hope is we can get basic peripherals working, and then get a buildroot working and then I hope OpenWRT can start working after a few more peripherals are working
<[Pokey]>
Theres really not many people working on this as far as I'm aware. The manufacturer is focusing on their baremetal SDK
<gch981213>
[Pokey]: It doesn't say where the SDHC is mapped to in the memory map section...
<[Pokey]>
gch981213: Indeed. We're guessing, based on their SDK, 20060000
<gch981213>
For 64 bit systems the memory address and size needs to be 64-bit while a number in the reg property is 32-bit, so it needs two numbers: <addr_high addr_low size_high size_low>
<[Pokey]>
ahh
<gch981213>
[Pokey]: e.g. A 0x1000 area starting from 0x11230000 is described as: reg = <0 0x11230000 0 0x1000>;
<[Pokey]>
Right!
<jow>
Ansuel: did you have a test to test the proposed iwinfo fdt compatible change?
<[Pokey]>
Me and the others have something to try now, I'll report back, thanks
<Ansuel>
actually now that i think about it I can totally test it on a ipq8074 board
<aiyion>
dangole showed me a development branch for the linux kernel yesterday, I read through the most recent commits, but am unsure how one does build some sort of bleeding edge OpenWrt. Is there a better way, than backporting all relevant commits to 5.15 and apply them as patches?
<Ansuel>
well using an external kernel tree is a way
<Ansuel>
but you will have to manually patch it
<dangole>
aiyion: use CONFIG_EXTERNAL_KERNEL_TREE and all you need is usually just very few openwrt-specific things on top of linux-next
<aiyion>
Thank you both, I'll give it a shot when I'm back.
<dangole>
Ansuel, aiyion, hauke: traced the hang down to first regmap access on the SGMII unit. now comparing clk registers to figure out why sgmii mmio range is unavailable...
<dangole>
(eth1 works because is doesn't use SGMII but rather GMII to connect built-in GE phy)
Tapper has quit [Quit: Tapper]
Tapper has joined #openwrt-devel
<mrkiko>
dangole: on what hw are you testing? brume2 like aiyion ?
<mrkiko>
or is it a different hang / problem?
* aiyion
is afk for a moment
<dangole>
mrkiko: i'm trying to port mt7981 to mainline linux, using gl-inet mt3000 hardware for testing
<jow>
Ansuel: seems to do what it is supposed to do, then
<Ansuel>
wonder if it was 0000 also before the patch
<jow>
no, before the patch it was initialized with fake IDs
<jow>
the hardcoded switch/case created fake IDs, and those were looked up in the database as pci device then
<Ansuel>
on luci it's always exposed with the name right?
<Ansuel>
from ubus ubus call iwinfo info '{"device":"wlan1"}'
<Ansuel>
"hardware": {
<Ansuel>
"id": [
<Ansuel>
0,
<Ansuel>
0,
<Ansuel>
0,
<Ansuel>
0
<Ansuel>
],
<Ansuel>
"name": "Qualcomm Atheros IPQ8074"
<Ansuel>
}
<jow>
yeah, LuCI just dispalys the name
<Ansuel>
if we really want we can save the vendor and subsystem vedor is it would be the only real value... but subsystem_device_id and device_id is all fake
<Ansuel>
for me the suggested patch is good as is
<Ansuel>
(just needs to add the missing entry for ipq8074)
<jow>
could you take care of it? Feel free to push it either with my Suggested-by and your S-o-b or my S-o-b and your Test-by or something
<jow>
+ the missing entry
rua has quit [Ping timeout: 480 seconds]
<Ansuel>
sure will send on the mailing list so you can check if the added tag are ok
goliath has quit [Quit: SIGSEGV]
rua has joined #openwrt-devel
<stintel>
aiyion: karlp: did you try 5.15 on sunxi ?
<karlp>
yeah, I've got 5.15 in my own tree.
<karlp>
anything in particular you were looking for?
<stintel>
karlp: nope, just considering switching sunxi to 5.15 by default
<karlp>
I want even newer, for something, that I can't remmeber right now, but will come back to me...
<stintel>
karlp: there is no newer than 5.15 in OpenWrt ;)
<stintel>
karlp: so I assume 5.15 ran fine for you?
<stintel>
if I can add a tested-by or 2 to the commit I'd just do it today :)
<karlp>
you can have mine :)
<stintel>
tha
<karlp>
Karl Palsson <karlp@etactica.com>
<stintel>
etactica ?
<stintel>
k ;)
<karlp>
was just double checking I did have 5.15 in my local tree :)
<stintel>
cheers
<karlp>
where's this commit?
<stintel>
ah not pushed yet
<karlp>
right, just saw it :)
<karlp>
if you're removing 5.10, shouldn't you be removing the files and stuff too?
<stintel>
next I'll have a look at ramips to see what's wrong there still with 5.15
<stintel>
good point
<karlp>
it might be worth pointing out that I'm testing 5.15 with a board that's not upstreamed
<karlp>
so some of those board support aptches that may or may not have been upstreamed, I'v
<karlp>
e not tested.
<karlp>
but sunxi is pretty close to upstream in general, so looks like it should be fine... :)
<stintel>
should be fine, it's still master
<stintel>
but people using snapshot images can't use testing kernel, so ideally we get everything switched to 5.15 by default asap to expose it to more testing
<karlp>
:+1:
<stintel>
I'm also testing ramips with 5.15, seems there is some kernel panic that needs fixing before we can switch
<robimarko>
Ansuel: nice to see the fake PCI id gone
<aiyion>
stintel: My commits were based on 5.15 I think, yes. But My concern was more of the device booting reiably and having a stable mac.
<stintel>
aiyion:
<stintel>
oops
<stintel>
aiyion: but that means you've also successfully booted and run 5.15 on sunxi - can I add your tested-by also ?
<aiyion>
But let me fire up the device for an hour and shove some trafficd, than I'll have it tested as well.
<stintel>
alright :)
<stintel>
thanks
<aiyion>
I'll get right to it, but building always takes a moment.
<Ansuel>
robimarko almost there tho... trying to understand why luci-rpc die after ubus call luci-rpc getWirelessDevices
<jow>
ukleinek: right, so my idea was to fix it in a generic manner by making the calling code ignore returned graph definitions that refer to types not present in the rrd being rendered
<jow>
Ansuel: abi breakage between rpcd iwinfo.so and libiwinfo.so ?
<Ansuel>
in theory i should have updated all the libs
<Ansuel>
that should be libiwinfo rpcd and rpcd-mod-luci
<jow>
ukleinek: can you pastebin me the output of `find /tmp/rrd -name '*.rrd'` ?
<Ansuel>
jow the strange thing is that the command correctly finish the first time and then luci-rpc die
<Slimey>
speaking of testing.
<f00b4r0>
stintel: i have a bunch of nanopis lying around, I could give it a shot later but right now my build horse is unavailable
<jow>
ukleinek: *facepalm* ... it's been too long that I worked with the code, solution seems rather simple actually
<jow>
ukleinek: the `graph` variable received as first arg by the `rrdargs()` function is a class instance providing a whole bunch of introspection methods
<Ansuel>
compiling a full image.... no point in wasting time with searching what lib is broken....
<jow>
ukleinek: among them, a `graph.dataTypes(host, plugin, plugin_instance)` which will return an array of `types` belonging to the given plugin instance
<jow>
ukleinek: in your sensors case this should be either `[ "temperature" ]` or `[ "temperature", "humidity" ]`, depending on which sensor instance the rrdargs function is invoked for
goliath has joined #openwrt-devel
<ukleinek>
jow: that "rather simple" part is what I expected. Not being fluent in js however ....
<ukleinek>
jow: so the idea is to only return the configurations for the types returned by graph.dataTypes, right?
<ukleinek>
jow: does it do the right thing then if my sensor yields (say) 2 temperatures and humidity?
<ukleinek>
jow: or is the filtering better be done by the code calling rrdargs()?
<jow>
yeah, the calling code could probably be smarter and check the .types array of the returned graph descriptions for intersections with the known datatypes of the plugin being rendered, but well
<jow>
need to run. if the pasted version works for you, could you amend the PR? I'll merge it later then
<ukleinek>
jow: Assume I test and massage that code, should I just update the PR with "Co-Authored-by:" or something similar?
* ukleinek
lets jow run
<ukleinek>
... and schedules testing later today
Ansuel has quit [Read error: Connection reset by peer]
<jow>
ukleinek: suggested-by is fine
Ansuel has joined #openwrt-devel
gch981213 has quit [Ping timeout: 480 seconds]
<Znevna>
can't figure out which commit introduced those errors x.x
gch981213 has joined #openwrt-devel
<Ansuel>
jow was thinking since we are adding compatible to the iwinfo struct
<Ansuel>
is it necessary to bump ABI?
<Ansuel>
ok tested on a full image an all works correctly
<aiyion>
stintel: Here's the screenlog of the sysupgrade from 5.10, boot of 5.15, and basic checking of networking. Maybe you spot something I didn't, but so far it looks good.
<Ansuel>
that in theory should handle the false-positive
<hauke>
I tried it yetserday and build x86 with glibc and musl with gcc 12 and gcc11
<hauke>
and elfutils build for me
<robimarko>
On ipq807x everything builds fine with GCC12 localy
<Ansuel>
then it's 100% my dirty buildbot
<mrnuke>
damex: have you checked that your serail cable/adapter is working with 3.3V? You can short TX and RX on the cable and see it it echoes things back. I fried several USB adapters bu connecting them to the TP-Link. Reason: the GND can be at 50V potential from earth due to the way the PoW works. Last night when I was testing, I fried another USB-serial adapter :p
<Ansuel>
hauke if that patch works should we care to have that instead of disabling the warning?
<hauke>
I think we should retry tomorrow when the x86/64 and malta/be builds are done
<Ansuel>
sure but it will totally work... just toolchain needs to be refreshed.
<dhewg>
those two targets fail with the same errors on PRs I pushed to today
<damex>
mrnuke: yeah, it works fine. i have many different usb ttl adapters and i confirmed that they work fine. one of them is ch343p (usb-c, designed/made by weact studio and schematics somehwere on github), some generic ch341a and some other stuff like pl2303 or something that i no longer use but they still work. i constantly debug esp32 chips using them through and i can definitely confirm that they work fine.
<hauke>
dangole: the gl-mt3000 is for sale for 69$, does it make sense to buy it?
<damex>
i have some other ttl adapters if that does matter and they still should work or i can repurpose one of the development boards to become a serial adapter :)
<robimarko>
hauke: I really hoped for dual core A53 to die finally
<Ansuel>
robimarko in theory your ipq807x pr should complete fine since every toolchain is locally built
<robimarko>
Ansuel: Yes, it compiles fine as there is no prebuilt toolchain so its build in the workflow itself
<damex>
mrnuke: maybe it would matter - 3.20.4 stock was unstable and constantly froze with stp on and under other circumstances. upgrading to 3.20.7 solved almost all concurrent problems. all switches boot with LEDS OFF when i plug 10gtek sfp->rj45 copper module on 9th port. works fine if i keep it plugged in to the 10th port.
<damex>
i tried downgrading past that and it refused to accept it from gui or tftp+cli.
<Ansuel>
any idea how to refresh gcc patches? totally forgot
<damex>
hauke: i have been deciding on new device with filogic and did pick banana pi r3 instead of mt3000 for what it offers. quad core, 4 times more ram, more ports, more wireless channels, m2 nvme and etc :) mt3000 is not supported yet though while banana thingy got official support
<damex>
but banana board does cost more :)
<stintel>
aiyion: thanks!
<dangole>
hauke: US$69 for a device with 2.5G Ethernet is quite nice, and my feeling is that MT7981 will be the new IPQ4019 in terms of popularity.
AtomiclyCursed has quit [Quit: ZNC 1.8.2 - https://znc.in]
<dangole>
SwedeMike: MT7531 is connected to MT7986 with 2.5GBit/s
<dangole>
SwedeMike: looks a bit like this fact was deliberately omitted in the image...
<SwedeMike>
looks promising!
bluew has joined #openwrt-devel
<dangole>
hauke: btw: I managed that eth0 on MT7981 no longer hangs on link-up, I figured the bus hang was due to a necessary clock ('sgmii_reg') not being enabled. now DMA still hangs for eth0, probably data path is not setup correctly...
<damex>
https://forums.servethehome.com/index.php?threads/cheap-8-ports-sfp-low-noise.28243/post-265363 oh my, tplink removed serial port on v2 of that tl-st1008f. so i guess gotta pop them them out of soc :)
<damex>
ah no, it is other way around. pins are present on v2 o-O
<Slimey>
oh remind me i need to bring my multimeter home
<Slimey>
s
<Borromini>
dangole: are you talking about the 802.11ax TP-Link you are porting?
<hauke>
Borromini: Is the TP link MT7981 avalibale in the EU?
<Borromini>
hauke: i have no idea, sorry. It looks like everyone is ordering those XDR-6086 off AliExpress
<Borromini>
i joined mid-convo so I don't know if that's what dangole was talking about, hence my asking
<Ansuel>
well nice... gcc version selection is broken....
<dangole>
Borromini: no, i don't have that XDR608x hardware, was only hacking on it via remote access. the mt7981 is gl-inet mt3000
<mrnuke>
damex: The only other idea is to check the UART and clock likes with an oscilloscope or logic analyzer to see if the SoC is dead.
<robimarko>
hauke: Other than GL-Inet stuff, you are gonna need to get the Filogic stuff from china
<robimarko>
TP-Link has plenty of models, but its all CN only
<robimarko>
I am not getting what does he want to do with that
<Ansuel>
probably a device enforce a specific bootargs and he wants to find a way to use that?
<robimarko>
root=PARTUUID is nothing special
<robimarko>
A lot of devices use it
<Ansuel>
yep i remember that and we fix that with hardcoding the bootargs or appending to them if i'm not wrong
<robimarko>
Not really
<robimarko>
We activelly use that for mvebu and other targets that generate SD card/eMMC images
<robimarko>
My point is, what would be the side-effect for boards that rely on that being correct
<Ansuel>
guess i will ask more info about it
robimarko has quit [Quit: Leaving]
<jow>
Ansuel: patch looks legit
<Ansuel>
jow what about the ABI problem?
<jow>
Ansuel: it simply makes fstools ignore root=xxx parameters it can't handle
<jow>
the rootdevname() function the value gets passed to expects a block device path
<Ansuel>
(oh ok the fstool thing)
<jow>
and in case there's multiple root=, e.g. a root=UUID=foo prepended by the bootloader and another root=/dev/blah, the patch would make fstools skipe the former
<jow>
*skip
<jow>
or rather; the intent of the patch is to force looking up the requested partition name in *all* block devices in case the kernel cmdline root= does not refer to a /dev/ path
<jow>
if it does refer to a /dev/ path, only devices belonging to the same block device as the root= parameter are considered
<jow>
currently this logic does not account for root=UUID=...
<jow>
in this case, fstools tries to find stuff in /sys/class/block/UUID=.../*/uevent
<jow>
which is wrong
<Ansuel>
considering rootdevname expect a /dev/ path... what is the output in the case PARTUUID=<xxx> is passed?
dangole has quit [Remote host closed the connection]
<jow>
in case the uuid happens to end with decimal digits, they'll get stripped off
dangole has joined #openwrt-devel
<jow>
otherwise the input value is returned back verbatim
<jow>
e.g. 67a4b35c-02 => 67a4b35c-
<jow>
basename("67a4b35c-") => "67a4b35c-"
<jow>
or rather "PARTUUID=67a4b35c-02" => "67a4b35c-"
<jow>
rpcd-mod-iwinfo is passing an exactly sizeof(struct iwinfo_hardware_ids) sized buffer
<jow>
so obviously it'll fail without recompilation
<jow>
but given that dhewg has other abi breaking changes pending as well, let's just go ahead, slap dhewg's changes on top and eventually bump iwinfo in master with a ABI_VERSION change
<Ansuel>
i guess RIP cleanup
<Ansuel>
think I will merge the current patch in iwinfo and move on the rest of the pr with the ABI change
<Ansuel>
yep that was the idea... add everything in iwinfo but only bump when we are finished
<jow>
given that 22.03.3 is out now and we backported the most important fixes I'm fine with breaking the abi now
<Ansuel>
btw about the fstools patch.... i'm checking and we are full of target with something like: setenv bootargs "console=ttyS2,1500000 earlycon=uart8250,mmio32,0xff1a0000 root=PARTUUID=${uuid} rw rootwait"
<jow>
I can only say that the patch as such makes sense, but I do not know about the wider implications
<jow>
how fstools is used in this context, whether anything is actually broken or will start working after the proposed change
<Ansuel>
need to check it more since we have many target using PARTUUID... the patch makes sense... so everything is wroking by luck? it's strange
matoro has joined #openwrt-devel
dangole has quit [Remote host closed the connection]
<jow>
it will fix volume_find("rootfs") and volume_find("rootfs_data") in mount_root for example
dangole has joined #openwrt-devel
<jow>
the jffs2reset applet performs a volume_find("rootfs_data") as well
<jow>
as does fstools/snapshot (iirc nowhere used by default) and fstools/ubi
<jow>
nvm about fstools/ubi, it declares an entirely different volume_find() locally, so it seems it'll affect mount_root and jffs2reset
dangole has quit [Remote host closed the connection]
<jow>
likely neither works as intended if kernel is booted with root=PARTUUID=... or root=UUID=...
<Ansuel>
https://git.openwrt.org/?p=project/fstools.git;a=blob;f=libfstools/partname.c;h=f59c52eb8f3c6da0e8ee6c4080abd7cdac3db715;hb=HEAD#l98 the interesting thing is this
<Ansuel>
wonder if the strip part is doing some magic
<jow>
no, it is not
<jow>
it's simply nuking digit characters from the end of the string until the first non-digit character
<jow>
if the last character after that happens to be a "p", it is nuked too
<jow>
(some blockdevs use an foo0p1 notation)
dangole has joined #openwrt-devel
<Ansuel>
so the glob is /sys/class/block/PARTUUID=.../*/uevent
<jow>
yes
<Ansuel>
how the hell this thing is working
<jow>
it is not
<jow>
I suppose affected devices end up using alternative code paths
<Ansuel>
probably since by the looks of it the partname is never found