[xDHC]

Originally Posted by jacobtc

Not surprising really, they will probably sell af version with "AMAZING QUALITY SCREEN ANDROID AUTO, WOW" at a later date.

Yes that is what i also suspect. And then they will do what carlinkit did to me a year ago, release a new unit and tell me i can upgrade to a new version for more money.

[Laurens0619]

Originally Posted by Firefly1337

Unfortunately no, I never figured out which pin goes where.
With the official SoC layout it is very easy to identify the serial pins of the chip. But on the PCB they just disappear in Via's, so it's impossible to tell where they are going.
The MCU has an empty header right next to it but also there I was only able to identify basic things like VCC and GND. And then you would only have access to the MCU, not the rest of the system.

The Indiwork manual has a nice layout on page 4 with I2C pins described on the main harness. Perhaps that could be used as an entry point.
The other cable has some undisclosed pins. Perhaps these go to the system itself?

There is an extra partition called 'runtime_cfg' that has some basic config flags e.g. which hardware ports (USB, graphical, etc) are used and in what order. There's also one that I think might enable USB OTG mode (currently it's set to '0'). But for that we need to be able to edit the .bin first...



We are not trying to change the screen's resolution, it will still stay at 1280x480. What we are trying to change is the resolution (probably more like 'quality') of AA.

That is too bad
I also found your post with the reference to the official ISPBoot packer.
Wouldnt we able to use this tool to pack the modified images?
https://f30.bimmerpost.com/forums/sh...19&postcount=4

edit: I tested the tool and it indeed breaks because the signature differs (the bimmertech file signature is "Gemini_ISP_image". After modifying that in the source the tool continues but fails with a strange error: sh: 1: Syntax error: "(" unexpected

[dws199]

Originally Posted by xDHC

Yes that is what i also suspect. And then they will do what carlinkit did to me a year ago, release a new unit and tell me i can upgrade to a new version for more money.

When I initially reported the issue to Carlinkit last year they sent me a fix but it turns out it was for their older wired version. I've pasted below the link in case it is of any use.

https://www.facebook.com/Carlinkit/p...34710657643619

[xDHC]

Originally Posted by dws199

When I initially reported the issue to Carlinkit last year they sent me a fix but it turns out it was for their older wired version. I've pasted below the link in case it is of any use.

https://www.facebook.com/Carlinkit/p...34710657643619

Oh i dont got a carlinkit anymore, i used to have their wired version and that fix they had really had minimal change, they upped the contrast for example. Red turned out to be pink due to it.

[nitsuj17]

Originally Posted by 07e92

muniz_ri do you have the Andream or Carlinkit unit? I could be wrong, but I think you have the Carlinkit, just want to double check before I flash my Carlinkit with 20.06.02 from the link below.

how is performance on that mcu? i am still using the latest official carlinkit one, and hadn't bothered updated the mcu to any of the andream ones

Originally Posted by xDHC

I've had confirmation from andream that they won't fix it and don't really care what others such as bimmertech do.

1) they might no longer be paying for updates in their contract with the vendor or
2) magically the fix will appear on more recently purchased one

Originally Posted by jacobtc

Not surprising really, they will probably sell af version with "AMAZING QUALITY SCREEN ANDROID AUTO, WOW" at a later date.

yeah certainly a possibility, since there isn't another "obvious" update to justify a new unit. the original mmi's were for adding rear/front cams, then there was the ones to add in apple tv/firesticks/screen mirroring, then wired carplay/aa, then wired carplay/aa widescreen, then wireless carplay/aa....next probably your idea, or "Super High Definitions Resolutions to Effect of Auto Android System Function"

[Matusov]

Originally Posted by muniz_ri

Yep, I have a Carlinkit unit. mcu 20.06.02 works great.

Originally Posted by muniz_ri

Yep, I have a Carlinkit unit. mcu 20.06.02 works great.

I can also confirm that 20.06.02 works on Carlinkit.

Absolutely no lag and the most responsive version. I did notice that this one does not have Menu to Cancel Reverse button. But the work-around is to use the actual physical reverse camera button to go back to Carlinkit.

One question I have is in AA google maps when I select to free move around the map, I can't actually move the cursor only zoom works. Any ideas?

[muniz_ri]

Originally Posted by nitsuj17

how is performance on that mcu? i am still using the latest official carlinkit one, and hadn't bothered updated the mcu to any of the andream ones

There is zero lag.

[Firefly1337]

Thanks for the feedback, I added that MCU to the list for Carlinkit as well.

[muniz_ri]

Originally Posted by Laurens0619

That is too bad
I also found your post with the reference to the official ISPBoot packer.
Wouldnt we able to use this tool to pack the modified images?
https://f30.bimmerpost.com/forums/sh...19&postcount=4

edit: I tested the tool and it indeed breaks because the signature differs (the bimmertech file signature is "Gemini_ISP_image". After modifying that in the source the tool continues but fails with a strange error: sh: 1: Syntax error: "(" unexpected

If it helps...Bimmertech didn't begin locking down their firmware until February. May make more sense to modify their Jan update to get around the newly added security.

Also, I am a newbie to linux but also thought that using the official packing tool to re-pack a modified bin may be the best approach. Can you give me some pointers on how to run the tool?

[bgalakazam]

Installed the module on my HU_ENTRYNAV 6.5" and it just worked. Audio, mic and maps - pretty much all I needed.

[Firefly1337]

I managed to extract the .bin using the official script and repack it again.
In the isp.c only the signature needs to be changed: (thx Laurens0619 )

const u08 file_header_signature[] = "Gemini_ISP_image";

After recompiling ('make') it worked for me using the 'extract4tftpupdate' function.
That will split each partition into multiple files: TFTP0000.BIN contains the flash script for that single partition and any subsequent file (TFTP00xx.BIN) will be a 2MB chunk of that partition.
I wrote a script that will extract and merge each partition back into a single file:

#!/bin/bash

PARTITIONS="uboot2 env env_redund ecos kernel rootfs spsdk spapp nvm pq logo tcon iop_car runtime_cfg vi isp_logo vendordata pat_logo version_info vd_restore anm_logo";

mkdir partitions;

for part in $PARTITIONS; do
        echo $part;
        ./isp_gemini extract4tftpupdate ISPBOOOT.BIN $part $part
        rm partitions/$part;
        rm $part/TFTP0000.BIN;
        cat $part/TFTP* > partitions/$part;
        rm -rf $part;
        echo "";
done;

Afterwards the local dir 'partitions/' should contain all partitions.
Only problem now are uboot and xboot partitions. It will only extract 'uboot2', so we are missing 'xboot1', 'xboot2', 'uboot0' and 'uboot1'.
They are not extracted because according to the comments in the isp.c script they are never flashed to the unit.
But you still need it for the file, of course.
uboot1 and uboot2 are identical, so they can just be copied.
The other boot partitions can be extracted from the original .bin file using dd.

Once you finally have all the partitions back together, this is the partition table and repack command:

./isp_gemini pack_image ISPBOOOT.BIN \
    xboot0 uboot0 \
    xboot1 0x100000 \
    uboot1 0x100000 \
    uboot2 0x100000 \
    env 0x80000 \
    env_redund 0x80000 \
    ecos 0x800000 \
    kernel 0x600000 \
    rootfs 0x5A0000 \
    spsdk 0x34E0000 \
    spapp 0x1400000 \
    nvm 0x1000000 \
    pq 0x20000 \
    logo 0x200000 \
    tcon 0x20000 \
    iop_car 0x200000 \
    runtime_cfg 0x100000 \
    vi 0x20000 \
    isp_logo 0x500000 \
    vendordata 0x40000 \
    pat_logo 0xD00000 \
    version_info 0x20000 \
    vd_restore 0x40000 \
    anm_logo 0x600000

The resulting .bin file is almost identical to the original file.
Why almost? While the flashing script at the end is mostly the same and even all the md5 checksums perfectly match, the NAND flash commands are different.

The original .bin has them like this:

nand write.bblk $isp_ram_addr $isp_nand_addr 0x8800

While the new one has this:

bblk write bblk $isp_ram_addr $isp_nand_addr 0x8800

So either this does not matter and is just a different syntax - or the public code uses a newer/different version of u-boot/xboot, which we don't have :/

Thoughts?

[cossie1]

Originally Posted by Firefly1337

I managed to extract the .bin using the official script and repack it again.
In the isp.c only the signature needs to be changed: (thx Laurens0619 )

const u08 file_header_signature[] = "Gemini_ISP_image";

After recompiling ('make') it worked for me using the 'extract4tftpupdate' function.
That will split each partition into multiple files: TFTP0000.BIN contains the flash script for that single partition and any subsequent file (TFTP00xx.BIN) will be a 2MB chunk of that partition.
I wrote a script that will extract and merge each partition back into a single file:

#!/bin/bash

PARTITIONS="uboot2 env env_redund ecos kernel rootfs spsdk spapp nvm pq logo tcon iop_car runtime_cfg vi isp_logo vendordata pat_logo version_info vd_restore anm_logo";

mkdir partitions;

for part in $PARTITIONS; do
        echo $part;
        ./isp_gemini extract4tftpupdate ISPBOOOT.BIN $part $part
        rm partitions/$part;
        rm $part/TFTP0000.BIN;
        cat $part/TFTP* > partitions/$part;
        rm -rf $part;
        echo "";
done;

Afterwards the local dir 'partitions/' should contain all partitions.
Only problem now are uboot and xboot partitions. It will only extract 'uboot2', so we are missing 'xboot1', 'xboot2', 'uboot0' and 'uboot1'.
They are not extracted because according to the comments in the isp.c script they are never flashed to the unit.
But you still need it for the file, of course.
uboot1 and uboot2 are identical, so they can just be copied.
The other boot partitions can be extracted from the original .bin file using dd.

Once you finally have all the partitions back together, this is the partition table and repack command:

./isp_gemini pack_image ISPBOOOT.BIN \
    xboot0 uboot0 \
    xboot1 0x100000 \
    uboot1 0x100000 \
    uboot2 0x100000 \
    env 0x80000 \
    env_redund 0x80000 \
    ecos 0x800000 \
    kernel 0x600000 \
    rootfs 0x5A0000 \
    spsdk 0x34E0000 \
    spapp 0x1400000 \
    nvm 0x1000000 \
    pq 0x20000 \
    logo 0x200000 \
    tcon 0x20000 \
    iop_car 0x200000 \
    runtime_cfg 0x100000 \
    vi 0x20000 \
    isp_logo 0x500000 \
    vendordata 0x40000 \
    pat_logo 0xD00000 \
    version_info 0x20000 \
    vd_restore 0x40000 \
    anm_logo 0x600000

The resulting .bin file is almost identical to the original file.
Why almost? While the flashing script at the end is mostly the same and even all the md5 checksums perfectly match, the NAND flash commands are different.

The original .bin has them like this:

nand write.bblk $isp_ram_addr $isp_nand_addr 0x8800

While the new one has this:

bblk write bblk $isp_ram_addr $isp_nand_addr 0x8800

So either this does not matter and is just a different syntax - or the public code uses a newer/different version of u-boot/xboot, which we don't have :/

Thoughts?

Sounds like custom software updates are coming soon

[muniz_ri]

Originally Posted by Firefly1337

I managed to extract the .bin using the official script and repack it again.
In the isp.c only the signature needs to be changed: (thx Laurens0619 )

const u08 file_header_signature[] = "Gemini_ISP_image";

Awesome. Have you attempted to flash the modified bin?

[Laurens0619]

Originally Posted by Firefly1337

I managed to extract the .bin....

Thoughts?

Great development
I noticed they recently committed the file, maybe you can use the previous version of the file? Im on my phone so hard to analyse the code for the broken parts

https://github.com/sunplus-plus1/isp...3a9721851d5300

https://github.com/sunplus-plus1/isp...ools/isp/isp.c

[dkeruza]

Originally Posted by Firefly1337

I managed to extract the .bin using the official script and repack it again.
In the isp.c only the signature needs to be changed: (thx Laurens0619 )

const u08 file_header_signature[] = "Gemini_ISP_image";

After recompiling ('make') it worked for me using the 'extract4tftpupdate' function.
That will split each partition into multiple files: TFTP0000.BIN contains the flash script for that single partition and any subsequent file (TFTP00xx.BIN) will be a 2MB chunk of that partition.
I wrote a script that will extract and merge each partition back into a single file:

#!/bin/bash

PARTITIONS="uboot2 env env_redund ecos kernel rootfs spsdk spapp nvm pq logo tcon iop_car runtime_cfg vi isp_logo vendordata pat_logo version_info vd_restore anm_logo";

mkdir partitions;

for part in $PARTITIONS; do
        echo $part;
        ./isp_gemini extract4tftpupdate ISPBOOOT.BIN $part $part
        rm partitions/$part;
        rm $part/TFTP0000.BIN;
        cat $part/TFTP* > partitions/$part;
        rm -rf $part;
        echo "";
done;

Afterwards the local dir 'partitions/' should contain all partitions.
Only problem now are uboot and xboot partitions. It will only extract 'uboot2', so we are missing 'xboot1', 'xboot2', 'uboot0' and 'uboot1'.
They are not extracted because according to the comments in the isp.c script they are never flashed to the unit.
But you still need it for the file, of course.
uboot1 and uboot2 are identical, so they can just be copied.
The other boot partitions can be extracted from the original .bin file using dd.

Once you finally have all the partitions back together, this is the partition table and repack command:

./isp_gemini pack_image ISPBOOOT.BIN \
    xboot0 uboot0 \
    xboot1 0x100000 \
    uboot1 0x100000 \
    uboot2 0x100000 \
    env 0x80000 \
    env_redund 0x80000 \
    ecos 0x800000 \
    kernel 0x600000 \
    rootfs 0x5A0000 \
    spsdk 0x34E0000 \
    spapp 0x1400000 \
    nvm 0x1000000 \
    pq 0x20000 \
    logo 0x200000 \
    tcon 0x20000 \
    iop_car 0x200000 \
    runtime_cfg 0x100000 \
    vi 0x20000 \
    isp_logo 0x500000 \
    vendordata 0x40000 \
    pat_logo 0xD00000 \
    version_info 0x20000 \
    vd_restore 0x40000 \
    anm_logo 0x600000

The resulting .bin file is almost identical to the original file.
Why almost? While the flashing script at the end is mostly the same and even all the md5 checksums perfectly match, the NAND flash commands are different.

The original .bin has them like this:

nand write.bblk $isp_ram_addr $isp_nand_addr 0x8800

While the new one has this:

bblk write bblk $isp_ram_addr $isp_nand_addr 0x8800

So either this does not matter and is just a different syntax - or the public code uses a newer/different version of u-boot/xboot, which we don't have :/

Thoughts?

Great Job!!!!!

Look at line 1408 of isp.c

My other concern is that they use a different type of SQUASHFS files system or a modified one. Their file system is not able to be mounted in my linux box. I can extract it, but not mount it.
After I extracte it, make the changes and rebuild the file I can mount it without issues.

[Firefly1337]

Originally Posted by dkeruza

Look at line 1408 of isp.c

Awesome!!! Thank you. I searched the file for the string before but no idea how I missed that.

Unfortunately I am not much of a C developer and not very deep in the compiling topic.

...(file_header_extract4update.partition_info[i].flags & FLAGS_BCH1K60) ? "bblk write bblk" : "nand write", ...

The '&' is the bitwise operator, right?
So probably that flag needs some adjustment:

#define FLAGS_BCH1K60 (1 << 0)    // partitions r/w by "nand read.bblk" and "nand write.bblk".

How does that define work? '1 << 0'
Found this: https://stackoverflow.com/questions/...-something-1-0
I need an explanation for that explanation Totally out of my depth here.

Originally Posted by dkeruza

My other concern is that they use a different type of SQUASHFS files system or a modified one. Their file system is not able to be mounted in my linux box. I can extract it, but not mount it.
After I extracte it, make the changes and rebuild the file I can mount it without issues.

Which OS do you have? VM?
It works in my Ubuntu VM.

[Laurens0619]

I was reading the rest of the repo and see the uboot (assume the thing that kicks off when usb drive is detected with firmware) being referenced a lot:

# How to use TFTP ISP to do partial update
# Execute "isp extract4tftpupdate" command to extract partial content from ISPBOOOT.BIN to produce
# TFTP BIN files. Please modify the partition name in the "isp extract4tftpupdate" instruction. You
# can update up to two partitions at the same time. For default, we will update uboot and kernel
# partitions. After TFTP BIN files are produced, let your board go into uboot and then execute the
# following uboot command.
# => run update_tftp
# It will update these partitions on the main storage of your board.

On an android phone you will go to fastboot (is that the same?) when holding some buttons.
Did anyone connected a usb keyboard and holded some buttons during boot?

Edit:
I dont think its the same board but vendors often apply same logic for different boards. Maybe the dip switches can be used to boot into uboot?
https://sunplus-tibbo.atlassian.net/...vices+of+Plus1

[biomed27]

Originally Posted by ///MToronto

Hi Guys,

I have the carlinkit using CarPlay but I am having a couple of issues:

1. When I call someone, I can't hear the person on the other end but that person can hear me. Also, when I try answer the phone using the steering wheel button, it hangs up the line. When I exit CarPlay and use the BMW system, everything works fine.

2. Long pressing the voice command button on the steering wheel does not activate Siri while in CarPlay.

Thanks for the help

1. Try deleting your phone from bmw interface on BT menu

2. Enable wheel key in set up menu. Go to BMW app logo if already in CarPlay mode and then set up. You should see the wheel key option.

[contracts34]

Originally Posted by Firefly1337

I managed to extract the .bin using the official script and repack it again.
In the isp.c only the signature needs to be changed: (thx Laurens0619 )

const u08 file_header_signature[] = "Gemini_ISP_image";

After recompiling ('make') it worked for me using the 'extract4tftpupdate' function.
That will split each partition into multiple files: TFTP0000.BIN contains the flash script for that single partition and any subsequent file (TFTP00xx.BIN) will be a 2MB chunk of that partition.
I wrote a script that will extract and merge each partition back into a single file:

#!/bin/bash

God I wish I could speak this language :clap:

PARTITIONS="uboot2 env env_redund ecos kernel rootfs spsdk spapp nvm pq logo tcon iop_car runtime_cfg vi isp_logo vendordata pat_logo version_info vd_restore anm_logo";

mkdir partitions;

for part in $PARTITIONS; do
        echo $part;
        ./isp_gemini extract4tftpupdate ISPBOOOT.BIN $part $part
        rm partitions/$part;
        rm $part/TFTP0000.BIN;
        cat $part/TFTP* > partitions/$part;
        rm -rf $part;
        echo "";
done;

Afterwards the local dir 'partitions/' should contain all partitions.
Only problem now are uboot and xboot partitions. It will only extract 'uboot2', so we are missing 'xboot1', 'xboot2', 'uboot0' and 'uboot1'.
They are not extracted because according to the comments in the isp.c script they are never flashed to the unit.
But you still need it for the file, of course.
uboot1 and uboot2 are identical, so they can just be copied.
The other boot partitions can be extracted from the original .bin file using dd.

Once you finally have all the partitions back together, this is the partition table and repack command:

./isp_gemini pack_image ISPBOOOT.BIN \
    xboot0 uboot0 \
    xboot1 0x100000 \
    uboot1 0x100000 \
    uboot2 0x100000 \
    env 0x80000 \
    env_redund 0x80000 \
    ecos 0x800000 \
    kernel 0x600000 \
    rootfs 0x5A0000 \
    spsdk 0x34E0000 \
    spapp 0x1400000 \
    nvm 0x1000000 \
    pq 0x20000 \
    logo 0x200000 \
    tcon 0x20000 \
    iop_car 0x200000 \
    runtime_cfg 0x100000 \
    vi 0x20000 \
    isp_logo 0x500000 \
    vendordata 0x40000 \
    pat_logo 0xD00000 \
    version_info 0x20000 \
    vd_restore 0x40000 \
    anm_logo 0x600000

The resulting .bin file is almost identical to the original file.
Why almost? While the flashing script at the end is mostly the same and even all the md5 checksums perfectly match, the NAND flash commands are different.

The original .bin has them like this:

nand write.bblk $isp_ram_addr $isp_nand_addr 0x8800

While the new one has this:

bblk write bblk $isp_ram_addr $isp_nand_addr 0x8800

So either this does not matter and is just a different syntax - or the public code uses a newer/different version of u-boot/xboot, which we don't have :/

Thoughts?

God how I wish I could speak this language

[Unspec]

Originally Posted by Firefly1337

Awesome!!! Thank you. I searched the file for the string before but no idea how I missed that.

Unfortunately I am not much of a C developer and not very deep in the compiling topic.

...(file_header_extract4update.partition_info[i].flags & FLAGS_BCH1K60) ? "bblk write bblk" : "nand write", ...

The '&' is the bitwise operator, right?
So probably that flag needs some adjustment:

#define FLAGS_BCH1K60 (1 << 0)    // partitions r/w by "nand read.bblk" and "nand write.bblk".

How does that define work? '1 << 0'
Found this: https://stackoverflow.com/questions/...-something-1-0
I need an explanation for that explanation Totally out of my depth here.



Which OS do you have? VM?
It works in my Ubuntu VM.

Single ampersand is bitwise, correct. && would be logical AND

1 << 0 is 1 shifted left 0 times, or 1 * 2^0. AKA 1. Likely done for consistency reasons, especially if there are bitwise shifts elsewhere in the code. There's no real deep meaning behind using 1 << 0, in this case. They're just setting the flag to 1.

[muniz_ri]

Attached are the logo image files for the Bimmertech and Carlinkit units.

[xDHC]

Originally Posted by muniz_ri

Attached are the logo image files for the Bimmertech and Carlinkit units.

Nice thanks! Any chance to get the backgrounds too? Would like to get rid of that ugly pos from andream.