update docs
This commit is contained in:
+150
-2
@@ -4,14 +4,42 @@ FDS includes `dasungd` for the configured Dasung Paperlike 13K grayscale monitor
|
||||
The controller starts during early boot and remains supervised in the base system,
|
||||
including console-only use. No GUI or ENVIRONMENT cartridge is required.
|
||||
|
||||
For installation, disk preparation and first power-on, start with
|
||||
[Run FDS on a Raspberry Pi 5](hardware-setup.md).
|
||||
|
||||
The supplied profile uses the dedicated monitor's EDID and USB companion identity,
|
||||
with raw mode 1 and contrast 4 as startup defaults. It is specific to that monitor;
|
||||
do not use its identity as a blanket match for other CH340 USB devices.
|
||||
|
||||
## HDMI plus USB-C on the Pi
|
||||
|
||||
Use the Pi's **micro-HDMI output** for video to the monitor's HDMI input. Use a
|
||||
separate **USB-A-to-USB-C data cable** from a Pi host port to the monitor for
|
||||
controller access, and power the monitor with its supplied DC adapter. The
|
||||
Pi's own USB-C connector is its power input; it does not output USB-C video.
|
||||
See the [wiring table](hardware-setup.md#2-wire-hdmi-video-usb-control-and-power-separately),
|
||||
[official Pi display guidance](https://www.raspberrypi.com/documentation/computers/getting-started.html#display),
|
||||
and [DASUNG's power guidance](https://shop.dasung.com/pages/q-a).
|
||||
|
||||
HDMI video and USB controller access are separate checks. The daemon talks USB
|
||||
regardless of the video cable, but the HDMI-plus-USB arrangement still needs to
|
||||
expose the expected UART and companion bridge on this monitor. HDMI alone does
|
||||
not carry the daemon's control protocol. A charge-only cable or a USB-C lead
|
||||
connected only to a charger cannot provide host USB control.
|
||||
|
||||
The image currently supplies a firmware EDID override for 3200 × 2400 at about
|
||||
37 Hz, recorded on the original workstation. DASUNG says some HDMI hosts need
|
||||
27 Hz instead; that does not establish which mode the Pi and this cable will
|
||||
accept. The forced profile can prevent using the monitor's native HDMI mode
|
||||
list. Use the diagnostic procedure below if needed; neither Pi HDMI compatibility
|
||||
nor physical power-cycle recovery is recorded as passed yet.
|
||||
[Manufacturer HDMI note](https://shop.dasung.com/pages/dasung-paperlike-13k-the-worlds-first-13-3-inch-37hz-3k-e-ink-monitor).
|
||||
|
||||
## Inspect the controller
|
||||
|
||||
The controller's socket is restricted to root. From a root maintenance console
|
||||
on FDS:
|
||||
The controller's socket is restricted to root. Use the local `RECOVERY#` console
|
||||
described in [Enter recovery](recovery.md#enter-recovery); the ordinary `FDS>`
|
||||
account cannot access it. On FDS recovery:
|
||||
|
||||
```sh
|
||||
dasungd status
|
||||
@@ -40,6 +68,126 @@ Inspect `/run/log/dasungd/current` and the reported status. Discovery requires
|
||||
the configured DRM EDID and matching USB companion topology. An ambiguous match
|
||||
is rejected. Set `usb_path` only after identifying the intended device topology.
|
||||
|
||||
At `RECOVERY#`, start with:
|
||||
|
||||
```sh
|
||||
lsusb
|
||||
lsusb -t
|
||||
dasungd status
|
||||
dasungd query
|
||||
tail -80 /run/log/dasungd/current
|
||||
```
|
||||
|
||||
The existing profile expects UART `1a86:7523` alongside SPI bridge `1a86:5512`
|
||||
under the same hub. If neither appears, check monitor power, its USB data port,
|
||||
the cable and the Pi host connection. If only one appears, preserve the USB tree
|
||||
and log: the cable/input combination has not yet satisfied the current profile.
|
||||
Do not disable companion checks or match every CH340 device to hide the failure.
|
||||
|
||||
`status` separates `connected` from `responsive` and includes `usb_error`,
|
||||
`display_error`, `displays`, `rx_frames` and `last_rx_ms_ago`. `query` queues
|
||||
requests; run `status` again after replies arrive. Keepalive packets being sent
|
||||
are not themselves evidence that the monitor answered.
|
||||
|
||||
Capture the actual DRM connector names and EDID at `RECOVERY#`:
|
||||
|
||||
```sh
|
||||
mkdir /tmp/dasung-hdmi
|
||||
cat /proc/cmdline > /tmp/dasung-hdmi/cmdline.txt
|
||||
for fds_connector in /sys/class/drm/card*-*; do
|
||||
[ -f "$fds_connector/status" ] || continue
|
||||
fds_connector_name=${fds_connector##*/}
|
||||
printf '%s: ' "$fds_connector_name"
|
||||
cat "$fds_connector/status"
|
||||
cat "$fds_connector/modes"
|
||||
cp "$fds_connector/status" "/tmp/dasung-hdmi/$fds_connector_name.status"
|
||||
cp "$fds_connector/modes" "/tmp/dasung-hdmi/$fds_connector_name.modes"
|
||||
cp "$fds_connector/edid" "/tmp/dasung-hdmi/$fds_connector_name.edid"
|
||||
done
|
||||
```
|
||||
|
||||
Use a new directory for each capture and save it before shutdown using
|
||||
[machine diagnostics](internal-storage.md#save-and-retrieve-diagnostics).
|
||||
An empty EDID on a disconnected connector is expected. The `modes` file lists
|
||||
available resolution names, not proof of the active refresh rate or picture
|
||||
quality. With `drm.edid_firmware` active, the EDID you read may be the supplied
|
||||
override; capture again without it to learn what HDMI actually advertises.
|
||||
|
||||
The configured DRM serial is `L56051794302`. Native HDMI EDID might identify the
|
||||
display differently from the recorded USB-C profile. With `require_display=true`,
|
||||
an identity mismatch can leave USB control disconnected even when HDMI video
|
||||
works. Retain the native EDID, USB topology and errors for a deliberate profile
|
||||
update; do not silently remove identity checks. Config changes must ultimately
|
||||
be rebuilt into both early boot and base/recovery images. The read-only
|
||||
`/etc/dasungd.toml` is not a persistent settings editor.
|
||||
|
||||
## Try the monitor's own HDMI EDID
|
||||
|
||||
Use this when the stock forced timing gives a blank or unstable picture, or when
|
||||
temporarily connecting a different HDMI display. The override currently applies
|
||||
to connected DRM outputs without a connector qualifier, so attaching another
|
||||
screen while retaining it is not an independent native-mode test.
|
||||
|
||||
Follow the offline edit procedure below. In the disk's **single-line**
|
||||
`cmdline.txt`, remove only this token for the EDID experiment:
|
||||
|
||||
```text
|
||||
drm.edid_firmware=edid/dasung-paperlike13k-37hz.bin
|
||||
```
|
||||
|
||||
For verbose diagnosis with a USB keyboard and display console, a complete
|
||||
command line based on the current production template is:
|
||||
|
||||
```text
|
||||
console=tty1 rdinit=/init ro loglevel=7 vt.global_cursor_default=0 fds.boot=normal fds.debug=1
|
||||
```
|
||||
|
||||
For the serial boot mode, retain `console=ttyAMA10,115200` after `console=tty1`
|
||||
instead. Use `fds.boot=recovery` in place of `fds.boot=normal` when intentionally
|
||||
booting recovery; never append a second conflicting `fds.boot` option. Do not add
|
||||
`fds.emulator=1` on real hardware or replace stage0 with a Raspberry Pi OS
|
||||
`root=…` command line.
|
||||
|
||||
Reboot and repeat the DRM/USB capture. Removing the override allows the monitor's
|
||||
HDMI EDID to supply modes; it does **not** guarantee 27 Hz or fix missing USB
|
||||
control. Record any change in picture and controller status. Restore the saved
|
||||
command line to return to the shipped profile. Keep both captures so a future
|
||||
HDMI profile change can be based on observed timings and identity.
|
||||
|
||||
### Edit the BOOT command line offline
|
||||
|
||||
Shut FDS down and disconnect Pi power. Connect NVMe to the Linux workstation, or
|
||||
boot the separate maintenance SD and access the inactive NVMe there. Identify
|
||||
the same disk by model/serial used when flashing it. Mount only its first
|
||||
partition, labeled `FDS_BOOT`; FDS does not normally mount it at
|
||||
`/boot/firmware` as Raspberry Pi OS does.
|
||||
|
||||
On that **workstation or maintenance OS**, replacing the partition path below:
|
||||
|
||||
```sh
|
||||
lsblk -p -o NAME,MODEL,SERIAL,SIZE,TYPE,PARTLABEL,MOUNTPOINTS
|
||||
sudo mkdir -p /mnt/fds-boot
|
||||
sudo mount -o nosuid,nodev,noexec \
|
||||
/dev/disk/by-id/REPLACE_WITH_VERIFIED_NVME-part1 /mnt/fds-boot
|
||||
sudo cp -n /mnt/fds-boot/cmdline.txt /mnt/fds-boot/cmdline.before-hardware.txt
|
||||
sudoedit /mnt/fds-boot/cmdline.txt
|
||||
cat /mnt/fds-boot/cmdline.txt
|
||||
sudo umount /mnt/fds-boot
|
||||
```
|
||||
|
||||
Check the identity before the mount and stop on any failed step. If the partition
|
||||
was automounted, unmount that instance first. Keep `/mnt/fds-boot` dedicated to
|
||||
this operation. The no-clobber copy retains an existing backup; if repeating the
|
||||
experiment, inspect that backup and skip the copy step if it already exists.
|
||||
Do not assume an older backup contains your latest settings. Keep `cmdline.txt`
|
||||
on one line and record its final contents with the
|
||||
test session. Safely disconnect the enclosure before moving NVMe back to the Pi.
|
||||
|
||||
To undo the edit, mount the same verified partition again, restore
|
||||
`cmdline.before-hardware.txt` over `cmdline.txt`, and unmount before rebooting.
|
||||
These edits change the flashed copy only; they do not change the source images
|
||||
or their recorded hashes. Reflashing restores the image's original command line.
|
||||
|
||||
FDS uses the daemon for USB control. Its configuration disables the original
|
||||
workstation-specific display hotplug procedure. Video mode and cabling are part
|
||||
of the machine's boot/display configuration. The detailed protocol, build
|
||||
|
||||
Reference in New Issue
Block a user