Best (most-stable) console image to start from?

GoogleGroups
1

Can anyone recommend the most stable version of RCN’s console images on which to base an embedded device that uses the PRU (uio_pruss)?

From what I understand there was incompatibility with the PRU somewhere between 3.8 - 4.1.

I’d like to go back in time (probably to a Wheezy install) to a point of known good stability (ie no reboots caused by OS/hardware), but I’m not sure where to land.

I most recently tried:

Jessie 8.4 console image of 4/7/2016
Kernel: 4.4.9 -bone-rt-r10 kernel

but am seeing spontaneous reboots (even not running my own SW).

Thanks for any guidance you can provide!

Best,
ST

2

No one can make this determination for you.

As there is no “one size fits all” image.

3

@William
I understand. I’m not asking for that. I’m already doing a fair bit of add and subtract, even starting from a console image, to come up with the best image for my own application. I’m just looking for the gut-check of folks who understand the various images and kernels better than I, to know which ones might be the best starting point. (ie those that have issues that might affect me, PRU/uio_pruss and others that I don’t know about).

The process of trying all of the available console images, customizing them and subjecting all of them to long-term stability tests, is a painstaking, and long process that I am in the middle of. I have already gleaned what I can from forums, etc. I know I’m not the only one going through this process, so I’m just hoping that someone share a few tips to help me reduce the search space. With no description of what each image contains, reference of what issues popped up for users of them, and no historical record of why new versions were rolled (presumably because some problems were fixed, and the newer one is better), I don’t have a lot to work with. Maybe this stuff exists somewhere, and I just don’t know where? If so, point me to it and I’ll keep reading.

Here’s what I’m working with:

“Use an official image” - adds a bunch of stuff that is inappropriate for an embedded device (graphical targets, node, cloud9, etc), I don’t know enough about what I can safe remove to start from here.

“Use the barefs” - really quite appealing, and I may get there someday, but for now, I don’t have a non-virtualized-os linux dev machine.

The best I’ve found so far:

“Use a console image”

Ok, so I’m using a console image:

“Use the latest image” - exposes me to the potentially lurking issues of the cutting edge. I am uncomfortable with that solution because the level of risk is too high for me.

My own reasoning is “Choose a long-term-support variant" (so it will have the chance to settle into greater stability).

BUT, I’ve been having a hard time solving stability problems with:
  Jessie 8.4 console image of 4/7/2016
  Kernel: 4.4.9 -bone-rt-r10 kernel

and know there was a period of uio_pruss issues somewhere in 3.8 - 4.1. So, my thought was to back up to Wheezy. But, which console image should I start with??? Was the latest one the best?

I’m thankful for any input, even if it is to tell me I’m going about this the wrong way. That said, one person telling me I’m doing it wrong is probably not going to help, unless they can point me to a better way. If not, then I’ll keep learning as best as I can, and asking for help when I’m stuck.

Best,
ST

4

My experiences has in the past been to stick with the Wheezy image, and just upgrade the kernel to 4.1.x. Perhaps 4.4.x, but I’m still on the fence with that one. Then . . .

remote_proc == TI kernel.

uio_pruss == bone kernel.

The rest is hit and / or miss trial by error.

Now, with all the above said. I am currently working with one of the later Jessie images, and having backed out of systemd back into sysv for an init daemon. My reason for Jessie is that I needed a newer gcc ( 4.7 + I think ) to compile the newer versions of Nodejs. I’m currently using. . .

william@beaglebone:~/dev$ node -v
v4.2.6
william@beaglebone:~/dev$ npm -v
3.9.0
william@beaglebone:~/dev$ gcc --version
gcc (Debian 4.9.2-10) 4.9.2
Copyright © 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

But anyway, I’m not 100% sure I’ll use a Jessie image, but I’m trying to making it work. Otherwise I’d have to fall all the way back to v0.10.x for Nodejs, at which point I’d fall back to Wheezy as well. I still Have a lot to test though, which I will not be able to completely test until I get a good portion of the software written for using nearly all the pins on the P8 / P9 headers . . . which will take a while as I have a lot I need to research javascript / Nodejs wise. Plus we’re usually pretty busy here during the spring / summer. So “round-to-its” are fewer, and further in between.

5

I’m not ready yet, other things need to be finished first, but unless better recommendations and examples appear before I get to it, I plan on starting with the 3.8.13-bone70 kernel and Wheezy (7.8) used by Derek Malloy in his “Exploring Beaglebone” PRU examples;
http://exploringbeaglebone.com/chapter13/#prettyPhoto

I think its pretty easy to do worse :slight_smile:

6

Hi Wally,

No really an argument per se, but just an observation on my own behalf. I have no found anything to be broken in terms of functionality on the latest 4.1.x kernels. One difference that I did notice right away however is that the 4.1.x kernels are more responsive, while using the operating system.

The uio_pruss examples all work fine, or at least worked fine with 4.1.x when i tested a couple months ago, or slightly longer.

7

@William
Thank you! I really appreciate you sharing your approach. Your clarification that the uio_pruss/remote_proc issue lies in the choice of kernel, not the version is a subtlety that was escaping me, despite having found my way to the bone-rt kernels. I also hadn’t realized that a 4.1.x kernel was an option with a Wheezy image. You just saved me days, if not weeks, of trial and error, and I really appreciate it.

My experiences has in the past been to stick with the Wheezy image, and just upgrade the kernel to 4.1.x. Perhaps 4.4.x, but I'm still on the fence with that one. Then . . .
remote_proc == *TI* kernel.
uio_pruss == *bone* kernel.

@Wally
Thank you too for sharing as well. Derek’s book is a great resource!

Best,
ST

8

Super Twang,

I think in terms of Jessie versus Wheezy though. You need to figure out how new the software has to be for each version of Debian. Wheezy, will be very reliable, but the software that it can run without too much work on your behalf will be older. Not that Jessie wont be reliable either, but the software it runs is newer, so perhaps not so tried and true.

Debian is not your typical Linux distribution however. Debian does not go release with a version unless it has been rigorously tested. Which means, perhaps there are still flaws, but compared to other distro’s they’re minor, and far rarer.

For me personally. The main reason why I still prefer Wheezy to Jessie is familiarity. But I can attempt to make Jessie as familiar as possible for me, and so far, it’s worked out ok.

9

Thanks this will be a real time saver for me too! I’d prefer to stick with Jessie if possible, as it is the future.

I permuted kernels on late Wheezy and early Jessie images (~7 months ago) trying to track down some USB webcam issues (two different HP models) on my BBB, no significant difference that I could see – all had weird problems with repeated frame captures. Ended up doing it with a Raspberry Pi2 instead. I haven’t revisited the USB webcams with newer images as the Pi2 is doing good enough for this.