Initial bringup -- Hal entries question
Michael Grunditz (8594) 245 posts |
Hi, I am doing a very basic bringup of a rom with a cpu emulator. My rom consists of HAL and Kernel. MMU mapping seems to work , but, something is very wrong. In the link 1 below where it save the addresses I get the following values:
r0 is the address of HAL_Init.. It seems very wrong and I get a crash loop when trying to jump to it. I wonder how it could happen. It mmumaps HAL and I think that the HAL entries is located , at 0xfa000000. 1 https://gitlab.riscosopen.org/RiscOS/Sources/Kernel/-/blob/master/s/HAL#L2780 |
Michael Grunditz (8594) 245 posts |
I am considering stack error. Not sure at all because in PineA64 port it isn’t modified before OS_Start. |
Michael Grunditz (8594) 245 posts |
This is a crash example
LR points to the calling address , R0 to ZeroPage SB to location of address storage. Note that PC ( destination address) can differ. When does the hal entries get populated and from where? The 1 function assumes offsets I think, and construct absolute address 1 https://gitlab.riscosopen.org/RiscOS/Sources/Kernel/-/blob/master/s/HAL#L2766 |
Jon Abbott (1421) 2640 posts |
What does the table of relative entries that HAL_Descriptor points too look like on entry to SetUpHALEntryTable ? And is the HAL_Workspace pointer correct? Either the HAL entry table is wrong when it’s initialised, corrupt at a later point or HAL_Workspace isn’t mapped correctly. What’s in the HAL_Workspace table at the point of the crash? Is it consistent with what it looked like on exit from SetUpHALEntryTable? |
Michael Grunditz (8594) 245 posts |
The addresses are consistent. You can see the workspace possibly the absolute mmu mapped sb address above. I have checked and the numentries is correct. I can safely think that the emulator isn’t behaving. Could possibly be something in hal. But since I have done it the same way in all mu ports I doubt that. I need to find exactly where the mapping goes wrong in order to trace inside the emulator. The rom gets mapped to fcxxxxxx. |
Jon Abbott (1421) 2640 posts |
If the tables are consistent and the problematic code is running under CPU emulation, that would be a logical conclusion. Have you built a step-debugger into the CPU emulator? Perhaps put a halt somewhere near the Aborting code and step through it to get a better idea of what’s going on in the emulator? |
Michael Grunditz (8594) 245 posts |
Putting in WFI here Gives: R1 points to something in HAL.. then it adds R3.. ends up at offset &5aea4 (in kernel) Same thing after >>> R0 = 0xe89a003f R0 ( the value that saves to table excluding the add to get abs adress ) is from 2 words before r1 (inside kernel) This gives me the impression that R3 in the first dump is wrong. |
Jon Abbott (1421) 2640 posts |
If I saw those two dumps under the ADFFS JIT, I’d say it’s more likely the interpreter has corrupt R0 with an instruction. |
Michael Grunditz (8594) 245 posts |
Not in this case, but it seems like memory access is fussy. R0 is from two words before where it is read from (R1). I guess that is also the case with the R3=0×38000 I am dumping ram now … Hmm it is consistent… asking for word 0×0 in HAL gives me the word before hal. Asking for second word gives me first word. yes that was it… adding #4 to made kernel go to HAL_Init. Sooo .. :/ Why is rom 4 bytes higher than it thinks it is? :D |
Michael Grunditz (8594) 245 posts |
Tonight vUV300-00 rom made it! (V for victory) I was the rom relocation that went wrong.. top of ram should point to last word and not the size .. stupid me. |
Colin Ferris (399) 1798 posts |
Its surprising when you get things together to ask a question – the answer comes :-) |
Michael Grunditz (8594) 245 posts |
It helps thinking loud. |