test_disk says everything is alright but playback is buggy, especially
when playing lossless files
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@27044 a1c6a512-1295-4272-9138-f99709370657
This caused mounting of µSD to fail on Fuzev2 in some cases, although
the card is detected properly
This might be the cause of playback glitches (more frequent for lossless
files) on clipv2
Trying to set the main PLL at 384MHz and FCLK at 240MHz didn't work, so
there might be some problems not understood yet
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@26979 a1c6a512-1295-4272-9138-f99709370657
AMSv2 and AMSv1 lowmem put the codec buffer in IRAM so we need to adjust
the address : AS3525_PHYSICAL_ADDRESS macro will do just that
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@26954 a1c6a512-1295-4272-9138-f99709370657
test_disk shows 1MB transfers are up to 3 times faster
not much difference for 1 or 8 sectors at a time
define STORAGE_WANTS_ALIGN to use the fast path when possible
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@26953 a1c6a512-1295-4272-9138-f99709370657
- cpufreq is now the same than AMSv1
- audio playback frequency should be more accurate
- adjust pclk (24.8MHz on clipv2/clip+, 41.333..MHz on fuzev2) : it is
still lower than the AMSv1 which use 62MHz on every model
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@26937 a1c6a512-1295-4272-9138-f99709370657
We need it for correct charger detection if we boot with charger plugged
because there is no edge interrupt
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@26936 a1c6a512-1295-4272-9138-f99709370657
it achieves all the requirements, work fine on c200v2, and is much simpler
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@26933 a1c6a512-1295-4272-9138-f99709370657
Reserve 1MB of DRAM for loading rockbox and use the rest as BSS
Write sdram setup in assembler and move it to a separate file, together
with MMU init code
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@26926 a1c6a512-1295-4272-9138-f99709370657
not working yet : an empty drive is detected
won't link on fuzev1: drivers allocated in usb_storage.c are too large
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@26905 a1c6a512-1295-4272-9138-f99709370657
has made it more reliable. It seems to basically work now, but
somehow when Linux tries to read the partition table and it gets the
"scsi read10" command, the storage_read_sectors(drive=0, start=0, count=8)
call never returns...
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@26894 a1c6a512-1295-4272-9138-f99709370657
Gets a bit more battery life
Adjust current usage, it was a bit too low for Clipv2/Clip+
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@26866 a1c6a512-1295-4272-9138-f99709370657
Fix the asm constraints to mark the left output variable as earlyclobber
Thanks to amiconn
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@26777 a1c6a512-1295-4272-9138-f99709370657
When building with eabi gcc, 2 variables are assigned the same register
This might be a bug in the constraints, but it's just simpler to use C,
even at the cost of 1 cycle per loop
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@26761 a1c6a512-1295-4272-9138-f99709370657
We can't pop into pc on ARMv4t when using thumb: the T bit won't be
modified if we are returning to a thumb function
Code running on ARMv4t should use the new ldrpc / ldmpc macros instead
of ldr pc, [sp], #4 and ldm(cond) sp!, {regs, pc}
No modification on pure ARM builds and ARMv5+
Note: USE_THUMB is currently never defined, no targets can currently be
built with -mthumb, see FS#6734
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@26756 a1c6a512-1295-4272-9138-f99709370657
preventing the DMA callback to advance in the recording buffer is not
enough in pcm_rec_dma_get_peak_buffer()
we need to prevent it interrupting us while we are copying the left
channel data into the right channel
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@26663 a1c6a512-1295-4272-9138-f99709370657
