Our first and most active Kerlink Wirnet gateway stopped working a few days ago (after running for 4 years non stop). After a few attempts to get it back to work I had to attach a serial FTDI connection (thanks to DIY Kerlink Wirgrid debug probe and @jpmeijers). All I get there is the following:
I think that this is just the default message for every boot. It’s not an error message. It just says that the on-die NAND has ECC.
See Convert Actility Kerlink gateway to TTN for another post with the same boot message. Looks normal.
If I had to guess I’d say that either your bootloader got corrupted, or your flash memory died. I have heard rumours that the early versions of these Kerlink gateways were prone to killing their flash memory. That’s also one of the main things that were fixed from firmware version 2 to version 3.
Were you by chance running old v2 firmware on the gateway?
Unfortunately I don’t know how to debug this any further. You might want to try the Kerlink wiki.
We updated to firmware 3.6 around one year ago. But that’s a good thing to know, we have a few other Kerlinks with firmware v2. Perhaps we can upgrade them to avoid this (rumor).
Any hints how to get access to the kerlink wiki? We bought the gateway through TTN back in the early days.
There was a day-long marathon of non-answers from some extremely unhelpful kerlink person here a few months ago. They’d never quite admit it, but it seems like they’re checking a signature (eg, hardware would check bootloader signature, bootloader would check linux image signature, etc) It seems to unfortunately be a box with a very paternalistic design - we’ll let you do what we feel like letting you do, if it’s our part that’s broken, tough luck.
In my experience he is a very helpful Kerlink person. That he did not answer your questions with the answers you are looking for does not make him unhelpful, just someone who is careful about company policy when answering politically laden questions.
Well, pretty basic factual questions concerning the early boot process went unanswered.
And now there’s a box that won’t boot, and isn’t giving meaningful output
Typically with such an SoC if things are not locked down there’s some sort of alternate way to get it to boot - bootloader, inject U-Boot via JTAG and start it up, etc.
Perhaps their support can help.
Or perhaps the only recourse is to see if the LoRa sub-circuit can be isolated from the apparently dead computer and used with something else.
Worth spending a minute to make sure the supply rail isn’t browning out, though. There does seem to be build version, so presumably the NAND isn’t entirely dead. The issue could be when things switch from the inital stub loaded by hardware, to trying to do things like configure external RAM and load the rest of the (presumably U-Boot) code there, so anything that prevents getting from bootstrap to a full system configuration could be suspect - external ram, clock circuitry, power to run the chip at a higher clock rate, contents of flash beyond the initial bootstrap piece…
Well, this is a bit rude given the time and patience I took to reply to vague questions.
This gateway doesn’t have the same bootloader as the one in the other conversation. The other gateway has a closed bootloader with optional signature checks. This gateway has an open bootloader with no signature checks. So I guess you were plain wrong about that, and I feel also plain wrong about my unhelpfulness. I’m here to provide free advice or free answers, I feel it’s being helpful.
However, the bootloader or the flash is corrupt here, as mentioned, and only JTAG can save it, if it’s even possible to save it. Ask Kerlink support and they’ll issue you an RMA (check with them the conditions).