03:31 <MoeIcenowy> apritzel: some PLL divider?

06:08 <fraolt> My understanding is that there is no dependency between GPU frequency and screen update. But I have no experience with these things, so I could be completely wrong.

06:10 <fraolt> I'd assume that the video out uses the "latest" frame, right. If the GPU doesn't provide a new frame I'd assume it still uses the old one.

06:10 <fraolt> ¯\_(ツ)_/¯

06:15 <fraolt> And for the record: In the 240 MHz scenario, the OPP for the GPU are still 120, 312, 432. The PLL_GPU runs at 240 MHz and the GPU uses a divider of 2.

07:00 <fraolt> I'm starting to wonder if the Mali400 has a minimum frequency, could that be?

07:27 <MoeIcenowy> fraolt: it's possible that the PLL has a minimum frequency

07:27 <MoeIcenowy> although GPU having a minimum is also possible -- but maybe you can try to put it on a clock source that bypasses PLL?

07:28 <MoeIcenowy> oh sorry the GPU clock has no bypass option

07:28 <MoeIcenowy> unlike the CPU clock

07:29 <MoeIcenowy> but I think the CPU could work well when bypass PLL

07:29 <fraolt> PLL has a min freq of 192 MHZ (according to the manual). GPU is connected to PLL_GPU via a divisor.

07:30 <fraolt> I have no idea how to bypass PLL.

07:37 <fraolt> I'm currently sifting through lore. The rk312x.dtsi use a minimum frequency 200 MHz that are in the "downstream kernel": https://lore.kernel.org/all/20230829171647.187787-23-knaerzche@gmail.com/

08:40 <diego71> mps: 6.5.12 not working for me

08:40 <diego71> (mainline kernel compiled from git)

09:06 <diego71> maybe you kernel have some patch that fix it?

09:35 <mps> diego71: sorry, it is 6.5.10 not 6.5.12, https://arvanta.net/mps/aports-local/aarch64/linux-sunxi-6.5.10-r0.apk

09:36 <mps> and I have only patch to reorder mmc cards

09:39 <mps> diego71: linux-sunxi-6.5.10-r0.apk is alpine package and it could be untarred by 'tar' and there is config file inside

09:48 <fraolt> MoeIcenowy: Out of curiosity, how would you bypass PLL for the CPU? I've looked at the manual and couldn't find anything in the CPUCFG register.

10:41 <MoeIcenowy> fraolt: the CPU clock has selectable parent

10:41 <MoeIcenowy> well my assumption is wrong and PLL couldn't be bypassed for GPU

10:46 <fraolt> ok, thx

11:01 <apritzel> fraolt: so where does this mandatory(?) /2 divider come from? I cannot find that in the manual or Linux' clock driver.

11:01 <apritzel> Does Linux set the PLL to 240, to be over the minimum, then divide in the mod clock by 2, to get to the required 120 MHz?

11:25 <fraolt> Yes, GPU iterates over the divisors: GPU requests (through CCU) 120MHz (M=1) for PLL_GPU and PLL_GPU returns 192 (because I set a minimum of 192), then GPU requests 240 MHz (M=2) from PLL_GPU and PLL_GPU returns 240. Done!

11:25 <fraolt> s/CCU/CCF/

11:38 <gamiee> apritzel: ping

12:31 <apritzel> gamiee: see the topic ;-)

12:32 <gamiee> apritzel: sorry, I know the topic, just I wanted to know if you are there. :D Please, did you saw my question about the CLI format for sid-write ?

12:35 <apritzel> ah yeah, right. Don't know a good way either, requiring a file seems a bit over the top, if you just want to write a word, though it's more flexible - and would avoid accidental usage

12:36 <apritzel> otoh given the wrong or a too long file might mess up your SID properly

12:36 <KREYREN_oftc> This kernel won't produce a working wayland on alpine/pmos any idea why? https://dpaste.org/EHUhA/raw

12:37 <KREYREN_oftc> uses mesa 23.3.3-r0

12:38 <gamiee> apritzel : hmm, so the following syntax should be sufficient I think?: `sid-write offset value` . User can still chain sid-writes or use lib_fel directly. Also, it should be `sid-write` or `sid-writel` ?

13:04 <apritzel> gamiee: if we stick with this direct write interface, it should be sid-writel. But are all interesting values 32-bit aligned full words?

13:06 <apritzel> KREYREN_oftc: is there some Alpine/PMOS config you could use as a starting point? It's probably easier to use that and enable Allwinner drivers, because that covers all distro's needs

13:06 <KREYREN_oftc> apritzel, this is the custom kernel they use for allwinner

13:06 <KREYREN_oftc> that i added EFI support into

13:07 <KREYREN_oftc> the custom kernel config for the device i spoke about earilier is supposed to be separate from this

13:09 <apritzel> well, custom kernel configs lead exactly to those problems you experience, and there is no easy solution other than to debug that, sorry

13:10 <apritzel> if you have some kind of working config (for another version, or another board), you can try to bisect over the config

13:29 <f_> KREYREN_oftc: I doubt the kconfig would cause such issues TBH

13:30 <f_> the kconfig currently used in pmOS, that is.

13:30 <KREYREN_oftc> f_, seems to work on linux-edge on alpine

13:30 <KREYREN_oftc> oh maybe it's bcs of the pine64 patches

13:30 <f_> IIRC pp uses the same kernel

13:30 <f_> Well no, ppp uses the same kernel.

13:31 <f_> KREYREN_oftc: Well if everything works with linux-edge then use it \o/

13:33 <KREYREN_oftc> f_, i want more allwinner oriented kernel bcs linux-edge has working gnome and stuff but the device suffers performance-wise on a bloated kernel that just unloads a huge amount of modules on it

13:34 <f_> ok.

13:45 <apritzel> KREYREN_oftc: "suffers performance-wise on a bloated kernel"> are you sure about that? What does cause performance issues, exactly?

15:58 <gamiee> apritzel : yes, from what I saw in SID for H3, the smallest "field" have one 32b, the biggest have eight of them. The file can be mess, but it can be useful for writing keys (what should be that 8x 32b values). Eventually, we can add some prompt which user needs to confirm before writing the file, like: "14 bytes will be written to SID, offset 0x18, thus this range of SID will be burned <0x18, 0x26>. Do you want to continue?"

17:33 <apritzel> I guess we will discuss the details on github, just do a PR and I will have a look

18:48 <gamiee> alright :) will clean it up a bit and send a PR. Thanks !

18:49 <gnarface> gamiee: is pine64 irc down?

18:50 <gamiee> gnarface : yes => https://pine64.org/2024/01/21/outage_january_21/ . tl;dr cluster had major storage failure, so I am doing recovery now.

18:51 <gnarface> gamiee: ah, thanks for the info.

19:15 <alikates> Hello, I recently bought one of those cheap android projectors and it comes with an Allwinner H713 cpu. I managed to dump the firmware and from it looks like its a respin of the TV303. I want to add support for it in mainline linux, so I wonder if anyone else has any technical info about this CPU models

19:17 <alikates> Also, the board of this device has a USB host port for attaching drives with videos and stuff, could this be a dual-role port which I can use to access FEL mode? Maybe somebody has experience where turns out it is indeed a dual-role port

19:17 <gamiee> gnarface : no problem :)

19:19 <gamiee> hi alikates , can you share link to the projector?

19:24 <alikates> It's this one https://www.amazon.com/Projector-Magcubic-Keystone-Correction-Portable/dp/B0C84JLZ9K

19:26 <alikates> it has really strange specs, as it looks like a really underpowered cpu, but claims to have 4k decoding and wifi 6 xD

22:38 <karlp> wht's the projector quality like itselfthough?

23:23 <alikates> pretty bad, the lighting isn't uniform and gets quite hot. but for watching youtube in my bedroom its enough

23:30 <apritzel> alikates: I think so far every board that has USB had the USB0 port connected, allowing FEL access

23:30 <apritzel> you need one of those non-standard A-to-A cables

23:31 <apritzel> but it's actually quite common: TV boxes do this, and even the Pine64 board have it that way

23:32 <apritzel> can you put the projector into FEL mode? Does it have a button, or an SD card slot?

23:35 <alikates> It has a button which was hidden by the case and i suspect it's for FEL, but cannot verify unless i wire up the usb to a PC. Btw it has UART exposed in a couple pads so I could get to an android shell, that's how i dumped the fw

23:35 <alikates> The button seems to hang the boot process somehow, at least from what I see with the UART

23:36 <apritzel> that sounds like the FEL button, the BROM now patiently waits for a USB host to connect

23:37 <apritzel> and I don't think we have any manual for a this "sun50iw12, SoC ID 0x1860, TV303 or H713"

23:37 <alikates> I also got access to the uboot, but the config parameters are stored as a raw string in a partition called 'env'. And when i changed it to not auto-boot it dropped me to the uboot shell because it cannot recognize some commands

23:37 <alikates> ah, it has kernel 5.4

23:37 <apritzel> the vendor U-Boot is typically pretty useless

23:38 <alikates> the boot process seemed quite non standard though...

23:38 <apritzel> github code search produces some hits for sun50iw12, it looks like pinctrl and CCU drivers are among them, which would be the biggest issues, from the Linux side

23:39 <alikates> is it common in allwinner to use OP-TEE? I'm used to qualcomm which uses its closed source trustzone

23:39 <apritzel> their U-Boot is just enough to get Android booted, typically. And they lack the most useful commands

23:40 <apritzel> we haven't seen OPTee in the vendor stack yet, I think

23:40 <apritzel> though that's not really relevant, as we usually replace all vendor firmware parts anyway

23:41 <apritzel> what AW provides is just a waste of time, you can just use it to gain information about the system

23:41 <alikates> I have a DTB dump, looks reasonable but there's some enabled stuff that doesn't make sense and gives a really cheap vibes, like digital TV decoder

23:42 <apritzel> AW's DTB is pretty good to scare small children. The newer ones were better (A523), but still contain contradictory information at times

23:43 <apritzel> again you can sometimes extract information (which pins are used, where is the WiFi connected, which PMIC rail supplies which peripheral)

23:43 <apritzel> but that all needs to be double checked and verified

23:43 <alikates> So, all the "allwinner,whatever" nodes are for their non-public drivers?

23:44 <alikates> My main concern would be the display driver, but I have a feeling it's just standard DSI

23:44 <apritzel> depends. They use some mainline drivers. The latest code drop (for the A523) was pretty good in using upstream drivers, but I don't know how old your kernel drop is

23:45 <apritzel> 5.4 doesn't sound too good

23:46 <alikates> okay, I'll continue my research next week. Thank you!

23:46 <apritzel> basic functionality (UART, SD card, eMMC, USB) is probably quickly relatively achievable. WiFi depends on the WiFi chip

23:46 <alikates> Btw, where is the uboot tipically stored? I couldn't find it in the emmc

23:46 <apritzel> alikates: yes, please, collect as much information as possible, the truth lies often in the combination of all pieces

23:47 <alikates> do you usually chainload mainline uboot or just replace the existing one?

23:47 <apritzel> try to keep the vendor system alive, it's often very valuable to either harvest sysfs/debugfs, or dump registers from the booted system

23:47 <apritzel> we typically replace it quite quickly

23:48 <alikates> Okay

23:48 <alikates> ty!

23:48 <apritzel> the DRAM init code is the most nasty showstopper, but there are tricks to use at least that from the vendor, for the initial phase

23:49 <apritzel> new SoC enablement is quite some work, especially without a manual, so brace yourself and take your time, but we are here to help

23:57 <apritzel> Mali G31 and quad A53 with Android 13 suggests it's close to the H616, but it apparently has a different SoCID, which means it's not just a die variant, like the H700 or T507