[U-Boot] [PATCH v3 06/20] common: Generic firmware loader for file system

[Lukasz Majewski <lukma@denx.de>]

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) to
any FPGA/SoC/whatever.

I do have in mind the ADI's SHARC DSP cores...

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

> 
> > 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 cannot help much with review/design phase since I know very
> > little on this particular Altera (up.. sorry Intel) solution.[...]




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