Andre,
I took some time to answer because I documented myself further. I like to be
precise.
You are right, this is the bit I missed: the platform seeks for a sd card to
boot before looking for the on board NAND.
So, from here, I can add my bootloader on the sdcard and let the fun start (no
need to flash the NAND).
I have looked at the u-boot code already, and I understand pretty well how this
SoC behaves now.
As for the IPIs, thanks, I will ditch the msgbox altogether and use the GIC
only.
Super, Andre, thanks again.
Cheers
--
Mark
21.09.2016, 15:03, "Andre Przywara" <andre.przyw...@arm.com>:
> 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.
--
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.
