Cannot reset Conduit mLinux

[Marta Soncodi]

I am following reset procedure described here:
http://www.multitech.net/developer/products/conduit/resetting-the-device/

Short reset does not cause reboot. Long reset (>5sec) does not have any effect either. The Conduit is stuck in a loop waiting for internet connection, serial PuTTY connection reports:

No internet connection, waiting...
No internet connection, waiting...
No internet connection, waiting...

I don’t know what settings to provide so I want to reset the Conduit to factory defaults. I appreciate any suggestions you may have.

[Marta Soncodi]

Stopped autoboot and got a bit more info:

U-Boot> printenv 
baudrate=115200
bootargs=mem=256M console=ttyS0,115200 root=/dev/mtdblock8 ro rootfstype=jffs2
bootcmd=nboot.jffs2 ${loadaddr} 0 ${kernel_addr}; bootm ${loadaddr}
bootdelay=0
ethact=macb0
ethaddr=00:08:00:4a:17:9c
hostname=AT91SAM9G25
ipaddr=192.168.2.1
kernel_addr=0x200000
loadaddr=0x22000000
netmask=255.255.255.0
serverip=192.168.2.2
stderr=serial
stdin=serial
stdout=serial

[Jeff Hatch]

Marta,

Have you installed any packages such as a third party LoRa server or anything. This looks like an init script is hanging the boot sequence waiting for an Internet connection. Is the Conduit configured and connected to a network with Internet access?

Jeff

[John Klug]

If you wish to re-flash your mLinux firmware using u-boot, take a look here:

Flashing mLinux Firmware

This can put the system back to defaults.

You will need to know what level of mLinux you were using so that you download the appropriate images, or if you wish, you may use the latest firmware (3.3.6). The instructions are for using minicom as a TTY program, and you will need a tftp server.

[Marta Soncodi]

Jeff, I have indeed installed TTN LoRa and mp-packet-forwarder is likely waiting for network access.

I had started the “Getting started with mLinux” procedure http://www.multitech.net/developer/software/mlinux/getting-started-with-conduit-mlinux/ and reconfigured for DHCP then conduit got stuck waiting for connection.

At this point changing ipaddress and serverip does not seem to help. Ex. router.us.thethings.network = 13.66.213.36.

Any suggestions on what I might use for ipaddress and serverip to avoid re-flashing the Conduit?

[Marta Soncodi]

John, thank you for the re-flash info. mLinux version is 3.2.0 but I may as well use 3.3.6 when re-flashing. (Will use SCP and Tftp32 from softpedia.)

[Jeff Hatch]

Marta,

The process that handles the reset must not be getting started before the TTN LoRa and mp-packet-forwarder is started and waiting in the foreground for an Internet connection. It would be really helpful to know when in the init sequence that package puts it’s init script. I have heard other people have this same problem. The only way I know how to get out of this for sure is to re-install the mLinux firmware from u-boot. Directions for how to do this can be found at (under Using U-boot & TFTP):

Flashing mLinux Firmware

If you get back to installing the TTN stuff, check and see where in the ordering the init script got installed in the rc5.d run level directory. As I said, other people have run into the same issue, and it would be nice to see if there is anything that can be done to keep it from happening more.

Thanks,

Jeff

[Marta Soncodi]

Here is the init section:

INIT: Entering runlevel: 5
Configuring network interfaces... IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
done.
Starting system message bus: dbus.
macb f802c000.ethernet eth0: link up (100/Full)
IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Starting OpenBSD Secure Shell server: sshd
done.
Starting syslogd/klogd: done
Loading [g_serial]
g_serial gadget: Gadget Serial v2.4
g_serial gadget: g_serial ready
lighttpd: disabled in /etc/default
Starting Mosquitto...
lora-network-server: disabled in /etc/default
Starting crond: OK
Found MTAC-LORA-915 with MTAC-LORA-1.0 hardware
No internet connection, waiting...
No internet connection, waiting...

I appreciate the help as I do need to understand how to properly configure and recover the conduit.

[Marta Soncodi]

Attempting to re-flash in u-boot, not sure which command I should use to transfer the 2 files:

U-Boot> tftpboot oe_uImage.bin
macb0: PHY present at 0
macb0: link up, 100Mbps full-duplex (lpa: 0xcde1)
Using macb0 device
TFTP from server 192.168.2.99; our IP address is 192.168.2.1
Filename 'oe_uImage.bin'.
Load address: 0x22000000
Loading: T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T
Retry count exceeded; starting again
macb0: PHY present at 0
macb0: link up, 100Mbps full-duplex (lpa: 0xcde1)
Using macb0 device
TFTP from server 192.168.2.99; our IP address is 192.168.2.1
Filename 'oe_uImage.bin'.
Load address: 0x22000000
Loading: T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T
Retry count exceeded; starting again

using tftp boot does not make sense since oe_rootfs.jffs2 needs to be transferred too…

Read this too, but did not clarify which command I should use: http://www.multitech.net/developer/forums/topic/connection-refused-after-auto-fash/

[Marta Soncodi]

Looked at NAND Flash Layout again and these need to happen:

0x00200000 oe_uImage.bin
0x01800000 oe_rootfs.jffs2

I guess nand could prepare for nboot but… cannot find manual or documentation for this.

[Marta Soncodi]

Ooops… missed this http://git.multitech.net/cgi-bin/cgit.cgi/meta-multitech.git/plain/contrib/uboot-setenv-mtcdt.minicom

Need to figure-out how to input all those lines without minicom.

[John Klug]

This output is usually indicative of a bad ethernet connection:

TFTP from server 192.168.2.99; our IP address is 192.168.2.1
Filename ‘oe_uImage.bin’.
Load address: 0x22000000
Loading: T T T T T T T T T T

You might want to try to use the U-Boot ping command, and recheck your tftp server.

[Marta Soncodi]

You are right:

U-Boot> ping 192.168.2.2
macb0: PHY present at 0
macb0: link up, 100Mbps full-duplex (lpa: 0xcde1)
Using macb0 device
ping failed; host 192.168.2.2 is not alive
U-Boot>

Problem is that in tftp server I only have access to 127.0.0.0.1 (loopback). 192.168.2.2 is dimmed and I cannot select it.

[Marta Soncodi]

At this point ping shows ‘host 192.168.2.2 is alive’.
Also, I enabled tftp client on my laptop and verified I can transfer both files via tftpd64.

run krb still does not work:

U-Boot> run krb
macb0: PHY present at 0
macb0: link up, 100Mbps full-duplex (lpa: 0xcde1)
Using macb0 device
TFTP from server 192.168.2.2; our IP address is 192.168.2.1
Filename 'oe_uImage.bin'.
Load address: 0x20000000
Loading: T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T
Retry count exceeded; starting again
macb0: PHY present at 0
macb0: link up, 100Mbps full-duplex (lpa: 0xcde1)
Using macb0 device
TFTP from server 192.168.2.2; our IP address is 192.168.2.1
Filename 'oe_uImage.bin'.
Load address: 0x20000000
Loading: T T T T

I turned on/off ‘Option negotiation’ in tftpd64 and it makes no difference.

[Marta Soncodi]

My mLinux Conduit is alive again.

I used tftpd64 from: http://www.softpedia.com/get/Internet/Servers/FTP-Servers/Tftpd32.shtml

A more recent version can be downloaded here:https://tftpd64.codeplex.com/
They even make available the source code: https://tftpd64.codeplex.com/SourceControl/latest#readme.txt

Of course, these downloads come with the risk of untrusted sources.

The more important piece of information for Windows users is that reading the minicom information alone does not give the full answer. TeraTerm and its Control > Macro functionality can be used to set the environment variables in U-boot, using the minicom script referred at http://www.multitech.net/developer/software/mlinux/using-mlinux/flashing-mlinux-firmware-for-conduit/
The actual re-flashing is done by TeraTerm with files being uploaded via tftpd64.

It would be nice if the TeraTerm and equivalent minicom macro information would be available on the main site.

I also verified reset and long reset work again.

• This reply was modified 7 years ago by Marta Soncodi.
• This reply was modified 7 years ago by Marta Soncodi.
• This reply was modified 7 years ago by Marta Soncodi.

[Jeff Hatch]

Marta,

Glad to hear you got it working. Thank you for the info and suggestions.

Jeff

[Marta Soncodi]

Thank you for the support!

Regards,
Marta Soncodi

[johann van Niekerk]

Im Sitting in the same boat! mind doing a step by step guide? I have tried but you lost me minicom. and downloading the file from git. everytime i click on the click is shows the content of the file and not download option.

[John Klug]

To download the minicom script from most web browsers, after bringing up the page do <File>, <Save Page as> or possibly <Ctrl>S.

In Minicom, while logged into U-Boot, execute the minicom control character (usually CTRL-A), followed by <G>. Up should pop a menu with items A, B, and C. Then type <C> (name of script selection), and enter the path of the minicom script, then type <enter>. The minicom script should now execute, which will put the flash commands into the U-Boot environment.

• This reply was modified 7 years ago by John Klug.
• This reply was modified 7 years ago by John Klug.

[johann van Niekerk]

Hi John

Thank you for the reply, I contacted tech support and they helped me with the reset procedure. up and running now

[Jac Kersing]

As the maintainer of the mp_pkt_fwd software I just happen to stumble onto this thread. I’m wondering why no-one bothered to log an issue on github if this happens to multiple users. I can’t solve issues that I’m not aware of.

FYI, the start script is at S95. Tested and working on mLinux 3.1.0 for months with multiple reboots. However I will change the startup to work in another way to resolve this.

• This reply was modified 6 years, 12 months ago by Jac Kersing.

[Jac Kersing]

For the record, I just pushed a new installer and package for the TTN mp-forwarder that resolves the wait for internet connection on boot issue.

[Jeff Hatch]

Jac,

There are multiple third party packet forwarders and network servers that people are installing on their Conduits. This is one of the first times that anyone has actually come out and said what package they were installing that was causing their boot issue. When designing init scripts, they should not block or retry anything indefinitely.

The process that handles reboots isn’t started until after your software was being started. Thus, the issue with the hang and inability to process the reset button presses. While not a desirable architecture, it has been that way for some time. This will be addressed in the future.

Thank you for updating your package to resolve the boot issue.

Jeff

[Author]

Posts