Hello,
sorry for being quiet for so long. I have created the initial version of
the tool for attaching FW information to files. It's located at:
https://github.com/jansucan/fwinfo
It is far from being complete (poor error handling, no comments, code
duplication, no manual page, ...). I will correct those bit by bit. I
would just like to know if it's heading the right direction.
The tlv_file.c contains support for TLV file format as described in one
of the previous mails. The fwinfo.c implements user interface and
handles the FW attributes. Currently the utility supports setting,
deleting, and listing attributes. Possible attributes are name, version,
endianness, license, and data. The data attribute can't be deleted or
set. It can only by listed. Listing it causes writing its content to
stdout which can be redirected to a file. Thus the original FW data can
be obtained without deleting all attributes. The utility prints only
names of the attributes set when executed without options.
When setting the first attribute the file is automatically initialized
as a TLV file. It means that the mandatory TLV records "data" and
"checksum" are created. When the last attribute is deleted, then also
the two mandatory TLV records are deleted and the file is no longer a
TLV file.
The following are some examples of usage. Set name, version and license.
The license text is read from a file:
$ fwinfo -s name="Firmware for XY
device",version=123,license=/usr/share/doc/XY/license.txt file
Add license and read its text from stdin:
$ cat /usr/share/doc/XY/license.txt | fwinfo -s license=- file
Delete name and endianness attributes:
$ fwinfo -d name,endianness file
List name and version attributes:
$ fwinfo -l name,version file
Firmware for XY device
123
Delete all attributes:
$ fwinfo -d all file
Please, let me know if the utility has some design flaws.
Thanks,
Jan
On 26. 7. 2017 10:28, Jan Sucan wrote:
It will be possible to add another records with unused IDs to the
linked list structure in the future. The number of records is not
fixed to the proposed ones.
There is one small change I would like to make. Endianness will be
expressed by only one record with these possible values:
- no_endianness
- little_endian_{2,4,8}
- big_endian_{2,4,8}
I will create first version of the tool for managing attached info and
submit it to the bugtracker for a review.
On Wed, 26 Jul 2017, Sepherosa Ziehau wrote:
Looks good to me. I'd leave some spare fields in the in-image record
head (zero filled), for future extension of the in-image record head.
On Sun, Jul 23, 2017 at 6:00 PM, Jan Sucan <sucan...@fit.cvut.cz> wrote:
Hello,
this is the proposal for the new firmware file format.
---- Firmware file format ----
Data structure used is a singly linked list. Operations on it have a
linear time complexity (worst-case), but because there is only a few
records it is sufficient.
Conditions for ordering of the records:
- checksum record is the first
- firmware image data is the last
Checksum and image data are the only mandatory records.
Start of the linked list is at the end of the file (and it continues
"backwards") so the file can be resized more easily when modifying
records (firmware attributes).
Each record has an ID (1 byte) which describes the meaning of it and
its allowed values. ID is followed by the length of attribute data in
bytes (4 bytes, little-endian). The next record starts immediately
after data of the current record.
Each record is read-write for a user except for the two read-only
records:
- checksum
- firmware image data
---- Records ----
- Checksum: string (checksum will cover everything after this record)
- License text: string (file path or complete text of the license, no
license ack is needed if not defined)
- Firmware version: integer number
- Firmware image endianness: boolean (little-endian, big-endian)
- Firmware image word size: 1,2,4 or 8 (used for endianness)
- Firmware image data: array
---- Operations with firmware files ----
- Initialize raw firmware file: create linked list structure and
checksum and firmware image data records
- Uninitialize firmware file: remove linked list structure and keep
only the original raw firmware data
- Check firmware using the checksum
- Set record's value: only for read-write records (this also creates
record which is not defined yet)
- Get record's value: for read-only and read-write records
- Remove record: only for read-write records
jan
On Thu, 20 Jul 2017, Sepherosa Ziehau wrote:
Hi,
On Wed, Jul 19, 2017 at 4:27 PM, Jan Sucan <sucan...@fit.cvut.cz>
wrote:
That's good and interesting idea. Attaching the config to the image
could unify the way in which config info is saved for both built-in
and non-built-in images, and also unify a code for parsing the config
info in the kernel firmware subsystem. Possibilities for firmware
file
formats:
- uuencoded
Pros: Config can be added, modified and removed by a text editor
Cons: .uu files are about 35% larger, need to implement
uudecoding in
the kernel, config correctness checked at firmware loading
time
- binary
Pros: firmware data size, user-interface of the new tool can be
better suited for given purpose than a text editor (which
is too
general), config correctness checked at config modifying time
Cons: need to create new tool for handling attached info (something
like kenv(1) for firmware)
For binary firmware it will be necessary to also add some checksum
data in case when config is not attached and firmware data is also
valid config. Checksum could be computed only from firmware data
or it
can cover the config data too.
I think, that the second file format would be better. I can try to
propose a format for the attached config and post it here for a
review.
Yeah, sure, go ahead :)
Thank you,
sephe
On Tue, 18 Jul 2017, Sepherosa Ziehau wrote:
I'd choose plain text config per-image. BTW, is it possible to
attach
the config at the beginning/end of the image? Assuming we can force
some image file creation rules.
On Tue, Jul 11, 2017 at 8:20 PM, Ján Sučan <sucan...@fit.cvut.cz>
wrote:
Hello,
I would like to introduce a few ideas about the new firmware
subsystem.
I
assume that it should not require adding a new system tools or
modifying
boot process.
Simplification is the first. It would be good to remove
parent-child
relationship and corresponding functionality. It would
significantly
simplify firmware handling. Its only practical use is when there
are
multiple images in one loadable kernel module. The module can be
unloaded
when all children are not in use. Usage of the children images is
tracked
through the counter for the parent image. If images will not be
placed
inside loadable kernel modules, the parent-child mechanism won't
have
any
practical meaning. I think, currently the mechanism is not used
anywhere
in
the DragonFly system and if it was, it could be easily replaced by
putting
every child image in its own module without modifying drivers.
There are two use cases according to who will provide firmware
images
to
the
system:
- developers of DragonFly BSD (they can modify and rebuild the
system)
- third-parties (they should not be required to modify and
rebuild the
system)
Providing a new non-built-in firmware should not require:
a) system rebuild
b) system reboot
c) loading a kernel module
All firmware images needs to have some information attached (at
least,
if
ack with a license is needed) which should be
d) stored persistently.
The question is where to save the information for non-built-in
images.
For
built-in images the info is saved in the kernel. Some possibilities
are:
- A plain text configuration file per image.
This satisfies requirements a), b), c) and d). Disadvantage is
parsing
the
text content.
- Kernel environment variables.
The problem with this is that they are initialized:
- by some kernel code (this violates a), b), c) )
- manually from userland by kenv command or kenv() libc
function
(violates d) )
- in the loader.conf (violates b) since the content is
processed at
boot
time)
Advantage is that the parsing is done by the kernel.
There would be two firmware sources: kernel and filesystem. In
case of
the
same image names, user could have a choice by setting a kernel
environment
variable, firmware from which source has higher priority and
will be
provided to consumer.
I will be happy for a comments and ideas
jan
--
Tomorrow Will Never Die
--
Tomorrow Will Never Die
--
Tomorrow Will Never Die
