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

[Stefan Agner]

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).

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

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?

--
Stefan