sputnik_ has quit [Remote host closed the connection]
sputnik_ has joined #linux-amlogic
Darkmatter66 has quit [Ping timeout: 246 seconds]
Darkmatter66_ has joined #linux-amlogic
kaspter has joined #linux-amlogic
camus has joined #linux-amlogic
kaspter has quit [Ping timeout: 246 seconds]
camus is now known as kaspter
sputnik_ has quit [Ping timeout: 256 seconds]
nickotheus has quit [Quit: Leaving]
camus has joined #linux-amlogic
kaspter has quit [Ping timeout: 246 seconds]
camus is now known as kaspter
sputnik_ has joined #linux-amlogic
camus has joined #linux-amlogic
camus1 has joined #linux-amlogic
kaspter has quit [Ping timeout: 256 seconds]
camus1 is now known as kaspter
camus has quit [Ping timeout: 265 seconds]
vagrantc has quit [Quit: leaving]
kaspter has quit [Ping timeout: 256 seconds]
camus has joined #linux-amlogic
camus is now known as kaspter
bengal has quit [Ping timeout: 265 seconds]
bengal has joined #linux-amlogic
sputnik_ has quit [Remote host closed the connection]
Darkmatter66_ has quit [Ping timeout: 260 seconds]
sputnik_ has joined #linux-amlogic
Barada has joined #linux-amlogic
ldevulder_ has joined #linux-amlogic
ldevulder has quit [Ping timeout: 240 seconds]
buzzmarshall has quit [Remote host closed the connection]
kaspter has quit [Ping timeout: 265 seconds]
kaspter has joined #linux-amlogic
ldevulder_ is now known as ldevulder
trem has joined #linux-amlogic
damex has quit [Read error: Connection reset by peer]
damex has joined #linux-amlogic
Barada has quit [Quit: Barada]
sputnik__ has joined #linux-amlogic
sputnik_ has quit [Ping timeout: 260 seconds]
Darkmatter66 has joined #linux-amlogic
Darkmatter66 has quit [Ping timeout: 265 seconds]
camus has joined #linux-amlogic
kaspter has quit [Ping timeout: 256 seconds]
camus is now known as kaspter
sputnik__ has quit [Ping timeout: 240 seconds]
camus has joined #linux-amlogic
kaspter has quit [Ping timeout: 240 seconds]
camus is now known as kaspter
trem has quit [Quit: Leaving]
buzzmarshall has joined #linux-amlogic
sputnik__ has joined #linux-amlogic
kaspter has quit [Quit: kaspter]
kaspter has joined #linux-amlogic
sputnik__ has quit [Ping timeout: 260 seconds]
cmeerw has joined #linux-amlogic
Darkmatter66 has joined #linux-amlogic
vagrantc has joined #linux-amlogic
yann has quit [Ping timeout: 272 seconds]
yann has joined #linux-amlogic
hexdump0815 has joined #linux-amlogic
<hexdump0815>
xdarklight: nice find - i added it and in my situation it did not really change anything ... i also re-checked my assumption that enabling/disabling the SND_MESON and SND_SOC_MESON options breaks/fixes eth for my sm1 and g12a boxes
<hexdump0815>
xdarklight: could it maybe be that on those boxes something is wired differently (from the sei510/sei610 dtbs i use as a base) in the hardware resulting in a mixup between eth and audio somehow?
<hexdump0815>
xdarklight: so it would be interesting to know if you have those options enabled for your box ... but there is no hurry with all this
<chewitt>
hexdump0815 are you 100% sure it's S905X3 .. not S905X2?
<hexdump0815>
chewitt: i see the problem on both actually :) ... so one box with x2 and one box with x3 and those boxes are really x2 and x3 as i built atf and u-boot for them as well and would have noticed if they were fake hardware
<chewitt>
It's just really unusual to see deviation from the reference designs with tvbox devices
<chewitt>
have you got a dump of the Android device-tree?
<chewitt>
I'd expect WiFi/BT to be different, and occasionally I see USB Ethernet instead of the usual Realtek chips
<chewitt>
but audio and other core SoC stuff .. if you're a far-east box vendor, why would you go out of your way to change everything?
<chewitt>
have you tried booting with vendor u-boot and mainline device-trees?
<hexdump0815>
chewitt: i wiped the emmc on the box and would have to restore it to be able to boot via legacy u-boot
<chewitt>
I'm just wondering .. if the Linux dts is 'wrong' in some way, then porting it to u-boot also messes up u-boot and you get double weird
<chewitt>
vendor u-boot might be fugly crap, but at least you know it sets up the hardware correctly, so one less variable in the processs
<hexdump0815>
chewitt: so your sm1 & g12a boxes with ext phy are working well with wired ethernet and audio and 5.9?
<chewitt>
the G12A/B devices I have work well, the SM1 board (not box) devices I have work well
<hexdump0815>
chewitt: so far i only made very good experiences with mainline u-boot on gxl/gxm boxes - it was just working fine ... i guess even chinese vendors are lazy and do not really modify the reference designs much :)
<hexdump0815>
chewitt: and you also explicitely tested wired etherent?
<chewitt>
I don't have any SM1 box hardware, but there's been enough success reports with the ac2xx dtsi and related dts that I'm fairly confident in it
<chewitt>
I rarely use WiFi
<chewitt>
takes too much effort to configure
<hexdump0815>
chewitt: and your ac2xx dts is not really much different from sei510/610 i guess?
<chewitt>
so I have an old Apple airport express that acts as a WiFi bridge; gives me 100-BaseT ethernet for anything i'm tinkering with
<chewitt>
the ac2xx is a mash-up of the SEI610 and g12a-x96-max dts
<chewitt>
mostly SEI610
<chewitt>
but using the audio/ethernet approach used in the g12a box, which is the same as used in the w400 (g12b) dtsi and many other similar ones
<chewitt>
since GXL, tvbox devicess rarely deviate much from the reference designs
<chewitt>
in GXBB there's more variety
<hexdump0815>
repk: narmstrong: btw. while we are at mainline u-boot on boxes - i thought that i had mainline atf working for sm1 following neils suggestion to simply change it to a55 - it boots nice but runs into an assert later as i noticed: https://github.com/hexdump0815/u-boot-misc/blob/master/readme.gxy#L5-L12
<hexdump0815>
repk: narmstrong: so maybe there is more work required to really get mainline atf working on sm1 ... maybe its just tv box weirdness, so maybe someone should try it on an odroid c4 maybe to verify
<chewitt>
I would revert back to vendor u-boot, get the Linux dts right, then experiment with u-boot knowing the Linux bits work
<chewitt>
looking at the various vendor u-boot sources I have, the main thing manufacturers seem to fiddle with is the ddr4 specs
<chewitt>
experiment with the VIM3L/C4 fips; if those result in boot, then I wouldn't reinvent the wheel too much
<chewitt>
(and SEI610)
<hexdump0815>
yes for this i have simply dumped out the ddr timinigs from a box and use that instead of the usual amlogic/odroid ddr files - works well so far - i guess those boxes simply have lower spec ram than the odroid files expect ...
<hexdump0815>
just to avoid misunderstandings: i have both g12a and sm1 booting perfectly fine with mainline u-boot, g12a even with mainline atf ... and without SND_MESON and SND_SOC_MESON options even ethernet works well
<hexdump0815>
in the kernel i mean - u-boot does not have ext phy support yet i think, so there eth does not really work, but i do not care yet about that
<narmstrong>
The collusion between eth and audio is weird, seems like with gigabit an mpll is used as clock source, could you dump the clock summary from debugfs when gigabit is working ? And same when audio is enabled and gigabit fails ?
<hexdump0815>
narmstrong: this is the clk-summary from the non working case (i.e. audio compiled in back then): https://pastebin.com/raw/5My93eAs ... but i'll get a fresh comparison with audio in and not soon ... one thing to note: my network is only 100mbit, but the boxes have a gbit phy
<narmstrong>
Indeed this shows Ethernet uses the mpll2 for the 250mhz clock which is wrong
<hexdump0815>
narmstrong: when i tried older kernels i noticed that for an old 5.8.0 it used the fdiv2 clk like xdarklight sees it with 5.9 too
<narmstrong>
Seems 1999999970 has a rounding error so it selects a different source
<narmstrong>
Fixed_pll
<narmstrong>
Would be interesting to have the same dump on 5.8
<narmstrong>
Maybe the pll calculation changed in between
<xdarklight>
hexdump0815: so indeed, bisecting would be awesome. also before bisecting it would be great if you could try https://pastebin.com/MauF040X
<hexdump0815>
xdarklight: i have that patch in already - it did not really change anything for me - what should i expect from it?
<xdarklight>
hexdump0815: OK, thanks for testing then. without that patch I'm not sure if the mux inside the dwmac-meson8b can change the parent clock as the mask is wrong (it should be 0x1 but it's actually 0x1 << 4)
<hexdump0815>
xdarklight: i'll keep it in ... will try a kernel with your selection of SND_MESON options - lets see if then eth still works for me ... for the bisecting: the point to look for is where the parent clock switches to mpll - right?
<xdarklight>
hexdump0815: yep, ff3f0000.ethernet#rgmii_tx_en needs to be very close to 125MHz - and with the MPLL2 parent which you are seeing this is way off
Darkmatter66 has quit [Read error: Connection reset by peer]
<hexdump0815>
xdarklight: i just got a fresh clock summary and now its close to 125mhz (this is with disabled audio and your patch in now) - https://pastebin.com/raw/6Cr11aK0
<xdarklight>
hexdump0815: in that state I expect Ethernet to work
<hexdump0815>
xdarklight: yes with these settings it works
<hexdump0815>
xdarklight: with your SND_MESON settings i have no ethernet
Darkmatter66 has joined #linux-amlogic
Darkmatter66 has quit [Client Quit]
<hexdump0815>
xdarklight: clk-summary with your audion settings (otherwise everything else is the same as from the clk-summary above) - eth not working: https://pastebin.com/raw/mKHEh4Cw
ldevulder has quit [Read error: Connection reset by peer]
<xdarklight>
hexdump0815: OK, I think that it confirms Neil's suspicion: there's something wrong with the clock calculation
ldevulder has joined #linux-amlogic
<hexdump0815>
xdarlight: will build a kernel from your exact config overnight to see what i get with that (just to rule out possible missing options etc.)
<hexdump0815>
xdarklight: and then will start the bisecting tomorrow most probably
<xdarklight>
sure, thanks
hexdump0815 has quit [Remote host closed the connection]