00:01 <alikates> I compared the register maps from the DTS with D1 and H616 ones and looks like it shares IPs with both

00:01 <alikates> As it's also implied by this patch https://lore.kernel.org/linux-arm-kernel/20230126063419.15971-2-samuel@sholland.org/

00:02 <alikates> assuming tv303 and h713 is the same

00:03 <alikates> but from what I've seen with these days of research, looks like its quite common for AW to keep reusing the same IPs for years, right?

00:04 <apritzel> yeah, they typically copy & paste most of the IP, but then change some tiny bits here or there

00:05 <apritzel> graphics could be quite tedious, especially since I don't know how they connect the "display" here

00:06 <apritzel> but I guess you bought that projector just to use it with a serial console only ... ;-)

00:08 <alikates> yeah xDD

00:08 <alikates> the dts has some references to mipsLoader, do you know anything about that?

00:09 <alikates> and yes, display looks bad:

00:09 <alikates> > compatible = "allwinner,sunxi-tvtop";

00:09 <alikates> no idea what that is

00:17 <apritzel> TVTOP is a common component in AW SoCs, though, it connects the output of the "display engine" (the framebuffer scan-out DMA device) to the respective video pins, TVTOP suggests is some kind of analogue signal

00:19 <apritzel> alikates: looks for tcon_tv in mainline sun50i-h6.dtsi

00:22 <alikates> Ooh, so maybe then it's not so bad

00:23 <apritzel> well, but details matter here (in an investigation ...)

00:25 <apritzel> meaning that those bits differ from SoC to SoC

00:27 <apritzel> I found https://github.com/CrealityTech/sonic_pad_os/blob/main/lichee/brandy-2.0/spl/include/configs/sun50iw12p1.h, which suggests that the SRAM layout is that of the R329

00:27 <apritzel> so mix and match!

00:27 <apritzel> not sure if w12p1 is something different from just w12, though

00:28 <alikates> in dts its w12p1

00:28 <alikates> also, iirc i saw a couple kernel modules, one called ge2d

00:30 <KREYREN_oftc> > <apritzel> KREYREN_oftc: "suffers performance-wise on a bloated kernel"> are you sure about that? What does cause performance issues, exactly? < Forced loading of unneded modules and configuration that doesn't correctly do what the system should be doing e.g. proper hybernation instead of just turned off display etc..

00:31 <KREYREN_oftc> things that generally shouldn't be an issue, but the linux kernel configuration is kinda not as functional in terms of configuration as it should be so it's needed

00:31 <alikates> apritzel: if you want to check out the DTS too: https://paste.debian.net/1304864/

00:35 <apritzel> KREYREN_oftc: sorry, that doesn't really parse. A custom config makes the image smaller, and boots faster, but other than that there should be much *performance* impact, compared to a generic modular kernel

00:36 <apritzel> KREYREN_oftc: arm64 is a single image kernel, meaning one kernel image to run on all systems (same like x86). Custom compiling kernels for a particular board was common for ARM in the past, but shouldn't really be needed anymore

00:37 <apritzel> (unless you are *very* short in resources)

00:37 <apritzel> alikates: thanks, I will take a look

00:37 <alikates> I'll also update the wiki when I have more info

00:45 <apritzel> interesting, so it's the NCAT2 generation (UARTs at 0x2500000, etc, like the D1), but with A53s

00:46 <apritzel> so like a cross over between the R329 and H616, I guess, or maybe a modernised version of the H616, with an NCAT2 memory map

00:49 <alikates> for me it looks like some weak old a53s but paired with other modern IPs

00:50 <alikates> quite interesting...

00:52 <alikates> btw, do i have to worry about secure boot? can the EL3 firmware be replaced easily? Some time ago I wanted to run VMs for fun in a pmOS phone but only EL1 is accesible. It would also be fun in this HW xD

00:59 <KREYREN_oftc> apritzel, like A64 is very short in resources and doing custom with ccache makes it possible to be recompiled on demand which is kinda the main motivation for hackerspace-environment but also kernels adjusted specifically for allwinner usually don't have issues with suspend and hybernation and the smaller kernel seems to make the system visibly more responsive

01:01 <KREYREN_oftc> *hibernation

01:01 <KREYREN_oftc> that said i don't think it's kernel-induced issues i think it's problem on downstream side with linux distributions forcing the load of kernel modules that eat on system resources and don't do anything useful

01:02 <KREYREN_oftc> so it's kinda also a research to have it on the sunxi wiki and adjust the kernels across all distros i maintain

01:02 <KREYREN_oftc> and to also make it easier for hardware hackers

01:02 <apritzel> alikates: some board use "secure boot", but it's mostly fake, as in: it's signed, but every key is accepted. We normally run a full OpenSource firmware stack (TF-A in EL3), so KVM (or even Xen) is not a problem

01:03 <alikates> nice!

01:03 <apritzel> KREYREN_oftc: that "loading modules that are not needed" sounds like a userland problem, typically the kernel loads only what's needed

01:04 <KREYREN_oftc> ye distro-induced issues that eat on the resources and then make users think that the system is too slow and incapable of anything

01:05 <apritzel> and most A64 systems are not short in resources in the sense that I mean: we are talking about a quad-core at 1+GHz and at least 512MB of DRAM, so whether the kernel image is 20 or 30MB is not really relevant

01:05 <apritzel> that's a different topic for the likes of those embedded DRAM chips like the F1C200s or T113s3

01:07 <apritzel> KREYREN_oftc: my feeling is those special domain distros cling too much onto the old times, as in: create a build for each system

01:09 <apritzel> I can understand that things like an actual phone require quite some tweaking (for fast suspend/resume, for instance), but I don't believe a system-tailored kernel config doesn't help much there

01:10 <apritzel> you should not really configure the kernel for a board, but instead select the drivers you will need, and let the actual configuration be done at runtime, driven by the DT

01:12 <apritzel> so all arm64 phones/devices supported by PMOS should be able to run on a single kernel image plus a set of modules. Unless you are talking vendor kernels, of course

01:29 <KREYREN_oftc> apritzel, teres-I has 2 GB of DRAM i am not aware of the considerations for which DRAM to use

01:31 <KREYREN_oftc> apritzel, i don't disagree with that idea that's why i am contributing to their linux-postmarketos-allwinner while hoping that the custom kernel will deprecate that package and go directly to linux-lts which is used for everything

01:31 <KREYREN_oftc> but i want to give people the option of a tiniest possible kernel bcs it's very important for hardware hacking

01:31 <KREYREN_oftc> which the platform is like mostly made for

07:11 <gamiee> apritzel: I can confirm that I saw few Allwinner BSPs (Tina-Linux) for their latest SoCs using OP-TEE. I was quite surprised.

20:49 <fraolt> Ugh, increasing the minimum GPU rate to 192 MHz in OPP table didn't completely fix the issue. The flipping frame issue happened again today for me (after 8 day without that issue): https://gitlab.com/postmarketOS/pmaports/-/issues/805