Debian Jessie on Raspberry Pi 2 | Hacker News Reader

Debian Jessie on Raspberry Pi 2

sjoerd.luon.net

203 pointsEmanueleAina69 comments

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

- 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/

There's also buildroot (http://buildroot.net/). The noobs distro installer for RPi is based on an older version of that.

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].

[1]: http://buildroot.uclibc.org/ [2]: http://buildroot.uclibc.org/downloads/manual/manual.html [3]: http://git.buildroot.net/buildroot/tree/board/raspberrypi/re...

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.

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.

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, but the CPU's a lot (400-700%!) beefier. We'll see how much of an effect that has in practice.

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.

I have to say, the Pi 2 comes across less as a bit of fun and more as something you can really start doing interesting things with.

Currently investigating image processing and ANPR using OpenCV.

Given that the only thing that has changed is the more powerful CPU, I'd say same fun and more interesting things! ;)

RAM also doubled to 1GB.

First generation B model was 256MB, later it was doubled to 512MB.

And ARMv7 is a big deal, as the article points out..

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?

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...

[1] Black Swift — tiny wireless computer https://www.kickstarter.com/projects/1133560316/black-swift-...

[2] Using AVR as peripheral controller https://www.kickstarter.com/projects/1133560316/black-swift-...

[3] ATtiny24A http://www.atmel.com/devices/ATTINY24A.aspx @Octopart https://octopart.com/search?q=ATTINY24A&filter%5Bfields%5D%5...

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.

[1]: http://www.emlid.com/new-raspbian-with-real-time-kernel-jan-...

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.

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.

Could you elaborate on this point? I'm curious as what the new architecture will help with, other than the porting issues mentioned in the article.

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

Hm, I've plenty of fun and more interesting projects than I can count with the prior model too.

I like the fact that processing speed has been boosted but that's all there is to it.

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.

Have you looked at Minecraft for Raspberry Pi ( http://pi.minecraft.net/ ) ? It can be scripted using Python. Great way to get kids hooked.

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.)

Here are a few ideas:

* http://www.hackster.io/raspberry-pi

* http://hackaday.io/projects/tag/raspberry%20pi

* http://raspberry.io/projects/

One of my projects: https://unop.uk/dev/raspberry-pi-electricity-monitor/

http://www.dexterindustries.com/GoPiGo/

I'm really happy about the 4 USB ports too. It was a pain having to use a USB hub on my Model B to get keyboard+mouse+WiFi.

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.

The previous model already had 4 USB ports.

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.

> Raspberry Pi is the first and most popular

While certainly most popular, I'd dispute the claim of being first. For example BeagleBoard was initially released in 2008.

Oh, you're right.

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!

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.

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.

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.

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.

No script to reproduce this image? We would all jump down sjoerd's throat if he asked us to "curl | sudo sh -", but this is almost equivalent :)

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.

Aaaand GPG signature added!

Cool, so now I'm confident that it was sjoerd that compromised my machine ;)

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.

It does not, although it has a hardware RNG. However ChaCha20_Poly1305 will yield excellent software performance as it's ideally suited to NEON.

It could perhaps go even faster, given the VPU is a vector processor.

Isn't ChaCha20/Poly1305 still draft status in TLS? Might not be very helpful.

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.)

I'm solely talking about browser compatibility.

(And don't get me wrong: I LOVE the work that's being done, and can't wait to be through with older cipher families!)

If you're streaming to mobile, ChaCha20 is out.

IE, Firefox, and Safari on the desktop: out. (so far)

Compatibility with IIS or any non-bleeding-edge middleware servers: out.

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.

Great news! Thanks. :)

Well I'm not a Pi user but thanks for bmap-tools. How did I not know about this before?

Mainly because Tizen isn't well publicised - I didn't know about the tool either, seems like it will be really useful.

Good start. Doesn't the BCM firmware have initramfs support already? Try ORGing it in at a00000 with config.txt.

Mainline wasn't that far behind but uses bcm2835 instead of bcm2708. That might change/need an update now - not sure? Will find out in a few days!

What does using the firmware's initramfs support give you?

Nice, although I'd rather have a mini Ubuntu 14.04 LTS. Ubuntu on ARMv7 is great, and I'd like a minimal distribution to get started.

There's Snappy Core, but to be honest I don't want to run that on a Pi just yet.

If you don't want the snappy part, it seems you can use a straight Ubuntu Core (not necessarily the Snappy Ubuntu Core).

The alpha image I downloaded lacked apt-get (given it was snappy). Anyone know of a "normal" one?

(oh, and https://news.ycombinator.com/item?id=9000584 - I just got a board)

Will this RPi2 support get upstream into Debian Jessie? That would be awesome.

That's the intention, but more work is needed.

I wonder what the chances of playstation 2 emulation working on RPi2 ?? :s

Zero.

been using jessie on older pis for a while with lessbian

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.

Reply on news.ycombinator.com