cpu id for big cpu 0x400

[Michael Grunditz]

In message <CAAqgp_Sj9Y=J=t22Vi1R9D765fjK7fJu3UX4szVzM8irO14A9g at mail.gmail 
.com>
          Michael Grunditz <michael.grunditz at gmail.com> wrote:

> On Thu, 19 Jan 2023 at 11:23, Stefan Kalkowski
> <stefan.kalkowski at 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.

-- 
Best regards,
Michael Grunditz

**  **