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@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@lists.genode.org https://lists.genode.org/listinfo/users