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

[Marek Vasut <marex@denx.de>]

On 04/04/2017 02:02 AM, Stefan Agner wrote:
[...]
>>>> 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.

Or you can abstract things out ?

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

Based on that discussion, I only see that noone opposed, but I don't see
any agreement.

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

I thought this command was starting the core by loading data to RAM ,
not flash ?

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

We always try to avoid one-off hacks, so it's not weird. I still don't
quite understand how it is a problem to abstract things out . I am not
asking you to support CA, but to avoid CM specific implementation which
cannot be extended to support CA or even MIPS/Nios2/etc .

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

Uh, why, that does not make any sense to me. Both the random core in
FPGA and the secondary CA9 core have almost the same bringup sequence.
What is so different about this stuff ?

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

So we already accepted a command which has shit commandline semantics
and we're stuck with it , hrm. You can always specify a default core
index for those two iMX boards and it's done. Or just fix the semantics
in their default environment, which is not awesome, but I doubt this is
wildly used yet.

-- 
Best regards,
Marek Vasut