MicroHacker Forum

Hey guys! As it is of interest, let's go to find how and where the Ford satnavs store their graphics. Let's start with an FX, as it is the smallest images, but it should then easy to adopt this on NX or MCA.

I'm pretty shure the images are in a packed/compressed format. Let's start with what we know:
The LCD Display is of brand "TPO Displays Corp." and type "TJ058ZA01AA". I couldn't find anything of interest on the web, no datasheet, no application notes. Only it's resolution, it should be 480 x 234 pixels, but the ratio seems wrong to me...

The image data must contain the displays area of course, but an important point is the number of colors of each pixel. Working with RGB-888 is very unlikely and uncommon to those kind of systems, as the images would take too much memory and CPU power. I think we can expect an indexed palette instead, As you can switch color-schemes, like on Convers+, it may be an similar image-processing.

I know from my hardware-inspections that the LCD is driven with RGB-666, so 6 Bits per color. So the LUT should be organized that way. Bit shurely they will use 1 Byte for each color component, so having 3 Bytes per LUT-Index.

If the images are indexed, we will find some color-LUT in the firmware-data and there may be 8 bits per pixel. The LUT-data is bound to the graphics ability of the hardware. As there is no dedicated LCD-Controller and the Cyclone 2 is doing that, we cannot simply determine how many colors the LUT can have. I would bet on 8 bits per pixel, so 256 possible colors.
So an image would make up to 480 x 234 x 8 Bits = 112.320 Bytes in decompressed format.

As there are many graphics available there is usually also a map where all memory locations of all images are stored. The map is then adressed by an index.

Right now i'm really unshure how HMI (OMAP) and FGS (Cyclone) are doing graphics and who do's what. Maybe the OMAP only doing Navi graphics and the menu's came from the Cyclone? Or the Cyclone just forms a special LCD-Controller with own Fonts and description language of the text and menus shown by the HMI?

Best would be to find the drawing routine, but i don't even know where to look after it.

In analysis of the firmware CD components the "fgs.dnl" file seems the most promising one for having graphics. When i extract the strings out of this file (which does not seem to be compressed or encrypted) i find all the messages and texts herein. BTW: there are messages indication the turn off/on of video input, which can be interesting later! As you might know, the video input is processed on the graphicsboard only. There is an additional A/D-chip for this, but of course the command to turn it off an on will come from the main application.

Another indication of my thoughts how this system may behave is that if you mix main and fron-units of the FX, you get strange text messages on the screen. This, in my opinion is caused by the HMI not sending whole texts, but only references (IDs) which text to show on the display and the display does all the translation and drawing. This would make sense to me. Also you don't find the display messages in the HMI firmware itself.

The point of looking at messages is that the program needs to access them somehow and this may be a way of tracing back to the drawing routine. So if one be able to put a breakpoint on an address of an usualy message, he may inspect the stack where this call came from.

One indication of having the images in this file could be the size and also the fact that the FGS could fast access the images, whithout transferring them from the OMAP.

So to narrow down the image locations i would exclude everything which can't be an image, like strings and program code. The problem is, right now i don't know which dialect the code is. The FGS application is run on an Cyclone (now Altera) chip. This is not an CPU or MPU but and FPGA. Together with an configuration from an small EEPROM it will "form" some kind of CPU, but could be everything. Best best would be an ARM-Architecture, but could be everything else. Maybe the strings give us some hints... and the fact that developers usually using vendor proposed standards, so let's look what the Cyclone II plattform is used for.

I find this string near the end of the file "uC/OS-II" and found out that this is an RTOS "MicroC/OS-II Real-Time Operating System":
http://www.sightsys.co.il/product/real- ... 9-nios-ii/
There is also an separate homepage of it: https://www.micrium.com/downloadcenter/recent-activity/

in system.elf im finde this

For me, the system.elf contains the underlying RTOS. The meaning of "image" here is more in the means of an fileimage not an picture. On this level there is no application dealing with graphics, that's pure OS.

I looked into the fgs.dnl file, where i suspect the graphics and could find some structures. Still not through it but getting close. Seems like those files somehow behave like a UDS update capture, it is split into chunks of 0x38 Bytes with an framepointer. As i took a dump from an desoldered Flash memory, i was able to compare what bytes are payload and what a "protocol". So far i can tell they are unencrypted.

The payload frames are mixed with infoframes, changing the display text and progress bar., like this: Those frames are related in a timeline.

I really wonder what does the update at all, there must be a function inside the main firmware, or even a separate application doing it. If so, the code could be found in the plattapp.bin file...

Here is an complete dumpfile of an FX graphics board Flash memory chip. I desoldered one and read back with an Flash programmer. Unfortunately i did not update the system beforehand, so this image is of an older FW-Version 0407. If i have time i repeat this step with an updated one. It is not so easy as it sounds because of limited space to surrounding part and, what is more problematic, massive ground layers unter it distributing the heat. With much patience you can do this once, but after the second try it is likely to damage the solder pads and wires.

All my efforts to get around this by directly read/write the Flash-chip in-circuit via the JTAG-Interface of the Cyclone-II FPGA where unsuccessful until now. To do so one needs to build an IP (program) which then configures the FPGA to build some sort of process unit (CPU or at least doing the task) to make it possible to route Flashdata over the JTAG interface. This is a bit complicated...

But it is possible to find parts from it also in the current update-CD fgs.dnl file. Just in case somebody else than me has time to look into. At least all the content from the fgs.dnl file will be put into the Flash of the graphicsboard.

As in the nature of compiled code (binary image) code we could expect code and data to be in separate location blocks. Normally the constants are nearby the code and the variable data follows at the end.

For me, something like this looks really more like code: and this looks more like packed image data:

Go4It you have thrue

Im search in fgs.dnl and fount this

Go4IT wrote: ↑10 Dec 2019, 12:59 Here is an complete dumpfile of an FX graphics board Flash memory chip. I desoldered one and read back with an Flash programmer. Unfortunately i did not update the system beforehand, so this image is of an older FW-Version 0407. If i have time i repeat this step with an updated one. It is not so easy as it sounds because of limited space to surrounding part and, what is more problematic, massive ground layers unter it distributing the heat. With much patience you can do this once, but after the second try it is likely to damage the solder pads and wires.

All my efforts to get around this by directly read/write the Flash-chip in-circuit via the JTAG-Interface of the Cyclone-II FPGA where unsuccessful until now. To do so one needs to build an IP (program) which then configures the FPGA to build some sort of process unit (CPU or at least doing the task) to make it possible to route Flashdata over the JTAG interface. This is a bit complicated...

But it is possible to find parts from it also in the current update-CD fgs.dnl file. Just in case somebody else than me has time to look into. At least all the content from the fgs.dnl file will be put into the Flash of the graphicsboard.

As in the nature of compiled code (binary image) code we could expect code and data to be in separate location blocks. Normally the constants are nearby the code and the variable data follows at the end.

For me, something like this looks really more like code:

Code: Select all

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000810  03 00 80 80 3A 88 E1 80 03 00 C0 80 44 00 00 84  ..€€:ˆá€..À€D..„
00000820  03 00 00 81 44 00 00 84 03 00 40 81 3A 92 06 18  ....D..„..@.:’..
00000830  3A 92 0E 38 3A 94 08 20 3A 94 10 40 3A 96 0A 28  :’.8:”. :”.@:–.(
00000840  3A 96 12 48 3A B0 C4 10 3A B0 CC 31 3A B0 04 11  :–.H:°Ä.:°Ì1:°..
00000850  3A B0 44 11 3A B0 0C 32 3A B0 4C 32 15 02 80 D8  :°D.:°.2:°L2..€Ø
00000860  C4 0B 80 00 3A 88 27 50 15 01 80 D9 44 00 00 84  Ä.€.:ˆ'P..€ÙD..„

and this looks more like packed image data:

Code: Select all

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

003CA820  22 22 22 22 70 00 00 00 00 00 00 00 00 00 00 00  """"p...........
003CA830  00 72 22 22 22 22 27 00 00 00 00 00 00 00 00 00  .r""""'.........
003CA840  72 22 22 22 22 22 70 00 00 00 00 00 00 00 00 00  r"""""p.........
003CA850  00 00 00 72 22 22 22 22 27 00 00 00 00 00 00 00  ...r""""'.......
003CA860  00 00 72 22 22 22 22 22 70 00 00 00 00 00 00 00  ..r"""""p.......
003CA870  00 00 00 00 00 72 22 22 22 22 27 00 00 00 00 00  .....r""""'.....
003CA880  00 00 00 00 72 22 22 22 22 22 70 00 00 00 00 00  ....r"""""p.....
003CA890  00 00 00 00 00 00 00 72 22 22 22 22 27 00 00 00  .......r""""'...
003CA8A0  00 00 00 00 00 00 72 22 22 22 22 22 70 00 00 00  ......r"""""p...
003CA8B0  00 00 00 00 00 00 00 00 00 72 22 22 22 22 27 00  .........r""""'.
003CA8C0  00 00 00 00 00 00 00 00 72 22 22 22 22 22 70 00  ........r"""""p.
003CA8D0  00 00 00 00 00 00 00 00 00 00 00 72 22 22 22 22  ...........r""""
003CA8E0  23 77 77 77 77 77 77 77 77 77 32 22 22 22 22 22  #wwwwwwwww2"""""
003CA8F0  70 00 00 00 00 00 00 00 00 00 00 00 00 72 22 22  p............r""
003CA900  22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22  """"""""""""""""
003CA910  22 22 70 00 00 00 00 00 00 00 00 00 00 00 00 72  ""p............r

And im found this 440x200
Its resolution display?

Good job! Know you're in

So, now that we found a trace and proof, let's dig into it.
The string telling "TPO_50_440x200" could really be the resolution of 440 x 200 pixels of the display. "50" may be the number of characters per row... and would then result in nearly 8bit per char in width.

The fact that the images you found seem to be repeated 3 times could be some kind of planar-mode for RGB. The image is 24 x 40 pixels.
I've loaded the file into https://rawpixels.net/, set file offset to the start of the image data (0x3CB910 = 3979536), set data plane mode to "planar" and image type to "RGB8" and get this lovely result:
Looks pretty good. Now, it seems that images are not packed in any way. The challenge is to get the right ratio (width/height) of an image to make it look correct.

I think the reason why the FGS is decoupled from the HMI is that Bosch could reused the same base HMI for different radio types, e.g. the Skoda/VW RNS system.
Therefore it makes perfectly sense to have a metalanguage between them.

When i look at the data which makes up the above image, i would now think the images are RGB555 (5 Bits per planar), so the display is capable of 32.768 colors, which feels pretty right.

im found this