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

[Adrian Reber]

On Mon, Jun 27, 2016 at 06:22:23PM +1000, Alexey Kardashevskiy wrote:
> 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 :)

This is slof-only and Thomas' idea sounds like the right thing to do.

		Adrian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/slof/attachments/20160627/1454e60b/attachment.sig>