WP Series AT Port, cm tool and all Cellular processes/interfaces documentation

I have to build the WP77 base image internally to satisfy SecureBoot requirements. I am currently running bitbake mdm9x28-image-minimal with the legato recips/layers to accomplish this. Upon loading the spk image using fwupdate, I have access to the cm tool but no formal documentation on it (just guides that reference it briefly). Also while i have AT Commands documented I do not see an TTY port that accepts AT commands.

I need the following:

  • Documentation on all the sub commands of the cm tool
  • Processes that relate to the cm tool
  • Interfaces to send AT commands (tty ports, etc.) and how to expose them
  • Internal processes that interpret the AT commands
  • AT or cm configurable parameters that are stored persistently and their location (IE: if I set a gpio to output and high, does this need to be done every boot? if not where is this info saved)

you can see here for cm tool

for the AT port, you can use /dev/ttyAT

/dev/ttyAT is not in /dev

It appears that /etc/init.d/confighw.sh needs to run in order to softlink /dev/ttysmd8 to /dev/ttyAT . This should have run at boot but did not. Manually running confighw.sh does fix this.

I have rebooted the WP7702 5 times and confighw.sh failed to run on all 5. How do i submit a bug report?

i can see this port /dev/ttyAT in my WP module
does this problem only happen to one module only?

You can contact distributor to report bug

I see the confighw.sh is scheduled to be called at boot, but it is not.

# ls -lh /etc/rcS.d/ | grep confighw
lrwxrwxrwx    1 root     root          21 Apr  5  2011 S03confighw.sh -> ../init.d/confighw.sh

does this problem only happen to one module only?

Is there any improvement on this faulty module if you erase the userapp partition?

How about using old FW? Does it help?

Here is what i know so far:

  • confighw.sh actually is being triggered at boot; however, ttyAT is not being added.
    • So inittab → /etc/init.d/rcS/etc/rcS.d/S03confighw.sh/etc/init.d/confighw.sh is working
  • running this script after boot successfully adds confighw.sh

This makes me think it is an early boot race condition, specifically I think the script is running before /dev/smd8 is created (a condition of adding ttyAT). I was planning on just modifying the script to confirm this theory; however, I have stumbled upon another issue. I cannot appear to edit confighw.sh either on board or in the yocto image.

When i edit the confighw.sh file on the device, I don’t see that change i made to it in the boot messages. When i edit the file in yocto and create a new image to push, the file appears unchanged.

Can you please tell me why both of these methods are ineffective? Is an overlay applied after boot? is confighw being read from a different partition?

When i edit the file in yocto and create a new image to push, the file appears unchanged.

you can see this:

does this problem only happen to one module only?

Is there any improvement on this faulty module if you erase the userapp partition?

How about using old FW? Does it help?

Happening with the two modules I have in my test environment. I think the main cause is that we have USB peripherals attached at boot which is keeping the kernel busy in early boot causing things to mount at a later time. Typically I would expect something like creating a symlink for a device to be a udev rule as they are more resilient against race conditions and not a startup script.

As far as editing confighw.sh to confirm this. I followed the procedure in the ‘Error after boot mangoh yellow’ page except i used fwupdate because I don’t have access to the swiflash usb port and it did not work.

Can you please explain the function of /mnt/flash/ufs/ and also what layer init.d is actually running from before the unionfs is applied?

I think that is kind of overlay concept

https://source.sierrawireless.com/resources/airprime/software/wp76xx/wp76xx-firmware-release-16,-d-,3-components/

Just like the legato application