14:23 <xdarklight> hexdump0815: for the Ethernet and USB errors: it seems that the GP0_PLL does not lock on your board. it's related to this message: "Failed to enable clk 'vpu': -5", -5 == -EIO and we only return that from the PLL driver

14:24 <xdarklight> hexdump0815: I need to double check on my board but I believe it was working last time I tested it there

14:24 <xdarklight> hexdump0815: (USB and Ethernet are then "just" fallout from this because their power domain is missing)

14:27 <xdarklight> hexdump0815: RE memory timings on M8S: my M8S is special because it doesn't seem to have *any* configurable CPU voltage regulator (neither a PMU nor PWM regulator). memory timings are set by u-boot (IIRC even before the ARM CPU is started). check if your M8S has a voltage regulator somewhere, if it does then the memory errors are probably because we're running a CPU freq which is too high for the voltage set by u-boot (which can cause

14:27 <xdarklight> memory errors as well)

16:02 <hexdump0815> xdarklight: here is the android dtb of my m8s - https://pastebin.com/raw/AyCGht3W ... there is some voltage table (looks like pwm based) in it and on android it is freq scaling from 96 to 1608 mhz

16:04 <hexdump0815> xdarklight: can it be that it works similar to this rockchip box: https://github.com/hexdump0815/linux-mainline-and-mali-rockchip-rk33xx-kernel/blob/master/misc.rkc/dtb/rk3328-t9.dts#L400-L409 ?

16:04 <xdarklight> hexdump0815: on Android mine stays fixed at 1.2GHz and the Android .dtb has a DVFS table but it doesn't specify to use a PMU (not present) nor a PWM

16:05 <hexdump0815> xdarklight: the consistency of chinese tv boxes :)

16:05 <xdarklight> hexdump0815: so yes, I think your M8S works similar to that Rockchip one or your MXQ (which also uses a PWM based CPU voltage regulator)

16:06 <hexdump0815> xdarklight: how do i find out which pwm is the proper one and how to configure it in the dtb?

16:06 <xdarklight> hexdump0815: your Android .dtb has: pmw_controller = "PWM_C"; inside meson_vcck_dvfs_driver

16:08 <xdarklight> hexdump0815: compare a couple of values from the cs_voltage_table with the one from MXQ's Android .dtb. They're probably similar / identical so you can copy from MXQ's .dts :)

16:10 <xdarklight> hexdump0815: also when PWM_C is VCCK (CPU voltage regulator) then I suspect that PWM_D is VDDEE ("everything else" regulator which powers the GPU and other parts)

16:16 <hexdump0815> xdarklight: that looks promising - the meson_vcck_dvfs_driver looks very similar to the mxq one indeed ... so i should take the vcck and vddee sections of the mxq dtb, maybe adjust the voltage ranges and put it into the m8s dtb?

16:16 <xdarklight> hexdump0815: yep, I'd give that a try and see if it fixes your problem

16:17 <hexdump0815> xdarklight: sounds like a plan - iany idea how to fix the GP0_PLL lock problem on the mxiii?

16:20 <xdarklight> hexdump0815: not sure about that one yet. can you please pastebin the output of: cat /sys/kernel/debug/regmap/dummy-system-controller\@4000/registers

16:20 <xdarklight> hexdump0815: then I can compare with my own boards

16:35 <hexdump0815> xdarklight: box is booting ... :)

16:39 <hexdump0815> xdarklight: here it is - https://pastebin.com/raw/zgTHUuib

16:51 <xdarklight> hexdump0815: can you please apply https://pastebin.com/4AuphQ4H and let me know if VPU then initializes for you?

16:52 <xdarklight> hexdump0815: (it seems that this is done conditionally in u-boot's early init phase: https://github.com/endlessm/u-boot-meson/blob/f1ee03e3f7547d03e1478cc1fc967a9e5a121d92/arch/arm/cpu/aml_meson/m8/firmware/pll.c#L190 - it seems that your bootloader doesn't do this init)

18:03 <hexdump0815> xdarklight: tried your patch - it seems to fix that error, but not the eth and usb problems - new dmesg and reg dump: https://pastebin.com/raw/KHecFYNt

18:05 <xdarklight> hexdump0815: hmm, so you still don't get any Ethernet interrupt in /proc/interrupts ?

18:06 <hexdump0815> xdarklight: i did not check that but ethernet was still not working ... booting the m8s right now to check the pwm change there ...

18:09 <xdarklight> hexdump0815: HUH, wait: soc soc0: Amlogic Meson8 (S802) RevC (19 - 0:27ED) detected

18:09 <xdarklight> hexdump0815: that means your board.dts should include meson8.dtsi instead of meson8m2.dtsi

18:09 <hexdump0815> xdarklight: maybe one side note regarding the mxiii eth: what worked was that it logged link up/down when i connected/disconnected the eth cable

18:10 <hexdump0815> xdarklight: ah - ok, so looks like not only my m8s is different from yours but also my mxiii differs too :)

18:12 <xdarklight> hexdump0815: yeah, why should it be easy :D. you're the first person I know to have an actual Meson8 (non m2) SoC. expect Ethernet to still not work because Meson8 uses different Ethernet clocks. I can cook a patch at some point but be prepared for 100% untested code ;)

18:21 <hexdump0815> xdarlight: i'm prepared :) ... regarding the pwm i realized, that i'll have to bring over the pwm defintion most probably too from mxq (pwm-regulator regulator-vcck: Failed to get PWM: -517) ... in mxq it is amlogic,meson8b-pwm - looks like there is no amlogic,meson8m2-pwm - so should i use amlogic,meson8b-pwm or amlogic,meson8-pwm then?

18:24 <xdarklight> hexdump0815: pwm_cd is already in meson8.dtsi, so you don't need to specify a compatible string anymore. just follow what meson8b-mxq.dts does with pwm_cd

18:24 <hexdump0815> xdarklight: while we are at rare hardware - was there a g9bb too? - this looks a bit like it: https://github.com/endlessm/linux-meson/blob/master/arch/arm/boot/dts/amlogic/mesong9bb_m211.dtd

18:28 <xdarklight> hexdump0815: according to https://github.com/endlessm/linux-meson/tree/master/arch/arm there was a meson g9tv as well. I assume both are similar to Meson8m2 but with the HDMI 2.0 controller from the GX SoCs

18:28 <xdarklight> hexdump0815: (I have no proof that they're similar to Meson8m2 though, it's pure speculation)

18:30 <hexdump0815> xdarklight: looks like the uneven ones never see the light? meson7, g9bb, g11 ...

18:36 <hexdump0815> xdarklight: i now have this https://pastebin.com/raw/1eGJBPHN but now it complains about "arch/arm/boot/dts/meson.dtsi:81.21-86.6: ERROR (phandle_references): /soc/cbus@c1100000/pwm@8650: Reference to non-existent node or label "pwm_c1_pins"" - same for the _d_pins - both seem to be defined in the middle of meson8b.dtsi

18:38 <xdarklight> hexdump0815: copy the pwm_d_pins from meson8b.dtsi to meson8.dtsi. for pwm_c we need to have a closer look, because there are three options on Meson8: pwm_c_dv9, pwm_c_dv29 and pwm_c_z

18:39 <hexdump0815> xdarklight: this is what i had in mind too - will try

18:40 <xdarklight> hexdump0815: your android.dts shows aml_pwm_pins with phandle 0x14 which is also passed to the VCCK driver. that one has amlogic,pins = "GPIODV_9"; so I would add pwm_c_dv9_pins to meson8.dtsi (you can follow what meson8b.dtsi does with pwm_c1_pins)

18:41 <xdarklight> hexdump0815: once you have switched to meson8.dtsi, can you please also pastebin the contents of /sys/kernel/debug/meson-clk-msr/measure_summary and /sys/kernel/debug/clk/clk_summary ?

18:43 <hexdump0815> xdarklight: the latte rwould then be back in mxiii land - right? ... how do you keep yourself such a good overview in all this dts jungle? :)

18:44 <xdarklight> hexdump0815: ah, yes - that would be on the MXIII :-). I see all of this as a challenge and exercise for whatever weird problems I face at work (I code Java for food, and weird problems show up in large scale projects)

18:45 <hexdump0815> xdarklight: i must admit that i did not fully get that pwm_c_dv9_pins thing - i took over the c1_ and d_pins from 8b to 8 - anything else to move/change?

18:47 <xdarklight> hexdump0815: yes, one more change is needed: pwm_c1 only exists on Meson8b (but not on Meson8/Meson8m2). replace all pwm_c1 with pwm_c_dv9 instead (which exists on Meson8/Meson8m2 but not on Meson8b)

18:47 <xdarklight> hexdump0815: if you add pwm_c1 to the .dtsi it will compile fine but complain when booting with that .dtb that drivers/pinctrl/meson/pinctrl-meson8.c doesn't know about pwm_c1

18:48 <hexdump0815> xdarklight: ok - got iz

18:49 <hexdump0815> xdarklight: oh - the last typo tells that i'm using a german keyboard :)

18:49 <xdarklight> hexdump0815: ich auch ;-)

18:53 <hexdump0815> xdarklight: :) ... are you sure about the pwm_c_dv9_pins? i cannot find it anywhere ...

18:54 <xdarklight> hexdump0815: "grep pwm_c_dv9_pins drivers/pinctrl/meson/pinctrl-meson8.c" shows it for me. but so far it is not used in any .dtsi

18:54 <hexdump0815> xdarklight: ah - ok - i only searched the dts* files

18:56 <hexdump0815> xdarklight: hm - arch/arm/boot/dts/meson.dtsi:81.21-86.6: ERROR (phandle_references): /soc/cbus@c1100000/pwm@8650: Reference to non-existent node or label "pwm_c_dv9_pins"

18:56 <xdarklight> hexdump0815: can you please pastebin your "git diff"?

19:00 <hexdump0815> xdarklight: https://pastebin.com/raw/cqLGN7T1

19:01 <xdarklight> hexdump0815: in meson8.dtsi you need to add pwm_c_dv9_pins above pwm_d_pins. just duplicate the pwm_d_pins block and rename everything to from "d" to "c_dv9" in the copy

19:14 <hexdump0815> xdarklight: ok, i have working freq scaling now, but sadly the box is still unstable - dmesg and "7z b" run - https://pastebin.com/raw/6rMwWqex

19:19 <xdarklight> hexdump0815: I'll get dinner now and think about it afterwards

19:19 <hexdump0815> xdarklight: i think this is not due to cpu voltage - scaling has 816000 1008000 1200000 1416000 1608000 and even if i limit it to the lowest value i get those decoding errors

19:19 <hexdump0815> xdarklight: guten appetit :)

20:34 <hexdump0815> xdarklight: back to mxiii - now with meson8.dtsi included and surprise: ethernet is working now ... here is the dmesg and the dumps you asked for: https://pastebin.com/raw/8KG2qfAE

20:37 <hexdump0815> xdarklight: usb is still not working - i mentioned it yesterday already: the android dtb has "gpio-vbus-power = "GPIOZ_1";" for "usb_a" - might this be realted maybe?

20:38 <xdarklight> hexdump0815: nice to see Ethernet working :-). for USB: you can try to copy the usb_vbus node from meson8b-ec100.dts and adjust it to use GPIOZ_1. however, the error you get is in the PHY driver so I'm not sure if it will help

20:58 <xdarklight> hexdump0815: now that Ethernet is working, can you please run: grep "" /sys/class/mdio_bus/*/*/phy_id

21:00 <hexdump0815> xdarklight: sure - result will come in a minute ... meanwhile this is my current mxiii patch - the usb_vbus did not seem to help - i tried it both with the gpio at the vcc_5v and without it

21:00 <hexdump0815> xdarklight: https://pastebin.com/raw/dmuep66i

21:01 <xdarklight> hexdump0815: right, I'll look at my MMC driver patches first - then I can look at your PHY problem

21:01 <hexdump0815> xdarklight: sure there is no hurry - here is the result of your grep: 0x02430c54

21:06 <xdarklight> hexdump0815: thanks. I think I understand the RMII clock routing now (WIP patch, won't work yet I think: https://pastebin.com/mt5pYMPQ ). if you open the case (no need to do so) you'll find a 50MHz crystal oscillator next to the IP101A Ethernet PHY. that clock signal is routed to the PHY and to the SoC. The SoC then divides it by 1 and then again by 2 or 20 (100Mbit/s or 10Mbit/s) to generate the RMII clock signal it needs internally

21:08 <hexdump0815> xdarklight: would it help you if i try that patch?

21:09 <xdarklight> hexdump0815: not in it's current state, a couple more changes in dwmac-meson.c are needed

21:10 <hexdump0815> xdarklight: ok - just let me know whenever it is ready for testing - whenever that might be :)

22:36 <hexdump0815> xdarklight: just a stupid idea - could the memory problem maybe related to a wrong load address? what load addresses are you using for kernel, initrd and dtb for your m8s? does it have 2g of ram too?

22:38 <xdarklight> hexdump0815: not sure, my MXIII only has 1GB RAM. I use: DTB @ 0x11800000, initramfs @ 0x15000000, uImage @ 0x14000000

22:42 <xdarklight> hexdump0815: I'm preparing a fix for your USB issue now - I'm porting this check to the mainline driver: https://github.com/endlessm/linux-meson/blob/5cb4882cdda584878a29132aeb9a90497a121df9/arch/arm/mach-meson8/usbclock.c#L120

22:44 <hexdump0815> xdarklight: cool - thanks a lot ... regarding the memory i ment the m8s - mine has 2gb and what is strange is that if i boot with mem=1020M it runs stable ... testing mem=2000M now ... are there any strange memory regions which need to be excluded on 8m2 maybe?

22:44 <xdarklight> hexdump0815: hmm, I'm only aware of the ones which are already in meson8.dtsi (and thus inherited by meson8m2.dtsi)

22:50 <hexdump0815> xdarklight: weird - mem=2000M is unstable mem=1500M seems to be stable ... maybe the box just has some bad ram - will have to search for some stress test for android to verify ...

22:59 <hexdump0815> xdarklight: can it be that u-boot somehow reserves some space which the kernel does not take into account - in the android boot output (https://pastebin.com/raw/xzmv2PQt) the kernel seems to see only about 1.6g - i also saw that on gxl that legacy u-boot seems to "eat" about 250+M which the kernel does not even see - if chainloading mainline

22:59 <hexdump0815> u-boot the kernel sees much more memory then ... lets see what happens if i limit the mem to what android sees ...

23:02 <xdarklight> hexdump0815: hmm, let's go through it one-by-one

23:03 <xdarklight> hexdump0815: "physical memory start address is 0x200000" -> we have a reserved-memory entry from 0x0 to 0x200000, so that is covered

23:04 <xdarklight> hexdump0815: "Reserved low memory from 0x06000000 to 0x1c2fffff, size: 355 MiB" -> in my opinion none of these should be "reserved" as the mainline drivers are either non-existent or can choose arbitrary memory regions

23:05 <xdarklight> hexdump0815: "cma: CMA: reserved 8 MiB at 2f000000" and "cma: CMA: reserved 20 MiB at 2dc00000" - mainline reserves one 64 MiB area dynamically, so that one should not be needed either

23:06 <xdarklight> hexdump0815: so adding these up explains why ~400 MB are missing in Android, but I think none of them is critical (compared to 0x0 to 0x200000, I've seen hard lockups back when that was missing)

23:09 <xdarklight> hexdump0815: (that's my take at the problem until you prove me wrong ;-) )

23:14 <xdarklight> hexdump0815: RE USB issue: I just pushed a new branch. please let me know if USB host works for you with that (the OTG port will still not work). if it doesn't then also try with the VBUS GPIO

23:17 <hexdump0815> xdarklight: thanks a lot - will try most probably tomorrow - btw. would it maybe also help to use CONFIG_USB_DWC2_HOST instead of CONFIG_USB_DWC2_DUAL_ROLE then?

23:18 <xdarklight> hexdump0815: for the second USB port you mean?

23:19 <hexdump0815> xdarklight: to me it looked like the problem appeared in the otg code path and i was thinking if only config the host part would avoid that?

23:21 <xdarklight> hexdump0815: it's actually a limitation of the OTG capable PHY and the way it's integrated with dwc2. if we configured it in OTG or peripheral mode then the problem would go away, but OTG is definitely not working yet and peripheral mode would have to be tested by someone

23:28 <hexdump0815> xdarklight: ok - got it ... just got a kernel oops while trying "7z b" again with mem=1575M - https://pastebin.com/raw/mgYke5SG - does that look like bad memory or like a code problem? any idea?

23:31 <xdarklight> hexdump0815: hmm, try enabling CONFIG_SLUB_DEBUG=y and CONFIG_SLUB_DEBUG_ON=y. it should yield a different error if it's a code problem somewhere. I used these two to find an issue with the help of someone else a while ago: http://lists.infradead.org/pipermail/linux-amlogic/2019-March/010839.html

23:33 <hexdump0815> xdarklight: thanks - i'll add those options tomorrow - time to go to bed ...

23:34 <xdarklight> hexdump0815: yep, bedtime here as well. good night

23:36 <hexdump0815> xdarklight: good night