Detection at startup is proving to be unreliable. Even if card is not
present at startup, upon insertion it will sort itself out properly.
Change-Id: I9ee90b724c90c530a39264f698c200a48aa72b1d
Including direct use of the external SD card mount
Known issue: If SD card is inserted at startup, it must be
ejected and reinserted to be registered.
Change-Id: I5f420160bda32135cbb088c1e8b04b6e3a73018e
The X3's line out is a bit hot, at ~4.3Vpp, so allow it to be backed off.
(On my X3, backing it off to -6dB brings Vpp down to ~3.4V)
Change-Id: Iea38ef1c6a1b183d0f8fb4eaf2bf9ed6b350a532
- Proper error codes are now returned from all functions. These codes will
be used by a host-side flash tool for error reporting.
- nand_erase_block() was replaced by nand_erase_bytes(). The caller can't
know how big an eraseblock is with the current API, so next best thing
is to verify the correct alignment inside the call and reject the erase
if it isn't properly aligned.
- Fixed typo in nandcmd_block_erase() which would cause an SFC error to be
interpreted as success. Yikes.
Change-Id: Id4ac9b44fa7fc2fcb81ff19ba730df78457c0383
headphone ADC thread stack was slightly too small. Bump it up a bit.
(it was _perfectly_ sized for the prior older toolchain+optimization flags...)
Change-Id: I2ca67c2b85c54f879892a31e281d7696f893389c
Use of IF_COP_CORE was mistakenly introduced as part of 89acde6af2,
effectively short-circuiting multiple tests resulting in the code
paths always being executed, on both cores.
Use the correct macro, so per-CPU paths are handled properly.
Change-Id: Id346cf759fc1b06b7d56694d7af1f469caf785a4
This appears to finally fix the issue
turns out the status register we were writing was only for the CPU
COP cache flush wiped out the CPU cache
--
Added some defines to cut down on the magic numbers
Added some comments explaining such
Set the address to full 20 bit address
0x1FFFFF which is then left shifted 11 internally -- somewhere around 4GB?
Link explains the cache status bits
https://daniel.haxx.se/sansa/memory_controller.txt
Change-Id: I57b7187c2f71a5b54ce145bf3a21ed492a8993cb
Enable its use in the jz47xx MIPS targets.
(accidently committed g#3249 before making these changes)
Change-Id: I1791946f632901f0c7a94b04b009671aa0d71717
* PREV/NEXT now swapped so they do what is expected in most contexts
* List and setting context retains prior behavior
* Enable the ADC that reads the headset remote and map the keys.
* As ADC-based remote "events" arrive as press/release pairs,
delay the button release.
Change-Id: I22d4eac3bfe1573b50eca795cf377bdafdeb5336
affects all hiby targets, fiiom3k, and ibasso dx50/dx90
As well as deduplicating a small pile of code, this also implements
hysteresis so we're not doing a sysfs read/lookup multiple times
back-to-back every time the power management tick fires.
Change-Id: I2f7672acbb36341becf67e07960c24c681270d09
Previously these were placed in DRAM, which is overwritten by RoLo
when it loads a new image, but RoLo must call commit_discard_idcache()
after loading the image.
Change-Id: I5dcc4ca711b774166f83c668695edbcabfab2604
The filesystem API often passes in unaligned receive buffers, and some
code (eg BMP reader) processes data in-place, leading to data loss when
we dropped the cache.
(And document exactly what we're doing, so we don't go through this again
at $future_date)
Change-Id: If47a7f2148a5a1a43777f0bd3be1bdfe8239e91e
In fixing the original bug I tried to optimize discard_dcache_range()
to minimize writeback and inadvertently introduced a second bug, which
typically ends in a TLB refill panic.
It occurs only if the range fits within one cache line, and when both
the start and end of the range are not aligned to a cache line. This
causes ptr to be incremented and end to be decremented, so ptr > end,
and the loop can't terminate.
Change-Id: Ibaac072f1369268d3327d534ad08ef9dcee3db65
- The range-based cache operations on MIPS were broken and only worked
properly when BOTH the address and size were multiples of the cache
line size. If this was not the case, the last cache line of the range
would not be touched!
Fix is to align start/end pointers to cache lines before iterating.
- To my knowledge all MIPS processors have a cache, so I enabled
HAVE_CPU_CACHE_ALIGN by default. This also allows mmu-mips.c to use
the CACHEALIGN_UP/DOWN macros.
- Make jz4760/system-target.h define its cache line size properly.
Change-Id: I1fcd04a59791daa233b9699f04d5ac1cc6bacee7
ATA DMA was enabled for all PP502x targets in d118f47 after previously reported instabilities were thought to have been fixed. The iPod 4G target remains unstable when UDMA 2 is enabled. File system corruption will eventually occur even using stock hardware in normal usage, according to both my own experience and that of several other forum users. UDMA 1 appears to be stable.
Change-Id: I8526bad9e879f5dad5174cfe07cd8828d8b72406
Basically no longer treat SCROLL_FWD/BACK as "button" events, instead
relying on the scrollwheel hooks to handle things properly.
Change-Id: I9bf18595ab3ca68e912f6dfb1f2eac2544578e73
* Bump internal mix buffer size by 4x, to 1K frames (matching ALSA period)
* Handle an underrun that occurs when filling the audio buffer
* Log underruns and make them available in the debug info
Change-Id: I28d56dd35d88851fa167ad92368a5882937a758f
v3: Add in config option
v4: Bugfixes
v5: Force a redraw upon exiting
v6: keypress-in-chargeonly mode enables mass storage (and vice versa)
v7: Fix bootloader builds
v8: Update manual, and have bootloader respect keypresses
v9: Change default to mass storage (ie no change in behavior)
todo:
* test-build dx50/dx90
* Switch from yes/no to proper menu?
* prevent WPS progress bar from drawing over us
Change-Id: I82e0ccb08497b7a5aa756ce77f1332ee963703a7
...
Change-Id: I7946cf240b18a4fa8ace5e25e1eb6e97b8b12d7c
This was introduced in e13c600133 back
when the author was trying to optimize the LCD code with DMA. For
whatever reason this broke the bootloader for the last 10 years or so
and no one could figure out why. This is now fixed.
However the bootloader is still currently broken in HEAD due to recent
changes to the LCD code. A fix for that is not yet known.
Change-Id: I046d53f9f391f558c391f2fadb6b260fe3be4d92
* pcm_get_bytes_remaining()
* pcm_calculate_peaks()
* pcm_get_peak_buffer()
Nothing in-tree uses these at all (except for the lua plugin wrapper)
Change-Id: I971b7beed6760250c8b1ce58f401a601e1e2d585
Some mSATA adapters seem to have trouble working with Rockbox using our
normal PIO timings; the timing value we use is probably out of spec and
is different to the OF. Switch to using the OF's timings according to
which PIO mode we select. This may not completely resolve problems with
these adapters but allows Rockbox to boot and play audio.
Change-Id: If73210700eb4af01864b373709ee1d15c775fb11
Also audiohw driver to specific device name, rewrite alsa controls code to
cache more data, thus making the code easier and use less stack. Avoid using
short/long in pcm alsa code since it's the wrong size on 64-bit (simulator
for example)
Change-Id: Ibc1ec44396e37b6cbdedbcf37300878638e5d2d3
