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 <[email protected]> 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
[email protected]
https://lists.genode.org/listinfo/users
_______________________________________________
Genode users mailing list
[email protected]
https://lists.genode.org/listinfo/users
