debian testing: 2016-05-01

Howdy!

So there’s a little something new in this week’s snapshot:

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2016-05-01

We’ve now switched from v4.1.x-ti to v4.4.x-ti by default.

hostap/wpasuppliant saw a major upgrade: 2.3 → 2.5

Board specific documentation:

BBW/BBB = BeagleBoard.org documentation over usb flash

BBG = seeedstudio.com documentation over usb flash

bonescript 0.5.0-beta with more fixes

nodejs v0.12.x

Wireless AP by default:

SSID: BeagleBone (or) BeagleBone-WXYZ
PASS: BeagleBone

Regards,

So there's a little something new in this week's snapshot:

Beagleboard:BeagleBoneBlack Debian - eLinux.org

We've now switched from v4.1.x-ti to v4.4.x-ti by default.

So, if I want to use PRUSS, I need to grab a -bone kernel, right?

Wireless AP by default:

Ooh!

Howdy!

So there’s a little something new in this week’s snapshot:

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2016-05-01

We’ve now switched from v4.1.x-ti to v4.4.x-ti by default.

With 4.4, should we be enabling -rt?

hostap/wpasuppliant saw a major upgrade: 2.3 → 2.5

Does this image include the WL183x patches from TI?

Board specific documentation:

BBW/BBB = BeagleBoard.org documentation over usb flash

BBG = seeedstudio.com documentation over usb flash

bonescript 0.5.0-beta with more fixes

I’m assuming beta4. I’ll try to get the fix in if using the old cape manager to continue using the old functions. All should be working better for the newer kernels.

nodejs v0.12.x

Wireless AP by default:

SSID: BeagleBone (or) BeagleBone-WXYZ

When would you not have the -WXYZ?

PASS: BeagleBone

Can you summarize connman vs. other configs for the various network connections?

So there’s a little something new in this week’s snapshot:

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2016-05-01

We’ve now switched from v4.1.x-ti to v4.4.x-ti by default.

So, if I want to use PRUSS, I need to grab a -bone kernel, right?

If using remoteproc, the -ti kernel should be OK. If you need uio_pruss, then I think you still need -bone. Not sure if there is progress on making this device tree adjustable.

Yeah, sorry. By PRUSS I meant uio_pruss. I depend on a third-party lib that uses that and isn't like to be updated any time soon. I don't have time to learn how to update it right now, given all the other things I have to finish on this project.

Hi Rick,

by default v4.4.x-ti (and the rt) will use remoteproc_pruss...

For uio_pruss:

cd /opt/scripts/tools/
git pull
sudo ./update_kernel.sh <OPTIONS>

Mainline (4.1.x lts)[edit
<http://elinux.org/index.php?title=Beagleboard:BeagleBoneBlack_Debian&action=edit&section=41>
]

4.1.x BeagleBone/BeagleBone Black
--bone-kernel --lts-4_1

4.1.x BeagleBone/BeagleBone Black + RT
--bone-rt-kernel --lts-4_1

Mainline (4.4.x lts)[edit
<http://elinux.org/index.php?title=Beagleboard:BeagleBoneBlack_Debian&action=edit&section=42>
]

4.4.x BeagleBone/BeagleBone Black
--bone-kernel --lts-4_4

4.4.x BeagleBone/BeagleBone Black + RT
--bone-rt-kernel --lts-4_4

Regards,

Thanks, Robert. Is that better than just apt-getting a particular kernel? I guess it's a bit easier, and always pulls down the latest?

Howdy!

So there's a little something new in this week's snapshot:

Beagleboard:BeagleBoneBlack Debian - eLinux.org

We've now switched from v4.1.x-ti to v4.4.x-ti by default.

With 4.4, should we be enabling -rt?

Good point, we were going to try that again, just did:

   25 cd /opt/scripts/tools/
   26 git pull
   27 sudo ./update_kernel.sh --ti-rt-channel --lts-4_4

debian@beaglebone:~$ uname -r
4.4.8-ti-rt-r22

So far, usb networking/flash/serial seem to work fine on my linux box..
(with 4.1.x-rt serial would fail).. I'll test windows 10 in a bit..

NM... it just hardlocked while typing this email... back to non-rt and more
testing. :wink:

hostap/wpasuppliant saw a major upgrade: 2.3 -> 2.5

Does this image include the WL183x patches from TI?

Nope, not yet.. I'm watching this tree for patches:

R8.7_RC14
<Gitweb @ Texas Instruments - Open Source Git Repositories - git.TI.com/gitweb - wilink8-wlan/hostap.git/commit;
just
showed up a little bit ago..

Board specific documentation:

BBW/BBB = BeagleBoard.org documentation over usb flash

BBG = seeedstudio.com documentation over usb flash

bonescript 0.5.0-beta with more fixes

I'm assuming beta4. I'll try to get the fix in if using the old cape
manager to continue using the old functions. All should be working better
for the newer kernels.

Correct beta4, but i need to fix

[ 22.276862] bone_capemgr bone_capemgr: part_number 'univ-emmc', version
'N/A'
[ 22.276896] bone_capemgr bone_capemgr: slot #4: override
[ 22.276911] bone_capemgr bone_capemgr: Using override eeprom data at
slot 4
[ 22.276927] bone_capemgr bone_capemgr: slot #4: 'Override Board
Name,00A0,Override Manuf,univ-emmc'
[ 22.464473] of_resolve_phandles: Could not find symbol 'pruss'
[ 22.470418] bone_capemgr bone_capemgr: slot #4: Failed to resolve tree

and stick a pruss node in the default dtb to make things happy for
cape-universal...

nodejs v0.12.x

Wireless AP by default:

SSID: BeagleBone (or) BeagleBone-WXYZ

When would you not have the -WXYZ?

On initial first bootup. Connman is so fast, wifi is already up before our
boot script has time to generate the ssh key's.. After our key's are
generated the ssid get's changed..

And on the x15, when you stick a usb wifi adapter is shows "BeagleBone".. :wink:

PASS: BeagleBone

Can you summarize connman vs. other configs for the various network
connections?

Connman is used by default for:

eth0/wlan0

/etc/network/interfaces is ignored except for the the usb0 values which are
used by the boot script to setup the usb0 network...

*Connman could be used for usb0, but there is no way to reserve
"192.168.7.2"...

Regards,

Eh, it's the same, as it also calls apt.. It just looks at these references
for the latest of each branch:

https://rcn-ee.net/repos/latest/jessie-armhf/

Regards,

r23 fixes this with a quick hack.. (remoteproc_pruss hasn't been merged in
ti's v4.4.x as of today yet..) SO the cape-universal overlay will load..

Regards,

Robert,

Nodejs 4.x is possible on these images yet ?

I was considering getting a Jessie image and backing out of systemd, then attempting to install Nodejs 4.x lts on it.

However if these images are not yet capable of Nodejs 4.x . . . then moving onward to a jessie image does not make so much sense for us.

By “installling” I mean I’ll be compiling my own Nodejs 4.x from source, and creating a package.

There's only one deb* package in the base install that can't handle nodejs
v4.x.

bb-bonescript-installer-beta

remove that, then just change:

/etc/apt/sources.list

deb https://deb.nodesource.com/node_0.12 jessie main
#deb-src https://deb.nodesource.com/node_0.12 jessie main

to

deb https://deb.nodesource.com/node_4.x jessie main
#deb-src https://deb.nodesource.com/node_4.x jessie main

then

apt-get update ; apt-get upgrade

* v4.x fixes:

spi: https://github.com/jadonk/bonescript/pull/126

i2c: something like:

https://github.com/RobertCNelson/bonescript/commit/4a3027d846f4350c7840030d8d9a6872f84da037

i2c was used in ii2.js so that needs to be rewritten...

Regards,

Thanks Robert.

I probably would not need SPI or I2C, as I’d implement my own library. Which is really very easy, as nodejs has a filesystem class object.

I’ll give this a go later as we’re busy out doors taking care of spring things today . . .

Happy to report that this is the first image in a while that has booted correctly on my A5A BBB with the USB “gadget” Ethernet. I’m concerned my particular board has USB hardware issues, but that is a problem for another day.

The START.htm link worked, the simple flash the LEDs bonescript button on the bonescript101 page worked, and cloud9 webpage launched. Node-red seems to work, but still no nod-red-node-beaglebone. These “extra” nodes would seem to be really welcome by newbies.

But, when I tried the fade.js example in cloud9 I got an error:
ocp:P9_14_pinmux was not found under /sys/devices/platform/ocp

While I’m helping my newbie friend, I’ve kind of taken on a role as newbie “out of the box” experience QA/QC tester.
If you don’t want this feedback, I’ll stop posting about it.

I only need one working system for him (and a clone of it for me), the BBG with lxqt image 2016-04-03 and all upgrades and a few fixes from this forum seems more than good enough at this point.

Down the road I’d like to use this old BBB for a PRU project, but I’m a long way from being ready to start on this, maybe by then things will have settled down to one “best supported” way to use the PRU, all this remoteproc vs. uio_pruss makes my head spin, but if I had to choose at the moment I’d pick uio_pruss based on what I’ve found out so far.

So far the image seems good, but perhaps a little large for a console image.

william@beaglebone:~$ sudo df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/mmcblk0p1 1.7G 319M 1.2G 21% /

This is with systemd ripped out and sysv in place. So maybe a bit of stuff that is no longer needed.

One thing I will complain about though. I do not like all the http redirects in the apt repo’s file. Firstly, because I have no idea what that is an alias for, and secondly, I’d prefer to keep everything stock. At minimum, using redirects is not stock. Regardless where they point to. At least security updates are stock, otherwise I would not be so polite here :wink:

So far so good though, and Robert, I will attempt to pull in my own sources for Nodejs 4.2.x, and compile like I normally do. I guess I’ll find out first hand whether that will work or not. Meaning, I wont pull the source in from the debian repo’s I’ll get them directly from Nodejs’s git . . .

So far the image seems good, but perhaps a little large for a console
image.

william@beaglebone:~$ sudo df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/mmcblk0p1 1.7G 319M 1.2G 21% /

This is with systemd ripped out and sysv in place. So maybe a bit of stuff
that is no longer needed.

One thing I will complain about though. I do not like all the http
redirects in the apt repo's file. Firstly, because I have no idea what that
is an alias for, and secondly, I'd prefer to keep everything stock. At
minimum, using redirects is not stock. Regardless where they point to. At
least security updates are stock, otherwise I would not be so polite here :wink:

Here is the details:

http://httpredir.debian.org/

based on your ip, it "could" find a faster connection.

For users in Europe it's been a big help..

So far so good though, and Robert, I will attempt to pull in my own
sources for Nodejs 4.2.x, and compile like I normally do. I guess I'll find
out first hand whether that will work or not. Meaning, I wont pull the
source in from the debian repo's I'll get them directly from Nodejs's git .
. .

Regards,

Happy to report that this is the first image in a while that has booted
correctly on my A5A BBB with the USB "gadget" Ethernet. I'm concerned my
particular board has USB hardware issues, but that is a problem for another
day.

The START.htm link worked, the simple flash the LEDs bonescript button on
the bonescript101 page worked, and cloud9 webpage launched. Node-red seems
to work, but still no nod-red-node-beaglebone. These "extra" nodes would
seem to be really welcome by newbies.

But, when I tried the fade.js example in cloud9 I got an error:
ocp:P9_14_pinmux was not found under /sys/devices/platform/ocp

Yeah, anything talking via pwm to pins needs some patches..

While I'm helping my newbie friend, I've kind of taken on a role as
newbie "out of the box" experience QA/QC tester.
If you don't want this feedback, I'll stop posting about it.

I only need one working system for him (and a clone of it for me), the BBG
with lxqt image 2016-04-03 and all upgrades and a few fixes from this forum
seems more than good enough at this point.

Down the road I'd like to use this old BBB for a PRU project, but I'm a
long way from being ready to start on this, maybe by then things will have
settled down to one "best supported" way to use the PRU, all this
remoteproc vs. uio_pruss makes my head spin, but if I had to choose at the
moment I'd pick uio_pruss based on what I've found out so far.

Regards,

Blah...

https://lists.debian.org/debian-project/2016/04/msg00012.html

When there is a response - and there isn't always - it's usually "nobody
currently maintains httpredir, sorry".

So, it appears as if currently nobody has time or the energy to take
care of httpredir.debian.org properly.

https://lists.debian.org/debian-project/2016/04/msg00018.html

So it was good for a year...

https://lists.debian.org/debian-devel-announce/2015/05/msg00003.html

yuck..

Regards,

Here is the details:

http://httpredir.debian.org/

based on your ip, it “could” find a faster connection.

For users in Europe it’s been a big help…

Ah, ok so something new in the “debian way” world. Thanks :slight_smile: