Hi,
I am thinking on doing a super quick bringup of base-hw on RK3399 SoC. But obvisually not if someone already do this. So step forward if you do that!
The SoC has a GIC500 , but I think it can be used in compat mode. In my first RISC OS effort I simply used the cpu interface (ARM regs).. so I guess that could be done. really simple only a few instructions.
THe Boot cpu is A53.
Is SoC timers used in Genode or is it ARM timers? It looks like that.
The purpose of bringup is:
1) I want to learn the craft 2) I need material to a online talk about bringing up SoCs , and I want to use something that is not pure assembler.
Cheers
Michael
Hello Michael,
On Thu, Nov 05, 2020 at 11:51:26PM +0100, Michael Grunditz wrote:
Hi,
I am thinking on doing a super quick bringup of base-hw on RK3399 SoC. But obvisually not if someone already do this. So step forward if you do that!
The SoC has a GIC500 , but I think it can be used in compat mode. In my first RISC OS effort I simply used the cpu interface (ARM regs).. so I guess that could be done. really simple only a few instructions.
The GIC500 resp. GICv3 specification is already supported by Genode/base-hw. The i.MX 8M SoC, we primarily used to support the ARMv8a architecture until now, uses the very same interrupt controller and a Cortex A53 CPU as well. So you might use that board-support as a template.
THe Boot cpu is A53.
Is SoC timers used in Genode or is it ARM timers? It looks like that.
It depends on the SoC. A lot of ARM SoCs supported by Genode do not provide the ARM generic timer, e.g. the Raspberry Pi 1-3. But, whereever possible we use the generic timers, for instance in the i.MX 8M SoC. So, again you might use it as a starting point.
The purpose of bringup is:
- I want to learn the craft
- I need material to a online talk about bringing up SoCs , and I
want to use something that is not pure assembler.
That is nice to hear. If you were successful, I would be glad is you share your experiences with us.
Best regards Stefan
Cheers
Michael
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
On Fri, 6 Nov 2020 at 12:16, Stefan Kalkowski stefan.kalkowski@genode-labs.com wrote:
That is nice to hear. If you were successful, I would be glad is you share your experiences with us.
Hmmm.. where is the entry to the boot image, I don't get anything on the serial port, tried both with bootm (uboot image) and 'go' (binary). I gave ctr0.s a shot and put out a character on the uart, but no luck. So I don't think I get to image entry.. When doing readelf I get entry as the same address as load address. Directly outputting characters from entry should do it with u-boot configured uart.
Michael
On Fri, 6 Nov 2020 at 16:40, Michael Grunditz michael.grunditz@gmail.com wrote:
On Fri, 6 Nov 2020 at 12:16, Stefan Kalkowski stefan.kalkowski@genode-labs.com wrote:
That is nice to hear. If you were successful, I would be glad is you share your experiences with us.
Hmmm.. where is the entry to the boot image, I don't get anything on the serial port, tried both with bootm (uboot image) and 'go' (binary). I gave ctr0.s a shot and put out a character on the uart, but no luck. So I don't think I get to image entry..
EHem , it helps editing the correct file! Should have noticed from running objdump -S
Sorry for the spam, I am back on track.
Michael
snip
I am facing below:
Error: Assertion failed: id < _count && _cpus[id].constructed() Error: File: /home/micken/genode/repos/base-hw//src/core/kernel/cpu.cc:198 Error: Function: Kernel::Cpu& Kernel::Cpu_pool::cpu(unsigned int) The call that gets me there originates from core/kernel. I have configured one cpu , so id is always 0. The construct function is called prior to this, but the util method doesn't return * I THINK * .
Any thoughts?
On Sat, 7 Nov 2020 at 15:57, Michael Grunditz michael.grunditz@gmail.com wrote:
snip
I am facing below:
Error: Assertion failed: id < _count && _cpus[id].constructed() Error: File: /home/micken/genode/repos/base-hw//src/core/kernel/cpu.cc:198 Error: Function: Kernel::Cpu& Kernel::Cpu_pool::cpu(unsigned int) The call that gets me there originates from core/kernel. I have configured one cpu , so id is always 0. The construct function is called prior to this, but the util method doesn't return * I THINK * .
Any thoughts?
After a lot of headache I found this:
This functioncall does not return:
_cpus[id].construct(id, _global_work_list);
A exception was generated and resulted in a call to kernel() when no cpu's where configured. Possible case for exception is changing in EL, starting cpus (psci), I hope/think that uboot handles it.. but need to investigate more. Booting from uImage fails, at first right before starting and decompressing, then after applied patch from imx8q , goes to "no atag builtin...etc". I removed that hang()... uboot bails out on decompression . I disabled compression and can now see exception directly after "starting kernel" ESR is image entry/load.
Which EL is best to start with? when testing with running genode with 'go' things worked quite well. With bootm it can switch to EL1.
I hacked in EL1 into 'go' Result: same issue.. get exception calls kernel().. probably exception from mmu init. What are the requirement for RAM , in terms of start and size? Should it include the Genode image?
OK I think I got most in this mail.. been writing on it all day! :-)
Btw if someone want to chat .. I am on irc.
Best regards,
Michael
On Sun, 8 Nov 2020 at 00:32, Michael Grunditz michael.grunditz@gmail.com wrote:
On Sat, 7 Nov 2020 at 15:57, Michael Grunditz michael.grunditz@gmail.com wrote:
snip
I am facing below:
Error: Assertion failed: id < _count && _cpus[id].constructed() Error: File: /home/micken/genode/repos/base-hw//src/core/kernel/cpu.cc:198 Error: Function: Kernel::Cpu& Kernel::Cpu_pool::cpu(unsigned int) The call that gets me there originates from core/kernel. I have configured one cpu , so id is always 0. The construct function is called prior to this, but the util method doesn't return * I THINK * .
Any thoughts?
After a lot of headache I found this:
This functioncall does not return:
_cpus[id].construct(id, _global_work_list);
A exception was generated and resulted in a call to kernel() when no cpu's where configured. Possible case for exception is changing in EL, starting cpus (psci), I hope/think that uboot handles it.. but need to investigate more. Booting from uImage fails, at first right before starting and decompressing, then after applied patch from imx8q , goes to "no atag builtin...etc". I removed that hang()... uboot bails out on decompression . I disabled compression and can now see exception directly after "starting kernel" ESR is image entry/load.
Which EL is best to start with? when testing with running genode with 'go' things worked quite well. With bootm it can switch to EL1.
I hacked in EL1 into 'go' Result: same issue.. get exception calls kernel().. probably exception from mmu init. What are the requirement for RAM , in terms of start and size? Should it include the Genode image?
OK I think I got most in this mail.. been writing on it all day! :-)
Btw if someone want to chat .. I am on irc
. Just want to confirm that I found the place of crash:
cpus[id].construct(id, _global_work_list); , just as I thought from start. I changed exception return to B .
From that I could narrow it down.
Thanks for reading!
Just want to confirm that I found the place of crash:
cpus[id].construct(id, _global_work_list); , just as I thought from start. I changed exception return to B . From that I could narrow it down.
Thanks for reading!
To be sure that uboot isn't the problem I tried with the same version you use on I.mx8m. It doesn't support my board so I only tried with top layer , u-boot.itb . It boots to exception. Iam thinking if the offending call is the first one which allocates ram dynamically. That would point to permission problem and or problem with the defined system ram. Bootm takes the el to el2.
To be continued..
Michael
To be sure that uboot isn't the problem I tried with the same version you use on I.mx8m. It doesn't support my board so I only tried with top layer , u-boot.itb . It boots to exception. Iam thinking if the offending call is the first one which allocates ram dynamically. That would point to permission problem and or problem with the defined system ram. Bootm takes the el to el2.
To be continued..
I gave this a second thought. I doubt permission error. RISC OS is started in the same way and works just fine. I would appreciate any thoughts from Stefan , why cpus[id].construct(id, _global_work_list); can produce a exception. I can't find it.
Michael
Hi Michael,
I just answered to you in the IRC channel. I could imagine that access to the GIC is the actual problem, because this is done in _arch_init() inside of the Cpu constructor.
Can you confirm, that you can proceed at least behind the Cpu construction if you uncomment the line:
repos/base-hw/src/core/spec/arm_v8/kernel/cpu.cc:20
or not?
Best regards Stefan
On Tue, Nov 10, 2020 at 10:06:13AM +0000, Michael Grunditz wrote:
To be sure that uboot isn't the problem I tried with the same version you use on I.mx8m. It doesn't support my board so I only tried with top layer , u-boot.itb . It boots to exception. Iam thinking if the offending call is the first one which allocates ram dynamically. That would point to permission problem and or problem with the defined system ram. Bootm takes the el to el2.
To be continued..
I gave this a second thought. I doubt permission error. RISC OS is started in the same way and works just fine. I would appreciate any thoughts from Stefan , why cpus[id].construct(id, _global_work_list); can produce a exception. I can't find it.
Michael
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
On Tue, 10 Nov 2020 at 10:40, Stefan Kalkowski stefan.kalkowski@genode-labs.com wrote:
Hi Michael,
I just answered to you in the IRC channel. I could imagine that access to the GIC is the actual problem, because this is done in _arch_init() inside of the Cpu constructor.
Can you confirm, that you can proceed at least behind the Cpu construction if you uncomment the line:
repos/base-hw/src/core/spec/arm_v8/kernel/cpu.cc:20
or not?
Not.. I have checked all related constructors , and non seems to get called. I somewhat suspect cpu constructor isn't called.
MIchael
Hi,
On Tue, Nov 10, 2020 at 12:21:50PM +0000, Michael Grunditz wrote:
On Tue, 10 Nov 2020 at 10:40, Stefan Kalkowski stefan.kalkowski@genode-labs.com wrote:
Hi Michael,
I just answered to you in the IRC channel. I could imagine that access to the GIC is the actual problem, because this is done in _arch_init() inside of the Cpu constructor.
Can you confirm, that you can proceed at least behind the Cpu construction if you uncomment the line:
repos/base-hw/src/core/spec/arm_v8/kernel/cpu.cc:20
or not?
Not.. I have checked all related constructors , and non seems to get called. I somewhat suspect cpu constructor isn't called.
To be really sure, that the constructor does not even get called, you might derive the Kernel::Cpu class from a Dummy class that prints something in its contructor. Of course, it should be the first class the Cpu class inherits from.
If the (hardware-)exception is really not caused inside the constructor, but before the constructor call, then you would be right and it has to do with the actual memory access for the object creation. The Cpu objects are constructed using the Genode::Constructible class, which contains a static char array as placeholder for the object memory. That means it is actually no dynamically allocated memory but already part of core's ELF sections. Therefore, it might be useful to investigate the linking address you are using for the whole image, and maybe to change that. Another reason might be some alignment constraints? To be really sure, what is going on, you could temporarily change the exception vector in file 'repos/base-hw/src/core/spec/arm_v8/exception_vector.s' at the very beginning to, e.g.:
.section .text.crt0
.rept 16 mrs x0, elr_el1 mrs x1, spsr_el1 adr x2, . and x2, x2, #0xf80 bl kernel .balign 128 .endr
And change the function kernel() to something like:
extern "C" void kernel(void * ip, void * spsr, void * off, void * esr_el1) { Genode::raw("ip=", ip, " spsr=", spsr, " exc_off=", off, " esr_el1=", esr_el1); }
Then the outcome of the first printing would be quite interesting to know.
Regards Stefan
MIchael
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
On Tue, 10 Nov 2020 at 13:24, Stefan Kalkowski stefan.kalkowski@genode-labs.com wrote:
Hi,
On Tue, Nov 10, 2020 at 12:21:50PM +0000, Michael Grunditz wrote:
On Tue, 10 Nov 2020 at 10:40, Stefan Kalkowski stefan.kalkowski@genode-labs.com wrote:
Hi Michael,
I just answered to you in the IRC channel. I could imagine that access to the GIC is the actual problem, because this is done in _arch_init() inside of the Cpu constructor.
Can you confirm, that you can proceed at least behind the Cpu construction if you uncomment the line:
repos/base-hw/src/core/spec/arm_v8/kernel/cpu.cc:20
or not?
Not.. I have checked all related constructors , and non seems to get called. I somewhat suspect cpu constructor isn't called.
To be really sure, that the constructor does not even get called, you might derive the Kernel::Cpu class from a Dummy class that prints something in its contructor. Of course, it should be the first class the Cpu class inherits from.
If the (hardware-)exception is really not caused inside the constructor, but before the constructor call, then you would be right and it has to do with the actual memory access for the object creation. The Cpu objects are constructed using the Genode::Constructible class, which contains a static char array as placeholder for the object memory. That means it is actually no dynamically allocated memory but already part of core's ELF sections. Therefore, it might be useful to investigate the linking address you are using for the whole image, and maybe to change that. Another reason might be some alignment constraints? To be really sure, what is going on, you could temporarily change the exception vector in file 'repos/base-hw/src/core/spec/arm_v8/exception_vector.s' at the very beginning to, e.g.:
.section .text.crt0
.rept 16 mrs x0, elr_el1 mrs x1, spsr_el1 adr x2, . and x2, x2, #0xf80 bl kernel .balign 128 .endr
And change the function kernel() to something like:
extern "C" void kernel(void * ip, void * spsr, void * off, void * esr_el1) { Genode::raw("ip=", ip, " spsr=", spsr, " exc_off=", off, " esr_el1=", esr_el1); }
Then the outcome of the first printing would be quite interesting to know.
Regards Stefan
Kernel: ip=0xffffffc00008ed60 spsr=0x600003c5 exc_off=0x200 esr_el1=0xffffffe02ff22000
Going to look up that esr.
On Tue, Nov 10, 2020 at 01:59:42PM +0000, Michael Grunditz wrote:
Another reason might be some alignment constraints? To be really sure, what is going on, you could temporarily change the exception vector in file 'repos/base-hw/src/core/spec/arm_v8/exception_vector.s' at the very beginning to, e.g.:
.section .text.crt0
.rept 16 mrs x0, elr_el1 mrs x1, spsr_el1 adr x2, . and x2, x2, #0xf80 bl kernel .balign 128 .endr
And change the function kernel() to something like:
extern "C" void kernel(void * ip, void * spsr, void * off, void * esr_el1) { Genode::raw("ip=", ip, " spsr=", spsr, " exc_off=", off, " esr_el1=", esr_el1); }
Then the outcome of the first printing would be quite interesting to know.
Regards Stefan
Kernel: ip=0xffffffc00008ed60 spsr=0x600003c5 exc_off=0x200 esr_el1=0xffffffe02ff22000
Ok, the first three arguments are meaningful, and you can check the ip with you core binary. The core binary with debug information can be found in your build directory under 'var/run/[run-script-name].core'
The ESR_EL1 argument is wrong. I forgot it in the assembler sippet above. The complete exception vector should be:
.section .text.crt0
.rept 16 mrs x0, elr_el1 mrs x1, spsr_el1 mrs x3, esr_el1 adr x2, . and x2, x2, #0xf80 bl kernel .balign 128 .endr
Sorry, for the inconvenience, I'm afraid you have to give it a second try.
Regards Stefan
Going to look up that esr.
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
On Tue, 10 Nov 2020 at 14:24, Stefan Kalkowski stefan.kalkowski@genode-labs.com wrote:
On Tue, Nov 10, 2020 at 01:59:42PM +0000, Michael Grunditz wrote:
Another reason might be some alignment constraints? To be really sure, what is going on, you could temporarily change the exception vector in file 'repos/base-hw/src/core/spec/arm_v8/exception_vector.s' at the very beginning to, e.g.:
.section .text.crt0
.rept 16 mrs x0, elr_el1 mrs x1, spsr_el1 adr x2, . and x2, x2, #0xf80 bl kernel .balign 128 .endr
And change the function kernel() to something like:
extern "C" void kernel(void * ip, void * spsr, void * off, void * esr_el1) { Genode::raw("ip=", ip, " spsr=", spsr, " exc_off=", off, " esr_el1=", esr_el1); }
Then the outcome of the first printing would be quite interesting to know.
Regards Stefan
Kernel: ip=0xffffffc00008ed60 spsr=0x600003c5 exc_off=0x200 esr_el1=0xffffffe02ff22000
Ok, the first three arguments are meaningful, and you can check the ip with you core binary. The core binary with debug information can be found in your build directory under 'var/run/[run-script-name].core'
The ESR_EL1 argument is wrong. I forgot it in the assembler sippet above. The complete exception vector should be:
.section .text.crt0
.rept 16 mrs x0, elr_el1 mrs x1, spsr_el1 mrs x3, esr_el1 adr x2, . and x2, x2, #0xf80 bl kernel .balign 128 .endr
Sorry, for the inconvenience, I'm afraid you have to give it a second try.
Kernel: ip=0xffffffc00008ed58 spsr=0x600003c5 exc_off=0x200 esr_el1=0x96000045
Thanks
On Tue, 10 Nov 2020 at 14:32, Michael Grunditz michael.grunditz@gmail.com wrote:
On Tue, 10 Nov 2020 at 14:24, Stefan Kalkowski stefan.kalkowski@genode-labs.com wrote:
On Tue, Nov 10, 2020 at 01:59:42PM +0000, Michael Grunditz wrote:
Another reason might be some alignment constraints? To be really sure, what is going on, you could temporarily change the exception vector in file 'repos/base-hw/src/core/spec/arm_v8/exception_vector.s' at the very beginning to, e.g.:
.section .text.crt0
.rept 16 mrs x0, elr_el1 mrs x1, spsr_el1 adr x2, . and x2, x2, #0xf80 bl kernel .balign 128 .endr
And change the function kernel() to something like:
extern "C" void kernel(void * ip, void * spsr, void * off, void * esr_el1) { Genode::raw("ip=", ip, " spsr=", spsr, " exc_off=", off, " esr_el1=", esr_el1); }
Then the outcome of the first printing would be quite interesting to know.
Regards Stefan
Kernel: ip=0xffffffc00008ed60 spsr=0x600003c5 exc_off=0x200 esr_el1=0xffffffe02ff22000
Ok, the first three arguments are meaningful, and you can check the ip with you core binary. The core binary with debug information can be found in your build directory under 'var/run/[run-script-name].core'
The ESR_EL1 argument is wrong. I forgot it in the assembler sippet above. The complete exception vector should be:
.section .text.crt0
.rept 16 mrs x0, elr_el1 mrs x1, spsr_el1 mrs x3, esr_el1 adr x2, . and x2, x2, #0xf80 bl kernel .balign 128 .endr
Sorry, for the inconvenience, I'm afraid you have to give it a second try.
Kernel: ip=0xffffffc00008ed58 spsr=0x600003c5 exc_off=0x200 esr_el1=0x96000045
Kernel: ip=0xffffffc00008ed60 spsr=0x600003c5 exc_off=0x200 esr_el1=0x96000045 Kernel: ip=0xffffffc00008ed60 spsr=0x600003c5 exc_off=0x280 esr_el1=0x96000045 Kernel: ip=0xffffffc00008ed60 spsr=0x600003c5 exc_off=0x300 esr_el1=0x96000045 Kernel: ip=0xffffffc00008ed60 spsr=0x600003c5 exc_off=0x380 esr_el1=0x96000045 Kernel: ip=0xffffffc00008ed60 spsr=0x600003c5 exc_off=0x400 esr_el1=0x96000045 Kernel: ip=0xffffffc00008ed60 spsr=0x600003c5 exc_off=0x480 esr_el1=0x96000045 Kernel: ip=0xffffffc00008ed60 spsr=0x600003c5 exc_off=0x500 esr_el1=0x96000045 Kernel: ip=0xffffffc00008ed60 spsr=0x600003c5 exc_off=0x580 esr_el1=0x96000045 Kernel: ip=0xffffffc00008ed60 spsr=0x600003c5 exc_off=0x600 esr_el1=0x96000045 Kernel: ip=0xffffffc00008ed60 spsr=0x600003c5 exc_off=0x680 esr_el1=0x96000045 Kernel: ip=0xffffffc00008ed60 spsr=0x600003c5 exc_off=0x700 esr_el1=0x96000045 Kernel: ip=0xffffffc00008ed60 spsr=0x600003c5 exc_off=0x780 esr_el1=0x96000045
< big cut>
The problem is hopefully solved
The problem was the _arch_init code that does gic code. I was unfortunate enough to do late night hacking , and in vane and desperation put in a crash into gicv3.cc :/
Anyway , big thanks for all help , and the pointer to _arch_init. Also the fact that I now know how to get a dump from genode..
Will be very useful later on!
Michael
-
Michael Grunditz -
Stefan Kalkowski