On Mon, 26 Aug 2024 12:05:03 +0200 Stefan Kalkowski <stefan.kalkow...@genode-labs.com> wrote:
> On Mon, Aug 26, 2024 at 11:42:44AM +0200, Stefan Kalkowski wrote: > > > I have checked bits and pieces. I believe that irq 30 is the timer > > > according to the manual. The gic should work , it did on RK3588. > > > Not sure if they are critical , but both is 0x1. > > > ICC_IGRPEN0_EL1 > > > ICC_IGRPEN1_EL1 > > > > > > > > > > > Just a shot in the dark: you told us that you stepped from EL3 > > > > to EL2 in u-boot?! Maybe you just switched the exception-level > > > > without further preparation of additional peripherals (like > > > > GIC) normally done by the TrustZone firmware? > > > > I assume that the GIC's default register values are initialized > > > > in a way that interrupts are marked "secure", and thereby > > > > cannot be enabled by the normal world resp. the hw kernel then. > > > > One way to proof this would be to lookup the Igroup registers > > > > of the GIC's redistributor interface while the CPU is still in > > > > EL3 (shortly before switching to EL2). > > > > > > Do you refer to the above regs? If I need to access GIC memory > > > mapped I need somes extra code. > > > > No, the ICC_IGREN* register belong to the cpu local interface of the > > GIC. What I meant are global ones that belong to the GIC's > > redistributor interface. > > In general the GIC's memory mapped I/O registers are accessed > > already within the Hw::Pic constructor within > > `repos/base-hw/src/bootstrap/spec/arm/gicv3.cc`. The constructor is > > used explicitly within the EL2 codepath of the > > `Bootstrap::Platform::enable_mmu()` for Cortex A53. If you really > > start in EL3, at least part of that code should be executed in EL3. > > In that case, you could duplicate the Pic initialization before > > entering `prepare_non_secure_world` as a first try. > > I have to correct myself. We already initialize the Pic alias Gicv3 > within EL3 (if booting to it), as well as in EL2. > In EL2 this is done explicitly within > `Bootstrap::Platform::enable_mmu()` asstated before. But in general, > it is done within `Bootstrap::Platform::Board::Board()`, which is > executed before `enable_mmu` (in EL3 if booted in EL3). > Sorry about the confusion with which EL u-boot leaves me in. But it is really odd. It definitely started in EL3 , if the Genode is correct in checking. I then tried with booting from EL2 which worked fine. After a bit of tinkering I wanted to try EL3 again, so I removed the switch from u-boot. I was *very* surprised to be in what I thought was EL2(!?) ... However I might be wrong. I want to check now , but see below , not getting there. I think that the interrupt issue might be because something in the source tree I started with (because it was the one where I started with RockChip).I have moved on to the current git version. But unfortunately it crashes,I think, right in the mem map code. I have tried to map only small part of ram but i doesn't make any difference. The only thing that is different in the very beginning is stack.. the old crt had stack embedded. The mmu file is the same I think. RK3588 booted up using a current tree back then. I can't verify if that is the case now since that board is in storage. It seems like Pic is initialized in different ways in the ports. I have the same as imx8 port. Thanks, Michael _______________________________________________ users mailing list -- users@lists.genode.org To unsubscribe send an email to users-le...@lists.genode.org Archived at https://lists.genode.org/mailman3/hyperkitty/list/users@lists.genode.org/message/EAALO55PLHYDIXESRTPBQTLYOJ2UFSWI/
