Initial bringup -- Hal entries question

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 ¹ below where it save the addresses I get the following values:

addr: 0xfc046ac0i r0 0×7c05aebc SP 0×7ff4

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.

¹ https://gitlab.riscosopen.org/RiscOS/Sources/Kernel/-/blob/master/s/HAL#L2780

I am considering stack error. Not sure at all because in PineA64 port it isn’t modified before OS_Start.

This is a crash example

LR 0xfc045b3c R0 0xffff0000 SB 0xfa0001e8 PC 0xde934ed4

LR points to the calling address , R0 to ZeroPage SB to location of address storage.
So far correct.. but PC is what it gets from SB pointer (HAL_WorkSpace – offset)

Note that PC ( destination address) can differ.

When does the hal entries get populated and from where? The ¹ function assumes offsets I think, and construct absolute address

¹ https://gitlab.riscosopen.org/RiscOS/Sources/Kernel/-/blob/master/s/HAL#L2766

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?

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.

emulator isn’t behaving

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?

Putting in WFI here
https://gitlab.riscosopen.org/RiscOS/Sources/Kernel/-/blob/master/s/HAL#L2772

Gives:
bq.
>>> R0 = 0xffff0000
>>> R1 = 0xfc022ea4
>>> R2 = 0xfa0001e8
>>> R3 = 0×38000
>>> R8 = 0xfc045a60
>>> PC = 0xfc046904
>>> LR = 0xfc045b14

R1 points to something in HAL.. then it adds R3.. ends up at offset &5aea4 (in kernel)

Same thing after
https://gitlab.riscosopen.org/RiscOS/Sources/Kernel/-/blob/master/s/HAL#L2775

>>> R0 = 0xe89a003f
>>> R1 = 0xfc05aea8
>>> R2 = 0xfa0001e8
>>> R3 = 0xfc05aea4
>>> R8 = 0xfc045a60
>>> PC = 0xfc046914
>>> LR = 0xfc045b14

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.

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.

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.

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
The value is there in the rom , but i think it should read the 4th word in the table.

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

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.

Its surprising when you get things together to ask a question – the answer comes :-)

It helps thinking loud.