[U-Boot] [PATCH 0/3] imx: bootaux elf firmware support

[Marek Vasut]

On 04/04/2017 12:42 AM, Stefan Agner wrote:
> On 2017-04-03 15:07, Marek Vasut wrote:
>> On 04/03/2017 11:36 PM, Stefan Agner wrote:
>>> Hi Lukasz,
>>>
>>> On 2017-04-03 04:20, Lukasz Majewski wrote:
>>>> Hi Stefan,
>>>>
>>>> Thanks for your patch. Please allow me to share some ideas for
>>>> improvements.
>>>>
>>>>> From: Stefan Agner <stefan.agner at toradex.com>
>>>>>
>>>>> This patchset enables to boot elf binaries on secondary Cortex-M
>>>>> class cores available on i.MX 6SoloX/7Solo/7Dual. This makes
>>>>> handling and loading firmwares much more convinient since all
>>>>> information where the firmware has to be loaded to is contained in
>>>>> the elf headers. A typical usage looks like this:
>>>>>
>>>>>   Colibri iMX7 # tftp ${loadaddr} firmware.elf && bootaux ${loadaddr}
>>>>>   Using FEC0 device
>>>>>   TFTP from server 192.168.10.1; our IP address is 192.168.10.2
>>>>>   Filename 'firmware.elf'.
>>>>>   Load address: 0x80800000
>>>>>   Loading: ##################################################  88.3
>>>>> KiB 5.4 MiB/s
>>>>>   done
>>>>>   Bytes transferred = 90424 (16138 hex)
>>>>>   ## Starting auxiliary core at 0x1FFF8311 ...
>>>>>   Colibri iMX7 #
>>>>
>>>> I can find some other platforms (not only IMX), which would benefit
>>>> from this code - the generic 'bootaux' command.
>>>>
>>>> One good example would to allow multiple binaries for different SoC
>>>> Cores (e.g. 2x Cortex-A8) to be loaded and started by u-boot.
>>>>
>>>> Hence, I'm wondering if you could make those patches usable for other
>>>> platforms as well?
>>>
>>> I don't think that this is a good idea. bootaux is meant for auxiliary
>>> cores, which often use a different architecture and are not cache
>>> coherent (hence the cache flushes).
>>>
>>> On SMP systems the main operating system normally starts the secondary
>>> core. Otherwise, if you want to run them separately using U-Boot, maybe
>>> a new command such as bootsmp would be more suited.
>>>
>> Admitedly, I didn't look at the patch, but if you want to boot ad-hoc
>> cores, you can very well also boot secondary cores on the current CPU
>> complex with the same command. Why not ?
> 
> Sure, it could be done. I just feel it is not the right design.
> 
> Auxiliary cores have usually a different view to memory, this is why I
> had to add the get_host_mapping callback in the elf loader code to let
> architecture dependent code translate to host addresses. SMP systems
> don't need that.
> 
> Also flush caches is not necessary on some cache coherent CPU's
> (depending on how your cache coherence between I and D cache looks
> like).

So SMP is just a reduced special-case of this , yes ?

> Creating a new command like bootaux comes with very few overhead.

The overhead is the new command, we already have many ad-hoc commands.

> This are the reasons why I feel creating a new command for a SMP boot
> case makes more sense. We can still reuse functions which are very
> similar by moving them into some common location, where it makes sense.
> 
>>
>> Also, I think this might come useful when booting stuff like "Altera
>> Sparrow" ...
> 
> I am not familiar with that architecture, what kind of core does it
> provide which needs to be booted by U-Boot?

The secondary ARM core in the SoCFPGA C-A9 complex or Nios2 core in the
FPGA.

-- 
Best regards,
Marek Vasut