Audi A5 Forum & Audi S5 Forum banner
281 - 300 of 315 Posts

· Registered
A5 2,7 TDI 2009
Joined
·
13 Posts
@DrGER : First time (since your post #273) I think I forget to put the file in "var" folder. Second time, I think the file was in the "var" folder but the name was wrong (missing the "....new.txt").. Third time everything were ok but just noticed that the file you gave me in post #273 miss a letter "e" :
Rectangle Font Screenshot Number Parallel

I corrected the name file to "mmelauncher.cfg.new.txt", started the script and then reboot the MMI
:) :) :) :) :) :)
It is ok now !!!!!!

@DrGER thanks a lot for your help and your time ! <3
@JulianHicks thanks foryour mmelauncher.cfg <3

I will try tonight when I leave the office. I hope it will still work :)
 

· Registered
Joined
·
3 Posts
Hello, please help me.

I've tried the update on a 3G High Nav but it doesn't activate and now I don't have SD card or AMI.
I tried to delete all partition, tried the script MMI 3G High activation failed, now missing jukebox + SD
but it doesn't work.

Do you know how to fix this ? How can I force an update firmware to reset the status ? What is the module name of the MMI to force the update
 

· Registered
Joined
·
27 Posts
@patroclox : The problem here isn't in the GEM, since we know that nav is enabled in your MMI 3GH system. The problem is getting one of the available 3GH "activator" SD scripts to run on your system when you see the "nav data is blocked" message. Unless something in the SD card file system is causing your MMI system to ignore the SD card (for example, a "hidden" directory/folder in the root directory/folder), I don't understand why these SD scripts do not run for you.

Yes, you can "work around" the QNX system patch with my mmi3ginfo2 SD script as starting point. In your case, I would create the correct mmelauncher.cfg and mme-becker.sh files separately (as UNIX files) and install them from an SD card using a simple script:
Code:
mount -uw /mnt/efs-system
cp -v $SDVAR/mme-becker.sh  /mnt/efs-system/sbin/mme-becker.sh
chmod -v 0755 /mnt/efs-system/sbin/mme-becker.sh
mv -v /mnt/efs-system/etc/mmelauncher.cfg  /mnt/efs-system/etc/mmelauncher.cfg.pre-navdb.bak
cp -v $SDVAR/mmelauncher.cfg  /mnt/efs-system/etc/mmelauncher.cfg
chmod -v 0644 /mnt/efs-system/etc/mmelauncher.cfg
Sorry DrGER, until now I haven't had time to do the test, I was going to do it right now, but I realized that you are proposing to copy the files mmelauncher.cfg and mme-becker.sh from the SD card to my system (cp - v source target), but I don't have those files, could you tell me where I can get them.

Thank you for everything, and sorry for so long without contacting you.
 

· Registered
Joined
·
8 Posts
I am just about to take the plunge and update the firmware and ultimately the maps in my 2012 Q5 HNav which is on the original mapping P0206_D1 and ECE 5.13.8. I have read many many posts on the topic but have just one question remaining about the activation. The activator bundled with the 6.35.1 maps has an extra couple of files compared to the activator that was included with the 6.32.1 maps. The extra files are mme-becker.ssh and mmelauncher.cfg. Does this make any difference? Which should I use?
 

· Registered
Joined
·
8 Posts
After some more reading it looks like I can answer my own question above to some extent. I don't think there is any fundamental difference beyond the fact that some run.sh scripts create the new mme-becker and mmelauncher files within the script whereas other activators have the two new files separately on the SD card to be copied over.

To date I have got the firmware up to the latest and also installed the 6.35.1 maps. However, interestingly I am now up against exactly the same problem that @patroclox seems to be having in that I just cannot get the activator script to start. I've used @DrGER mmi3ginfo2 script which runs beautifully and seems to result in a correct log file so I know there is nothing wrong with my SD card slot in the mmi or the ability of the mmi to read and start a script on an SD card. It's really quite odd how we are both having similar problems (and possibly @biomanrose was too). I've tried a number of different SD card (none of which are micro) and always used FAT32. I've also checked there are no hidden files. The only thing I haven't had a chance to do yet is try a Linux PC. Any other thoughts? Could I just use the run.sh script in mmi3ginfo and copy the two files in the same way @biomanrose did? Seems very odd that the mmi3ginfo script will run but none of the activators.
 

· Registered
2014 A4Q/8K 6MT MMI 3G+
Joined
·
586 Posts
@Keith-i : I've been taking a closer look at some of the start-up processes in our QNX systems recently, which got me to thinking about the so-called "activator" scripts that patch (hack?) the system to terminate process vdev-logvolmgr after it creates file /lvm/acios_db.ini at system start up. The current method is to piggy-back on the launch of mme-becker from the mmelauncher process by launching shell script mme-becker.sh, instead (as defined in the mmelauncher.cfg file) and include the background sub-shell commands (waitfor /lvm/acios_db.ini 180 && sleep 10 && slay vdev-logvolmgr) in the new shell script before it starts the actual mme-becker QNX binary. I think I determined why whoever discovered the magic to unblocking nav database access (possibly Keldo in 2014/15?) put the sub-shell stuff here (answer: someone else was already using mme-becker.sh to start the DHCP client on device uap0 for internet tethering on the WiFi device, but that's a different story).

I think the shell bits that terminate the vdev-logvolmgr process can go anywhere early enough in the start up process. Inspection of the system log (from sloginfo) on our 3G+ system show the vdev-logvolmgr process starting about 165 seconds into the boot process, followed by its termination (from signal 15) 10 seconds later. The trick, then, is to identify shell scripts launched by the QNX system services process (srv-starter-QNX) that are equivalent on both 3G High & 3G Plus systems, and replace that script with a new script that includes our nav database unblocking code just before it exits:
Code:
(waitfor /lvm/acios_db.ini 180 && sleep 10 && slay vdev-logvolmgr) &
I see that /mnt/efs-system/usr/bin/manage_cd.sh appears on both systems; its 3G High startup config is:
Code:
    <Process>
      <Number>37</Number>
      <Name>/usr/bin/manage_cd.sh</Name>
      <Args/>
      <ResArgs/>
      <Prio>10</Prio>
      <StartParam>BACKGROUND</StartParam>
      <OnTerminate>KEEP_INTERFACE</OnTerminate>
      <Shutdown>IGNORE</Shutdown>
      <ProvidesInterface>50</ProvidesInterface>
      <RequiresInterface>3</RequiresInterface>
      <RequiresInterface>4</RequiresInterface>
      <RequiresEnvironment/>
    </Process>
and on 3G Plus systems:
Code:
    <Process>
      <Number>37</Number>
      <Name>/usr/bin/manage_cd.sh</Name>
      <Args/>
      <ResArgs/>
      <Prio>10</Prio>
      <Partition>System</Partition>
      <StartParam>BACKGROUND</StartParam>
      <OnTerminate>IGNORE_ALL</OnTerminate>
      <Shutdown>IGNORE</Shutdown>
      <KeepInterface>true</KeepInterface>
      <MaxProcessRestarts>0</MaxProcessRestarts>
      <FinalAction>IGNORE</FinalAction>
      <VariantCode>-1</VariantCode>
      <VariantMask>-1</VariantMask>
      <ProvidesInterface>45</ProvidesInterface>
      <RequiresInterface>3</RequiresInterface>
      <RequiresInterface>19</RequiresInterface>
      <RequiresEnvironment/>
    </Process>
I think the differences between the two are minor -- the result is the same in both cases; it's worth taking a look at putting the nav database "unblocker" here, instead of burying it inside of a bogus mme-becker.sh script.
I don't have access to a 3G High system here (I managed to extract the ifs-root.ifs file of the NAR 3G High software update to examine the mmi3g-srv-starter.cfg file); it would be useful to confirm that the manage_cd.sh script is the same (or mostly) on the two systems to simplify installation of a practical work-around to the "blocked nav datatbase" problem. I plan to have a go at this on our 3G+ system in the next few days and report back.
But to answer your immediate question, you could rework the mmi3ginfo run.sh script to install the mme-becker.sh and mmelauncher.cfg files directly; something like this:
Code:
mount -uw /mnt/efs-system
cp -v ${SDVAR}/mme-becker.sh /mnt/efs-system/sbin/mme-becker.sh
mv -v /mnt/efs-system/etc/mmelauncher.cfg /mnt/efs-system/etc/mmelauncher.cfg-ORIG
cp -v ${SDVAR}/mmelauncher.cfg /mnt/efs-system/etc/mmelauncher.cfg
ls -o /mnt/efs-system/sbin/
ls -o /mnt/efs-system/etc/
Copy the mm-becker.sh and mmelauncher.cfg files to the var folder of the SD card, and inspect the log files for error messages before restarting your MMI system. --g
 

· Registered
Joined
·
8 Posts
@DrGER thanks for taking the time to reply. Your understanding of our systems is invaluable and also fascinating. If I can help in any way by copying files from my European 3G High unit for you then please let me know. I have a bit of very basic experience with unix/linux so understand some of the concepts but not neccesarily how to write the code.

Meantime I will put your bit of code into the run.sh file on the mmi3ginfo script to get my system activated as I can see it is always reversible. I'm curious to know what the official Audi unlock process is. Some information seems to suggest it is an SD card whereas others say SVM..
 

· Registered
2014 A4Q/8K 6MT MMI 3G+
Joined
·
586 Posts
@Keith-i : For an SD card script to run, a sequence of events needs to complete successfully, starting with the QNX system catching the card insertion event, followed by finding and mounting the FAT32 filesystem, then finding, decoding/decrypting, and executing the copie_src.sh script, as detailed in the QNX syslog:
Code:
00:07:17    6 20002   2206 ==> CardDetect Interrupt
00:07:17    6 20002   2206 == monitor thread: got 0x7f
00:07:17    7 20002   2206 sdcInitHw: ctrl:1 stat:514 ien:0 flag:140000 ifcs:0
00:07:17    4 20002   2206 sdcSetFreq: SDC clock: 200000Hz
00:07:17    5 20002   2206 sdcIdentification: Ver 2.00 comliant SDC detected: try to initialize...
00:07:17    5 20002   2206 Card's       Supply Range: 2.70 V ... 3.60 V
00:07:17    5 20002   2206 sdcIdentification: SDC is not a HC card.
00:07:17    5 20002   2206 sdcGetGeom: capacity = 1967128576Byte (1921024 * 1024Byte)
00:07:17    5 20002   2206 sdcGetSpeed: Card speed is: 25000000
00:07:17    4 20002   2206 sdcSetFreq: SDC clock: 22000000Hz
00:07:17    5 20002   2206 sdcGetTimeouts: TAAC=2.0*1ms=2000000.000000ns NSAC=0=0.000000ns R2W_FACTOR=32
00:07:17    5 20002   2206 sdcGetTimeouts: timeouts set: rd:160ms wr:4080ms
00:07:17    5 20002   2206 == driver thread starting ...
00:07:17    5 20002   2206 DMA channel 258 used
00:07:17    5 20002   2206 == driver thread: entering handler loop ...
00:07:17    5 20002   2206 devb-sdc-hbfpga: ins:1
00:07:17    5 20002   2206 devb-sdc-hbfpga: type:2 sub_type:441 vid:2 did:544d speed:25000000
00:07:17    5 20002   2206 devb-sdc-hbfpga: product:'SD02G' s/n:ad759b2b
00:07:17    5 20002   2206 devb-sdc-hbfpga: diskname:'sdcard2'
00:07:17    5 20002   2206 devb-sdc-hbfpga: write prot.: false
00:07:17    5 20002   2206 devb-sdc-hbfpga: device not used: false
00:07:17    2     5   100 cam-disk.so (Sep  7 2012 14:44:35)
00:07:17    6 20002   2206 == monitor thread: done.
00:07:18    3    23     0 /mnt/sdcard20t12 media inserted
00:07:18    5    23     0 /mnt/sdcard20t12 forcing rule SD_CARD_RIGHT - match
00:07:18    4    23     0 /mnt/sdcard20t12:SD_CARD_RIGHT - client 0:208906
00:07:18    5    23     0 /mnt/sdcard20t12 trying rule SW_UPDATE - fail
00:07:18    5    23     0 /mnt/sdcard20t12 forcing rule NOT_SW_UPDATE - match
00:07:18    4    23     0 /mnt/sdcard20t12:NOT_SW_UPDATE - client 0:208906
00:07:18    5    23     0 /mnt/sdcard20t12 trying rule BOARD_BOOK - fail
00:07:18    5    23     0 /mnt/sdcard20t12 forcing rule NOT_BOARD_BOOK - match
00:07:18    4    23     0 /mnt/sdcard20t12:NOT_BOARD_BOOK - client 0:208906
00:07:18    5    23     0 /mnt/sdcard20t12 trying rule NAVI_UPDATE - fail
00:07:18    5    23     0 /mnt/sdcard20t12 forcing rule NOT_NAVI_UPDATE - match
00:07:18    4    23     0 /mnt/sdcard20t12:NOT_NAVI_UPDATE - client 0:208906
00:07:18    5 20002   2206 sdc_dsn: 02-544D-SD02G-48-AD759B2B
00:07:22    5 20001     0 proc_scriptlauncher: ATTACH: [ADD_SDC_MSD_/mnt/sdcard20t12]
00:07:22    5 20001     0 proc_scriptlauncher: In Funktion script_decoder
00:07:22    5 20001     0 proc_scriptlauncher: Das Anlegen der Scriptdatein in diesem Verzeichnis /dev/shmem/copie_scr.sh war erfolgreich
00:07:22    5 20001     0 proc_scriptlauncher: Beginne mit decodieren
Note in this case five (5) seconds elapse after the card is inserted and the copie_scr.sh script is decoded. I've learned that if an SD script doesn't run within 10 seconds or so, remove the card, count to 10 slowly, and re-insert. I generally keep a (blank) 2GB card in slot 1 to capture log files & screen shots, so scripts and software updates use slot 2 (/mnt/sdcard20t12).
As you have time, can you run a simple SD script to copy the manage_cd.sh file from your 3G High system:
Code:
cp -v /mnt/efs-system/usr/bin/manage_cd.sh ${SDVAR}/
and share the file (or its contents) here ? --g
 

· Registered
Joined
·
8 Posts
@DrGER I've run the cp script and below is the contents of manage_cd.sh

Code:
#!/bin/ksh

for i in 1 2 3 4
do
   mount -t cd -r /dev/cd0 /fs/cd0
   mount_ret=$?
   if test $mount_ret -eq 0; then
      touch /dev/shmem/CD0_STARTED
      echo cd0 mounted after $i try
      break
   fi
done

if test $mount_ret -ne 0; then echo cd0 mount failed!; fi

# the mount loop is required as a temporary workaround to an io-blk race
# condition (QNX PR/55354)
I was expecting something bigger for some reason but hope it is of use to you. Strangely after the script ended and it asked me to press any key and eject the SD card the MMI screen went a bit odd and had the nav route selection screen superimposed over the map. A reboot seems to have fixed it though.

Out of interest, what is the code or mechanism that you use to capture logs to SD1? Also, does it by default send screenshots to SD1 or is that user controllable.
 

· Registered
2014 A4Q/8K 6MT MMI 3G+
Joined
·
586 Posts
@Keith-i : Many thanks for that -- this confirms that script manage_cd.sh is the same on both High & Plus systems.
Re the odd screen behavior after running an SD script, you can disregard this and select [MENU] (or whatever the 3G High equivalent is) to reset the display. I've also noticed that the display generally resets to the last display function just prior to running the script, so I switch to [CAR] for a moment, then back to [MENU] before running a new script. Should be no need to reboot the system (I hope).

Screenshots are always sent to SD 1 as PNG files with the current date/time stamp in the filename -- I believe this is not selectable.
I've made changes to the scripts called by the Green Engineering Menu [GEM] /googleearth screen for copying certain log files to SD 1. 3G High systems don't have Google Earth functions, but other shell scripts are available in /mnt/efs-system/scripts to do similar, for example, listDBInfo.sh might be launched by /nav/databaseupdate > [List HDD Database info] in the GEM:
Green Rectangle Terrestrial plant Font Screenshot

I expect your 3G High system should have an equivalent GEM screen. --g
 

· Registered
Joined
·
8 Posts
@DrGER success with the activation using your mmi3ginfo2 script with the launcher and becker files in the VAR folder. All seems to have gone smoothly and so far no 'navigation blocked' message.

Is there any logic you know of to the advice frequently found on the forums not to install the activation until the blocked message appears? I can't see what difference this makes as far as copying 2 new files onto the system.

Re the odd screen behavior after running an SD script, you can disregard this and select [MENU] (or whatever the 3G High equivalent is) to reset the display
Interestingly none of the buttons seemed to respond when the display went funky, hence why I did a reboot.

Thanks again for your help.

And for anyone else doing this, I found I needed to do the SVM adaptation channel 15 process twice to clear the 03276 fault code.
 

· Registered
2014 A4Q/8K 6MT MMI 3G+
Joined
·
586 Posts
@Keith-i : That's good news.

I think the guidance regarding when to run the "activator" script (i.e., not until the "blocked" message appears) is to keep end-users from running the script again, unnecessarily, if the system is already "patched". My recollection is that the 3rd party unblocker scripts still try to do things if they find evidence that the system is patched already (rather than just exiting early with a note why).

That's odd about your system becoming unresponsive (except to restart) after running the script that copied the manage_cd.sh file to the SD card. Hmmm. Still, all's well that ends well. Cheers --g

Update 16 Dec 2022:
For the record, moving the nav database unblocking code from the (unnecessary) mme-becker.sh script to /usr/bin/manage_cd.sh works perfectly on our 3G+ system, and is cleaner, IMO:
Code:
#!/bin/ksh
for i in 1 2 3 4
do
   mount -t udf -r -o format=udf:joliet:iso9660e:iso9660:audio,case=asis /dev/cd0 /fs/cd0
   mount_ret=$?
   if test $mount_ret -eq 0; then
      touch /dev/shmem/CD0_STARTED
      echo cd0 mounted after $i try
      break
   fi
done
if test $mount_ret -ne 0; then echo cd0 mount failed!; fi
/usr/apps/bench/TimeLogger "Starting MMI3G NAVDB Unblocker patch"
(waitfor /mnt/lvm/acios_db.ini 180 && sleep 10 && slay vdev-logvolmgr) &
If @patroclox still has blocked nav data, this solution may work for him. --g
 

· Registered
Joined
·
3 Posts
@DrGER : Thank you for the awsome work on figuring out the mechanism of the map activation and sharing your insights with us.
I am familar with shell scripts as I work a lot with Raspberry PI and read your posts at least twice to understand the whole process of updating and activation. I have a 3G high and as I understand your activation method will also work for my system. The only thing I don't understand is the process of the TimeLogger
/usr/apps/bench/TimeLogger "Starting MMI3G NAVDB Unblocker patch"
Is this realy necessary or "just" adding the quoted string to some logging file? For what is the "Timelogger" used regularly?
 

· Registered
2014 A4Q/8K 6MT MMI 3G+
Joined
·
586 Posts
@ware : Thanks for your comments.

Note that I do not call this an "activation" method, as proper activation requires a legal FSC file that is authenticated by both processes vdev-logvolmgr and MMI3GApplication. The technique discovered by Keldo back in 2014/15 essentially unblocks access to the nav database when a proper/legal FSC file is not installed for the nav database release by terminating the vdev-logvolmgr process before the MMI3GApplication process can authenticate acios_db.ini. My contribution (if one can call it that) is to simplify how the unblocker patch is applied to MMI3G High & Plus systems in a consistent manner so the patch script can be used universally. I offered further comments on this over on Audizine: Unblocking Nav Database Access Following Updates on MMI 3G/3G+ Systems

Re TimeLogger, this writes the string argument and a timestamp in milliseconds to the syslog, which is viewed by sloginfo:
Code:
Time             Sev Major Minor Args
Jan 01 00:00:00    6 20000     0 Option -u is active! APS is disabled!
Jan 01 00:00:00    6 20000     0 Service Starter QNX - Process launch manager (version
core 4.2.23)
...
Jan 01 00:00:04    6 20000     0 Interface [02]: 'AVAIL' '/dev/cam0'
Jan 01 00:00:04    6 20000     0 Interface [03]: 'AVAIL' '/dev/cd0'
Jan 01 00:00:04    2 981710     1 Found matching display at index 0 (dcb: 0x01000123) -
matchin index = 0
Jan 01 00:00:04    2 981710     1 Found matching display at index 2 (dcb: 0x04020213) -
matchin index = 1
Jan 01 00:00:04    2 981710     1   allocatedHead   = 1
Jan 01 00:00:04    2 981710     1   statusCode       = 0
Jan 01 00:00:04    2     5   100 cam-disk.so (Sep  7 2012 14:44:35)
Jan 01 00:00:04    6 20000     0 Process[37]: 'POST_STARTING' '/usr/bin/manage_cd.sh'
Jan 01 00:00:04    5     1     1 BENCHMARK: Starting MMI3G NAVDB patch, Timestamp: 4590
Jan 01 00:00:04    6 20000     0 Interface [07]: 'AVAIL' '/dev/hd0t78'
Jan 01 00:00:04    6 20000     0 Interface [05]: 'AVAIL' '/dev/hd0'
Jan 01 00:00:04    6 20000     0 Process[08]: 'RUN' '/usr/bin/devb-eide-hbfpga'
Jan 01 00:00:04    6 20000     0 Package [12]: 'RUN' 'COMMON'
Jan 01 00:00:04    6 20000     0 Interface [45]: 'AVAIL' '/dev/shmem/CD0_STARTED'
Jan 01 00:00:04    6 20000     0 Process[37]: 'RUN' '/usr/bin/manage_cd.sh'
Jan 01 00:00:04    6 20000     0 Package [03]: 'RUN' 'MANAGE_CD'
...
So, not necessary for the unblocker code to work; I find it useful to document the process, as the overhead cost is negligible.
I've seen only one other script use TimeLogger -- in /mnt/efs-system/lsd/lsd.sh, which starts the j9 Java virtual machine process (used to implement the MMI display interface and Green Engineering Menu subsystem). The thing I haven't yet teased out is what QNX construct is applied to make certain flash filesystem files (vdev-logvolmgr, MMI3GApplication, TimeLogger) "invisible" to the shell (so they can't be listed by "ls" or otherwise accessed by the shell) after a system condition is met or a certain amount of time elapses. --g
 

· Registered
Joined
·
3 Posts
@DrGER : YES, you are absolutley right, activation is the wrong wording, it's just bypassing it. Thank you for the confirmation of my thougths belonging to the TimeLogger. I also read your post on Audizine before...
Maybe a small hint to your mmi3ginfo2-v221206, which I used for gathering all system information. I think there is some problem with the {SDBIN} variable, which raised an error in my fist run. By replacing it with {SDPATH}/bin everything run smoothly and I got the MainUnit version.
 

· Registered
2014 A4Q/8K 6MT MMI 3G+
Joined
·
586 Posts
...
Maybe a small hint to your mmi3ginfo2-v221206, which I used for gathering all system information. I think there is some problem with the {SDBIN} variable, which raised an error in my fist run. By replacing it with {SDPATH}/bin everything run smoothly and I got the MainUnit version.
Thanks for your feedback, @ware. My copie_scr.sh script sets some initial shell variables (see my comments about that over here: New and Improved Encoded copie_scr.sh Script ).
It's been about a year since I wrote this, and somehow imagined that I set env var SDBIN, too. But I did prepend it to the PATH env var, so really, it shouldn't be necessary to use the full pathname to call our sed binary saved in the bin dir.

While I'm thinking about it, can you please confirm something for me. On 3GP (HN+) systems, /tmp/sw_trainname.txt contains the software train name of the main unit. 3G (HNav) system don't have this file, but I believe that MMI3GApplication writes it to the syslog, which can be seen with sloginfo.

As you have time, can you run the following SD script segment on your HNav system:
Code:
sloginfo | sed -n 's/^.* +++ Train //p' | sed -n '1p'
I expect this should return one line starting with "HNav..." I'd like to add this to my mmi3ginfo script if we know it returns the correct train name (as reported by the Red Engineering Menu). --g
 
281 - 300 of 315 Posts
Top