00:24 <tokyovigilante> macromorgan: is that on the -H? I've found only one of ports can supply power with battery out, but on the -Plus, presumably it is wired for both power and OTG use

00:24 <tokyovigilante> Ok, have been successful (partially) with the v4 cpufreq patches on the H700, but only up to 1.4GHz. The 1.5GHz speedbin works very briefly but is extremely unstable, I managed to get most of the way through boot by pushing DCDC1 up to 1.24v but didn't want to go higher (and the BSP seems ok at 1.16v), and the 1.032GHz bin causes an immediate panic (it is selected by default by the governor at

00:24 <tokyovigilante> boot, oddly even though a 1.008GHz bin is defined and this seems to be the default frequency)

00:24 <tokyovigilante> [ 1.565460] cpufreq: cpufreq_online: CPU0: Running at unlisted initial frequency: 1008000 KHz, changing to: 1104000 KHz

00:24 <tokyovigilante> $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies

00:24 <tokyovigilante> 480000 720000 1104000 1200000 1416000

00:24 <tokyovigilante> May need to investigate opp-supported-hw

00:25 <macromorgan> the H I have USB working on one port as a host and the other port as a device

00:25 <macromorgan> plus wifi and bluetooth working fine now

00:25 <tokyovigilante> Nice, did you need to do anything else for BT?

00:25 <macromorgan> so I'm slowly building up progress... I'm starting to poke at registers on the PMIC to see what else the device is capable of and get hardware ready. I think worst case I can get the power button next which should be trivial

00:26 <macromorgan> cleanly define the regulators properly

00:26 <macromorgan> and set a mmc-pwrseq-simple

00:27 <tokyovigilante> Sounds good, to be fair BT seems much more stable since apritzel's second AXP patchset with regulators

00:28 <tokyovigilante> I'll start looking at sound and the LCD, as well as potentially start a formal patchset for the DT now that the AXP717 is defined

00:28 <macromorgan> I haven't figured out all the specifics yet but so far I know that the WiFi is powered by reg_cldo4

00:29 <macromorgan> also USB has either some enable pins or regulators, I haven't figured it out cleanly just yet though which it is. pin PI7 turns on the power to the USB host port, and pin PE5 seems to power on the USB logic

00:30 <macromorgan> though the device mode port seems to work without these

00:31 <macromorgan> also the second SD card has a regulator on PE4... if you don't enable that regulator the second SD card doesn't work

00:32 <tokyovigilante> good finds!

00:33 <macromorgan> yeah... schematics would have made this go much faster...

00:35 <tokyovigilante> ikr, have you asked Anbernic at all?

00:41 <tokyovigilante> Have just tried the 512-sector boot offset, which seems to work:

00:41 <tokyovigilante> Trying to boot from MMC1

00:41 <tokyovigilante> mmc_load_image_raw_sector: mmc block read error

00:41 <tokyovigilante> SPL: failed to boot from all boot devices

00:41 <tokyovigilante> ### ERROR ### Please RESET the board ###

00:41 <tokyovigilante> Assume I then need to feed it an initramfs somehow

00:46 <macromorgan> no, Anbernic doesn't hand out schematics. I've repeatedly told them I'm fine with an NDA (for hardware, I refuse to NDA the software bits). So everything I do I have to do the very hard way.

00:53 <macromorgan> also I found the LEDs, but I need to get the backlight defined clearly before I decide how to define the LEDs on the device tree. Turns out both pins used for LEDs can be PWMs too, but I think one of them might conflict with the backlight

00:53 <macromorgan> the PMIC has a cool "breathe" function too for its LED (the orange one)

00:54 <macromorgan> but it has to be enabled by fiddling some bits

00:56 <tokyovigilante> the important stuff ;)

00:56 <tokyovigilante> awesome about the backlight LEDS though

00:59 <tokyovigilante> Do you still need my kernel tree?

03:45 <Jookia> jernej: ok, video output is working on the t113 :) i'll try and do an RFC this week

07:19 <blathijs> linkmauve: That might be tricky - I think armbian might be using a vendor kernel, or at least have a bunch of patches applied to the kernel which might interfere with easy bisecting. I might try to see if clean mainline works well enough to boot and test for this problem, or my alternative plan was looking through the git commits for the v4l2 h264 driver to see if there's

07:19 <blathijs> anything that looks like it might be related and then revert that to see if that helps

20:02 <jernej> Jookia: nice, looking forward to patches

21:11 <Jookia> i'm not sure how to break it up so i might just dump it as a single patch for now

21:12 <Jookia> it's a surprisingly small patch

21:12 <Jookia> but it's kind of ugly too :)