pcengines/apu2-documentation

Cellular modem detection in PCIe mode

Opened this issue · 6 comments

baantunes commented

PCEngines firmware version

v4.15.0.1 and a compiled one based on v4.15.0.1

APU2 variant

apu2e running ubuntu server 20.04

Question text

We are trying to run a cellular modem in PCIe mode on the APU2.
For the board to detect it, we need to enter the boot menu, by selecting F10, then select option 2, and afterwards exit a let the board reboot.
We where advised by the manufacturer that this could be an issue related with the modem initialisation, where the module needed to boot itself up internally, before the host system could proceed with its own boot and detect connected PCIe devices.
For that we compiled our one BIOS, based on the v4.15.0.1, with the boot-menu-wait file with a value of 20 sec (after we figured the writing format). The board waits the defined 20 sec but the modem still isn't detected.
Also, subsequent soft reboots, i.e. without disconnecting from power, don't detect the modem and even if previously detected stops being detected.

What is the strange behaviour that entering the BIOS menu leads to the modem detection?

Thanks in advance,
Bruno

miczyg1 commented

I advise to get familiar with this comment and subsequent ones: #115 (comment)
apu2 PCIe reset circuitry is not well designed, it seems and causes problems with PCIe resetting and detection. We have encountered many other problems with modems, which e.g. involved broken cellular modem firmware which tried to use USB 3.0 signals of the modem, while the slot was connecting a PCIe or SATA signals to these pins. There is no easy telling what is the culprit here.

  • Any more details what cellular modem it is?
  • Any hardware manual describing the pins of the modem?
  • Which apu2 mPCIe slot did you use?
baantunes commented

Hello miczyg1,

Thank you for the reply.

I advise to get familiar with this comment and subsequent ones: #115 (comment)

I'm aware of it. I think this problem, while related, is somewhat different.

There is no easy telling what is the culprit here.

That's what I'm afraid of.

  • Any more details what cellular modem it is?

The modem is a SIMCom SIM8202G-M.2 5G

  • Any hardware manual describing the pins of the modem?

It's available this link HW design at page 13

  • Which apu2 mPCIe slot did you use?

The behaviour is the same in both slots

mkopec commented

For that we compiled our one BIOS, based on the v4.15.0.1, with the boot-menu-wait file with a value of 20 sec (after we figured the writing format). The board waits the defined 20 sec but the modem still isn't detected.

It's possible that the delay specified in boot-menu-file happens too late and the firmware needs to wait earlier in the boot process (i.e. before PCIe enumeration). We don't have this modem here for testing, but I've built a firmware image for you based on v4.16.0.3 with an extra 1 second delay before PCIe enumeration: https://cloud.3mdeb.com/index.php/s/3ELmAAtTdJ2qg8c

Please let me know if this fixes your issue, if it does then we'll integrate this into the next firmware release.

baantunes commented

Helo Michał,

Thank you for the firmware image. Now the modem is detected in the middle slot, for the other PCIe slot, it was necessary to enable the clock in the BIOS: Force mPCIe2 slot CLK (GPP3 PCIe). With that change the modem is consistently detected in both slots after soft and hard reboots.

The modem still isn't fully functional since we still don't have AT ports. We don't know if this would also be an issue with board or the drivers. On another board, the ten64 from traverse, we also aren't able to get the modem to work but at least the AT port is enumerated.

mkopec commented

@miczyg1 Any idea what the issue with the lack of AT ports might be related to?

metux commented

Can't speak for that particular modem, but experienced similar problems back a few ago (when writing the apu board linux driver). In my case it worked by sending RST via gpio (that's why the driver exports those lines) when the modem doesn't come up and wait for a while. Of course only works on those boards where the RST lines are wired as shown in the schematics.

Not sure whether bootload really can and should do something about it (especially when it becomes so modem specific): intermediate HW problems are something that the OS some how needs to handle nevertheless.

Everybody who's got similar problems: let's try to collect everything we learn about those problems.
For a bunch of other reasons we're thinking about an own baseband subsys (which then can get more knowledge on specific modems) that could also handle those quirks. But it's too early to say whether we can really spend the effort for that.