lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Y1MxOYp1G1RLhrQc@arch-desk>
Date:   Fri, 21 Oct 2022 16:54:33 -0700
From:   Shane Parslow <shaneparslow808@...il.com>
To:     "Kumar, M Chetan" <m.chetan.kumar@...el.com>
Cc:     netdev@...r.kernel.org
Subject: Re: [PATCH net] net: wwan: iosm: Fix 7360 WWAN card control channel
 mapping

On Fri, Oct 21, 2022 at 02:04:37PM +0000, Kumar, M Chetan wrote:
> > -----Original Message-----
> > From: Shane Parslow <shaneparslow808@...il.com>
> > Sent: Wednesday, September 28, 2022 11:37 AM
> > To: Kumar, M Chetan <m.chetan.kumar@...el.com>
> > Cc: netdev@...r.kernel.org
> > Subject: Re: [PATCH net] net: wwan: iosm: Fix 7360 WWAN card control
> > channel mapping
> > 
> > On Tue, Sep 27, 2022 at 01:43:22PM +0000, Kumar, M Chetan wrote:
> > > > -----Original Message-----
> > > > From: Shane Parslow <shaneparslow808@...il.com>
> > > > Sent: Monday, September 26, 2022 9:35 AM
> > > > To: shaneparslow808@...il.com
> > > > Cc: Kumar, M Chetan <m.chetan.kumar@...el.com>; linuxwwan
> > > > <linuxwwan@...el.com>; Loic Poulain <loic.poulain@...aro.org>;
> > > > Sergey Ryazanov <ryazanov.s.a@...il.com>; Johannes Berg
> > > > <johannes@...solutions.net>; David S. Miller <davem@...emloft.net>;
> > > > Eric Dumazet <edumazet@...gle.com>; Jakub Kicinski
> > > > <kuba@...nel.org>; Paolo Abeni <pabeni@...hat.com>;
> > > > netdev@...r.kernel.org; linux- kernel@...r.kernel.org
> > > > Subject: [PATCH net] net: wwan: iosm: Fix 7360 WWAN card control
> > > > channel mapping
> > > >
> > > > This patch fixes the control channel mapping for the 7360, which was
> > > > previously the same as the 7560.
> > > >
> > > > As shown by the reverse engineering efforts of James Wah [1], the
> > > > layout of channels on the 7360 is actually somewhat different from that
> > of the 7560.
> > > >
> > > > A new ipc_chnl_cfg is added specifically for the 7360. The new
> > > > config updates channel 7 to be an AT port and removes the mbim
> > > > interface, as it does not exist on the 7360. The config is otherwise
> > > > left the same as the 7560. ipc_chnl_cfg_get is updated to switch between
> > the two configs.
> > > > In ipc_imem, a special case for the mbim port is removed as it no
> > > > longer exists in the 7360 ipc_chnl_cfg.
> > > >
> > > > As a result of this, the second userspace AT port now functions
> > > > whereas previously it was routed to the trace channel. Modem crashes
> > > > ("confused phase", "msg timeout", "PORT open refused") resulting
> > > > from garbage being sent to the modem are also fixed.
> > >
> > > Trace channel is mapped to 3rd entry.
> > >
> > > /* Trace */
> > > { IPC_MEM_CTRL_CHL_ID_3, IPC_MEM_PIPE_6, IPC_MEM_PIPE_7,
> > >   IPC_MEM_TDS_TRC, IPC_MEM_TDS_TRC,
> > IPC_MEM_MAX_DL_TRC_BUF_SIZE,
> > >   WWAN_PORT_UNKNOWN },
> > >
> > > I cross checked by running AT test on 7360. Both ports are functional as
> > expected.
> > > We should be able to send or receive AT commands with existing below
> > config.
> > >
> > > /* IAT0 */
> > > { IPC_MEM_CTRL_CHL_ID_2, IPC_MEM_PIPE_4, IPC_MEM_PIPE_5,
> > >   IPC_MEM_MAX_TDS_AT, IPC_MEM_MAX_TDS_AT,
> > IPC_MEM_MAX_DL_AT_BUF_SIZE,
> > >   WWAN_PORT_AT },  -----------> wwan0at0
> > >
> > > /* IAT1 */
> > > { IPC_MEM_CTRL_CHL_ID_4, IPC_MEM_PIPE_8, IPC_MEM_PIPE_9,
> > >   IPC_MEM_MAX_TDS_AT, IPC_MEM_MAX_TDS_AT,
> > IPC_MEM_MAX_DL_AT_BUF_SIZE,
> > >   WWAN_PORT_AT }, ------------> wwan0at1
> > >
> > > Does this second AT port (wwan0at1) goes bad at some point or is
> > > always not functional/modem crashes sooner we issue AT command ?
> > >
> > > Could you please help to check the modem fw details by running below
> > command.
> > > at+xgendata
> > 
> > Upon further investigation, it looks like the modem crashes only occur after
> > S3 sleep, and are likely a different issue that this patch does not fix. Sorry for
> > the confusion.
> > 
> > I say that the channels are mapped incorrectly because upon opening
> > wwan0at0, I recieve "+XLCSINIT: UtaLcsInitializeRspCb received result = 0",
> > and no response to AT commands. The behavior I would expect, and the
> > behavior I get after applying the patch, is normal responses to AT commands
> > in the same way as wwan0at1 pre-patch.
> > 
> > To be clear, my patch points wwan0at0 to channel 4, and wwan0at1 to
> > channel 7. I have perhaps been ambiguous with the terms I have been using.
> 
> I cross checked the channel mapping. It is proper.
> In the present implementation 2 AT port are enabled and are mapped to channel 2 & 4.
> 
> 	/* IAT0 */
> 	{ IPC_MEM_CTRL_CHL_ID_2, IPC_MEM_PIPE_4, IPC_MEM_PIPE_5,
> 	  IPC_MEM_MAX_TDS_AT, IPC_MEM_MAX_TDS_AT, IPC_MEM_MAX_DL_AT_BUF_SIZE,
> 	  WWAN_PORT_AT },
> 
> 	/* IAT1 */
> 	{ IPC_MEM_CTRL_CHL_ID_4, IPC_MEM_PIPE_8, IPC_MEM_PIPE_9,
> 	  IPC_MEM_MAX_TDS_AT, IPC_MEM_MAX_TDS_AT, IPC_MEM_MAX_DL_AT_BUF_SIZE,
> 	  WWAN_PORT_AT },
> 
> The channel 7 you are mapping to wwanat1 is an additional AT channel which we have not mapped to/enabled by default.
> 
> I flashed the same version of FW (1920) on my setup and I see both the AT ports are functional as expected. If mapping was not 
> proper channel would not have returned response to any AT commands and the reason why you are seeing "+XLCSINIT:" is, 
> in that version of modem FW the GNSS module is returning UNSOL command on initialization. This was fixed in later fw.
> 
> But one issue I noticed is, modem is crashing in S3 sleep. This issue is also not observed with latest modem fw.
> 
> > 
> > To recap:
> > -- The modem crashes are likely an unrelated issue.
> > -- wwan0at0 is currently unresponsive to commands, and outputs
> >    "+XLCSINIT...", but responds normally post-patch.
> > 
> > AT+XGENDATA returns the following:
> > +XGENDATA: "XG736ES21S5E20NAMAV2DEFA19223101408
> > M2_7360_XMM7360_REV_2.1_RPC_NAND 2019-May-29 11:40:45
> > *XG736ES21S5E20NAMAV2DEFA19223101408__M.2_7360_MR2_01.1920.00
> > *"
> > "*"
> > "FAB-CODE:7*SDRAMVendor=0x08 (Winbond), SDRAMRevision=0x0000"
> > 
> > I don't see any firmware updates online.

Looks like my vendor's firmware is a bit behind upstream. Thanks for bearing
with me.

On another note, what would your opinions be on exposing the RPC interface
to userspace? My understanding is that the 7360 does not have an MBIM
interface, so configuration via RPC is required to bring up the modem.

Is an MBIM interface added in a later firmware version? Are there problems
with this approach?

It seems to me that this would be the last step in making the 7360 usable.

I'm imagining something along the lines of adding a WWAN_PORT_RPC to
wwan_core.c and updating iosm_ipc_chnl_cfg.c

Such an interface should be able to work with the existing xmm7360-pci
tool.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ