For those interested in rolling their own RPi rootfs builds:
- Spindle is a collection of scripts that's used to build the 'official' Raspbian images. It's hardly stripped-down as-is, and far from my favorite rootfs building strategy, but is a starting point: https://github.com/asb/spindle
- The resin.io folks are trying to do "docker for embedded devices", with RPi as one of the initial targets. They have a pre-built rootfs that pulls your docker images via their (proprietary) cloud service. https://resin.io/
Buildroot[1] is another good tool for rolling your own rootfs. If you have ever built your own kernel (i.e. ran make menu-config) you will feel right at home using buildroot. And their documentation is fantastic[2].
Buildroot is a lot simpler than Yocto or OpenEmbedded. I found it a lot easier to quickly understand how Buildroot works and get something working with it than I did with Yocto. Of course Buildroot's simplicity means that you give up some nice to have features that you would probably want for more serious projects.
They have specific instructions for getting started with RaspberryPI v1[3].
Going to second buildroot. I played around with yocto/oe and found it overly complicated for what I needed. Buildrot is much easier to grok and modify/add packages.
OpenEmbedded was indeed fairly frustrating to work with when I did a project with it several years ago. I don't remember the details, though. What I do remember is that OE decoupled board-specific configuration from package selection. buildroot does both in a single .config file, so that may make it less suitable for some projects.
Though OpenEmbedded is a fantastic tool with lots of recipes, lately I've been cooling off on the whole idea. IMHO, no embedded linux build is finished unless you have a way to update the device (for security issues etc). For OE:
1) it's too much work to rebuild everything when you want to pickup security updates
2) upstream doesn't generally update packages in a timely fashion
3) divergence between your recipes and upstream is a big problem
4) opkg isn't as full-fledged as dpkg/yum etc.
So lately, for my own projects, it's gotta be dpkg-based with an active upstream repo.
Does anyone know if the ethernet port still hangs off the USB bus? The CPU usage of that thing killed the last use case I had. (Not to mention the stability. The BeagleBone turned out to be solid in it's place.)
It does, which is interesting. I have a number of BBB modules and a couple of RPi modules (still waiting on the 2) and an ODROID C3 which is faster than the BBB but not nearly the community support. I expect the Pi 2 to reach parity with the BBB (given the CPU). Nice that they kept the price down as that keeps it viable in this niche.
Say no to OpenCV, unless it got mayor redesign. Its great for experimenting and prototyping, just like GNU Radio Companion, but its nickname is 'lets copy that buffer one more time'.
First thing you do when serious about image processing is you DO NOT deploy OpenCV on the end product. You settle on algorithm that works for you, and reimplement it in C (or verilog) as close to metal as you can get.
Definitely agree with this. I got Face Detection using OpenCV on a 320x300 video stream to work at about 2fps (e.g. two detection cycles per second) on the B+ over-clocked to 1Ghz so hopefully the Rpi2 will be a substantial improvement on this.
I was using it the context of controlling the "eye" of a wheeled robot so both the eye and the robot could follow faces. 2FPS was workable on this but 320x300 didn't give it much of a field of view.
Are you aware that there are already more powerful tiny ARM single-board computers on the market that fit in the same size, power and price envelope? Like ODROID: http://www.hardkernel.com/main/products/
From $35 4x1.5Ghz Cortex-A5 ODROID-C1 to $99 octa-core Exynos5422 ODROID-XU3 Lite (4x1.8Ghz Cortex-A15, 4x1.3GHz Coretex-A7, plus OpenCL 1.1)
They have their own ecosystem and monthly magazine (sic!). Raspberry Pi is one of the first and most popular; it's great for beginners, but if you really need to push the envelope there is always competition that tries to undercut them in price, performance and/or features. Now again, RPi 2 has set a new bar, but it is not that high.
Yep absolutely, have been wondering about the C1, my only concern is that getting OpenCV and some of the supporting libraries to build on the Pi was a big challenge but doable because there's such a large community to help out. The same was true with WiFi and Camera drivers.
So the C1 and related boards look great but I'm cautious of building around something with a smaller community just because of the potential for it taking far longer to troubleshoot the underlying stuff I need setup to work on the actual project. That said I'm pretty sure I'll succumb to a c1 in the next couple of months!
Yeah but I don't think its niche will change as much. It fell slightly short in terms of processing power at not so many things. Obviously the faster the better though.
Actually one of the biggest failings of the original Pi was that you couldn't do timing-sensitive I/O operations on the GPIO pins reliably. If you can dedicate one of the 4 cores for GPIO processing (we're not talking a lot of data throughput here), that problem goes away. My biggest beef with the Arduino platform is that the CPU/RAM is just too small to really do much with other than act as a pure sensor<->serial bridge -- and functional GPIO means the new Pi is essentially a half-price replacement for an Arduino Yun.
You'd probably need to write the code in C/C++ (rather than Python or some other interpreted language) to get deterministic execution, but that's an acceptable limitation in my mind.
Is there an implementation of RTLinux on ARM? If so, is it (mostly) compatible with the RPi2?
I doubt that you could easily dedicate one core for RT GPIO while running regular Linux on the rest. That would require quite significant engineering both from the kernel and HW. Probably a better architecture would be something like the PRUs in OMAP SoCs used in BBB, i.e. semi-independent RT co-processors.
Besides there is lots of devices in the market positioned between Arduino and RPi. STM32 F4 Discovery board is a good example; an order of magnitude more processing power than an Arduino Uno but still a MCU designed for bare-metal (real-time) operation.
Some timing sensitive operations like PWM are possible on the old Pi by making the DMA controller directly transfer data from hardware PWM to GPIO without using any CPU cycles.
Frameworks like pigpio and servoblaster use that trick, but the standard gpio python module which doesn't use DMA has more mindshare, probably due to its simplicity.
There is an implementation of RTlinux for the RPi from the Navio guys [1], but I'm not sure if it's compatible with RPi2.
It's why I'm using Beaglebone Black for a project involving many RGB LEDs that have a timing-sensitive protocol - it has two "programmable realtime units" on-die with the CPU. It's a pair of separate cores (200mhz, IIRC) that can handle in hardware the kind of software bit-banging that needs to be done on RPi, and it shares some memory with the CPU. It's able to process or raise interrupts, too. It can handle ADC, PWM, and probably a few other TLAs that I'm missing.
Black Swift [1] guys are telling us: [2] "Want realtime I/O? Add yourself an ATtiny MCU [3] for under $1."
Black Swift is a newer, tinier single-board computer - for 'a bit more embedded' computing than the Raspberry Pi. No audio/video, but a built-in Wi-Fi. Actually, its central SoC in itself is a recent Atheros Wi-Fi chip that happens to have a 400 MHz MIPS 24k CPU embedded. Here's where Black Swift founders see themselves in comparison to the competition: http://www.black-swift.com/images/wiki/BlackSwift-competitio...
Math, lots and lots of math. The new chip has an actual floating point unit instead of it being emulated, support for the NEON SIMD extensions, both of which will definitely help in speed in dealing with any amount of number crunching. It's also got virtualization extensions, so you should be able to run Xen on it and do some level of OS development if you wanna get one for that. Really, it boils down to a lot of little differences that will line up together to make a lot of tasks on the Pi a lot easier to handle.
The previous RPi did actually have hardware FP, see http://raspberrypi.stackexchange.com/questions/545/does-the-.... I think the arch support is probably the big issue - any standard Linux distro with an armhf port will work on the new RPi. Probably gets you access to a lot more interesting Debian packages than you did with Raspbian.
Thanks for the correction. I recalled the original release of debian for the Pi didn't have floating point support, but did not recall that that was because Debian was building towards the least common denominator. I don't think you'd get that many more interesting packages with the new arch, but you probably will get a lot more usability out of the packages
I run headless so don't run into that problem... it would be nice to get some more power so I could plug in a hard drive without having to use a USB hub, though. Tried it a few times without a hub and the drive keeps clicking - spinning down may be the right term? So I've held off on using it as a media center which is what I really want to do.
The power circuits were revised quite a bit in the B+ (and 2), and also between early spins of the Pi and later ones. You may have better luck with a later board revision - I have a Pi B from the very first batch and it can barely keep a backlit keyboard going, but never bothered returning it because I don't use its USB anyway. There's also a lot of flaky USB power supplies out there - make sure yours is solid.
Any chance of a link to some of these. I have started volunteering at a coderdojo and we have plenty of RPi's I just need some inspiration for projects, or more accurately I want to inspire the kids and would like some examples we could work on while they think of their own.
Yeah, I poked at that one just a little bit, but found it pretty limited and kinda buggy. Felt like it was fired off and forgotten. But, hey, maybe with Microsoft buying Minecraft and doing Win10 for the Pi, it will get a second look. (maybe. ha.)
How the hell is a "really basic" Linux distro 3G in size? To me, a "really basic" Linux install, particularly one which is just capable of providing a prompt, should come in at less than 1/10th of that size: Kernel & modules, basic shared libraries, standard linux command line tools... what else?
For comparison, my ubuntu VM is under 1.5G, and that's not been a "really basic" install even when it was first created.
[EDIT] Thanks, it's the whole disk partition image, not the distro itself.
The actual gzipped image file at https://images.collabora.co.uk/rpi2/ is 156 MByte, so I guess 3Gb is the size of the partition imaged, not of the actual data consumed.
Indeed, that was the point of using bmaptool: the actual used space is about 1/10th of the whole image, weighting around 400MB, and with bmaptool you can avoid writing a lot of zeroes to the SD card.
The data is more or less split like that:
224M usr
90M lib
67M var
11M boot
5,8M bin
3,3M sbin
2,9M etc
Of course with some customizations one can do a lot better, but this is just a straight Debian installation with documentation, locales, translations, manpages, etc.
To expand on egil's point, the page actually says 2.5G of the 3G is zeros. So it's probably a 3 GB filesystem with 2.5 GB free space -- not quite 1/10th the size, but not that far off.
He probably didn't care because it's not much more than partitioning, running debootstrap, installing the few extra packages and copying config.txt and cmdline.txt. :)
That said a gpg signature could be a good thing to add.
Does anyone know if the RPi 2 has hardware accelerated crypto? A project of mine that serves HTTPS video streams from an RPi was not usable on a model B with more than 8 users.
By comparison, I know CubieBoard has accelerated crypto but I don't want to switch horses half way, so to speak.
Yes, but the draft is already running in production and mainlined in Chrome, as well as BoringSSL (and thus throughout Google, I understand?) and LibreSSL - nothing stopping you from benefiting from it right now. The final spin on the AEAD's in final draft, it won't be too long, then the TLS WG is importing that.
(I'm still working out the details - there are a few things about the VPU we don't know - but the ChaCha core function in particular looks like something the VPU could do very naturally, except that it's got diagonals. However a permutation to make those vertical might fix that, and if it can wrap around and the transform doesn't cancel out the benefit, it might perform very well. Or, it might block and be slower than the CPU. Hard to know at this stage, but if I come up with a good implementation I'll release it.)
Regarding mobile: the latest Android Browser, and the mainline Chrome for Android and beta Chrome for Android both have CC20. agl specifically called out Android as a use case - ARMv7+NEON performance of ChaCha20 is substantially faster than, say, AES.
Yes, you'll probably be waiting until the RFC is out for wider support. I reckon it makes a leading candidate for "AES backup/standby", however.
Yep, but the point is about running real Debian, not any Debian-derived distributions like Raspbian that have been rebuilt for ARMv6.
With the old Pi it was not possible because the CPU only supported the ARMv6 instruction set, while mainstream distributions (Debian, Ubuntu, Fedora, etc.) all require ARMv7.
Fortunately the just released Pi 2 sports Cortex-A7 Cores which use the ARMv7 instruction set, which made this possible without any full rebuild.
It would have been possible to use Debian, but the armel build which is running on ARMv6 would have diminished the performance even further, as it servers for very old ARM processors.
- Spindle is a collection of scripts that's used to build the 'official' Raspbian images. It's hardly stripped-down as-is, and far from my favorite rootfs building strategy, but is a starting point: https://github.com/asb/spindle
- Yocto / OpenEmbedded recipes are available for truly stripped-down build possibilities. Here's a random blog post specific to RPi: https://delog.wordpress.com/2014/09/16/embedded-linux-system...
- The resin.io folks are trying to do "docker for embedded devices", with RPi as one of the initial targets. They have a pre-built rootfs that pulls your docker images via their (proprietary) cloud service. https://resin.io/