Re: Linux Kernel 6.6.36 and upstream mhi repo latest: Interface definition of sierra_em919x

Re: Linux Kernel 6.6.36 and upstream mhi repo latest: Interface definition of sierra_em919x

[manivannan.sadhasivam]

+ Slark (Foxconn PoC), MHI list

Hi Johannes,

On Fri, Jul 12, 2024 at 02:57:57PM +0000, Johannes Fischer wrote:
> Hi Mani,
> found you for a maintainer for the MHI package at kernel.org .
> 
> We are building up a BananaPi-R4  openwrt (snapshot) box where we ant to have a SierraWireless EM9191 modem in the M.2 slot being connected via PCIe. First, we had some trouble detecting the SIM, that is solved by isolating the SIM_DET pin on the module, the BPI-R4 has wrong logic on SIM detection contact (in opposite to statement in schematic). The EM9191 runs on almost latest firmware.
> The BPI-R4 has the specialty that FULL_CARD_POWER_OFF# and RESET# are not controlled by GPIO. PCIe Interface PERST is controlled as expected
> After solving this, adding right kernel modules and powering up the box we saw module coming up exposing a "wwan0" network interface and devices for AT, mbim(ctrl) and qxdm.
> We were able to set up traffic using mbim-network and mbim-set-ip script, very manual, no modemmanager or similar.
> After a reboot (or a pci device remove / pci bus rescan in sysfs) the modules showed up differently. We got a network interface named "mhi_hwip0", devices were AT, mbim(ctrl), qmi, qxdm.
> AT/qxdm was accessible, the mbim and qmi channels as well, however we were not able to start traffic by configuring the interface as before.
> 
> Looking at dmesg revealed the lines given below. The module looks to enumerate differently, reason is not known to us.
> 
> <power on>
> root@ROOter:~# dmesg | grep "MHI PCI device found"
> [   12.039259] mhi-pci-generic 0003:01:00.0: MHI PCI device found: foxconn-sdx55
> root@ROOter:~# echo 1 > /sys/bus/pci/devices/0003:01:00.0/remove
> root@ROOter:~# echo 1 > /sys/bus/pci/rescan
> root@ROOter:~# dmesg | grep "MHI PCI device found"
> [   12.039259] mhi-pci-generic 0003:01:00.0: MHI PCI device found: foxconn-sdx55
> [  144.317656] mhi-pci-generic 0003:01:00.0: MHI PCI device found: sierra-em919x
> root@ROOter:~##
> 

I believe the reason for 2 different enumeration behavior is due to the firmware
not detecting the reboot properly. So if your host SoC is not toggling the
PERST# as expected, you will end up seeing these kind of behaviors.

@Slark: Correct me if I'm wrong. Also please share the reboot steps expected by
the firmware.

During PCI remove/rescan, if the driver is unloaded then we just power down the
MHI stack, but don't reset the device. And when the driver is loaded again, it
again powers up the MHI stack. And this means, only the MHI state machine will
be reset. So this should not change the firmware flow. But I don't exactly know
how the firmware behaves. Maybe the firmware gets reset?

@Slark: Again, please share what is the expected behavior of the firmware during
host driver unload/reload.

> With this information I went into pci-generic.c and this showed for the two types of devices
> static const struct mhi_channel_config mhi_foxconn_sdx55_channels[] = {
>                 MHI_CHANNEL_CONFIG_UL(0, "LOOPBACK", 32, 0),
>                 MHI_CHANNEL_CONFIG_DL(1, "LOOPBACK", 32, 0),
>                 MHI_CHANNEL_CONFIG_UL(4, "DIAG", 32, 1),
>                 MHI_CHANNEL_CONFIG_DL(5, "DIAG", 32, 1),
>                 MHI_CHANNEL_CONFIG_UL(12, "MBIM", 32, 0),
>                 MHI_CHANNEL_CONFIG_DL(13, "MBIM", 32, 0),
>                 MHI_CHANNEL_CONFIG_UL(32, "DUN", 32, 0),
>                 MHI_CHANNEL_CONFIG_DL(33, "DUN", 32, 0),
>                 MHI_CHANNEL_CONFIG_HW_UL(100, "IP_HW0_MBIM", 128, 2),
>                 MHI_CHANNEL_CONFIG_HW_DL(101, "IP_HW0_MBIM", 128, 3),
> };
> 
> And
> 
> static const struct mhi_channel_config mhi_sierra_em919x_channels[] = {
>                 MHI_CHANNEL_CONFIG_UL_SBL(2, "SAHARA", 32, 0),
>                 MHI_CHANNEL_CONFIG_DL_SBL(3, "SAHARA", 256, 0),
>                 MHI_CHANNEL_CONFIG_UL(4, "DIAG", 32, 0),
>                 MHI_CHANNEL_CONFIG_DL(5, "DIAG", 32, 0),
>                 MHI_CHANNEL_CONFIG_UL(12, "MBIM", 128, 0),
>                 MHI_CHANNEL_CONFIG_DL(13, "MBIM", 128, 0),
>                 MHI_CHANNEL_CONFIG_UL(14, "QMI", 32, 0),
>                 MHI_CHANNEL_CONFIG_DL(15, "QMI", 32, 0),
>                 MHI_CHANNEL_CONFIG_UL(32, "DUN", 32, 0),
>                 MHI_CHANNEL_CONFIG_DL(33, "DUN", 32, 0),
>                 MHI_CHANNEL_CONFIG_HW_UL(100, "IP_HW0", 512, 1),
>                 MHI_CHANNEL_CONFIG_HW_DL(101, "IP_HW0", 512, 2),
> };
> 
> Here you can see, that the IP channels are configured differently.
> 
> I gave it a try and configure the IP channels for EM919x for MBIM as well.
> This solved the issue, EM9191 enumerates now for "wwan0" as well after restart of the PCIe link by rescan and reboot.
> 
> Th EM9191 is a 5GNR Sub6 module and follow the QC strategy only to expose MBIM for IP connectivity, RMNET and RNDIS are not supported as per documentation.
> 
> My question here would be why this got not reported before, I see a lot of activities ongoing for Foxconn-SDX55 but low for the restart issues. It may be the the missing GPIOs for RESET#/FULL_CARD_POWER_OFF# are special for the BPI-R4 board. We saw for Techship MC201 that these can be directed to GPIO by setting a jumper. Maybe Lenovo laptops etc always invoke RESET# if such modules have to recover.
> 
> Anyway, I think we can live with the change, proposal would be to add this to upstream.  Question is still open, why it enumerates differently.
> 

No, we cannot change the modem config due errantic firmware behavior. This will
affect other modems depending on this config.

Let's hear from Slark first.

- Mani

-- 
மணிவண்ணன் சதாசிவம்

Re: Linux Kernel 6.6.36 and upstream mhi repo latest: Interface definition of sierra_em919x

[Johannes Fischer]

Hi all,
@Stark,
first, I accept that changes may have side impact on other modems.
Please have in mind that I flashed SWIX55C_03.14.10.04 and the respective generic nvu a few days ago, so I assume to be quite close to default config.

Using  the sierra_em919x config with IP links changed to MBIM in kernel I can establish data traffic; I do not see a component converting the MBIM stream to RMnet in Linux kernel (?). I wonder whether there is positive  confirmation about a EM919x working in PCIe mode with the current kernel config, in which mode? (We did not have trouble using the EM919x in USB mode.)

About GPIO handling, as said there is none for for Full_Card_Power_off# (6, 10k pull-up to 3V3) and RESET# (67, just a C=100nF to GND) on the BPI-R4. 
We  have not validated the timing in BPI-R4 with 6.6.36 or current kernel versus the timing diagram at "AirPrime EM919X/EM7690 Product Technical Specification". As you said there may be a corner case that we end up 
with the Foxconn config due to timing at BPI-R4 power up times.

I get from your statement, that the valid config should be sierra_em919x, thanks for this clarification.

@Mani,
for  my understanding: I would be only able to get a MBIM type channel if the channel is configured for IP_HW0_MBIM. If it is configured for IP_HW0 only than it would be plain IP traffic like RMnet. Is this understanding ight? - Thanks

Johannes Fischer

________________________________________
From: Slark Xiao <slark_xiao@163.com>
Sent: Friday, 12 July 2024 18:38
To: manivannan.sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: Johannes Fischer <johannes.fischer@verificationpartners.com>; Steven Edwards <steven.edwards@verificationpartners.com>; mhi <mhi@lists.linux.dev>
Subject: Re: Linux Kernel 6.6.36 and upstream mhi repo latest: Interface definition of sierra_em919x
 
Hi all，
I believe this issue caused by some issue on device AP side or PIN power sequence. We met similar issue before.
You were using the settings of foxconn at first since the sub-vid match with foxconn. This actually is not expected since there  is a Sierra settings exists .
After remove and reacan, you get the correct PCIe ID enumarate. That's what it is. Sierra config was added based on rmnet solution, so your previous MBIM solution won't work anymore.
There is a difference of the sub-VID/PID between the PBL stage and kenel up boot stage.
This issue mainly caused by an abnormal initial boot (may come from firmware side or the PCIE power sequence, including full card power off/PERST ).

---- Replied Message ----

+ Slark (Foxconn PoC), MHI list

Hi Johannes,

On Fri, Jul 12, 2024 at 02:57:57PM +0000, Johannes Fischer wrote:
> Hi Mani,
> found you for a maintainer for the MHI package at kernel.org .
>
> We are building up a BananaPi-R4  openwrt (snapshot) box where we ant to have a SierraWireless EM9191 modem in the M.2 slot being connected via PCIe. First, we had some trouble detecting the SIM, that is solved by isolating the SIM_DET pin on the module, the BPI-R4 has wrong logic on SIM detection contact (in opposite to statement in schematic). The EM9191 runs on almost latest firmware.
> The BPI-R4 has the specialty that FULL_CARD_POWER_OFF# and RESET# are not controlled by GPIO. PCIe Interface PERST is controlled as expected
> After solving this, adding right kernel modules and powering up the box we saw module coming up exposing a "wwan0" network interface and devices for AT, mbim(ctrl) and qxdm.
> We were able to set up traffic using mbim-network and mbim-set-ip script, very manual, no modemmanager or similar.
> After a reboot (or a pci device remove / pci bus rescan in sysfs) the modules showed up differently. We got a network interface named "mhi_hwip0", devices were AT, mbim(ctrl), qmi, qxdm.
> AT/qxdm was accessible, the mbim and qmi channels as well, however we were not able to start traffic by configuring the interface as before.
>
> Looking at dmesg revealed the lines given below. The module looks to enumerate differently, reason is not known to us.
>
> <power on>
> root@ROOter:~# dmesg | grep "MHI PCI device found"
> [   12.039259] mhi-pci-generic 0003:01:00.0: MHI PCI device found: foxconn-sdx55
> root@ROOter:~# echo 1 > /sys/bus/pci/devices/0003:01:00.0/remove
> root@ROOter:~# echo 1 > /sys/bus/pci/rescan
> root@ROOter:~# dmesg | grep "MHI PCI device found"
> [   12.039259] mhi-pci-generic 0003:01:00.0: MHI PCI device found: foxconn-sdx55
> [  144.317656] mhi-pci-generic 0003:01:00.0: MHI PCI device found: sierra-em919x
> root@ROOter:~##
>

I believe the reason for 2 different enumeration behavior is due to the firmware
not detecting the reboot properly. So if your host SoC is not toggling the
PERST# as expected, you will end up seeing these kind of behaviors.

@Slark: Correct me if I'm wrong. Also please share the reboot steps expected by
the firmware.

During PCI remove/rescan, if the driver is unloaded then we just power down the
MHI stack, but don't reset the device. And when the driver is loaded again, it
again powers up the MHI stack. And this means, only the MHI state machine will
be reset. So this should not change the firmware flow. But I don't exactly know
how the firmware behaves. Maybe the firmware gets reset?

@Slark: Again, please share what is the expected behavior of the firmware during
host driver unload/reload.

> With this information I went into pci-generic.c and this showed for the two types of devices
> static const struct mhi_channel_config mhi_foxconn_sdx55_channels[] = {
>                 MHI_CHANNEL_CONFIG_UL(0, "LOOPBACK", 32, 0),
>                 MHI_CHANNEL_CONFIG_DL(1, "LOOPBACK", 32, 0),
>                 MHI_CHANNEL_CONFIG_UL(4, "DIAG", 32, 1),
>                 MHI_CHANNEL_CONFIG_DL(5, "DIAG", 32, 1),
>                 MHI_CHANNEL_CONFIG_UL(12, "MBIM", 32, 0),
>                 MHI_CHANNEL_CONFIG_DL(13, "MBIM", 32, 0),
>                 MHI_CHANNEL_CONFIG_UL(32, "DUN", 32, 0),
>                 MHI_CHANNEL_CONFIG_DL(33, "DUN", 32, 0),
>                 MHI_CHANNEL_CONFIG_HW_UL(100, "IP_HW0_MBIM", 128, 2),
>                 MHI_CHANNEL_CONFIG_HW_DL(101, "IP_HW0_MBIM", 128, 3),
> };
>
> And
>
> static const struct mhi_channel_config mhi_sierra_em919x_channels[] = {
>                 MHI_CHANNEL_CONFIG_UL_SBL(2, "SAHARA", 32, 0),
>                 MHI_CHANNEL_CONFIG_DL_SBL(3, "SAHARA", 256, 0),
>                 MHI_CHANNEL_CONFIG_UL(4, "DIAG", 32, 0),
>                 MHI_CHANNEL_CONFIG_DL(5, "DIAG", 32, 0),
>                 MHI_CHANNEL_CONFIG_UL(12, "MBIM", 128, 0),
>                 MHI_CHANNEL_CONFIG_DL(13, "MBIM", 128, 0),
>                 MHI_CHANNEL_CONFIG_UL(14, "QMI", 32, 0),
>                 MHI_CHANNEL_CONFIG_DL(15, "QMI", 32, 0),
>                 MHI_CHANNEL_CONFIG_UL(32, "DUN", 32, 0),
>                 MHI_CHANNEL_CONFIG_DL(33, "DUN", 32, 0),
>                 MHI_CHANNEL_CONFIG_HW_UL(100, "IP_HW0", 512, 1),
>                 MHI_CHANNEL_CONFIG_HW_DL(101, "IP_HW0", 512, 2),
> };
>
> Here you can see, that the IP channels are configured differently.
>
> I gave it a try and configure the IP channels for EM919x for MBIM as well.
> This solved the issue, EM9191 enumerates now for "wwan0" as well after restart of the PCIe link by rescan and reboot.
>
> Th EM9191 is a 5GNR Sub6 module and follow the QC strategy only to expose MBIM for IP connectivity, RMNET and RNDIS are not supported as per documentation.
>
> My question here would be why this got not reported before, I see a lot of activities ongoing for Foxconn-SDX55 but low for the restart issues. It may be the the missing GPIOs for RESET#/FULL_CARD_POWER_OFF# are special for the BPI-R4 board. We saw for Techship MC201 that these can be directed to GPIO by setting a jumper. Maybe Lenovo laptops etc always invoke RESET# if such modules have to recover.
>
> Anyway, I think we can live with the change, proposal would be to add this to upstream.  Question is still open, why it enumerates differently.
>

No, we cannot change the modem config due errantic firmware behavior. This will
affect other modems depending on this config.

Let's hear from Slark first.

- Mani

--
மணிவண்ணன் சதாசிவம்

Re:Re: Linux Kernel 6.6.36 and upstream mhi repo latest: Interface definition of sierra_em919x

[Slark Xiao]

At 2024-07-13 17:41:27, "Johannes Fischer" <johannes.fischer@verificationpartners.com> wrote:
>Hi all,
>@Stark,
>first, I accept that changes may have side impact on other modems.
>Please have in mind that I flashed SWIX55C_03.14.10.04 and the respective generic nvu a few days ago, so I assume to be quite close to default config.
>
>Using  the sierra_em919x config with IP links changed to MBIM in kernel I can establish data traffic; I do not see a component converting the MBIM stream to RMnet in Linux kernel (?). I wonder whether there is positive  confirmation about a EM919x working in PCIe mode with the current kernel config, in which mode? (We did not have trouble using the EM919x in USB mode.)
>
>About GPIO handling, as said there is none for for Full_Card_Power_off# (6, 10k pull-up to 3V3) and RESET# (67, just a C=100nF to GND) on the BPI-R4. 
>We  have not validated the timing in BPI-R4 with 6.6.36 or current kernel versus the timing diagram at "AirPrime EM919X/EM7690 Product Technical Specification". As you said there may be a corner case that we end up 
>with the Foxconn config due to timing at BPI-R4 power up times.
>
>I get from your statement, that the valid config should be sierra_em919x, thanks for this clarification.
>

Yeah, I just checked this issue again. We met this issue in our ARM  platform.
Device boot up shall through PBL->SBL->Kernel boot up. And there are 2 different PCIe settings between PBL and kernel side.
When host mhi driver probed, your device may still in PBL  stage or SBL stage(the PCIe EP in device side is not ready), then you will get a "foxconn-config" since your PBL ID match with that one.
Solution shall have these:
1. Update firmware side to keep ID same between PBL and kernel config.
2. Powerup device earlier.
3. Probe MHI driver by manual to avoid of device kernel is not ready.

>@Mani,
>for  my understanding: I would be only able to get a MBIM type channel if the channel is configured for IP_HW0_MBIM. If it is configured for IP_HW0 only than it would be plain IP traffic like RMnet. Is this understanding ight? - Thanks
>
>Johannes Fischer
>
>________________________________________
>From: Slark Xiao <slark_xiao@163.com>
>Sent: Friday, 12 July 2024 18:38
>To: manivannan.sadhasivam <manivannan.sadhasivam@linaro.org>
>Cc: Johannes Fischer <johannes.fischer@verificationpartners.com>; Steven Edwards <steven.edwards@verificationpartners.com>; mhi <mhi@lists.linux.dev>
>Subject: Re: Linux Kernel 6.6.36 and upstream mhi repo latest: Interface definition of sierra_em919x
> 
>Hi all，
>I believe this issue caused by some issue on device AP side or PIN power sequence. We met similar issue before.
>You were using the settings of foxconn at first since the sub-vid match with foxconn. This actually is not expected since there  is a Sierra settings exists .
>After remove and reacan, you get the correct PCIe ID enumarate. That's what it is. Sierra config was added based on rmnet solution, so your previous MBIM solution won't work anymore.
>There is a difference of the sub-VID/PID between the PBL stage and kenel up boot stage.
>This issue mainly caused by an abnormal initial boot (may come from firmware side or the PCIE power sequence, including full card power off/PERST ).
>
>---- Replied Message ----
>
>+ Slark (Foxconn PoC), MHI list
>
>Hi Johannes,
>
>On Fri, Jul 12, 2024 at 02:57:57PM +0000, Johannes Fischer wrote:
>> Hi Mani,
>> found you for a maintainer for the MHI package at kernel.org .
>>
>> We are building up a BananaPi-R4  openwrt (snapshot) box where we ant to have a SierraWireless EM9191 modem in the M.2 slot being connected via PCIe. First, we had some trouble detecting the SIM, that is solved by isolating the SIM_DET pin on the module, the BPI-R4 has wrong logic on SIM detection contact (in opposite to statement in schematic). The EM9191 runs on almost latest firmware.
>> The BPI-R4 has the specialty that FULL_CARD_POWER_OFF# and RESET# are not controlled by GPIO. PCIe Interface PERST is controlled as expected
>> After solving this, adding right kernel modules and powering up the box we saw module coming up exposing a "wwan0" network interface and devices for AT, mbim(ctrl) and qxdm.
>> We were able to set up traffic using mbim-network and mbim-set-ip script, very manual, no modemmanager or similar.
>> After a reboot (or a pci device remove / pci bus rescan in sysfs) the modules showed up differently. We got a network interface named "mhi_hwip0", devices were AT, mbim(ctrl), qmi, qxdm.
>> AT/qxdm was accessible, the mbim and qmi channels as well, however we were not able to start traffic by configuring the interface as before.
>>
>> Looking at dmesg revealed the lines given below. The module looks to enumerate differently, reason is not known to us.
>>
>> <power on>
>> root@ROOter:~# dmesg | grep "MHI PCI device found"
>> [   12.039259] mhi-pci-generic 0003:01:00.0: MHI PCI device found: foxconn-sdx55
>> root@ROOter:~# echo 1 > /sys/bus/pci/devices/0003:01:00.0/remove
>> root@ROOter:~# echo 1 > /sys/bus/pci/rescan
>> root@ROOter:~# dmesg | grep "MHI PCI device found"
>> [   12.039259] mhi-pci-generic 0003:01:00.0: MHI PCI device found: foxconn-sdx55
>> [  144.317656] mhi-pci-generic 0003:01:00.0: MHI PCI device found: sierra-em919x
>> root@ROOter:~##
>>
>
>I believe the reason for 2 different enumeration behavior is due to the firmware
>not detecting the reboot properly. So if your host SoC is not toggling the
>PERST# as expected, you will end up seeing these kind of behaviors.
>
>@Slark: Correct me if I'm wrong. Also please share the reboot steps expected by
>the firmware.
>
>During PCI remove/rescan, if the driver is unloaded then we just power down the
>MHI stack, but don't reset the device. And when the driver is loaded again, it
>again powers up the MHI stack. And this means, only the MHI state machine will
>be reset. So this should not change the firmware flow. But I don't exactly know
>how the firmware behaves. Maybe the firmware gets reset?
>
>@Slark: Again, please share what is the expected behavior of the firmware during
>host driver unload/reload.

Just like I said in above, driver unload/reload  shall don't have any  impact. Firmware
side would do a new connection with RC  side without firmware reset.

>
>> With this information I went into pci-generic.c and this showed for the two types of devices
>> static const struct mhi_channel_config mhi_foxconn_sdx55_channels[] = {
>>                 MHI_CHANNEL_CONFIG_UL(0, "LOOPBACK", 32, 0),
>>                 MHI_CHANNEL_CONFIG_DL(1, "LOOPBACK", 32, 0),
>>                 MHI_CHANNEL_CONFIG_UL(4, "DIAG", 32, 1),
>>                 MHI_CHANNEL_CONFIG_DL(5, "DIAG", 32, 1),
>>                 MHI_CHANNEL_CONFIG_UL(12, "MBIM", 32, 0),
>>                 MHI_CHANNEL_CONFIG_DL(13, "MBIM", 32, 0),
>>                 MHI_CHANNEL_CONFIG_UL(32, "DUN", 32, 0),
>>                 MHI_CHANNEL_CONFIG_DL(33, "DUN", 32, 0),
>>                 MHI_CHANNEL_CONFIG_HW_UL(100, "IP_HW0_MBIM", 128, 2),
>>                 MHI_CHANNEL_CONFIG_HW_DL(101, "IP_HW0_MBIM", 128, 3),
>> };
>>
>> And
>>
>> static const struct mhi_channel_config mhi_sierra_em919x_channels[] = {
>>                 MHI_CHANNEL_CONFIG_UL_SBL(2, "SAHARA", 32, 0),
>>                 MHI_CHANNEL_CONFIG_DL_SBL(3, "SAHARA", 256, 0),
>>                 MHI_CHANNEL_CONFIG_UL(4, "DIAG", 32, 0),
>>                 MHI_CHANNEL_CONFIG_DL(5, "DIAG", 32, 0),
>>                 MHI_CHANNEL_CONFIG_UL(12, "MBIM", 128, 0),
>>                 MHI_CHANNEL_CONFIG_DL(13, "MBIM", 128, 0),
>>                 MHI_CHANNEL_CONFIG_UL(14, "QMI", 32, 0),
>>                 MHI_CHANNEL_CONFIG_DL(15, "QMI", 32, 0),
>>                 MHI_CHANNEL_CONFIG_UL(32, "DUN", 32, 0),
>>                 MHI_CHANNEL_CONFIG_DL(33, "DUN", 32, 0),
>>                 MHI_CHANNEL_CONFIG_HW_UL(100, "IP_HW0", 512, 1),
>>                 MHI_CHANNEL_CONFIG_HW_DL(101, "IP_HW0", 512, 2),
>> };
>>
>> Here you can see, that the IP channels are configured differently.
>>
>> I gave it a try and configure the IP channels for EM919x for MBIM as well.
>> This solved the issue, EM9191 enumerates now for "wwan0" as well after restart of the PCIe link by rescan and reboot.
>>
>> Th EM9191 is a 5GNR Sub6 module and follow the QC strategy only to expose MBIM for IP connectivity, RMNET and RNDIS are not supported as per documentation.
>>

You shall contact with @Thomas Perrot for confirmation. Sierra device was added by him.

>> My question here would be why this got not reported before, I see a lot of activities ongoing for Foxconn-SDX55 but low for the restart issues. It may be the the missing GPIOs for RESET#/FULL_CARD_POWER_OFF# are special for the BPI-R4 board. We saw for Techship MC201 that these can be directed to GPIO by setting a jumper. Maybe Lenovo laptops etc always invoke RESET# if such modules have to recover.
>>
>> Anyway, I think we can live with the change, proposal would be to add this to upstream.  Question is still open, why it enumerates differently.
>>
>
>No, we cannot change the modem config due errantic firmware behavior. This will
>affect other modems depending on this config.
>
>Let's hear from Slark first.
>
>- Mani
>
>--
>மணிவண்ணன் சதாசிவம்

Re: Re: Linux Kernel 6.6.36 and upstream mhi repo latest: Interface definition of sierra_em919x

[manivannan.sadhasivam]

On Mon, Jul 15, 2024 at 11:43:26AM +0800, Slark Xiao wrote:
> 
> At 2024-07-13 17:41:27, "Johannes Fischer" <johannes.fischer@verificationpartners.com> wrote:
> >Hi all,
> >@Stark,
> >first, I accept that changes may have side impact on other modems.
> >Please have in mind that I flashed SWIX55C_03.14.10.04 and the respective generic nvu a few days ago, so I assume to be quite close to default config.
> >
> >Using  the sierra_em919x config with IP links changed to MBIM in kernel I can establish data traffic; I do not see a component converting the MBIM stream to RMnet in Linux kernel (?). I wonder whether there is positive  confirmation about a EM919x working in PCIe mode with the current kernel config, in which mode? (We did not have trouble using the EM919x in USB mode.)
> >
> >About GPIO handling, as said there is none for for Full_Card_Power_off# (6, 10k pull-up to 3V3) and RESET# (67, just a C=100nF to GND) on the BPI-R4. 
> >We  have not validated the timing in BPI-R4 with 6.6.36 or current kernel versus the timing diagram at "AirPrime EM919X/EM7690 Product Technical Specification". As you said there may be a corner case that we end up 
> >with the Foxconn config due to timing at BPI-R4 power up times.
> >
> >I get from your statement, that the valid config should be sierra_em919x, thanks for this clarification.
> >
> 
> Yeah, I just checked this issue again. We met this issue in our ARM  platform.
> Device boot up shall through PBL->SBL->Kernel boot up. And there are 2 different PCIe settings between PBL and kernel side.
> When host mhi driver probed, your device may still in PBL  stage or SBL stage(the PCIe EP in device side is not ready), then you will get a "foxconn-config" since your PBL ID match with that one.
> Solution shall have these:
> 1. Update firmware side to keep ID same between PBL and kernel config.

Having 2 PCIe IDs for a single device doesn't sound right. If it is fixed in
successive firmware releases then fine, otherwise please fix it for all.

- Mani

-- 
மணிவண்ணன் சதாசிவம்

Re:Re: Re: Linux Kernel 6.6.36 and upstream mhi repo latest: Interface definition of sierra_em919x

[Slark Xiao]

At 2024-07-21 16:35:22, "manivannan.sadhasivam" <manivannan.sadhasivam@linaro.org> wrote:
>On Mon, Jul 15, 2024 at 11:43:26AM +0800, Slark Xiao wrote:
>> 
>> At 2024-07-13 17:41:27, "Johannes Fischer" <johannes.fischer@verificationpartners.com> wrote:
>> >Hi all,
>> >@Stark,
>> >first, I accept that changes may have side impact on other modems.
>> >Please have in mind that I flashed SWIX55C_03.14.10.04 and the respective generic nvu a few days ago, so I assume to be quite close to default config.
>> >
>> >Using  the sierra_em919x config with IP links changed to MBIM in kernel I can establish data traffic; I do not see a component converting the MBIM stream to RMnet in Linux kernel (?). I wonder whether there is positive  confirmation about a EM919x working in PCIe mode with the current kernel config, in which mode? (We did not have trouble using the EM919x in USB mode.)
>> >
>> >About GPIO handling, as said there is none for for Full_Card_Power_off# (6, 10k pull-up to 3V3) and RESET# (67, just a C=100nF to GND) on the BPI-R4. 
>> >We  have not validated the timing in BPI-R4 with 6.6.36 or current kernel versus the timing diagram at "AirPrime EM919X/EM7690 Product Technical Specification". As you said there may be a corner case that we end up 
>> >with the Foxconn config due to timing at BPI-R4 power up times.
>> >
>> >I get from your statement, that the valid config should be sierra_em919x, thanks for this clarification.
>> >
>> 
>> Yeah, I just checked this issue again. We met this issue in our ARM  platform.
>> Device boot up shall through PBL->SBL->Kernel boot up. And there are 2 different PCIe settings between PBL and kernel side.
>> When host mhi driver probed, your device may still in PBL  stage or SBL stage(the PCIe EP in device side is not ready), then you will get a "foxconn-config" since your PBL ID match with that one.
>> Solution shall have these:
>> 1. Update firmware side to keep ID same between PBL and kernel config.
>
>Having 2 PCIe IDs for a single device doesn't sound right. If it is fixed in
>successive firmware releases then fine, otherwise please fix it for all.
>
>- Mani
>
>-- 
>மணிவண்ணன் சதாசிவம்
For formal release, we will write PCIE ID into fuse to keep PBL PCIe ID same as Kernel side.
This issue normally could be found in test module only.
Maybe Sierra Wireless didn't notice this issue( or no fuse mechanism applied).

Thanks!

Re: Linux Kernel 6.6.36 and upstream mhi repo latest: Interface definition of sierra_em919x

[manivannan.sadhasivam]

On Sat, Jul 13, 2024 at 09:33:17AM +0000, Johannes Fischer wrote:
> Hi all,
> @Stark,
> first, I accept that changes may have side impact on other modems.
> Please have in mind that I flashed SWIX55C_03.14.10.04 and the respective generic nvu a few days ago, so I assume to be quite close to default config.
> 
> Using the sierra_em919x config with IP links changed to MBIM in kernel I can establish data traffic; I do not see a component converting the MBIM stream to RMnet in Linux kernel (?). I wonder whether there is positive confirmation about a EM919x working in PCIe mode with the current kernel config, in which mode? (We did not have trouble using the EM919x in USB mode.)
> 
> About GPIO handling, as said there is none for for Full_Card_Power_off# (6, 10k pull-up to 3V3) and RESET# (67, just a C=100nF to GND) on the BPI-R4.
> We have not validated the timing in BPI-R4 with 6.6.36 or current kernel versus the timing diagram at "AirPrime EM919X/EM7690 Product Technical Specification". As you said there may be a corner case that we end up with the Foxconn config due to timing at BPI-R4 power up times.
> 
> I get from your statement, that the valid config should be sierra_em919x, thanks for this clarification.
> 
> @Mani,
> for my understanding: I would be only able to get a MBIM type channel if the channel is configured for IP_HW0_MBIM. If it is configured for IP_HW0 only than it would be plain IP traffic like RMnet. Is this understanding right? - Thanks
> 

Correct.

- Mani

-- 
மணிவண்ணன் சதாசிவம்