Genode on RPI

[Tomasz Gajewski]

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