It's the first thing that works, JTAG or other proprietary debug ports aside. It's the thing that you start with in order to get everything else to work, and it's the thing that works when everything else fails. That's why my desk is full of RS232 dongles and cables. The first thing I need to do when I get a new board is to figure out where the console is.
Multi-purpose boards ranging from ~Nano-ITX to Flex-ATX in size. Typical features include dual power inputs, a bunch of ethernet ports, rs232 & rs485 ports, isolated gpios, analog inputs, wireless modem (3g/lte/5g), and more depending on the board. These are used for things such as hooking up on prem sensors and alarm systems, providing redundant internet / vpn connectivity for devices, remote management of devices that either don't have direct internet support at all or aren't actually secure enough to be exposed (or just can't allocate a public IP address and thus need a tunnel/vpn for management), etcetra.
Not what I was expecting. I somehow associated "find console" and "board bringup" with notions of signal analysis and 23 SMA connectors and "BUG: unable to handle kernel paging request" and "ARGH it was a hairline solder bridge this entire time". Need to despecialize my definitions a bit.
But that's very cool. How does the redundant connectivity stuff work? Just basic failover, or WAN bonding? (I'm also vaguely aware that some setups sometimes go through carriers that will provision a custom APN packaged with an upstream VPN so the device is physically isolated from the public internet, which can both increase security and lower cost from port scans etc.)
(Also, in a prior comment (https://news.ycombinator.com/item?id=29032123) you mentioned how Allwinner offer an SIP with DDR3 - interesting. I've been idly curious for a while about where the FC100s-based "my business card runs Linux" would be at a couple years on, and what a minimal working example would look like. Definitely a bit of a tangent though.)
> Not what I was expecting. I somehow associated "find console" and "board bringup" with notions of signal analysis and 23 SMA connectors and "BUG: unable to handle kernel paging request" and "ARGH it was a hairline solder bridge this entire time". Need to despecialize my definitions a bit.
Oh it can be a bit like that sometimes. Kernel crashes, general instability, overheating, broken (or shorted) PMICs, miswired signals (turns out it's very easy to get TX and RX pairs between CPU & peripheral mixed up), wrong voltage levels, wrong clocks, peripherals missing firmware.. I've seen it all, and I've had plenty of use for the oscilloscope recently. Hopefully we'll get the next prototype soon-ish but there's still stuff that needs to be debugged :) I'm kinda spread thin between board bringup & debugging and writing new features for the customer.
> How does the redundant connectivity stuff work? Just basic failover, or WAN bonding?
There's more than one mechanism in place. The basic route failover stuff in Linux doesn't work very well (afaict it only detects the gateway going down, which doesn't help if the gateway is another on-prem router which stays alive when the link to ISP goes belly up). So we've got periodic ping probes (to a configurable set of IPs) which promote/demote the corresponding route when a few probes succeed/fail.
We've also got a daemon which maintains multiple connections (also multiple protocols) to multiple servers through all WAN interfaces and all connections do regular keepalives; packets are rerouted to another connection when one fails. It can also duplicate packets to multiple connections simultaneously (it's often necessary to get alarms delivered to more than one place), among other things. It's sort of an overlay network that performs VPN-like functions (and more) on and off the internet, and can tunnel anything from SMS to serial ports to raw ethernet to individual TCP & UDP ports or specific protocols like FTP.
Bonding as such isn't implemented but it's on the radar.
> Oh it can be a bit like that sometimes. Kernel crashes, general instability, overheating, broken (or shorted) PMICs, miswired signals (turns out it's very easy to get TX and RX pairs between CPU & peripheral mixed up), wrong voltage levels, wrong clocks, peripherals missing firmware.. I've seen it all, and I've had plenty of use for the oscilloscope recently. Hopefully we'll get the next prototype soon-ish but there's still stuff that needs to be debugged :)
On the one hand, yikes; on the other hand, coool :)
> I'm kinda spread thin between board bringup & debugging and writing new features for the customer.
[Cries in long distance]
Shipping hardware to AU would probably be a bit... unsustainable ;_;
> There's more than one mechanism in place. The basic route failover stuff in Linux doesn't work very well (afaict it only detects the gateway going down, which doesn't help if the gateway is another on-prem router which stays alive when the link to ISP goes belly up).
Oh yay.
> So we've got periodic ping probes (to a configurable set of IPs) which promote/demote the corresponding route when a few probes succeed/fail.
*Takes notes*
I'm switching to sorta-fiber soon and the connection comes with a 4G backup. Using a modem without SMA (which no Consumer™ would ever need, right?) in a "what's service?" reception area. So I'm planning to reimplement the 4G failover with my own dongle (and antenna) :3
At least that's the theory. Not sure if it'll work. Waiting for my old DSL connection to die first so I can record the click, because I'm... weird. :P
> We've also got a daemon which maintains multiple connections (also multiple protocols) to multiple servers through all WAN interfaces and all connections do regular keepalives; packets are rerouted to another connection when one fails.
Cool.
> It can also duplicate packets to multiple connections simultaneously (it's often necessary to get alarms delivered to more than one place), among other things.
Does this use a confidence scoring system or does it just copy everything Nx -> 1:N?
(...admittedly I'm now thinking of the bandwidth management in multi-SIM video broadcast systems. Not quite the same thing.)
> It's sort of an overlay network that performs VPN-like functions (and more) on and off the internet, and can tunnel anything from SMS to serial ports to raw ethernet to individual TCP & UDP ports or specific protocols like FTP.
O.o neat
> Bonding as such isn't implemented but it's on the radar.
Interesting, I can see how it's simultaneously not-so-relevant and yet would probably simplify things here and there.
