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

[Alexey Kardashevskiy]

On 27/06/16 16:39, Thomas Huth wrote:
> 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.


Is it slof-only ROM filesystem type or it is from something like ieee1275?
We could just legalize the existing behaviour if it is not the latter :)



-- 
Alexey