ihex firmwares can include a jump address for starting execution. Add a
-j option which will cause this to be written into the generated file as a
record with address zero and data consisting of the address to jump to,
allowing drivers to make use of this information.
This format is chosen because it most closely follows the original ihex
format, though it may make more sense to write a record with length zero
and the address stored as the address. The records are not omitted by
default since our ihex format does not include record type information and
so including additional records may lead to confusion.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Fix up -Wmissing-prototypes in compileable userspace code, mainly under
Documentation/.
Signed-off-by: Ladinu Chandrasinghe <ladinu.pub@gmail.com>
Signed-off-by: Trevor Keith <tsrk@tsrk.net>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This reverts commit 8b249b6856.
This 'fix' is not necessary; we just need to undo the damage caused
accidentally by Igor/Mauro in 4b29631db3
("V4L/DVB (9533): cx88: Add support for TurboSight TBS8910 DVB-S PCI card")
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Rafael reported:
I get the following error from 'make modules_install' on my test boxes:
HOSTCC firmware/ihex2fw
/home/rafael/src/linux-2.6/firmware/ihex2fw.c:268: fatal error: opening dependency file firmware/.ihex2fw.d: Read-only file system
compilation terminated.
make[3]: *** [firmware/ihex2fw] Error 1
make[2]: *** [_modinst_post] Error 2
make[1]: *** [sub-make] Error 2
make: *** [all] Error 2
where the configuration is that the kernel is compiled on a build box
with 'make O=<destdir> -j5' and then <destdir> is mounted over NFS read-only by
each test box (full path to this directory is the same on the build box and on
the test boxes). Then, I cd into <destdir>, run 'make modules_install' and get
the error above.
The issue turns out to be that we when we install firmware pick
up the list of firmware blobs from firmware/Makefile.
And this triggers the Makefile rules to update ihex2fw.
There were two solutions for this issue:
1) Move the list of firmware blobs to a separate file
2) Avoid ihex2fw rebuild by moving it to scripts
As I seriously beleive that the list of firmware blobs should be
done in a fundamental different way solution 2) was selected.
Reported-and-tested-by: "Rafael J. Wysocki" <rjw@sisk.pl>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Cc: David Woodhouse <dwmw2@infradead.org>
Fix both the IHEX firmware generation (len field always null, and EOF
marker a byte too short) and loading (struct ihex_binrec needs to be
packed to reflect the on-disk structure).
Signed-off-by: Marc Zyngier <maz@misterjones.org>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Some drivers could do with using records like Intel HEX, but with each
record being larger than 256 bytes. This has been possible in the binary
representation (struct ihex_binrec) in the kernel since the beginning --
at least of the the current version of history. But we haven't been able
to represent that in the .HEX files which get converted to .fw files.
This adds a '-w' option to ihex2fw to make it interpret the first _two_
bytes of each line as the record length, instead of only one byte. And
adds makefile rules for %.H16->%.fw which use that.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Not the straight conversion to binary which objcopy can do for us, but
actually representing each record with its original {addr, length},
because some drivers need that information preserved.
Fix up 'firmware_install' to be able to build $(hostprogs-y) too.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
