Jun
16

JZ4755 Jamma Board Reverse Engineering Part 3 (King of Game Board)

Lawrence Sheed // 16 Jun 2012 // 5 Comments

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 port: Receives a block of data through the USB (device) port, and stores it in internal SRAM. 10 Initialization via NAND memory with 512-byte pages at Chip Select 1 (CS1): 11 Initialization via NAND memory with 2048-byte pages at Chip Select 1 (CS1):

In our board, if we press BOOT, this pulls the pin low, so CPU see’s 01, and waits for an IPL from USB.
If we leave it to boot normally, then it reads from NAND.

So far so good.

Lets see if anyone was watching carefully
Our board NAND chip has a page size of 8192+OOB
Our *CPU Hardware* supports either 512bytes or 2048bytes page size on boot.
Our 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.

Lets look at what happens.

If I read out the NAND (NREAD 0 8192 0 0) with our carefully set sizing, I see the following:

0000 - 2047 (2k in size) - DATA FF 55 55 .. 02 00 0C 2048 - 2549 (512bytes in size) - BLANK 2560 - 4607 (2k in size) - DATA (padded at end with FF's to 2k size) 21 20 00 .. 85 8c 90+ FF -> 2048 end 4608 - 6655 (2k in size) - DATA (padded at end with FF's to 2k size)

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

Lets look at the RAW NAND DUMP (NREAD_RAW 0 8192 0 0). Our raw page size is 8192.

Page 0 00000 - 02047 (2k in size) - DATA FF 55 55 .. 02 00 0C (same as before) 02048 - 02102 (55 bytes) - (presumed OOB / ECC stuff...) NEW Page 1 08192 - 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. 10240 - 10294 (55 bytes ) - (presumed OOB / ECC stuff...) NEW Page 2 16384 - 18431 (2k in size) - DATA (padded with 0's from 17892 - 18431), so our NAND loader data is roughly 5.5KBish. 18432 - 18486 (55 bytes ) - (presumed OOB / ECC stuff...) NEW Page 3 25026 onwards FF's - so uninitialized.

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.

Thats only necessary for the first 4 pages in the NAND though.
Once the NAND.BIN MINIOS bootstrap is running, it should be able to cope with our proper data size.

How does it do that though?

MINIOS Bootloader starts up, as it gets added to the CPU boot sequence detailed above, then it looks for 3 things in 3 places

Our mystery locations for that are:

Page 61
Page 62
Page 63

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.

Page 61 in mine has 12 bytes. This looks exceedingly good as I know that my work is, er, working

USBBoot :> nreadraw 61 24 0 0 Reading RAW from No.0 device No.0 flash.... 0x00000000 :00 20 00 00 c0 01 00 00 00 01 00 00

00 20 00 00 = 8192 PAGE SIZE c0 01 00 00 = 448 OOBSIZE 00 01 00 00 = 256 PAGE PER BLOCK

Lets look at the 3 bytes.

First 16bit word is = 8192 – thats our Page Size
Second 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)
Third 16bit word is = 256 – thats how many pages per block we have.

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…

Block 63 contains a whole 10 bytes. This is the UID of the device. Mine is set to 0. Lazy buggers

Ok, so now we booted, and the MINIOS bootstraploader / NAND.BIN has read our NAND size, then what?

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.

This can be Linux, or something else. In the board, the OS used is MINIOS, so it loads something else – aka MINIOS.

MINIOS is actually uCOS-II – You can find details on that from Micrium, as they licence it out.
Ingenic has a custom version of uCOS-II for their board. uCOS-II is also a RTOS (Real Time OS).

You can read more on MINIOS here – http://en.wikipedia.org/wiki/MicroC/OS-II

Anyway, lets get back to work, and less chatter

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.

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. 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.

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 ~~Portuguese~~ Spanish, so we both relied on Google Translate to talk via email today, but we seem to be doing ok

Onto the tech side again, our secondary loader is, in MINIOS terms, called LOADER.BIN

This sits at Page 128
LOADER.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!

In theory, Page 256 contains
DEF_BOOT.BIN

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.
I 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.

Other bits:

IMG_BOOT.BIN – bootup code if used.
MINIOS.BIN – the OS.
RES.BIN – Resources used by MINIOS.BIN

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.

I have what looks like RES.BIN stuff, I have a MINIOS, and I can see interesting things.

Interesting things below:

Dump pos 0x100200 - seems to have the RES.BIN filesystem in mine -


mobile_tv.bin

desktop.bin

udc_battery.bin

sysconfig.bin

toolsbox.bin

calendar.bin

ebook.bin

worldclock.bin

russblock.bin

fmradio.bin

recorder.bin

mp3_compress.bin

viewer.bin

jpgdec.bin

pngdec.bin

bmpdec.bin

gifdec.bin

AudioTag.bin <-- significant, means case sensitive

vplayer.bin

fplayer.bin

aplayer.bin

video.bin

alarm.bin

gameplay.bin

gba_lib.bin

nes_lib.bin

snes_lib.bin

md_lib.bin

ticru_lib.bin

dcDecoder.bin

dvEncoder.bin

dcdv.bin

mpcodecs_ad_liba52.bin

mpcodecs_ad_hwac3.bin

ffmpeg64.bin

ffmpeg_vd_mpegmisc.bin

ffmpeg_vd_mpegmisc2.bin

ffpmeg_vd_mpegvideo.bin

mpcodecs_vs_libmpeg2.bin

ffmpeg_vd_svq3.bin

mpcodecs_vd_realvid.bin

aux_task.bin

desktoplib_simplen.bin desktoplib_drawer.bin desktoplib_slide.bin desktoplib_tradition.bin <- chinese traditional desktoplib_arena.bin desktoplib_diorama.bin

So, I know that that part is correct at least, as it really truly looks like proper data
Other things of note.

Our FAT part of the NAND, that is USB accessible is referred to internally as nfl: (Nand FLash I expect).

Looks like our loader looks for these files in the user side:

nfl:\system\music.img
nfl:\system\ebook.img
nfl:\system\desktop.img
nfl:\system\record.img
nfl:\system\system.cfg
nfl:\system\UPDATE.BIN

Filename strings are NULL terminated.

There is also this:

nfl:\GAME \gamegameList

This seems to be our mapping of game.zip -> proper name file (having taken a look at that).
Which, 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.

Other other observations -
I was wrong on my guess about DMENU - its actually the bog standard uCOS-II File System dialog in use.
I 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!
Mine says JZ4740 1.0sp1 Nov 19 2011 in the ROM. Guess codebase for MINIOS is JZ4740 based?

Lastly, and even more useful, there apparently is a Mini console - Mini CONSOLE V1.0
I need to see how to setup access, as that looks quite interesting...

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.

Pretty good progress though

Good reference on this:
http://code.google.com/p/dingoo-linux/wiki/DualBoot
http://www.vogeeky.co.cc/software/minios/struktura-minios (Russian)
http://micrium.com/page/downloads/ports/mips_technologies - MiniOS Mips code. Useful more for how MINIOS does its stuff, than relevance to us.
http://forum.arcadecontrols.com/index.php?topic=108550 - The thread where I've been posting other findings on this.

June 16, 2012 // Arcade Machines, Exploits, Firmware, Technical Mumbo Jumbo // 5 Comments // Tags: ingenic, JAMMA, JZ4755, mips, Reverse Engineering, RTOS, ucOS-II

5 Comments to “JZ4755 Jamma Board Reverse Engineering Part 3 (King of Game Board)”

Joseba Epalza says:

June 17, 2012 at 12:11 am

entry point for prepare download LOADER code from NAND and jump into:

80c: e8148424 addiu a0,a0,5352 –> direccion texto “Prepare to download MINIOS ….” (Dir 0x14E8 (0x24E8 real))
810: 0000a2ac sw v0,0(a1)
814: 000002ae sw v0,0(s0)
818: 0000c2ac sw v0,0(a2)
81c: 2b01000c jal 0x4ac
820: 00000000 nop
824: 0080043c lui a0,0×8000
828: 2b01000c jal 0x4ac
82c: 08158424 addiu a0,a0,5384 –> “Ingenic Semiconductor ….. ”
830: 03000224 li v0,3
834: 000022ae sw v0,0(s1)
838: ca04000c jal 0×1328
83c: 00000000 nop
840: 0080023c lui v0,0×8000
844: 7416578c lw s7,5748(v0)
848: 1b00f702 divu zero,s7,s7
84c: f401e002 teq s7,zero,0×7
850: 12900000 mflo s2
854: 54004012 beqz s2,0x9a8
858: 0080163c lui s6,0×8000
85c: 7c16c48e lw a0,5756(s6)
860: 3c01000c jal 0x4f0
864: 0080153c lui s5,0×8000
868: 7c16c28e lw v0,5756(s6)
86c: 0080033c lui v1,0×8000
870: 02804272 0×72428002
874: 7816668c lw a2,5752(v1)
878: b016a526 addiu a1,s5,5808 ???
87c: 9002000c jal 0xa40
880: 21200002 move a0,s0
884: b016b392 lbu s3,5808(s5)
888: ff000224 li v0,255
88c: 8080113c lui s1,0×8080
890: 3f006216 bne s3,v0,0×990
894: 21f00000 move s8,zero
898: 0080023c lui v0,0×8000
89c: 7c16448c lw a0,5756(v0)
8a0: 0080033c lui v1,0×8000
8a4: 7816668c lw a2,5752(v1)
8a8: 0080023c lui v0,0×8000
8ac: 21200402 addu a0,s0,a0
8b0: ffff8424 addiu a0,a0,-1
8b4: 9002000c jal 0xa40
8b8: b0164524 addiu a1,v0,5808 ???
8bc: 0080023c lui v0,0×8000
8c0: b0164390 lbu v1,5808(v0)
8c4: 54007314 bne v1,s3,0xa18
8c8: 0080033c lui v1,0×8000
8cc: 7c16628c lw v0,5756(v1)
8d0: 18004010 beqz v0,0×934
8d4: 21800000 move s0,zero
8d8: 0080143c lui s4,0×8000
8dc: 3e020008 j 0x8f8
8e0: 0080133c lui s3,0×8000
8e4: 7c16c28e lw v0,5756(s6)
8e8: 7016838e lw v1,5744(s4)
8ec: 2b100202 sltu v0,s0,v0
8f0: 10004010 beqz v0,0×934
8f4: 21882302 addu s1,s1,v1
8f8: 21280002 move a1,s0
8fc: 21204002 move a0,s2
900: 21302002 move a2,s1
904: 0a03000c jal 0xc28
908: b016a726 addiu a3,s5,5808 ???
90c: 01001026 addiu s0,s0,1
910: f4ff4104 bgez v0,0x8e4
914: 60156426 addiu a0,s3,5472
918: 2b01000c jal 0x4ac
91c: 00000000 nop
920: 7c16c28e lw v0,5756(s6)
924: 7016838e lw v1,5744(s4)
928: 2b100202 sltu v0,s0,v0
92c: f2ff4014 bnez v0,0x8f8
930: 21882302 addu s1,s1,v1
934: 0080033c lui v1,0×8000
938: 7416628c lw v0,5748(v1)
93c: 0100de27 addiu s8,s8,1
940: 1b00e202 divu zero,s7,v0
944: f4014000 teq v0,zero,0×7
948: 12100000 mflo v0
94c: 2b10c203 sltu v0,s8,v0
950: 16004010 beqz v0,0x9ac
954: 01b3023c lui v0,0xb301
958: 7c16c48e lw a0,5756(s6)
95c: 3c01000c jal 0x4f0
960: 01005226 addiu s2,s2,1
964: 7c16c28e lw v0,5756(s6)
968: 0080033c lui v1,0×8000
96c: 02804272 0×72428002
970: 7816668c lw a2,5752(v1)
974: b016a526 addiu a1,s5,5808 ???
978: 9002000c jal 0xa40
97c: 21200002 move a0,s0
980: b016b392 lbu s3,5808(s5)
984: ff000224 li v0,255
988: c4ff6212 beq s3,v0,0x89c
98c: 0080023c lui v0,0×8000
990: 0080043c lui a0,0×8000
994: 2b01000c jal 0x4ac
998: 40158424 addiu a0,a0,5440 –> dir text “1. Bad Block”
99c: 0080023c lui v0,0×8000
9a0: 3c01000c jal 0x4f0
9a4: b0164490 lbu a0,5808(v0)
9a8: 01b3023c lui v0,0xb301
9ac: 50004234 ori v0,v0,0×50
9b0: 0080043c lui a0,0×8000
9b4: 000040ac sw zero,0(v0)
9b8: 2b01000c jal 0x4ac
9bc: 78158424 addiu a0,a0,5496 “_Jump to 0x” dir REAL del NAND.BIN en 0×2578, o 0×1578 del codigo
9c0: 3c01000c jal 0x4f0
9c4: 8080043c lui a0,0×8080
9c8: 0080043c lui a0,0×8000 –> texto 0×80800000
9cc: 2b01000c jal 0x4ac
9d0: 84158424 addiu a0,a0,5508 “_Launch…” dir REAL del NAND.BIN en 0×2584, o 0×1584 del codigo
9d4: 00b0023c lui v0,0xb000
9d8: ffff0324 li v1,-1
9dc: 08104234 ori v0,v0,0×1008
9e0: 000043ac sw v1,0(v0)
9e4: 3400bf8f lw ra,52(sp)
9e8: 3000be8f lw s8,48(sp)
9ec: 2c00b78f lw s7,44(sp)
9f0: 2800b68f lw s6,40(sp)
9f4: 2400b58f lw s5,36(sp)
9f8: 2000b48f lw s4,32(sp)
9fc: 1c00b38f lw s3,28(sp)
a00: 1800b28f lw s2,24(sp)
a04: 1400b18f lw s1,20(sp)
a08: 1000b08f lw s0,16(sp)
a0c: 8080193c lui t9,0×8080
a10: 08002003 jr t9 –> Jump to 0×80800000 = NAND LOADER.BIN, page 128?

It’s interesting code to understand how and where, JZ4755 loads NAND into DRAM.
emphatic says:

June 18, 2012 at 6:02 pm

Hey, I’m gonna follow your progress on this blog instead of BYOAC because of that hostile guy crapping all over that thread. Unless you wanna make a new thread over there and call it “Reverse-engineering Game of King JAMMA PCB”.
Lawrence Sheed says:

June 18, 2012 at 7:09 pm

That guy is being a complete asshole*, god knows what he’s thinking. He’s pretty much ruined that thread with his spamming now..
Longer term I’ll probably move this to my retrosticks forum on http://forum.retrosticks.com , as I have that setup, and my elves made it all pretty n stuff, so need to start making it have some content, then I can hopefully make the odd few rmb selling arcade stuff on there too

*I’m an asshole sometimes too, but not in this occasion at all, and when I am an asshole, its usually with a justifiable reason
emphatic says:

June 19, 2012 at 2:10 am

He’s the worst troll on that site with 20+ bans already. :/ He pops up and start posting in tech discussions that he then hijacks as he tries to inject his own projects. He called himelf Driver-man at first, cross posting at lots of gaming forums and even successfully hacking the BYAC forums. Google “Driver.man MAME” to see complete madness,
Joseba Epalza says:

June 19, 2012 at 3:28 am

” Longer term I’ll probably move this to my retrosticks forum on http://forum.retrosticks.com…” –> It’s a good idea

We must “cannibalize” MINIOS!!

Post comment

Recent Trackbacks

Large: Checking the Watermark: Review of Shenhua’s Watermark coal project economic assessment | Economists
Monitoring servers with an USB lamp: Laurence Sheed uses the eBuddy for server load and door entry monitoring .
Branik's Blog: Bing Is A Nuisance
Computer Solutions Blog: sysfence updates for debian (startup script, and makefile fix)
eFront Blog: 5 things you (perhaps) don’t know about eFront