Genode on RPI

[Bob Stewart]

Hi Tomasz,
I should have thought about you not having access to a 64 bit compiler, sorry! There are many significant assembly changes and system register changes that make it impossible to get very far if 32 bit code is executed while in the aarch64 state. You've come across one with the cps instruction. Processor state is reported completely differently in aarch64, there is no cp15 "coprocessor" to control the pe any more, and you cannot write to the pc, to name just a few of the more significant changes.

Since my focus has purely been aarch64, I'll take a look at the aarch32 sections and section D.20 on interprocessing (changing execution state) in the architectural ref manual to see what i can find, tomorrow. This appears to be more difficult than it should be.

I'd suggest you try to get the u-boot patch to set the execution state to aarch32 for sure, it will save you a lot of reading time!

Bob

Get Outlook for Android<https://aka.ms/ghei36>

________________________________
From: Tomasz Gajewski <tomga at wp.pl>
Sent: Thursday, January 3, 2019 6:07:45 PM
To: Bob Stewart
Cc: users at lists.genode.org
Subject: Re: Genode on RPI


Bob Stewart <robjsstewart at gmail.com> writes:

>> Do I correctly understand, that I can go back to u-boot after running
>> Genode with 'hlt #01' and analyze content of memory there? I would be
>> surprised but definitely it would be useful.
> Yes, you can do that and the memory addresses you poked values into
> will be there. Same if you just hit the reset button.

This is something I wouldn't have guessed. I always thought about reset
as a "total reset". This seems like a usuful technique. Thanks.

>>> I sincerely hope Genode does not implement a version of the Linux
>>> DT. It is an error prone approach developed many years ago in the
>>> embedded world. There are more elegant, syntax checkable,
>>> configuration description approaches available today.
>> Could you give some hints about those alternatives? I have no
>> experience in this area and what seems to be tempting in device tree
>> is that when you look into linux sources there are already dts files
>> for all flavours of RPI including mine. U-boot uses this too - I
>> wanted to use source from this due to smaller amount of code but that
>> probably doesn't matter much.
> Approaches that use xml where the defined syntax provides a human
> readable and understandable descriptions in comments in provided xml
> templates.  But what's really wrong with the current configuration
> approach with Scupt?

I didn't think about that level as Sculpt (although some kind of a
converter from device tree to configuration could be implemented
probably). I may be totally wrong but I thought that device tree can
remove a need to write code dedicated to concrete boards. As I see it
now there are classes that define some base addresses, memory ranges,
etc. for different boards. I know for sure there is one for Raspberry Pi
1. Due to fact that that Raspberry Pi 3B+ has different base address for
all devices I had to make changes in code to reflect this. My
understanding is that this information could be obtained from boot
loader and there wouldn't have to be a need for specific builds for
version 1 and version 3. Obviously I've found out that there are other
(much more important) differences than addresses so maybe I'll have to
change my mind about using device tree.

> I'd suspect that the PE is in AArch64 state and not AArch32, cps is
> not a valid instruction in AArch64.
>
> You need to change crt0.s first read what exception level your in then
> the exection state:
>
>    /*
>      ** Check that we are in EL1 not EL0 **
>     */
>     mrs x11, CurrentEL
>     cmp w11, #04
>     beq 0f
>     hlt #00
>     0:
>
>     /*
>      ** check the execution state halt if not 32 bit
>      */
>     mrs x2, spsr_el1
>     and w2, #0x10  /* M[4] is the execution state bit 0 = aarch64 1 =
> aarch32 */
>     bne 1f
>     hlt #01
>
>     1:  ...

I can't quickly test this as, at least currently, this file is compiled
for 32bit instruction set and CurrentEL and spsr_el1 are not valid.

However maybe this mode is AArch32. I've seen some patches to u-boot
that were supposed to detect if loaded kernel is for AArch32 and switch
mode accordingly so maybe state is not AArch64. Additionally if this
code is compiled for AArch32 would it work at all in AArch64 state? I
haven't found answer for this with quick search. Will continue, but not
now.

Thanks for your suggestions. I'll read and experiment and hopefully get
back with not only questions.

Tomasz Gajewski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20190104/e9e76309/attachment-0001.html>