Hi,

On 21/09/16 11:27, Mark L. wrote:
> Hi,
> 
> The plan:
> 1) erase && replace the bootloader with a custom one on a H3 SoC (much 
> simpler/faster/secure and fitting the need perfectly)
> 2) create a custom small OS, replacing the AMP default behavior with a SMP 
> one: basically matching the address spaces between cpus and just send the 
> other cores some work to do from cpu0 ( they won't have an operating system 
> and basically wait for CPU0 events -> hence the new bootloader as well).
> 
> Questions:
> 1) H3 datasheet: are all the registers there or are there some undocumented 
> ones? (to burn the new bootloader, that is critical)

Not everything is documented, but you can take a look at U-Boot, that
should cover everything you need.
But I wonder why you want to replace U-Boot in the first place, if you
disable PSCI (and UEFI) it shouldn't be in the way after you started
your OS. And although U-Boot is usually used with Linux, it is actually
OS agnostic, so launching "something else" from is definitely a
supported use case. AFAIK the arisc isn't used these days with an
upstream Linux software setup.

Also have you checked ar100-info [1]? That should give you the bare
minimum in terms of initialization to launch your custom code.

Rewriting a boot loader (which would involve DRAM initialization) is
pretty tedious and complicated, so I'd strongly recommend against it.

Also what do you mean exactly with "burn a bootloader"? On most
Allwinner boards we use upstream U-Boot exclusively (no Allwinner
provided code), so many people "burn" a boot loader already. Also you
can put it on an SD card, which I wouldn't exactly call "burning".

> 2) CPU IPIs: we have a msgbox on this platform according to the datasheet. 
> But how do you send a message from CPU0 to CPU3 or CPU2 to CPU1, without 
> interrupting the unconcerned cpus (respectively {CPU1,CPU2} and {CPU0,CPU3} )?
> Because the datasheet talks about user0 and user1 but no cpuIDs are involved 
> and it is not clear to me.

So since you mentioned the msgbox and AMP above, I take it you want to
have the OpenRISC and the ARM cores working together?
Using the msgbox you can only send messages from the ARM cores to the
OpenRISC and vice versa. Sending a message from ARM CPU0 to CPU1, for
instance, doesn't work this way (I tried this on the A64), at least you
won't see the IRQ.
But if you want to notify one ARM core from another, just use the GIC
and SGIs, you can target single cores or group of cores with this one.
If you target the OpenRISC, you can use the msgbox.
Targeting a specific ARM core from the OpenRISC is not easily possible,
AFAICT, since there is only one msgbox IRQ. You can set the affinity of
this IRQ to an ARM core, but this must be done from the ARM cores
beforehand and cannot be influenced from the OpenRISC (as the GIC isn't
accessible from the OpenRISC).

Cheers,
Andre.

[1] https://github.com/ssvb/ar100-info

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to