00:13 <apritzel> I talked to the author, and he said this looks like one of the cases this warning was meant to catch

00:13 <apritzel> but this would need to be checked

00:14 <apritzel> what I meant to say above is that this warning should show up for every Allwinner device using the sun50i IOMMU driver, so it's not something introduced by your patches

01:16 <tokyovigilante> oh yup, understood. So as it stands the IOMMU driver needs work regardless of the patch, but I'd be better off submittig without IOMMU support currently? Not actually needed for this patch anyway. Ideally I'd get video decode and HDMI in at some point but that will need more work for the scaler and color space stuff we cut out of the original DE33 patch.

06:12 <parthiban> apritzel LPDDR with 4GB variant for A133 doesn't work / boot. I noticed that the A133 patch set for DDR is already merged in the upstream u-boot tree. Could you please help guide to understand or possible way to address the issue? Couldn't reach to Cody Eksal also. Thanks.

13:00 <diego71> hi, does anybody know how to check if crust firmware is working on A64 cpu?

13:22 <gnarface> good question...

14:45 <Lightsword> apritzel, btw there weren't any workarounds discovered to get FEL booting working on h616 with secure boot right?

14:53 <juanesf91> parthiban: Hi, I have compiled armbian for radxa cubie a5e (allwinner a527) my board version is 1.1 with 2gb of ram and i have no problems to boot the image but i have had reports (some without log) of boards that do not start and it seems that they are the 4gb ram versions. in the last implementation of patches that are sending to mainline i added orange pi 4a to add patch gmac200 so i was able to compile a test image in

14:53 <juanesf91> which it reports to me that one does not start and another does.

15:01 <juanesf91> Reviewing the Orange Pi 4a v1.1 schematic on page 3, two different voltages appear for the RAM: 1.1V LPDDR4 and 0.6V for LPDDR4X. With this last configuration in u-boot's Defconfig, I received a functional report. In fact, the schematic shows a specific circuit for configuring the RAM.

15:03 <juanesf91> https://forum.armbian.com/topic/49353-opi-4a-allwinner-t527/page/3/#findComment-222001

15:05 <juanesf91> https://linux-sunxi.org/File:OPI_4A_V1_1_SCH.pdf

15:05 <juanesf91> https://github.com/juanesf/build/blob/da64eaa07d557964623aa8e569dbd8ea25d5118a/patch/u-boot/sunxi-dev-u-boot-a523/add-defconfigs-for-orangepi_4a.patch#L45

15:10 <wens> use 1.16

15:27 <apritzel> parthiban: which LPDDR revision? And on which board? DRAM parameters are board specific, so they might differ from what we used on the Liontron board. Did you extract the parameters from a boot0 binary?

15:29 <apritzel> Lightsword: I believe all newer SoCs behave similar (and different from say the A64) when it comes to secure boot FEL, but I didn't find time yet to dig into my A133 secure boot tablet yet to investigate

15:30 <apritzel> Lightsword: though I have some leads, and we should be on the right track (being in monitor mode), it just doesn't work yet :-(

15:31 <Lightsword> apritzel, ah, so it's mostly just a matter of finding a way to get out of monitor mode properly?

15:33 <apritzel> Lightsword: well, monitor mode is good, since it's the highest privilege level, it's just not fully compatible with the BROM FEL code, since some registers are banked or behave differently between the modes. My money is on the GIC

15:43 <parthiban> apritzel: It's custom PCB based on A133. Yes managed to extract the DDR params https://pastebin.com/raw/wMMepMT9 and also used Cody's initial WIP branch and managed to boot it. But accessing beyond 1GB fails to work. The same case with upstream u-boot as well.

15:47 <apritzel> mmh, accessing beyond 1GB is an interesting error pattern, it might be the address mapping issue then?

15:53 <parthiban> apritzel mapping in u-boot? from TRM the range is 0x4000 0000---0x13FFF FFFF, so I thought 4GB is possible.

15:57 <apritzel> No, I meant the internal controller mapping. There is the phy_init[] array, which maps SoC pins to DDR signals IIUC. And there is also a mapping between the physical memory address and the DRAM's ranks/banks/rows/cols, see mctl_set_addrmap()

16:03 <parthiban> Ok am still trying to get familiar with the DDR terms. but from the code `TODO: Handle 1.5GB + 3GB configurations` means 4GB is not supported or added at this point?

16:15 <parthiban> apritzel I have the memory dumped using md.w for vendor and upstream u-boot. Currently comparing the values and the purpose with the code, more of decoding values approach. If there is any forward/better approach, please let me know. Thanks.

16:22 <apritzel> comparing register dumps is indeed a good way forward

16:22 <apritzel> and 1.5G/3GB are a special case, because they are not a power of two, so this requires some extra code for detection

16:23 <apritzel> 4GB might work, but it probably hasn't been tested

16:25 <jakllsch> is there a MMIO window cutout?

16:52 <apritzel> jakllsch: all MMIO is below 1GB, if that's what you mean. On H616 boards with 4GB of DRAM it really maps between 1GB and 5GB

16:52 <jakllsch> ah, cool, it hoists

17:05 <apritzel> jakllsch: actually that's more a natural behaviour, nothing special: those MMIO/PCIe gaps in PCs are more due to the PC platform mapping DRAM at address 0, and it needs some MMIO below 4GB

17:09 <jakllsch> apritzel: eh, well, yeah, but still, there've been the likes of RK3399 (which only has 32-bit physical addressing), and the Intel 945 chipset (which supported 4G but couldn't hoist DRAM out of the MMIO conflict zone)