version.h doesn't store the version number as string anymore. Update
findversion to use the individual values instead.
Change-Id: I6bf0fdd4420d41279b44cffd22b42febbfc778ce
Check for lrelease and always try to run it if found. If not found show a
warning. This avoids build problems for certain setups which previously
required -config dbg to complete.
Change-Id: I60f0f49adc8455743afc5e4d23294ce0729f38d2
Update to latest quazip release. Note that quazip is now LGPL and not GPL /
LGPL dual licensed anymore.
Change-Id: Ie1e975b5b546dd31218eef9df472527493fe81e0
I copied the direction button description from snake2
manual, as both snakes seem to have the same controls.
No guarantee however :)
Change-Id: I8ca1ccf75f0737d5a922aae207c7c7efef5ec026
Some arm gcc versions have multiple cpp symbols beginning with
__ARM_ARCH, but want only the one that contains the arch version.
Change-Id: I6792572e29200fc4e62ba07bdd63dc722356c2bb
- more whitespace to enhance readability
- better/fixed/more comments ;)
- some minor optimizations
- general code cleanup
Change-Id: I2b5f69aba0f83f989abb2c636920646e4315583f
This tiny patch gives the player a bit time to
overlook the terrain and move the thumb to the
action button.
Change-Id: I63a4347c5bdafdd354f8c95b2bcdc64e046133a5
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
Change-Id: Ib83735b3db8475be5de9c94231714e88668a0340
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.
Change-Id: I70635c307a1443bba6801c588cf1efde299db9a4
The solution is a bit hacky as it simply call make in libs
directory as pre-dependency. Clean doesn't touch libs.
Change-Id: Ib447a48fd87cc41228944f17444474a55d393543
It's not needed as picture flow has it's own buffer.
This reverts commit 9076b433d1.
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).
