04:54 <wens> tokyovigilante: IIRC it was a switch or something you had in the audio path? if it's just jack detection then IIRC the hardware has support for it, but no one implemented support for it

04:56 <tokyovigilante> there is a GPIO switch for the jack detection, then there is a speaker amp which has a separate enable/disable GPIO tied to a regulator. the mux chip is passive I think and just attached to the line out.

04:56 <tokyovigilante> so hopefully it should be enough to just power/depower the amp based on the headphone jack state.

05:22 <MoeIcenowy> MasterR3C0RD: BTW I got a Trimui Smart Pro (which is said to use Allwinner A133p)

07:14 <MasterR3C0RD> MoeIcenowy: Same thing I bought recently! Though I messed up while I was soldering UART (inexperienced, small pads, not-so-great iron + solder + bench) and tore off the UART TX pad by accident...

07:14 <MasterR3C0RD> Luckily though I still have RX so I can at least use that for getting debug output

07:15 <MasterR3C0RD> Main issue that's blocked me though is the PMIC used for the CPU supply; I haven't been able to find a complete driver or any datasheet for it

07:15 <Jookia> MasterR3C0RD: shouldn't there be enough in the BSP?

07:16 <MasterR3C0RD> Jookia: No BSP was released for this device, I had gotten it solely for the A133P

07:16 <MasterR3C0RD> And for the extra peripherals it'd allow me to take a look at

07:18 <MasterR3C0RD> It uses a Linux 4.9.113 kernel, but the BSP for the Sonic Pad (the most complete one I've been able to find thus far) doesn't even have a reference to the PMIC used (TCS4838)

07:19 <MasterR3C0RD> Amusingly, the top search result on Google now is the IRC log here when I mentioned it a few days ago

07:55 <Jookia> maybe it has default voltages at boot?

10:43 <warpme> apritzel: here is sunxi-fel sid-dump + android boot log: https://gist.github.com/warpme/878427298635f0c51a51582d54534ad6 indeed it looks like h728 is "very" a523. by this syterkit bl31 failure on h728 board really makes me sad....

10:45 <apritzel> warpme: ah, so you are not using Syterkit as a boot0 replacement?

10:46 <warpme> or mybe this syterkit bl31 issue is infact not real bl31 issue but result of missing my avaota a1 board adaptations to h728? (infact only change i done in avaota1 code is to get dram support)

10:46 <apritzel> because that's what I did: build Syterkit for the Avaota-A1 board, then use board/avaota-a1/extlinux_boot/extlinux_boot_bin_card.bin

10:47 <warpme> apritzel : well - i'm trying to use syterkit as bootloader following syterkit wiki

10:47 <apritzel> and you need the scp.bin as well, the vendor BL31 seems to depend on it. Syterkit loads both, but I guess this boot0 you use just loads bl31.bin?

10:47 <warpme> "use board/avaota-a1/extlinux_boot/extlinux_boot_bin_card.bin" - yes this is exactly what i'm doing

10:49 <apritzel> I will send you what I have tonight. I also made two new targets: one to directly load "u-boot-a523.bin" (alongside scp.bin and bl31.bin)

10:49 <apritzel> the other is a binary that does the DRAM init, then returns to FEL

10:52 <apritzel> warpme: ah, sorry, I see that log is the Android bootlog ...

10:56 <apritzel> warpme: ah yeah, it looks like there is some compatibility issue with the vendor BL31, as shipped with Syterkit, for the T527. Can you extract bl31.bin from the device or some update image?

10:59 <warpme> apritzel : for syterkit exlinux: building board/avaota-a1/extlinux_boot/extlinux_boot_bin_card.bin; adding bl31.bin/scp.bin/splash.bin + having /extlinux/extlinux.conf from minimyth2 on FATFS partition gives me: https://gist.github.com/warpme/bbecd383032140c31dc3cfdef5ffa95b

11:10 <warpme> for extracting bl31 from vendor: may you hint me how to do this? (alternatively i can share for download dump of first 16MB of eMMC to anybody playings)

11:11 <apritzel> warpme: is that failing to load some DTB? This "FATFS: read (null) addr=40400000" suggests that it doesn't even know the DT file name

11:14 <apritzel> seems like you need a "fdt" line in extlinux.conf?

11:14 <apritzel> and please note that the extlinux parsing code in Syterkit it quite buggy, I saw it failing with certain valid config files

11:18 <warpme> well - this log mesage is infact what i don't understand: my extlinux.conf is: https://gist.github.com/warpme/e07f6f8237c3bb3d0d81e8f6141b1d6e sunxi.dtb is present in root of FATFS. Maybe lack of initrd line confuses syster? let me try add it (albeit i dont use initrd)

11:22 <warpme> yeah: syter is really picky about content of extlinux.conf. with exlinix.conf file from systerkit repo i'm getting a bit better: https://gist.github.com/warpme/baaed4efcd3d28451daacfa4b121d680

11:23 <apritzel> warpme: you can use this tool to scan image files for DTBs, then extract one with "-e": https://gist.github.com/apritzel/0fe8efd8e57f6e0d5cc13695412e8ce6

11:24 <warpme> ah ok. cool. let me try~

11:25 <apritzel> warpme: the parsing routine is not good: it uses strstr to find the keywords, which gives you false positives (like "oldkernel" would match "kernel"), and it ignores comments

11:26 <apritzel> (I fixed that in my tree)

11:37 <warpme> i compared working syterkit bootlog and mine bootloag: https://gist.github.com/warpme/baaed4efcd3d28451daacfa4b121d680 (see L61 - it is last line from syter before kernel start to talk) In mine bootlog it looks like syter is telling all expected and there is nothing from kernel. maybe issue is in kernel earlycon? my bootline is: append earlycon=uart8250,mmio32,0x02500000 clk_ignore_unused console=ttyAS0,115200 root=/dev/mmcblk0p2

11:37 <warpme> rootwait debug

11:43 <apritzel> warpme: and you ran into a second Syterkit issue: it wants to patch the DTB, but this is buggy as well

11:43 <warpme> heh - it looks like time to switch to....yours syterkit?

11:51 <apritzel> warpme: try this file as the .bin file: https://paste.c-net.org/PunctureAwaken

11:51 <apritzel> that's some build I found here, so no promises

11:56 <warpme> oh yours bin is for lpddr4 while i'm on ddr3 so....0MB deteccted

11:56 <apritzel> ah right, it has the DRAM parameters hard coded ...

11:57 <apritzel> then you have to wait for tonight ...

12:00 <warpme> sure. np. thx!

15:53 <MoeIcenowy> MasterR3C0RD: I found https://bbs.aw-ol.com/topic/5012/lt527x-e-%E7%B1%B3%E5%B0%94-t527-%E5%BC%80%E5%8F%91%E6%9D%BF%E6%8A%98%E8%85%BE%E8%AE%B0%E5%BD%95 which says TCS4838

15:54 <MoeIcenowy> is this really a PMIC? I think what I saw is a single programmable DCDC ...

15:54 <MoeIcenowy> as said by https://www.eefocus.com/article/1723244.html

15:54 <MoeIcenowy> (WARNING: CHINESE

15:55 <MoeIcenowy> BTW usually you can try GitHub code searching

15:56 <MoeIcenowy> it may deliver some surprise

15:56 <MoeIcenowy> e.g. see https://github.com/search?q=tcs4838&type=code

15:57 <MoeIcenowy> okay the driver seems to say it's a dual channel DCDC chip

15:57 <MasterR3C0RD> MoeIcenowy: Not really sure about where the line is, but it appears to have at least 2 DC-DC converters (dcdc0, dcdc1) that can be polyphased

15:57 <MasterR3C0RD> Yeah okay

15:59 <MoeIcenowy> oops tcs4838 datasheet seems to be available nowhere

16:00 <MoeIcenowy> the eefocus page have its pin map

16:02 <parthiban> MoeIcenowy: tcs4838 datasheet is under NDA :-( I have access, but sorry!

16:02 <MasterR3C0RD> Gah

16:03 <MoeIcenowy> ah then is it just a dual-channel DCDC as we guessed?

16:04 <Jookia> parthiban: ping about replying to my email about the tcon :)

16:05 <parthiban> Jookia: sorry, swapped myself into mesa3d. Couldn't spent time with DE yet. Also my LVDS is connected over 2.0mm header, which I need some hardware patches to check LVDS1. Still in my basket.

16:05 <MoeIcenowy> https://github.com/YuzukiHD/TinyVision/blob/2dd84f3cb0d0bec2d6ab95408d4468471c5c60e6/kernel/linux-4.9/drivers/regulator/pmu-ext-regulator.c seems to be at least some code readable and possible for a driver implementation

16:06 <Jookia> parthiban: alright. the main issue is just aggreeing that DE0 = mixer0 in this case :)

16:12 <parthiban> Jookia: DE0 = DE0 Clock + RT Mixer0 + Write-Back + Rotate

16:12 <MasterR3C0RD> MoeIcenowy: Nice find! I'll take a look at that in the coming days then and see if I can get together a mainlinable driver; should give me enough to look at for A133/A133P OPP tables

16:12 <Jookia> parthiban: but DE1 is selected by mixer1 in the code

16:13 <parthiban> DE1 is not real yet.

16:13 <Jookia> ok, so the tcon top does nothing with DE1?

16:13 <Jookia> so we should remove that from the code?

16:16 <parthiban> DE_PORT_SELECT_REG plays a role for DE1. But there is no real existence of DE1 in upstream is what I meant

16:16 <Jookia> ok but upstream sets the port to DE1 if mixer1 is used

16:16 <Jookia> because the code says DE1 = mixer1

16:43 <parthiban> Jookia you are right, the whole idea of sun8i_tcon_top_de_config is wrong.

16:44 <Jookia> oh no

16:46 <parthiban> if there is 2 mixers for DE0 and when using mixer1 of DE0, this will enforce using tcon with DE1. So this won't work AFAIK

16:47 <Jookia> allwinner's code does the same thing

16:47 <Jookia> when ther's a separate DE is uses two tcon tops

16:48 <Jookia> so i'm fairly sure 'DE' means 'mixer'

20:45 <apritzel> warpme: can you try this branch: https://github.com/apritzel/SyterKit/commits/extlinux_fix/

20:46 <apritzel> also it came to me that the TV box probably only has one PMIC, not two like the Avaota (like the OrangePi 4A, apparently)

20:46 <apritzel> so the hardcoded PMIC setup would need to be adjusted