SD-card upload, boot video working

[jeffreyjacques]

Undocumented rev C filesystem / media protocol (SD-card upload, boot video) — interest in upstreaming?

Summary

While getting a Turing 5" rev C (chs_5inch.dev1_rom1.88) working on Linux, I
reverse-engineered the vendor Windows app (TURZX.exe) and found that the rev C
serial/COM device class (the one that parses chs_5inch.dev1) implements a
filesystem + media protocol layered over the ordinary rev C packet format —
none of which is documented here today. I've verified the commands below on real
hardware, and I have working Python tooling for them.

Before proposing any code, I'd like to gauge whether you want this upstream, and
in what form. Big caveat up front: everything below is verified on one
unit (5", ROM 88). The rev C family (2.1"/2.8"/8.8") shares unreliable USB IDs,
so I can't promise the command set or mount paths are identical on other sizes.
That uncertainty is exactly why I'm opening a discussion rather than a PR.

What the protocol looks like

Same rev C framing as everything else — [cmd][0xEF69 BE][param u32 BE][flag][00 00][payload], padded to 250 B. For the file commands, param = ASCII path
length and the payload is the path.

Cmd	Operation	Notes	Verified
0x64	QuerySdCard	returns flashTotal-flashUsed-flashValid-sdTotal-sdUsed-sdValid	✅ read-only
0x6E	GetFileSize	param = path length, payload = path	✅ read-only
0x65	QueryDir	creates the directory if missing (nodir-createdone)	✅ side-effecting
0x6F	UploadFile	ascii(path) + uint32_le(size), wait create_success, stream body as 250-byte frames carrying 249 B each; firmware truncates to declared size, answers file_rev_done	✅
0x78	StartVideoPlay	plays a file already on the card	✅
0x8C	PlayImage	shows an image already on the card	✅
0x66	DelFileOrDir	destructive — listed for completeness; my tooling refuses to construct it	⚠️

Other things confirmed on hardware:

• The unit mounts its SD card at /mnt/SDCARD/ with img/ and video/
  subfolders; internal flash is /mnt/UDISK/ (Allwinner SoC).
• Boot video = whichever file was last played via 0x78 — that choice
  survives power cycles. Combined with the display's power-on start mode, this
  lets a rev C unit with an SD card play a video at power-on before any host
  connects.

Why it might be worth having

• Put images/videos on the SD card over USB, no card reader or disassembly.
• Set a boot animation / standalone splash for a display that isn't always
  attached to a running host.
• It pairs naturally with a small STARTMODE option for rev C (replay last
  image/video at power-on) that I've also been looking at.

What I already have

Working, hardware-tested Python: an SD-card/query probe, an uploader (dry-run by
default, 0x66 intentionally not constructible), and an imageio-ffmpeg
converter that produces the h264/yuv420p MP4 the firmware actually accepts (its
help text claims GIF support, but the panel doesn't play GIF).

Questions for you

1. Do you want this upstream at all, given it's vendor-undocumented and
   verified on a single unit?
2. What form fits the project best?
   • tools/ scripts (lowest commitment, honest "tested on these units" framing), or
   • first-class LcdCommRevC methods (UploadFile / DisplayVideo), which
     implies broader rev C support I can't currently guarantee, or
   • a simple-program.py-style example.
3. How would you want the destructive 0x66 handled — omit entirely, or
   document-but-never-construct (what I do now)?
4. Do you have access to other rev C sizes (2.8"/8.8") to help confirm the
   command set generalizes before anything ships?

Happy to open focused PRs (read-only queries first, then upload/play, never
delete) once you've signalled a direction. Thanks!