sonyxperiadev / device-sony-common

70 stars 139 forks source link

Add modem configs for Finnish providers Elisa and DNA #889

Closed LaakkonenJussi closed 2 years ago

LaakkonenJussi commented 2 years ago

This adds modem configs for the Finnish Elisa and DNA providers.

The firmware files reside at /vendor/firmware_mnt/image/modem_pr/mcfg/configs

The IDs are listed at service_provider_sim_configs.xml but were missing a modem.conf.

MarijnS95 commented 2 years ago

Just like with https://github.com/sonyxperiadev/device-sony-common/pull/884#issuecomment-1107803071, are these all the providers on your ROM that are not tracked in this repo yet?

Thaodan commented 2 years ago

This would be also needed for r-mr1.

MarijnS95 commented 2 years ago

Let's update the target branch (and rebase + force-push) indeed :)

jerpelea commented 2 years ago

please rebase

LaakkonenJussi commented 2 years ago

Just like with #884 (comment), are these all the providers on your ROM that are not tracked in this repo yet?

I think there are more but I have no resources to test them if they really work. There are many mbn files as well that do have MMC + MNC references (as, e.g., mcc123 and mnc123) - if those could be set according to the MCC and MNC codes defined for the config id in the XML then there would be more. Ran the following on android Q/10 base files:

#!/bin/bash
PATH_TO_MBN_FILES="$1"

find $PATH_TO_MBN_FILES/* -type f -name mcfg_sw.mbn|while read -r line ; do
    MCC=$(grep -oE 'mcc[0-9]{3}' "$line"|uniq|grep -oE '[0-9]{3}')
    MNC=$(grep -oE 'mnc[0-9]{3}' "$line"|uniq|grep -oE '[0-9]{3}')
    if [ ! -z "$MCC" ] && [ ! -z "$MNC" ] ; then echo "$line $MCC $MNC" ; fi
done

And there could be more that could have their configs set based on that info, if the conf is missing.

LaakkonenJussi commented 2 years ago

This would be also needed for r-mr1.

Sorry, finger slipped. I think we used android Q/10 as base here with these changes so changing accordingly to q-mr1 - if it is ok, and reopening.

LaakkonenJussi commented 2 years ago

Reopened.

LaakkonenJussi commented 2 years ago

please rebase

Done, to q-mr1.

sledges commented 2 years ago

Please do not cherry-pick this to r-mr1, because paths are different there;

[root@Xperia10III defaultuser]# find /vendor/firmware_mnt/image/modem_pr/mcfg/configs/ -type f | grep -Ei "elisa|dna"
/vendor/firmware_mnt/image/modem_pr/mcfg/configs/mcfg_sw/generic/EU/DNA/VLVW/Finland/mcfg_sw.mbn
/vendor/firmware_mnt/image/modem_pr/mcfg/configs/mcfg_sw/generic/EU/Elisa/Commercial/FI/mcfg_sw.mbn
/vendor/firmware_mnt/image/modem_pr/mcfg/configs/mcfg_sw/generic/EU/Elisa/VLVW/Estonia/mcfg_sw.mbn
jerpelea commented 2 years ago

@sledges too late. Please submit a patch with the path fix on r-mr1

MarijnS95 commented 2 years ago

@sledges But firmware_mnt is a device partition that's never touched by SODP. As such it is not attached to SODPs release scheme at all.

Or am I misreading your comment?

MarijnS95 commented 2 years ago

@LaakkonenJussi I don't think it matters if you have not tested them, most of these have probably never been tried. I just try to get as large of a mapping in here, it's already beyond stupid to have an mcc+mcn mapping (plus sometimes other fields) in an XML that map to a random code, which need to be resolved to an mbn path by reading another file from disk. Why can't we have the mbn name directly in XML (even if different for multiple devices) :facepalm:

I guess I prefer phones without a modem at all, instead of this garbage :grimacing:

sledges commented 2 years ago

@sledges But firmware_mnt is a device partition that's never touched by SODP. As such it is not attached to SODPs release scheme at all.

Or am I misreading your comment?

We encourage users to match the major version of stock Android before flashing AOSP or Sailfish OS. Otherwise there have been discrepancies in the past; and this too wouldn't work if users have differing paths in modem firmware as opposed to symlinks from here.

MarijnS95 commented 2 years ago

That seems quite inconsistent given that we're always focusing on compatibility with "the latest" (through emma, at least) firmware, and SODP is miles ahead of stock when it comes to Android versions.

Thaodan commented 2 years ago

Please do not cherry-pick this to r-mr1, because paths are different there;

[root@Xperia10III defaultuser]# find /vendor/firmware_mnt/image/modem_pr/mcfg/configs/ -type f | grep -Ei "elisa|dna"
/vendor/firmware_mnt/image/modem_pr/mcfg/configs/mcfg_sw/generic/EU/DNA/VLVW/Finland/mcfg_sw.mbn
/vendor/firmware_mnt/image/modem_pr/mcfg/configs/mcfg_sw/generic/EU/Elisa/Commercial/FI/mcfg_sw.mbn
/vendor/firmware_mnt/image/modem_pr/mcfg/configs/mcfg_sw/generic/EU/Elisa/VLVW/Estonia/mcfg_sw.mbn

That is not exactly true even on latest R the path for Xperia 1/Xperia 5 is still the on in this PR. It is somewhat true because later devices use the path names described in your comment.

sledges commented 2 years ago

That seems quite inconsistent given that we're always focusing on compatibility with "the latest" (through emma, at least) firmware, and SODP is miles ahead of stock when it comes to Android versions.

Unfortunately it is not feasible to expect all the existing users to reflash their devices via Emma once a newer version is available.

jerpelea commented 2 years ago

@sledges But firmware_mnt is a device partition that's never touched by SODP. As such it is not attached to SODPs release scheme at all. Or am I misreading your comment?

We encourage users to match the major version of stock Android before flashing AOSP or Sailfish OS. Otherwise there have been discrepancies in the past; and this too wouldn't work if users have differing paths in modem firmware as opposed to symlinks from here.

in this case we can create check where the configuration is stored and create symlinks for the missing files

MarijnS95 commented 2 years ago

Unfortunately it is not feasible to expect all the existing users to reflash their devices via Emma once a newer version is available.

Nor can you expect anyone to not have the latest firmware, someone is going to run into mismatched path problems either way.

in this case we can create check where the configuration is stored and create symlinks for the missing files

I don't think we should write to firmware_mnt where the mbns are stored. Perhaps ModemConfig on odm can be tweaked to support multiple paths in these modem.conf files, separated by a newline?

jerpelea commented 2 years ago

Sorry if I was not explaining my thoughts. I was thinking that we should check for paths then create symlinks in persist to point to the configs that match the device firmware. As the last step I will update vendor to match the new layout and read them form persist so that we can make all versions happy.

MarijnS95 commented 2 years ago

@jerpelea That only works if we can point ModemConfig (not the opensource part but the bit on ODM) to look for these files (the paths in this PR) relative to the persist directory. Then we also need "something" to create a symlink to the right directory.

But if we do, we might as well:

  1. Move all these paths, with possible alternative directories, into xml;
  2. Remove all these modem.conf files from the repo here;
  3. In the opensource ModemConfig bit, as soon as a SIM match is found:
    1. Find the first valid firmware path in its xml (it'll be a list, or multiple XML elements, or something);
    2. Create a modem.conf in the appropriate (new) S##.# subdirectory on /persist;
    3. Fill it with the path to the firmware mbn we found;
    4. Then proceed as normal with the setprop.
jerpelea commented 2 years ago

@Thaodan go for it

MarijnS95 commented 2 years ago

Presuming this is a good idea, who's going to make the modifications to ModemConfig?

jerpelea commented 2 years ago

@MarijnS95 I will modify the private part