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