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

[Stefan Agner]

On 2017-04-03 16:34, Marek Vasut wrote:
> 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 ?

Yeah, I guess you can get away with dummy callback implementation and a
performance hit due to cash flushes.

> 
>> Creating a new command like bootaux comes with very few overhead.
> 
> The overhead is the new command, we already have many ad-hoc commands.
> 

Agreed, and I really wished that this got discussed when that command
initially got added. I brought it up back then...
https://lists.denx.de/pipermail/u-boot/2016-January/240323.html

It seemed to be acceptable to just add this ad hoc command, with some
"random binary format" support back then... Ok, it is not entirely
random, since it is the format of a binary how it ends up in
microcontrollers execute in place flash (stack pointer and reset vector
are the two first words).... However, making this ad hoc command now
generic really feels weird to me, since we would end up supporting that
format for A class CPUs etc... bootaux is really suited for auxiliary
M-class cores on ARM, as it is right now. Maybe we should have named it
bootm ;-)

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

In my thinking, the Nios2 core seems like such a remote processor well
suited for the bootaux command. For the secondary A9, I would create a
new command.

If we want to support the two with the same command, we already have a
first problem: How do we address them? Of course, we could add just a
index or something, but this would already break backward compatibility
of the bootaux command.

--
Stefan