# Joerg Sonnenberger 2007-07-13:
> On Fri, Jul 13, 2007 at 09:56:51AM +0200, Manuel Bouyer wrote:
> > On Fri, Jul 13, 2007 at 08:44:31AM +0200, Martin Husemann wrote:
> > > On Fri, Jul 13, 2007 at 12:07:01AM +0000, Arnaud Lacombe wrote:
> > > > Would it be ok to add an Intel HEX[1] parser to firmload(9) ?
> > > 
> > > I'd prefer to have a userland converter and just put the binary image
> > > there. Would there be any downsides to that aproach?
> > 
> > The HEX format allows to have different memory regions in the same
> > file, it can't be converted to a simple binary image (it can be something
> > like a sparse file). This could be emulated by calling firmload() for
> > each memory region, but this probably mean you have the firmware
> > split in several files ...
> 
> I still think that putting the parser in the kernel is the wrong
> approach. But having a small header that can be parsed by firmload would
> be fine with me. A few restrictions are IMO perfectly fine like
> non-overlapping segments, strict ordering, total size in the header etc.
> That makes it also a lot less worrysome for the kernel. If we want such
> multi-segment support the next question would be whether the firmware
> interface should be extended accordingly so that the image itself is
> loaded and the kernel doesn't have to allocate the full range to put the
> few sparse parts inside.

From a quick look, the kernel interface as-is cannot easily deal with
multi-segment images. It should be extended if and only if there's
considerable amount of devices that require it. If OTOH we're talking
about a few isolated cases I think it's fine for them to have private
ways of firmware loading.

If it turns out we need generic support for multi-segment firmware
images, I'd agree with Herb in that in-kernel S-Record parser is no
big deal -- it's just a couple of lines of code. I'd prefer to avoid
Intel HEX, it's somewhat bloated (supports weird addressing modes)
and its use tends to come with byteorder doubts associated IMO.

	-- Jachym