02:16 <triskit> soupborsh: interesting, I thought the BROM was executed in place though…? Boot0 would be the SPL so not technically a “ROM”

03:29 <apritzel> warpme: the link doesn't work (anymore?), but in general the vendor BL31 is botched and has special expectations. I hacked Syterkit's extlinux recipe to load an early mainline U-Boot port instead of a kernel, with USB and MMC working, then take it from there

03:30 <apritzel> I can push my Syterkit changes once I am back on my machine

03:31 <apritzel> be advised that this is all a hack, to unblock kernel development, which has the highest latency and review requirement

03:36 <apritzel> but if you need something quickly, I'd go with Syterkit's extlinux target, plus the SCP and BL31 that ships with it, and remove the Avaota display code

03:39 <apritzel> triskit: I highly doubt that Allwinner does anything fancy like ROM patching or shadowing, we have never seen any evidence of that

03:40 <apritzel> the BROM code is not PIE, for a start, and there is not enough freely available SRAM for any kind of shadowing

03:41 <apritzel> I hear you that the "smc" does not work, it's the same situation on my secure A133 tablet, but there must be something else we miss

03:46 <triskit> apritzel: got it. Although patches are not “fancy”, speaking from 16-bit MCU-land :D

03:48 <apritzel> we are talking AW here, so the "fancy bar" is quite low ;-)

03:51 <apritzel> on the A133, it returns from the smc, and I wonder if it's actually secure SVC, but not the "highest implemented EL", which ARMv8 requires for things like RVBAR and CNTFRQ write access

03:55 <apritzel> this is a subtle difference between v7 and v8, even in AArch32: you can be in secure SVC, but that can be EL1 or EL3. At reset it's EL3, but if you eret from there, it's EL1

04:00 <apritzel> loki666: did you get your regulator question answered? The &reg_cldo3 is an alias, which points to a subnode of the regulator node within the AXP node

04:01 <triskit> apritzel: Good to know… I should compare the H6 and H616 BROMs at some point.

04:02 <apritzel> loki666: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/regulator/axp20x-regulator.c#n829 connects the AXP register offset and voltage encoding to the "cldo3" node name

04:03 <apritzel> loki666: I feel like using the node name for matching is not really by the "DT book", but that's how the binding is

04:05 <apritzel> triskit: in any case, it's just an issue with FEL, isn't it? Becasue loading from MMC via a TOC0 image works for me on that tablet

04:07 <triskit> Right

06:45 <loki666> apritzel: yes I understand for the regulators that match the PMIC registers via their names, but in other case (like tokyovigilante récent codec patch) a new regulator node is created and assigned to the device

06:46 <loki666> Are these "dummy" regulator that can't be changed by PMIC but are added just to make the device happy?

06:51 <loki666> Well....codec is maybe a bad example, but we do that for mmc supply and LCD supply also (in downstream patches)

08:06 <Jookia> loki666: yes, not all regulators are controllable

08:06 <Jookia> this means drivers can work with both fixed supplies and switchable ones

10:51 <loki666> Btw, I found the H618 datasheet here https://docs.banana-pi.org/en/BPI-M4_Zero/BananaPi_BPI-M4_Zero

10:51 <loki666> If someone wants to upload to the wiki

10:59 <loki666> Well there isn't much...

12:54 <warpme> apritzel: thx for looking on bl31 on h728! Boot log from booting was from syterkit with syterkit bl31.bin/scp.bin: https://gist.github.com/warpme/cef721be8621720cddad7a037b5fda9a With mainline bl31 (v2.12) boot just hangs on L41 So for me it looks like hard blocker is bl31 (syterkit traps; mainline hangs)

13:00 <parthiban> apritzel: "sun50i-iommu 30f0000.iommu: attempt to map address beyond 4GB" Am still trying to understand the iommu driver and also your changes made in this respect from https://lore.kernel.org/linux-sunxi/20240616224056.29159-1-andre.przywara@arm.com/. The same works with my 1GB RAM variant and fails to work in 4GB variant of the A133. Quick hints will help me narrow down this. Thanks.

13:09 <warpme> parthiban : just fyi: when i updated kernel in 2 distros to 6.12 i started to have issues with h313/h616/h618 boards having >2G. Issue was with iommu. I don't have time to find root cause then properly solve it so i developed hack which works ok for me on 4G devices. Code is like this: https://github.com/warpme/minimyth2/blob/master/script/kernel/linux-6.12/files/0615-drivers-iommu-sun50i-iommu-fix-iommu-on-h616.patch Just in

13:09 <warpme> case.....

13:11 <parthiban> warpme thanks, for now I passed mem=2G to the kernel to check my display engine stuff

13:13 <warpme> i had exactly the same issue. limiting mem to 3600MB (iirc) was bringing hdmi back....

13:14 <parthiban> in that case, IMO it makes sense to post to the mailing list

13:18 <warpme> yeah - agree. issue is dramatic lack of time (professional life just kills me). Also suspect "interesting" discussion threads which fr sure will happen (like "this is wrong"; "code is horrible"; "you are doing it wrongly" etc)

13:19 <warpme> after all this is hack - not proper solution :-(

13:20 <parthiban> warpme I will post the issue faced to the list. looping piotr.oniszczuk@gmail.com will work?

13:21 <warpme> yes!

17:11 <MasterR3C0RD> parthiban: The changes in that patch appear to just force RAM handled by the MMU to <= 0xFFFFFFFF. When you have 2GiB of RAM, for example, the highest DRAM address available is 0x80000000, but in the memory map this starts at 0x40000000, thus the highest possible address is actually 0xbfffffff

17:12 <MasterR3C0RD> s/0x80000000/0x7fffffff

17:14 <MasterR3C0RD> This fits within the 32-bit address space, but when you have 4GiB of RAM, the highest physical address is 0x13FFFFFFF; the MMU can't handle addresses outside the 32-bit range, so it'll error if that's attempted

17:14 <MasterR3C0RD> My guess is that something's passing in an address in the higher parts of RAM, and thus it can't be mapped

17:18 <MasterR3C0RD> So it seems more likely that what's happening is the DE driver is trying to allocate framebuffer memory in DRAM, but the allocation it's getting is in said zone

17:47 <MasterR3C0RD> Or something in the vein of "DE driver attempts to allocate DMA memory, but the address allocated is >0xFFFFFFFF"; not entirely sure of the specifics there

18:16 <apritzel> MasterR3C0RD: that shouldn't be a problem though, as the default DMA map is still 32bit, so allocations should come from <3GB anyway

18:17 <apritzel> but indeed every physical address involved should be checked

18:18 <apritzel> shame that the IOMMU of all devices cannot handle more than 32bits...

18:21 <MasterR3C0RD> apritzel: Considering the iommu error appears to be coming from fbdev-dma (based on the error that follows the iommu in his mailing list post), it certainly seems like it must be something in the vein of "allocating DMA memory outside the valid range for the IOMMU"

18:22 <apritzel> warpme: to be clear: there is no mainline TF-A support for the A523 family, so we are stuck with the vendor build for now

20:20 <warpme> apritzel: yes i already discovered that for A523/H728 there is no atf yet. So it looks to me like only existing atf for a523 is syterkit (and i assume it works ok on a523). Unfortunatelly syterkit seems not working with h728 so....currently my h728 board becomes shelf dust collector :-( argh....

22:12 <apritzel> warpme: i wouldnt say that, i guess the h728 is the same die as the 523 - what does sunxi-fel say about the SoC-ID?

22:57 <MasterR3C0RD> apritzel: I had checked the SoC family page when warpme had came by initially; it says the H728 matches the A523 (sun55iw3p1)

23:02 <apritzel> well, that's what the wiki says, but it would be good to get a technical confirmation