Correctly set endpoint maximum packet size so host will not consider
end of transfer after receiving first packet when transfer is larger
than 64 bytes (at High Speed the endpoint max packet size was set to
64 but according to descriptor it is 512).
Split DMA transfers up to CPPI_MAX_FRAG so we get single interrupt
after each call to tnetv_cppi_send().
Change-Id: I385b66bc5d71975a4e3e9167efac0b1334bd3ffc
Return complete R2 response to caller. Due to incorrect bitfield
handling only bits [127-96] were ever returned to caller.
Change-Id: I83726af35fb24a8051fcca8b8d019ad89d17500e
Port USB driver from Sansa Connect Linux kernel sources. The device
successfully enumerates and responds to SCSI commands but actual disk
access does not work. The SCSI response sent to host mentions that both
internal storage and microsd card are not present.
Change-Id: Ic6c07da12382c15c0b069f23a75f7df9765b7525
Modify count, buffer and start address only after successful transfer.
This makes the retry operation to use the same address and buffer as the
just failed transfer.
Change-Id: I4f49bbdc861d634e33ea5e939a9693474411d24d
Clearing recoverzap parameter exists the Recovery Mode. This makes it
possible to run Rockbox on Sansa Connect without relying on original
Linux firmware.
Enable write-through cache on flash memory as write-back complicates
handling without any real benefits. The flash memory accepts commands
as series of writes at predefined addresses, so it is important that
the cache does not interfere with the writes.
Change-Id: I219f962f20953d84df43012cf16bbb16d673add8
It never worked, and hasn't compiled in something like a decade, Given
the HW capabilities (limited onboard flash, no expandability) there's
really no point in trying to fix/complete it.
Change-Id: I7d175089840396f8891645bd10010d730dd5bfdc
They were never finished, never saw any release ever, and haven't
compiled for the better part of a decade. Given their HW capabilities [1],
they are not worth trying to fix.
[1] 1-2MB RAM, ~256MB onboard flash, no expandability
Change-Id: I7b2a5806d687114c22156bb0458d4a10a9734190
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
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
* 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
Nothing in the core has used it for some time. It's exported to the
plugin API but the last plugins to use it were switched to the mixer API
back in 2011.
This allows us to get rid of pcm_play_dma_pause() from all audio drivers
Change-Id: Ic3fa02592316f84963e41d792d1cabb436d1ff6b
I'm currently running up against the limitations of the lcd_draw functions
I want these functions to be able to be used on any size buffer not
just buffers with a stride matching the underlying device
[DONE] allow the framebuffer to be decoupled from the device framebuffer
[DONE need examples] allow for some simple blit like transformations
[DONE] remove the device framebuffer from the plugin api
[DONE}ditto remote framebuffer
[DONE] remove _viewport_get_framebuffer you can call struct *vp = lcd_set_viewport(NULL) and vp->buffer->fb_ptr
while remote lcds may compile (and work in the sim) its not been tested on targets
[FIXED] backdrops need work to be screen agnostic
[FIXED] screen statusbar is not being combined into the main viewport correctly yet
[FIXED] screen elements are displayed incorrectly after switch to void*
[FIXED] core didn't restore proper viewport on splash etc.
[NEEDS TESTING] remote lcd garbled data
[FIXED] osd lib garbled screen on bmp_part
[FIXED] grey_set_vp needs to return old viewport like lcd_set_viewport
[FIXED] Viewport update now handles viewports with differing buffers/strides by copying to the main buffer
[FIXED] splash on top of WPS leaves old framebuffer data (doesn't redraw)
[UPDATE] refined this a bit more to have clear_viewport set the clean bit and have skin_render do its own screen clear
scrolling viewports no longer trigger wps refresh
also fixed a bug where guisyncyesno was displaying and then disappearing
[ADDED!] New LCD macros that allow you to create properly size frame buffers in you desired size without wasting bytes
(LCD_ and LCD_REMOTE_)
LCD_STRIDE(w, h) same as STRIDE_MAIN
LCD_FBSTRIDE(w, h) returns target specific stride for a buffer W x H
LCD_NBELEMS(w, h) returns the number of fb_data sized elemenst needed for a buffer W x H
LCD_NATIVE_STRIDE(s) conversion between rockbox native vertical and lcd native stride (2bitH)
test_viewports.c has an example of usage
[FIXED!!] 2bit targets don't respect non-native strides
[FIXED] Few define snags
Change-Id: I0d04c3834e464eca84a5a715743a297a0cefd0af
The right thing here probably to just not bother at all, as this
bootloader can't launch rockbox yet anyway.
Change-Id: I62bd22353b6adc9dbe35b94f3b60a6a67348356a
(we were trying to foward-declare functions from within static
initializer context. GCC no longer accepts this)
Change-Id: I58f316ecc84c8ab45fffc054955727a55714b0a3
Allow IPod 3rd generation to recognize when USB is connected and reboot into disk mode.
This problem is listed at the bottom of the Ipod status page https://www.rockbox.org/wiki/IpodStatus
Change-Id: I8f32afd065d3a91cddc56fe63454bd082bfa29b9
If we come up and the RTC is in a reset state, we need to release that
before trying to initialze anything else. (See IMX23RM 23.8.1 and 39.3.10)
Change-Id: I1820ab771ba81f7d428d07040b7d188d9f688127
For reasons that are still unclear, the 'ncbss' region was overlapping
the "audiobuffer" when linked with 2.21, but okay with 2.20.
Fixed it by making the audiobuffer explcitly use the current position
instead of relying on it being implicit.
With this change, portalplayer-based targets generate working binaries
when built with binutils 2.21 or newer.
This bug also theoretically affects imx233/imx31 targets as they
also have NOCACHE_BASE games in their linker scripts, but I lack
access to one to test with.
Change-Id: Idb38ab20f03599b9ed3d4bc0eafe519f38677438
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
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
7442742 ("iPod Classic: disable IRAM1") was causing subsequent ipod6g
bootloader builds to result in a completely black screen upon
installation, with recovery only possible with a reflash through DFU
mode.
IRAM1 is re-enabled for bootloader only.
Change-Id: I92d489c91f81cad55d66a8647c1e61a45f468770
On Classic, IRAM1 (second 128Kb of a total of 256KB available IRAM) is
slower than DRAM. Codecs that actually are using regions of IRAM1 runs
faster when DRAM is used, so IRAM1 is disabled and only IRAM0 remains
enabled: 48KB for core and 80KB for codecs/plugins.
The next test_codec results shows how decode time is decreased:
file boosted unboosted
*.ra ~1.5% ~0.5%
*.mpc ~21% ~4.5%
*.ogg ~0.5% ~0%
nero_he*.m4a ~8% ~1%
nero*.m4a ~25% ~7%
wmapro*.wma ~4.5% ~0%
wma*.wma ~25% ~7%
In addition there is a small power save when IRAM1 HW is disabled.
Change-Id: I102adee11458e82037f23076d5d5956e23235de8
Allow user to select cpu undervolt
There have been quite a few issues across the SANSA AMS line related
to CPU undervolting while most players show greatly increased runtime
some crash.
Rather than constanly upping the voltage we now have a
setting with a safe value for all players and the option for lower voltages
I plan to add a few other options here later such as disk
timings and maybe some other clocks/experimental settings
Added: Disk Low speed option for AS3525v2 devices cuts
frequency to 12 MHz from 24 MHz
Added: Disk Low speed option for AS3525v1 devices cuts
frequency to 15.5 MHz from 31 MHz
Added: I2c Low Speed AS3525 devices, should be bigger improvement for v1 devices
Fixed: Debug menu for AS3525v2 No SDSLOT frequency,
Showed IDE freq though it is unused
Added: DBOP and SSP underclocking affects display on v1/v2 respectively
Fixed: debug menu now has SSP frequency, and SSP_CPSR
Update: made settings menu more generic
Update: cleaned up code
Added: Clip v1 & Fuze v1 didn't have HAVE_ADJUSTABLE_CPU_VOLTAGE.
not sure why but, waiting on testing to confirm
Added: C200v2 and E200v2 devices and HAVE_ADJUSTABLE_CPU_VOLTAGE.
Fixed: v1 devices don't like display timing set lower (dbop)
v1 devices don't have a divider set for ssp (causes divide by 0)
Fixed: ClipZip display lags with Max SSP divider changed from 0xFE to 0x32
Fixed: v1 devices didn't work properly with highspeed sd cards
Added code from http://gerrit.rockbox.org/r/#/c/1704/
Added powersave and IDE interface enable/disable
Added: V2 devices now have powersave enabled on sd interface
Update: cleaned up code, lang defines, added manual entries
Update ssp clock mechanism added calculated ssp divider to clipzip
Update turn display clock off when clip+ turns off display
Fixed: clipzip wrong register for SSP clock
Change-Id: I04137682243be92f0f8d8bf1cfa54fbb1965559b
TODO: add other players?
Saves 100+ bytes (50 of it in iram), saves a bit of power
Internal LCD clock decreased but with added efficiency of drawing routines
loses only around 2 Hz on the scanrate (~75Hz) while fps is slightly increased
Column offsets are now calculated outside the loops saving a few instructions
Passing a LCD_NOP command after lcd_update turns off Data/Cmd# gpio
saving a bit more power
Added a function lcd_write_cmd_triple() that allows 3 commands to be sent at once
when enabled with LCD_USE_FIFO_FOR_COMMANDS it sends them back to back without
checking FIFO status in between or sending to thhe D/C# Gpio.
Makes an assumption about the FIFO being large enough to
accept 3 commands after being emptied which should be the case on the
clipv1, clipv2, clipplus. I have only enabled it for the clip plus
as thats the only device I have to test it on.
On clip+ the SSP clock is now turned off when screen is off
Change-Id: Ib5fd24697bfe4ac8b8ee017361e789e4a7910d21
On the clip zip most debug menu items get cut off and there is
no way to read most of the debug menu items.
This patch makes the menu button scroll the text 1 character
to the right with each press and the center (select) button
re-aligns the text
Adds SSP frequency(v2) & register
Adds SD slot frequency(v2)
Change-Id: If4705d6790e25061931ca654062e22fc2e0a6f16
I2c controller needs to be enabled in order to read CSPR0, CSPR1
registers function sets CGU_I2C_AUDIO_MASTER_CLOCK_ENABLE
and only clears if it wasn't previously enabled
Use divider set in register to calculate frequency rather than
hard coded divider
Change-Id: I54ecc0c1859e906c00f4c2ae8ae2424a4619df98
Also removes the sd_enable() function call. It was only used in
the debug screen on AMSv1 and not used at all on AMS v2.
For v1,obtain debug info in a struture passed to a dedicated
debug info function so that enabling and disabling the controller
isn't racy.
Change-Id: I7c44693bc2df5a1f16168b05b3abfe622f9584ce
Lcd_update rect was hanging during horizontal screen update x = 238 and width = 2
which was within the bounds of the screen, this seems to be a weird corner case
but more testing needs done.
Update_rect now properly bounded between 0 - screen w/h
--Cleaned up code
Pixels in x are now multiples of 4.
Datasheet states:
-------------------------------------------------------------------------------------------
WORD_LENGTH=0 implies the input frame buffer is RGB 16 bits per pixel.
DATA_FORMAT_16_BIT field indicates if the pixels are in RGB 555 or RGB 565 format.
Limitations:
— BYTE_PACKING_FORMAT [3:0] should be 0x3 or 0xC if there is only one pixel per word.
— If there are two pixels per word, BYTE_PACKING_FORMAT [3:0] should be 0xF and
H_COUNT will be restricted to be a multiple of 2 pixels.
and
WORD_LENGTH=3 indicates that the input frame-buffer is RGB 24 bits per pixel (RGB 888). If
BYTE_PACKING_FORMAT [3:0] is 0x7, it indicates that there is only one pixel per 32-bit word
and there is no restriction on H_COUNT.
Limitations:
— If BYTE_PACKING_FORMAT [3:0] is 0xF, it indicates that the pixels are packed, i.e. there
are 4 pixels in 3 words or 12 bytes. In that case, H_COUNT must be a multiple of 4 pixels.
-------------------------------------------------------------------------------------------
We are using 16 bits per pixel and byte_packing = 0xF but device crashes with multiple of 2 pixels
Behaviour can be verified with plugin - oscilloscope, Horizontal mode device hangs as indicator
reaches right of screen
Change-Id: I1445f5334f4e7fe59304c65c76b47d0daa0614b2
Windows now ignores the hidden flag, so just nullify the entries
to hide depending upon whether or not bootloader install mode is
activated.
Change-Id: I00d0797e40ea3b5f5d5d8e1243b50cfcdd029bb4
Instead of checking ticks, set a sticky dirty flag that indicates
that the RTC needs to be read. This gives a timely update and more
accurate readout without actually reading the RTC until it changes.
The implementation should atomically read the flag and clear it.
Setting the flag would typically happen in an RTC tick ISR.
Change-Id: I6fd325f22845029a485c502c884812d3676026ea
New support as well as some buggy support fixed.
Still no floating point support if ever that would be desired.
Support (*):
* Flags: '-', '+', ' ', '#', '0'
* Width and precision: 'n', '.n', '*' and '.*'
* Length modifiers: 'hh', 'h', 'j', 'l', 'll', 't', 'z'
* Radix: 'c', 'd', 'i', 'n', 'o', 'p/P', 's', 'u', 'x/X'
(*) Provision exists to switch lesser-used stuff on or off or when
certain functionality isn't desired (bootloader?). The compulsory
radixes are everything but 'o', 'n', 'p/P' and 'x/X' with length
modifiers being optional. The default setup is 'l', 'z', 'c', 'd',
'p/P', 's', 'u', 'x/X'.
* Move fdprintf() to its own file. It was in a strange place.
* Make callers compatible and fix a couple snprintf() bugs while
at it.
Could smush it down in size but I'm gonna get over the binsize
neurosis and just the let optimizer do its thing.
Change-Id: Ibdc613a9b6775802c188b29b9dd46c568c94f7c3
At normal loads:
- disabling auto slow boosts performance at the cost of runtime (~ -5%)
- disabling at max cpu does not noticibly decrease runtime
Change-Id: I5de80201c9a24ce556862151cbd6b21b01708b63
Adds boot data to as3525 devices Sansa C200v2 E200v2 Clip Clipv2 Clip+ ClipZip
fuze, fuzev2 m200v4
Adds boot_data to features.txt
default arm crt0.s now had boot data if HAVE_BOOTDATA is defined
Change-Id: I614a556696540511a69fc12a4520b01c268bf8a9
Bootdata is a special location in the Firmware marked by a magic header
The bootloader is able to copy information to the firmware by locating
this struct and passing data to the firmware when it is loaded but
before it is actually executed
Data is verified by a crc of the bootdata
Change-Id: Ib3d78cc0c3a9d47d6fe73be4747a11b7ad6f0a9e
Playing AAC-HE files resulted in a race condition between
audio/codec/buffering for set_cpu_frequency
Change-Id: I35e1c1fd18db623e2990c305acdca03f57184d0d
* Editing a bunch of drivers' thread routines in order to
implement a new feature is tedious.
* No matter the number of storage drivers, they share one thread.
No extra threads needed for CONFIG_STORAGE_MULTI.
* Each has an event callback called by the storage thread.
* A default callback is provided to fake sleeping in order to
trigger idle callbacks. It could also do other default processing.
Changes to it will be part of driver code without editing each
one.
* Drivers may sleep and wake as they please as long as they give
a low pulse on their storage bit to ask to go into sleep mode.
Idle callback is called on its behalf and driver immediately put
into sleep mode.
* Drivers may indicate they are to continue receiving events in
USB mode, otherwise they receve nothing until disconnect (they
do receive SYS_USB_DISCONNECTED no matter what).
* Rework a few things to keep the callback implementation sane
and maintainable. ata.c was dreadful with all those bools; make
it a state machine and easier to follow. Remove last_user_activity;
it has no purpose that isn't served by keeping the disk active
through last_disk_activity instead.
* Even-out stack sizes partly because of a lack of a decent place
to define them by driver or SoC or whatever; it doesn't seem too
critical to do that anyway. Many are simply too large while at
least one isn't really adequate. They may be individually
overridden if necessary (figure out where). The thread uses the
greatest size demanded. Newer file code is much more frugal with
stack space. I barely see use crack 50% after idle callbacks
(usually mid-40s). Card insert/eject doesn't demand much.
* No forcing of idle callbacks. If it isn't necessary for one or
more non-disk storage types, it really isn't any more necessary for
disk storage. Besides, it makes the whole thing easier to implement.
Change-Id: Id30c284d82a8af66e47f2cfe104c52cbd8aa7215
Due to some undocumented behavior, the touchscreen was almost unusable in point
mode. Now it's much better but still not very nice to use, probably it needs some
filtering.
Change-Id: Idc8a0214b09f268e6be907ee6ec3126cc0d88773
SUPPORTED SERIES:
- NWZ-E450
- NWZ-E460
- NWZ-E470
- NWZ-E580
- NWZ-A10
NOTES:
- bootloader makefile convert an extra font to be installed alongside the bootloader
since sysfont is way too small
- the toolsicon bitmap comes from the Oxygen iconset
- touchscreen driver is untested
TODO:
- implement audio routing driver (pcm is handled by pcm-alsa)
- fix playback: it crashes on illegal instruction in DEBUG builds
- find out why the browser starts at / instead of /contents
- implement radio support
- implement return to OF for usb handling
- calibrate battery curve (NB: of can report a battery level on a 0-5 scale but
probabl don't want to use that ?)
- implement simulator build (we need a nice image of the player)
- figure out if we can detect jack removal
POTENTIAL TODOS:
- try to build a usb serial gadget and gdbserver
Change-Id: Ic77d71e0651355d47cc4e423a40fb64a60c69a80
The ZEN/X-Fi (STMP3700) don't handle memory frequency scaling really well, for
this reason we run it at a fixed frequency. That frequency was previously set
to 64Mhz because when the CPU run at its lowest frequency, we set the VDD voltage
to 0.975 V and on STMP3700, VDDD=VDDDMEM and this is too low to run EMI at 130Mhz.
This is not a good solution because under heavy load, running the EMI at 64Mhz
results in frame drops and a sluggish device. Thus we now run the EMI at 130Mhz
all the time now. To do so, increase the minimum VDD voltage to 1.275 V.
This may result is a decreased battery life on those targets but it will also
avoid all sorts of glictches and all the device to truly run at full speed.
Change-Id: Ia8391492c29fe67bc2701aa7d8cfd00a9df349e8
