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 Androidhttps://aka.ms/ghei36
________________________________ From: Tomasz Gajewski tomga@wp.pl Sent: Thursday, January 3, 2019 6:07:45 PM To: Bob Stewart Cc: users@lists.genode.org Subject: Re: Genode on RPI
Bob Stewart robjsstewart@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