11:08 <LordKalma> do you prefer buildroot or yocto? or buildgear?

15:27 <szemzoa> I have an 'almost' working dram init c source for T113-S3, based on sun20i-d1-spl code, but with modifications (I have to look what was needed and what is unnecessary), but the DRAMC_get_dram_size() calcs 32MB RAM instead of 128MB :). Anybody with a better knowledge has an idea what can be wrong? Here is the original boot0 and my log: https://pastebin.com/0eia0tgA

15:59 <MoeIcenowy> szemzoa: 2KB page size is quite small...

15:59 <MoeIcenowy> is the scanning of page size wrong?

15:59 <MoeIcenowy> or is the page size macros wrong? ;-)

16:00 <MoeIcenowy> oh the orig log is also 2KB

16:00 <MoeIcenowy> then your result is just right

16:00 <MoeIcenowy> maybe your formula of calculating the size missed something?

16:32 <LordKalma> We managed to narrow down the problem with the timings/clock in our device down to something that happened between 5.8.18 vs 5.9.0

16:32 <LordKalma> so something introduced in 5.9 changed the way the clock/timings work

16:38 <bauen1> LordKalma: so git-bisect is working, or did you manually test versions ?

16:40 <LordKalma> a member has a 24c machine

16:40 <LordKalma> he just tested versions

16:46 <LordKalma> So 5.9 changed the CPU governor

16:46 <LordKalma> and that's the "bug"

16:51 <LordKalma> anything other than the performance governor breaks the system

17:24 <LordKalma> I suspect timer driver

19:48 <apritzel> LordKalma: so running 5.15 with the performance governor works?

19:48 <apritzel> and what's the firmware (U-Boot) running there?

20:20 <LordKalma> the member that was doing the testing testes 5.9.0 and saw it it behaved weirdly, but then, and I quote "run cpupower frequency-set -g performance before starting the app and it works fine on 5.9"

20:20 <LordKalma> we'll have news about other versions soon

20:20 <LordKalma> about U-Boot, we're using a copy-pasted U-boot image

20:20 <LordKalma> nobody has bothered to make (discover/RE) the U-Boot config yet

20:25 <apritzel> LordKalma: what's the storage situation? Where is the rootfs mounted on? Raw NAND flash or eMMC (/dev/mmcblk...)?

20:26 <LordKalma> currently we haven't touched the internal storage

20:26 <LordKalma> but it's emmc if you're curious

20:26 <LordKalma> we have been booting of SD card

20:26 <apritzel> I see

20:26 <LordKalma> yeah, we've been "zero damage" so far :p

20:27 <apritzel> well, if it's eMMC, then a mainline U-Boot "port" is probably a five minute job

20:27 <LordKalma> Now we know how to configure the kernel, we have the panel driver,

20:27 <LordKalma> now I would like for us to configure uboot

20:27 <LordKalma> I saw buildroot can also configure uboot and get a single unique .img file in the end, that would be ideal

20:28 <apritzel> it's basically a matter of copying a "nearby" defconfig and putting the devicetree in the right folder

20:28 <LordKalma> buildroot can make out of tree changed to u-boot, right?

20:28 <LordKalma> the other community member helping with this has been using the BR2_EXTERNAL system

20:28 <apritzel> bah, I don't care about those wrapper tools ..

20:28 <LordKalma> we've been adding stuff out of tree

20:29 <LordKalma> how do you do your embedded then?

20:30 <apritzel> I just treat it like a computer ;-)

20:31 <apritzel> eventually you have to break all of that down into pieces anyway, for upstreaming

20:33 <apritzel> LordKalma: did you have the UART connected? Then you could easily build mainline U-Boot, put that at sector 16 of an SD card, and boot it

20:36 <apritzel> LordKalma: when you say "copy-pasted U-Boot image", is that a file that you copied from the original firmware or some magic sectors on the SD card?

20:39 <apritzel> LordKalma: to answer your "embedded" question: I either boot via UEFI, load manually by typing commands, or automate that via a script

20:40 <apritzel> in any case I mix and match the required components (kernel/EFI app, initrd, command line, DTB), as needed

20:57 <LordKalma> I was told mainline uboot doesn't have any suitable configuration out of the box. Still have to confirm that

20:58 <LordKalma> The uboot is extracted with dd and written to some sector yes

20:59 <LordKalma> dd if=X6100-sdcard-20220219.img of=uboot_sdcard.bin bs=1024 skip=8 count=512 seek=0

20:59 <LordKalma> This is the extraction from the firmware update file

22:01 <apritzel> LordKalma: OK, thanks,downloading ...

22:12 <apritzel> LordKalma: ok, try (or delegate) the following (in a mainline U-Boot tree): copy configs/Bananapi_m2m_defconfig to configs/x6100_defconfig

22:14 <apritzel> remove the CONFIG_USB0_ID_DET line in there, set CONFIG_MMC0_CD_PIN to an empty string (""), and change your DT name

22:14 <apritzel> then copy your .dts file to arch/arm/dts

22:15 <apritzel> I reckon that's the safest config. If DRAM init doesn't work, try to lower CONFIG_DRAM_CLK, for instance to 456

22:15 <apritzel> I will try to rev-eng the frequency from their SPL, but no promises ...

22:17 <apritzel> is Xiegu a Swedish company? Or is that just the distributor/point of contact in Europe?

22:20 <apritzel> LordKalma: can you run "md.l 0x01c20020 1" on the vendor U-Boot prompt? That should dump the PLL_DDR0_CTRL_REG, to learn the DRAM frequency

23:01 <apritzel> LordKalma: wow, they seem to use 384 MHz only, judging by the SPL disassembly, so try that