Genode on RPI

Bob Stewart robjsstewart at gmail.com
Thu Jan 3 14:00:35 CET 2019 

Looks like your problem is simply that the boot loader is leaving the pe in the aarch64 execution state and you need to add code in crt0.s to create a small exception handler and an exception vector table for executing the handler on some exception you choose. The needs to be done before the first cps instruction.

Bob

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

________________________________
From: Bob Stewart <robjsstewart at gmail.com>
Sent: Wednesday, January 2, 2019 4:10:53 PM
To: users at lists.genode.org
Subject: Re: Genode on RPI

Tomasz, see comments in-line.

Bob

On 1/2/19 10:24 AM, Tomasz Gajewski wrote:
> Hi,
>
> I'll try to quickly move discussion about rpi to new thread to not
> pollute thread about Roadmap 2019.
>
>
> Bob Stewart <robjsstewart at gmail.com> writes:
>
>> I'm working on implementing a base-hw kernel on a Cortex A53 platform
>> (not Rpi) which is what the Rpi 3x is based on. So, that means a
>> significant amount of work to convert from the existing Genode code
>> supporting the armv7 architecture to support the armv8
>> architecture. I'm focused initially on only the aarch64 instruction
>> set, but will later add support for aarch32. This is a retirement
>> project for me so my progress is not driven by any great need and is
>> slow. After about six months of casual working I'm at the stage of
>> debugging a virtual memory translation table enhancements need to
>> support 64-bit memory (a new Level-0 table in the page table code in
>> lpae.h). The means all the assembly code changes required have been
>> made (and about 12 other areas of change) and I clean compile a from a
>> log run script.
> My plans did not include targetting 64 bit implementation as seems to be
> too big target for amount of time I can devote to it. I just wanted to
> fix/workaround some problems which I expected to find when dealing with
> device drivers - not earlier. And only trying to use code available in
> Genode already (so 32bit for ARMv7). If I correctly understand 32bit
> instruction set for ARMv8 should be compatible with ARMv7. Am I wrong
> with this assumption?

I believe your assumption is correct, although I have not verified that
it is true.

I'd carefully read Chapter E1, The AArch32 Application Level
Programmer's Model in the ARM  Architecture Reference Manual, Armv8, for
ARMv8-A architecture profile, for any difference they may mention
espactially related to exception handle or system level register changes
that affect running in the AArch32 state.

>
>> For debugging at this level, you really only have two choices: Either
>> delve into the ARM hardware debugging facilites (CoreSight) or insert
>> small pieces of code to poke variable values or a trace number into a
>> currently unused region of memory. Code like:
>>
>>              using ull = unsigned long long;
>>              ull volatile * debug_ptr = (ull *)0x91000600;
>>              *debug_ptr = MAX_ENTRIES;
>>              debug_ptr += 0x01;
>>              *debug_ptr = BLOCK_SIZE_LOG2;
>>              debug_ptr += 0x01;
>>
>> if your booting into uboot to start up, you can inspect the memory
>> region through uboots' md command. Breakpoints can be implemented with
>> the assembly code line:  asm volatile("hlt #01\n"); . Objdump gives
>> you the assembly code listing if you need it.
> 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.
>
>> 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?
>> Let me know if I can help with any compile/link issues you have, I
>> probably came across most of them in my work to-date. I'm using a
>> Linaro tool chain for aarch64. There is a separate one for aarch32
>> which I don't currently use.
>
>
> Currently my "problem" is that my RPI doesn't pass through marked line
> in crt0.s
>
>      /*****************************************************
>       ** Setup multiprocessor-aware kernel stack-pointer **
>       *****************************************************/
>
>      mov sp, #0                  /* for boot cpu use id 0    */
> --> cps #31                     /* change to system mode    */
>
>      .global _start_setup_stack  /* entrypoint for all cpus */
>      _start_setup_stack:
>
>
> I think it is due to RPI firmware is leaving processor in HYP mode - not
> SVC. But currently this is all I know.
>
> I tried to put code from FOC that is used switch processor back to SVC
> mode but as I don't understand details of it yet something is not
> working. There is some similar code in Genode implementation for Arndale
> board.
>
> On the other hand - maybe running in HYP mode is what is better for
> Genode? Some hints?

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:  ...

Then comes the hard part, since your in aarch64, the only way you can
change execution state is through a return from a change in exception
level, that's the architectural rule. I'd query the rpi community for
the simplest way of doing that. If you don't get any joy that way, I'll
see if i can come up with a generic way of using a reset exception
handler response to invoke the change.

Bob

>
>
>
> If I comment out section with 'cps #31' it goes further and I it does
> not return from 'Bootstrap::Platform & p = Bootstrap::platform();' in
> 'extern "C" void init()' and last place which I found that is executing
> is constructor: Bootstrap::Platform::Board::Board in
> 'repos/base-hw/src/bootstrap/spec/rpi/platform.cc'
>
> I'll try to find out more and ask more specific questions about this
> part.
>
>
> Tomasz Gajewski
>
> _______________________________________________
> Genode users mailing list
> users at lists.genode.org
> https://lists.genode.org/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20190103/fbd96c70/attachment-0001.html>

More information about the users mailing list