<digitalcircuit>
ipq806x L2 1.4 GHz cache debugging quick update: trying a different 12VDC power supply for the NBG6817 lead to failure in 30 minutes. Either it's nowhere near the 5 amp rating and quality (as router's OEM power supply is only 3.5 amps), or that's not the issue. I've currently moved on to testing a powered USB 3.0 hub so my USB 3.0 HDD draws nearly zero power from the router itself (peaked at 0.001 amps).
<digitalcircuit>
(For what it's worth, the issue seems nondeterministic - sometimes I've had a reboot within 30 minutes on the OEM power supply, too. So the new power supply isn't verifiably worse or better yet. I'd need to measure the actual output under load.)
test has joined #openwrt-devel
test has quit [Remote host closed the connection]
<fda>
blocktrron_: thy, i will test it. i noticed "ipq40xx: set MAC address for AVM boxes at preinit" my fritzrepeater-1200 seems to have the correct mac even without this patch. or is it a preparation for kernel 5.10?
* enyc
meeps
<enyc>
digitalcircuit: I'm thinking capacitors and buck converter quality and so-on ;/
<fda>
blocktrron_: avm7320's mac: i notices lan has mac "00:11:22:33:44:53" . all avm devices have macs in the envorinment of bootloader (adam)
<enyc>
digitalcircuit: I tended to hack things like this by temporarially attaching another low-esr filter cap across the relevant terminals on backside of the board!
<slh>
the nbg6817 tends to run hot, but I wouldn't quite suspect that to be the underlying problem yet (as digitalcircuit is not alone with these issues)
<fda>
blocktrron_: with "generic: Kconfig: exit on unset symbol" 7320 still boots!
<fda>
sry, "generic: fix kernel panic on existing mac-address node"
rmilecki has quit [Quit: Konversation terminated!]
aiyion_ has joined #openwrt-devel
aiyion has quit [Ping timeout: 480 seconds]
rmilecki has joined #openwrt-devel
aiyion has joined #openwrt-devel
aiyion_ has quit [Ping timeout: 480 seconds]
Rentong has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
zhoreeq has quit [Remote host closed the connection]
aiyion_ has joined #openwrt-devel
zhoreeq has joined #openwrt-devel
aiyion has quit [Ping timeout: 480 seconds]
goliath has joined #openwrt-devel
aiyion has joined #openwrt-devel
aiyion_ has quit [Ping timeout: 480 seconds]
dedeckeh has joined #openwrt-devel
nitroshift has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
owrt-1907-builds has quit [Quit: buildmaster reconfigured: bot disconnecting]
owrt-1907-builds has joined #openwrt-devel
owrt-2102-builds has quit [Quit: buildmaster reconfigured: bot disconnecting]
owrt-2102-builds has joined #openwrt-devel
valku has quit [Remote host closed the connection]
owrt-snap-builds has quit [Quit: buildmaster reconfigured: bot disconnecting]
jlsalvador has quit [Read error: Connection reset by peer]
jlsalvador2 is now known as jlsalvador
<Tusker>
hey guys, is there an option to to build the initramfs kernel under 4MB but the sysupgrade image to a different size? Mikrotik seems to only want to boot a kernel 4MB or lower, but has 16M flash
<blocktrron_>
fda: the mac address offset is not necessarily stable for NAND devices
<blocktrron_>
As the pointers are not accounting for broken blocks. As the second stage bootloader is not updated (and the amount of hackery for these devices is already sufficient for my taste), we can just redundantly read it from tffs
danitool has joined #openwrt-devel
<Tusker>
ie, if I set IMAGE_SIZE := 3712k the kernel and initramfs size is good, but the sysupgrade image fails because it's bigger than that...
<Tusker>
I think I'll do it like check-size $$$$(SYSUPGRADE_IMAGE_SIZE)
<Tusker>
yeah, that seems to work well
<rmilecki>
ynezz: thanks
jlsalvador2 has joined #openwrt-devel
jlsalvador has quit [Read error: Connection reset by peer]
<fda>
blocktrron_: i think the mac for 732 worked 1-3 weeks ago. i set vlan-mac different than the lan-interface mac. as i know the hw-mac i could set it witz openwrt.
<fda>
as 00:11:22:33:44:53 does not look random it could cause problems with multiple of these devices in 1 lan
abiliomarques_ has joined #openwrt-devel
jlsalvador2 has joined #openwrt-devel
jlsalvador has quit [Read error: Connection reset by peer]
jlsalvador2 is now known as jlsalvador
<abiliomarques_>
hello guys, after porting a qualcomm MIPS (QCA4531) based hardware to stock OpenWRT 19.07, I must report it runs just fine, except for some performace issues ... it seems that syscalls are too slow. Initially I was using kernel 4.14.209 (as it comes with 19.07), and I thought it was related to security patches of the last few years
<abiliomarques_>
then I went to lede 17, ported the drivers to it, ran kernel 4.4.182, and performance is low compared to qualcomms QSDK
<abiliomarques_>
qualcomm QSDK with kernel 4.4.60 and kernel 4.4.279 is fast
<abiliomarques_>
this penalty seems visible when doing syscalls. It does not seem to affect user mode, and running a test process with time shows that the increment is only in sys
<abiliomarques_>
my test is just basically a loop with several million syscalls
<Habbie>
abiliomarques_, any chance it's vsyscalls vs. real syscalls?
<abiliomarques_>
hmmm, for the sake of simplifying things, I ended up calling syscall with a wrong number (0xFF00) ... it returns -1
<abiliomarques_>
this produces the same behavior as other calls
jlsalvador has quit [Read error: Connection reset by peer]
jlsalvador2 is now known as jlsalvador
<abiliomarques_>
I know Qualcomm is one of those manufacturers that add a lot of their secret sauce, but I thought this was mostly for network drivers
<abiliomarques_>
but do they also boost basic things with the MIPS core?
<aiyion>
can someone recommend a wiki page on how mdio, network interfaces and dts files work together in openwrt?
<aiyion>
I've been probing around for a few days now, but did not find which combination in my dts file would get the interface to work.
Tapper has joined #openwrt-devel
<aiyion>
the ar71xx image does have it on mdio1 if that's what the 'mdio.1' in this line is for: "ag71xx-mdio.1:04 [uid=004dd041"
<aiyion>
I ffel like I'm missing a tool that tells me what mdio interfaces are available (kind of like spidump) and what parameters are used to access them.
<PaulFertser>
aiyion: the upstream kernel docs explain MDIO. And it's often possible to autodetect PHYs connected to an MDIO bus.
<PaulFertser>
aiyion: I think "ag71xx-mdio.1:04" means second (starting from zero) mdio bus and address=4.
<PaulFertser>
(a single bus can control many PHYs, so they need to have different addresses; usually just 1 is used when a single device is present)
wulfy23 has joined #openwrt-devel
<wulfy23>
r17311 bcm2711 seeing a change in scaling behavior pinned much higher(top)
<wulfy23>
anyone else seeing changes in time_in_state?
<wulfy23>
dnsmasq?
<aiyion>
PaulFertser: then I would expect something like this to work: https://bpa.st/TPGQ
<abiliomarques_>
Habbie: any idea on how to profile/continue ?
<aiyion>
But as soon as I reference mdio1 in my dts file instead of mdio0 i get a message like "cannot be probed, trying later".
<aiyion>
compiling just now toverify; one sec
<Habbie>
abiliomarques_, i don't know, sorry
<PaulFertser>
aiyion: please always save and share full dmesg outptu
<aiyion>
only difference in what ive got locally is the mac adress calculation.
<PaulFertser>
aiyion: and full log for ar71xx dmesg too
bluew has quit [Quit: Leaving]
<aiyion>
there you go, the boot log compiled minutes ago (ath79): https://bpa.st/YGNQ
<aiyion>
and an ar71xx pendant, though its freifunk, so the will be batman fragments one should ignore: https://bpa.st/QC2Q
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<PaulFertser>
aiyion: what happens if you just enable eth0 and do not touch anything about mdio? It doesn't seem to be likely that eth0 is actually using mdio1.
<aiyion>
it was skipped as it lacked the meory portion;
<aiyion>
*memory
<karlp>
this is all I had in my board when I ported: https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ath79/dts/ar9331_etactica_eg200.dts;h=402fca80a1eacb63db0a3681953641393930891e;hb=HEAD#l76
* karlp
wonders how onion got completely skipped in ath79, I thought it was relatively common
<aiyion>
what's simple-mfd
* karlp
has no idea anymore... :)
<PaulFertser>
aiyion: no eth0 though in the pull
<karlp>
multi function device at least
<aiyion>
and nvmem cells?
<karlp>
nvmemcells is brand new stuff replacing mtd-mac-shitz
<karlp>
it's a new upstream way of saying where some nvmem is..
<aiyion>
sorry Paul, thats the portion I only have locally as its broken yet; will push one sec
<karlp>
that's not part of your ethernet problem.
<aiyion>
and the gmac portion?
<karlp>
this is related to where the ethernet is actually wired up to the ar9331
<aiyion>
should I install tree to give a better overview, or are you looking for something specific, I don't understand?
<blocktrron_>
fda: are the macaddresses correct upon first boot?
<PaulFertser>
aiyion: if mdio1 is not disabled in DT it should appear there... find /sys -name \*mdio\*
<aiyion>
blocktrron_: the macadresses i added for wireless and claculated for eth are matching up with the ar71xx image.
<aiyion>
other than that there is currently no eth0 device I can verify the mac adress of.
<blocktrron_>
aiyion: i was talking to fda about his lantiq issue, not your onion issue
<aiyion>
PaulFertser: https://bpa.st/SBIA it is there, but under firmware, no where i looked
<aiyion>
blocktrron_: sorry, didn't see the nick; thought it was some abbreviation.
<blocktrron_>
no worries
<aiyion>
at least there's a line regarding the switch
<aiyion>
and within "ethernet-phy@4/"
<aiyion>
would it help to chnage the four to something different again? like zero or one?
<PaulFertser>
aiyion: and what if you enable @eth1 ?
<PaulFertser>
aiyion: no, it wouldn't
<aiyion>
I blindly increased it to match the reg portion earlier.
<aiyion>
enable in the dts file?
<PaulFertser>
aiyion: yes, in the dts. I can't understand how you can end up having /sys/firmware/devicetree/base/ahb/eth@1a000000/mdio/switch0@1f/mdio-bus
<aiyion>
its all pushed in the PR :/
<PaulFertser>
No, I can now. Try enabling both eth0 and eth1, just status ok for both.
<aiyion>
one sec
<PaulFertser>
There's something silly going on but I can't somehow understand just what exactly it is...
<aiyion>
build is running; I removed the mac portion in order to have only status okay.
<karlp>
I think the deal is that you need "eth1" enabled to turn on the switch, and eth0 talks tot he switch
<karlp>
and what's phyiscally connected is eth4, which is on the switch on eth1....
<aiyion>
the other way around, no?
<karlp>
and because it's a switch port with nothing else conneected, you just ignore that it's port 4 or 3 or 2 or 1...
<aiyion>
aye.
<karlp>
also....
<karlp>
this should _not_ be in the "onion" dts.... :)
<Tusker>
is that the normal onion omega ? the small SBC ?
<karlp>
because this only exists when you add a dock....
<karlp>
there's no ethernet port on the onion itself.
<Tusker>
yeah, I have an onion without a dock, so probably can't help out directly
<aiyion>
Tusker: just tried; disbaling it does not cut it;
<aiyion>
set eth0 as disabled;
<aiyion>
now only one eth shows up, called eth0
<karlp>
this is why I said to be careful, as they're just names :)
<aiyion>
but setting the ip and pinging the network results in silence
<aiyion>
understood.
<aiyion>
just wanted to be as lear as possible
<Tusker>
can you compile in phy-tools or mdio-tools? so you can check easily what is on each phy ? enable both mdio0 mdio1 and check each phy on each one
<aiyion>
the interfaces are currently down. Any need in changing tha?
<aiyion>
*that
<Tusker>
looks like eth1 is the one that should work, it didn't come up on boot ?
<aiyion>
eth0 comes up, when i plug and reconnect the cable.
<aiyion>
it says to be part of br-lan, which does not exist prior.
<aiyion>
eth1 (the one that would work) does not try to be part of br-lan (which is fine i tthink) but does not come up without manual intervention.
<Tusker>
if you disable 1a000000.eth, does the resultant eth0 attach to mdio.0:1f:04 ?
<aiyion>
with which comand?
<Tusker>
i mean, in your dts, if you disable 1a000000
<aiyion>
if I disbale either the other becomes the eth0 thats stuck.
<aiyion>
that's the problem PaulFertser spoke about 80 minutes ago :/
<Tusker>
aiyion: if you use ethtool and change it to autoneg off, and 10mbps link, do you see any activity coming from it ? if you set it to fixed 1000 in dts ?
<Tusker>
or maybe you need to reconfigure 1a000000 and point it to mdio.0:1f:04 ?...
<aiyion>
I'd have to read up on how to do either of the proposed :S
<fda>
blocktrron_: in char-dev /dev/mtd0 ('urlader') are 6 sqeuential macs, inclusing original lan-mac, with names like maca, macb, macwlan, macwlan2, macdsl
zhoreeq has quit [Remote host closed the connection]
zhoreeq has joined #openwrt-devel
zhoreeq has quit []
<hauke>
blocktrron_: multiple builds are failing becasue of your kernel config changes
<hauke>
I like them
<hauke>
the improvment, but someone should take care of the fallout
<aiyion>
If I get the diagram in the ar9331's datasheet right, I'd like to discuss a previous statement of yours; regarding it wouldn't matter which switch port it is connected to.
<Slimey>
hi there
<aiyion>
" karlp | and because it's a switch port with nothing else conneected, you just ignore that it's port 4 or 3 or 2 or 1... "
<aiyion>
phy 4 does not appear to be connected to the other phys, does it?
<aiyion>
The question would then be how one'd enable the switch with only eth0 (100M mii) and not the gmii one present.
<karlp>
~I mean, you had this working, you're just poking things for fun now right?
<karlp>
just turn on both ports.
<karlp>
you can probably find "alternative" ways of making it work, but to what end?
<karlp>
there's existing hardware that just enables both ports, so that the switch gets enabled properly.
<karlp>
unless you have an itch in how the kernel handles this platform wide, just enable them both and walk away
<aiyion>
karlp: Well, I'd like to get the dts file upstream;
<aiyion>
All I heard up until now, does not give me confidence a ghost interface would be suitable.
<karlp>
if you follow the exact same style as the other openwrt files, they have the best chance of all going together.
<karlp>
and also easiest for them to all get "fixed" together.
<karlp>
I'm pretty sure that's why mine lists it as a simple-mfd....
<karlp>
so it's not "ethernet" it's jsut "turn this on so the right bits get turned on.
<karlp>
I think you're overstressing it.
<aiyion>
ah
<karlp>
get it into openwrt, matching other openwrt devices, and matching expected behaviour from how it was with ar71xx, (ie, do macs match what you expect) then worry about upstream.
<karlp>
upstreaming ath79 is a major task, you're not just going to try and send your dts from openwrt as is :)
<aiyion>
instead I would do what?
<aiyion>
not as is; I'm lacking a bunch of gpios as well as the proper ethernet behaviour.
<karlp>
just submit to openwrt.
<karlp>
"restore onion dropped in ath79 migration"
<blocktrron_>
What I'm still wondering - this definitely was the behavior in the past (failing on missing config symbols), but got lost somehow when switching to 4.19 / 5.4
<RyanHallmighty>
Hey there :) I am interested in trying to learn about development concerning this project and specifically I have a device with the RTL8196E chipset and I haven't found anything for it and I'm curious if there's any work that has been done regarding it :)
jlsalvador has quit [Read error: Connection reset by peer]
jlsalvador has joined #openwrt-devel
Borromini has quit [Quit: Lost terminal]
jlsalvador has quit [Quit: jlsalvador]
danitool has joined #openwrt-devel
Acinonyx_ has quit [Remote host closed the connection]
Acinonyx has joined #openwrt-devel
rejoicetreat has joined #openwrt-devel
jlsalvador has joined #openwrt-devel
rmilecki has quit [Ping timeout: 480 seconds]
dedeckeh has quit [Remote host closed the connection]
<slh>
RyanHallmighty: the short answer is no, and it's not very likely that it will be supported in the futuer either - the long answer would be documented in the forum, under the search term 'lexra' (and that's before even looking at the abysmal driver state for realtek wireless)
<hauke>
blocktrron_: I also saw this at work with kenre 4.19 the build passes sometimes even when there are some unkwon options
<blocktrron_>
hauke: I'm pretty sure we've had build failures upon unset symbols in the past with the buildbots
<blocktrron_>
maybe the buildbot behaves different know, idk
<hauke>
blocktrron_: we saw this only when building with -jX something, but not when buidling without -j in the second run
rsalvaterra has quit [Quit: Leaving]
Tapper has joined #openwrt-devel
<RyanHallmighty>
@slh alright thanks for the info :)
<blocktrron_>
hauke: "saw this only" --> build failing or build succeeding?
<slh>
RyanHallmighty: it doesn't really help either that most known RTL8196E devices provide insufficient system resources (usually 4 MB flash and 32 MB RAM, sometimes even less)
RyanHallmighty has quit [Remote host closed the connection]
<hauke>
with -jX it failed and without -j it passed
<blocktrron_>
interesting
RyanHallmighty has joined #openwrt-devel
Tusker has joined #openwrt-devel
RyanHallmighty has quit [Remote host closed the connection]
netprince has quit [Read error: Connection reset by peer]
Tusker is now known as Guest3859
Guest3859 has quit [Read error: Connection reset by peer]