Disecting the Aussie MMCS

[NathanNT]

Summary: This thread is intended to assist in our efforts to dissect the Aussie version of the MMCS found in the Pajero. While assistance is welcome, please avoid bringing up things like - "can you disable such-n-such for me?" and "can you add feature-x or support for y?". The simple fact is we are not up to that stage yet.

WHAT WE KNOW

1. The Australian Pajero MMCS has no hard-drive (overseas versions have a hard drive).

2. The unit appears to be an Eclipse system as a whole (possibly an AVN119M or some such). This is based on:
2a. The string "FUJITSU TEN LIMITED" contained in loading.kwi
2b. The following site contains the fit guides for the Pajero. http://www.fujitsu-ten.co.jp/eclipse...s/m000261.html
2c. You can use google to translate the following page to find other relevant fit guides for various models: http://www.fujitsu-ten.co.jp/eclipse...itsubishi.html (The pajero is in the middle - the link with the H18.10 is the latest information).

3. A very _similar_ loading.kwi file is used in the Mazda CX-9. The following link contains several pages with useful information: http://denso.wikispaces.com/
3a. According to this site, internal chips used include the "Naviem Denso", and various other sources cite this as a multi-OS supporting chip. It appears to be used in the Toyota Prius.
3b. It is based on a Toshiba TX49 cpu. According to Toshiba it appears to be MIPS based. This is consistent with observations of the code found in loading.kwi

4. Can not find the link right now, but someone did post a link to the schematic of the MMCS. It looks fairly close to the unit we have, and is consistent with the contents of loading.kwi.

HIDDEN MENUS

Two codes are currently known to work:
1-3-1-3-1-3-4-2
4-2-4-2-4-2

We do not know where these codes are stored, and as such can not currently identify any other codes. However we do know where the strings are that are used in the menus, and as such can work backwards to figure out where the menus are generated.

DISASSEMBLY OF THE KWI

We currently have a simple bit of C code that can pull the loading.kwi file apart into individual segments. The first 0x50 bytes contain basic information, including the "magic" string "MIUT", some sort of short name, some sort of type, a longer string / discription.

Following the header, are 4 byte memory offsets. The first four bytes are most likely where the segment is loaded into memory. Remaining four bytes appear to be entry points of some sort.

We can confirm the CPU is NOT an m32c, sh4, or for that matter anything with a variable instruction length. The machine language instructions are fixed length, 4 bytes each. It is a little endian, and MIPS instructions appear correct.

Disassembly can be done via several methods, however the most efficient method is currently being worked on. For those who have done this before, download binutils, configure with "--target=mips-elf". Use "as" and "objdump" as you require.

OPERATING SYSTEM

It is not WinCE. Note: The Naviem appears to have something called the "Windows Automotive" as a possible operating system. This appears to be used in non-Australian systems, and is probably a light-weight WinCE type version (assuming MS could do something that light weight!).

ITRON, muTRON, TRON etc are _specifications_, NOT operating systems. As such you can have an OS that complies with these specifications.



Hopefully I have covered the key points here. If I have missed _relevant_ links, please add as required.

[NathanNT]

See page 6 of the following PDF. Note reference to "Naviem":

http://www.t-engine.org/english/archives/TEP051213_u11_en.pdf

We might be able to get the source code:

http://www.t-engine.org/

[Black_NS]

2. The unit appears to be an Eclipse system as a whole (possibly an AVN119M or some such).

Manufactured by Kenwood (?under licence?). note model number on the photos by jasonw on this post.

[NathanNT]

I should mention, if anyone has corrections for the summary above, let me know.

On a second note, I have spent quite some time messing around with objdump and parts of the code. To cut a long story short, objdump will work, but will not make our life easy. So I am going to write something something myself (a good few hours work) which will take the required short-cuts to make the long term job much faster (and should they change the loading.kwi in the future, a very simple job to rework any changes).

[grobinson]

if anyone has corrections for the summary above, let me know...

HIDDEN MENUS

Two codes are currently known to work:
1-3-1-3-1-3-2-4
4-2-4-2-4-2

The first code is 1-3-1-3-1-3-4-2.

Grant

[NathanNT]

Code has been corrected in the first post.

Now, for those playing at home - During the weekend the disassembler should be ready for use. But to give a glimpse...

func_0x190:
190: 27bdffd0 addiu sp,sp,0xffd0
194: afbf002c sw ra,0x2c(sp)
198: 0dd000c5 jal 0x314
19c: 00000000 nop
1a0: afa0001c sw zero,0x1c(sp)
1a4: 3c013740 lui at,0x3740
1a8: afa00024 sw zero,0x24(sp)
1ac: 242105a8 addiu at,at,0x5a8 ;0x374005a8
1b0: afa00020 sw zero,0x20(sp)
1b4: 3404015e ori a0,zero,0x15e
1b8: 0020f809 jalr xxx
1bc: 27a5001c addiu a1,sp,0x1c

This is part of the function from "BLK.OSG - BlockOutScreen". So the best guess it either clears the screen, or it turns the power to the screen off. Several features:

1. addiu and sw are messing with the stack pointer and the return address (ra). This is a clear indicator of the start of a function.

2. jalr and addiu (the last two lines) are same sort of thing (xxx is some disassembler code I have to finish off) - except a clear indicator of a function exit.

3. The code is optimised. See the alternation between sw and lui (line 1a0 onwards). sw is a "store word", which uses memory, and thus is slow. So this is interspersed with code that manipulates the CPU only.

4. Points 1,2 and 3 are suggestive of a compiler / high level language in use (expected, but helps confirm it).

5. the lui and addiu instruction are setting up a memory access to location 0x374005a8. Given the BLK.OSG module is loaded at offset 0x374005a8, we can find offset 0x05a8 within the file. This sort of thing is critical for working out strings and variables. Once complete, the disassembler should for the most part identify the variable / string. This makes life easier later.

There is still some stuff I am reading up on (never touched mips before, so some of this is a learning experience for me too) - such as how the CPU talks to other chips etc.

[NathanNT]

Slow progress... but none-the-less... After many profound brain thingys inside my head, I have found the first part of how the service menu is displayed. First you need to pull out BPE.FILE (using a tool I wrote earlier in the week). Next, we find "S e r v i c e" at offset 7de2c0 in that file. Dump the 7d, and we have e2c0 as a memory offset.

Now, search for c0 e2 in BPE.FILE and go cross-eyed looking for it. I was expecting to see a whole bunch of code, but as it turns out, we end up with a "map" of sorts... At offset 7d8220, we find the following:

c0 e2 69 4c 04 00 00 00 08 00 00 00
08 e3 69 4c 04 00 00 00 3e 00 00 00
10 e3 69 4c 04 00 00 00 0b 00 00 00

So, the first 4 bytes contain the offset in some fashion. The next 8 bytes contain the location to display the string on the screen (I think) in X,Y coordinates. I think it only does 8 bytes at a time. Hmmm... looking at it, the X,Y coords may come first...

From this would should be able to find something that actually displays the menu and waits for input. This should also allow reconstructing each screen, and thus how various service information is obtained in order to display it.

Can someone tell me the nag screen prompt (ie what is the actual text displayed on the screen)?

[apsilon]

Can someone tell me the nag screen prompt (ie what is the actual text displayed on the screen)?

How about a pic so you can even see the layout?



I'd love to get rid of this screen.

[The Commodore]

Bloody oath!!!

That would be worth more than a case of Crownies!!!

Regards......

[NathanNT]

This looks like a promising OS... It has all the right phrases...
Denso, Fujitsu Ten, TKernel, ECLIPSE (AVN7406HD), supports TX9 processor.

http://www.esol.co.jp/english/embedded/successstory.html#denso_ften

This is the best guess of what we have. Now we just need technical information. We may be able to get away with the TKernel base as ESol seems to be an extension.

[NathanNT]

Progress is slow... but I am slowly finding my way through this thing... and the news is good. For those playing at home:

ACC.DEV appears to be related (funny enough) to the key / starting Acc positions / turning the vehicle off. Here is what we know:

ACC_0x5c8: Appears to be a start function
ACC_0x60c: Probably a restart function
ACC_0x658: Appears to perform specific start and/or stop functions related to: Memory Stick, Hdd, CDEjecting CD2Ejecting, MdEjecting???, SECOM (forgot what SECOM is), Display
ACC_0xa4c: Turn Interrupts on and off
ACC_0xb6c: ACC Timeout and Restart - see question below
ACC_0xc28: Reset function (as opposed to restart function)
(Various other misc functions associated with specific tasks).

From here we should be able to trace down to the nag screen at least.

KSLLIB.OPT appears to be some sort of system logging. Given it is fairly simple code, and contains some strings with "%d" etc, we should be able to map some of the basic IO.




Questions (again, I would know these if I had the car... so be patient)...

If you ignore the nag screen, does the MMCS eventually "turn off" after a certain timeout? (I assume yes).

For those who have messed around in the Diag screens, there is a "Car Type Setting" screen. I am assuming the Pajero does not have a CAN bus, so we can change the setting. Does anyone know what settings are listed? For those who may have other KWI files, can you identify any settings for those vehicles?

[slandells]

I haven't test it for hours, but I can confirm that after at least 15 minutes, if you don't hit the 'agree' button on the nag screen, it's still there...

[RJOther]

The available Car types are:
1.3M25
2.3M45
3.----
4.----
5.----
The NT Exceed is set to 3M45.

I didn't have any luck finding these strings in the loading.kwi.

[NathanNT]

The NT Exceed is set to 3M45.

I remember seeing the 3M25 somewhere as the model for something else.

Anyway, progress from here on in will be a little slow - we are really bogged in the mud looking for the sock you lost while trying to help get a Prado out... I am trying to figure out why offsets in the strings containing the service menus are skewed (basically it means part of the BPE section in the loading.kwi is loaded into a different part of memory - if I can figure out where in memory, and where that is done in the BPE section, I should be able to move onto the next stage of working out how the MMCS gets the speed signal... and thus deal with the "in motion" issues).

This is basically how the ACC part fits together (as mentioned, this is probably related to the key to the car being in the ACC position or off):

ACC_3a0 - Entry point
Calls 5c8 or 60c

ACC_5c8 - Start

ACC_60c - Restart

ACC_b6c - Acc Timeout, SetRestart

ACC_c28 - Reset

ACC_148c - Turns power on and off for various external devices?
a0 = probably set to the pin / device number
0x0 = MStick
0x1 = Hdd
0x2 = CdEject
0x3 = Cd2Eject
0x4 = MdEject
0x5 = SECOM
0x6 = HDD Power
0x7 = Disp (possibly display)
a1 = 1=on, 0=off

ACC_1f18 - Called with a string
s0 = memory location of string
s1 = length of string

One of the system calls is probably a printf:

From MSCD.OPT, probably a printf function call:
1fd4: 3c043a10 lui a0,0x3a10
1fd8: 8c250000 lw a1,0x0(at)
1fdc: 24846444 addiu a0,a0,0x6444 ;0x3a106444, offset = %d
1fe0: 0e8417f6 jal 0x5fd8
or:
2198: 92050061 lbu a1,0x61(s0)
219c: 3c043a10 lui a0,0x3a10
21a0: 0e8417f6 jal 0x5fd8
21a4: 248465ec addiu a0,a0,0x65ec ;0x3a1065ec, subclass = %d
and finally:
5fd8: 340c004b ori t4,zero,0x4b ;0x6b
5fdc: 00003b4c syscall ed
As such syscall ed with t4 = 0x4b and t0 = ptr to variable???
syscall ed seems to support t4 from 0x00 to 0x75 at least
syscall ee seems to support t4 from 0x00 to 0x26 at least

Some strings I may have missed in the LOADING.KWI:
PROG
ENED
OUTD
MARK

I am basically providing summaries here so the information is not lost. I also now have a copy of TKernel, which eSol is based on. Still not sure if there is a match between TKernel and the code in the MMCS. (Note: The TKernel license is very explicit about sharing, and until I can confirm if it is useful or not, there is no point other people going and getting copies).

Edit: Before I forget, for those playing at home, PM/email me and I will send a copy of the disassembler through (the code is what I would call "alpha", and still has a long way to go before it could do some bigger files such as BPE, but it can do most of the smaller chunks and as you can see above it shows where references to strings are, so makes light work of some harder things). You will probably want to read up on the TX/9 CPU and MIPS basics first to understand the registers and how they work.

[matt777]

Great work Nathan been watching this thread in anticipation.

Quick Question.
For the steering wheel controls what involved if I connect a different brand Ebay gps/dvd to the car..
Will the steering wheel controls work.

I remember someone mention canbus support and will be fine!??

HELP as I really want to change to a system that support speed camera alerts and ozi explorer.