ChanServ changed the topic of #linux-sunxi to: Allwinner/sunxi development - Did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait for an answer! - This channel is logged at https://oftc.irclog.whitequark.org/linux-sunxi
evgeny_boger has quit [Ping timeout: 480 seconds]
vagrantc has joined #linux-sunxi
mnemoc has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
mnemoc has joined #linux-sunxi
<libv> MoeIcenowy: not sure there is a gpl drop yet, i have not looked though
vagrantc has quit [Quit: leaving]
cnxsoft has joined #linux-sunxi
evgeny_boger has joined #linux-sunxi
<evgeny_boger> smaeul: hi, I have T507 BSP and it's indeed use the same "sun50iw9p1" code as H616.
<smaeul> evgeny_boger: thanks for confirming!
<smaeul> btw all of the code snippets I pasted came from the MR813 BSP
cnxsoft1 has joined #linux-sunxi
cnxsoft has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
hlauer has joined #linux-sunxi
apritzel has joined #linux-sunxi
<evgeny_boger> btw, anyone got R528 datasheet (not user manual)?
Daanct12 has joined #linux-sunxi
<montjoie> anyone with a orangepi one plus ? ethernet is not working
indy has quit [Read error: Connection reset by peer]
indy has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
pmp-p has joined #linux-sunxi
<hlauer> montjoie: Is this a new device or did it work in the past?
tnovotny has joined #linux-sunxi
tnovotny has quit [Quit: Leaving]
apritzel has joined #linux-sunxi
<mps> anyone here using Olimex olinuxino-a64 board? with latest kernels (5.16 and 5.17) uptime shows loads over 1.0 even when just few basic processes are running
<montjoie> hlauer: I saw commit fixing it, so it should have worked
<mps> on olimex teres notebook which is also A64 SoC load is normal
<mps> I tested with local kernel build and armbian kernels
<hlauer> montjoie: Is 100Mbit working? Because the fix is GBit only
<montjoie> hlauer: the kernel say no PHY at this address
Daanct12 has quit [Remote host closed the connection]
Daanct12 has joined #linux-sunxi
<hlauer> ok, then I have no idea
Daaanct12 has joined #linux-sunxi
Daanct12 has quit [Read error: Connection reset by peer]
evgeny_boger has quit [Ping timeout: 480 seconds]
Daaanct12 has quit [Remote host closed the connection]
anarsoul has quit [Read error: Connection reset by peer]
anarsoul has joined #linux-sunxi
evgeny_boger has joined #linux-sunxi
adjtm has quit [Read error: Connection reset by peer]
JohnDoe_71Rus has quit []
hlauer has quit [Remote host closed the connection]
cnxsoft1 has quit []
JohnDoe_71Rus has joined #linux-sunxi
vagrantc has joined #linux-sunxi
Danct12 has quit [Remote host closed the connection]
<montjoie> that is strange, pineh64 works but not opi1+
<apritzel> montjoie: what is your setup, exactly? which kernel/DT?
<montjoie> I try 5.18-rc4 and 5.17.x (next is broken)
<montjoie> dwmac-sun8i 5020000.ethernet eth0: no phy at addr -1
<montjoie> so it is like phy_addr is never set
<montjoie> but the code path should be ok since on the same kernel, pineH64 works
<montjoie> hardcoding the addr to 1 do not work, so a bigger problem is here
<apritzel> is there anything suspicious in dmesg? Does the gmac-3v3 regulator show up?
<montjoie> I enable regulator debug and retry
<apritzel> you could also check /sys/kernel/debug/regulator/regulator_summary
<apritzel> also it looks like Ethernet is not enabled in mainline U-Boot (but it is for the PineH64), not sure if that has an effect?
<montjoie> that could be a reason, anyway my job need ethernet for updating uboot... so a manual uboot update will be necessary
<apritzel> the PHY regulator looks pretty straight-forward, just raise PD6, but then again OrangePi was picky about timing before
<montjoie> gmac3v3 is enabled
<jernej> montjoie: if I'm not mistaken, opi1+ has same ethernet bringup problems as opi3, but for some reason, opi1+ ethernet support was mainlined and opi3 not
<jernej> montjoie: if i recall correctly, megi created some driver patches for handling dual power supplies
<jernej> to ensure correct power up steps
<jernej> i have no idea why it was never mainlined
<montjoie> megi: hello, any link to patches ?
<jernej> patches 44-47
<montjoie> megi: any plan to mainline ?
<megi> patches would need to be re-done differently, since this was rejected upstream
<megi> different DT bindings
<megi> to me it's a bit bizarre that each ethernet driver needs to handle powerup of the phy instead of this being done by the phy driver itself
<montjoie> megi: do you have a link to the rejection ?
<megi> no
<megi> it basically states to move phy-io-supply to phy DT node
<megi> personally, I'd move both -supply proeprties there, but then it would be even weirder to keep the powerup code in stmmac driver :)
<megi> I'm pretty sure someone will dislike splitting the properties like that, so if you just follow the suggestion, you'll get another runaround
<montjoie> I dont understand the need to splitting phy supplies
<megi> well, you can do it a hacky way and declare one of those supplies as supplied by the other
<montjoie> and why about adding support for it in phy-core ?
<montjoie> thanks for the link
<megi> oh, yeah, now I rememeber, this is not just stmmac handling phy powerup but specific sunxi glue for it... so some really obscure glue code searching around in multiple DT nodes to find how to powerup something that would best be handled elsewhere
apritzel has quit [Ping timeout: 480 seconds]
evgeny_boger has quit [Ping timeout: 480 seconds]
evgeny_boger has joined #linux-sunxi
machinehum1 has joined #linux-sunxi
evgeny_boger has quit [Ping timeout: 480 seconds]
machinehum has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
JohnDoe_71Rus has quit []
adjtm has joined #linux-sunxi
qwestion has quit [Ping timeout: 480 seconds]
evgeny_boger has joined #linux-sunxi
adjtm has quit [reticulum.oftc.net coulomb.oftc.net]
diego71 has quit [reticulum.oftc.net coulomb.oftc.net]
pgwipeout[m] has quit [reticulum.oftc.net coulomb.oftc.net]
chuang[m] has quit [reticulum.oftc.net coulomb.oftc.net]
Arthur[m]123 has quit [reticulum.oftc.net coulomb.oftc.net]
sajattack[m] has quit [reticulum.oftc.net coulomb.oftc.net]
z3ntu has quit [reticulum.oftc.net coulomb.oftc.net]
psydroid[m] has quit [reticulum.oftc.net coulomb.oftc.net]
Nemo_bis has quit [reticulum.oftc.net coulomb.oftc.net]
igraltist has quit [reticulum.oftc.net coulomb.oftc.net]
evadot has quit [reticulum.oftc.net coulomb.oftc.net]
jemk has quit [reticulum.oftc.net coulomb.oftc.net]
ndufresne has quit [reticulum.oftc.net coulomb.oftc.net]
rtp has quit [reticulum.oftc.net coulomb.oftc.net]
karlp has quit [reticulum.oftc.net coulomb.oftc.net]
ad__ has quit [reticulum.oftc.net coulomb.oftc.net]
maz has quit [reticulum.oftc.net coulomb.oftc.net]
adjtm has joined #linux-sunxi
diego71 has joined #linux-sunxi
sajattack[m] has joined #linux-sunxi
Nemo_bis has joined #linux-sunxi
chuang[m] has joined #linux-sunxi
rtp has joined #linux-sunxi
Arthur[m]123 has joined #linux-sunxi
pgwipeout[m] has joined #linux-sunxi
maz has joined #linux-sunxi
z3ntu has joined #linux-sunxi
jemk has joined #linux-sunxi
ndufresne has joined #linux-sunxi
evadot has joined #linux-sunxi
igraltist has joined #linux-sunxi
karlp has joined #linux-sunxi
ad__ has joined #linux-sunxi
psydroid[m] has joined #linux-sunxi
Danct12 has joined #linux-sunxi
Danct12 has quit [Quit: Quitting]
Danct12 has joined #linux-sunxi
<mps> hmm, looks like I found suspect for high load on olimex olinuxino-a64 with 5.16 kernel and up. it is r8188eu rtl wifi driver in combo with wpa_supplicant
adjtm has quit [Quit: Leaving]
Asara has quit [Quit: leaving]
Asara has joined #linux-sunxi