From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lukasz Majewski Date: Wed, 5 Apr 2017 21:54:23 +0200 Subject: [U-Boot] [PATCH 0/3] imx: bootaux elf firmware support In-Reply-To: <20170405191023.GG19897@bill-the-cat> References: <20170329195827.6217-1-stefan@agner.ch> <20170403132024.514307fd@jawa> <0d0cd2362362fb2029e46821678f2f8b@agner.ch> <20170404102318.68ba4166@jawa> <20170405171506.64c9ec8e@jawa> <4b627baf53db77c1ef85a916e986e148@agner.ch> <20170405191023.GG19897@bill-the-cat> Message-ID: <20170405215423.085a8062@jawa> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Wed, 5 Apr 2017 15:10:23 -0400 Tom Rini wrote: > On Wed, Apr 05, 2017 at 11:20:43AM -0700, Stefan Agner wrote: > > On 2017-04-05 08:15, Lukasz Majewski wrote: > > > Hi Stefan, > > > > > >> On 2017-04-04 01:23, Lukasz Majewski wrote: > > >> > Hi Stefan, > > >> > > > >> >> 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). > > >> > > > >> > I do remember, that I saw similar "tiny" patch to add "just > > >> > one" ad-hoc command to do the same (conceptually) for TI SoC > > >> > floating on the u-boot mailing list. > > >> > > > >> > Please correct me if I'm wrong, but bootaux is IMX specific > > >> > and does work, which very likely, will be also required by > > >> > other SoC vendors (TI's Sitara is also equipped with Cortex-M4 > > >> > and PRUSS). > > >> > > >> bootaux is currently IMX specific, and its currently supported > > >> binary format is M-class specific. > > >> > > >> > > > >> > Unification of such effort can save us all a lot of trouble in > > >> > a very near future. > > >> > > >> In OSS, you do not develop for the future. It gets developed > > >> when its here. > > > > > > I cannot agree here. When you perceive threat then you prepare > > > for it. > > > > > >> > > >> > > > >> >> > > >> >> On SMP systems the main operating system normally starts the > > >> >> secondary core. > > >> > > > >> > I think that there are some conceptual similarities between > > >> > loading code to SMP core and Cortex M3. Of course some > > >> > "tweaks" would be needed. > > >> > > > >> > > >> There are conceptual similarities between a car and a truck, > > >> still, they are likely manufactured in a different assembly > > >> line, probably by a different producer. > > >> > > >> I guess in the end it really depends on where you draw the line: > > >> There are differences between loading code which will get > > >> executed by the primary code, loading code to execute explicitly > > >> on a SMP core, and loading code to execute on a remote processor. > > >> > > >> The first case is already well supported, and we need to keep > > >> support backward compatibility. > > >> > > >> The second case, IMHO, is a somewhat silly case: A SMP system > > >> usually gets driven by a single OS image, and that OS makes sure > > >> to initialize the cores (maybe with the help of firmware, such > > >> as the PSCI interface on ARM). There is no need for a boot > > >> loader command to execute a image on a secondary core > > >> explicitly... > > > > > > I do understand (and agree) with your point with SMP. > > > > > > But, I do know at least one use case when somebody would like to > > > start two binaries (those are bare metal programs, taking care of > > > SoC setup, IPC, etc). > > > > > > And maybe Linux with some FPGA based IP block already configured > > > in u-boot. > > > > > >> > > >> The third case is probably a case where we could start think > > >> about unification efforts. > > >> > > >> > > >> >> Otherwise, if you want to run them separately using U-Boot, > > >> >> maybe a new command such as bootsmp would be more suited. > > >> > > > >> > Hmm - I do think that it would be too much: > > >> > > > >> > - bootm for generic single core > > >> > - bootaux for IMX > > >> > - bootsmp for SMP (on IMX/TI/RK?) > > >> > - boot?? for ?? > > >> > > >> There is at least also bootz and bootelf. > > > > > > I will reply to the other thread regarding bootelf. > > > > > >> > > >> > > > >> > I would like to avoid adding new commands for doing > > >> > conceptually the same work. > > >> > > > >> > Even better, we could extend bootm to support the "multi > > >> > binary" case too, but IMHO it would be also correct to have > > >> > "bootaux" to handle generic binaries loading. > > >> > > > >> >> > > >> >> > > > >> >> >> > > >> >> >> Note that the bootaux command retrieved the entry point > > >> >> >> (PC) from the elf binary. > > >> >> > > > >> >> > Could you make this code flexible enough to handle not only > > >> >> > elf binaries, but also other data (e.g. FPGA bitstreams)? > > >> >> > > >> >> The code of bootaux is rather small, I don't see much value > > >> >> into stuff boot code for other peripherals into it. > > >> > > > >> > But I'm not asking to write support for other vendor's SoC/use > > >> > cases. > > >> > > > >> > I'm just wondering if you could write generic command > > >> > (framework) to support this use case and as an example add > > >> > support for your IMX's Cortex-M3/4. > > >> > > > >> > > >> Sure, mv arch/arm/imx-common/imx_bootaux.c cmd/, there is the > > >> framework :-) > > >> > > >> But this promotes the M class specific binary format to a generic > > >> format supported for all cores. > > >> > > >> > We would kill two birds with one stone - IMX is supported from > > >> > the very beginning and we do have generic code to extend it by > > >> > other vendors. > > >> > > > >> >> I don't know how FPGA > > >> >> bistream loading typically works, but I guess it is quite > > >> >> different from loading a firmware into RAM/SRAM and flush > > >> >> caches... > > >> > > > >> > FPGA quirks would be handled in arch/SoC specific code. > > >> > > > >> >> > > >> >> I am not against reuse and unification, I just feel that this > > >> >> is not really a case where we gain much. > > >> > > > >> > With generic "bootaux/bootm" command we can point other > > >> > developers who would like to add such booting code to the > > >> > already available framework. > > >> > > > >> > Also, we would prevent other "ad-hoc" commands adding to > > >> > u-boot. > > >> > > > >> > > >> Extending bootm does not seem like a good idea. bootm is already > > >> rather complex, making it even more complex by supporting the > > >> auxiliary core case seems really not work well. > > >> > > >> Also, bootm supports lots of features which you probably never > > >> would use or test on a remote core (e.g. initramfs etc...) > > >> > > >> >> > > >> >> > > > >> >> > Maybe it would better to: > > >> >> > ------------------------- > > >> >> > > > >> >> > Embrace those binaries into FIT file (*.itb)? And allow > > >> >> > multiple binaries loading? I'm thinking of work similar to > > >> >> > one already did by Andre Przywara for SPL: > > >> >> > > > >> >> > "[PATCH v3 00/19] SPL: extend FIT loading support" posted on > > >> >> > 31.03.2017? > > >> >> > > > >> >> > In that way we would "open" many new use cases, and other > > >> >> > platforms (e.g. FPGA's, TI, etc) could benefit from it. > > >> >> > One solid use case is to load different Linux binaries > > >> >> > (or/and bare metal programs) to different SoC cores. > > >> >> > > > >> >> > The "meta data" (i.e. load address, data type, description), > > >> >> > could be extracted from the FIT format (the code is already > > >> >> > in u-boot). > > >> >> > > > >> >> > IMHO, this is very generic approach. > > >> >> > > >> >> I did some experiments with using FIT images for auxiliary > > >> >> core firmware, however, it did not add a lot of advantage > > >> >> over using elf: > > >> >> http://git.toradex.com/cgit/u-boot-toradex.git/commit/?h=2015.04-toradex-next&id=d1d416f272e840e8139aec911f89a70fe5523eb2 > > >> > > > >> > Unfortunately, not all use cases allow using ELF format. FIT > > >> > gives more flexibility: > > >> > > > >> > - ./doc/README.dfutftp -> different images loading > > >> > > > >> > - Andre's patch to load multiple binaries in SPL - [PATCH v3 > > >> > 00/19] SPL: extend FIT loading support" > > >> > > > >> > > >> Are flexible, but very much U-Boot specific. And much more > > >> complex to support. > > >> > > >> >> > > >> >> Firmwares are already built and available in the elf file > > >> >> format. The Linux remoteproc framework, which is meant to > > >> >> handle this kind of cores too, supports elf firmware loading > > >> >> too, so supporting elf in U-Boot too is a nice alignment. > > >> >> Also using FIT adds an additional step when building firm > > >> >> wares... > > >> > > > >> > But this is all OK. > > >> > > > >> > The ELF binary would be wrapped in FIT (with e.g. "elf" > > >> > property, even 1 to 1 mapping). Then the 'bootaux/bootm' could > > >> > parse ELF (which is also generic). And then some "IMX > > >> > specific" (arch/SoC) code would be executed. > > >> > > > >> > > >> So we go from a nacked binary loaded directly to the place it > > >> has been linked to, to a double wrapped firmware file...? > > > > > > We would have elf binary file embedded into FIT file, these would > > > bring flexibility. > > > > > > FIT support is in place (u-boot/spl). > > > > > > In such a way you can use any binary in any format. > > > > > > But I must admit that we are going off-topic here..... > > > > > >> > > >> Not sure if user will appriciate that extra work and boot time. > > >> And developers the extra code. > > >> > > >> Maybe in a perfect world that just works, because you know, FIT > > >> is generic, and elf is generic... But that is just not how it > > >> works in practice. The existing FIT code is rather complex, > > >> supports lots of corner cases. The elf code supports different > > >> header types... Loading the elf sections (which use M4 specific > > >> addressing) needs address translation to get to suitable host > > >> addresses... > > > > > > Maybe I'm an idealist :-) > > > > > > One analogy comes to my mind between linux and u-boot. > > > > > > The proliferation of u-boot commands and linux board files. Why > > > Linux spend tremendous resources to remove board files and switch > > > to device tree? > > > > > > > I argue that is the right way of doing it: Do ad-hoc solutions, > > whatever makes sense, and once you understand the full breath of > > design space it is much easier to build a suitable framework. At > > that point, do the refactoring and build that suitable framework. > > > > If you design a framework without the understanding of the whole > > design space, you will end up with something which does not work > > well and needs lots of work-arounds etc... > > > > Of course, it is a bit different since both examples have outside > > facing impact (change to device tree as well as changes to U-Boot > > commands). > > To ask the silly question, isn't cmd/remoteproc.c part of the proper > framework for a solution here? > Yes, this seems like a solution :-). Thanks for pointing out. 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: wd at denx.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: