Messages in this thread | | | Date | Fri, 6 Jun 2008 10:15:25 +0100 | From | Alan Cox <> | Subject | Re: [PATCH 00/18] firmware: moving drivers to request_firmware() |
| |
> * firmware should be field-replaceable, even if one was compiled in
If you want to replace it then put it in the file system. You've said binuntils isn't acceptable in your "vision" below so field replacing compiled in ones clearly is. It's a needless overcomplication.
> * the preferred form of firmware is one or more binary blobs, stored in > a regular [filesystem|git] binary file.
That depends on the firmware. In a few cases we even have firmware source in the tree.
> * in-tree firmwares should be stored in one or more binary files in the > tree, not in C source code or .ihex files. > > * when firmware is stored as binary blob, it is easier for > (1) vendor to replace,
Nope, they can't submit a diff to the tree except as an attachment which will be dropped if you do that.
> (2) developer/user to compare/verify using sha1,
sha1 doesn't appear to be totally secure for that purpose with a firmware block any more. Putting the sha1 in the header might be a good idea in some cases (eg DaveM wants to be sure precisely *which* tg3 firmware he loads)
> (3) does not require a C compiler or binutils to unpack
Why ? What is the usage scenario ? Vendor distributed firmware for PC class systems is going to be a deb or rpm that drops files into ../lib/firmware.
> Thus, if you are going to be touching the in-tree firmwares at all, it > doesn't make sense to convert from C source to any format other than > native binary.
You don't mean native binary either. Native binary on some of these devices is very strange indeed. Its simply bytes in various random formats for stuffing into the device in various random ways - that's not really "native" in all cases.
Alan
| |