From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Agner Date: Mon, 03 Apr 2017 15:42:12 -0700 Subject: [U-Boot] [PATCH 0/3] imx: bootaux elf firmware support In-Reply-To: <15002942-54e4-2271-f88e-fe67e9892f7d@denx.de> References: <20170329195827.6217-1-stefan@agner.ch> <20170403132024.514307fd@jawa> <0d0cd2362362fb2029e46821678f2f8b@agner.ch> <15002942-54e4-2271-f88e-fe67e9892f7d@denx.de> Message-ID: <42b4c04248e2c10ed12a794913e0d428@agner.ch> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 >>>> >>>> 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