isp: Endianness of firmware data

[Ján Sučan]

Dňa 2017-06-02 13:50 Ján Sučan napísal(a):
> Dňa 2017-06-02 03:07 Sepherosa Ziehau napísal(a):
>> On Fri, Jun 2, 2017 at 4:58 AM, Ján Sučan <sucanjan at fit.cvut.cz> wrote:
>>> Hello to all,
>>>
>>> I would like to ask for a help with an issue for which I am not sure
>>> about a clean solution.
>>>
>>> With isp driver firmware I wanted to do the same as I did with mxge: to
>>> move firmware data from arrays in C header files to uuencode .uu files
>>> in a sys/contrib/isp.
>>> The issue is that the firmware is stored in arrays of uint16_t. The isp
>>> driver has macros for handling the firmware data on both little-endian
>>> and big-endian machines. But it seems, that it uses some of those
>>> uint16_t values not caring about endianness (see the
>>> sys/dev/disk/isp/isp.c line 841 where the value is used directly for
>>> controlling number of repetitions of a while cycle).
>>>
>>> Currently, the correct order is ensured at compile-time. If the firmware
>>> is moved to files it will be saved with fixed endianness. So it wil be
>>> OK on little-endian and bad on big-endian or the other way around.
>>> I think of modifying firmware data right after firmware_get() so driver
>>> will find expected endianness.
>>
>> Maybe just generate two version of uu files (one big endian, one
>> little endian), and install the correct version of uu file (we only
>> support little endian currently).  This may be simpler than other
>> ways.
>>
>> Thanks,
>> sephe
> 
> Hello sephe,
> 
> thanks for the tip. It seems, that the make system does not provide
> endianness detection. I could add something like bsd.endian.mk in
> FreeBSD where endianness is defined statically according to selected
> target machine architecture.
> The endianness should be treated also in a case, when the firmware is to
> be compiled into the kernel (sys/conf/files). It could be done by
> additional level of preprocessing before <name>.fw target where it
> should be decided which .uu file to use.
> 
> Or, because DragonFly BSD supports only little-endian architectures, the
> other solution could be to use ostrich algorithm and ignoring the issue.
> 
> Thanks
> jan

Hello sephe,

the solution I would implement is modification of the
sys/tools/fw_stub.awk script so it will optionally take bin-endian
version of firmware image and the module code generated will then
contain conditionally compiled sections according to endianness. Image
specification will be in format
<firmware:name:version:big_endian_firmware> so it will be fully backward
compatible. It will solve both cases: when firmware is compiled into the
kernel and when it is embedded in a module.

Thanks
jan