GCC 7 and up complain about this false positive when -Wformat-truncation
or -D_FORTIFY_SOURCE is turned on.
Primarily affects simulator builds on hosts with strict defaults.
Change-Id: I385b3c247775e1268b6bbd326b1afc3eb5453db7
At least newer devices support more NVP properties in a device-independent
numbering. Many are supported but I just added two useful ones
Change-Id: I57926de7f0dd364b46a57ca8d48a5c4d4f20402b
Loop terminator needed a preincrement rather than postincrement, and
also used a proper #define instead of a magic number.
Change-Id: Iafd6a0dce0304cb94e4f1d04cce46d2ca603507a
In addition to version and target also check id1_max & id2_max
for proper length before allowing voice file to be loaded
Change-Id: I36016059d07781b0bb43dd9873bbb6e565298d76
User reported LCD screen corruption via forum in 3.14 and 3.15
turning backlight off and back on seems to fix the issue
http://forums.rockbox.org/index.php/topic,53192.0.html
Change-Id: Id0b34d2f9b77e79ab0ecabace331f0b203184724
DX50/DX90 has a Cortex-A9 with NEON, use those specific flags
for speed.
Generic Android targets is for v4.4 (API 19) which doesn't support
pre-v7 ARM CPUs, so target generic armv7-a with hardfp support.
(This patch includes a rearrangement of the android toolchain helpers to
allow target-specific GCCOPTS. Huzzah)
Change-Id: I696051ef3fae25e1569c7b904decb7a3a0c6b674
(A lot of work was done on this thing, for a target that hasn't been compileable
at least since we moved to git..)
Change-Id: Ibface9392f3251b5be4bf1e0c4d12639c4f1662d
The oldest verison of the NDK one can still download today is version
10e from mid-2015, which comes with GCC 4.9, and no longer supports
32-bit hosts.
With this, one can actually compile the iBasso DX50/DX90 targets again,
as well as the generic android target, as long as one has the correct
SDK platforms (v16 for ibasso, v19 for generic) and SDK tools installed.
Change-Id: I62f2e742d5cfc13133244aeff75a928a7294ac91
No targets are enabled, but the hosted Hiby-based targets could have this
feature enabled if they weren't so buggy:
* No generic way to determine wakeup reason under Linux
* No generic way to be asynchronously notified if the alarm is
triggered when we're already awake
* Shutting down may clobber RTC wakeup (driver/etc dependent)
* Rocker's kernel's RTC driver has some 24h clock and timezone-related
issues.
So, the infrastructure is arguably useful, but the only applicable
hardware I have is pathologically brain-dead.
Change-Id: Ie1aa38e72b831c8a0695ff684f260e514eef9710
Only AGPTeck Rocker is enabled for now, and it doesn't work properly:
* No generic way to determine wakeup reason under Linux
* No generic way to be asynchronously notified if the alarm is
triggered when we're already awake
* Shutting down may clobber RTC wakeup (driver/etc dependent)
And finally:
* AGPTek kernel's RTC driver has some 24h clock and
some timezone-related issues.
So, the infrastructure is arguably useful, but the only applicable
hardware I have is pathologically brain-dead.
Change-Id: Iac6a26a9b6e4efec5d0b3030b87f456eb23fc01d
enable keylock in WPS and FMS by simultaniously pressing POWER and BACK.
It was necessary to change the ACTION_FM_EXIT from BUTTON_BACK-button-press-event to
BUTTON_BACK|BUTTON_REL-event and BUTTON_BACK|BUTTON_REPEAT-event to easily be able
to press BUTTON_POWER|BUTTON_BACK without accidentally triggering ACTION_FM_EXIT.
also rebase to current master and add myself to docs/CREDITS
Change-Id: I263a034d0d8fd047d39265e3598ae7936dd8133d
This is to enable binary patching of Hiby-based firmware files
Note that noting in rbutil uses this yet.
Change-Id: I03ac824dd7402d508eb4e857ad78f184eb0d0243
Once some missing power optimization stuff was added to the X3ii code,
they were completely identical.
Change-Id: I68e4db5e270e8ff22f91e521616a054bd7baa95d
On file systems with 2048 bytes per cluster, the bpb_secperclus value
gets multiplied by 4 when the meta data is loaded. This patch changes
the sanity check to consider (and reverse) that multiplication before
checking the cluster size.
Signed-off-by: Stefan Ott <stefan@ott.net>
Provided by Roman Stolyarov
Integration, Refactoring, and Upstreaming by Solomon Peachy
X3II confirmed working by forum tester, X20 is nearly identical.
This includes bootloader, main firmware, and the flash image patcher.
Eventual Todo:
* Further refactor AGPTek Rocker & xduoo hiby bootloaders
* Further refactor AGPTek Rocker & xduoo hosted platform code
Change-Id: I34a674051d368efcc75d1d18c725971fe46c3eee