no, it is not WinCE.
In principle they compiled a kind of own microkernel/bootload, which contains yaffs driver (necessary to read/write the NAND itself).
The bootloader is actually able to respond to some secret combination on UART, which i don't need/care for now.
Maybe the most interessting part of the bootloader is the fact that this is exact (or maybe a bit changed) bootloader as on
older Owon DSOs (they using S3C2440 like Tekway/Hantek, i believe the PDS/MSO series). In principle when you
type the secret combination you can download fw, flash NAND, erase it and so on. It also contains the encryption for NAND.
The rest of the NAND, well the actuall yaffs file system is containing few files only:
dso app itself
BMP file (the logo)
TXT files (they a kind of settings for actual fw)
PARAM files (for setup savings)
HZLIB file (which is the encryption i guess)
There is additionally copy of all these files (so each file have a copy too).
/flash/boot/paramcp - params copy
/flash/boot/param - params file
/flash/boot/bmpcp bmp copy
/flash/boot/bmp bmp file
/flash/boot/txcp txt copy
/flash/boot/tx txt file
/flash/boot/mecp menu copy
/flash/boot/me menu file
/flash/boot/hlpcp help copy
/flash/boot/hlp help file
/flash/boot/hzcp hzlib copy
/flash/boot/hz hzlib file
/flash/boot/oscp copy of DSO app
/flash/boot/os DSO app itself
/flash/boot/fpcp FPGA design copy
/flash/boot/fp FPGA deisg file
The bootloader is in principle checking NAND, when something wrong copy will be used.
Now all these files, except the HZLIB, are sectored (2048 byte sectors).
These sectory are NOT the NAND OOB sectors, they are for the yaffs. Normally yaffs is storing
sector information in OOB area, Owon created (due the fast that they using own yaffs implementation and encyption)
additional own sectors.
Now these sectors are blank, but it should contain checksum (this is 20byte long, so 2028byte data + 20 byte crc per sector).
These CRC checksum is in the HZLIB file, so if you try to change something binary in the file you have to care about the
HZLIB too. For now this is not what i care about, crc can be always patched to valid. Maybe HZLIB is something else,
but it looks for me as CRC file.
What i'm doing now is to analyze the dso app itself to find what i need to patch first, when
this is done i will work on HZLIB/CRC. These blanks in code can be skipped for now, the code make sense
without them. I was only worrying that part of the data is in HZLIB, which is luckily not the case.
The hadrware itself contains also EEPROM, haven't checked what inside, but what i can see from NAND dump
the serial number is almost everywhere, so you can't just use firmware from higher model and re-flash
because you will get new serial number. However, this was anyway not what i was hoping to do, i think
it will be enough to find filter position in dso app, change the filter to well let say 650MHz (or maybe only 350MHz),
patch the HZLIB/CRC and reflash DSO.
Of course such modification will be overwritten when you do firmware update, but as Owon is anyway in
the opinion that the firmware is "mature" i don't think that many people will do updates monthly (like on other DSOs).
So for now i know what inside, where to look for what i wish to patch, where is the CRC - of course if this hack
will work not everybody will be able to hack Owon without proper tools.
You will need at least ARM JTAG (i still recomend H-JTAG), a driver for S3C2416/K9F1G08 NAND with OOB support
(which i wrote yesterday) and maybe a spare NAND when you worry about unexpected changes (it is always a good idea
to backup NAND, solder empty one, restore backup and work with that - EEPROM copy/backup make sense as well).
If someone have an Owon SDSxxxx and ARM JTAG and wish to play a bit, attached JTAG pinout.
In principle you don't have to disasseble everythign, it is enough to remove back cover to get access to
JTAG, sure when you wish to resolder NAND you have to remove all these f*** screws and PCBs.
Yeah, and of course every file is marked at begin and end with the name, so when you wish
to check/play with the DSO app itself, search for oscp, copy everything from there until you find
another one oscp marking, hex it looks like 01 FF FF FF 01 00 00 00 FF FF 6F 73 63 70.
As mentioned above you have then of course skip 20 bytes every 2028 bytes to get the real app dump,
aynway, have fun