Den tis 25 okt. 2022 17:21Stefan Kalkowski <stefan.kalkowski@genode-labs.com> skrev:
Hello Michael,

On Tue, Oct 25, 2022 at 03:24:01PM +0200, Michael Grunditz wrote:
> >> Indeed, it would be good to instrument all occurrences of `throw`
> >> within the page-table implementation for ARMv8. It shares the
> >> implementation with ARMv7 Large Physical Address Extension support
> >> defined within the following header:
> >>
> >>
> >> https://github.com/genodelabs/genode/blob/master/repos/base-hw/src/include/hw/spec/arm/lpae.h
> >>
> >> Regards
> >> Stefan
> >>
> >> I also notice that alloc add
> > https://github.com/genodelabs/genode/blob/8ece2366354c941ad2206f3d511cd75a1065bb75/repos/base-hw/src/bootstrap/platform.cc#L47
> > allways allocs a bigger amount out ram than I have in my ram declariation.
> > If I increse my size it adds more. Why? Does it add image size to ram size?
> >
>
> Just an alignment problem ..  if I align my mem ,, it stays.
> But it doesn't help for the insert of region for loading elf objects.
>
> And then the switch to el1.. still trying to find out the difference in cpu
> core that maskes that to fail, if it isn't ram related.

Did you instrumented all occurrences of `throw` inside the page-table
header, like I've suggested? Exception handling does not function at
this very early time. At this early stage usage of the page-table API
always needs to be cooperativly in the sense that you're not allowed
to double-insert, insert mis-aligned mappings, nor exceed the
page-table memory. I expect that a C++ exception is the reason for
your stall here. To find out what is going on, you should instrument
that first.

It doesn't make sense to try to step further, when the page-table
isn't set up appropriatedly. A switch to another exception level is not
constructive without a useful MMU setup. Before switching from EL2 to
EL1, the MMU for EL2 gets enabled using the page-table that got set up
formerly.

When looking at your insert_translation trace, I expect it contains
all calls of insert_translation?! I recognized that there has no 1:1
mapping occurred, which is normaly the case before the core/kernel ELF
is loaded. Without the 1:1 mapping it is clear that enabling the MMU
will lead to a fault resp. stall of the machine.

Regards
Stefan

--
Stefan Kalkowski
Genode labs

https://github.com/skalk | https://genode.org

_______________________________________________
Genode users mailing list
users@lists.genode.org
https://lists.genode.org/listinfo/users


Thanks for reading my confused emails.
The debug printouts is the last of many. I am doing something with throws now  as you suggest. And yes I am aware of that the translation tables needs to be correct. 

But none of this was problematic with a53. So something needs change for a76. Debugging translations will hopefully give some sort of answer. Register wise the cores should function the same. Ie both follow armv8 standards. 

Correct me on this,but I can't find any register writing before el1 and mmu time.

I am also thinking of uboot.  I have no control over it as it is now. It promptly refuses uimages,  gives abort. I am loading binary to load/start address and start it with go.

Bootm command does a bit more than just jumping to a address.

I need to build uboot, but in order to boot from mmc I need to nuke boot sector on emmc.

A good thing is that I have the TRM's now.

Michael