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
For some reason it was defined as 'unsigned short' but all arguments to
the threading functions and other structs used size_t. The SDL plugin
tried to allocate a 2MB stack and this resulted in much badness.
This is a _very_ old bug, and might be responsible for countless subtle
bugs!
Change-Id: I8b7fd79a10c21e3ab524a89b4d40d9afa4fab638
The pp502x cache init code tries to flush the cache by reading
a block of DRAM. Change the starting point from 0x0 to 0x1000
so the compiler doesn't helpfully insert an undefined instruction
to deliberately crash the target.
(This behavior is intentional on the part of GCC, and was triggered
by using -Os with my experimental 4.9.4 toolchain)
Change-Id: I2d2719615a1164a035f3dac8a56dd3737bbab1d5
This frees us from having to keep the web site in sync.
Note that only currently-referenced patches were kept.
Change-Id: I50da1b75baeac214cf142c8b76a05a8c56b4c1d4
