Following up from my previous posts on this, looks like my idea’s are correct about the size of the NAND for setup, and my NAND read stuff works. Yay for me.<\/p>\n
Lets recap:<\/p>\n
JZ4755 boot sequence is as follows:<\/p>\n
CPU powers up.
\nChecks BOOT_SEL line, takes appropriate action.<\/p>\n
In our board, if we press BOOT, this pulls the pin low, so CPU see’s 01, and waits for an IPL from USB. So far so good.<\/p>\n Lets see if anyone was watching carefully \ud83d\ude42 Lets look at what happens.<\/p>\n If I read out the NAND (NREAD 0 8192 0 0) with our carefully set sizing, I see the following:<\/p>\n So, we have roughly about 6k odd of data, out of our 8k max. Its a bit weirdly laid out though, and has some holes in there, so its _not_ correct \ud83d\ude41<\/p>\n Lets look at the RAW NAND DUMP (NREAD_RAW 0 8192 0 0). Our raw page size is 8192.<\/p>\n So, with that, we know that NREAD doesn’t quite work for our first 4 pages (page 0 – 3), and we either need to NREAD_RAW, or possibly use a 2048byte page size in order to read the NAND.BIN properly.<\/p>\n Thats only necessary for the first 4 pages in the NAND though. How does it do that though?<\/p>\n MINIOS Bootloader starts up, as it gets added to the CPU boot sequence detailed above, then it looks for 3 things in 3 places \ud83d\ude42<\/p>\n Our mystery locations for that are:<\/p>\n Page 61 Page 61 contains our NAND size stuff, which as we know from above, our Bootloader *can’t* use, as its only 2k or 512byte set at the hardware level initially.<\/p>\n Page 61 in mine has 12 bytes. This looks exceedingly good as I know that my work is, er, working \ud83d\ude42<\/p>\n 00 20 00 00 = 8192 PAGE SIZE Lets look at the 3 bytes.<\/p>\n First 16bit word is = 8192 – thats our Page Size Block 61, and Block 62 are the same. Basically 62 is a backup of 61. If the NAND.BIN MINIOS loader can’t read Block 61 12 bytes, it tries Block 62. If neither work, you’ll need to reflash, or replace the NAND…<\/p>\n Block 63 contains a whole 10 bytes. This is the UID of the device. Mine is set to 0. Lazy buggers \ud83d\ude42<\/p>\n Ok, so now we booted, and the MINIOS bootstraploader \/ NAND.BIN has read our NAND size, then what?<\/p>\n Well, you’ll need to disassemble the code to see (eg as part of my previous post), but essentially it calls the next thing in line.<\/p>\n This can be Linux, or something else. In the board, the OS used is MINIOS, so it loads something else – aka MINIOS.<\/p>\n MINIOS is actually uCOS-II – You can find details on that from Micrium, as they licence it out. You can read more on MINIOS here – http:\/\/en.wikipedia.org\/wiki\/MicroC\/OS-II<\/a><\/p>\n Anyway, lets get back to work, and less chatter \ud83d\ude42<\/p>\n NAND.BIN passes control onto whatever is sitting at Page 128 (this can be changed, but in the JAMMA board, and in the GameBox GBX-0001), the next loader is at Page 128.<\/p>\n As I don’t have much info on the MINIOS side, I got a lot of this info from other places. Mostly the MINIOS_CFG.INI in the Ingenic FTP Site, plus some gracious help from Joseba Epalza (thanks!) at www.zonadepruebas.com<\/a>. He supplied a Gamebox dump, and asked me a few questions, which made me re-examine things, which was extremely useful as then I could bounce idea’s and findings off of someone else.<\/p>\n The Gamebox hardware and the Jamma hardware is extremely similar, so the NAND dump in both is good for both of us to double check each others work. Unfortunately, I don’t speak Onto the tech side again, our secondary loader is, in MINIOS terms, called LOADER.BIN<\/p>\n This sits at Page 128 In theory, Page 256 contains I need to go back and recheck that now, as my dumps are a bit messy, and I need to check on actual hardware, vs the many whoops I renamed that wrong files I now have messing up my desktop. Other bits:<\/p>\n IMG_BOOT.BIN – bootup code if used. The rest… (FAT16 Filesystem which is readable over USB via normal boot) Ignoring my first 8k not quite correct dumped dumps + possibly borked secondary loader stuff, the rest of the data dump looks accurate.<\/p>\n I have what looks like RES.BIN stuff, I have a MINIOS, and I can see interesting things.<\/p>\n Interesting things below:<\/p>\n mobile_tv.bin So, I know that that part is correct at least, as it really truly looks like proper data \ud83d\ude42 Our FAT part of the NAND, that is USB accessible is referred to internally as nfl: (Nand FLash I expect).<\/p>\n Looks like our loader looks for these files in the user side:<\/p>\n nfl:\\system\\music.img Filename strings are NULL terminated.<\/p>\n There is also this:<\/p>\n nfl:\\GAME \\gamegameList<\/p>\n This seems to be our mapping of game.zip -> proper name file (having taken a look at that). Other other observations - Lastly, and even more useful, there apparently is a Mini console - Mini CONSOLE V1.0 Guess I need to see if I can get the Ingenic RTOS\/uCOS-II stuff, unfortunately their FTP site has it, but the RAR file is broken, so it doesn't unrar completely. This means we're missing all of the good bits that we need for reference. I can give them a call Monday though, and see if they'd be interested in helping me out. <\/p>\n Pretty good progress though \ud83d\ude42<\/p>\n Good reference on this: Following up from my previous posts on this, looks like my idea’s are correct about the size of the NAND for setup, and my NAND read stuff works. Yay for me. Lets recap: JZ4755 boot sequence is as follows: CPU powers up. Checks BOOT_SEL line, takes appropriate action. boot_sel[1:0] 00 Unused 01 Initialization via USB […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[390,48,282,25],"tags":[414,391,416,413,393,417,415],"class_list":["post-861","post","type-post","status-publish","format-standard","hentry","category-arcade-machines","category-exploits","category-firmware-2","category-technical-mumbo-jumbo","tag-ingenic","tag-jamma","tag-jz4755","tag-mips","tag-reverse-engineering","tag-rtos","tag-ucos-ii"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.computersolutions.cn\/blog\/wp-json\/wp\/v2\/posts\/861","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.computersolutions.cn\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.computersolutions.cn\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.computersolutions.cn\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.computersolutions.cn\/blog\/wp-json\/wp\/v2\/comments?post=861"}],"version-history":[{"count":5,"href":"https:\/\/www.computersolutions.cn\/blog\/wp-json\/wp\/v2\/posts\/861\/revisions"}],"predecessor-version":[{"id":866,"href":"https:\/\/www.computersolutions.cn\/blog\/wp-json\/wp\/v2\/posts\/861\/revisions\/866"}],"wp:attachment":[{"href":"https:\/\/www.computersolutions.cn\/blog\/wp-json\/wp\/v2\/media?parent=861"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.computersolutions.cn\/blog\/wp-json\/wp\/v2\/categories?post=861"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.computersolutions.cn\/blog\/wp-json\/wp\/v2\/tags?post=861"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}boot_sel[1:0]
\n00\tUnused
\n01\tInitialization via USB port: Receives a block of data through the USB (device) port,
\nand stores it in internal SRAM.
\n10\tInitialization via NAND memory with 512-byte pages at Chip Select 1 (CS1):
\n11\tInitialization via NAND memory with 2048-byte pages at Chip Select 1 (CS1):<\/code><\/p>\n
\nIf we leave it to boot normally, then it reads from NAND.<\/p>\n
\nOur board NAND chip has a page size of 8192+OOB
\nOur *CPU Hardware* supports either 512bytes or 2048bytes page size on boot.
\nOur IPL (aka NAND.BIN) must be 8K in size or less, as the CPU has 8k only, and it copies the bootloader to that obeying BOOT_SEL. <\/p>\n0000 - 2047 (2k in size) - DATA FF 55 55 .. 02 00 0C
\n2048 - 2549 (512bytes in size) - BLANK
\n2560 - 4607 (2k in size) - DATA (padded at end with FF's to 2k size) 21 20 00 .. 85 8c 90+ FF -> 2048 end
\n4608 - 6655 (2k in size) - DATA (padded at end with FF's to 2k size) <\/code><\/p>\nPage 0
\n00000 - 02047 (2k in size) - DATA FF 55 55 .. 02 00 0C (same as before)
\n02048 - 02102 (55 bytes) - (presumed OOB \/ ECC stuff...) NEW
\nPage 1
\n08192 - 10239 (2k in size) - DATA 21 20 00 .. 10 80 00. Our 85 8c 90 above is actually part of the 55byte sequence, so definitely our NREAD is incorrect, as we're suddenly short data.
\n10240 - 10294 (55 bytes ) - (presumed OOB \/ ECC stuff...) NEW
\nPage 2
\n16384 - 18431 (2k in size) - DATA (padded with 0's from 17892 - 18431), so our NAND loader data is roughly 5.5KBish.
\n18432 - 18486 (55 bytes ) - (presumed OOB \/ ECC stuff...) NEW
\nPage 3
\n25026 onwards FF's - so uninitialized.<\/code><\/p>\n
\nOnce the NAND.BIN MINIOS bootstrap is running, it should be able to cope with our proper data size.<\/p>\n
\nPage 62
\nPage 63<\/p>\nUSBBoot :> nreadraw 61 24 0 0
\nReading RAW from No.0 device No.0 flash....
\n0x00000000 :00 20 00 00 c0 01 00 00 00 01 00 00<\/p>\n
\nc0 01 00 00 = 448 OOBSIZE
\n00 01 00 00 = 256 PAGE PER BLOCK
\n<\/code><\/p>\n
\nSecond 16bit word is = 448 – thats our OOB size (oob = out of block, usually used for CRC or Error etc, as NAND can go BAD if you write to it frequently)
\nThird 16bit word is = 256 – thats how many pages per block we have.<\/p>\n
\nIngenic has a custom version of uCOS-II for their board. uCOS-II is also a RTOS (Real Time OS).<\/p>\nPortuguese<\/del> Spanish, so we both relied on Google Translate to talk via email today, but we seem to be doing ok \ud83d\ude42<\/p>\n
\nLOADER.BIN tries to read a file called DEF_BOOT.BIN for configuration settings, as that tells LOADER.BIN where the rest of the filesystem is!<\/p>\n
\nDEF_BOOT.BIN<\/p>\n
\nI also need to check if I need to read as 2k block size\/or raw to get the correct data in these pages, as one place online says that the secondary bootloader (LOADER.BIN) also assumes 2k size.<\/p>\n
\nMINIOS.BIN – the OS.
\nRES.BIN – Resources used by MINIOS.BIN<\/p>\n
\n—<\/p>\nDump pos 0x100200 - seems to have the RES.BIN filesystem in mine - <\/p>\n
\ndesktop.bin
\nudc_battery.bin
\nsysconfig.bin
\ntoolsbox.bin
\ncalendar.bin
\nebook.bin
\nworldclock.bin
\nrussblock.bin
\nfmradio.bin
\nrecorder.bin
\nmp3_compress.bin
\nviewer.bin
\njpgdec.bin
\npngdec.bin
\nbmpdec.bin
\ngifdec.bin
\nAudioTag.bin <-- significant, means case sensitive\nvplayer.bin\nfplayer.bin\naplayer.bin\nvideo.bin\nalarm.bin\ngameplay.bin\ngba_lib.bin\nnes_lib.bin\nsnes_lib.bin\nmd_lib.bin\nticru_lib.bin\ndcDecoder.bin\ndvEncoder.bin\ndcdv.bin\nmpcodecs_ad_liba52.bin\nmpcodecs_ad_hwac3.bin\nffmpeg64.bin\nffmpeg_vd_mpegmisc.bin\nffmpeg_vd_mpegmisc2.bin\nffpmeg_vd_mpegvideo.bin\nmpcodecs_vs_libmpeg2.bin\nffmpeg_vd_svq3.bin\nmpcodecs_vd_realvid.bin\naux_task.bin\n\n\ndesktoplib_simplen.bin\ndesktoplib_drawer.bin\ndesktoplib_slide.bin\ndesktoplib_tradition.bin <- chinese traditional\ndesktoplib_arena.bin\ndesktoplib_diorama.bin<\/code><\/p>\n
\nOther things of note.<\/p>\n
\nnfl:\\system\\ebook.img
\nnfl:\\system\\desktop.img
\nnfl:\\system\\record.img
\nnfl:\\system\\system.cfg
\nnfl:\\system\\UPDATE.BIN <\/p>\n
\nWhich, is why when I added FBANext compatible stuff to the user FS, it complained that it was garbage, but still worked. Lazy lazy lazy hardcoded file list, tsk tsk.<\/p>\n
\nI was wrong on my guess about DMENU - its actually the bog standard uCOS-II File System dialog in use.
\nI was wrong about FBANext being used, it looks more like FBAPlus PSP was used, and our version still has the Exit to PSP dialog still in there, as well as the menu options for the framerate etc. I guess I need to see how to bring that up, as that *is* useful!
\nMine says JZ4740 1.0sp1 Nov 19 2011 in the ROM. Guess codebase for MINIOS is JZ4740 based?<\/p>\n
\nI need to see how to setup access, as that looks quite interesting...<\/p>\n
\nhttp:\/\/code.google.com\/p\/dingoo-linux\/wiki\/DualBoot<\/a>
\nhttp:\/\/www.vogeeky.co.cc\/software\/minios\/struktura-minios<\/a> (Russian)
\nhttp:\/\/micrium.com\/page\/downloads\/ports\/mips_technologies<\/a> - MiniOS Mips code. Useful more for how MINIOS does its stuff, than relevance to us.
\nhttp:\/\/forum.arcadecontrols.com\/index.php?topic=108550<\/a> - The thread where I've been posting other findings on this.<\/p>\n","protected":false},"excerpt":{"rendered":"