l1k

Traditional German manufacturers scrambling to get their foot into IoT, but also various international companies. The RevPi modules pop up at places you can't imagine. Before long there's going to be Linux in every electric cabinet. In other news, Linux world domination is progressing according to plan.

That's the requirement prescribed by EN 61131-2. We test with 60°C, so an additional safety margin of 5°C.

Both the hardware (base board schematics) as well as the software are open source. Let's say Kunbus goes down the drain and you hit an issue. Best case someone in the community has already fixed it. Worst case you'll have to hire a decent consultant. Show me another PLC that affords the same kind of vendor independence.

As to availability, the hardware is manufactured and assembled in Denkendorf, Germany, so the supply chain is short. The Foundation guarantees availability of the Compute Module 1 and 3 until at least January 2023.

We use the Raspberry Pi Compute Module, i.e. a special, stripped-down version of the Raspberry Pi which fits on a 200 pin SO-DIMM module. This version does not use an SD card but has a 4 GByte eMMC on-board. (It would be possible to use an SD card in addition to the eMMC but we don't make use of that.)

Of course the eMMC is still based on flash, which has a limited lifetime. So we use a customized version of Raspbian which has swap disabled by default (can be enabled if you need it) and tunes the syslog configuration to reduce the amount of log data written. It's also possible to use a tmpfs-backed /var/log (can be enabled with a mouse click or a simple command). That way we try to prolong the lifetime of the eMMC as much as possible.

We've also been in talks with the Foundation about this and they have asserted that the eMMC is of good quality and should last for the typical lifetime of a PLC (which can be decades).

The case is made of polycarbonate. Cardboard would be interesting from an environmental perspective, but likely wouldn't be able to withstand the harsh conditions prescribed by EN 61131-2 (low/high temperatures, damp air, vibrations/shock etc). We add a safety margin to those conditions, e.g. 61131-2 requires safe operation at 55 degrees Celsius, we test at 60 degrees. The products are used e.g. in automotive applications where these harsh conditions are not just theoretical.

Yes, with appropriate software. logi.CAD (an IEC 61131-3 automation platform) is pre-installed as a demo version and license keys are available at the online shop for a few bucks.

But noone is forcing you to use a specific software. You can use Python or even Bash. The input and output values are stored in a process image by an open source kernel driver (piControl) and you can access the process image through a char device. Just seek() to the value you're interested in and issue a read() or write().

There's a patch set for the kernel called PREEMPT_RT:

https://wiki.linuxfoundation.org/realtime/start

It contains patches to get latencies down and touches numerous subsystems of the kernel. Most importantly, interrupt handlers become preemptible. (Normally interrupts are executed in "atomic context", i.e. they cannot be preempted. This also means e.g. that you can't sleep in an interrupt handler because the timer interrupt is disregarded. With PREEMPT_RT_FULL, interrupts are executed in "process context", i.e. as normal kernel threads which can be interrupted.)

We use the kernel branch of the Foundation (which contains a ton of patches required for hardware support of the Raspberry Pi), cherry-pick the realtime patch set on top, then apply three custom patches, one is a fix to make the USB driver's interrupt handler preemptible. The result is this branch:

https://github.com/RevolutionPi/linux/commits/revpi-4.4

A mini HDMI port is on the top of the RevPi Core and you can attach any display that you would normally use on a Raspberry Pi. There are some displays available from 3rd parties which are suitable for mounting on top hat rails.

The CSI and DSI pins are not accessible on external ports I'm afraid. I'm also not aware of plans to add modules which would make CSI/DSI available externally. In theory it's possible to open the case and attach wires to the pins which go to a connector external to the case and you could connect a CSI camera or DSI display there, however the result can hardly be considered "industrial". :-)

An alternative is to connect a USB camera.

The 4-core BCM2837 on the Compute Module 3 is beefy enough for image processing with OpenCV, in fact we're using OpenCV for our demos at expos. It may even be sufficient for video transcoding. One thing to be aware of though is that we're using a kernel with RT patches. Which means low latency, but also lower throughput. If you don't need low latencies but maximum throughput, it may be a good idea to use a kernel without RT patches. All the tooling to build a custom kernel is on GitHub.

The I/O modules themselves have 2 pin headers with 14 pins each. The pin headers receive adapters with wire terminals. The adapters are included.

The German I/O module page has an animation which shows this in detail, it seems the English page is missing that for some reason:

https://revolution.kunbus.de/io-modul/

1. There's a Photoshop wiz on the team. I'm not aware of any colleagues with chicken, must be stock photos then. The crazy stuff shown on expo photos is real though (snack lottery, "occupied" booth etc).

2. I think that was a different company, I'll have to ask the CEO next time I see him.

When all 4 cores are under load, the BCM2837 on the Raspberry Pi 3 will rapidly reduce the clock rate after about 60 seconds (from 1.2 GHz to 600 MHz, or even 300 MHz if the core temperature exceeds 85 degrees Celsius). Cooling is required if you want decent performance for prolonged periods of time.

The RevPi Core 3 is equipped with a high performance cooler which is able to sustain 1.2 GHz at full load for about 20 minutes (at room temperature). After that the clock rate will be moderately reduced to 1.15 GHz.

Hi there. I'm an engineer on the Revolution Pi team. AMA.

This was answered in the German Revolution Pi forum a few months back: https://revolution.kunbus.de/forum/viewtopic.php?f=8&t=6&p=1...

The TL;DR is that the products have gone through all the testing required by EN61131-2 and you can safely deploy them in harsh environments (e.g. wrt electromagnetic radiation or vibrations/shocks). However there is no external certification.

That is mostly correct. A few corrections/additions:

* It's either the Compute Module 3 or the older (cheaper, slower) Compute Module 1.

* The schematics of the base board in the RevPi Core are open source: https://revolution.kunbus.de/download/1803/

* Normally you wouldn't open the RevPi Core case and solder stuff to the base board, though you're given all the information you need if want to do so. The expected use is to just mount the RevPi Core on a top hat rail and extend it with I/O or gateway modules via the PiBridge connector.

Thanks! The FileVault2 driver for Linux that you couldn't find is probably this one:

https://github.com/libyal/libfvde/wiki

It's experimental though. Better back up your data.

I'd recommend to create a partition for ZFS and move data there that you want to use on both OSes, or outright install Linux on a zpool and mount that on macOS. This has worked remarkably well for me, even with lz4 compression and all the other great features. Layer ZFS on TrueCrypt if you need encryption, I wrote a howto a while ago but never had the time to update it:

https://github.com/zfsonlinux/pkg-zfs/wiki/Dual-booting-OS-X...

If nothing's plugged in then many devices can indeed be suspended in some way, either by putting them in PCI power state D3hot or by cutting power if the platform supports it. Plug events are then signaled e.g. by an ACPI GPE (general purpose event, an interrupt sent by the platform to the OS).

The case I was referring to was with the Ethernet cable still plugged in. They seem to suspend the Ethernet controller but don't wake it when packets come in, presumably because the controller doesn't support that. The machine appears dead from the outside after a few seconds of inactivity.

That is correct. The Thunderbolt controller has two DisplayPort sink ports which are wired to the GPU, in addition to the PCIe 3.0 4x interface which goes to a root port in the CPU. So to actually max out the 40 Gbit/s, you need to drive external displays and also max out the PCIe 3.0 4x interface. Which is another way to say that 8 Gbit/s are reserved for DisplayPort.

For a Linux driver it wouldn't be acceptable to compromise functionality like this as it's expected to work equally well on big iron as on laptops. So we have to tweak a lot more to achieve the same level of battery life.

No that is not mythology, Apple specifically targeted developers in the past, such as in this 2002 commercial featuring a stereotypical grey-bearded UNIX guru:

https://www.youtube.com/watch?v=O4AgFhIm1qs

Quote: "It's not just for artists. It's not just for pointy-headed intellectuals from California. It's for us, it's for programmers, it's for developers."

Yes, but as stated in the article only on macOS or Linux on non-Macs. Not with Linux on Macs unfortunately. Someone needs to scrutinize the Intel-developed code for non-Macs, figure out how to port it to Andreas Noever's driver, and fill in the missing parts by reversing the macOS driver.

Also, the Alpine Ridge controllers are attached with PCIe 3.0 4x lanes, that's 31.504 GBit/s, so you can't exhaust the available bandwidth fully.

First of all, macOS power manages devices too aggressively: I've noticed that if I ssh from another computer into my MacBook Pro (booted into macOS and connected to wired Ethernet), the connection becomes unresponsive after a few seconds of inactivity. I have to ping from the MacBook Pro to a machine on the LAN to make the ssh connection responsive again. It looks like macOS suspends the BCM 57765 Ethernet controller and doesn't resume it upon reception of packets from the LAN. Apple seems to consider macOS purely a client OS from which one ssh's to the outside world but not the other way round.

Second, there's no proprietary battery magic in macOS, as stated in the article I already achieve 10.5W idle power consumption on my Ivy Bridge MacBook Pro with discrete GPU, Thunderbolt and AirPort suspended, wheras macOS achieves 7W. I've noticed a GPE in the ACPI tables for the Firewire controller which presumably signals hotplug when the controller is asleep. We're not using that on Linux yet, we keep the Firewire controller active all the time. Adding that would probably save another 1W.

So we're inching ever closer to macOS levels of battery life, and I think eventually we may be able to surpass it because of the sophisticated CPU pstate management that Intel developers continue to tweak with every new release.

Let's say you're a penetration tester, you're on-site trying to break into a network, have no Internet connectivity (e.g. because you're in a shielded data center or don't want to raise suspicion) and need to crack some passwords. 5x Skylake CPU + 5x Polaris GPU would be a sufficiently beefy platform for Hashcat, and it would fit into your backpack.

Or let's say you want to quickly set up a Hadoop cluster to crunch some data.

Five machines is certainly small as HPC clusters go, and in reality you'll probably have to cap this to four machines because you need one port to attach to a power socket if you need the cluster for more than 2-3 hours. Nevertheless the 4x 40 GBit/s Thunderbolt ports offer some really interesting possibilities, and I'm not aware of any other portable machine that has this right now.

Personally I've been using fink for >12 years now, I enjoy being able to use the familiar apt-get and dpkg to manage packages on macOS:

http://finkproject.org/

I even backported the then-current version to MacOS X 10.4 (Tiger) last year. :-)

https://github.com/l1k/fink/commits/branch_0_38_tenfour

There was a thread on dri-devel a year ago:

https://lists.freedesktop.org/archives/dri-devel/2015-Octobe...

Back then the probed panel resolution (EDID retrieved by radeon) was 3840x2160, which doesn't make any sense because the panel actually has 5120x2880. It's unclear if this was because of missing/broken MST support in radeon (Multistream Transport) or if Apple used some proprietary mechanism to squeeze the panel resolution in a single stream transport. You may want to contact the person who started that thread (Andreas Tunek) and ask if the situation has improved with contemporary kernels.

Well, it turns out there are folks who like Apple's form language but can't get (all of) their work done on macOS or don't want to use it for some reason. So there's a target audience for Linux on the Mac. I'm not saying it's a huge crowd.

Author here. As explained in the intro, folks like antirez are considering moving back to Linux and in his linked HN comment he specifically talks about trying Linux on the MacBook he's currently using to see where he's headed. The article seeks to give these folks in particular a helping hand in understanding what works and what doesn't:

https://news.ycombinator.com/item?id=12820490

That said, the kernel developers working on Mac hardware support aren't Apple haters. We're fans. I also don't share the "not for professionals" criticism that was widely directed at the new MacBook Pro fully: E.g. as stated in the article, the four Thunderbolt ports are interesting for HPC applications as you can build a portable compute cluster with up to five fully-meshed high-speed networked nodes. If that's not professional I don't know what is.