rename 7360 to 7560

[lneuhaus]

The driver for 7360 did not work for my 7560 modem. Simply renaming all occurrences of 7360 to 7560 worked for me. I understand that this is not supposed to replace the 7360 driver, but wanted to raise awareness of this option. Maybe both drivers can be merged into one by someone more familiar with the codebase. Until then, using this feature branch should do the job for the 7560.

EDIT: I got further by using this driver, i.e. surpassed a number of errors I had with the original 7360 driver. However, I never actually got a WAN connection working with this either. Not sure what's missing still.

[lneuhaus]

EDIT: I got further by using this driver, i.e. surpassed a number of errors I had with the original 7360 driver. However, I never actually got a WAN connection working with this either. Not sure what's missing still.

[x42]

Thanks for getting the ball rolling! Module loads and

I managed to communicate with the device using some basic AT commands (via echo and cat /dev/ttyXMM1) Ostensibly it looks fine.

AT+CGMI         -> Fibocom
AT+CGMM         -> L860 LTE Module
AT+CMEE=2       -> OK
AT+CPIN?        -> +CME ERROR: SIM NOT INSERTED
AT+CSQ          -> CSQ: 99,99

However there is a SIM in the slot... -- Do you get past this stage?

Otherwise I guess we'll have to wait for https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/258#note_681451 (fingers crossed)

[tgxn]

Without toggle-able support for both devices, this will have to remain a branch/hard fork.

[cawilliamson]

I've packaged this modified driver for NixOS - even wrote a patch for the latest version with the rename changes referenced here and I get the same thing as you folks - I never managed to get a successful connection - open_xdachannel results in:

root@thinkpad> open_xdatachannel -a everywhere                                                                                      /etc/nixos/pkgs/xmm7560
RPC executing UtaMsSmsInit
b'1600000002040000001602040000003011000100020400000000'
response: 0x0
RPC executing UtaMsCbsInit
b'1600000002040000001602040000002511000100020400000000'
response: 0xffffffa8
RPC executing UtaMsNetOpen
b'1600000002040000001602040000005311000100020400000000'
response: 0xffffffa8
RPC executing UtaMsCallCsInit
b'1600000002040000001602040000002411000100020400000000'
response: 0xffffffa8
RPC executing UtaMsCallPsInitialize
b'1600000002040000001602040000003a11000100020400000000'
response: 0xfffffff7
RPC executing UtaMsSsInit
b'1600000002040000001602040000002611000100020400000000'
response: 0xffffffa8
RPC executing UtaMsSimOpenReq
b'1600000002040000001602040000000111000100020400000000'
response: 0xffffffa8
RPC executing CsiFccLockQueryReq
b'1c00000002040000001c02040000018e11000101020411000101020400000000'
async_ack: 0x0

Did anyone get any further with this? I will continue to poke and prod it when I get some time free but for now I've got this as far as I can.

[tgxn]

Hi @cawilliamson,

I'm not sure this fork/branch ever worked. @lneuhaus mentioned he didn't manage to get it working.
There's some more discussion in this thread but not for a few months now.

The part it's getting hung up on could be related to the FCC lock (CsiFccLockQueryReq) (or the UtaModeSet directly afterwards)

Edit: Thinking you should see the output to do_fcc_unlock if it got a response from rpc:

xmm7360-pci/rpc/rpc.py

Line 371 in 1eb2ee4

print("FCC lock: state %d mode %d" % (fcc_state, fcc_mode))

If you're not seeing that then something related to FCC unlock code must be borked.

[nursoda]

You marked this as wontfix. Typically this means that this bug should be closed. I assume the right place to mention this would be the main README.md?