LoRa® Server: TTN via LoRaGateway_1.1.0062_Release_r202
Details:
Had a 7258 for around 10 months, which has been working fine connecting to TTN on the original software. After updating the firmware to the latest version (was on supplied version ~ 10 months old) I no longer get a connection to the gateway on the LAN or WLAN. I do not see a DHCP request on my router, but I do see an activity light on the LAN.
The firmware was downloaded and unzipped, then uploaded to the gateway. The Gateway went through the install process, but after it rebooted itself, there is no contact. On power up the PWR LAN and WLAN lights are lit for a few seconds before the LAN and WLAN LEDs turn off.
I have tried a short and long reset, with no obvious effect. Is it possible to update the firmware via the USB or SD card interfaces? What is the pinout of the console port?
This might be a dumb question but it might have reset to factory defaults, so can you still see the AP, so you can connect to it via Wi-Fi? This should be one way to do it if for some reason the DHCP is not assigning an address to it.
Flashing via the Console port is possible, but also might further brick it so let’s stay away from it for now
Hi Vladislav,
Thanks for the reply, not a dumb question at all. This was my thought as well after I failed to connect, but I’m not seeing any sign of an AP coming up.
I also tried connecting to the default 192.168.230.1 address via the LAN with no success. Wireshark doesn’t seem to show any obvious network address when I monitor the LAN port.
When I perform a short or long reset, I don’t see any change in the LED pattern (only power lit) and no sign of any change in network status.
Before the update, the system was working fine on my WLAN, and sending packets to TTN. When I started the update I selected the ‘keep settings’ option. I was hoping a long reset would return me to the default settings, and the default AP, but no luck so far.
If you have the console pinout I could at least try monitoring the system startup. At this point I don’t known if it is managing to partly boot up or not. Does the WLAN/LAN light coming on and then going off again after 3-4 seconds tell us anything useful?
Apologies for not being of much help as it seems you havea lready done what I would have.
Perhaps you could do the following:
You would need an RS232 cable to plug into the Console port and whatever interface you have on the other end. I myself use an Serial to USB cable (has a built in converter) as I only have USB ports on my machine.
Upon resetting the Gateway you should see activity if you connect to it via the RAK serial tool (are you familiar with it). Not sure of the Baud rate, should be either 115200 or 9600. Worst case you will see gibberish symbols, meaning that it is probably loading something and you need to try a different one.
If it manages to boot you will see the output. If there is nothing than it is dead mate
Hi again,
Yes, I would be very happy to try this.I have just downloaded the tool. Do you know where the pinout of the RJ45 console port is documented? And is this RS232 levels (±12v) or TTL/3.3v signals?
I’m really hoping it isn’t dead, as this is first time I have tried to update it, and getting a new one to Iceland is expensive…
Hi. The console port is TTL. Please try to connect with LAN cable between the Gateway and PC and follow this instruction : The default IP is 169.254.X.X . The last two segments(X.X) are mapped from the last four bits of the MAC address of your gateway. For example, the last four bits of the MAC address are 0F:01, and the IP address is 169.254.15.1. Make sure to manually set the address of your PC to one in the same network (for example 169.254.15.100). Use the same credentials for the Web UI as for AP mode. And try to access it on that IP 169.254.x.x.
Hi Todor,
Many thanks for this. I’ll try this as soon as I get back to site this evening…
Just in case I need it, do you have the pinout for the RJ45 console port? There seems to be no ‘standard’ pinout for console ports…
Actually the external console port on the RJ45 uses RS232 levels provided by U9 which is a line driver/receiver.
However, if you open the case then the J15 near the processor module has the same signals at 3v3 levels. The difference is not only in voltage range, but the two versions are inverted with respect to each other.
Mine no longer has stock firmware so I’m not sure of the behavior of that, but the traditional baud rate for MT76x8 systems is 57600 so I’d try that as well as 115200.
I’ve heard it suggested (but cannot confirm) that the RJ45 pinout is the same as that of Cisco networking gear. What I’d personally do is get a common ground with the PC perhaps from the USB port, and then simply try connecting the USB-serial cable’s receive data line to each pin of the RJ45 in turn while rebooting the gateway and looking for startup messages from U-Boot or OpenWRT. A scope would make this even faster.
Hi Chris,
Many thanks for the info. I was guessing a Cisco cable pinout was likely, but I like your scope idea best. I’ll get probing if I don’t have any luck with the Ethernet connection. This will also clearly show me what voltage levels I have before I connect a serial USB dongle. I should have RS232 and ttl converters somewhere in the bits box.
Hi again,
Ok, so some progress…
No luck on the default IP - Unable to get any response
Serial console - Comms seems to be using a cisco-like pinout, and I can seen a boot log.
## Booting image at bc050000 …
Image Name: MIPS OpenWrt Linux-3.18.45
Image Type: MIPS Linux Kernel Image (lzma compressed)
Data Size: 1195136 Bytes = 1.1 MB
Load Address: 80000000
Entry Point: 80000000
Verifying Checksum … OK
Uncompressing Kernel Image … OK
No initrd
## Transferring control to Linux (at address 80000000) …
## Giving linux memsize in MB, 128
After what looks like a normal startup, we start to see some memory issue, as the system reports several filesystem errors
jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x008e0008: 0x00c1 instead
And finally ends with a kernel panic
[37.420000] jffs2: notice: (1) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found.
[ 37.450000] VFS: Mounted root (jffs2 filesystem) readonly on device 31:5.
[ 37.460000] Freeing unused kernel memory: 192K (80340000 - 80370000)
[ 37.470000] Kernel panic - not syncing: No working init found. Try passing init= option to kernel. See Linux Documentation/init.txt for guidance.
[ 37.470000] —[ end Kernel panic - not syncing: No working init found. Try passing init= option to kernel. See Linux Documentation/init.txt for guidance.
[ 93.950000] random: nonblocking pool is initialized
I have not dug too deep, but there seems to be an option to boot via TFTP, could I use this to try and load firmware?
Probably. You might see the Linkit Smart 7688 docs for guidance on doing so. I know I’ve done it with other MT76x8 systems. You can also do it over the serial port though it will take approximately a year.
At this point you’re about as soft-bricked as you are likely to get, ie, U-Boot works but the Linux partition is bad. You probably aren’t going to mess up U-Boot (if you did you’ll likely have to swap out the flash chip…) but you also aren’t likely to make the situation with the Linux partition any worse.
And maybe you’ll get an official answer on a procedure here.
You inspired me to plug mine in and boot it to poke around. It’s unfortunate that this U-Boot doesn’t seem to have the ability to read a new image a USB stick that Mediatek’s U-Boot does. Don’t try to replace this U-Boot with Mediatek’s though, as that uses ttyS2 for the console while this has it wired to ttyS0.
Hi Chris,
Yeah the USB/SD card was my first thought after it failed to reboot, in the hope it would read a boot.bin and recover… No such luck.
However the good news is that I have just managed to upload the firmware via TFTP after a bit of experimentation, and the system is now operating again, albeit a bit oddly, but the web UI was a bit odd before anyway.
Huge thanks for your help in this, I ended up scoping the serial lines before hacking a cable, which I should probably clean up and keep, just in case I soft brick it again.
Out of interest, you mentioned you are running different firmware. Is this something you recommend? I just need this to act as gateway to TTN at this point, so I’m happy to lose the other features the supplied firmware supplies.
I’m a big believer in building the entire stack for mission critical components from source, but it’s not for everyone. I’d worked with OpenWRT on the MT7688 before and we had some fairly unique needs in both the packet forwarder and surrounding management and reliability daemons to support a unique network so it made sense.
