10:56 <eliasbakken> jernej: CPUSLDO is not enabled by default, no. So if the ARISC should be enabled from a clean boot, then the CPUSLDO must be enabled. I don't know the registers for the ARISC clock source, but it might be that the ARSIC is not clocked by default. Also, the MSGBOX has a separate clock.

11:11 <loki666> On a133p front, we managed to get the kernel to boot (issue was u-boot dram params)

11:11 <loki666> On the Zero28

11:12 <loki666> SMP is not working (as expected)

11:13 <loki666> partiban do you have a branch to test your DE2 update for A100, post on ML is incomplete

11:32 <jernej> eliasbakken: I can't find anything related about ARISC CPU clock in documentation. I suspect CPUS in documentation is ARISC and MCU is RISC-V, but sometimes it looks CPUS is also RISC-v...

11:37 <jernej> apritzel: git version of openocd seems to works nicely with a527. What I've noticed is that we should look into M-BROM for FEL boot issues instead of S-BROM. Hopefully finding aarch32 switch issue won't be hard now.

12:57 <jernej> apritzel: so the reason why sunxi-fel breaks is because soc ends in what it looks like some interrupt or trap handler at address 0x15010, which is just infinite empty loop.

13:13 <jernej> so it seems to be data abort handler

14:42 <jernej> apritzel: so reset is done properly and back_in_32 gets executed. From what I can tell, someting restoration of the fel state goes wrong and cpu ends on invalid instruction

14:52 <Soupborsh> I'm new and trying to port U-Boot to B288. Everything I did was just guess and logic. I have possibly silly questions I couldn't find answers, this place seem to be most appropriate to ask.

14:53 <jakllsch> then ask :-)

14:54 <Soupborsh> How do I properly create B288 as new SoC based on H3? I want all things from H3 that work to continue but I want to make changes specific to B288.

14:58 <Soupborsh> I tried but GPIO stopped working and code was messy.

16:25 <jernej> apritzel: when cpu goes in data abort handler, it has LR set to 0x1502c, which is right behind call to USB0 device interrupt handler

16:25 <jernej> not sure if this helps

16:36 <jernej> apritzel: now I'm pretty sure that something is wrong with GIC. If I load SPL via jtag, it works fine and goes back to some loop in mbrom. But as soon as I execute "sunxi-fel ver" it goes back to data abort trap.

17:47 <BroderTuck> jernej: Progress! (even tho it's not fully solved yet)

17:48 <jernej> it's fun! going through tons of assembly without much clue :)

17:49 <BroderTuck> remind me, this trouble is because the Avaota (and the Radxa board?) start in secure?

17:51 <jernej> neither start in secure

17:51 <jernej> and both are problematic

17:51 <jernej> apritzel has some third board, which works fine, so I suspect is due die variations

17:52 <jernej> there is a lot of SID checks in mbrom

17:52 <MasterR3C0RD> loki666: https://gitlab.com/linumiz/linux/-/tree/b4/a133-display-support?ref_type=heads

17:53 <loki666> Thanks

17:53 <BroderTuck> Maybe "start in secure" was a bad description, more like "need Toc0".

17:54 <MasterR3C0RD> That's the full DE series for the A133P; I haven't seen parthiban here for a while but I might shoot him an email at some point and see if he would be able to resend it

17:55 <jernej> well, none of these boards need toc0, standard egon header...

17:57 <BroderTuck> Anyway, I think the device apritzel has that it works on is the same tv box that I have, the X96QPro+

18:05 <jernej> BroderTuck: that's H728, right? can you dump sid?

18:07 <BroderTuck> It starts out 0300ff00, I can check the rest if you want

18:10 <BroderTuck> 0300ff00:81704824:75b09010:147f1cd6 (sunxi-fel sid)

18:11 <jernej> hm... actually I'm more interesting what's on 0x03006210

18:11 <jernej> so right behind chipid

18:12 <jernej> just call sid-dump

18:14 <BroderTuck> palvencia.se/sid-dump.txt

18:17 <jernej> thanks, so it's zero on both...

18:27 <BroderTuck> Apparently the ff00 part should be enough to identify the H728

19:57 <BroderTuck> jernej: Just did a small test to see if all the cores were really online. "make -j 6" took about a quarter of the time of a plain "make" when compiling u-boot

20:01 <jernej> that's great. Now someone can write dvfs driver to get full speed ;)

20:22 <apritzel> Soupborsh: it's a bit involved, and quite tedious to explain here in the chat

20:22 <apritzel> Soupborsh: but first: from the kernel point of view, there are some ARM cores and a bunch of drivers, the DT tells you which drivers to use

20:23 <apritzel> so if the B288 is close to the H3, you just reference the same drivers as the H3 does

20:23 <apritzel> there are two devices which are quite SoC specific, so you need special versions for those: the pinctrl and the clock (CCU) driver

20:25 <apritzel> Soupborsh: this series should give you some idea how to go about it: https://lore.kernel.org/linux-sunxi/20250205125225.1152849-1-szemzo.andras@gmail.com/T/#u

20:26 <apritzel> jernej: so is it failing still in our back_in_32 code? Or when the first interrupt fires, already in BROM code?

20:27 <apritzel> BroderTuck: as jernej said: the X96QPro+ is using H728, and it's the same non-secure/eGON boot as the other two boards

20:28 <jernej> apritzel: back_in_32 code works just as expected, it fails somewhere in BROM when handling USB afterwards

20:28 <apritzel> so either the BROM is doing something differently on H728, or (more likely) we have a bug in our FEL code and somehow get away with it on that chip, but not on the A523/T527

20:30 <jernej> along the way I identified 2 brom configs bits which reside in sid. one seems to kill FEL support and other looks like allows high speed USB for fel

20:31 <apritzel> regarding more enhanced A523 support (DVFS, for instance): is there someone out there willing to address things? There are plenty of smaller tasks that can be done independently

20:31 <apritzel> jernej: ah nice, I think USB2.0 FEL came up some years before, but I guess we have bigger issues to address first - like getting it work at all completely ;-)

20:32 <apritzel> jernej: so you got JTAG working, using a MicroSD breakout board, I guess? How do you connect the JTAG signals to your host? Some random USB JTAG adapter, supported by OpenOCD?

20:33 <jernej> is there any difference in protocol? I would assume that it is just higher speed

20:34 <apritzel> FE 2.0> back then the report was to just flip a few bits, and it would be faster

20:34 <apritzel> FEL* 2.0

20:35 <apritzel> on the host side it would be about OCHI vs. EHCI, I think, but apparently it's easier on the MUSB side?

20:37 <apritzel> jernej: so I guess you have seen the two GICv3 registers I save/restore in the U-Boot code? I checked the other registers, they either should not matter or were the same as on reset

20:37 <apritzel> I tried two or three I was not sure about, but they didn't make a difference

20:37 <apritzel> but I did this mostly on the H728, because that's the most reliable board for FEL for me

20:38 <apritzel> I got an Avaota v1.5 from TL Lim last week, but did not come around to try that yet

20:41 <jernej> apritzel: I made this: https://ibb.co/0pncsZY7

20:42 <jernej> surprisingly first revision already works. openocd script was a challenge, but mostly because it's first time I was writing it

20:43 <apritzel> wow, that's neat! PCBWay?

20:43 <jernej> correct

20:43 <jernej> I plan to push it to gh

20:44 <apritzel> very nice!

20:45 <jernej> apritzel: to get back to your gic questions - I identified extra registers that are written

20:46 <jernej> icc_sre and icc_grpen0

20:46 <apritzel> I scanned the BROM code for GICv3 sysregs written, and think I covered all of them - some are nonsense^Wirrelevant I think

20:46 <apritzel> yes, ICC_SRE is RES1, for instance (tested that)

20:47 <apritzel> and IIRC saving and restoring igrpen0 didn't change anything

20:47 <jernej> correct, I tested that anyway and no difference

20:48 <apritzel> it doesn't make much sense anyway, since we are surely using group1 only

20:52 <jernej> so what it could be? I can test/check anything, if you can come up with an idea

20:57 <jernej> apritzel: is there anything else in GIC600 that could be suspect?

20:58 <apritzel> mmh, now that you say GIC-600: there could be some IMPDEF registers, for power saving/bringup, I can check those

21:11 <jernej> that reminds me, maybe is some design decision on board that makes it work on X96QPro+ (sbc vs. tv box)

22:24 <apritzel> well, I thought about this as well, but can't really believe that, since it's just FEL and the BROM, so nothing board specific, and FEL itself works