00:01 <apritzel> farhan: if it's designed for mainline, and all the devices are supported, this should work: enabling a new board would indeed just involve loading the right DT

00:01 <apritzel> plus a U-Boot defconfig, most likely with the proper DRAM parameters (for newer SoCs)

00:03 <farhan> apritzel: Would you please mention which varient of H616 is under discussion here?

00:04 <apritzel> farhan: do you mean the board tokyovigilante, macromorgan and Raqbit are dealing with? That's the H700 on the Anbernic RG35xx devices

00:04 <apritzel> farhan: what is your board using?

00:07 <farhan> apritzel: oh ok I went to Raqbit's gist and it was about H616 SUN50i, which is actually my board using

00:07 <apritzel> the H616 is very close to the H700, the latter mostly just exposes more pins

00:08 <apritzel> the both use the same code, and the differences are expressed in the DTS. The little where the chips differ is handled in U-Boot and TF-A, and we autodetect the variants

00:08 <farhan> apritzel: I have a little bit of linux knowledge and love to learn a little about SBC

00:10 <apritzel> farhan: for an H616 board you need the DRAM parameters, you can read them from a vendor image using https://github.com/apritzel/sunxi-fw

00:11 <apritzel> if you look at the recent patches on the lists for enabling new boards (e.g. the Tanix TX1), you should get an idea what you need

00:12 <apritzel> https://lore.kernel.org/linux-sunxi/?q=%22Tanix+TX1%22

00:13 <farhan> apritzel: I was reading here and there, a while back and someone mentioned about using uboot config for orange pie zero which was recently supported back then. I tried my best to give that a shot and asking a little bit one libreelec. But offcource no use, so i put it in the draw and forgot about it.

00:14 <farhan> apritzel: i will certainly give that a try. thank you

08:36 <tokyovigilante> thanks apritzel, Raqbit definitely worth working through the process manually, good for both debugging and your understanding of the boot process

08:37 <tokyovigilante> maybe read the IRC logs from https://oftc.irclog.whitequark.org/linux-sunxi/2024-03-02#32984887

08:37 <tokyovigilante> March 3-5 is when apritzel talked me through manually loading each component (SPL -> TF-A -> u-boot -> kernel)

08:38 <tokyovigilante> really weird that SD boot works but FEL doesn't with the same binary, given that tree has been running fine here for a month or so, but you'll probably need to pull it apart to figure out why

08:38 <tokyovigilante> you're running a -H right? What board revision?

08:39 <tokyovigilante> My -H is 2024-01-08 v4

08:47 <tokyovigilante> https://oftc.irclog.whitequark.org/linux-sunxi/2024-03-10#33008578

08:48 <tokyovigilante> that log is a bit later, interestingly acmeplus had the same issue with a binary u-boot I had built, but it turned out to be some sort of Ubuntu USB issue if you read that log

12:04 <Raqbit> tokyovigilante: Yep, I've got an -H 2024-01-08 V4 as well. The puzzling part is that the uboot-with-spl binary reads back fine, which lead me to believe it can't be a FEL-transport issue.

12:06 <Raqbit> Looking at the wiki, there does seem to be a lot of magic and switcheroo going on when booting u-boot over FEL to accommodate for the BROM application stack: https://linux-sunxi.org/FEL/USBBoot#General_description_of_the_.22sunxi-fel_uboot.22_command_implementation

12:25 <apritzel> Raqbit: yes, but this is purely SoC specific: so if it works on one board with one of H616/H313/H700/T507, it works on all

12:26 <apritzel> so in the past we had issues that only showed with certain newer compilers, I think GCC 11.1 and later, GCC 10 was fine

12:27 <apritzel> so it might be worth comparing notes on how the components were built, and also mixing and matching the components

12:35 <apritzel> jernej: do you have any idea why the H616 clock driver has been backported to v5.4 and v5.10?

16:39 <jernej> apritzel: I believe A100 and H616 drivers are backported so "clk: sunxi-ng: Unregister clocks/resets when unbinding" can be backported.

16:40 <jernej> tokyovigilante: There will be no rage from maintainers, if you don't follow code style. But patches won't be merged either.

16:41 <jernej> tokyovigilante: Is that H616 analog audio driver based on D1 one from smaeul?

16:41 <macromorgan> tokyovigilante: I'm back today and looking at this again. I tried building your latest rg35xx-upstream and booting it on the H, but I'm also getting the same stuck at "Trying to boot from MMC1". Is that what you're getting or are you getting further?

16:41 <jernej> as far as I can tell, D1 and H616 have almost the same analog audio peripheral

16:43 <apritzel> jernej: mmh, but "backporting" the whole file is unnecessary, isn't it? Is this some kind of automatism, because no one could be bothered to remove the h616 file from the patch?

16:45 <jernej> seems so. But you have to understand stable branch managers - unless they know exactly what they're doing, it's much safer to just find dependencies and merge them too.

16:45 <jernej> but that's why they're sending patches for review

16:51 <gamiee_> Hi folks, is anyone here interested in getting SBC with Allwinner T527 SoC for mainlining/reversing/etc...? If yes, please send me DM. Thanks :)

18:27 <macromorgan> gotta be a problem with my a-tf binary I guess

18:30 <macromorgan> think I'm missing something from this 4 series set: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/27326

18:31 <macromorgan> should I have a device tree in A-TF or something?

18:33 <macromorgan> I've also pinged Anbernic to see if they set anything that allows the device to be distinguishable in software so that we can maybe use the same bootloader for all devices

18:53 <macromorgan> also if anyone needs it I dumped the RG28XX device tree here: https://gist.github.com/macromorgan/1ce131a841379f3e8f2a14c8a6ae3410

19:04 <apritzel> macromorgan: what about the extra buttons? what happens if you read the GPIOs on the other devices?

19:05 <macromorgan> haven't gotten there yet, still trying to figure out why my U-Boot isn't booting

19:05 <apritzel> I once experimented with the pull-up/pull-down settings GPIO registers: a floating pin would follow the PU/PD setting, a fixed pin wouldn't

19:05 <macromorgan> I'm honestly running low on ideas :-(

19:06 <macromorgan> it fails right as it tries to jump to the A-TF image (not sure if it actually gets to A-TF or not, as even with debug I don't see any output from A-TF)

19:06 <apritzel> to unblock you, can't you use tokyovigilante's binaries, for the time being

19:06 <apritzel> or at least his TF-A binary

19:06 <apritzel> and btw: all those TF-A patches are optional, it works fine without them

19:13 <macromorgan> okay

19:14 <macromorgan> well I still need to figure out why my handoff is failing :-(

19:21 <apritzel> what is rg28xx? did they run out of letters already, and named it using a different number, despite it being the same SoC?

19:21 <macromorgan> 28 means the screen size is 2.8" instead of 3.5"

19:21 <macromorgan> otherwise it's the same device, yeah

19:22 <apritzel> i see

19:56 <Raqbit> I like how they name it XX, like it's a chip family

20:12 <macromorgan> well XX doesn't matter here, because the very first one was an Actions Semi abomination

20:12 <macromorgan> but each after that has been H700

20:32 <macromorgan> did Tokyo post his BL31.elf on here? I might have missed that conversation

22:32 <apritzel> macromorgan: did you mean bl31.bin? For Allwinner we need the binary, not the ELF file (as for Rockchip, IIRC)

22:32 <macromorgan> yeah, I just remembered a few minutes ago and it turns out that made the difference

22:33 <macromorgan> I hate that I spent several hours on it and that was the issue... things are working for me now

22:33 <apritzel> \o/

22:36 <macromorgan> is there a reset function or something on the dram controller? I'm wondering (thinking of ways to approach making ram init more stable) if we reset and pause for a few ms on each boot

23:42 <apritzel> the BSP code has some udelays sprinkled all over the place, but IIRC jernej double checked that and found all of those accounted for in the mainline code

23:43 <apritzel> and there have been some attempts of poking in the dark and adding some random things here and there

23:44 <apritzel> but before I commit to any of them, I would really like an explanation

23:52 <apritzel> macromorgan: this thread is about the H6, but might apply to the H616 as well: https://lore.kernel.org/u-boot/20231001161336.31140-2-viraniac@gmail.com/