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.

Joerg