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] [thread-next>] [day] [month] [year] [list]
Message-Id: <YT6HPS.1GNVHHJXEVF83@unrealasia.net>
Date: Fri, 03 Jan 2025 03:15:34 +0800
From: Muhammad Nuzaihan <zaihan@...ealasia.net>
To: Sergey Ryazanov <ryazanov.s.a@...il.com>
Cc: netdev@...r.kernel.org, Loic Poulain <loic.poulain@...aro.org>,
	Johannes Berg <johannes@...solutions.net>, Andrew Lunn <andrew@...n.ch>,
	Slark Xiao <slark_xiao@....com>
Subject: Re: [PATCH] Add NMEA GPS character device for PCIe MHI Quectel Module
 to read NMEA statements.

Hi Sergey,


On Fri, Jan 3 2025 at 02:05:19 AM +0800, Muhammad Nuzaihan 
<zaihan@...ealasia.net> wrote:
> Hi Sergey,
> 
> So there is a separate GNSS subsystem in the linux kernel. I'll check 
> that out.
> 
> I went through a bit of research to get this working. Went to quectel 
> forums to figure out and quectel has their own set of drivers. They 
> showed me their own source code and they have their own 
> implementation of their NMEA interface in their driver with port at 
> /dev/mhi_LOOPBACK.
> 
> But i was not quite happy because i have to use their connection 
> manager instead of ModemManager since i am using it for my Lenovo 
> laptop and not embedded which their software was designed for.
> 
> Went around /sys in the kernel and found:
> 
> root@...ammads-ThinkPad:/sys# find . -name 'mhi0*'
> ./devices/pci0000:00/0000:00:1c.6/0000:08:00.0/mhi0
> ./devices/pci0000:00/0000:00:1c.6/0000:08:00.0/mhi0/mhi0_DIAG
> ./devices/pci0000:00/0000:00:1c.6/0000:08:00.0/mhi0/mhi0_IP_HW0_MBIM
> ./devices/pci0000:00/0000:00:1c.6/0000:08:00.0/mhi0/mhi0_MBIM
> ./devices/pci0000:00/0000:00:1c.6/0000:08:00.0/mhi0/mhi0_NMEA
> ./devices/pci0000:00/0000:00:1c.6/0000:08:00.0/mhi0/mhi0_DUN
> ./bus/mhi/devices/mhi0
> ./bus/mhi/devices/mhi0_DIAG
> ./bus/mhi/devices/mhi0_IP_HW0_MBIM
> ./bus/mhi/devices/mhi0_MBIM
> ./bus/mhi/devices/mhi0_NMEA
> ./bus/mhi/devices/mhi0_DUN
> ./bus/mhi/drivers/mhi_wwan_mbim/mhi0_IP_HW0_MBIM
> ./bus/mhi/drivers/mhi_wwan_ctrl/mhi0_DIAG
> ./bus/mhi/drivers/mhi_wwan_ctrl/mhi0_MBIM
> ./bus/mhi/drivers/mhi_wwan_ctrl/mhi0_NMEA
> ./bus/mhi/drivers/mhi_wwan_ctrl/mhi0_DUN
> 
> So i figured it has mhi0_NMEA and that's how i thought of writing the 
> patch to expose mhi0_NMEA after reading some linaro guy's 
> presentation on MHI and his initial mhi0_QMI work with ModemManager.
The Linaro guy was Loic! Thank you. :) - 
https://static.linaro.org/connect/lvc21/presentations/lvc21-317.pdf
> 
> With my patch, on bootup, it doesn't automatically attach nmea0 port 
> at all, 5G works properly with modemmanager at boot but no nmea port.
> 
> To get that nmea0 port i had to unload all mhi_* and wwan modules and 
> load them back again to ensure wwan0nmea0 gets attached to /dev.
> 
> After that i run commands with quectel's own AT commands at wwan0at0 
> with AT+QGPS+1 and then AT+QGPSGNMEA="RMC" (also 
> AT+QGPSCFG="outport",usbnmea) and this starts the streaming of the 
> NMEA gps statements. If i don't run the AT commands, even 5G 
> connectivity with modemmananager do not work as well. After running 
> it, all NMEA streams starts to come and 5G connectivity works.
> 
> After that i would only run gpsd to read /dev/wwan0nmea0 (the port 
> can only be use/locked by one program) and run cgps (client gps) to 
> make nmea values more easier to read.
> 
> All this is stable, i have been running "cgps" program for hours 
> together with 5g on modemmanager and no issues. Just the above quirks 
> about unloading and loading of kernel modules and running AT commands 
> (i wrote a shell script to automate this)
> 
> I can try to help out as much as i can.
> 
> NMEA continous stream
> ---
> 
> Welcome to minicom 2.8
> 
> OPTIONS: I18n
> Port /dev/wwan0nmea0, 22:50:48
> 
> Press CTRL-A Z for help on special keys
> 
> $GPRMC,172551.00,A,0607.736155,N,10217.012565,E,0.0,,020125,0.4,W,A,V*74
> $GPRMC,172552.00,A,0607.736156,N,10217.012566,E,0.0,,020125,0.4,W,A,V*77
> $GPGGA,172553.00,0607.736156,N,10217.012566,E,1,07,0.4,15.0,M,-7.3,M,,*47
> $GPRMC,172553.00,A,0607.736156,N,10217.012566,E,0.0,,020125,0.4,W,A,V*76
> $GPGGA,172554.00,0607.736157,N,10217.012567,E,1,07,0.4,15.0,M,-7.3,M,,*40
> $GPRMC,172554.00,A,0607.736157,N,10217.012567,E,0.0,,020125,0.4,W,A,V*71
> ... continuously
> 
> 
> Regards,
> Zaihan
> 
> On Thu, Jan 2 2025 at 07:18:46 PM +0200, Sergey Ryazanov 
> <ryazanov.s.a@...il.com> wrote:
>> Hi Muhammad and welcome to netdev,
>> 
>> On 01.01.2025 23:12, Muhammad Nuzaihan wrote:
>>> Hi netdev,
>>> 
>>> I made a mistake in choosing AT mode IPC, which is incorrect. For 
>>> NMEA streams it should use LOOPBACK for IPC. If it uses AT, i 
>>> noticed that using gpsd will cause intermittent IOCTL errors 
>>> which is caused when gpsd wants to write to the device.
>>> 
>>> Attached is the patch.
>> 
>> Do you had a chance to check this discussion: 
>> https://lore.kernel.org/all/CAMZdPi_MF=-AjTaBZ_HxtwpbQK5+WwR9eXsSvnvK_-O30ff+Tw@mail.gmail.com/
>> 
>> 
I've read the discussion. Interesting that I had that i had the same 
thought of using AT interface to communicate with the NMEA.

There was a question about NMEA with MHI, not sure if what i did is 
identical to Slark's idea.


>> To summarize, an NMEA port suppose to be exported through the GNSS 
>> subsystem to properly indicate the device class. Still, the port 
>> needs to be exported through the WWAN subsystem to facilitate a 
>> corresponding control port discovery. Looks like that the WWAN 
>> changes going to be a bit more tricky.
>> 
Read about the GNSS subsystem, some really old article but it sounded 
it doesn't support all devices (and it only support dedicated GPS 
devices), not sure if there are improvements after that.

Should we be focusing on WWAN would be appropriate rather than 
duplicating work with GNSS?

The part that i am unsure is whether the MHI NMEA implementation i have 
currently supports features like showing a map of satellites like 
normal GPS hardware with Linux GNSS would and i don't see yet in my 
data.

Just for the start is to get the data like altitude, speed, mean sea 
level, climb rate, time, lat/lng - which i got.

I'll try to improve on my patches and see how i can load and fix the 
issues i encountered earlier.
>> 
>>> Thank you.
>>> 
>>> Signed-off-by: Muhammad Nuzaihan Bin Kamal Luddin 
>>> <zaihan@...ealasia.net>
>>> 
>>> On Thu, Jan 2 2025 at 02:34:03 AM +0800, Muhammad Nuzaihan 
>>> <zaihan@...ealasia.net> wrote:
>>>> Hi netdev,
>>>> 
>>>> I am using a Quectel RM520N-GL *PCIe* (not USB) module which uses 
>>>> the MHI interface.
>>>> 
>>>> In /devices/pci0000:00/0000:00:1c.6/0000:08:00.0/mhi0 i can see 
>>>> "mhi0_NMEA" but the actual NMEA device is missing in /dev and 
>>>> needs a character device to be useful with tty programs.
>>>> 
>>>> NMEA statements are a stream of GPS information which is used to 
>>>> tell the current device location in the console (like 
>>>> minicom).
>>>> 
>>>> Attached is the patch to ensure a device is registered (as /dev/ 
>>>> wwan0nmea0) so this device will stream GPS NMEA statements 
>>>> and can be used to be read by popular GPS tools like gpsd and 
>>>> then tracking with cgps, xgps, QGIS, etc.
>>>> 
>>>> Regards,
>>>> Muhammad Nuzaihan
>>>> 
>>>> Signed-off-by: Muhammad Nuzaihan Bin Kamal Luddin 
>>>> <zaihan@...ealasia.net>
>>>> 
>>> 
>> 



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ