Hi
Where does Genode/base-hw write the exception vector to the address that hypervisor_exception_vector reports it?
It doesn't work. If I leave out the vbar setting I get exceptions from uboot if I do something stupid. If not , nothing. But of course, I might be wrong it is just that I would expect exceptions.
For example: When I by mistake put NR_OF_CPUS inconsistently., I get nothing if vbar set, if not, trigger assert. Not sure how this relates (seems odd ) but I think that it is a hint.
The el2_stack seems like a very high address.
Thanks,
Michael
Hello Michael,
On Tue, Jan 03, 2023 at 12:29:31PM +0100, Michael Grunditz wrote:
Hi
Where does Genode/base-hw write the exception vector to the address that hypervisor_exception_vector reports it?
The hypervisor_exception_vector gets mapped at a later point during kernel initialization. But it needs to be set in the corresponding EL2 register while the bootstrap code is still in EL2 to be able to return later to it. It is not useable for debugging kernel/bootstrap issues anyway. So do not mind, if you cannot see anything useful when provoking a machine exception in this stage. If you want to use it as debug utility, you can use the u-boot exception vector, like you already did.
It doesn't work. If I leave out the vbar setting I get exceptions from uboot if I do something stupid. If not , nothing. But of course, I might be wrong it is just that I would expect exceptions.
For example: When I by mistake put NR_OF_CPUS inconsistently., I get nothing if vbar set, if not, trigger assert. Not sure how this relates (seems odd ) but I think that it is a hint.
The el2_stack seems like a very high address.
This is correct, but it is simply at the higher area of the virtual 64-bit address space, like the whole kernel/hypervisor code too.
Regards Stefan
Thanks,
Michael
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
On Tue, 3 Jan 2023 at 16:10, Stefan Kalkowski stefan.kalkowski@genode-labs.com wrote:
Hello Michael,
Hello Stefan and thanks for the answer.
On Tue, Jan 03, 2023 at 12:29:31PM +0100, Michael Grunditz wrote:
Hi
Where does Genode/base-hw write the exception vector to the address that hypervisor_exception_vector reports it?
The hypervisor_exception_vector gets mapped at a later point during kernel initialization. But it needs to be set in the corresponding EL2 register while the bootstrap code is still in EL2 to be able to return later to it. It is not useable for debugging kernel/bootstrap issues anyway. So do not mind, if you cannot see anything useful when provoking a machine exception in this stage. If you want to use it as debug utility, you can use the u-boot exception vector, like you already did.
I see. Thanks for the explanation.
The el2_stack seems like a very high address.
This is correct, but it is simply at the higher area of the virtual 64-bit address space, like the whole kernel/hypervisor code too.
I figured that. It is just that I was unsure about el2_stack because of , set before mmu.
I am pretty much stuck in the EL dropping from EL2. It worked for RK3399 but that was with A53. I have cross referenced the manuals and studied the uboot macro asm. No difference , and the uboot switch works just fine. I am currently comparing Genode and uboot setup before EL switching.If I don't set the EL2 stack I get an exception ESR: 0x3a000000. Exception from an Illegal execution state. In uboot it isn't changed (Obvisually ). I am also going to rebase once again. Good as a sanity check.
Thanks,
Michael
On Tue, 3 Jan 2023 at 17:20, Michael Grunditz michael.grunditz@gmail.com wrote:
I figured that. It is just that I was unsure about el2_stack because of , set before mmu.
and apparently I ignored the sctlr settings :-)
OK so here is what I have now..
The code for EL switch with comments:
asm volatile("mov x0, sp \n" ** current phys sp "msr sp_el1, x0 \n" ** set el1 sp "adr x0, 1f \n" *point out return point "msr elr_el2, x0 \n" * set it "mov sp, %0 \n" *** set virtual sp el2 "eret \n" *** exception return "1: \n" ** return point "ldr x0,=0xfeb50000\n" ** uart address "mov x1,#'m' \n"** write to it "str x1,[x0] ": : "r"(stack_el2): "x0","x1");
Before this I added: Genode::addr_t const oldvbar = Cpu::Vbar_el2::read(); Cpu::Vbar_el1::write(oldvbar);
... and it is from uboot. I hope el1 will get it with that last statement.
I get nothing on uart.. and no exception catched. The whole point of writing to uart with asm is to test if it is the exit to c++ that fails.
Running out of ideas.
/Michael
Running out of ideas.
I see now , after upgrading sourcetree to the latest release, that MMU is disabled in ctr0.s. Doing that made Genode::raw stop working and no difference in EL switching. I am thinking.. I tried to disable dcache in uboot before.. which should turn mmu off. But since it now is disabled in genode startup I can't see that necessary.
I would like to see a bit more ARM init in Genode /base-hw . Would be nice to turn everything off and then bring in the wanted functionality. That would make a common ground. In my case there are a bunch of blobs running before uboot. I don't have control over them at all. It can boot linux, but linux does a complete setup of cpu last time I looked. u-boot runs in el2, caches and mmu is on.
The blobs are the only difference from what I did on rk3399, besides different ARM core.
...... Michael