Re: [PATCH v3] quectel: EC21 needs aux channel to be the first mux channel
Hi Lars, Unfortunately I must come back to this issue. I got hands on a few new EC21s here and guess what ? The mux order is back to the original one again. This means, the aux channel has to be the second channel. So I did a bit of investigation why and when this happened. But information is rare. The modems I originally worked on and created the patch for have Firmware EC21EFAR06A01M4G_BETA0318. (Reversed mux order) The new ones do have version EC21EFAR06A03M4G. (original mux order) I know that there was a version EC21EFAR02A02M4G that did not support cmux at all. Due to some Quectel Confidential Document in a firmware version "R02A03" some bug was fixed in cmux, so cmux must be in there since then. The EC21EFAR06A01M4G_BETA0318 that I have is dated inbetween EC21EFAR02A02M4G and this "R02A03". The mux order must have changed between EC21EFAR06A01M4G_BETA0318 and EC21EFAR06A03M4G. I suspect (without knowing for sure) due to the beta-nature of my firmware, that this is the only firmware with reversed mux order and that they changed it after that and "R02A03" up until EC21EFAR06A03M4G share the same original mux order. According to Quectel the EC21EFAR06A01M4G_BETA0318 firmware I have here is not "out in the wild". The modems I have here are the only ones with this firmware. So my question is what's best to do now ? I feel the best would be to revert this patch. I am very sorry for this. New modems will work and I suspect old modems "out in the wild" will work also. I don't care about supporting the few "BETA0318" modems I have here. I guess just send a revert patch with the reasons outlined in the commit description and I can take it. Another way would be to leave this patch and implement some firmware switch and use reversed mux order for the "BETA0318" only I have and use normal original mux order for all other cases. That would also be fine. Regards, -Denis ___ ofono mailing list -- ofono@ofono.org To unsubscribe send an email to ofono-le...@ofono.org
Re: [PATCH v3] quectel: EC21 needs aux channel to be the first mux channel
On Tue, May 26, 2020 at 10:22:46PM -0500, Denis Kenzior wrote: > Hi Lars, > > On 5/29/20 7:43 AM, poesc...@lemonage.de wrote: > > From: Lars Poeschel > > > > The Quectel EC21 does only work correctly, if the mux channel used for > > aux is the first mux channel. It does only put it's URC messages in the > > first mux channel, so this has to be the aux channel in our case. > > To be flexible on the mux order we introduce two arrays here, that then > > contain the initialization data in their needed order. > > Initialization data is then applied by for-looping over this array. > > --- > > plugins/quectel.c | 61 --- > > 1 file changed, 47 insertions(+), 14 deletions(-) > > > > Applied, thanks. Unfortunately I must come back to this issue. I got hands on a few new EC21s here and guess what ? The mux order is back to the original one again. This means, the aux channel has to be the second channel. So I did a bit of investigation why and when this happened. But information is rare. The modems I originally worked on and created the patch for have Firmware EC21EFAR06A01M4G_BETA0318. (Reversed mux order) The new ones do have version EC21EFAR06A03M4G. (original mux order) I know that there was a version EC21EFAR02A02M4G that did not support cmux at all. Due to some Quectel Confidential Document in a firmware version "R02A03" some bug was fixed in cmux, so cmux must be in there since then. The EC21EFAR06A01M4G_BETA0318 that I have is dated inbetween EC21EFAR02A02M4G and this "R02A03". The mux order must have changed between EC21EFAR06A01M4G_BETA0318 and EC21EFAR06A03M4G. I suspect (without knowing for sure) due to the beta-nature of my firmware, that this is the only firmware with reversed mux order and that they changed it after that and "R02A03" up until EC21EFAR06A03M4G share the same original mux order. According to Quectel the EC21EFAR06A01M4G_BETA0318 firmware I have here is not "out in the wild". The modems I have here are the only ones with this firmware. So my question is what's best to do now ? I feel the best would be to revert this patch. I am very sorry for this. New modems will work and I suspect old modems "out in the wild" will work also. I don't care about supporting the few "BETA0318" modems I have here. Another way would be to leave this patch and implement some firmware switch and use reversed mux order for the "BETA0318" only I have and use normal original mux order for all other cases. What do you think? Thank you, Lars ___ ofono mailing list -- ofono@ofono.org To unsubscribe send an email to ofono-le...@ofono.org
Re: [PATCH v3] quectel: EC21 needs aux channel to be the first mux channel
Hi Lars, On 5/29/20 7:43 AM, poesc...@lemonage.de wrote: From: Lars Poeschel The Quectel EC21 does only work correctly, if the mux channel used for aux is the first mux channel. It does only put it's URC messages in the first mux channel, so this has to be the aux channel in our case. To be flexible on the mux order we introduce two arrays here, that then contain the initialization data in their needed order. Initialization data is then applied by for-looping over this array. --- plugins/quectel.c | 61 --- 1 file changed, 47 insertions(+), 14 deletions(-) Applied, thanks. Regards, -Denis ___ ofono mailing list -- ofono@ofono.org To unsubscribe send an email to ofono-le...@ofono.org
[PATCH v3] quectel: EC21 needs aux channel to be the first mux channel
From: Lars Poeschel
The Quectel EC21 does only work correctly, if the mux channel used for
aux is the first mux channel. It does only put it's URC messages in the
first mux channel, so this has to be the aux channel in our case.
To be flexible on the mux order we introduce two arrays here, that then
contain the initialization data in their needed order.
Initialization data is then applied by for-looping over this array.
---
plugins/quectel.c | 61 ---
1 file changed, 47 insertions(+), 14 deletions(-)
diff --git a/plugins/quectel.c b/plugins/quectel.c
index 043d39f9..cb15e147 100644
--- a/plugins/quectel.c
+++ b/plugins/quectel.c
@@ -78,6 +78,27 @@ static const uint8_t gsm0710_terminate[] = {
0xf9, /* close flag */
};
+enum mux_type {
+ QUECTEL_MUX_TYPE_AUX = 0,
+ QUECTEL_MUX_TYPE_MODEM,
+ QUECTEL_MUX_TYPE_MAX,
+};
+
+struct mux_initialization_data {
+ enum mux_type mux_type;
+ char *chat_debug;
+ const char *n_gsm_key;
+ const char *n_gsm_value;
+};
+
+static const struct mux_initialization_data mux_order_default[] = {
+ { QUECTEL_MUX_TYPE_MODEM, "Modem: ", "Modem", "/dev/gsmtty1"},
+ { QUECTEL_MUX_TYPE_AUX, "Aux: ", "Aux", "/dev/gsmtty2"} };
+
+static const struct mux_initialization_data mux_order_ec21[] = {
+ { QUECTEL_MUX_TYPE_AUX, "Aux: ", "Aux", "/dev/gsmtty1"},
+ { QUECTEL_MUX_TYPE_MODEM, "Modem: ", "Modem", "/dev/gsmtty2"} };
+
enum quectel_model {
QUECTEL_UNKNOWN,
QUECTEL_UC15,
@@ -106,6 +127,7 @@ struct quectel_data {
struct l_timeout *init_timeout;
size_t init_count;
guint init_cmd;
+ const struct mux_initialization_data *mux_order;
};
struct dbus_hw {
@@ -838,6 +860,7 @@ static GAtChat *create_chat(struct ofono_modem *modem, char
*debug)
static void cmux_gatmux(struct ofono_modem *modem)
{
struct quectel_data *data = ofono_modem_get_data(modem);
+ GAtChat *chat;
DBG("%p", modem);
@@ -853,18 +876,21 @@ static void cmux_gatmux(struct ofono_modem *modem)
g_at_mux_start(data->mux);
- data->modem = create_chat(modem, "Modem: ");
- if (!data->modem) {
- ofono_error("failed to create modem channel");
- close_serial(modem);
- return;
- }
+ for (int i = 0; i < QUECTEL_MUX_TYPE_MAX; i++) {
+ chat = create_chat(modem, data->mux_order[i].chat_debug);
+
+ if (!chat) {
+ ofono_error("failed to create %schannel",
+ data->mux_order[i].chat_debug);
+ close_serial(modem);
+ return;
+ }
+
+ if (data->mux_order[i].mux_type == QUECTEL_MUX_TYPE_AUX)
+ data->aux = chat;
+ else
+ data->modem = chat;
- data->aux = create_chat(modem, "Aux: ");
- if (!data->aux) {
- ofono_error("failed to create aux channel");
- close_serial(modem);
- return;
}
setup_aux(modem);
@@ -880,7 +906,9 @@ static void mux_ready_cb(struct l_timeout *timeout, void
*user_data)
DBG("%p", modem);
/* check if the last (and thus all) virtual gsm tty's are created */
- ret = stat(ofono_modem_get_string(modem, "Modem"), );
+ ret = stat(ofono_modem_get_string(modem,
+ data->mux_order[QUECTEL_MUX_TYPE_MAX - 1].n_gsm_key),
+ );
if (ret < 0) {
if (data->mux_ready_count++ < 5) {
/* not ready yet; try again in 100 ms*/
@@ -957,8 +985,10 @@ static void cmux_ngsm(struct ofono_modem *modem)
* the kernel does not yet support mapping the underlying serial device
* to its virtual gsm ttys, so hard-code gsmtty1 gsmtty2 for now
*/
- ofono_modem_set_string(modem, "Modem", "/dev/gsmtty1");
- ofono_modem_set_string(modem, "Aux", "/dev/gsmtty2");
+ for (int i = 0; i < QUECTEL_MUX_TYPE_MAX; i++) {
+ ofono_modem_set_string(modem, data->mux_order[i].n_gsm_key,
+ data->mux_order[i].n_gsm_value);
+ }
/* wait for gsmtty devices to appear */
if (!l_timeout_create_ms(100, mux_ready_cb, modem, NULL)) {
@@ -1014,6 +1044,8 @@ static void cgmm_cb(int ok, GAtResult *result, void
*user_data)
return;
}
+ data->mux_order = mux_order_default;
+
if (strcmp(model, "UC15") == 0) {
DBG("%p model UC15", modem);
data->vendor = OFONO_VENDOR_QUECTEL;
@@ -1030,6 +1062,7 @@ static void cgmm_cb(int ok, GAtResult *result, void
*user_data)
DBG("%p model EC21", modem);
data->vendor = OFONO_VENDOR_QUECTEL;
data->model = QUECTEL_EC21;
+
