I see that morse_driver uses a 16bit board_id from OTP_DATA2 M610X_OTP_DATA2_SUPPLEMENTAL_CHIP_ID which is used for the BCF file name.
I have two M.2 cards that both have an MM6108 but via different vendor modules. One is from Quectel and the other from Silex. Both report the same SDIO vid/pid and have no board_id programmed in OTP yet require different BCF files. As a card vendor using modules like these how am I supposed to program the OTP such that the BCF can be properly defaulted to the right file variant?
At the moment, none of our module partners are programming the boardtype field in OTP. As such, there is no way to identify the module type from software.
I am in the process of setting up a ‘registry’ and encouraging our partners to start programming those bits for exactly this reason. This will certainly be the case for new designs, and I will encourage assigning boardtypes to new production of current designs.
Unfortunately the MM6108 is inconvenient to program in the field. The OTP programming must be done with VDDIO at 2.5V.
At the moment, none of our module partners are programming the boardtype field in OTP. As such, there is no way to identify the module type from software.
I am in the process of setting up a ‘registry’ and encouraging our partners to start programming those bits for exactly this reason. This will certainly be the case for new designs, and I will encourage assigning boardtypes to new production of current designs.
Unfortunately the MM6108 is inconvenient to program in the field. The OTP programming must be done with VDDIO at 2.5V.
Thanks Zandr… great info!
I noticed morse_cli has an otp write method but I had not tried it… I guess it won’t work then with VDDIO=3.3V.
That is a difficulty, especially as there could be card vendors such as us with a design that supports a resistor loading option for VDDFEM of 3.3V vs 5.0V which requires a different BCF. Perhaps that’s the only reason for a different BCF per module however and the only reason I can think of to build a version of our card with VDDFEM=3.3V would be a minor cost reduction for those who don’t need that extra 1dBm of TX power.
The module I’m using also differs from the previous one I evaluated in that it has an external OSC requiring enable_ext_xtal_init=1. That would be another reason to have a unique board_id or even a bit in the OTP that specifies this.
Is there any permanent damage that could be done to the chip/module if the wrong BCF is loaded due to different vendor GPIO mappings?
|