[SLOF] sloffs: tool to read and write SLOF images

[Thomas Huth]

On 27.06.2016 08:11, Adrian Reber wrote:
> On Mon, Jun 27, 2016 at 01:02:59PM +1000, Alexey Kardashevskiy wrote:
>> On 16/06/16 06:06, Adrian Reber wrote:
>>> On Wed, Jun 15, 2016 at 09:36:13PM +0200, Thomas Huth wrote:
>>>> On 15.06.2016 10:29, Adrian Reber wrote:
>>>>> This brings the sloffs code to read, copy and append files to an existing
>>>>> boot_rom.bin from my repository at https://lisas.de/~adrian/slof/slof.git/ .
>>>>>
>>>>> This code was written in 2008 and all patches have been cherry-picked
>>>>> without modifications. Only the last patch (13/13) updates the code
>>>>> to work with today's compilers.
>>>>
>>>> Cool, thanks for posting it! I also gave it a try, and it works for me 
>>>> fine with the current boot_rom.bin images, too.
>>>>
>>>> However, I still get some compiler warnings here (gcc 4.8.5):
>>>>
>>>> sloffs.c: In function ‘sloffs_dump’:
>>>> sloffs.c:434:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
>>>>   if (be64_to_cpu(*(uint64_t *)header->date)) {
>>>>   ^
>>>> sloffs.c:435:3: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
>>>>    printf("%04x", be16_to_cpu(*(uint16_t *)(header->date + 2)));
>>>>    ^
>>>> sloffs.c:445:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
>>>>   if (be64_to_cpu(*(uint64_t *)header->mdate)) {
>>>>   ^
>>>> sloffs.c:446:3: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
>>>>    printf("%04x", be16_to_cpu(*(uint16_t *)(header->mdate + 2)));
>>>>    ^
>>>
>>> Interesting. With gcc 6.1.1 on Fedora 24 I do not see those warnings.
>>>
>>>> We already changed most Makefiles of SLOF to use -fno-strict-aliasing,
>>>> so we should maybe use that for tools/Makefile, too - or simply
>>>> fix the aliasing problems ;-)
>>>
>>> Whatever fits better to the remaining code. The romfs structs are broken
>>> and the actual dates are stored in the padding fields behind date and
>>> mdate.
>>
>> I am a bit confused here.
>>
>> As I read the code, the dates are stored in both date and padding fields,
>> it is just shifted by 2 bytes so padding is used. And the tool does not
>> handle properly written dates at all as romfs is always wrong - where are
>> these dates are stored? Cannot we fix that spot and then fix the tool not
>> to have this workaround?
> 
> Yes, the structures defining the romfs header and the romfs code
> unfortunately disagree. My tool just tries to cope with the broken code.
> 
> The definition is in include/calculatecrc.h and it written in
> romfs/tools/create_crc.c. There is also some forth code reading this
> field: bdate2human
> 
> I discussed this already on IRC with Thomas and it should be easy
> fix it. It just means sloffs will never display the correct dates of old
> romfs files. Which is probably not that important...

I think we should simply replace the "char date[6]" field in struct stH
with "char date[8]" and remove the padding[2]. Then add a big fat
comment that the first two bytes of date[] are unused and should be
ignored ... that way the code should look better and we keep the
compatibility with old boot_rom.bin files.

 Thomas