00:15 <vicencb> mmind0: just tested: i have observed two things

00:15 <vicencb> mmind0: the kernel provided by archlinuxarm has random behaviour, sometimes the issue is reproduced at boot, sometimes is not reproduced.

00:15 <vicencb> mmind0: the kernel i compiled with the debug option does not reproduce the issue, although the configuration is very different.

00:15 <vicencb> mmind0: later this week will test with another kernel with debugging on and with a more similar configuration.

11:14 <jackmitchell> does anyone know if it's possible to boot a ramdisk from the rockchip bootrom using mainline tools? I had a workflow with sunxi processors where it went bootrom -> uboot spl -> uboot proper -> linux and ramdisk which had been pre-loaded into memory via bootrom

11:15 <jackmitchell> I have been experimenting with the rkdevelop/rkflash tools but so far have only managed to get to the point where I can load the spl, but it then drops back to maskrom immediately where I suspect it then tries to load uboot proper from a storage device?

11:22 <hanetzer> jackmitchell: unsure if it can be done with tools available now, but I believe it is possible

11:25 <jackmitchell> hanetzer: ok, I had come to that conclusion but thought I would double check I wasn't missing anything, I guess the next best option is probably a minimal emmc image to flash to the board which brings up uboot proper and then starts dfu to allow flashing

11:26 <jackmitchell> one last question though, on my rk3288 firefly board, I have wiped the emmc from rkflashtool in maskrom mode, however when I reset the board I still get a full build of uboot starting, is this coming from the emmc and erasing the flash from 0x0 hasn't actually wiped the flash; or is it embedded somewhere else

11:27 <jackmitchell> I understand from rockusb you can only access the emmc from an offset of 0x2000, however I thought from maskrom you could access the full emmc from 0x0

11:30 <hanetzer> unsure. does there exist spi flash? is this booted with some sdcard in it which may contain u-boot code?

11:39 <jackmitchell> no spi flash as far as I'm aware and without sd card, I have suspicions that the erase emmc isn't fully working or not behaving how I understand it to; I'll keep going and see if I can get to the bottom of it, thanks for you help!

13:21 <DuClare> mmind00: Hmh, is there a simple way to enable clocks?

13:21 <DuClare> Like, statically

13:22 <mmind00> DuClare: not from the commandline ... if in doubt just disable the disabling in drivers/clk/clk-gate.c ;-)

13:25 <DuClare> Yea.. simply frobbing the grfs didn't do much for me, so I'm fumbling on to the next thing

13:26 <DuClare> debugfs tells me none of the hsic related clocks are enabled

13:30 <mmind00> DuClare: at least HCLK_HSIC should've gotten enabled through the ehci driver though

13:30 <DuClare> Oh right

13:30 <DuClare> That one is

13:31 <mmind00> DuClare: but yeah, the phy related clocks probably never get enabled due to the missing phy driver

13:34 <DuClare> What's the purpose of registering a clock in the phy driver anyway? Is it just so the usb driver can then toggle it off to save power?

13:51 <mmind00> DuClare: yep ... the phy itself is a separate hardware block, "just" connected to the actual usb controller

13:52 <mmind00> DuClare: the phy driver in the Rockchip case handles clocks + GRF settings (there is also some part of power-control in there)

13:53 <mmind00> DuClare: and that is stuff you really don't want hacked into a _generic_ usb driver that can be used by a lot of different socs

13:54 <mmind00> (even on rockchip socs we have the same phy connected to both dwc2 + ehci-generic at least)

13:54 <mmind00> not even thinking about the usbphy also containing its own PLL which even gets fed back to the core clock controller