When you click on links to various merchants on this site and make a purchase, this can result in this site earning a commission. Affiliate programs and affiliations include, but are not limited to, the eBay Partner Network.
Ah. What you're comparing is the contents of the ifslinks.txt file that dumpifs generates as part of its work. I'm not sure I'd be concerned about that - it's a text file, and isn't something that is flashed to the device; rather it's just reporting symlinks, and if the source/target looks slightly different but the net effect is the same, that's NBD. What you're flashing to the device is the actual filesystem that mkxfs produces, and which dumpifs extracts.
The command I used for creating the patched IFS is
So what you should be comparing is the *contents* of ifs_extracted against an extracted patched_ifs.ifs and *not* the contents of the ifslinks.txt file. You can achieve this with a shell script. Something like the following:
find ifs_extracted -type f | while read a; do b=`echo $a | sed -e 's/ifs_extracted/patched_ifs/'`; cksuma=`cksum $a | awk '{print $1}'`; cksumb=`cksum $b | awk '{print $1}'`; if [ $cksuma != $cksumb ]; then echo $a \($cksuma)\) \<--\> $b \($cksumb\)': NOT OK'; fi; done
If you run this against your ifs_extracted and patched_ifs, you should only see a single file difference this reports as "NOT OK", which is the MIBRoot file. Something like this:
ifs_extracted/usr/apps/MIBRoot (1352948790) <--> ifs_extracted_orig/usr/apps/MIBRoot (1702713611): NOT OK
If that is the case, you have a perfectly valid patched IFS image.
My mkifs_attributes.txt file was the same as yours and as you can see, all it is is a specification of what symbolic links to create:
#Porsche PCM4/MIB2 ifs-root (stage 2) attributes file
[-followlink] #Do not resolve links
[compress=2] #LZO Compression
[-bigendian] #Little Endian (ARMLE)
[-autolink] #Do not auto link shared objects
[perms=777] #chmod 777
[uid=0 gid=0] #chown root:root
#You can add a script to be executed after mount here, one line only
#[+script] .script = {
#touch /dev/shmem/AudioFadedIn; touch /dev/shmem/production_mode
#}
#Symlinks. Add lines here to match your dumpifs symlinks
#[type=link] dest_file=source_file
[type=link] /lib/SPC_configuration.so=/lib/libSPC_configuration.so
[type=link] /lib/AudioConfig_ARM.so=/lib/libAudioConfig_ARM.so
[type=link] /lib/AudioConfig_DSP.so=/lib/libAudioConfig_DSP.so
[type=link] /usr/bin/flashunlock=/usr/bin/flashlock
[type=link] /usr/bin/libi2c-inic-master.so=/lib/libi2c-inic-master.so.1.0
[type=link] /lib/librdshbfpga.so.1.0.0=/lib/librdshbfpga.so
[type=link] /lib/libSysMoCCAFrameworkSharedSo.so=/lib/libSysMoCCAFrameworkSharedSo.so.6
[type=link] /lib/AudioConfig_DSP.so=/lib/libAudioConfig_DSP.so
[type=link] /lib/liba2itodspipc.so=/lib/liba2itodspipc.so.1
In fact that's what I did. I did this command: diff -r ./original/ifs_extracted ./repack/ifs_extracted" files are all different
and all file inside of original/ifs_extracted and repack/ifs_extracted (in which the mibroot has not even been modified) are different as you can see:
for this reason i think that the problem is on mkifs_attribute.
For repack, i did the same your command:
./mkxfs -t ifs -nn -o ./ -r / ./mkifs_attributes.txt ./ifs_extracted ./myIfsRootStage2Original.repack.ifs
I don't know which attribute to modify ... the representation used by Arm is little endian and i read that ifs' compression is LZ0.
The properties of the links don't know which possible links can affect, so I don't touch them.
The owner of the file does not modify it.
The permission properties are not taken by repacked ifs as 777 but as 644.i don't know how to continue to repackage, i am stuck.
thanks
In fact that's what I did. I did this command: diff -r ./original/ifs_extracted ./repack/ifs_extracted" files are all different
and all file inside of original/ifs_extracted and repack/ifs_extracted (in which the mibroot has not even been modified) are different as you can see:
for this reason i think that the problem is on mkifs_attribute.
For repack, i did the same your command:
./mkxfs -t ifs -nn -o ./ -r / ./mkifs_attributes.txt ./ifs_extracted ./myIfsRootStage2Original.repack.ifs
I don't know which attribute to modify ... the representation used by Arm is little endian and i read that ifs' compression is LZ0.
The properties of the links don't know which possible links can affect, so I don't touch them.
The owner of the file does not modify it.
The permission properties are not taken by repacked ifs as 777 but as 644.i don't know how to continue to repackage, i am stuck.
thanks
Hmm, so that really just leaves - I think - mkxfs as the potential culprit. My mkxfs cksum is
4137208885 337176 mkxfs
The other thing I see is that your mkxfs command is *not* the same as mine - in particular, you use "-r /" while I don't.
Last edited by enzotcat; 03-19-2021 at 04:33 PM.
Reason: added a comment
Numerous people have reported day to day life with it in this thread. The tl;dr of it is:
- All expected AA functions are available and work as expected
- The icon to go into AA on the home screen is funny looking because it doesn't exist
- Sometimes the microphone doesn't detect within the first few minutes of connecting (this might just be a me or my phone issue)
- The diamond button on your steering wheel does not do anything within the AA environment
What updates? AA is driven almost entirely by the phone.
The headunit side of it is simply a receiver for the audio and video signal, enables autonegotiation for the bluetooth setup, and extends the car's microphone and GPS antenna (or signal?) to be available to the phone in some applications. Wireless AA is the only "upgrade" I'm aware of on the headunit side of things from what the PCM4 natively offers, and to be honest it's rather useless. You can get a third party dongle to enable wireless AA on any AA-enabled headunit that doesn't natively support the wireless part, or you can wait for someone to try to backport a future MIB2 system's code that supports wireless AA (and you will be waiting a very long time).
- Sometimes the microphone doesn't detect within the first few minutes of connecting (this might just be a me or my phone issue)
It's not just you. I have the same problem - the mic connection is spotty; sometimes it won't recognize anything, sometimes it recognizes the "hello google" and nothing else, and sometimes it's completely fine. I've got a Pixel 3 XL running Android 11 stock, FWIW. I do not seem to have this problem in my Volvo running AA.
It's not just you. I have the same problem - the mic connection is spotty; sometimes it won't recognize anything, sometimes it recognizes the "hello google" and nothing else, and sometimes it's completely fine. I've got a Pixel 3 XL running Android 11 stock, FWIW. I do not seem to have this problem in my Volvo running AA.
Odd, okay. Happened on my P2XL a lot. I seldom use it and can't remember if it's happened much or at all on my Galaxy S20U....
Hmm, so that really just leaves - I think - mkxfs as the potential culprit. My mkxfs cksum is
4137208885 337176 mkxfs
The other thing I see is that your mkxfs command is *not* the same as mine - in particular, you use "-r /" while I don't.
I have exactly your version, cksum is the same
I still tried to repack using your files the original ifs_extracted and after i have unpacked it but the problem persists.
I think that the problem is attribute list..
i'm running mkxfs on a vm Kali VmWare, may it be necessary to recompile it?is it very strange the change all file...
if anyone has any other version of mkxfs and mkifs_attribute.txt i would be very grateful.
thanks alls
I have exactly your version, cksum is the same
I still tried to repack using your files the original ifs_extracted and after i have unpacked it but the problem persists.
I think that the problem is attribute list..
i'm running mkxfs on a vm Kali VmWare, may it be necessary to recompile it?is it very strange the change all file...
if anyone has any other version of mkxfs and mkifs_attribute.txt i would be very grateful.
thanks alls
Mystery to me. Could be some internationalization/localization problem with code pages. Try setting everything to US English if it is not. Also, I used a Fedora 33 workstation VM for doing mine.
Mystery to me. Could be some internationalization/localization problem with code pages. Try setting everything to US English if it is not. Also, I used a Fedora 33 workstation VM for doing mine.
i have only keyboard italian...i'have restart the Vm with original keyboard setting, i took the test again, same problem.
dumpif and dumpifs_helper work because i did diff -r between original ifs_extracted and a patch for my fw version and it only changes the MIbroot.
I don't know what is the problem...
That's awesome, I am in contact with them right now. I bought the dongle you linked and he said "you got it right the first time". haha. Thank you for the advice!
03-18-2021, 09:52 PM
