Cortex-M7 support was added in GCC 5, while GCC 4.9 only
supports the M4. The instruction set is almost identical
between both processors; the only difference is that the
M7 supports double-precision floating point and the M4
doesn't.
Since Rockbox currently doesn't use the FPU, building M7
targets as M4 works fine.
Change-Id: I5880d6e81a85fa9b3e16e08d57e7955b4493df0b
Even though ARMv7-M has a hardware divider, 64-bit division is
handled in software and needs a div0 handler. The libgcc routines
call __aeabi_{i,l}div0 so we alias those to __div0.
Change-Id: I5152c43d39e25e03f31404753f13978a614aca06
Currently, only the development bootloader can be built successfully.
This is a part of the large iPod Nano 3G and iPod Nano 4G support patch.
Credit: Cástor Muñoz <cmvidal@gmail.com>
Change-Id: I74ea0da999ddb1d8ce5d0f5434141b3f0b5f7448
Currently, only a bootloader can be built successfully. The development bootloader is functional, it enables further progress on the port.
This is a part of the large iPod Nano 3G and iPod Nano 4G support patch.
Credit: Cástor Muñoz <cmvidal@gmail.com>
Change-Id: Idf85e42334b0e0ae36f9ed273e2940d5d7736e34
M-profile cores manage interrupts differently from classic cores
and lack the FIQ. Split the interrupt management parts out into
separate headers but keep the endian swapping routines (which are
not profile-dependent) in the common system-arm header.
The initial part of the vector table is common to all Cortex-M
CPUs and is intended to be included by the target linker script,
with the vendor-specific part of the vector table appended to it.
Change-Id: Ib2ad5b9dc41db27940e39033cfef4308923db66d
GCC cannot compile the existing assembly here on ARMv7-M,
claiming impossible constraints. It is actually possible to
compile if the input arguments (addresses and sizes) are
first moved to a high register so as not to conflict with
the use of r0-r7 in ldm/stm -- this is exactly what GCC does
for ARMv6, but it won't do it on ARMv7-M for some reason.
We can get a result similar to the ARMv6 code by manually
moving the inputs into temporaries, but the generated code
is a actually a bit smaller on ARMv7-M if the r0-r7 block is
shifted up to r3-r10. This only works since ARMv7-M supports
the 32-bit Thumb encoding -- 16-bit Thumb can't represent an
ldm/stm instruction of this type.
It's worth #ifdef'ing the code because although the ARMv7-M
version works on ARMv6 too, it spills a lot of registers on
the stack even though register use is mostly similar.
Change-Id: I9bc8b5c76e198aecfd0a0e7a2158b1c00f82c4df
On ARMv7-M, stm/ldm instructions can't include SP, so we must
load and store that separately. This changes the order of
registers in the context struct, but it doesn't seem to be
accessed anywhere else so this shouldn't cause any problems.
Change-Id: Ie1cd23272f23384e030f51f0b76739624fa7332b
Commit 1fb906500a ("x1000: LCD DMA fix") caused a regression
on the Q1 by breaking the LCD_X1000_DMA_WAIT_FOR_FRAME logic,
since the wrong branch of lcd_wait_frame() was taken.
Change-Id: Icb44335f506a1a691280de8219188526bb11468f
All the X1000 targets use "fast" sleep, as opposed to the normal
HAVE_LCD_SLEEP define which creates a user-configurable option.
Remove the ifdefs to make the code a bit easier to read.
Change-Id: Ibb80c92a8e23191651fee61fc8cf6f4e4fac8750
Looks like they were always off-by-one, so the wrong functions have been used to rectify this bug. This is now properly fixed.
No changes to the ipodnano2g binaries (bootloader, rockbox)
Change-Id: I19fe1b89f9e5d722f7e877d60f68fc3275c3642a
This makes these files compileable, or in some cases less
broken, on Cortex-M targets.
In lcd-16bit.c, newer versions of GAS complain about the
infix condition codes so we use the suffix form instead,
which requires unified syntax to compile on GCC 4.9.
Change-Id: If45166d3fc83d64c692cbb331096a966397aa9e9
ARMv7-M has hardware division, so it doesn't require __div0
or any support functions for 32-bit division.
Change-Id: I840683a1a77d737f378899ca4bcf858216b81014
Add some logic to detect classic and M-profile cores, and make
this info available to the build system. All existing targets
are classic profile.
Change-Id: I07bfcd418bcaa6297b9bbf889fc189f167147428
-1 could be supplied unintentionally from user code when utf8_size is computable value
Fixup for 004304dc and 1f548f74
Change-Id: I93008ea289bdb134f051975c25b0db9d0e64b823
This mirrors the behavior of idle poweroff,
which inhibits shutdown as long as a charger
is plugged in, even if a device is capable
of powering off while charging.
Since usb_inserted() already checks for USB_POWERED,
certain devices with the ability to power off while
charging, already exhibit this behavior when using
the sleep timer anyway.
Change-Id: I35ed4b542a8a4df06a34395c85f4d37fc1d2ce53
try #2 at this
if there isn't enough data remaining to fill the columns
then don't read any more data
looking at the blame for this driver it had similar logic originally
But really on native this is just extra overhead so..
Ifdef out for native
Change-Id: I105dea1f7adc0448f345b268fcfa8574333132a9
1-bit vertical displays overread the buffer due to the way the
packing works, this isn't the hottest path anyway but
we can check if height <= 8 and make stride 0 so the dummy data
gets the beginning of the data instead
Change-Id: I88ab4dc37bfd2d680d125f964beafe0ddfb00645
When a line is over a selected length bi-directional scrolling
is disabled.
In non bidir scrolling the string is copied to a buffer twice with
a space between "scroll text" + " " + "scroll text"
this is to allow scrolling the line in the forward direction
with minimal extra logic
Note: that is the ONLY direction it is equiped to handle
In the USB screen I observed while switching through the different modes
that sometimes the text was corrupted
turns out you can still have scroll->backwards set to true
which causes offset to go negatve but we never check if offset < 0
in non bidir scrolling mode and happily continue with ever more negative offsets
Change-Id: I210f7880be953d3cc42469828a7ca5fc2b2ab96f
the YPR1 apparently can do voltage or percent measure
I'm pretty sure its missing logic for disksafe and shutdown,
perhaps the device takes care of it for you?
hopefully someone with the device notices the issue
(perhaps due to a older battery needing capacity tweaked)
Change-Id: I79d3927fa8b154ba231aa6894de7920a4e4dd4c7
when battery_bench is run
exports a file in the rockbox directory called 'battery_levels.default'
if the user wants their own levels they can rename the file battery_levels.cfg
and it will be loaded at boot
some minimal error checking is performed prior to using the values
added manual entry
Change-Id: Ia0126faced0c7229fcf8385a1bcb584b5a9dc378
GCC 9.5 issues a -Wmisleading-indentation warning due to an extra
semicolon at the end of the while loop. It does seem unintentional
since the loop is a busy wait, so remove the semicolon.
Change-Id: I83b8676cbf38434b8148c43906c6bba9c16d036e
Only affected status display, charging is handled entirely by hardware.
Introduced in f3026cd0 (2024-11-02)
Change-Id: I08c7c442fb3bddf18e5a0d33dac963c24d3c9182
The "charging" status is apparently "charging needed" as it
is asserted even when power is not being supplied. So first check
to see if USB is connected, and if so, then check the "charging" status.
Change-Id: I3050f187e0b6c9d97d25d80015b413cd02e5c3b2
On PATA, we'd cap our transers at UDMA2 if the device reported that an
80 pin cable wasn't detected, but SATA devices do not perform this test.
So alter the check to only apply on PATA devices, so that SATA devices
can run at full UDMA speeds.
Change-Id: Id7aa25f2a702c0af73d707395439d69da1e04719
On these older iPods, power was not being shut down completely, which led to a backfeed situation leading to decreased battery life and some stability issues.
This was particuarly apparent when using SD card adapters that do not
respect the ATA power management commands (ie all of them), as they never enter a low-power state on their own.
With this change, there are reports of battery life exceeding 20 hours of continuous playback (~30% increase with CF cards, 3x improvement with SD cards) and appears to resolve intermittent wakeup stability issues with SD adapters.
Change-Id: I46cfff7a59bb18a448989812303f30869df24d2d
in testing of three ways of doing this
current: ((_ctype_+1)[(unsigned char)(c)]&_N)
alt1(this patch): (((unsigned int) (c) - '0') < 10)
alt2: ((unsigned int)(c ^ 0x30) < 10)
alt1 and alt2 are the same in terms of speed and instructions (on arm v7) but alt2 has one more
instruction on mips
(across several archs in godbolt mips, armv7v8, x86) and on ARM7 (clipzip) device about 9% faster
less false positives for both alt1 and 2 when you start supplying more than 8bits
not sure if that matters in practice though
I tried similar with isxdigit but could only get to within 1 instruction of the ctype implementation
although it negated the array lookup I saw no discernable speed difference on device
https://godbolt.org/z/qGvh4hqnG
Change-Id: I5c9e8fd3915709853e0e33427038e20a068058b6
Responding to the bug report posted by iPodVT:
https://forums.rockbox.org/index.php/topic,55180.msg255292
- An active sleep timer that runs out will now cause the
player to shut down regardless of playback state
- When playback state is paused or stopped, once the
idle timer has run out, player will shut down, regardless
of any running sleep timer
Change-Id: I33de682a63ed1db76174eb2394ef5568f37cc677
characters less than the first diacritic in the symbol table (0x300)
return false after checking the MRU table
we gain some performance by eliding the function call all together if less than first diacritic
Change-Id: I02c14e350eb168eca808523affad443cd43888b4
remove nvram and use the existing settings framework for it
add a crc check to the user_settings data to see if we need to save
the user setting file or if we can just save the status file (resume.cfg)
move volume to the system_status struct so we don't write the whole settings file
over volume changes
allow user to still export volume with save sound settings
allow the user to also export pitch and speed
name the file .resume.cfg
Rename all the SYSTEM_STATUS save file variables to TLAs to save space and
discourage tinkering
Cleanup DEBUG_AVAIL_SETTINGS output
when saving user_settings it calls status_save as well this cause the resume
file to be written twice. instead remove the callback for status_save
when setting_save is called
remove header text when saving .resume.cfg
convert status_save() to status_save(bool force)
add SYSTEM_STATUS_UPDATE_TICKS
for ATA device set this to 5 minutes
since we arlready wait for the disk to be up before saving
we don't want to miss our window
for all other every 15 minutes
that way if the battery is too low by the time shutdown comes around you
don't lose much progress
Change-Id: I27214ffd6e5d5494ee5ca83b14f04a41ba426ad7
Use AXP2101's egauge battery percent level if available (hw4 units).
If not available (_battery_level() will return -1 on hw1-hw3 units),
fall back to voltage battery level.
Also fix logic in axp2101_battery_status()
Change-Id: Ic300418532dae6f7772fff8bf5e2b32516f3b973
Revisit this after discussion with chris_s on IRC and forum
Pitch menu now changes icon when pitch has been changed
uses NVRAM to save the pitch settings unconditionally
Manual updated
Change-Id: Idcb4c2b7fe42f7a203dc4bfc46285657f370d0fd
if you run yesno screens back to back or another screen with
wait_for_release you may never see the release
instead clear anything in the queue but release events
Change-Id: I1b1e42cbb44f2fdfed441ab1f217b6ea4fe07492
If I'm interpreting the git history correctly,
the config file for Zen Vision was at some point
inadvertently replaced with one for the
Zen Vision:M.
This deletes the currently unused creativezv.h,
and moves its contents into zenvision.h.
The config files appear to be identical except for
CREATIVE_ZV vs CREATIVE_ZVM define, different
keypads (CREATIVEZVM_PAD vs CREATIVEZV_PAD) and
BOOTFILE_EXT (zv vs zvm), a different model name
and number, as well as different LCD dimensions
and DPI.
The buttonmap still seems to require adjustment.
Change-Id: I9a5e65df750db21be5f5a1ed7a80a50706237781
