<nwf>
Hi channel; I have found that the TP-Link Archer C7 TFTP recovery path struggles with squashfs-factory.bin images that occupy more than half (or theresabouts) of the flash. It claims to write the whole thing, but the kernel then fails to boot with squashfs complaining "unable to read id index table", suggesting corruption.
<nwf>
However, the official OpenWRT images are small enough that everything goes fine, and sysupgrade is able to write things correctly.
<nwf>
I'd like for that caveat to end up in the wiki, but I don't have an account.
<Mangix>
nwf: so archer c7v1 factory?
<nwf>
This particular unit is a v2.
<nwf>
But yes, factory u-boot AFAIK.
<Mangix>
actually, I don't think v1 support was properly migrated from ar71xx to ath79
Tapper has quit [Ping timeout: 480 seconds]
f00b4r__ has joined #openwrt-devel
T-Bone has quit [Ping timeout: 480 seconds]
Borromini has joined #openwrt-devel
<nwf>
Ah, yes, in fact, reading the TFTP flash logs in more detail, the v2 flash is "flash size 16MB, sector count = 256" but the bootloader says "Erased 124 sectors". So only the first 8M are actually erased and ready to be updated by this route. sysupgrade knows better.
<nwf>
I don't think OpenWRT has support for building a newer U-Boot for this board?
<Znevna>
flashing an initial smaller image is such an issue?
<Znevna>
other devices are in the same boat soon anyway
<nwf>
It's not a huge problem, it's just A) annoying that it doesn't work when I custom build a larger squashfs and B) undocumented that it's a restriction.
<nwf>
I spent hours figuring this out; it would have been nice if the wiki had had a note. That's all.
borek has quit [Ping timeout: 480 seconds]
tmxpro has joined #openwrt-devel
<PaulFertser>
nwf: do you need a wiki account? I can create one for you right away, just need your desired wiki nick and e-mail.
<nwf>
Oh, that'd be grand. nick nwf, if that's alright; email via PM to follow. :)
<Borromini>
nwf: which device and which issue wer eyou bumping into?
soxrok2212 has quit [Read error: Connection reset by peer]
nixuser has quit [Remote host closed the connection]
nixuser has joined #openwrt-devel
Tapper has joined #openwrt-devel
Borromini has quit [Ping timeout: 480 seconds]
<tmxpro>
Hello I am trying to port to D-Link DAP-1522 B1 but I am doing something wrong with flash setup (VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6) in boot log. This is my first time porting so I am probably missing something simple. I am using OpenWRT 19.07.2
robimarko has joined #openwrt-devel
Tapper has quit [Quit: Tapper]
robimarko has quit [Quit: Leaving]
<hgl_>
when I add a pkg A to pkg B's Makefile's DEPENDS, building B also builds A. However, A is only a runtime dep. Is it possible to ask the build system to skip building runtime deps?
rua has quit [Remote host closed the connection]
rua has joined #openwrt-devel
<jow_>
hgl_: no. a potential workaround is using EXTRA_DEPENDS:=B to A's Makefile in order to specify "raw" opkg control file depends
<jow_>
this will only inject a dependency into the package metadata, the build system will be unaware of it
<hgl_>
jow_, cool, and opkg will still install A when B is installed? I wonder what EXTRA_DEPENDS is really for, since it's only a potential workaround?
<jow_>
it usually is used to decorate buildsystem generated opkg depends with additional constraints, such as version dependencies
<jow_>
the name of the variable could be better; RUNTIME_DEPENDS or ADDITIONAL_RUNTIME_DEPENDS would convey the purpose more clearly
<hgl_>
jow_, ah, I see. But when submitting a package to openwrt/packages, I should still list runtime deps in DEPENDS right? EXTRA_DEPENDS should only be used for testing purposes I guess?
goliath has quit [Quit: SIGSEGV]
<hgl_>
I mean listing runtime depes in EXTRA_DEPENDS. Checking from other packages, they only use it when a version restriction is needed. I guess I will only use it during testing since it's a pure runtime dep.
<jow_>
hgl_: personally I'd say it's fine even for an offical package
<jow_>
hgl_: hm, actually no. one downside is that scripts/feeds will not recognize the dependency
<jow_>
so if a user builds a custom image, runs scripts/feeds install A and select A as <*> in menuconfig, B will neither get installed from feeds, nor get built or enables as =y in the .config and subsequently not end up in the image
<jow_>
so it is not suitable outside of the local testing scope
<hgl_>
wish runtime deps could be supported. Currently simply by depending on a kmod package, CI building time exploded from a couple minutes to more than half an hour.
<\x>
so there we go
<\x>
first IPQ9574 from xiaomi, 10GbE RJ45 + 10GbE SFP+ + 4x2.5GbE, 2GB RAM 1799CNY
<\x>
oh nvm robi isnt here
<Znevna>
from where does openwrt get the wifi regulatory info?
<aiyion>
Since OpenWrt 22.03? the NanoPi R1 appears to have trouble with its boot device: "Waiting for root device /dev/mmcblk0p2..." it does not fail every time, but often; maybe half the time. Does somebody know whether other devices behave in a similar way?
<stokito>
this is very often needed feature to call REST APIs. Currently acme.sh installs GNU wget to accomplish this. The ddns_scripts are also using the GNU wget just for a few small options and i wish to send another PR to add them but before I need to ensure that all previous patches been applied.
<stokito>
Is it possible somehow to mark these patches with more priority? That would be really great
<stokito>
I can record a video with the PR explanation and demo to make the review easier
<dangole>
stokito: I've seen that patch and was hoping that others would also look at it. I will revisit it later this day.
<stokito>
great, thank you! In case of any question you can just call me on matrix: @stokito:matrix.org or telegram stokito. I'll be near my PC
stokito has quit [Remote host closed the connection]
floof58 is now known as Guest1780
floof58 has joined #openwrt-devel
Guest1780 has quit [Ping timeout: 480 seconds]
nwf has quit [Read error: Connection reset by peer]
cbeznea has joined #openwrt-devel
nwf has joined #openwrt-devel
dansan has quit [Ping timeout: 480 seconds]
soxrok2212 has joined #openwrt-devel
soxrok2212 has quit [Ping timeout: 480 seconds]
PaulFertser has joined #openwrt-devel
robimarko has joined #openwrt-devel
soxrok2212 has joined #openwrt-devel
cc0 has quit [Remote host closed the connection]
schwicht has joined #openwrt-devel
<robimarko>
\x: Did Xiaomi release the BE router?
cc0 has joined #openwrt-devel
minimal has joined #openwrt-devel
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
soxrok2212 has quit [Quit: Who ate my gummy worms?]
soxrok2212 has joined #openwrt-devel
<Znevna>
ERROR: dlopen("/usr/lib/collectd/sensors.so") failed: Error loading shared library liblua.so.5.1.5: No such file or directory (needed by /usr/lib/collectd/sensors.so). The most common cause for this problem is missing dependencies. Use ldd(1) to check the dependencies of the plugin / shared object.
<Znevna>
boo :p
<Znevna>
guess I have to put back lua support for now
<Znevna>
guess I have to put lua back for now
<Znevna>
great I had one line scrolled up ^^ sorry
<soxrok2212>
dangole: issue with xdr--6086 came from dts. dbdc seemed to be breaking it. was going strong for a few hours last night, but when I woke up this morning the device crashed again
<soxrok2212>
rebooted, then eth1 started its up/down loop again. eth1 is connected to a 2.5g port on my modem. 2.5g lan port is connected to my 10g switch so it wouldve negotiated at 2.5g in both cases. lan port seemed okay and doesn't seem to get into an up/down loop
noltari_ has quit [Read error: No route to host]
noltari has joined #openwrt-devel
<dangole>
soxrok2212: the eth1 up/down loop is a new phenomenon of has that been happening before?
noltari has quit [Read error: Connection reset by peer]
<soxrok2212>
dangole: ive just noticed it, but i havent had it up and in use very long
<soxrok2212>
was quite annoying last night
noltari has joined #openwrt-devel
<soxrok2212>
started around 10pm last night my time, rebooted then was fine for ~4-5 hours. woke up to crashed unit, rebooted and eth1 loop started iimediately
<dangole>
almost sounds like it could be thermal related, ie. overheat of the PHY
<soxrok2212>
heat sink wasnt really hot, just warm
<dangole>
ok
<soxrok2212>
but yeah i think dbdc was the cause of the kernel panic
<soxrok2212>
granted i think i got another this morning
<soxrok2212>
amadeus said theres some issues running the rtl8221b connected to the mt7531 switch at 1g
<dangole>
stokito has left and I use Telegram or Matrix. sad.
<dangole>
i don't think that mac rate adaptation is at all implemented for the mt7531 sgmii. the bunch of experimental/draft patch from @lynxis add this for the SoCs GMAC SGMII unit, but not for MT7531
<dangole>
soxrok2212: ^^^^
<soxrok2212>
so lots of work left then
<dangole>
soxrok2212: first of all, Linux 5.15 is by now lagging behind upstream phylink stuff. i'm preparing (yet another) large series of backports from newer linux to linux 5.15 updating phylink and esp. also recent phylink PCS changes
<dangole>
soxrok2212: at this point, unfortunately, my attempts of backporting the relevant parts make things worse rather than better
Borromini has joined #openwrt-devel
<dangole>
soxrok2212: and then this MAC-side SGMII rate adaptation depending on phy link speed has to be implemented in a way that i could be sent upstream -- lynxis hack patches are good for poc, but not good for upstream.
<tmxpro>
Is my flash partition map incorrect if kernel cannot find root partition or is there something else to look out for?
<Znevna>
Borromini: there's no fix regarding MT7613, that guy just has country set to India, which has .. DFS-UNSET >.>
<dangole>
tmxpro: heavily depends on the device in use. obvious reasons other than wrong partitioning in dts include kernel cmdline options, such as mtdparts= or root=, and if the problem occurs after sysupgrade, then most likely sysupgrade code for the device is to blame
<SlimeyX>
hm
<SlimeyX>
will this increase the mac addr in hex? ip link set dev eth1 address $(macaddr_add "$base_mac" 0x1f)
<SlimeyX>
or do i need to use dec of 31
<tmxpro>
hmm if root and mtdparts are not set then where does it determine the root partition from? And is there any systematic way to verify partitioning?
<Borromini>
Znevna: I saw
<Borromini>
Znevna: according to the DFS list on wikipedia though India's supposed to have *some* channesl on DFS
<tmxpro>
dangole: Also can I fully trust flashing in U-Boot or could the device have buggy bootloader aswell? Or it is most likely just incorrect partitions in dts?
<SlimeyX>
nm got it
<dangole>
tmxpro: flashing via U-Boot usually works fine. and yes, if neither mtdparts= nor root= is present in cmdline, then partitioning in dts will decide. in dts you can mark the partition containing the firmware as 'compatible = "openwrt,uimage", "denx,uimage";', that will trigger automatically splitting-off the rootfs and rootfs_data parts. and if there is a partition named 'rootfs', OpenWrt carries a kernel patch selecting it as
<dangole>
the default rootfs.
noltari has quit [Read error: No route to host]
noltari has joined #openwrt-devel
noltari has quit [Read error: No route to host]
noltari has joined #openwrt-devel
<tmxpro>
dangole: Sorry, I just double checked everything and had calculated rootfs partition size incorrectly. After changing it to from about 2MB to full ~4MB it fully booted - I scratched my head on this for 2 days now :D
<dangole>
tmxpro: instead of statically coding the size of kernel and rootfs, it is much better to split a single 'firmware' partition dynamically. in this way you neither waste space nor need to be afraid of kernel growing larger than your previously anticipated fixed size.
<dangole>
tmxpro: and note that the above applies to NOR flash. if the device comes with NAND flash, you should use UBI where ever possible, and for the rootfs it is always possible (for kernel it depends on the bootloader supporting UBI)
<Znevna>
any mt7621 & mt7915 sorcerers that can help me figure out how to enable the wifi leds on ax53u? :P
<tmxpro>
dangole: yes it was "firmware" partition already - but thanks for the info since was I was actually wondering why some devices had "firmware" and some "rootfs" partitions.
<tmxpro>
What should I do once I get all gpio sorted out and everything tested and working? When stock it is 4/32 device, so can I still just try to get the changes into master? And what about adding it to wiki?
shibboleth has joined #openwrt-devel
<dangole>
tmxpro: yes, once everything is working and DTS and userspace additions are clean, please submit a patch to the mailing list or open a PR on github. if you want to edit wiki, send me your full name and email by PM, I can create a wiki account for you.
schwicht has joined #openwrt-devel
noltari has quit [Quit: Bye ~ Happy Hacking!]
noltari has joined #openwrt-devel
noltari has quit [Read error: No route to host]
noltari has joined #openwrt-devel
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
schwicht has joined #openwrt-devel
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
schwicht has joined #openwrt-devel
shibboleth has quit [Quit: shibboleth]
robimarko has quit [Quit: Leaving]
Ansuel has quit [Quit: Probably my PC decided to sleep or I decided to sleep.]
cbeznea has quit [Quit: Leaving.]
torv has quit [Remote host closed the connection]
torv has joined #openwrt-devel
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
tmxpro has quit [Remote host closed the connection]
tmxpro has joined #openwrt-devel
cc0 has quit [Remote host closed the connection]
cc0 has joined #openwrt-devel
T-Bone has joined #openwrt-devel
Yyyyyy has joined #openwrt-devel
f00b4r__ has quit [Read error: Connection reset by peer]
danitool has joined #openwrt-devel
Yyyyyy has quit [Remote host closed the connection]
minimal has quit [Quit: Leaving]
schwicht has joined #openwrt-devel
csrf has joined #openwrt-devel
dansan has joined #openwrt-devel
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<dangole>
soxrok2212: linux 6.1 to be released by kernel.org: probably pretty soon. linux 6.1 used in OpenWrt: we'll see if it gets stamped 'longterm' on kernel.org (chances are not bad for that to happen)