cpu id for big cpu 0x400

[Michael Grunditz]

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?


Michael