CONFIG_RK27XX_FTL selects the FTL a target's NAND uses,
RK27XX_FTL_SCHEME_A or RK27XX_FTL_SCHEME_B. rk27generic and the YP-CP3
are Scheme A, the HM-60x Scheme B. ftl-rk27xx.c mounts the one named;
for Scheme B it maps the drives onto the volumes ID block 1 records:
the system disk from LBA 0, the user volume after the system data
area.
The other rk27xx targets with NAND - HM-801, MA8, MA8C, MA9, MA9C and
iHiFi 760, 770, 770C, 800, 960 - have no confirmed scheme. They drop
the NAND from storage and build only the FTL scheme finder, so users
can report what their device holds and the scheme can then be set.
Only Scheme A flushes at shutdown: Scheme B holds nothing in RAM.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Change-Id: I484217b82c6de7316b90b354c012bfbaa263b3dd
Many rk27xx targets have NAND whose format nobody has examined. The
finder reads ID block 1 and the first page of the first 512 blocks and
says which FTL formatted them: Scheme A by its remap-log blocks,
Scheme B by its bad-block table and data headers, another Scheme B
generation by other 0xFxxx tags. The later ID block layout ('RK27' at
0x0a) records the FTL area's BCH strength at 0x1ed - 8 on the HM-601,
14 on the Archos Vision 28 - and the scan reads in that mode.
It is read-only, shown in the debug menu as "View FTL scheme", and
built for targets whose NAND is not storage - none yet.
Run on dumps of an HM-601 it reports Scheme B, a Samsung YP-CP3
Scheme A, and an Archos Vision 28 the other Scheme B generation.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Change-Id: I0528f9d2a6996089b6488a77b43942f6fd1f2c16
ftl-rk27xx.c has been four empty stubs since 2010. Fill them in with
the flash translation layer the rk2705/rk2706 original firmware uses,
called Scheme A here to tell it from the log-structured layout of later
firmware. It reads and writes that format exactly as the original
firmware does, so a device keeps working with its original firmware
after Rockbox has written to it.
- ftl-scheme-a.{c,h}: the FTL. The file opens with a description of
the on-flash format and how the FTL works: the SYS and USER volumes,
super-blocks and zones, the zone table, the remap log and its mirror,
the exchange record and the write protocol, power-loss recovery, bad
blocks. Oddities of the original firmware kept for compatibility are
marked where they are.
- Parameters that differ between firmware builds - the zone reserve
base, the system zone offset, the format flag - are recovered from
the media at mount and checked against its structure; a mount that
cannot confirm them is read-only. A mount that would have to repair
the remap log while not allowed to write fails rather than serve
wrong data.
- ftl-rk27xx.c: the storage glue. It finds the boot area's ID block,
which records where SYS ends, and mounts the FTL.
- ata-nand-rk27xx.c: a drive per volume. SYS holds the original
firmware - on a Rockbox device including the BASE.RKW that chainloads
the bootloader - and nothing of the user's, so it is a drive only when
the target defines HAVE_RK27XX_NAND_SYS. Capacity comes from the FTL's
tables, not from raw block geometry.
- config.h: HAVE_STORAGE_FLUSH for the rk27xx NAND. The FTL holds up to
three part-written pages in RAM; storage_flush() commits them at
shutdown and ROLO.
Writing is opt-in: without FTL_ALLOW_WRITE the FTL mounts read-only and
never writes the flash, not even a repair the mount could make.
Two bugs of the original firmware are not reproduced. A write starting
before a page held part-written in RAM and running through it left two
buffers holding that page, and the older one was later programmed over
the newer data; such a write now flushes the held page first. And its
bad-block marker took two of its three metadata bytes from the stack,
which can make a retired block look like a remap-log block; the marker
is now written in full.
Tested in a host simulator on NAND images of a Samsung YP-CP3 and a
generic rk2705, against the original firmware's FTL object run under
qemu-arm: identical traces of every read, program and erase, with a
hash of the data each program writes, over mounting and reading, random
writes with every sector verified, a power cut at every flash operation
of a write, and a program or erase failure at every one.
On a generic rk2705: the read-only mount reports the layout and
capacities the original firmware does and every file's MD5 matches; a
write test passes 8192/8192 across a remount and a power cycle.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Change-Id: I573d944389cefb456ecf38c6c7b91bebfe0fe377
flash-rk27xx.c drives the NAND controller and its BCH engine for the
flash translation layer that follows. It knows the chip's geometry and
how to read, program, erase and copy sectors, but not what the sectors
mean.
- Addresses are 512-byte sectors in a linear view of the chip where a
block is a super-block: on a two-plane part, one physical block from
each plane, consecutive pages alternating between them. The layer
maps that view to the chip; the FTL never sees planes.
- Every sector carries 16 spare bytes: 13 of BCH code, generated and
checked by the hardware, and 3 for the FTL. Byte 1 is written 0x00 on
every program - the "page programmed" marker the original firmware's
FTL keys its mount and recovery on.
- The program sequence was read out of the original firmware's own
machine code. The write kick is the read kick plus FL_WR, and the BCH
engine needs BCH_WR to encode rather than decode.
- A copy is read through the ECC engine and programmed, never the
chip's internal data move, which on this MLC part would carry bit
errors forward.
- Writes are refused until the FTL enables them, and writes into the
boot area are dropped and reported successful, as the original
firmware does. The write-protect line is lifted only for the duration
of each program or erase.
- Failures and timeouts are counted: the FTL can act on few of them.
Only the first chip is handled; every device the FTL has been checked
on has one.
Tested on a generic rk2705 directly, on a free block: a program across
both planes, a single-sector program with metadata, a whole page, a
copy and an erase each read back byte-exact through the controller's
ECC decode, which also shows the code it generated is valid.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Change-Id: If6ffa9f9811172f4f8829c1e68d6de9466a022c8
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
Scaffolding for a port, starting from the rk27xx generic target: configure
entry 146 (target id 117, model number 132), config/samsungypcp3.h, and
firmware/target/arm/rk27xx/ypcp3/.
- LCD: the rk27xx LCD interface (lcdif-rk27xx.c) with this panel's init
sequence, from RE. See g#1050. Looks like SPFD5420A 18-bit bus,
400x240 landscape. It differs from the generic panel's sequence in the
gamma curve and in not writing VCOM_HV1.
- Backlight: PD4 / PWM0 with the generic board's timing, which the hwstub
work found to be the same.
- Storage: the microSD slot. Card detect is PC7, active low,
as on the generic board.
- Keys: the YP-R0's key set - five-way yog, Back, Menu, Rec/User, Power -
so the target uses SAMSUNG_YPR0_PAD and its keymaps. Eight keys sit on
two resistor ladders on the LSADC, found in the original firmware and
measured on a unit:
channel 1 up 158, down 295, select 435, left 561, right 687
channel 2 menu 155, back 292, user 431
each key owning half a step either side of its reading;
power is GPIO C1, active high.
Builds as firmware and as bootloader. Status 3 (unusable) in builds.pm.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Change-Id: Iff4984023415f341ca7507af6b5b2b551201e953
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
Rockbox only drives NAND parts proven on hardware, and this tree has one
model to prove them on. This is the image that lets an owner of another
Nano 3G supply what validating theirs takes: a bootloader built with
-DNAND_CHECK and run from DFU, which never touches the NOR flash or
writes to the NAND.
Testing evidence: firmware/target/arm/s5l8702/ipodnano3g/TESTING.md.
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Change-Id: I46328b69f8011337790f35a195de97b5bcf347a5
The Nano 3G keeps everything behind the S5L8702 flash controller and
Apple's FTL ("Whimory"), and nand-nano3g.c was a stub, so the port had
no storage at all. This is the flash driver, the FTL and the wiring that
makes the NAND Rockbox's disk. The three are one change because neither
half is usable without the other: the driver alone cannot see a
filesystem, and the FTL alone has nothing to drive.
Testing evidence: firmware/target/arm/s5l8702/ipodnano3g/TESTING.md.
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Change-Id: Ib04a991489ff3a1a63cd55552e4a8d7ec7a5fc8c
Add S5L8702 VPU-B initialization, reset, bitstream input, frame output,
and cache maintenance to the iPod 6G target. Advertise it with
HAVE_HW_H264 and append a capability-gated decoder interface to the
plugin API.
Keep MP4 parsing, AAC decode and mixer output, A/V synchronization,
playback controls, resume state, and presentation in the multi-file
h264_player plugin. The target layer exposes decoder operations only.
Accept non-fragmented MP4/M4V containing Constrained Baseline H.264
through level 3.0, up to 640x480 at 30 fps, with optional AAC-LC audio.
Validate codec configuration and all sample-table relationships before
activating the hardware.
Read MP4 tables in bulk, boost the CPU while preparing them, and report
staged loading progress so long movies do not appear to hang during
startup.
Register the viewer and document its format limits and controls. The
libm4a compatibility fixes needed by video-first containers remain in
the preceding standalone change.
Tested on an iPod Classic 6G through an isolated Rolo nightly runtime:
H.264/AAC playback and M4V startup succeeded. Normal and
isolated-runtime iPod 6G builds also complete, and git diff --check is
clean.
Change-Id: I1e96c65c7d0b4231a94f602f8052f1b26d6e4a80
Add NTSC composite output for the iPod Classic 6G/7G using the
S5L8702 video processor, mixer, and encoder. Reconstruct the setup used
by the original firmware and mirror the 320x240 LCD in a centered
648x432 viewport.
Expose the driver through HAVE_COMPOSITE_VIDEO_OUT and a
target-neutral videoout interface. Keep the S5L8702 MMIO layout and
register definitions with the other SoC definitions in s5l87xx.h.
Convert LCD updates from RGB565 to planar YUV420. MPEG playback copies
decoded YUV420 planes directly, avoiding an RGB round trip. Hold output
clocks and CPU boost only while the memory-backed layer is active, and
restore them on disable or power-off.
Defer dock identification out of the serial tick because the accessory
resistor ADC path sleeps. Auto detection recognizes the measured Philips
DCP750/37 resistor range; manual mode can qualify other attached docks.
Leave interrupts enabled during the encoder's 10 ms reset wait so PCM
DMA can service linked-buffer completions when a dock is inserted during
audio playback. Keep reset assertion, reset release, all SVID register
writes, and pipeline start atomic so the composite setup cannot
interleave.
Hardware tested on an iPod Classic 6G/7G with a Philips DCP750/37 for
correct colors and geometry, stable UI mirroring, and full-screen MPEG
playback.
Change-Id: I669f2477d5cc707b48f7d24384c713d874a80e3f
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
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
Remove all SD protocol handling and all target specific code
like GPIO/interrupt handling and clock parent setup. This can
now be handled from sdmmc_host_target_init() for each target.
Now only the clock frequency is managed by the MSC driver.
To make this code easier to factor out later, it's confined
to helper functions that do not access the driver state.
One small change is that MSCxDIV output is now clamped to a
minimum of 50MHz to avoid unnecessary frequency changes. The
MSC_CLKRT divider can still divide 50MHz down to 400 KHz so
there is no downside to this.
Auto-CMD12 is now unused. Using it would make error handling
more difficult for sdmmc_host since the controller does not
expose response data for the auto-CMD12.
Explicit CMD12 was not handled correctly in the old version
of the driver because the busy signal was ignored for R1b
responses if there was no associated data transfer. This is
now fixed by waiting for the PRG_DONE interrupt instead of
END_CMD_RES for non-data transfer R1b type commands.
Since existing X1000 targets are all very similar they use
a shared implementation in sdmmc-x1000-common.c for clock
setup and card detection. New targets can either use this
or create a separate file if they are different enough to
warrant one.
Change-Id: I35396637325d7c06a10151bb6aee64cabdc7b682
HibyOS-based target: keymaps, LED, powermgmt, bootloader and sim support,
plus cabbiev2 for the new 360x640x16 screen. Opus 5 helped w/ debugging
and the initial scaffolding.
Updated name to FB_STRIDE_MISMATCH, added simulator bmp and specs.
Change-Id: If797ac6581cf75d9d1fcf36e615ee03cf6f905d6
Decode the jack remote's play/pause and volume buttons via the
"Mikey" controller (I2C 0x72) and report them as multimedia keys so
they work on every screen, like the OF. Protocol reverse engineered
on-device, notes in mikey-6g.c.
Change-Id: If5f3d3abf043c0ce0d8ca7beb0f4b591e41c5c43
Implement the USB Audio Class DAC on the HiBy R1 and R3ProII, driven by
the usb_audio setting from the scaffolding patch: the host plays audio
over USB and the player's CS43131 renders it.
The vendor kernel provides a UAC gadget function "uac_sa" whose char
device /dev/uac_sa delivers the host's PCM: the isochronous OUT frames
are converted to left-justified S16-in-S32 stereo and queued in a kernel
ring, drained with a non-blocking read(). The data path lives in
usb-dac-hiby.c -- a pump thread drains /dev/uac_sa into a small
single-producer/single-consumer ring and the mixer callback hands that
PCM to the codec through the normal ALSA output path. No resampling is
needed because Rockbox clocks the codec at the host-negotiated rate.
The DAC is built on the existing configfs gadget and binds the UDC like
ADB, while usb_power_only keeps the USB thread out of the way. In charge
mode it is a standalone self-bound gadget. In adb mode it is composed
alongside adb on one gadget so the host gets a sound card and adb at
once; uac_sa must be the first-linked function (audio interfaces 0-1)
because the vendor function hard-codes its interface numbers.
The pump is hardware-only, so usb-dac-hiby.c is excluded from simulator
builds; the usb_audio_get_active() playback-interlock stub lives with the
scaffolding.
The R3ProII shares this hosted HiBy port and the same userspace gadget,
and the data path is codec-agnostic, so nothing here is R1-specific.
Only the R1 has been validated on-device.
Co-Authored-By: Claude Opus 4.8
Change-Id: I64c57ede27f411a2c61d41a7e0fa127b51a7b5b9
add class driver source files.
also register iap audio sink.
usbstack/iap/libiap directory is imported from libiap.
Change-Id: I776c5caec33fe9efadc448e2e3b37d500bf19c9f
Remove now-unused stuff related to the PNX0101 processor,
which was missed during the removal of the IFP-7xx port.
Change-Id: I5ff248b3e83cb67a357743130c3e51ed84a720e5
Playback is implemented using a target-specific PCM layer,
using the STM32H7 SAI & DMA registers directly. There are
a number of pop/click issues:
1. Slight click when powering up the amplifiers
2. Click when starting and stopping playback
3. Popping when changing playback frequency
4. Popping when shutting down
It should be possible to eliminate or at least mitigate
(2) to (4) in software, but (1) happens as a result of
powering on the amplifiers while everything is muted so
might be unavoidable.
Change-Id: I398b66596176fb2341beb7deba7bf6f4f3fb82b3
I'm leaving it enabled because that's clearly the intent
of the bootloader, but at least there's now an easy path to disabling it
if so desired.
Change-Id: I4f4ecc9a453d376f92e411e0544b587fe4b4c864
This way we don't need to stub out a bunch of functionality when we
don't have any actual USB class drivers enabled.
Change-Id: Ia0ecf5be4bb41bebfcd347090959f3204a2aba59
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
Allow toggling the system debug state from the debug menu
in Rockbox, or by holding a button combo at boot, so that
an SWD/JTAG debugger can be attached to normal non-debug
builds without too much hassle.
Change-Id: Iee47ef916ade2e5ec1094a63c68e48f1b27b0bbb
Both targets were part of the (presumably dead) Lyre project
and no longer build. The Mini2440 was much more complete than
the Lyre and doesn't seem terribly difficult to fix up to the
point where it at least builds, if someone still cares -- but
given it is a dev board in a box, it's unlikely it ever saw
much use.
Change-Id: I09745379d28db69ea9aaf77f0a62b049884260e1
It doesn't seem to have been functional ever and currently
doesn't build; eg. the last commit to the LCD driver added
a syntax error, and there's some duplicate functions between
mmu-armv6.S and system-pp502x.c. Doesn't seem worth the
effort to fix.
Change-Id: I82b5bec3ed9686f28aedbe283818af792b96daf4
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
It looks like the GDB stub only ever worked for the Archos
Recorder and iRiver IFP-7xx, neither of which are in-tree
any more.
Change-Id: If1910675b88b4707d26df9bc095818902af2d25b
The intent here is that when HAVE_USBSTACK is not defined, or we are
in a bootloader wthout HAVE_BOOTLOADER_USB_MODE, a device may still
some of USB subsystem initialized. For example, this may be needed
to enable USB-based charging functionality.
So, get rid of the blanket enables of USB_FULL_INIT based on target SoC,
enabling HAVE_BOOTLOADER_USB_MODE on targets that need it, and clean up
the initial mess. Most of this mess is because usb_core.c has no sense
of USB_FULL_INIT or not, and is always included when HAVE_USBSTACK is
set (even in bootloaders without BOOTLOADER_USB_MODE), but dealing with
that latter case will come later.
Change-Id: I7f805b89dded39aeea2db9038209780069e3b600
This is a small & simple ELF loader which just copies
program segments from disk to memory. It only supports
static binaries right now.
Change-Id: I8944feb5b9dafcc5c56e12383aed25e2718ad7ea
The clock helpers are only used for leaf clocks of single
peripherals, which don't benefit from reference counting.
Change-Id: Ica5685e7bc0fce621ae46f758f0ad0b1dcfb2789
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
Add CONFIG_BINFMT to select the binary format used for
plugins/codecs and define two options for the existing
implementations (native ".rock" format or dlopen-based).
Split the load_code.h header into two separate headers
to make it look less messy.
Change-Id: Ibd66773160df35a8c6f29a617d12c961bdabf317
Enable pullups on SDMMC CMD/DATx lines and set output
speed to medium. Using HIGH and VERYHIGH speeds seems
to cause data corruption, with frequent CRC failures.
Change-Id: I732d19e03a2a857453755b68b6749497eafaef70
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
