Understanding data structure of "fgs.dnl" file from Nav-FX Update-CD

[Go4IT]

I try to understand how this file format is used to update the graphicsboard of the navigationsystem FX ("fgs.dnl").

Right now i now that it is layouted like a script, the work is does is there step by step, block by block. You find this when looking at the strings it contains:

Code: Select all

ROM:00000009	0000000D	C	FGS DNL Mode
ROM:00000079	0000001F	C	Start Download              0%
ROM:000000E9	0000001F	C	Erase FDS Area              2%
ROM:00000191	0000001F	C	Erase Testmanager Area      3%
ROM:00000239	0000001F	C	Erase Application Area      5%
ROM:000002E1	0000001F	C	Flash FDS Area             21%
ROM:00000389	0000001F	C	Flash FDS Area             22%
ROM:00000431	0000001F	C	Flash FDS Area             23%
ROM:000004D9	0000001F	C	Flash FDS Area             24%
ROM:00000581	0000001F	C	Flash Testmanager Area     25%
ROM:00005E19	0000001F	C	Flash Testmanager Area     26%
ROM:0000B6B1	0000001F	C	Flash Testmanager Area     27%
ROM:00010F81	0000001F	C	Flash Testmanager Area     28%
ROM:00016819	0000001F	C	Flash Testmanager Area     29%
ROM:0001C0E9	0000001F	C	Flash Testmanager Area     30%
ROM:00021981	0000001F	C	Flash Testmanager Area     31%
ROM:00027251	0000001F	C	Flash Testmanager Area     32%
ROM:0002CAE9	0000001F	C	Flash Testmanager Area     33%
...
ROM:0004DF21	0000001F	C	Flash Testmanager Area     39%
ROM:0004DFC9	0000001F	C	Flash Application Area     60%
...
ROM:0052CF89	0000001F	C	Flash Application Area     89%
ROM:0052D031	0000001F	C	Verifying Flash            90%
ROM:0052D0D9	0000001F	C	Flashing finished         100%
ROM:0052D140	00000009	C	ADMINEND

What you find it that each block starts with an message presented in update-mode, shown on screen of FX:

IMG_2377.JPG

IMG_2380.JPG

The whole file is split up into blocks of 0x38 bytes in size (unused bytes padded with "FF"). I found this structure to be there:

Code: Select all

Byte-Offset
0x00          : frametype
                   0x12 = Flash erase
                   0x16 = info payload to update display
                   0x22 = some kind of dummy frame (contains only "FF")
                   0x24 = Flash data
                   0x41 = END-Frame
                   0x42 = contains 0x0E additional bytes of a prior 0x12 command-frame (see below)
0x01..0x04 : number of payload bytes after frame header (0x00 means "no data") in Little-Endian format
0x05..0x07 : target address (Little Endian)
0x08          : Always 0x00 (padding byte?)
0x09..0x37 : Frame payload data of given length (all "FF" if length was 0)

Next i would like to find out the different frametypes:

Code: Select all

Format of frametype 0x16:
0x00 : The progressbar image percentage value (0x3F = 63%)
0x01.. : ASCII-Text shown in display e.g. "Flashing finished         100%", padded to 30 characters with "00" bytes up to end of given payload length

Format of frametype 0x24:
The "FDS Area" is written to 0x0002 0000
The "Testmanager" (FGMAGIC.TMG) to 0x0003 0000
The "Application Area" (FGMAGIC.STD) to 0x0007 0000

Format of frametype 0x42:
"02 00 00 00 00 00 0A 00 46 00 FA 00 0F 00"

The very last block contains this:

Code: Select all

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

0052D140  41 44 4D 49 4E 45 4E 44 00 00 00 00 00 00 00 00  ADMINEND........
0052D150  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0052D160  00 00 00 00 00 00 00 00 03 00 00 00 04 00 00 00  ................
0052D170  02 00 00 00 3C 00 00 00                          ....<...

Code: Select all

0x00 .. 0x07 "ADMINEND" (keyword), frametype 0x41

This is the rest (trailer) of the DNL file:

Code: Select all

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

0052D170                          00 00 00 00 10 0A 08 0B          ........
0052D180  00 00 01 00 CE DE AD CE 31 21 52 31 94 D1 52 00  ....ÎÞ.Î1!R1”ÑR.
0052D190  25 FE 51 7C                                      %þQ|

split into DWORDs (left size in native byteorder, little-endian. right size in Big-Endian):
1. 0000 0000 = 0000 0000
2. 100A 080B = 0B08 0A10
3. 0000 0100 = 0001 0000
4. CEDE ADCE = CEAD DECE
5. 3121 5231 = 3152 2131
6. 94D1 5200 = 0052 D194
7. 25FE 517C = 7C51 FE25

The 1st up to the 5th DWORD seems to be the same on all DNL-files (maybe a signature?)
The 6th DWORD is the length of the fgd.dnl file (0x52D194)
The 7th DWORD is aa CRC-32 checksum of the whole file (without the checksum itself)

There is also other interesting stuff inside, which we can look into as soon as we disassembled the structure:

Code: Select all

ROM:00113F49	0000002C	C	Fgs_AppHmi_u32VideoSignalCallback: VIDEO-CAL
ROM:00114159	00000014	C	/cygdrive/c/AlteraWork/LS_Release/di_fgs_sw/Components/FgsAppHmi/src/FgsAppHmi.cpp
# Oh boy, i wish i had this cpp-source at hand ;-)
ROM:001141F9	0000001C	C	FGS_VideoScreen_vIsVideoSignal: bVideoSignal = %d : bNewVideoSignal = %d
ROM:0011425D	00000028	C	FGS_VideoScreen_vIsVideoSignal: Video signal available\n
ROM:001142A1	0000001C	C	FGS_VideoScreen_vIsVideoSignal: NO Video signal\n
ROM:001142E1	00000014	C	!!!!!!!!!!!!!!!!!!!!  FGS_EVENT_HMI_VIDEO_FORCE_RESET  !!!!!!!!!!!!!!!!!!!!!!!!!!!\n
ROM:00114351	00000014	C	FGS_EVENT_HMI_VIDEO_FORCE_RESET
ROM:001145A5	00000028	C	fgs_tclEntry::vSwitchVideo:  ################################    VIDEO_ON   
ROM:00114611	0000002C	C	tclEntry::vSwitchVideo:  ################################    VIDEO_OFF   

So, with this information it should be possible to create a C program to extract the binary image parts out of this DNL file and gain a full image of the Graphicsboard Flash.

[tomy75]

great go4it

Screen Shot 2020-01-10 at 15.44.24.png

you can extrac ony bin data

[Go4IT]

I've manage (somehow to create a small program to extract the Flash-area-files out of the fgs.dnl file.
You find the source and EXE in the dnl_unpack.zip and example data inside fgs.dnl_extraction.zip.

There are 3 areas comming out of the DNL file:
0x0002 0000 - 0x0002 009F : FDS (data)
0x0003 0000 - 0x0006 CACF : Testmanager (program)
0x0007 0000 - 0x0044 326B : Application (program)

Next i try to find out the CPU architecture of the programs to get them disassembled in IDA Pro.

[tomy75]

super go4IT

what fgs file you use? one is 5,4MB an other is 5,5MB

thenx

Screen Shot 2020-01-12 at 22.00.17.png

[Go4IT]

what fgs file you use? one is 5,4MB an other is 5,5MB

With a simple filecompare you could have found out yourself Well, it's the basic "ford_lsr" version.

I beliefe the other one, "f_ls_rvc" is just a bit newer and compiled with a different tool. Because RVC must not necessarily mean "Rear View Camera", as we like it to be, but in perspective of a programmer it is more "RealView Compiler" (http://infocenter.arm.com/help/index.js ... cahef.html). If you look at the strings inside the image, there are indications for that theory.

[tomy75]

yes i now you use "ford_lsr" version

Wouldn't this help us?

https://www.mikrocontroller.net/topic/478192#new

[Go4IT]

That's a different topic! Is't about running the main FW on an QEMU Emulator on PC instead of the board. Besides, this is me you are refering to

[tomy75]

im found this comment in system.elf
its from ARM/Thumb C/C++ Compiler, RVCT2.1 [Build 583]

comment.txt

[DGAlexandru]

The same file modified for easy read (open with Notepad++):

Code: Select all

Input Comments:
fileutil.o  
	ARM/Thumb C/C++ Compiler, RVCT2.1 [Build 583] tcc --debug -c --remove_unneeded_entities -oY:/build/nucleus_core/vfat/nucleus/arion/nucleus_vfat_lib_r/release/objects/fileutil.o --diag_style=ide 
	--cpu=ARM926EJ-S --fpmode=ieee_full -IX:/di_arion_psw/components/interfaces/ -IX:/di_arion_psw/products/interfaces/ -IX:/di_arion_psw/products/nucleus_core/core/nucleus/include/ -IX:/di_arion_psw/products/nucleus_core/file/nucleus/include/ -IX:/di_arion_psw/products/nucleus_core/vfat/nucleus/include/ -IY:/build/nucleus_core/vfat/nucleus/arion/nucleus_vfat_lib_r/release/ -IY:/build/nucleus_core/vfat/nucleus/arion/nucleus_vfat_lib_r/release/versionheader/ -DARM -DNO_DLL_USE -DOSAL_CONF=OSAL_NUCLEUS -DOSAL_PLATFORM=OSAL_TUAREG -DSYSTEM_S_USE_BPSTL -DVARIANT_S_FTR_DISABLE_HEAPCLEAR -DVARIANT_S_FTR_ENABLE_FFS2TFFS -DVARIANT_S_FTR_ENABLE_FFS_3_4 -DVARIANT_S_FTR_ENABLE_LOGICAL_STACK -DVARIANT_S_FTR_ENABLE_RADIO4PARAMOUNT_PLATFORM -DVARIANT_S_FTR_ENABLE_SYSTEM_PROFILER -DVARIANT_S_FTR_ENABLE_TFFS -DVARIANT_S_FTR_ENABLE_TRACE_EXT_PROTOCOL -DVASCO_OS_NUCLEUS -D__arm -O2 --apcs=/inter --brief_diagnostics --force_new_nothrow --no_wrap_diagnostics X:/di_arion_psw/products/nucleus_core/vfat/nucleus/sources/fileutil.c
dfixu.o  
	ARM/Thumb Macro Assembler, RVCT2.1 [Build 328] --schedule 
	--cpu=4TxM --depend=dfixu.d --fpu=none --object=dfixu.o --schedule_cpu="ARM9E-S,ARM10200E,ARM1136JF-S" --apcs=/no8byte/interwork/swstna/ropi/rwpiclient --memaccess=rw:-S22 -I../../../clx --predefine="INTERWORK SETL {TRUE}" --predefine="fpu_none
scanf_char.o  
	ARM/Thumb C/C++ Compiler, RVCT2.1 [Build 328] armcc --thumb -c --split_ldm -oscanf_char.o --depend=scanf_char.d --schedule_cpu="ARM9E-S,ARM10200E,ARM1136JF-S" 
	--cpu=4TxM --fpu=none -I../../ -I../../angel -I../../public -J../../stdh -Dscanf_char_c -Otime --apcs=/no8byte/interwork/noswst/norwpi/ropi --memaccess=rw:-S22 ../../scanf.c

comment_easyRead.txt

comment.txt opened in Notepad++ then:
search and replace in Regular expression mode for (ARM/Thumb) with \n \t $1 (new line, tab, searched pattern)
search and replace in Regular expression mode for (--cpu) with \n \t $1 (new line, tab, searched pattern)
search and replace in Regular expression mode for \x0\x0\x0(.+\.o) (three NULL chars, then anything untill .o) with \n $1 (new line, searched pattern)
search and replace in Regular expression mode for \x0\x0(.+\.o) (two NULL chars, then anything untill .o) with \n $1 (new line, searched pattern)

[sanndo]

OK, all system.elf code is write and compile with Nucleus RTOS, I think.
Did anyone have experience with this IDE?