[AstroZ]

Originally Posted by StevenN

Hi,

Well I changed my CIC 80gb HDD to a 120gb MSata, using the same parts as detailed on the installation instructions (Page 1). Everything worked fine, until now, And similar problems to what others have had I think? However, I may have a reasoning for this, if others could help with my reasoning, that would be appreciated.

This weekend, I noticed the CD Player would not work, unusual as I rarely use it, it simply reported, "Unreadable Media".

yes I had similar issues, the dvd player would not work until I re-imaged the drive. my music collection worked fine but it is rarely used or updated.

My maps update would also not work and I think this is because the map update software checks/verfies every file. (This may be the best way to reproduce the issue.)

Originally Posted by StevenN

Yesterday, I took the MSATA out and wote the cloned disc image back to it, everything is all working perfect again. This leads me to a possibility that the QNX system and Controller are not compatiable in the usage of the MSATA. I am thinking, that the MSATA has not corrupted, or suffered heat stroke, but has become full, and cant be erased deleted by the QNX and Controller.

With a HDD, you can simply write data back and forth to the HDD, however, with SSD's, you have to firstly delete the old data, and then that block can be used. Something that possibly the controller was not doing correctly.

This is an interesting theory. My thought are along the same lines.

In old school (pre SSD/ TRIM) Operating Systems like QNX, once some data is not needed (i.e. deleted) it is not "zeroed out", instead the file allocation bitmap is updated to mark that data as "empty" even though that physical place may still contain the discarded data. The below is a simplification:

File Allocation Bitmap:
1) There is a file from 0x0100-0x1000
2) There is a NOT file from 0x1000-0x1100 <-- this file was previously deleted
3) There is a file from 0x1100-0x2000
raw disk:
0x0100-0x1000: 1000010001010001....
0x1000-0x1100: 1101010000010001....
0x1100-0x2000: 0010010010000000....

SSD firmwares may be doing something that interferes with writing files. QNX probably does not use the SSD optimally for small files, nor tell the SSD deleted should now be zero'd. SSDs can only write to blocks, not to individual memory pages. On SSDs the TRIM ATA command is normally used do garbage collect silently in the background, as a form of optimisation.

Now the problem is when QNX tries to write a new smaller file where there was old non-zero data. For the sake of speed and flash memory life the SSD controller does not always write small files to the first avaliable space where the small file fits as the whole blocks have to be read, the small file inserted and then the whole block written back. see: https://www.anandtech.com/show/2738/8

This is similar to defragementation and may be why doing a dd on an SSD using if=/dev/zero is quick and mostly useless as the data may well still be there until garbage collected by TRIM.

in the above file system example, lets say the OS requests via the file system to the SSD a new file "4)" and is written to the file system. The SSD writes it at 0x2000-0x2100, rather than the free space.

write file 4) size 0x0100 content: 0010101111101110...

After the write:

File Allocation Bitmap:
1) ...
4) There is a new file from 0x2000-0x2200  
3) ...
raw disk:
...
0x1000-0x1100: 1101010000010001... <-- the old deleted file is not overwritten wastes SSD space
...
0x2000-0x2100:0010101111101110...

hopefully, you can see the problem.

Fortunately (or unfortuantely) the SSD is rarely written to in the CIC so this is not a common problem and is difficult to reproduce.

Remember, there are several issues at play here:
1) It could be that the SSD assumes TRIM is enabled on the OS but QNX does not support TRIM (likely). maybe the SSD cannot work without TRIM support in the OS.
2) It could be that TRIM is enabled on the SSD but the SSD does not have time to complete the zeroing operations e.g. when the car is off.
3) It could be that TRIM commands/low-level erase information never reaches the SSD because of the SATA->IDE controller.
4) it could be that after a long period of use without TRIM the time for writes becomes too long due to fragementation, and casues issues.
5) something else (e.g. SSD/flash memory health?)

Originally Posted by StevenN

So, on looking around the web, I found this PATA SSD Drive:

https://www.memoryc.co.uk/16612-128g...SABEgJyEfD_BwE

Does anybody have any experience of using these type of drives? Or can suggest an alternative?

Thanks

It may be worth trying, but you won't know if it has worked unless you are able to reproduce the issue. The assumption you are making is that this new drive will somehow always write the full file contents to the disk in the most optimal way (reorganising data). The real solution is for QNX to become SSD aware (almost impossisble!).

A simpler option would be looking at disabling TRIM on the SSD so that every write command is honored (at the cost of speed and SSD life). I'm not sure if there is a utility for this, and it may be specific to your SSD.

For now the simplest option seems to be to re image the SSD drive from the HDD every few years when it breaks.

Another option would be clearing the memory cells https://wiki.archlinux.org/title/Sol..._cell_clearing I suspect this is what happens when re imaging the drive.

It would also be worth checking the SSD health using SMART monitoring tools or similar.

[POBEP]

Originally Posted by AstroZ

That is very interesting - can you post a few pics of the device(s) you used and links to where you got them from?

so it could be a firmware issue with the adapter. The sata -> ide chlp must read some data from the SSD to present it as an IDE drive (this is why the drive appears as a "samsung" when connected to a machine, and the size appears right).

The mSATA is Micron M500iT (industrial grade).
Got it in a sealed bag here

The IDE-2-mSATA is ableconn, bough 3 of them here
Both purchased Apr-2020 worked without any issue

The one I got Apr-2021 worked well in old Dell laptop, but did not worked in the BMW CIC unit, see pictures below

[AstroZ]

Originally Posted by POBEP

The mSATA is Micron M500iT (industrial grade).
Got it in a sealed bag here

The IDE-2-mSATA is ableconn, bough 3 of them here
Both purchased Apr-2020 worked without any issue

The one I got Apr-2021 worked well in old Dell laptop, but did not worked in the BMW CIC unit, see pictures below

Thanks for sharing this. if you can, please post images of the Apr-2020 convertor's chip. It may give a clue as to why there is an issue e.g. if the chips are different.

You should also contact the company to see if they can explain why you are having this issue, e.g. maybe there was some change in the manfacturing, firmware, testing?

The contact information is: support@ableconn.com you may be able to return the 2021 convertor as it could be a bad convertor.

[POBEP]

Originally Posted by AstroZ

Thanks for sharing this. if you can, please post images of the Apr-2020 convertor's chip. It may give a clue as to why there is an issue e.g. if the chips are different.

Below images of the working ableconn adapter.
(Now I can take dashboard trim apart in no time )

Originally Posted by AstroZ

You should also contact the company to see if they can explain why you are having this issue, e.g. maybe there was some change in the manufacturing, firmware, testing?

The contact information is: support@ableconn.com you may be able to return the 2021 convertor as it could be a bad convertor.

I'll write them a note. The non-compatible unit is on its way back to Amazon

[StevenN]

Thanks AstroZ. Very informative and useful.

Originally Posted by AstroZ

Remember, there are several issues at play here:
1) It could be that the SSD assumes TRIM is enabled on the OS but QNX does not support TRIM (likely). maybe the SSD cannot work without TRIM support in the OS.
2) It could be that TRIM is enabled on the SSD but the SSD does not have time to complete the zeroing operations e.g. when the car is off.
3) It could be that TRIM commands/low-level erase information never reaches the SSD because of the SATA->IDE controller.
4) it could be that after a long period of use without TRIM the time for writes becomes too long due to fragementation, and casues issues.
5) something else (e.g. SSD/flash memory health?)
.

On looking into this in greater details, especially around the, "Trim" Function, it seems that QNX4 Does NOT support the Trim Support. Without the, "Trim" support, the SSD will simply get filled, there is no means for the OS to actively delete data, this then leads to a noticiable slowdown in the performance, (Something I did notice after I put the re-cloned MSATA back in, performance much improved) and eventualy the system not working properly.

I think that as your rightly say, there is not much data written to the SSD, then the SSD may prove an adequate solution, provided data is limited as much as possible to the SSD, also, with map updates, probably best to the original HDD, then recloned back to the SSD to limit the data stored.

I found this post on this issue with QNX4 and the problem with SSD's:

https://community.qnx.com/sf/discuss...ost_post116949

It seems, that the only reasonable solution is that in another year or so, experience the same problems and have to dismantle the car again. However, I can't go dismantling the car every year!

So, it seems that the QNX is only suitable for HDD's which is why it's still used in later BMW's. Therefore, the better solution would be to update the original HDD Toshiba 8050 GAC @ 4,200 RPM (Which are impossible to find new) to the newer version used in the F Series cars but spin at 5,200 RPM. Quicker access and suitable for the QNX. This is one I found on Ebay

https://www.ebay.co.uk/itm/BMW-CIC-S...iABEgLzL_D_BwE

If this proves quicker than the previous HDD drive, 5,400 RPM Vs 4,200 (28% quicker) then it may prove the longer term solution. If or not this drive is Automotive grade is difficult to determine.

Thanks

[AstroZ]

Originally Posted by POBEP

Below images of the working ableconn adapter.
(Now I can take dashboard trim apart in no time )

I'll write them a note. The non-compatible unit is on its way back to Amazon

cool- let us know. wha they say. The mask/revisons on the chips is clearly different. I wonder if they made a change that broke things.

One thing to try, if you get the same adapter again is to simply transfer the SSD over and see if it works in the new unit. As you say you have the experience ripping the dash open

Originally Posted by StevenN

I found this post on this issue with QNX4 and the problem with SSD's:

Good find!

the interesting thing on that page is the link to the QNX knowlegebase. http://www.qnx.com/support/knowledge...0114000000N4mM it says

QNX 6 does support SSD's properly.

The CIC uses QNX 6.3.2 so according to that page it should be supported. However as the CIC expected a HDD so QNX may not be configured to properly use the SSD. I assume that trim is disabled.

The interesting thing is the partition type on the CIC is QNX4 but the file system itself is formated to QNX 6. Maybe this is forcing the drive to use QNX4 file system features, and so not use TRIM (?). QNX 4 is more error resilent than QNX6.

If TRIM is supported by the OS it should be possible to check, and enable it. Let me know if you find a command to way to check/enable TRIM on QNX6. I can create a script.

Originally Posted by StevenN

Quicker access and suitable for the QNX. This is one I found on Ebay

https://www.ebay.co.uk/itm/BMW-CIC-S...-/265023971867

If this proves quicker than the previous HDD drive, 5,400 RPM Vs 4,200 (28% quicker) then it may prove the longer term solution. If or not this drive is Automotive grade is difficult to determine.

Interesting but - I would not go back to HDD after SDD... especially with the used HDD may not be in good condition. The rule of thumb used to be never buy a used HDD...

[StevenN]

Originally Posted by AstroZ

Interesting but - I would not go back to HDD after SDD... especially with the used HDD may not be in good condition. The rule of thumb used to be never buy a used HDD...

Completely true, I used that one as this quickest example I could find, they are new on Amazon for £45.00. I have ordered this today, and will clone that. When the SSD fails/fills up, I will try the cloned HDD.

https://www.amazon.co.uk/gp/product/...?ie=UTF8&psc=1

The priority really is in having the original HDD Backed up, and a replacement ready for when it fails. Now I just want to cease dismantling my car each year.

[AstroZ]

Ok after a quick google, I found:

https://developer.blackberry.com/nat...s-qnx6.so.html

trim=disable|enable|discard
Disable or enable support for TRIM, or use discard instead.

A managed NAND block device can't overwrite in-place and has no idea of whether content in a block is even valid or meaningful to a mounted filesystem. So the management layers have no choice but to preserve all written content, which can be a lot of wear-levelling overhead if in fact those blocks belonged to say a deleted file, or if the partition was freshly formatted.

The TRIM command is thus a hint to the managed NAND device from the filesytem that certain sectors are no longer live and can be discarded (i.e., the content doesn't have to be preserved or copied by wear-levelling, and/or logical blocks can be erased rather than be reclaimed from elsewhere).

Using the discard option gives better performance than enabling trim. When the filesystem tells the driver to discard a set of blocks, the driver simply marks them as discarded and returns, queuing them up for garbage collection later. If the filesystem requests the driver to trim a set of blocks, they're cleaned immediately, which may result in heavy disk I/O, depending on the current state of the system. In the end they do the same thing, just with different timing.

on the CIC we can see in /etc/fstab the QNX6 file system is not mounted with TRIM:

...
# CIC-High fstab
/dev/hd0t77    /mnt/hbnavi  qnx6 ro      
/dev/hd0t77.1  /mnt/hbcddb  qnx6 ro
/dev/hd0t77.2  /mnt/hbdata  qnx6 ro
/dev/hd0t77.3  /mnt/hbuser  qnx6 rw
/dev/hd0t77.4  /mnt/hbmedia qnx6 rw
/dev/hd0t77.5  /mnt/hbdebug qnx6 rw
...

Probably we need enabled or discard.

only .3-.5 need TRIM as these are the only rw. I guess the reason for slow down/hdd fill up is /mnt/hbdebug (and hbmedia, hbuser) has small amounts of debug data written to it fairly regularly.

I'd have confirm the theory. I think updating the map a couple of times, adding removing music collections should eventually trigger the issue, if we are correct.

Once confirmed, we would need to change the file to:

...
# CIC-High fstab
/dev/hd0t77    /mnt/hbnavi  qnx6 ro      
/dev/hd0t77.1  /mnt/hbcddb  qnx6 ro
/dev/hd0t77.2  /mnt/hbdata  qnx6 ro
/dev/hd0t77.3  /mnt/hbuser  qnx6 rw trim=enable 
/dev/hd0t77.4  /mnt/hbmedia qnx6 rw trim=enable 
/dev/hd0t77.5  /mnt/hbdebug qnx6 rw trim=enable 
...

(n.b. untested)

[StevenN]

Originally Posted by AstroZ

Ok after a quick google, I found:

...
# CIC-High fstab
/dev/hd0t77    /mnt/hbnavi  qnx6 ro      
/dev/hd0t77.1  /mnt/hbcddb  qnx6 ro
/dev/hd0t77.2  /mnt/hbdata  qnx6 ro
/dev/hd0t77.3  /mnt/hbuser  qnx6 rw trim=enable 
/dev/hd0t77.4  /mnt/hbmedia qnx6 rw trim=enable 
/dev/hd0t77.5  /mnt/hbdebug qnx6 rw trim=enable 
...

So that will mount or create the new file system on the SSD, which is all good, as now the filesystem has been created to be readable by QNX6 with the, "Trim" commands neeed for SSD's.

But, when we put the original data back, using the cloning method, this will overwrite the newly created file system with the old system.

Probably the easiest method is too simply import a number of files into the Music Collection, delete the entire music collection, and import again. If this assumption about not deleting is correct, then the music collection should be either un-readable or inaccessable.

The issue presents itself, by showing the music collection, then refusing to play, or trying to import, the import completely fails. Also, becuase when you slot a CD in, it asks if you want to copy this to the car. I found that once the music collection was inaccesible, then so the CD also failed to work. Probably becuase that too is unable to write to the HDD

At the moment, I know very little about QNX, and have not made a mountable media to fully play with it, this I will look at doing next.

[AstroZ]

also found:

http://www.qnx.com/developers/docs/q...ilesystem.html

The Power-Safe filesystem is a reliable disk filesystem that can withstand power failures without losing or corrupting data. It was designed for and is intended for traditional rotating hard disk drive media.

This filesystem is supported by the fs-qnx6.so shared object.

To address the problems associated with existing disk filesystems, the Power-Safe filesystem never overwrites live data; it does all updates using copy-on-write (COW), assembling a new view of the filesystem in unused blocks on the disk. The new view of the filesystem becomes "live" only when all the updates are safely written on the disk. Everything is COW: both metadata and user data are protected.

and from my previous link:

The Power-Safe filesystem was designed for and is intended for traditional rotating hard disk drive media. It operates by moving the on-disk filesystem state from one stable view to another stable view using copy-on-write (COW) to relocate modified blocks. To finalize this transition, all dirty blocks involved in the new view must be committed to persistent storage, and then a new filesystem superblock/root referencing the relocated blocks is committed.

This provides power-safe robustness, because at any point in time either the old version is completely accessible or the new version is completely accessible (with no live data being overwritten in between). Thus to mount as read-write on a given device, that device must have the following properties:

one of the following:
The device may buffer write data for performance reasons, and the return from a WRITE may not necessarily indicate the data is committed to permanent storage. But such a device must implement a FLUSH/SYNC command that forces any cached or buffered write data to persistent storage, and doesn't return until it's guaranteed that all data is stable across a power-loss.

or:
The device doesn't buffer write data, and operates in a strict write-through manner, where return from a WRITE is a guarantee that the data was immediately committed to persistent storage. Such a device doesn't require an additional FLUSH/SYNC command.
and both of the following:
The action of writing to one data region (an advertised device sector) can in no way damage the contents of any other region, even under conditions such as power-loss, vibration, temperature, etc.

and:
Data that has previously been reported as committed to persistent storage remains stable until explicitly overwritten. The device may implement facilities such as bad-block remapping or wear-leveling to support this requirement, provided that such activity never causes loss of persistent data, even under conditions such as power-loss, etc.

I'm not sure if the SSD drives we use can make these guarantees.

there are some other interesting options in the qnx driver though for aligned IO and block optimisation.

[AstroZ]

Originally Posted by StevenN

So that will mount or create the new file system on the SSD, which is all good, as now the filesystem has been created to be readable by QNX6 with the, "Trim" commands neeed for SSD's.

But, when we put the original data back, using the cloning method, this will overwrite the newly created file system with the old system.

as long as the trim option is used to mount the SDD, SSD drive should maintain good order of data.

the option just tells the driver to use TRIM commands on delete. It should have no effect on the HDD.

Originally Posted by StevenN

Probably the easiest method is too simply import a number of files into the Music Collection, delete the entire music collection, and import again. If this assumption about not deleting is correct, then the music collection should be either un-readable or inaccessable.

it would be great if you come up with a set of steps for reproducability. I'm not sure that large transfers (multi mb mp3 files etc) would trigger the issue. it has to be lots of little writes and deletes - each file less than SDD block size.

give it a go and report back

[opjose]

Mounting the drive with the trim option only applies to your local Qnix installation.

Once that drive is mounted in the CIC those commands have no effect as they would need to be part of the operating system of the CIC itself, when mounting the SSD.

Likewise the posts about the other characteristics are also not applicable.

The CIC OS deals with the drives the way it has been set up to do, and that is all in the read only firmware operating system installed on the CIC.

[StevenN]

Originally Posted by opjose

Mounting the drive with the trim option only applies to your local Qnix installation.

Once that drive is mounted in the CIC those commands have no effect as they would need to be part of the operating system of the CIC itself, when mounting the SSD.

Likewise the posts about the other characteristics are also not applicable.

The CIC OS deals with the drives the way it has been set up to do, and that is all in the read only firmware operating system installed on the CIC.

Yes, this all makes sense.

So, quite simply, changing the original HDD to a SSD WILL lead eventually the SSD not working properly and the CIC unit not functioning correctly.

Dependent upon time and number of reads, will only determine when the time comes to ether re-write the SSD / think the SSD has become corrupted or broken / re-install the original HDD or try and find another solution.

Update

On looking at other sites, I found this post on the, "French Car Forum". This post relates to the exact same problems being experienced with SSD's being used by the QNX:

https://frenchcarforum.co.uk/forum/v...ic.php?t=57430

This post goes on to explain the option to use is, "Compact Flash". Compact Flash is 100% compatible with an older PATA Interface, and behaves like a True IDE device. Also explained here:

https://www.delkin.com/blog/technica...ital-sd-cards/

It seems that only the higher end CF cards support Trim, which is fine, we don't need or want Trim supporting.

I am going to get these two items off Amazon, and see how this works out:

https://www.amazon.co.uk/gp/product/...11KBU0XI&psc=1

https://www.amazon.co.uk/gp/product/...KL5A1OLE&psc=1

[opjose]

There is no reason for the SSD to fail prematurely.

Modern SSD built in controllers take care of wear leveling automatically.

Mine has been in service for five years without a single issue too though I purchased the PATA SSD mentioned originally.

I have a copy of the original image just in case.

I expected extreme temps to be the bigger problem but so far that has not been true.

[AstroZ]

Originally Posted by opjose

Mounting the drive with the trim option only applies to your local Qnix installation.

Once that drive is mounted in the CIC those commands have no effect as they would need to be part of the operating system of the CIC itself, when mounting the SSD.

Likewise the posts about the other characteristics are also not applicable.

The CIC OS deals with the drives the way it has been set up to do, and that is all in the read only firmware operating system installed on the CIC.

actually I'm trying this on the CIC via telnet:

target:/> uname -a                                          
QNX front 6.3.2 2009/10/30-15:33:18EDT HB_SH7785 shle

target:/> mount -u -T qnx6 -o trim=enabled,rw /dev/hd0t77.3 
mount: Can't remount /dev/hd0t77.3 (type qnx6) 
mount: Possible reason: Invalid argument

Sadly TRIM is not supported in the 6.3.2 qnx6 driver, as posted it the link by @StevenN . I won't play with this too much more, but I'm sure if it was supported I could make the mount changes persistent.

@StevenN - good find, I think CF to IDE seems to be a very good option. Keep us updated.

BTW I also found out why the drive will get filled up (except for MP3s), even though we assumed low recreation of files. the file /mnt/hbdebug/core/CicHighEceUsaSecond.ass is written quite often as are *.scl files in /mnt/hbuser/textenrolements .

[opjose]

Don't know how the changes could have been made persistent.

As the CIC boots up from Flash it loads the mount tables.

Even if you made the change in ram, the next time your start the car or reboot the CIC it would be undone.

The HDD stores everything that gets modified, and that is not available until it is mounted.

AFAIK the OS images are not raw data dumps and could be encrypted.

[AstroZ]

Originally Posted by opjose

Don't know how the changes could have been made persistent.

As the CIC boots up from Flash it loads the mount tables.

Even if you made the change in ram, the next time your start the car or reboot the CIC it would be undone.

The HDD stores everything that gets modified, and that is not available until it is mounted.

AFAIK the OS images are not raw data dumps and could be encrypted.

Ok! thanks for the input.

[Leucosticte]

Originally Posted by AstroZ

All looks ok. How was the img file made? It seems like your mbr may have been corrupted. The partitions are not showing. Post the results of

sfdisk -d /dev/sdc

fdisk -l /dev/sdc

So it turns out the IDE to USB adapter I was using was a cheap pos, I got another one and it cloned perfectly and works in my cic now. Thanks for the help!

[Brownpower]

So im using QNX RTOS 6.2.1, is this going to work?

right now trying to mount the FS i get the following error:

Cant mount / (type qnx6)
possible reason: Cant access shared Library

[Jagaer]

StevenN Funny you mention the CF Adapter.

I recently got rear-ended, so decided to a bit of an upgrade once I get it back from the body shop.



I bought a CF-to-IDE adapter, and a 128GB memory card to try out in the system. (Not because of TRIM issues, but because it appears that the SSD's *really* don't like to work correctly at -30 to -40C)




I also wanted to join the next decade with Android Auto/Apple Carplay, so bought a Korean Adapter from Indiwork: https://indiworkshop.com/shop/carpla...c-for-bmw-cic/






I'll post updated info or guides, depending on how they work, since they're currently sitting in boxes waiting for my car to return.

[AstroZ]

Originally Posted by Jagaer

StevenN Funny you mention the CF Adapter.

I recently got rear-ended, so decided to a bit of an upgrade once I get it back from the body shop.

I bought a CF-to-IDE adapter, and a 128GB memory card to try out in the system. (Not because of TRIM issues, but because it appears that the SSD's *really* don't like to work correctly at -30 to -40C)

I also wanted to join the next decade with Android Auto/Apple Carplay, so bought a Korean Adapter from Indiwork: https://indiworkshop.com/shop/carpla...c-for-bmw-cic/

I'll post updated info or guides, depending on how they work, since they're currently sitting in boxes waiting for my car to return.

Hello!

Sorry to hear about the car getting rear ended. Hopefully insurance sorts it out.

Look forward to seeing your results with the CF adaptor to IDE. In the UK the msata to ide adaptor is getting harder to find and there was a report of one of the latest versions of the chip on the IDE/MSATA board maybe not working.

As for the Carplay box, check out the following thread:
https://f30.bimmerpost.com/forums/sh....php?t=1675929

The box you got looks very similar, prob based on the same board. I assume you will be able to use the upgraded/modded firmwares from that thread. I doubt you'll use the CIC much at all after that...

One of my other cars has netflix, spotify, youtube, OTA updates... but still no carplay support (and no VIM). I find myself driving the e93 more often when the weather is nice, though.

[nsjames]

Originally Posted by Jagaer

StevenN Funny you mention the CF Adapter.

I recently got rear-ended, so decided to a bit of an upgrade once I get it back from the body shop.



I bought a CF-to-IDE adapter, and a 128GB memory card to try out in the system. (Not because of TRIM issues, but because it appears that the SSD's *really* don't like to work correctly at -30 to -40C)



I also wanted to join the next decade with Android Auto/Apple Carplay, so bought a Korean Adapter from Indiwork: https://indiworkshop.com/shop/carpla...c-for-bmw-cic/


I'll post updated info or guides, depending on how they work, since they're currently sitting in boxes waiting for my car to return.

I'm interested in how all of this plays out.

I've put my factory HDD back in the unit. after a year of use the kingston SSD was flaky, and absolutely refused to do a map update, even after I reimaged it and tried again.
I installed the original drive and it completed first go without issue.

To those that bought the micron deal from ebay, still working?

I'm not terribly concerned about drive failure as I have a good working image saved, but I did like the SSD performance when zooming the map and such.
I just went back to a 128GB flash drive in the center console for music. It's more convenient to pop out and add new music to it anyhow.