From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lukasz Majewski Date: Sun, 29 Oct 2017 23:57:13 +0100 Subject: [U-Boot] [PATCH v3 06/20] common: Generic firmware loader for file system In-Reply-To: <95a9e5a5-abdc-926f-13af-d31b53c12631@denx.de> References: <1507882137-27841-1-git-send-email-tien.fong.chee@intel.com> <1507882137-27841-7-git-send-email-tien.fong.chee@intel.com> <26f9b350-3f78-d2f0-a49b-b2a76d4128c8@kernel.org> <1508740671.3650.6.camel@intel.com> <20171026145101.4395505c@jawa> <1509096198.2931.15.camel@intel.com> <20171027123553.237aa07e@jawa> <20171028234350.4560ad94@jawa> <95a9e5a5-abdc-926f-13af-d31b53c12631@denx.de> Message-ID: <20171029235713.3a1b7472@jawa> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: u-boot@lists.denx.de Hi Marek, > On 10/28/2017 11:43 PM, Lukasz Majewski wrote: > > Hi Marek, > > > >> On 10/27/2017 12:35 PM, Lukasz Majewski wrote: > >> [...] > >>>>>>>>>  common/Makefile   |   2 + > >>>>>>>>>  common/load_fs.c  | 163 > >>>>>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >>>>>>>>>  include/load_fs.h |  40 ++++++++++++++ > >>>>>>>>>  3 files changed, 205 insertions(+) > >>>>>>>>>  create mode 100644 common/load_fs.c > >>>>>>>>>  create mode 100644 include/load_fs.h > >>>>>>>> There is alot of change here and the commit message doesn't > >>>>>>>> tell > >>>>>>>> me anything! Please describe, in detail, what your patch is > >>>>>>>> doing. > >>>>>>>> > >>>>>>>> Also you need to include more people in the review path for > >>>>>>>> this > >>>>>>>> patch. > >>>>>> These are the code factored out from splash loader, contains > >>>>>> some common functions which can be used by other file system > >>>>>> loader such as > >>>>>> fpga loadfs. > >>>>> Would it be possible to provide ./doc entry to explain how one > >>>>> can use > >>>>> this set of tools (splash/loadfs loaders) ? > >>>>> > >>>> Sure. I will provide a./doc or comment in next version. > >>>> Basically, the idea is factoring out the common code which > >>>> specific handlle image in file format loading from flash to > >>>> target(memory/device) between splash loader and fpga loadfs. So, > >>>> you will see i have declared a few weak functions, which is used > >>>> for defined speficic handling algorithm such as get_file, and > >>>> fs_loading. > >>>> > >>>> Initially, my plan is creating a more generic function name and > >>>> geneirc file name, then replacing those splash_loader fs at > >>>> separate patch set. > >>>> > >>>> Now, i am working directly on splash loader. Anyway, i also like > >>>> more discussion and good comments while i am working on it. > >>> > >>> I've asked for a documentation, since I do have one idea in the > >>> back of my head. > >>> > >>> I'm wondering if other SoCs could benefit from this solution? For > >>> example when we treat the FPGA as a DSP processor which needs to > >>> have bitstream ( or better firmware ) loaded to some physical > >>> address. I'm also wondering if your work would allow for > >>> start/stop of the code execution? > >> > >> This is supposed to be a firmware loader (kind-of like the firmware > >> loader in Linux), > > > > So in principle I should be able to load any bitstream (firmware) > > Yes, using this framework. > > > to > > any FPGA/SoC/whatever. > > No, this part is up to you to implement. > > > I do have in mind the ADI's SHARC DSP cores... > > The part which calls the firmware loader API and pushes it into those > cores is up to you to implement. > > >> so I have no idea what you mean by "start/stop" > >> execution. > > > > Ok. This can be done in a separate driver. No issues with that. > > IMO it indeed should. Ok. > > >>> It would be best to have some kind of common code and extensions > >>> per soc/architecture. > >> > >> I can't see a usecase for that. > > > > The use case would be to reuse/tweak this code to be able to load > > firmware for the SHARC DSP processors. > > I think your driver will use the firmware loader indeed, but this > functionality you described would be part of some driver for that > hardware, not the FW loader. Unfortunately, there is no such "driver" available from the vendor - hence I'm poking around to see what can be "reused". 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: 488 bytes Desc: OpenPGP digital signature URL: