QY8255NA (JDM, ARM/QY8XXX build): dead touchscreen after Write NAND cycle — request for unattended Write NAND flag + packaging question

[trombocit]

Hardware: Clarion QY8255NA (Nissan Connect, JDM, serial 00000813), confirmed ARM32/THUMB QY8XXX build config (independently
disassembled — not the SH4/QY7XXX config).

Symptom: after alternating a few Write NAND runs from a known-good backup with some Xanavi installer boot attempts, the head
unit is now stuck cycling BL-SY-01 (occasionally falls back to BL-UP-10). On a freshly-written/verified 109-beta SD, the full
LeafSDTools menu renders fine (LCD alive), but the touchscreen doesn't respond at all. We traced this to Touch.cpp — the input
loop only listens to the TPL1:/LCD1: touch driver IOCTL; there's no WM_KEYDOWN/VK_* handling anywhere, so a USB keyboard
genuinely can't help either (confirmed by testing, then confirmed in source — not a wiring issue).

We have a valid NAND+SRAM+VFlash backup taken before the trouble started (64 MB NAND, matches (MAX_BLOCKS+1)*bufferSize for
QY8XXX), but can't run Write NAND to restore it because of the dead touch.

Ask 1 (feature request): RunReadNAND() already has an unattended path via \SystemSD\dumpnand.txt → RunReadNAND(true).
RunWriteNAND() has no equivalent — it's hard-gated on WaitForTouch(INFINITE) in WriteNAND_QY8.cpp. Would you consider an
analogous flag-file (e.g. \SystemSD\writenand.txt) that bypasses the touch wait while keeping the existing backup-size
validation? Would help anyone else who ends up with a dead touchscreen but a good backup, not just us.

Ask 2 (packaging question): We independently confirmed the ARM/THUMB QY8XXX config links only against standard WinCE libs
(commctrl/coredll/ceddk/ddraw) — no proprietary Clarion SDK needed to compile, matching what issue #6 found. We wrote a
ROMHDR/TOCentry parser and exhaustively scanned the full 9.66 GB LeafSDTools-109.img (every ECEC container in the entire
bootable region, plus a full binary string search) — LeafSDTools.exe doesn't appear anywhere as a named file in the SD image.
So it must be packaged directly into the NK ROM image. Could you share how you package a compiled .exe back into the bootable
image — is it binmod/romimage.exe against a Platform Builder BSP, and is that BSP (or just the packaging steps) something you
could point us to?

Happy to share our findings (ROMHDR layout, ECEC container format, exact scan coverage) if useful for other QY8XXX owners hitting similar issues (looks related to the pattern in #4 and the JDM-suffix question in #11).

[developerfromjokela]

Hardware: Clarion QY8255NA (Nissan Connect, JDM, serial 00000813), confirmed ARM32/THUMB QY8XXX build config (independently disassembled — not the SH4/QY7XXX config).

Symptom: after alternating a few Write NAND runs from a known-good backup with some Xanavi installer boot attempts, the head unit is now stuck cycling BL-SY-01 (occasionally falls back to BL-UP-10). On a freshly-written/verified 109-beta SD, the full LeafSDTools menu renders fine (LCD alive), but the touchscreen doesn't respond at all. We traced this to Touch.cpp — the input loop only listens to the TPL1:/LCD1: touch driver IOCTL; there's no WM_KEYDOWN/VK_* handling anywhere, so a USB keyboard genuinely can't help either (confirmed by testing, then confirmed in source — not a wiring issue).

We have a valid NAND+SRAM+VFlash backup taken before the trouble started (64 MB NAND, matches (MAX_BLOCKS+1)*bufferSize for QY8XXX), but can't run Write NAND to restore it because of the dead touch.

Ask 1 (feature request): RunReadNAND() already has an unattended path via \SystemSD\dumpnand.txt → RunReadNAND(true). RunWriteNAND() has no equivalent — it's hard-gated on WaitForTouch(INFINITE) in WriteNAND_QY8.cpp. Would you consider an analogous flag-file (e.g. \SystemSD\writenand.txt) that bypasses the touch wait while keeping the existing backup-size validation? Would help anyone else who ends up with a dead touchscreen but a good backup, not just us.

Ask 2 (packaging question): We independently confirmed the ARM/THUMB QY8XXX config links only against standard WinCE libs (commctrl/coredll/ceddk/ddraw) — no proprietary Clarion SDK needed to compile, matching what issue #6 found. We wrote a ROMHDR/TOCentry parser and exhaustively scanned the full 9.66 GB LeafSDTools-109.img (every ECEC container in the entire bootable region, plus a full binary string search) — LeafSDTools.exe doesn't appear anywhere as a named file in the SD image. So it must be packaged directly into the NK ROM image. Could you share how you package a compiled .exe back into the bootable image — is it binmod/romimage.exe against a Platform Builder BSP, and is that BSP (or just the packaging steps) something you could point us to?

Happy to share our findings (ROMHDR layout, ECEC container format, exact scan coverage) if useful for other QY8XXX owners hitting similar issues (looks related to the pattern in #4 and the JDM-suffix question in #11).

Hi.

leafsdtools.exe is inside the nk directly. I used another tool, binmody found somewhere on 4pda, but it is closed source. I've wanted to make automated insertion process into the recovery NK without binmody and relying on external programs, thus why there is no working build process. I'd hugely appreciate if you can contribute and make the build process automatically inject the exe to the NK.

Also about the disk size, it is totally not necessary to be 9 gigabytes, which was something I discovered last year. Clarion does this annoying trolling, keeping two MBRs. Simple resizing did not give results for me back when I was developing this program, so I did not resize it at all. Now with the knowledge, you could cut the size down to tens of megabytes.

[developerfromjokela]

ps. look here for the binmody https://www.drive2.ru/l/676021531272284166/

[trombocit]

Thanks a lot for the quick answer — that confirms our approach and gives us a real path forward (and the binmody link +
MBR/size explanation was very useful too).

Update on our side, in case it's useful to others hitting the same wall:

We wrote a parser for ROMHDR/TOCentry/FILESentry (Microsoft's documented WinCE 5.0 format, confirmed byte-for-byte against an
independent implementation) and walked both the module table (nummods) and the files table (numfiles) of the 470-6105-01 NK
for our exact image. We still can't find "LeafSDTools.exe"/"SDTool" as readable text anywhere — not in nummods, not in
numfiles, not via a full binary string search across the whole 9.66 GB image. 12 of the 22 FILES entries are marked compressed
(attr bit 0x800), so it's plausible the name only exists inside a compressed blob we can't currently read.

We actually got real Windows DLL loading working on Linux (no Wine) — built eimgfs (github.com/nlitsme/eimgfs) as a 32-bit
binary with its own DLL loader, and CECompressv3.dll/CECompressv4.dll load and export CEDecompress correctly. But every
decompress call returns failure (0xFFFFFFFF) regardless of compression type (xip/rom/xpr/lzx/xph). The tool hardcodes
dwSkip=0, wStep=1, dwPagesize=4096 for the CEDecompress call — do you happen to know if CETUS BSP / this build uses different
values for any of these, or is there a simpler way (e.g. via binmody itself) to just extract the file list with real names
instead of guessing?

Either way — really appreciate you taking the time, and happy to share our ROMHDR/TOCentry/FILESentry findings if they're
useful for the wiki or for other QY8XXX users.

[developerfromjokela]

Thanks a lot for the quick answer — that confirms our approach and gives us a real path forward (and the binmody link +
MBR/size explanation was very useful too).

Update on our side, in case it's useful to others hitting the same wall:

We wrote a parser for ROMHDR/TOCentry/FILESentry (Microsoft's documented WinCE 5.0 format, confirmed byte-for-byte against an
independent implementation) and walked both the module table (nummods) and the files table (numfiles) of the 470-6105-01 NK
for our exact image. We still can't find "LeafSDTools.exe"/"SDTool" as readable text anywhere — not in nummods, not in
numfiles, not via a full binary string search across the whole 9.66 GB image. 12 of the 22 FILES entries are marked compressed
(attr bit 0x800), so it's plausible the name only exists inside a compressed blob we can't currently read.

We actually got real Windows DLL loading working on Linux (no Wine) — built eimgfs (github.com/nlitsme/eimgfs) as a 32-bit
binary with its own DLL loader, and CECompressv3.dll/CECompressv4.dll load and export CEDecompress correctly. But every
decompress call returns failure (0xFFFFFFFF) regardless of compression type (xip/rom/xpr/lzx/xph). The tool hardcodes
dwSkip=0, wStep=1, dwPagesize=4096 for the CEDecompress call — do you happen to know if CETUS BSP / this build uses different
values for any of these, or is there a simpler way (e.g. via binmody itself) to just extract the file list with real names
instead of guessing?

Either way — really appreciate you taking the time, and happy to share our ROMHDR/TOCentry/FILESentry findings if they're
useful for the wiki or for other QY8XXX users.

I wanted to explore also unpacking nk, haven't had time to do it. Btw, what's your end goal, modding the OS? :)

[trombocit]

Fixing our own head unit is the immediate goal — restoring the touchscreen so we can run Write NAND from the good backup. Beyond
that, we're curious whether we could get something as simple as a custom "hello world" binary packaged into the NK and running on
the device — more out of curiosity about the platform than any concrete plan.

[developerfromjokela]

Fixing our own head unit is the immediate goal — restoring the touchscreen so we can run Write NAND from the good backup. Beyond
that, we're curious whether we could get something as simple as a custom "hello world" binary packaged into the NK and running on
the device — more out of curiosity about the platform than any concrete plan.

Alright :) hope you can get it restored and working again.