Hi Stefan,
> 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.ag...@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
I can only regret that this discussion did not happened then...
>
> 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 ;-)
Please refer to my reply to an earlier mail in this thread.
>
> >> 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
>
>
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
