The headphone amplifier enable, GPIO F2, shares its pin with SDRAM
address line A12 and is A12 until switched in IOMUXB. Rockbox never
switched it, so driving F2 never reached the amplifier: started from
the Rockbox bootloader, playback and the FM radio were near silent
and distorted. They only worked when the original firmware had run
first, as it switches the pin. The 16 MB of SDRAM does not use A12.
Tested on a YP-CP3 booted from the Rockbox bootloader.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Change-Id: I40610aaf88f06fd4831d07174b0f66a4ba32204d
audiohw_set_monitor() switched the output mixer from the DAC to both line
bypasses: voice and beeps went silent while the radio played, and a line
nobody listened to was mixed in, with its noise. Both line inputs were
also powered from start-up on.
- the target names the line its tuner is on, RK27XX_CODEC_FM_LINE (1 or
2); both are used where it does not say
- monitoring adds that line's bypass to the DAC instead of replacing it
- the line inputs stay in standby until monitored, and go back after
Only rk27generic uses the internal codec - the other rk27xx targets
have external DACs or codecs.
Tested on rk27generic: the radio plays through the monitored line, key
clicks stay audible over it, and playback is unaffected.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Change-Id: I177fdf605e4d997159898c868b2186c9584eb19a
- config: HAVE_RECORDING, sources microphone and FM, 8-48 kHz
- wm8751.c: the YP-CP3's own audiohw_set_recsrc(). The rk27xx cannot
send received samples straight back out, so what is heard of an input
goes through the codec's analog bypass - the input PGA into the output
mixers: the radio always, the microphone never. As in the original
firmware, the radio passes the PGA at +12 dB when only listened to,
and the microphone - mono, on RINPUT2 - gets +13 dB boost and is
recorded by the right ADC onto both channels (the original firmware's
noise gate is left out). The HD300's version assumes the microphone on
INPUT3 and headphones on OUT1, and switches OUT2 - the YP-CP3's
headphones - off.
- wm8751.c: the playback-only FM monitor added for the YP-CP3 goes; the
radio is routed by audiohw_set_recsrc() now, as on the HD300
- wm8751.h: DATSEL, which ADC feeds each channel of the output data
Only partly tested on hardware: FM radio still plays, and the recording
screen's peak meter follows the microphone. Not yet tested: a recorded
file played back, recording FM, recording gain range.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Change-Id: I3c25f4333f765d98dddc2fd722c111f8493bbe77
The YP-CP3's tuner is a Silicon Labs Si470x at I2C address 0x20, an
Si4703 by the RDS the original firmware enables. The firmware drives it
the Si470x way - writes from register 2, reads from 0x0A - starts its
oscillator with TEST1 = 0x8100 and a 500 ms wait before ENABLE, and has
no power or reset line for it.
- config: CONFIG_TUNER SI4700 with RDS, polled (no interrupt line
needed), and FM radio as an input source
- si4700.c: the YP-CP3 starts the oscillator as the Sansas do
- power-ypcp3.c: tuner power stubs - there is nothing to switch
- the rk27xx tuner I2C glue, and "radio" in the target's configure entry
- wm8751.c: audiohw_set_monitor() for a WM8750 target that plays the
radio but cannot record (rk27xx has no recording yet). The tuner, on
LINPUT1/RINPUT1, goes through the input PGA at +12 dB - as in the
original firmware - into the output mixers, the DAC staying in the mix.
The existing monitor routing lives in the recording code and switches
OUT2 off, which is the YP-CP3's headphone output.
Tested on a YP-CP3: stations tune and play at a sane level.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Change-Id: Ic097fc85dbd7fb71fcc28c97a9d378fa09599e79
The YP-CP3 uses Wolfson WM8750. Headphones are wired on OUT2 and
a headphone amplifier enabled by GPIO F2, active high -
all RE from the original firmware.
The original firmware runs the codec as I2S master in its 12 MHz "USB
mode", fed a fixed 12 MHz MCLK, which puts 44.1 kHz at 44.118. Rockbox
instead makes the rk27xx the master and clocks the codec from the codec
PLL at exactly 256 fs (CODEC_SLAVE, as every other rk27xx target with an
external codec), so the codec's CLOCKING register is its normal-mode
256 fs setting at every rate. 96 kHz is left out: the WM8750 cannot take
it at 256 fs.
- config: HAVE_WM8750, CODEC_SLAVE, rates 8-48 kHz; the WM8750 has
hardware tone controls, so HAVE_SW_TONE_CONTROLS goes
- ypcp3/wmcodec-ypcp3.c: register writes over the rk27xx I2C driver
- wm8751.c: on the YP-CP3, power on and drive OUT2 instead of OUT1, set
the volume there, and switch the amplifier with the outputs
- english.lang: the YP-CP3 gets the bass/treble cutoff settings the
WM8750 brings
Tested on a YP-CP3: playback at 44.1 and 48 kHz on headphones, pitch and
volume correct.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Change-Id: I870038fb6a21a9c26b025e3df7c220fd925f49f6
The S-35390A keeps the hour either as 0-23 or - its default after a
power-on reset - as 0-11 plus a p.m. flag, selected by the 12/24 bit of
status register 1. The driver assumed 24-hour mode and never set it: it
masked the p.m. flag off, so on a chip left in 12-hour mode every
afternoon read as morning, and writing an afternoon time stored an
out-of-range hour.
Read the mode in rtc_init() and convert the hour both ways. The chip's
mode is left alone, as another firmware on the same player may depend on
it - the Samsung YP-CP3's original firmware runs it in 12-hour mode and
never touches the bit. If the status register cannot be read, the driver
keeps assuming 24-hour mode, as before.
Upstream removed the driver with its only users, the Meizu M3/M6 and
Samsung YP-S3 ports (1a33d7990a); the Samsung YP-CP3 needs it, so it
comes back here, with RTC_S35390A and its SOURCES entry.
Also pick the I2C header by CONFIG_I2C, so rk27xx targets can use the
driver; i2c_read()/i2c_write() have the same shape there.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Change-Id: I54d8c8cfaa1b88237f6c4b08d2a510ec9fce8ec5
A host can replace an unfinished control transfer with a new SETUP. ARC
and DesignWare flush EP0 without reporting completion callbacks, leaving
the core waiting for a data/status packet that will never arrive.
Explicitly notify the core after both directions and stale completion
bits have been cancelled. Return an abandoned data/status stage to READY.
If a queued or running handler still owns the request and data buffer,
keep that ownership and suppress its response; dispatch only the latest
replacement when it returns. A driver-owned SET_ADDRESS can also cancel
a deferred request without passing its SETUP to the core.
Do not overwrite an arbitrary busy state in usb_core_setup_received().
ARC cancellation is a prerequisite in the preceding patch; DesignWare
cancels both EP0 directions before notifying and rearming reception.
Change-Id: Ia8e0a68fe47ccab952168da24a2f76e311ca2b15
Handle SET_ADDRESS directly when each controller receives SETUP, before
passing other requests to the core. Cancel transfers, send the status
response in the driver and queue usb_core_notify_set_address(); the core
only updates its address/configuration state. Remove usb_drv_set_address
and avoid a request callback from the core back into the controller.
Keep status completions for this driver-owned request out of the core EP0
state machine. ARC writes DEVICEADDR and notifies after successful status
IN completion; other controllers retain their existing register/status
ordering or automatic address handling. Use IRQ-local operations on
DesignWare rather than helpers which unconditionally re-enable its IRQ.
Take the low seven bits of wValue; do not impose new validation on the
unspecified wIndex/wLength fields. Convert all eleven firmware backends;
the separate hwstub API is unchanged.
Change-Id: I7b96275df90c14ef4a9954f04ac6fdc004ec8d6c
Fills in the stubs the Nano 3G port was left with, taking each from how
the original firmware drives the same hardware.
Testing evidence: firmware/target/arm/s5l8702/ipodnano3g/TESTING.md.
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Change-Id: Iea5314769502f5941a176600869591756c5e3233
Pure file move, in preparation for a second Ingenic SoC.
dma, gpio, i2c, installer, kernel, nand and the SPL NAND backend
move from target/mips/ingenic_x1000/ to target/mips/ingenic/
Drivers that cannot move as whole files, because part of each is
genuinely X1000-specific, are left alone for now: msc, uart, sfc, the
debug menu and the OST helpers in system-x1000.c.
Verified as a no-op: built at target 246 --type=b before and after from
the same source path, bootloader.bin is byte-identical, and every moved
file's object has the same instruction stream under its new name.
Builds clean with no warnings for targets 246, 260 and 247, both
--type=n and --type=b.
Change-Id: I9f67c23384df49b8c4554d695b772bcd54a4e32f
Co-Authored-By: Claude Opus 5
sdmmc_host looks only at the transport status the controller returns,
and passes NULL for the response of every data transfer, so nothing ever
reads R1. A card does not signal a rejected command by failing the
transfer: it answers normally and simply does not commit the data. A
write refused for a write-protect violation, an address error or an
internal ECC failure is therefore reported to the filesystem as a
success.
Add sdmmc_host_submit_cmd_r1(), which fails a command whose response
carries any bit in SD_R1_CARD_ERROR, and use it for SET_BLOCKLEN and the
read or write itself. Those responses were already being received and
discarded, so this costs no extra bus traffic.
The R1 of the transfer command is returned before the data moves, so it
cannot report a failure which happened during the transfer. Whatever
ends the transfer has to be checked too: CMD12 where it terminates a
multiblock transfer, and CMD13 (SEND_STATUS) where CMD23 was used and
there is no closing command. Without the CMD13 an error is reported only
on the next transfer, against the wrong sector.
A CMD12-terminated read which ends on the last block of the card will
have tried to read past the end, and the SD spec (4.3.3, "Block Read")
requires the resulting OUT_OF_RANGE to be ignored. It is masked out for
exactly that case.
Only valid for R1 and R1b. A controller cannot apply the check itself
because it is told the response length rather than its format, and R3,
R6 and R7 are also 48-bit responses carrying unrelated bits in the same
positions.
Affects any target building sdmmc_host.
Exercised on X1600 hardware over 8 GiB of sequential reads with no
errors; the error path itself was not observed to trigger. Not run on
X1000 hardware.
Change-Id: I4a80dd29385d3eb4f256bc745a84f96e7054bbf8
Co-Authored-By: Claude Opus 5
This commit does the following changes to the 3ds port:
- Rename the target from ctru to 3ds.
- Rename all files and functions with the ctru naming convention to 3ds.
- Created a new file and folder structure that will better integrate future console ports that share the same codebase.
- Fixed a buffer overflow bug in pcm code.
Change-Id: I17c6f86df64eb99dd2b653485d70832ff46b2ba8
Some 512G Samsung cards (and possibly other cards) seem to
have problems with repeated single block read commands and
sometimes just time out without ever sending the data. The
card response is received OK and reports no errors but no
data is received.
The problem also occurs if a multiple block read is used to
transfer a single block but doesn't seem to occur when more
than one block is transferred.
Less commonly, timeouts can occur on write commands but it
is not clear if that happens only after a timed out read.
Adding a delay of a few tens of milliseconds before each
read/write single block command appears to prevent this.
Change-Id: I5a02b71f59cc02832acaf30e5f900a3ee8804e76
According to commit 7327d9fb6c ("Implement set block count
(CMD23) for x1000 target") some cards may experience data
corruption with certain controllers when CMD12 is used to
terminate multiblock writes. Using set block count (CMD23)
is reported to fix this issue.
Following the approach in that patch, use the SCR register
to probe support for CMD23, but disable use at runtime if
CMD23 generates an illegal command error.
Change-Id: I3ee1e48939b79b848fbda12c6737f2f974f47fa0
The frame-scheduling logic cherry picked from the 'rockpod'
fork [1] was not correct for high-speed hosts and broke USB
Audio output.
The DWC seems to schedule based on the DWC_DSTS.SOFFN field,
which is a 14-bit microframe number for high-speed hosts. For
full speed hosts SOFFN is the LSB-aligned 11-bit frame number.
For high-speed hosts, USB Audio and iAP use a bInterval of 4
for the ISO endpoint which means the host sends a packet every
8 microframes. Thus, we only receive data on even microframes,
which is why adding frame scheduling broke things (and why we
got away with not doing it before).
For full speed the bInterval is 1, we get a packet each frame
and we do need to tell the core to receive on odd frames.
This code is still not completely correct for arbitrary ISO
endpoints -- for that we would need the function drivers to
provide the (micro)frame number on which they want to send or
receive.
Tested by forcing full speed at the device side by setting
USB_DW_DCFG_SPEED=3. USB Audio works fine in both high and
full speed modes now.
[1] c390dfdbdf
Change-Id: I17d283821cd0861e414c48208ca67f6e98464d7c
* Dedicated FIFO mode requires a non-zero multi-count for periodic INs
* Add ISO frame polarity
* Correct max packet size for high-speed ISOC operation
Change-Id: I2c0d40b5f8d0e1e4cf43369631f17c7f80c6fab2
The enable check read
if(r & (1 << info->en_bit) == 0)
`==` binds tighter than `&`, so this evaluates as `r & ((1 << bit) == 0)`,
i.e. `r & 0`, which is always false. The check never fired, and a supply
that was switched off reported the voltage it would have had if enabled.
Callers cannot tell "off" from "on at this voltage", so anything reading a rail back to confirm it came up gets a false confirmation.
Found by inspection while bringing up another Ingenic target. Not run on
X1000 hardware as I do not have one of these devices.
Change-Id: I19fc89ff33cce047160d826ce2344cc34b26e224
Co-Authored-By: Claude Opus 4.8
Last patch didn't swap both x and y so was wrong and messed up the coord pair
I didn't want to add more swapping due to extra overhead
ultimately the issue is that you have 1/2 pixel error (-1 0 1)
and when doing the reverse line the error is on the wrong side
so instead get the first point from the opposite dinc
Change-Id: I141c4af36a601314f2b509a9ebfcfab3b5213bcd
Enable HAVE_LCD_FLIP for the Clip Zip and implement lcd_set_flip()
in the LCD driver, making the Display -> Flip Display setting work.
This lets the player be used upside down, e.g. clipped to clothing
with the control buttons pointing up and screen on the bottom.
Defining HAVE_LCD_FLIP also activates the existing button remap in
button_flip() (firmware/drivers/button.c) for this target: while the
display is flipped, LEFT/RIGHT, UP/DOWN and the volume keys are all
swapped to match the new orientation, so the whole device is usable
upside down, not just readable.
The flip is done in hardware by reversing the controller's GRAM write
direction and mirroring the write window in lcd_setup_rect, so partial
updates keep working and there is no per-frame cost. Both panel
variants are handled: the type 0 WiseChip/SEPS114A via MEMORY_WRITE/READ
(1Dh, 0x02), and the type 1 Visionox/LD7134 via the Graphic RAM Writing
Direction register (05h, 0x03). The direction register is written in
lcd_enable(), so it is set while the panel is powered and is re-applied
after display standby; lcd_set_flip() cycles the panel off and on so a
change to the setting takes effect immediately.
For the simulator, which has no real LCD controller, lcd_set_flip() is
implemented in the SDL LCD driver (lcd-bitmap.c) as a software mirror of
the framebuffer, so the flip is visible in theme previews; the generic
uisimulator stub is guarded out when HAVE_LCD_FLIP is defined.
Tested on real type 1 / LD7134 hardware in both orientations: display
content, button remapping and album art are all correct, and test_fps
shows partial updates run at full speed when flipped (1/4 frame 325 fps,
matching the non-flipped rate). The type 0 / SEPS114A path uses the same
approach; the 0x02 direction value was confirmed to flip a type 0 panel
by William Wilgus during review.
Change-Id: I99ef13949102b344826e72d1d90c71e2271448a6
clang uses "unsigned int" for "uint32_t", which does not match gcc's
"unsigned long".
fix errors caused by this.
Change-Id: I05aaf23934167a56a6e400f49fcaf8b70bfaca13
this commit is a combination of the following changes, which
significantly refactors usb core and class drivers.
1. unify usb buffers of each class driver to reduce iram usage
currently, many class drivers allocate their own buffer to receive
control out data, which is a waste of iram.
share one common buffer for that usage to address the issue.
2. simplify control request handling by implicitly receiving write
request data packets
change 1 above fixed the data destination. therefore, having the core
receive the data allows us to reduce the class driver's work and
simplifies the api.
3. enhance usb core's control request handling and unify the legacy
driver api
in order to implement change 2, both the legacy and new driver apis
should be supported. so that, using the designware driver as a
reference, the new driver api functionality is move into usb core.
this simplifies the usb device drivers by requiring them to implement
only the functionalities equivalent to the legacy api.
tested with ipodvideo(arc) and erosqnative(designware)
Change-Id: I3627daa90278751f599e2108ec150ec3f8f6c524
the capabilities of endpoint of several devices such as dwc2 change during
runtime, so they cannot be determined during driver initialization.
therefore, allocation using ep_specs is inappropriate.
to support these devices, add functions to the driver that determine whether
endpoints are available and make allocation more flexible.
tested with ipodvideo(arc) and erosqnative(designware)
Change-Id: I8005c17f3d763cd17306bf49918e1cd8084bdeff
They haven't seen development activity for the better part
of two decades and apparently were never able to even boot
to Rockbox, although the Rockbox bootloader could load the
original firmware.
Change-Id: I5cfa5909c21feaf2825aa685a05e78044b893a13
These targets haven't seen any changes since 2008-09
have bitrotted to the point they don't compile anymore.
With only internal NAND flash for storage which doesn't
seem to have ever been accessible from Rockbox, they've
never been usable and there's probably not much point
keeping them around any more.
Change-Id: I2fc63da20682b439126672065ae013044cb2d1c4
This is mainly useful for bootloaders that want to safely
disable the SD/MMC controller before booting. Disabling a
controller will reset and power down the bus; all attempts
to read or write to a disabled controller will fail.
Change-Id: I4a7ec4287f2b8510a35d964cc806c74be8c86406
storage_sleepnow() is the one that is actually implemented
by storage drivers. storage_sleep() sends a Q_STORAGE_SLEEP
event to the storage thread, which will normally end up
calling the driver's sleepnow() function.
Change-Id: Ib6523073348431dcc75c0f10ef99060c6960efd8
Enable high speed USB for the Echo R1. Includes reasonably
complete support for full speed USB on the STM32H743 since
that was necessary to debug why it wasn't working at first
(which turned out to be a bug in memcpy, not a hardware or
driver issue).
Change-Id: Ie713195b22ba88c79b9b0d6eb289cb9ccd2763c2
This allows targets to select full speed operation instead
of the default high-speed mode, which is mainly interesting
for debugging USB communication.
Change-Id: I405ff63c6660ca03ea04282a12b59dac06ca46f5
If the PHY doesn't correctly report the ID pin state,
then the DWC2 core may operate in host mode by default.
Defining USB_DW_FORCE_DEVICE_MODE in the target config
will set the FDMOD bit in the GUSBCFG register to force
the core into device mode regardless of what the PHY
reports.
Change-Id: If2391aaa4a7c65ba6c90dd56074faeb3ed1ac2ca
Two cache discards for targets with POST_DMA_FLUSH were
not properly guarded by USB_DW_ARCH_SLAVE, which causes
data loss when DMA is disabled.
Change-Id: If14ffdc5662f77b3ff57a04c5b9f94d4cac7e514
sdmmc_host is a portable driver for targets with SD/MMC
storage. It handles all the logic needed to initialize
and access SD/MMC devices which is common to all targets.
Targets only need to implement functions to issue SD/MMC
commands, manage clocks & power, and managing the insert
state of the card (if it is hotswappable). This vastly
reduces the work needed to get a new SD/MMC based target
up & running.
At present it's only written for and tested with SD cards,
as I don't have access to an MMC-based target to test on.
Change-Id: I6a0d7747113c11a3697ae20cbb551bef8bfd1292
