09:21 <wens> is there such a thing?

09:21 <wens> oops

14:25 <lschmid> apritzel: I've played arround some more the u-boot on the fused t113 and I can't get it succesfully continue. I even tried loading the monitor into the SRAM A1 to see if anything different happens, but it still hangs on the exact same step as before. I also compared the vector tables and call addresses with the unfused board and they seem to match... Any ideas what I could try/check next?

14:38 <apritzel> lschmid: I am still thinking ;-) or rather scratching my head, because this should all be architectural, so within the core (so Arm Cortex, not Allwinner). which means there should be no difference between "secure boot" or not

14:40 <lschmid> apritzel: Is the monitor also being used in non-secure mode? Like do the smc calls also perform something in there?

14:41 <apritzel> do you mean "non-secure boot / fuse burnt"?

14:41 <lschmid> exactly

14:42 <apritzel> yes, that's why I wonder, that should be the same

14:42 <lschmid> oh i see. yeah that's very weird then

14:44 <lschmid> would it maybe help to be able to jtag the soc? If that even works on allwinners atm

14:44 <apritzel> U-Boot proper should always be entered in secure EL1, from which it installs the monitor vectors, then triggers the smc to get into monitor mode, sets the NS bits, and erets, now into non-secure

14:45 <apritzel> yes, JTAG would be useful, and the signals are multiplexed on the SD card pins, and some people in here have used that successfully

14:46 <gamiee> also paulk did openocd configs, but not sure for which all SoCs.

14:47 <apritzel> you would need to hack U-Boot to change the PortF pinmux, and would lose access to the SD card in the process

14:48 <apritzel> and would need a microSD breakout board, unless you have those pins on headers on your board

14:48 <lschmid> I'd have to flash the signed u-boot the eMMC then, but that shouldn't be an issue if I enable ums. I'll see if i can find my jtag stuff and a micro-sd breakout

15:32 <lschmid> Okay I think openocd is finding the chip. Does that sound right? "JTAG tap: auto0.tap tap/device found: 0x5ba00477 (mfg: 0x23b (ARM Ltd), part: 0xba00, ver: 0x5)"

16:00 <lschmid> apritzel: Okay i got jtag working. What do we want to look at?

16:01 <apritzel> well, can you see where it hangs? Or what it does immediately before that?

16:04 <lschmid> If i stop the cpu after it "hangs" it seems to be running somewhere in DRAM (0xc08cb428)-ish

16:27 <apritzel> but DRAM ends at 0x50000000 or even 0x48000000?

16:28 <apritzel> lschmid: can you set a breakpoint, for instance in the monitor vectors?

16:34 <lschmid> apritzel: Okay i've got some even weirder stuff now. It seems to run away after the "bx r6" in psci_stack_setup. And the weird thing is if I set a breakpoint for "psci_stack_setup" the kernel actually tries to start up and gets stuck some time later

16:35 <lschmid> As for the DRAM ending earlier. I had thought this is DRAM too as the Datasheet refers to it as DRAM SPACE from 0xC0000000 again

16:37 <apritzel> lschmid: but that's the memory map as seen by the DSP?

16:39 <apritzel> now I actually wonder if that's something weird with some system registers, I think I saw strange things on a secure boot system as well (cache ID register being wrong)

16:39 <apritzel> can you check what the value returned by the "mrs" instruction is (for MPIDR)?

16:40 <lschmid> in arch/arm/cpu/armv7/start.S ?

16:41 <lschmid> Or just anywhere

16:42 <apritzel> in psci.S

16:42 <lschmid> did you mean mrc?

16:43 <apritzel> yes indeed, spent a good part of the day dealing with AArch64 system registers ;-)

16:46 <lschmid> If i've done it right MPIDR is 0x80000000

16:48 <apritzel> thanks, that looks alright, and should work

16:57 <lschmid> Any reason why i would not be able to step past "bx r6"? The address in r6 looks good, but if I step over it gdb never returns

16:59 <lschmid> and if i stop it after using ctrl+c were somewhere in 0xc08cb49c again

17:00 <apritzel> can you check what the newly calculated secure stack pointer is? Does that make sense? It should in the middle of U-Boot data

17:01 <lschmid> i think that would be 0x47fc6ffc?

17:06 <lschmid> r6 for bx is 0x47fc4030 btw

17:07 <apritzel> both look reasonable (relocated correctly by U-Boot to the end of DRAM)

17:16 <lschmid> "bx r6" basically jumps to r6 right? so a "set $pc=$r6" in gdb should do the same, right?

17:17 <apritzel> yes, that should return to the instruction after the "bl psci_stack_setup"

17:18 <lschmid> So why does bx r6 run away, and set $pc=$r6 work (at least until the next chance it gets to run away again)?

17:18 <apritzel> that's a good question! ;-)

17:19 <lschmid> What I'm hearing is "it shouldn't"

17:20 <lschmid> The "next chance" is a "movs pc, lr" (ERET to non-secure) in _secure_monitor

17:20 <lschmid> And it will run away into 0xc.... again

17:22 <lschmid> Or it might actually crash. Since when i break afterwards, it always shows me this 0xc08cb49c address and if I try to continue I get "Cannot insert breakpoint" and "Cannot access memory at address 0x47f756d0" and I have to hard-reset the board