Elpaulo has quit [Read error: Connection reset by peer]
Elpaulo has joined #linux-amlogic
bengal has quit [Ping timeout: 240 seconds]
bengal has joined #linux-amlogic
sputnik_ has quit [Ping timeout: 256 seconds]
kaspter has quit [Ping timeout: 240 seconds]
kaspter has joined #linux-amlogic
buzzmarshall has quit [Remote host closed the connection]
kaspter has quit [Remote host closed the connection]
kaspter has joined #linux-amlogic
kaspter has quit [Remote host closed the connection]
kaspter has joined #linux-amlogic
sputnik_ has joined #linux-amlogic
efqw has joined #linux-amlogic
Barada has joined #linux-amlogic
Barada has quit [Client Quit]
Barada has joined #linux-amlogic
kaspter has quit [Ping timeout: 256 seconds]
kaspter has joined #linux-amlogic
drieschel has joined #linux-amlogic
camus has joined #linux-amlogic
kaspter has quit [Ping timeout: 256 seconds]
camus is now known as kaspter
drieschel has quit [Quit: drieschel]
asdf28 has joined #linux-amlogic
ldevulder has joined #linux-amlogic
ldevulder has quit [Quit: Leaving]
ldevulder has joined #linux-amlogic
kaspter has quit [Ping timeout: 260 seconds]
kaspter has joined #linux-amlogic
cmeerw has joined #linux-amlogic
Linnaea_ has quit [Ping timeout: 264 seconds]
Linnaea_ has joined #linux-amlogic
damex has quit [Ping timeout: 272 seconds]
ldevulder has quit [Quit: Leaving]
ldevulder has joined #linux-amlogic
camus has joined #linux-amlogic
kaspter has quit [Ping timeout: 256 seconds]
camus is now known as kaspter
random_yanek has quit [Quit: random_yanek]
random_yanek has joined #linux-amlogic
kaspter has quit [Ping timeout: 256 seconds]
kaspter has joined #linux-amlogic
Barada has quit [Quit: Barada]
camus has joined #linux-amlogic
kaspter has quit [Ping timeout: 272 seconds]
camus is now known as kaspter
Necrosporus has quit [Ping timeout: 260 seconds]
Necrosporus has joined #linux-amlogic
damex has joined #linux-amlogic
kaspter has quit [Quit: kaspter]
kaspter has joined #linux-amlogic
sputnik_ has quit [Ping timeout: 256 seconds]
vagrantc has joined #linux-amlogic
hexdump0815 has joined #linux-amlogic
<hexdump0815>
xdarklight: i'm struggling quite a bit trying to get ethernet working on a h96max-x3 sm1/s905x3 box - i only have a 100mbit hub, so its not a gbit problem - i'm not getting any real connection through
<hexdump0815>
xdarklight: what looks potentially suspect to me is the "meson8b-dwmac ff3f0000.ethernet: no reset control found" line and maybe there there are multiple "libphy: mdio_mux: probed" but maybe they are ok
<hexdump0815>
xdarklight: i'm running mainline u-boot on the box directly, i.e. legacy u-boot is wiped and replaced by mainline u-boot which works perfectly fine otherwise and the non working ethernet was a problem also with legacy u-boot and chainloading a mainline u-boot
<hexdump0815>
xdarklight: any idea how to resolve or debug this would be very welcome - if any additional information or any further tests are required, please let me know
hexdump0815 has quit [Remote host closed the connection]
kaspter has quit [Quit: kaspter]
<Necrosporus>
I have managed to enable framebuffer console but it seems to be using 720p resolution by default. How do I make it use 1080p instead?
damex has quit [Ping timeout: 240 seconds]
damex has joined #linux-amlogic
damex has quit [Ping timeout: 265 seconds]
damex has joined #linux-amlogic
hexdump0815 has joined #linux-amlogic
afaerber has quit [Ping timeout: 240 seconds]
<hexdump0815>
xdarklight: i forgot - i see a similar behaviour on a g12a/s905x2 t95q box which seems to use the external phy as well
<hexdump0815>
chewitt: i also tried your latest libreelec -box test images but it looked a bit like they are a bit in the flux right now (some strange messages here and there) - is there any play where i can find a stable version of the amlogic-box image?
<xdarklight>
it will bring the dwmac controller IP into a "known state", instead of relying in whatever (strange) state u-boot left it
<xdarklight>
hexdump0815: apart from that everything it looking good: you're not forcing the PHY ID (with a compatible string) so the PHY's reset line must be fine. link up and speed are detected so the PHY interrupt is either OK or not broken enough to not detect the link ;). drivers all seem to be enabled correctly
<xdarklight>
hexdump0815: the only idea that comes to my mind: try CONFIG_REALTEK_PHY=y instead of =m - that's pure trial and error though, just because I seem to remember that someone once may have said that it could fix things
<hexdump0815>
xdarklight: thanks a lot for the quick response - i did not have that patch in, so testing it now and will add the =y for the realtek phy as well and report back
<hexdump0815>
xdarklight: with those two changes the "no reset control found" is gone now, but sadly i'm still not getting any connection - what combination of phy-mode and delay parameters would be the most safe for 100mbit?
<hexdump0815>
xdarklight: one thing i noticed is if i do an ifconfig down and afterwards up i end up with "flow control off" while initially i had "flow control rx/tx" - does this have any meaning?
<xdarklight>
hexdump0815: anything with rgmii in the name should be safe, I'd probably start with rgmii-txid
<xdarklight>
hexdump0815: for flow control I am not sure, this is a question which I would ask the stmmac maintainers
<hexdump0815>
xdarklight: no change with rgmii-txid ... some other observation: if i rmmod the dwmac_meson8b driver and modprobe it again then i get a null pointer: https://pastebin.com/raw/u839iT1z ... i guess this is not supposed to hapen? would it make sense to compile the driver with =y too?
<xdarklight>
hexdump0815: ew, this is not supposed to happen. seems like a stmmac bug :(
<xdarklight>
hexdump0815: since it's simple to do so you can try =y for the dmwac-meson8b driver, but it's just another trial and error change :(
<hexdump0815>
xdarklight: and another observation - in my resulting dtb i get "interrupts = <0x0 0x8 0x4>;" and in the android dtb i have "interrupts = <0x0 0x8 0x1>;" - is this due to the different kernels or a real difference?
<hexdump0815>
xdarklight: ok - thx for the info - maybe i should try with 5.10-rc next then after =y
<xdarklight>
hexdump0815: looking at that commit since we're at trial and error: you may want to add eee-broken-100t; to the PHY and pastebin the ethtool -S eth0 output
<asdf28>
xdarklight: regarding the bluetooth device tree node, i saw "enable-gpios = <&gpio GPIOX_17 GPIO_ACTIVE_HIGH>;"
<asdf28>
could it be that this is necessary to enable the module?
<xdarklight>
asdf28: yes, definitely :) that's one of the problems when doing it in userspace: when and how to toggle this GPIO
<asdf28>
ah, okay
<asdf28>
i have compared everything with the android system, the serial device is the same and it's using the same firmware
<asdf28>
but it seems to be dead
<asdf28>
i have tried the legacy and the mainline driver and it doesn't output anything, it's just as if it wouldn't exist
<asdf28>
i'll try to figure out how the android kernel did this
<xdarklight>
asdf28: I'd try with the mainline kernel again. don't just try with GPIO_ACTIVE_HIGH but also try with GPIO_ACTIVE_LOW - I'm not sure what polarity they are using in the Android kernel so it may require flipping
<asdf28>
there's a device "bt-dev" in the android dts, this has "gpio_reset = <0x18 0x60 0x00>;"
<asdf28>
okay, thank you i'll try that1
<asdf28>
!
<xdarklight>
asdf28: you're on the right track. now the question is: what GPIO is 0x60 in the Android kernel ;)
<hexdump0815>
xdarklight: sure - will give it a try - just to be sure it was 100 (not 1000) in eee-broken-100t?
<xdarklight>
hexdump0815: good point. eee-broken-1000t and eee-broken-100tx both exists. since we're doing trial and error: set both
<xdarklight>
(100t doesn't exist, it's 100tx)
<asdf28>
to be honest, i don't even know what GPIO means... i need to read abit more about that first
<asdf28>
gpio_reset = <0x18 0x60 0x00>; <-- maybe 0x00 refers to GPIO_ACTIVE_LOW then? this is defined as 0 in the kernel... yes i'll try that
<xdarklight>
asdf28: 0x0 means GPIO_ACTIVE_HIGH, 0x1 is GPIO_ACTIVE_LOW. but the Android kernel doesn't respect this flag and has some weird things hardcoded (and sometimes patched by different vendors). in other words: only trust the GPIO number ;)
<asdf28>
and GPIOX_17 in the mainline DTS equals 0x60 so this could be correct
<asdf28>
oh, you're right, i got confused about the ACTIVE_HIGH/LOW there
<hexdump0815>
how does this gpio naming work btw. i.e. mapping GPIOX_17 to 0x60?
<xdarklight>
okay that's good. I guess it's only about the polarity then (in theory it can be related to the 32kHz clock also, but let's keep that out of the equation - on my boards with RTL8723BS it was never necessary)
<asdf28>
so then, the android dts is equivalent, but it has this extra value of 0x18 at the start: gpio_reset = <0x18 0x60 0x00>;
<asdf28>
whereas the mainline dts only has the latter two values
<xdarklight>
hexdump0815: it's defined in include/dt-bindings/gpio/meson*.h - then there's the mapping between "that number" and the hardware registers in the pinctrl driver
<xdarklight>
asdf28: 0x18 is the reference to the GPIO controller, probably "&gpio" in the mainline .dts
<asdf28>
anyway, i did not have this enable-gpio setting yet, so i'll try that now, this could be it
GNUtoo has quit [Ping timeout: 260 seconds]
<xdarklight>
hexdump0815: weird, it says that you're receiving data. and all error fields are zero, huh
<hexdump0815>
xdarklight: yes - i just ran the command twice with a moment inbetween and diffed the results and the rx counters seem to grow
<hexdump0815>
xdarklight: i guess in theory i should have counters for tx too then - right?
<xdarklight>
hexdump0815: yes - near the very top. can you also check the output of: "ip a" and see if your dhcp client (assuming you want to use DHCP) is running?
<hexdump0815>
xdarklight: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 5e:ff:28:11:bc:cb brd ff:ff:ff:ff:ff:ff
<hexdump0815>
xdarklight: dhcp client is running
<hexdump0815>
xdarklight: and indeed with tcpdump i can see traffic on the interface
hexdump081557 has joined #linux-amlogic
<hexdump081557>
hm - got disconnected and am now reconnected under another name :)
<hexdump081557>
xdarklight: incoming traffic i mean i can see with tcpdump - so looks like receiving works but sending does not
hexdump0815 has quit [Ping timeout: 245 seconds]
hexdump081557 has quit [Remote host closed the connection]
hexdump0815 has joined #linux-amlogic
<xdarklight>
hexdump0815: hmm, can you please go to u-boot and run a command for me? let me look up that command
<hexdump0815>
xdarklight: there is no autocali command - do i have to rebuild u-boot with some option for it maybe?
<xdarklight>
hexdump0815: ah, I totally forgot that you're on mainline u-boot
sputnik_ has joined #linux-amlogic
<hexdump0815>
xdarklight: my u-boot is sei610 based and seems to have the internal phy configured - but this should not be a problem - or?
<hexdump0815>
xdarklight: is the kernel assuming any initial eth setup from u-boot?
<xdarklight>
hexdump0815: the kernel should not assume anything like that. unfortunately I -ETIMEDOUT for today. if you have any chance to run the autocali command from the vendor u-boot then please pastebin the output. else the next thing to check is probably clocks... RGMII TX clock may be off/wrong
<hexdump0815>
xdarklight: ok - thx a lot for your help ... i think i saw i small diff in the clocks lines in the dts too
<hexdump0815>
xdarklight: i have a dump of the emmc which i made before i wiped it - i can try to revert to android with it and the run the autocali command in legacy u-boot
cmeerw has quit [Ping timeout: 268 seconds]
<xdarklight>
hexdump0815: if you saw something wrong with the clocks then I'd check these first
<hexdump0815>
xdarklight: looks like they are not really comparable - only one clk in android dts and 4 in mainline
<xdarklight>
it's because the Android kernel mostly relies on u-boot setting up Ethernet ;)
<xdarklight>
can you pastebin /sys/kernel/debug/clk/clk_summary so I can look into it tomorrow?
<hexdump0815>
would it help to restore android and get the clk-summary from there?
<asdf28>
yes! that did the trick. setting enable-gpios did enable the bluetooth, it's working now
<asdf28>
thanks a lot xdarklight, i would never have figured this out
<xdarklight>
asdf28: awesome, that's great to hear :-) - I assume this is with the mainline driver?
<asdf28>
yes i used the mainline driver with the android firmware
<asdf28>
but i'll try the firmware that comes with the kernel
<xdarklight>
hexdump0815: uuuh, it's selecting MPLL2 as clock parent and instead of FCLK_DIV2. that's weird and needs to be investigated further as to why that is
GNUtoo has joined #linux-amlogic
<hexdump0815>
xdarklight: ok - tomorrow or another day then ... would restoring android help or not so much?
<xdarklight>
hexdump0815: I don't think so. we need to find out why mainline is selecting the "wrong" parent
<hexdump0815>
xdarklight: are you sure - to me it looks its fclk_div2 in both cases
<hexdump0815>
xdarklight: ah - now i see - further up you mean
<xdarklight>
yep, starting at ff3f0000.ethernet#rgmii_tx_en is the important part
<hexdump0815>
where is this clock relation defined?
<xdarklight>
ðmac - clock-names "clkin0" and "clkin1". then the common clock framework is supposed to pick the "right" one automatically based on the target rate 125MHz
<hexdump0815>
let me upgrade to the latest 5.9 or 5.10-rc at least before we investigate deeper - not that we are hunting old bugs in the end ...
<xdarklight>
my output is from 5.9.11, just FYI
<xdarklight>
(you can see that I'm getting old as I'm running a stable kernel version, not linux-next, not even -rcX ...)
<hexdump0815>
:) ... same here - then maybe let me go to 5.9.11 as this seems to work well for you
<xdarklight>
mpll2 is running with the same rate as on your board: 294909637Hz, with fclk_div2 the result would be less than 2Hz off so I don't see any reason why CCF (common clock framework) would prefer MPLL2 over FCLK_DIV2
buzzmarshall has joined #linux-amlogic
hexdump0815 has quit [Remote host closed the connection]