08:17 <narmstrong> xdarklight: no prob take your time, I’ll need to spend some more time since there’s huge compatible mis usage in DT anyway (on arm64 especially)

10:45 <tolszak> narmstrong: How to force Odroid C2 micro USB to work in host mode?

10:46 <narmstrong> tolszak: good question, xdarklight should know that

10:46 <tolszak> narmstrong: It doesn't work whatever I plug in. I can try to make it work with both CONFIG_USB_OTG, will check if it works.

10:57 <tolszak> narmstrong: Also I see something like that when I plug in the camera: http://dpaste.com//9Z2J9SPMZ

11:02 <narmstrong> WoW pretty bad indeed

11:03 <xdarklight> tolszak: to enable USB host on the micro USB connector I think you "just" need to set &usb0_phy and &usb0 to status = "okay" in meson-gxbb-odroidc2.dts

11:04 <xdarklight> tolszak: it won't have any OTG support though, so it's either host (default) or device, depending on what's set in the .dts

11:04 <tolszak> xdarklight: "just" - lmao, how could I forget that :-)

11:04 <tolszak> xdarklight: Thank you very much. I will givve it a try

11:04 <xdarklight> tolszak: to be clear: th ehardware supports OTG but I haven't managed to make that work in the driver(s) yet

11:04 <tolszak> xdarklight: Fortunately host mode is what I need.

12:46 <tolszak> xdarklight: I've added patch to linux-yocto. Seems it is there. Do I need to add it also to u-boot?

12:46 <tolszak> Seems like the micro usb still doesn't work

12:48 <tolszak> narmstrong: I added CONFIG_GPIO_SYSFS=y but the /sys/class/gpio is not present, any idea how to access gpio?

12:49 <narmstrong> Using the libgpiod tools

12:52 <tolszak> narmstrong: So only new way is available, understood.

12:53 <narmstrong> The older way should work but honestly I haven’t used it for a while so maybe there’s a trick to enabled it

13:07 <tolszak> narmstrong: There is /sys/firmware/devicetree/base/serial-number but no /sys/bus/platform/devices/secure-monitor/serial

13:07 <narmstrong> tolszak: on which soc ?

13:08 <tolszak> narmstrong: Still playing with Odroid C2.

13:08 <narmstrong> tolszak: gxbb doesn’t have a serial number

13:09 <tolszak> I see so probably /sys/firmware/devicetree/base/serial-number is the same for all right?

13:09 <tolszak> narmstrong: Any idea how to check if device tree has been modified instead of looking at yocto sources? It looks alright there but still the micro usb doesn't work

13:11 <narmstrong> I think serial-number is added by u-boot

13:11 <narmstrong> tolszak: no easy way to check

13:12 <narmstrong> You can explore DT in sysfs or procfs and see if the changes are present

13:14 <tolszak> I decompiled fdt

13:18 <mkorpershoek> Could you have a look at: https://gitlab.baylibre.com/baylibre/amlogic/atv/u-boot/-/commit/c3f496fc3afac93fc1782e3a4d1fd097abf3a92a I will polish/send to the list if this looks ok.

13:18 <mkorpershoek> narmstrong: i've not found any generic USB role switch via DM_USB. However, i've found another trick to do the mode switching with DM_USB_GADGET=y

13:18 <mkorpershoek> Besides testing fastboot, UMS and reading a flash drive from U-boot, anything else you want me to test for this ?

13:20 <tolszak> narmstrong: xdarklight: That's my decompile /sys/frimware/fdt http://dpaste.com//GCGQAZQPR no idea if usb0 is enabled or now. All devices related to usb have status "okay"

13:25 <narmstrong> mkorpershoek: this is a nice trick !

13:47 <tolszak> xdarklight: Disclaimer - I never configured device tree in past. But seems like in meson-gxbb.dtsi meson-gxl-usb2-phy is set as compatible but I don't see usb2_phy defind anywhere like on other models. Moreover usb0 and usb1 has phy-names = "usb2-phy". Is it ok?

13:55 <xdarklight> tolszak: can you please pastebin your kernel log? I have to head to my next meeting in a few minutes, but I'll get back to you later tonight

13:55 <xdarklight> tolszak: also now that I think about it again: we probably have to pull a GPIO HIGH/LOW to enable VBUS

13:58 <narmstrong> wait I think the C2 has a jumper to select the power source, no ?

13:59 <narmstrong> tolszak: yes both phys and usb controllers are enabled

13:59 <narmstrong> mkorpershoek: could you clean the serie so I can test if the same works on GX ?

14:00 <tolszak> narmstrong: There is J1 I need to check what it is. The jumper is not applied

14:01 <mkorpershoek> narmstrong: I'm on it. will clean and send to the mailing list.

14:01 <narmstrong> mkorpershoek: great !

14:01 <tolszak> narmstrong: It would be need to applied if micro usb act in device mode. docs: "Remove the Jumper on J1 if you don't use the USB OTG port as a power input"

14:01 <tolszak> xdarklight: Will send log soon.

14:05 <tolszak> xdarklight: That's dmesg just after boot http://dpaste.com//2ZHXJGP9J

14:06 <xdarklight> tolszak: great, your .dts changes are correct as it has identified both USB controllers. I think it's indeed the VBUS GPIO that's missing/in the incorrect state

14:07 <xdarklight> tolszak: I'll get back to you on this later - if you find a solution in the meantime then please ping me here again

14:07 <tolszak> xdarklight: Can I do it in dts? I mean enable vbus?

15:27 <tolszak> xdarklight: meson-gxbb-p20x.dtsi looks similar to odroidc2, it doesn't set phy-supply on &usb1_phy. I removed phy-supply = <&usb_otg_pwr>; and seems working. Is it a coincidence or correct solution?

15:48 <narmstrong> tolszak: it's probably a correct solution, USB is a mess on odroid-c2 anyway

15:50 <mkorpershoek> narmstrong: i've send the series. hope I covered enough with it

15:50 <tolszak> narmstrong: TY

15:57 <narmstrong> mkorpershoek: thanks I’ll review and test it on my side

15:58 <mkorpershoek> please be extra cautious. I'm fairly novice on USB related things

16:49 <tolszak> xdarklight: Hello, seems like micro usb doesnt' start when nothing is plugged in during boot. When I plug in something I see: VCC3V3: disabling

16:51 <tolszak> xdarklight: The case to use microusb hub was to have separate power and be able to run 2 webcams 720p 60fps. seems like Micro USB and regular usb hub shares the same power source? Do you know if there is separate power source and have micro usb as separate hub?

17:22 <xdarklight> tolszak: I need to check the schematics again. but it's a known issue (that I forgot to mention) that USB hotplug does not work on Odroid-C1/C2. the hotplug issue is also present for the USB host ports, but I see that you have something plugged in at boot so you probably haven't hit that case before yet

17:25 <xdarklight> tolszak: looking at https://dn.odroid.com/S905/Schematic/odroid-c2_rev0.2_20171114.pdf again - the USB part is confusing. I *believe* (but have no proof) that there's two separate PWREN signals for USB: 1) is for the USB host ports and derived from VCC3V3 2) is for the micro USB port and is managed by GPIOAO_5. based on *my* understanding dropping &usb_otg_pwr from &usb1_phy makes sense

18:04 <tolszak> xdarklight: Is it all that is needed? So now usb1 is regular host hub powered by VCC3v3 and usb 0 is powered by otg power

18:04 <tolszak> in dts it is signaled by: "GPIOAO_5 GPIO_ACTIVE_HIGH"

18:06 <xdarklight> tolszak: hard to say for sure, I don't have an Odroid-C2 myself so I can just go with what I see in the schematics and what others find during testing

18:06 <tolszak> narmstrong: Seems like you are right though.

18:07 <tolszak> xdarklight: ^

18:09 <xdarklight> tolszak: can you please also pastebin the output of "cat /sys/kernel/debug/gpio"? (just for me to verify that everything matches my expectations)

18:10 <tolszak> xdarklight: http://dpaste.com//8TQCKDY73

18:11 <tolszak> xdarklight: I might have replug micro usb since last reboot

18:11 <tolszak> I'm not sure if it makes a difference

18:11 <tolszak> xdarklight: Also reboot doesn't work on odroid c2

18:12 <xdarklight> tolszak: weird: "gpio-502 (USB OTG Power En |regulator-usb-pwrs ) out lo" - I expected this to be "out hi"

18:13 <xdarklight> tolszak: hmm, not sure what the issue with reboot is, can't remember anyone else reporting this

18:14 <tolszak> xdarklight: Sorry for that, it is irrelevant for now.

18:20 <tolszak> xdarklight: What about vin-supply = <&p5v0>; in usb_otg_pwr perhaps I don't understand schematics

18:21 <tolszak> xdarklight: Isn't it only used on USB_B hub?

18:31 <tolszak> xdarklight: gpio-502 (USB OTG Power En |regulator-usb-pwrs ) out hi

18:31 <tolszak> xdarklight: Only when booted with device plugged in

19:01 <tolszak> narmstrong: Dooh there is no crpufreq in Odroid C2 in /sys/devices/system/cpu

19:01 <narmstrong> xdarklight: this is not normal

19:01 <narmstrong> xdarklight: oops wrong person

19:01 <narmstrong> tolszak: this is normal

19:02 <tolszak> narmstrong: no scaling governors?

19:03 <narmstrong> tolszak: the scpi must have failed to probe

19:05 <tolszak> narmstrong:

19:05 <tolszak> &scpi_clocks {

19:05 <tolszak> >---status = "disabled";

19:05 <tolszak> };

19:06 <tolszak> in meson-gxbb-odroidc2.dts

19:07 <tolszak> narmstrong: You disabled it in 2017

19:07 <tolszak> f7bcd4b6f6983d668b057dc166799716690423a4

19:09 <narmstrong> :-/

19:09 <narmstrong> I don’t remember but the reason must have been solid

19:10 <tolszak> narmstrong: http://dpaste.com//FHDY77QLQ

19:12 <narmstrong> Yep it’s a problem when opp tables are in firmware and there’s no way to add limits of filter out some opps

19:13 <tolszak> narmstrong: If the hw is tested to work with max_freq "1752" and the software I use. Is it a way to set it in yocto?

19:13 <narmstrong> Anyway the cpu are at maximum freq at boot so you won’t gain anything with dvfs

19:13 <tolszak> I mean I think I need to that get fluent 60fps

19:14 <tolszak> And the bits in: https://wiki.odroid.com/odroid-c2/application_note/software/set_cpu_freq are met

19:14 <tolszak> actually only 2 cores are loaded like 60-70% all the time.

19:14 <tolszak> Or perhaps less I don't remember

19:34 <tolszak> narmstrong: Does it mean I can't go higher that 1536?

19:35 <narmstrong> tolszak: you could re-enable scpi, use user space cpufreq governor and set 1752

19:37 <tolszak> narmstrong: Yeah I reverted your patch, but I think I need to enable CONFIG_CPU_FREQ cause still it is not in sysfs

19:39 <tolszak> narmstrong: forget about it, I forgot to copy patch to yocto layer. Working too long today

20:11 <xdarklight> tolszak: RE vin-supply = <&p5v0>; in &usb_otg_pwr - this means: "the P5V0 (main 5V power input) provides the input voltage for the USB_OTG_PWR regulator [which is controlled by GPIOAO_5]". the power for the USB hub is P5V0 directly, without an additional regulator (controlled by a GPIO) in between

20:12 <tolszak> xdarklight: Seems like it works stable as long as something is connected to microsd before boot and not disconnected afterwards

20:12 <xdarklight> tolszak: s/microsd/micro USB/ ?

20:12 <tolszak> yes, thanks, late a bit for me :)

20:12 <xdarklight> no worries :)

20:13 <tolszak> xdarklight: I suppose Neil is away already, maybe you know how to expose cpufreq?

20:13 <xdarklight> tolszak: still strange that the GPIO is toggling from "out lo" to "out hi" depending on whether something's connected to the hub

20:14 <xdarklight> tolszak: set &scpi_clocks to status = "okay", then boot Linux, hope that it doesn't crash (due to SCPI firmware with "too high frequencies") and then check "cat /sys/bus/cpu/devices/cpu0/cpufreq/scaling_max_freq"

20:16 <xdarklight> if scaling_max_freq returns 1.54GHz then everything is fine, if it returns a higher number then your system may be unstable. they did some weird thing with the SCPI firmware (responsible for managing the CPU clocks on the GXBB/GXL/GXM SoCs) where they allow up to 2GHz. the problem with that approach: 2GHz are only valid if only one core is enabled, but they're still exposing the 2GHz frequency point even if all four cores are enabled...

20:16 <tolszak> cpu0 has onlye this: cache/ cpu_capacity hotplug/ of_node/ online power/ regs/ subsystem/ topology/ uevent

20:16 <xdarklight> most likely because &scpi_clocks is still disabled

20:18 <tolszak> xdarklight: work-shared/hardkernel-odroidc2/kernel-source/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts has spi_clocks status = "okay"

20:18 <tolszak> I will decomplie fdt

20:20 <tolszak> xdarklight: seems like it is enabled https://dpaste.com//4MK9VM4QR

20:21 <xdarklight> tolszak: hmm, do you have CONFIG_ARM_SCPI_CPUFREQ=y and CONFIG_COMMON_CLK_SCPI=y in your kernel .config?

20:22 <tolszak> xdarklight: yes

20:26 <xdarklight> tolszak: can you please pastebin the output of "cat /sys/kernel/debug/clk/clk_summary"?

20:26 <tolszak> xdarklight: http://dpaste.com//G4F8Z3ZKS

20:28 <xdarklight> tolszak: weird, the "vcpu" (SCPI) clock is missing

20:28 <tolszak> xdarklight: But you see it is okay in decompiled fdt

20:29 <xdarklight> tolszak: yep, typically it's either the OF node being disabled or the driver not compiled (in). but you seem to have both

20:33 <tolszak> xdarklight: I have everything enabled in Clock support for Almogic platforms

20:34 <xdarklight> tolszak: that's good. please note that CONFIG_COMMON_CLK_SCPI is outside of the Amlogic menu. let me check something

20:34 <tolszak> xdarklight: Yes, I know, it is enabled too

20:35 <tolszak> xdarklight: Be back in 5 minutes

20:37 <xdarklight> tolszak: reference boot log from GXL (similar enough to GXBB): https://storage.kernelci.org/mainline/master/v6.1-rc6/arm64/defconfig/gcc-10/lab-clabbe/baseline-meson-gxl-s905x-libretech-cc.html

20:37 <xdarklight> tolszak: I'm missing the following line in your log: "scpi_protocol scpi: SCP Protocol legacy pre-1.0 firmware"

20:38 <xdarklight> tolszak: hmm, but I'm looking at http://dpaste.com//8TQCKDY73 which is probably before you enabled &scpi_clocks

20:38 <tolszak> xdarklight: where should it be? in dmesg?

20:39 <xdarklight> tolszak: yep, in dmesg

20:41 <tolszak> xdarklight: http://dpaste.com//BUYBNZEZT

20:41 <tolszak> That's clean boot

20:42 <tolszak> CONFIG_ARM_SCPI_PROTOCOL=y

20:42 <tolszak> CONFIG_ARM_SCPI_POWER_DOMAIN=y

20:42 <tolszak> In config

20:43 <tolszak> xdarklight: Instead of reverting this patch: f7bcd4b6f6983d668b057dc166799716690423a4 I just set scpi_clocks ststus to okay

20:44 <tolszak> in meson-gxbb-odroidc2.dts

20:44 <xdarklight> tolszak: that approach is fine

20:45 <xdarklight> tolszak: do you have CONFIG_PLATFORM_MHU=y ?

20:46 <tolszak> xdarklight: nope

20:47 <tolszak> xdarklight: Onlye CONFIG_ARM_MHU=y

20:47 <xdarklight> tolszak: please enable it and try again. it's the mailbox driver that SCPI uses for communication

20:54 <tolszak> xdarklight: I;m sorry it will take a few minutes more. I;m rebuilding whole image again.

21:03 <tolszak> xdarklight: scpi_protocol scpi: SCP Protocol legacy pre-1.0 firmware and cpufreq is there

21:03 <tolszak> xdarklight: Many many thanks!

21:04 <tolszak> perhaps it should be added to default config

21:04 <xdarklight> tolszak: great! :-) it's already part of arch/arm64/configs/defconfig

21:04 <tolszak> xdarklight: So why I don't have it?

21:04 <tolszak> I use meta meson kirstone

21:05 <xdarklight> tolszak: maybe it's missing somewhere in the yocto configs? I'm not familiar with yocto though, so I don't have any starting point for you :/

21:06 <tolszak> xdarklight: Now I need to insert 1752 into scalin_availabel_frequencies

21:06 <xdarklight> tolszak: so you want to overclock?

21:07 <tolszak> xdarklight: previously the device was working ok with 1752

21:07 <tolszak> for many years

21:07 <tolszak> the stability requirements from https://wiki.odroid.com/odroid-c2/application_note/software/set_cpu_freq are met

21:07 <xdarklight> tolszak: ah, I've never done this on GXBB/GXL/GXM before. with newer SoCs it's easy as the frequency table is part of the .dtb. I thought that there's a toggle in the vendor u-boot, but I'm not sure

21:11 <xdarklight> tolszak: ah, in that odroid wiki link: setenv max_freq "1752" # 1.752GHz

21:11 <xdarklight> tolszak: do you have vendor u-boot or mainline u-boot?

21:11 <tolszak> xdarklight: Yes but it is for vendor u-boot

21:11 <tolszak> I use meta-meson uboot which is stock one I think

21:13 <xdarklight> tolszak: ah, I never looked into how that max_freq setting is passed to the SCP firmware in vendor u-boot. but I'm sure this setting is not available in upstream u-boot yet

21:13 <xdarklight> tolszak: Linux just communicates with the SCP which presents all values it "knows" (or which are unlocked). so the question is: how to get this value into the SCP firmware

21:14 <tolszak> xdarklight: :-(

21:20 <tolszak> xdarklight: There is an option to boot using vendor u-boot

21:20 <tolszak> I will give it a try