Re: isp: Endianness of firmware data

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 <[email protected]> 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