This tool can pack/unpack a jz4760 archive (like the one used for the fiio x1/x3/x5), and can descramble/scramble (it's the same operation) a firmware file (the sys.bin file in the archive). I did my best to keep the compatibility with the leaked Fiio/Ingenic tool which has the same name.
I wrote the tools from scratch, but here are some remarks:
- the format used is a slightly modified IHFS used in the older JZ4640 series, I used the information on the wiki about the IHFS format
- the CRC computation done was already reversed engineered by someone on the forums but I realised this later
- There are a few unknown fields in the headers, see comments in the source code
- The firmware scrambling was discovered by pure guess, I realised there were some repetitve sequences, some I guessed it was a rotative XOR and ran some analysis to find the most probable sequence
36480c2: Fix a race condition in as3525 I2C driver caused by stacked ISRs.
It was possible for interrupts of higher priority than the current IRQ level to attempt to restart the interface while it was still active on a transfer. The list modification also wasn't protected within the I2C ISR itself.
079d7fb: Revert "PictureFlow: Add move callback for buflib allocations"
It's not needed as picture flow has it's own buffer.
This reverts commit 9076b433d18b5db1a1987fe99ca7c70808f22b0e.
Detailed explanation from Thomas Martiz (thanks!):
buflib buffers can be passed to yielding functions just fine. Problems only arise if the are concurrent allocations, for example if two threads allocate from the same context simultaneously or if the callee does it's own allocations. This can't happen in the pictureflow case, it has it's own context and a single thread allocating from it.
Therefore the problem isn't yield() itself, but possible concurrent buflib_alloc() calls that result from the thread switch. This is because compaction only ever happens on allocation (and not in a backgroud thread or so).