Hi
I am testing starting from the big cpu on rk3588. The cpu id is 0x400. Starting is fine up to core entry. But there it stops. EL switching works.
The question is , every other core is compared to NR_OF_CPUS, which is from 0 and up. What do I need to change?
Michael
( will try now with core 1 , since obvisually core 0 isn't set up so that el switching works. I still thinks we should do core init so that we get a common state , regardless how u-boot leaves us. )
On Tue, 17 Jan 2023 at 11:14, Michael Grunditz michael.grunditz@gmail.com wrote:
Hi
I am testing starting from the big cpu on rk3588. The cpu id is 0x400. Starting is fine up to core entry. But there it stops. EL switching works.
The question is , every other core is compared to NR_OF_CPUS, which is from 0 and up. What do I need to change?
Michael
( will try now with core 1 , since obvisually core 0 isn't set up so that el switching works. I still thinks we should do core init so that we get a common state , regardless how u-boot leaves us. )
I am happy to say that el switching from e2 to el1 now works for core 0! I am clearing all standard regs (including fp regs) and hcr_el2,cptr_el2 in crt0.S
Very happy!!
Hello Michael,
On Tue, Jan 17, 2023 at 11:14:52AM +0100, Michael Grunditz wrote:
Hi
I am testing starting from the big cpu on rk3588. The cpu id is 0x400. Starting is fine up to core entry. But there it stops. EL switching works.
I'm a bit puzzled what you mean exactly by "... fine up to core entry." In this case you do not mean CPU core, but Genode's core component entry, don't you?
The question is , every other core is compared to NR_OF_CPUS, which is from 0 and up. What do I need to change?
You have said cpu id is 0x400? Is this what `Cpu::current_core_id()` has returned? I'm wondering because the implementation should always return values below 256. Or do you mean the raw hardware value from register MPIDR? Could you please provide that register's value by printing `Cpu::Mpidr::read()`?
Actually, this function is meant to map the CPU topology to a continuous range of natural numbers beginning from zero.
Michael
( will try now with core 1 , since obvisually core 0 isn't set up so that el switching works. I still thinks we should do core init so that we get a common state , regardless how u-boot leaves us. )
This is what we try to do actually, but of course the environment bootstrap starts in depends on the state the bootloader has left us. The claim that for instance Linux kernel resets every possible system register isn't true either. We cannot forsee every potential hardware configuration, but of course things are getting more easy the more different SoC and boards are getting ported.
Regards Stefan
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
On Thu, 19 Jan 2023 at 11:23, Stefan Kalkowski stefan.kalkowski@genode-labs.com wrote:
Hello Michael,
On Tue, Jan 17, 2023 at 11:14:52AM +0100, Michael Grunditz wrote:
Hi
I am testing starting from the big cpu on rk3588. The cpu id is 0x400. Starting is fine up to core entry. But there it stops. EL switching works.
I'm a bit puzzled what you mean exactly by "... fine up to core entry." In this case you do not mean CPU core, but Genode's core component entry, don't you?
Yes ,I meant the jump to Genode core.
The question is , every other core is compared to NR_OF_CPUS, which is from 0 and up. What do I need to change?
You have said cpu id is 0x400? Is this what `Cpu::current_core_id()` has returned? I'm wondering because the implementation should always return values below 256. Or do you mean the raw hardware value from register MPIDR? Could you please provide that register's value by printing Cpu::Mpidr::read()`?
0x81000400 This was printed with error(). Genode::raw gives me an assert in lock.
Actually, this function is meant to map the CPU topology to a continuous range of natural numbers beginning from zero.
The thing is. U-boot starts at core 0x0. So in order to get to the big cpu I need to do psci to power it up. The big cpu starts at 0x400 ( from a psci point of view).
So I started the big cpu at the beginning. Every comparing is done with NR_OF_CPUS. which obvisually is starting from 0 and up. Correct me if I am wrong.
I actually didn't try the zeroing the regs when doing this. It could actually be the problem, since after starting a new core, that core needs some initial setup.
In riscos we have a function "init_arm" which does this. On rk3399 we switch to the big cpu right at the start. The cpu init in riscos is designed to work without uboot. riscos has been around for quite some time :) Originally it was a physical rom and definitely not with uboot.
This is what we try to do actually, but of course the environment bootstrap starts in depends on the state the bootloader has left us. The claim that for instance Linux kernel resets every possible system register isn't true either.
Sorry for being uneducated, in regards to the linux kernel. I like to be corrected :-)
We cannot forsee every potential hardware configuration, but of course things are getting more easy the more different SoC and boards are getting ported.
Ofcourse. Just thought that zeroing regs wouldn't hurt. Is it possible to override the start file in a soc tree?
Michael
In message <CAAqgp_Sj9Y=J=t22Vi1R9D765fjK7fJu3UX4szVzM8irO14A9g@mail.gmail .com> Michael Grunditz michael.grunditz@gmail.com wrote:
On Thu, 19 Jan 2023 at 11:23, Stefan Kalkowski stefan.kalkowski@genode-labs.com wrote:
Hello Michael,
On Tue, Jan 17, 2023 at 11:14:52AM +0100, Michael Grunditz wrote:
Hi
I am testing starting from the big cpu on rk3588. The cpu id is 0x400. Starting is fine up to core entry. But there it stops. EL switching works.
I'm a bit puzzled what you mean exactly by "... fine up to core entry." In this case you do not mean CPU core, but Genode's core component entry, don't you?
Yes ,I meant the jump to Genode core.
The question is , every other core is compared to NR_OF_CPUS, which is from 0 and up. What do I need to change?
You have said cpu id is 0x400? Is this what `Cpu::current_core_id()` has returned? I'm wondering because the implementation should always return values below 256. Or do you mean the raw hardware value from register MPIDR? Could you please provide that register's value by printing Cpu::Mpidr::read()`?
0x81000400 This was printed with error(). Genode::raw gives me an assert in lock.
Actually, this function is meant to map the CPU topology to a continuous range of natural numbers beginning from zero.
The thing is. U-boot starts at core 0x0. So in order to get to the big cpu I need to do psci to power it up. The big cpu starts at 0x400 ( from a psci point of view).
So I started the big cpu at the beginning. Every comparing is done with NR_OF_CPUS. which obvisually is starting from 0 and up. Correct me if I am wrong.
I actually didn't try the zeroing the regs when doing this. It could actually be the problem, since after starting a new core, that core needs some initial setup.
In riscos we have a function "init_arm" which does this. On rk3399 we switch to the big cpu right at the start. The cpu init in riscos is designed to work without uboot. riscos has been around for quite some time :) Originally it was a physical rom and definitely not with uboot.
This is what we try to do actually, but of course the environment bootstrap starts in depends on the state the bootloader has left us. The claim that for instance Linux kernel resets every possible system register isn't true either.
Sorry for being uneducated, in regards to the linux kernel. I like to be corrected :-)
We cannot forsee every potential hardware configuration, but of course things are getting more easy the more different SoC and boards are getting ported.
Ofcourse. Just thought that zeroing regs wouldn't hurt. Is it possible to override the start file in a soc tree?
I did some more printing and the cpuid is 0x4 when passed into the el2->el1 switch.
Maybe I should change number of cpus to 8, but not starting the others.
Hello Michael,
On Thu, Jan 19, 2023 at 01:33:57PM +0100, Michael Grunditz wrote:
I did some more printing and the cpuid is 0x4 when passed into the el2->el1 switch.
Maybe I should change number of cpus to 8, but not starting the others.
This is what I would expect, and should be correct.
Regards Stefan
On Thu, 19 Jan 2023 at 14:36, Stefan Kalkowski stefan.kalkowski@genode-labs.com wrote:
Hello Michael,
On Thu, Jan 19, 2023 at 01:33:57PM +0100, Michael Grunditz wrote:
I did some more printing and the cpuid is 0x4 when passed into the el2->el1 switch.
Maybe I should change number of cpus to 8, but not starting the others.
This is what I would expect, and should be correct.
Unfortunately it didn't help. I wonder, is it possible at all to boot up on the 5th cpu?
/MIchael
Hello Michael,
On Thu, Jan 19, 2023 at 12:54:30PM +0100, Michael Grunditz wrote:
In riscos we have a function "init_arm" which does this. On rk3399 we switch to the big cpu right at the start. The cpu init in riscos is designed to work without uboot. riscos has been around for quite some time :) Originally it was a physical rom and definitely not with uboot.
This is what we try to do actually, but of course the environment bootstrap starts in depends on the state the bootloader has left us. The claim that for instance Linux kernel resets every possible system register isn't true either.
Sorry for being uneducated, in regards to the linux kernel. I like to be corrected :-)
Hopefully, you didn't got me wrong. I did not want to teach nor correct you. I only wanted to contradict the impression that the ARMv8 initialization code in Genode is not agile with regard to different boot environments at all, but Linux on the other hand is doing "full initialization" (mentioned in a previous mail). Surely, we can always do better, but I sensed a black-and-white comparision here.
It would also be interesting to start Genode on an ARM board without u-boot, e.g. to decrease boot-time. However, till now we prefered convenience with regard to boot-media freedom etc. instead of handling the whole initialization on our own.
We cannot forsee every potential hardware configuration, but of course things are getting more easy the more different SoC and boards are getting ported.
Ofcourse. Just thought that zeroing regs wouldn't hurt. Is it possible to override the start file in a soc tree?
I do not stem against improvements of the CPU initialization, and I'm pretty glad about related patches in our issue tracker. Alternatively, it is of course always possible to replace, either crt0.s or high-level code in a SoC-specific repository.
Best regards Stefan
Michael
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
-
Michael Grunditz -
Stefan Kalkowski