Garmin Obstacle Databases for Gns430 Support?

[unflavoredgelatin]

Is it possible to support the Garmin Obstacle and Terrain databases for the gns430's? I'd be happy to test anything to help.

[dimaryaz]

Not currently possible - though I've been working on that for a while.

First, you need the Garmin programmer device; I'm fairly certain that the Skybound device physically cannot support the Terrain/Obstacles cards.

I have a work-in-progress branch that implements reading and writing from the Terrain/Obstacles data card. That should let you do two things:

• Back up a data card to a file: jdmtool read-database backup.bin
• Restore it from a backup: jdmtool write-database backup.bin

For some reason, I haven't been able to copy one data card to a different data card: a few blocks remain empty, the verification step fails, and GNS 430 loads the obstacles database, but shows a "TER FAIL" error message (But I was able to restore the second card from its own backup successfully, so at least that fixed the error.) I'm still not sure if that's a problem with the data card, or some kind of copy protection, or what. But I haven't done that much testing here.

I have not implemented logging into Garmin, accessing databases, etc. - but, it's actually not difficult to download them. See this comment and file names in the discussion before it.

Once you have Garmin's files, you can extract them using jdmtool extract-taw .... I still don't know how to properly copy the extracted files to the card. Unlike NavData cards where the whole data card is the database, the TAWS cards seem to have four data locations at these sectors (where each sector is 0x10800 bytes):

• 0: Some constant data that should always be there; if it's not, Garmin attempts to "repair" the card. The data seems to contain file names: basemap.bin, obstacle.odb, airport.adb, terrain.tdb, esn.txt.
• 320 (0x140): Obstacles (obstacle.odb?)
• 640 (0x280): Airport Terrain (airport.adb?)
• 1920 (0x780): Terrain (terrain.adb?)

I'm guessing basemap.bin refers to 0x0 itself. No idea what esn.txt is or where it might be located.

However, even then, when Garmin copies the files to the data card, it modifies a few bytes, so the result is not exactly the same as the original file. I'm guessing it's some form of copy protection. (But I wouldn't be surprised if it doesn't actually do anything; they have a bunch of other completely pointless copy protection going on.) I haven't had a chance to really test it. It's possible that simply copying the files would work.

jdmtool write-database currently can only write the whole card. I was going to add options like --offset, but haven't done that yet. But, you could still do something like read the whole card, modify part of the file, then write the whole file back.

Anyways, let me know if you manage to get any of this working, or if you manage to figure out any of Garmin's logic.

[eld400]

jdmtool clear-card not work correctly for taws card

jdmtool detect -v
Found a Garmin device at Bus 001 Device 007: ID 091e:1300
Firmware version: Aviation Card Programmer Ver 3.05 Apr 01 2024 08:42:10
Chip IIDs: 0x010179ec
Card type: 256MB Terrain/Obstacles, 1 chip(s) of 256MB

PS > jdmtool clear-card
Found a Garmin device at Bus 001 Device 007: ID 091e:1300
Detected data card: 256MB Terrain/Obstacles
Clear all bytes on the data card? (y/n) y
Erasing the database: 100%|██████████████████████████████| 277M/277M [00:08<00:00, 33.6MB/s]
Done in: 8.3s.

jdmtool read-database testtaw1.bin
Found a Garmin device at Bus 001 Device 007: ID 091e:1300
Detected data card: 256MB Terrain/Obstacles
Reading the database: 100%|██████████████████████████████| 277M/277M [00:54<00:00, 5.07MB/s]
Done in: 54.7s.

when I check testtaw1.bin, all bytes are not set to FF.

I write 00 to all bytes on card (I have checked, all bytes is set to 0)
and erase card, I read card and check if all are to 0xFF

first no 0xFF (0x00) begin at 0x4200000
and 0xFF continue at 0x8400000
next 0x00 at 0xC600000 to 0x10800000

By the way, it's weird 0x10800000 while the memory is 256Mb, normaly for 256Mb address max is 0x10000000 !

[dimaryaz]

@eld400: Oh, if erasing doesn't work correctly, that would explain all the bugs! I will test that when I get a chance.

And yes, there are lots of weird things about the data card: it uses different block sizes when reading and writing, the sector size is not divisible by the block sizes, and (I think) 256MB is not divisible by the sector size, so the card is actually slightly bigger than 256MB.

[eld400]

I just check type of chip on my card, it's 128M (Chip IIDs: 0x010179ec) not 256M like jdmtool say, chip: K9K1G08U0M-YCB0 samsung Nand flash memory.

If this data can help you :

K9K1G08U0M-YCB0.pdf

[dimaryaz]

Ah, I didn't know your card was 128MB; I was assuming it was the same as mine, just a different IID (mine is 0x0101daec). Just pushed a fix: 0a786d9

Your data does explain some of these numbers: https://github.com/dimaryaz/jdmtool/blob/taws/src/jdmtool/data_card/common.py#L22

• sector_size=0x10800: that matches "1 Block = (16K + 512) Bytes"
• min_write_size=0x0840: that's exactly 4 pages; I wonder why 4? I'll see if 528 also works when writing.
• read_size=0xf800: that's... 120 pages + 128 bytes? Don't know where that comes from.

[dimaryaz]

I write 00 to all bytes on card (I have checked, all bytes is set to 0)
and erase card, I read card and check if all are to 0xFF

first no 0xFF (0x00) begin at 0x4200000
and 0xFF continue at 0x8400000
next 0x00 at 0xC600000 to 0x10800000

If I divide those by 0x10800 to get block numbers, I get:

• First range: 0x400-0x800
• Second range: 0xC00-0x1000

Actually, if this is a 128MB card, then it looks like jdmtool just read the same 128MB twice: the second range is the first plus 0x800.

I just tried erasing a new 256MB card. I got all 0xFFs except for four blocks: 0x700, 0x701, 0xE64, 0xE65. Don't know what that means.

I also saw this in the PDF - could that be the answer?

Any intentional erasure of the original invalid block information is prohibited.

Oops...

[eld400]

Hi,
I have allready try with : (0xec, 0x79): (DataCardType.TAWS, 0x800, "Terrain/Obstacles")

if I clear card,
bytes 0 to 41FFFFF are at FF,
bytes 4200000 to 83FFFFF are at 00

PS > jdmtool clear-card
Found a Garmin device at Bus 001 Device 005: ID 091e:1300
Detected data card: 128MB Terrain/Obstacles
Clear all bytes on the data card? (y/n) y
Erasing the database: 100%|██████████████████████████████████████████████| 138M/138M [00:04<00:00, 33.7MB/s]
Done in: 4.1s.
PS >
PS > jdmtool read-database .\testtaw.bin
Found a Garmin device at Bus 001 Device 005: ID 091e:1300
Detected data card: 128MB Terrain/Obstacles
Reading the database: 100%|██████████████████████████████████████████████| 138M/138M [00:26<00:00, 5.24MB/s]
Done in: 26.4s.
PS >

[sHorst]

Hey nice work,

i did some research. And i came up with those offsets:

for 128MB Cards:

    OFFSET_128MB_SERIAL   = 0x000001f6
    OFFSET_128MB_BASEMAP  = 0x00000400
    OFFSET_128MB_OBSTACLE = 0x00a00000
    OFFSET_128MB_AIRPORT  = 0x01200000
    OFFSET_128MB_TERRAIN  = 0x01e00000
    OFFSET_128MB_END      = 0x08000000
    BLOCK_SIZE_128 = 0x200
    FOOTER_SIZE_128 = 0x10

for 256MB Cards:

  OFFSET_256MB_SERIAL   = 0x000001f6
   OFFSET_256MB_BASEMAP  = 0x00100000
   OFFSET_256MB_OBSTACLE = 0x01400000
   OFFSET_256MB_AIRPORT  = 0x02800000
   OFFSET_256MB_TERRAIN  = 0x07800000
   OFFSET_256MB_END      = 0x10000000
   BLOCK_SIZE_256 = 0x800
   FOOTER_SIZE_256 = 0x40

General Constants

    BAD_SEKTOR_SIZE = 0x4000

    FILENAME_INDEX_BASEMAP = 0
    FILENAME_INDEX_OBSTACLE = 1
    FILENAME_INDEX_AIRPORT = 2
    FILENAME_INDEX_TERRAIN = 3
    FILENAME_INDEX_ESN = 4

The cards have a footer for each block. It includes a index and a checksum

i use those to calculate between Card (raw) address to logic address:

  # Each block has a 0x10 or 0x200 Byte long trailer, which contains blockNr and CRC
    def logic_to_raw_address(address, block_size=BLOCK_SIZE_128, footer_size=FOOTER_SIZE_128):
        block = floor(address / block_size)
        return address + block * footer_size

    def raw_to_logic_address(start, block_size=BLOCK_SIZE_128, footer_size=FOOTER_SIZE_128):
        block = floor(address / (block_size + footer_size))
        return address - block * footer_size

The second block (ID 1), has a BadBlockTable, which nukes certain block nr. Those are than skipped for reading/writing. That explains why the cards look different.

[dimaryaz]

@sHorst: thanks for the info!

The second block (ID 1), has a BadBlockTable, which nukes certain block nr.

Heh, it starts with "XBLKS" - I guess that stands for "bad blocks". I've noticed it before, and was wondering what it meant. But, not sure how to interpret the rest of it.

I've looked at the footers, and in my case (256MB card), it does not match what the PDF says about bad blocks. (Don't know if it's because the PDF is about 128MB cards, or if it's just Samsung's convention, and Garmin does it differently.)

In any case, what I see in footers on a brand new card:

• Bad blocks: all 0s
• Good blocks: 4-byte block number (little endian), then 0s, then what I'm guessing is a 4-byte checksum

But, then I looked at a backup of a different card, and the blocks start with block number plus 0x01000000 for some reason!

[dimaryaz]

I'm now trying to make sense of the bad blocks table. Here are the values from three data cards I have (after removing XBLKS and trailing 0s):

• 7c000002: no bad blocks
• be02008003320702: 2 sectors: 0x700 (blocks 0xe000-0xe01f), 0x701 (blocks 0xe020-0xe03f)
• 0802004c01220302: 4 sectors: 0x298 (blocks 0x5300-0x531f), 0x299 (blocks 0x5320-0x533f), 0x644 (blocks 0xc880-0xc89f), 0x645 (blocks 0xc8a0-0xc8bf)

(By sector I mean 32 blocks - but looks like the bad blocks are always 64 at a time?)

[sHorst]

i think the pdf only states what comes from the factory about the bad blocks, garmin will read those infos and stores them in the sektor 1 (second block).

i found that this code does give good results for bad blocs table for both cards (128 and 256):

        # first Block contains BadBlockTable
        xblk, crc = read_block(fd, BLOCK_XBLK, block_size=BLOCK_SIZE, footer_size=FOOTER_SIZE)
    
        bb_count = int.from_bytes(xblk[6:8], 'little')
        bad_sektors = []
        for i in range(bb_count):
            bad_sektors += [int.from_bytes(xblk[8 + i*2:10 + i*2],'little'), ]
    
        bb_crc = 0 
        for i in range(bb_count*2 + 8): 
            # ignore CRC in calc
            if i == 5:
                continue
            bb_crc += xblk[i]
        bb_crc = (~bb_crc & 0xFF) + 1 
    
        if bb_crc != xblk[5]:
            print('CRC of XBLK is wrong: {bb_crc:02x} vs. {xblk[5]:02x}')
    
        print('bb_count: ', bb_count)
        print('bad sektors: ', [hex(x*0x4000) for x in bad_sektors])
    
        # unknown badBlock fields
        field_0x24 = xblk[bb_count * 2 + 8]
        field_0x2c = xblk[bb_count * 2 + 9]
        field_0x34 = int.from_bytes(xblk[bb_count * 2 + 0xa:bb_count * 2 + 0xd], 'little')
        print(f'field 0x24: {field_0x24:02x}')
        print(f'field 0x2c: {field_0x2c:02x}')
        print(f'field 0x34: {field_0x34:04x}')

and for then converting that to the offsets:

   def isBadBlock(block, bad_sektors=None, block_size=BLOCK_SIZE_128):
        return isBadOffset(block * block_size, bad_sektors)
    
    
    def isBadOffset(offset, bad_sektors=None):
        for bad_sektor in bad_sektors:
            if offset in range(bad_sektor * BAD_SEKTOR_SIZE, (bad_sektor + 1) * BAD_SEKTOR_SIZE):
                return True
        return False

[dimaryaz]

Nice! Your code works; I just needed to use 64-block sectors instead of 32-block ones, and then the numbers are correct. (I also missed a range of bad blocks in the second card.)

In my case, after the bad sectors, I just have a single 0x02 byte, and it's the same for all three cards.

Just a guess: bad sectors probably need to be remapped to other locations. That's better than skipping them because, if a new sector goes bad, then skipping it means having to move all of the data in the following sectors. Is it possible that your unknown fields are numbers of the replacement sectors? (And I don't have them because Garmin has not yet needed to write anything to the bad sector locations?)

[sHorst]

possible, but in the garmin binaries i only saw the bad block table read not written, so my assumtion is, that those are only used by the factory not later in the live of the card.

I also saw, that they only skip bad blocks. but the "files" start at the same offsets anyhow. so there is a max number of bad blocks per file.

[dimaryaz]

Well, Garmin Database Manager does have a way to "repair" the data card. I'll see what exactly it does, but I would guess that it looks for bad blocks and writes the table.

Yeah, the fact that file offsets are always the same implies that bad blocks don't cause the rest of the data to shift. So the question is, what happens if you have a bad block at one of the file offsets, and need to write data to it? I guess for now, I could just have jdmtool show an error saying "sorry, you're out of luck". In theory, I could implement a virtual USB device (using e.g. USB/IP) that simulates a USB programmer with a card with bad blocks at the right locations, and see what Garmin does... Huge pain, but technically doable.

[sHorst]

i assume, the skip mechanic will work, and the first block ist just skipped. but we need to investigate that further. The question is, what would happen, if the bad block table or the first block is broken, ..