UART name per legato version / FX30 version

Hi, I have code that builds to different FX30 modems and with different versions of legato. The name for the uart seems to change from device to device and legato version.

How can I work out what dev name I should be using per device/legato version? I need to build it into my build system.

I have now got ttyHS0, ttyHSL0 and ttyMSM0

I thought it was just the legato version that determined this, but now I am not sure.

I am building for FX30S modems with wp85, wp76xx and wp77 modules…

Can someone help please?

You need to have a list to match with different module and firmware

Yes, but what is that list… what version of what FW causes the change in naming? I know that the following guide suggest a change to the MSMx naming Linux 4.14 Migration Guide - Legato Docs… but what about the other naming differences… HS0 and HSL0?

Does this help?

It depends on at!mapuart setting

Yes I am aware of mapuart. AT!MAPUART? return 17,0…

for some reason I have the same problem descripbed in the link. only ttyHS0 is available in /dev/ not /ttyHSLO

Any ideas how I revert it back. I assumed my problem was with FW versions… but maybe this device has got itself in a mess…

dmesg | grep tty give me the below

[    0.000000] Kernel command line: console=ttyHSL0,115200 console=ttyHSL1,115200 root=/dev/ram rootfs_ro=true user1_fs=ubifs verity=on ima_ready=0 lkversion=1.3.0_482d4b1057 androidboot.serialno=5d8bf338 androidboot.authorized_kernel=true quiet androidboot.baseband=msm rootfstype=ubifs rootflags=bulk_read
[    0.574929]  uart_func_init(), line=0, uart_type=1, uart_func=17<6>[    0.574938] ttyHS0 could be used as generic serial port.
[    0.578182] 78b0000.uart: ttyHS0 at MMIO 0x78b0000 (irq = 49, base_baud = 460800) is a MSM HS UART
[    0.580612]  uart_func_init(), line=1, uart_type=1, uart_func=0<6>[    0.580621] ttyHS1 is disabled.
[    0.581398]  uart_func_init(), line=1, uart_type=0, uart_func=0<6>[    0.581407] ttyHSL1 is disabled.
[    0.581663]  uart_func_init(), line=0, uart_type=0, uart_func=0<6>[    0.581672] ttyHSL0 is disabled.

You’ll see the only ttyHS0 is set as a generic serial port…

I found this in the latest user guide (update 2 weeks ago)… which suggest something has gone wrong with port mappings… I have never put it into the mode 15… so not sure how it has gone wrong…

o set:
• can be:
0—UART disabled
1—AT Command service (Note: Not available for UART 2)
2—Diagnostic Message service
4—NMEA service
14—RS-485 Linux application (Note: Not available for UART 2)
Note: Option 14 is only available in release FX30S 3G R14.0.2.001 or
later. Option 14 uses /dev/ttyHSL0 driver. As well, RS-485 will be enabled
automatically upon startup.
1**5—RS232 with Hardware Flow control: **
· Linux application (UART 1)
**Note: Option 15 is only available in release FX30S 3G R14.0.2.001 or **
later. Option 15 uses /dev/ttyHS0 driver. However, option 17 uses /dev/
**ttyHSLx driver, where x is the UART number. As well, RS232 with flow **
control will be enabled automatically upon startup.
16—Linux console
17—Customer Linux application
• can be:
1—UART 1 (Default if UART number is not specified)
2—UART 2
Value returned: OK

I remember I tried this before:

FX30(WP77 inside) (FW: R14)
AT!MAPUART=17,1 → /dev/ttyHSL0
AT!MAPUART=15,1 → /dev/ttyHS0

Yes I know that is what the documentation I linked above says. But that is NOT what is happening on my module. It is going to AT!MAPUART=17,1 → /dev/ttyHS0 when it should rather be AT!MAPUART=17,1 → /dev/ttyHSL0 according to the docs… so something is not right on my module.

I have tried flashing the stock image… no change. I have tried factory resetting… no change…

Is it possible the config on the device has been changed/ corrupted. Can I get it back to the factory state… How do I achieve that?

are you using the WP7607 which having old memory with the official R14.1 full imge instead of the yocto image built by yourself?

No this is the WP7611-1 module

I have two running… one is correct and using HSL0… but this one is somehow got itself stuck on HS0… I am sure it used to work with HSL0… I wonder if all the attempts of getting FW download to work has caused some conflicts with version changes etc…

Also it is notable that if I configure “UART1” with the AT service, Linux console or DM port… I get no data from the device over the serial port… I used to get debug message if set to LINUX console… it is now dead…

So I think something has happened to the mapping in LINUX…

are you using the yocto image built by yourself?

if you have one OK WP7611 and one NOK WP7611, have you compared ati3 and ati8 to figure what makes the difference?

As mentioned above I’ve put on the stock FW… so not mine… I did have mine on… but tried all the default stuff…

THE NOK WP7611-1

Manufacturer: Sierra Wireless, Incorporated
Model: FX30(WP7611-1)
Revision: SWI9X07Y_02.37.03.00 73df45 jenkins 2020/04/08 10:59:14
IMEI: 352588320135500
FSN: ZW251730830610

Legato Ver:
Yocto Ver:  SWI9X07Y_02.37.07.00 2023-03-06_12:27:27
OS Ver: Linux version 3.18.140 (oe-user@oe-host) (gcc version 7.3.0 (GCC) ) #1 PREEMPT Mon Mar 6 11:54:33 UTC 2023
LK Ver: 1.3.0_482d4b1057
RootFS Ver: SWI9X07Y_02.37.07.00 2023-03-06_12:27:27
UserFS Ver: unknown
MCU Ver: unknown


THE OK WP7611-1

Manufacturer: Sierra Wireless, Incorporated
Model: FX30S(WP7611-1)
Revision: SWI9X07Y_02.37.06.00 b91e64 jenkins 2020/06/02 00:54:15
IMEI: 352588320137118
FSN: ZW252431020510

Legato Ver: 19.11.5.cdc94bb9_fa5a606a7dc8c397dd98e6abdb975bac
Yocto Ver:  SWI9X07Y_02.37.10.02 2022-02-17_11:09:54
OS Ver: Linux version 3.18.140 (oe-user@oe-host) (gcc version 7.3.0 (GCC) ) #1 PREEMPT Thu Feb 17 11:02:54 UTC 2022
LK Ver: 1.3.0_482d4b1057
RootFS Ver: SWI9X07Y_02.37.10.02 2022-02-17_11:09:54
UserFS Ver: unknown
MCU Ver: unknown

all version (modem, legato, yocto) are different…
You need to isolate different factors to see which component makes the problem…

I guess the yocto version “SWI9X07Y_02.37.10.02” is working fine to enumerate the correct UART device node.
And it should be given by your distributor as mentioned here:

I got it to work again… by flashing not the stock FW, but the intermediate one you linked above…

At this point the mapping was still wrong… but I changed the mode to


then rebooted and ran


then rebooted

then my mapping as correct again…