debian: test images (2014-01-29) (resend with correct topic..)

GoogleGroups
1

Lets keep this going, round 4...

First, for tracking please report all bugs to:
http://bugs.elinux.org/projects/debian-image-releases

Fixes:
3.8.13-bone37 -> 3.8.13-bone39
* rs485 support from Micka
* dir-changeable propery for gpio-of-helper from Charles
* cape-bone-proto from me *(new default pinmux)

New Packages:
python-pip, python-setuptools, python2.7-dev

Fixes:
systemd: limit journal to 8Mb (should fix ever expandign /var/logs issues)
cape-bone-proto loaded on bootup by /etc/default/capemgr
chromium: 32.0.1700.76 -> 32.0.1700.102
nodejs: 0.10.24 -> 0.10.25
https://github.com/beagleboard/am335x_pru_package.git >
/opt/source/am335x_pru_package
multiarch: added /lib/ld-linux.so.3 (for those HelloWorld users with
the wrong gcc "armel" compiler..)
Adafruit_BBIO installed
default apache moved from port 80 to 8080 (bonescript.socket takes over port 80)
"grow_partition.sh" script for users of the microSD image..
* cd /opt/scripts/
* git pull
* ./tools/grow_partition.sh
* sudo reboot
* (after a few minutes, df -h should use the whole disk..)
bonescript-autorun.service enabled

LCD3/LCD4/LCD7 users, xinput_calibrator is installed by default..
Can you please compare 3.8.13-bone36 with 3.8.13-bone39 to test
Micka's touchcreen fix?

I've tried to make it very easy to test via:

cd /opt/scripts/tools
sudo ./update_kernel.sh --kernel v3.8.13-bone36
sudo rm /etc/pointercal.xinput
sudo reboot

cd /opt/scripts/tools
sudo ./update_kernel.sh --kernel v3.8.13-bone39
sudo rm /etc/pointercal.xinput
sudo reboot

So please compare and contrast bone36/bone39, as we really need
testing from users..

Camera people (3.1MP and RadiumBoards):
What userspace programs are we missing? gstreamer? OpenCV plugins?

I really want to include a default shell script that'll take a picture
and allow end users to validate the 3.1/Radium capes work.. (it'll be
installed under /opt/scripts/capes/) Or even some html5 bone101
voodoo and show the image in the browser window?

Questions? Should we switch to connman? (i'm still testing this too..)

To test:
apt-get remove wicd-* --purge
apt-get install connman
(no good gui with connman)

Does your "cape" work?

Does your wifi adapter work? Are we missing it's firmware?

So go forward and test the first "beta" release. There are 3 files on
the web server, depending on what you want to do. Using the same
standard procedure found here:
http://elinux.org/Beagleboard:Updating_The_Software

http://rcn-ee.net/deb/testing/2014-01-29/

3cc218e9303c6823035585364e2de2c0
./BBB-eMMC-flasher-debian-7.3-2014-01-29-2gb.img.xz
d7e00474379a85edcf6385bc9584466c ./bone-debian-7.3-2014-01-29-2gb.img.xz
2d0c043b311cc31bd6286c4c2058b174 ./debian-7.3-lxde-armhf-2014-01-29.tar.xz

An eMMC "flasher" which can be installed to any 2GB or greater microSD
card. [BBB-eMMC-flasher-debian-7.3-2014-01-29-2gb.img.xz]

http://rcn-ee.net/deb/testing/2014-01-29/BBB-eMMC-flasher-debian-7.3-2014-01-29-2gb.img.xz

It takes about 10-15 Minutes to dd microSD (2GB), 15 minutes to flash
eMMC (look for full 4 LED's)

2GB standalone image that can be flashed to any 2GB or greater.
[bone-debian-7.3-2014-01-29-2gb.img.xz]

http://rcn-ee.net/deb/testing/2014-01-29/bone-debian-7.3-2014-01-29-2gb.img.xz

It takes about 10-15 Minutes to dd microSD (2GB)

To resize once booted:
* cd /opt/scripts/
* git pull
* ./tools/grow_partition.sh
* sudo reboot

Finally one of my classic "setup_sdcard.sh".
[debian-7.3-lxde-armhf-2014-01-22.tar.xz]

http://rcn-ee.net/deb/testing/2014-01-29/debian-7.3-lxde-armhf-2014-01-29.tar.xz

Note for users who use my classic "setup_sdcard.sh" script, here is
the magic options to get the beaglebone project files + systemd.

sudo ./setup_sdcard.sh --mmc /dev/sdX --uboot bone
--beagleboard.org-production --enable-systemd

To "rebuild"
git clone git://github.com/beagleboard/image-builder.git
cd image-builder
git checkout bb.org-v2014.01.29 -b tmp
touch release
./beagleboard.org_image.sh

Regards,

2

Lets keep this going, round 4...

First, for tracking please report all bugs to:
http://bugs.elinux.org/projects/debian-image-releases

Fixes:
3.8.13-bone37 -> 3.8.13-bone39
* rs485 support from Micka
* dir-changeable propery for gpio-of-helper from Charles
* cape-bone-proto from me *(new default pinmux)

New Packages:
python-pip, python-setuptools, python2.7-dev

Fixes:
systemd: limit journal to 8Mb (should fix ever expandign /var/logs issues)
cape-bone-proto loaded on bootup by /etc/default/capemgr
chromium: 32.0.1700.76 -> 32.0.1700.102
nodejs: 0.10.24 -> 0.10.25
GitHub - beagleboard/am335x_pru_package >
/opt/source/am335x_pru_package
multiarch: added /lib/ld-linux.so.3 (for those HelloWorld users with
the wrong gcc "armel" compiler..)
Adafruit_BBIO installed
default apache moved from port 80 to 8080 (bonescript.socket takes over
port 80)
"grow_partition.sh" script for users of the microSD image..
* cd /opt/scripts/
* git pull
* ./tools/grow_partition.sh
* sudo reboot
* (after a few minutes, df -h should use the whole disk..)
bonescript-autorun.service enabled

LCD3/LCD4/LCD7 users, xinput_calibrator is installed by default..
Can you please compare 3.8.13-bone36 with 3.8.13-bone39 to test
Micka's touchcreen fix?

I've tried to make it very easy to test via:

cd /opt/scripts/tools
sudo ./update_kernel.sh --kernel v3.8.13-bone36
sudo rm /etc/pointercal.xinput
sudo reboot

cd /opt/scripts/tools
sudo ./update_kernel.sh --kernel v3.8.13-bone39
sudo rm /etc/pointercal.xinput
sudo reboot

So please compare and contrast bone36/bone39, as we really need
testing from users..

Camera people (3.1MP and RadiumBoards):
What userspace programs are we missing? gstreamer? OpenCV plugins?

Cheese was used quite a bit on Angstrom. A good test for OpenCV might be
GitHub - jadonk/stache: OpenCV demo app that adds mustaches to detected faces.

I really want to include a default shell script that'll take a picture
and allow end users to validate the 3.1/Radium capes work.. (it'll be
installed under /opt/scripts/capes/) Or even some html5 bone101
voodoo and show the image in the browser window?

I think doing the bone101 thing makes some sense. OpenROV has a nice
streaming thing. mjpeg-streamer is also an interesting way to do that.

3

This is great, thanks again for your hard work. I’ll take a look tonight.

You had previously mentioned adding .dtbo scripts to the /boot partition (or was it initrd.img) to allow overlays to be detected via EEPROM and loaded without blocking waiting for the emmc cape.

Were you able to get that to work?

Thanks Robert.

-W.

4

That thread was mostly me talking about ways to make it work..

I did add a very trivial load cape at boot time (without modifing
uEnv.txt) script..

https://github.com/beagleboard/image-builder/blob/master/target/init_scripts/capemgr-debian.sh

https://github.com/beagleboard/image-builder/blob/master/target/init_scripts/capemgr

So i just:

echo "CAPE=cape-bone-proto" >> /etc/default/capemgr

and it's autoloaded on the next reboot..

Regards,

5

Robert:

Thanks for putting this up. I have the 2GB SD Image working and, thanks to your easy script, was able to expand it to use my entire 8Gb SD card.
I’m sorry, but I’m still fairly new to this, so forgive me if I’m perplexed by simple things:)

On my older Debian install, based on your eewiki from a few months ago, I was able to add both Dallas 1wire support and also enable the ADC’s by adding the following line to uEnv.txt

optargs=capemgr.enable_partno=BB-ADC,BB-W1

I already had compiled the BB-W1-00A0.dtbo based on HipsterCircuits blog example, and copied it to /lib/firmware
This worked fine on the older Debian SD version
But on today’s new one, only the BB-ADC gets loaded into slot. I also tried only loading BB-W1, and only BB-ADC, and again, only BB-ADC works.
The thing that confuses me is that if instead, after loading BB-ADC via uEnv.txt, I am in /lib/firmware and issue:

echo BB-W1:00A0 > /sys/devices/bone_capemgr.9/slots

I then see that the BB-W1 overlay has been loaded and the one-wire temp sensor works as expected.

Any clues? Thanks

John

6

Thanks, it's working fine on my BBB using the setup_sdcard.sh approach. I'm
also using the latest 3.13 kernel:

Linux markbbb 3.13.0-bone5 #1 SMP Sat Jan 25 01:06:55 UTC 2014 armv7l
GNU/Linux

The only issue I noticed was several 404 errors from the bone101 website.

Mark

7

Which init script is enabled by default ?

Do we have a choice of what init system to use ?

Is this image also coming with a X server and desktop manager or it can be used as a minimal console only ?

8

I'm not sure why, capemgr.enable_partno hasn't been as reliable..

Just edit /etc/default/capemgr and replace the one define to "BB-W1" *
and reboot.. it should load your BB-W1 on the next boot..

* Only one cape is support at this point, it was a quick hack..

See:

https://github.com/beagleboard/image-builder/blob/master/target/init_scripts/capemgr-debian.sh
https://github.com/beagleboard/image-builder/blob/master/target/init_scripts/capemgr

Regards,

9

Which init script is enabled by default ?

The ones i enable..

Do we have a choice of what init system to use ?

systemd: unless you disable it..

Is this image also coming with a X server and desktop manager or it can be
used as a minimal console only ?

It includes lxde, but you could remove it easily..

But I think your missing the point of this Image, so go read:

The purpose of this image is to TEST what the next default image will
be on the boards shipped.

If your doing something custom, take a look here:

http://elinux.org/BeagleBoardDebian#Demo_Image

For a more minimal image..

Regards,

10

So presumably, this isn’t detecting capes via EEPROM; it’s effectively the equivalent of doing:

echo cape-bone-proto > /sys/devices/bone_capemgr.9/slots

In a startup script?

11

So presumably, this isn't detecting capes via EEPROM; it's effectively the
equivalent of doing:

echo cape-bone-proto > /sys/devices/bone_capemgr.9/slots

In a startup script?

Yeap.

Regards,

12

Ok, so I’m still interested in getting my overlay loaded at boot time via EEPROM. Could you elaborate on your ideas about using initrd.img to store the .dtbo files?

Thanks!

13

Robert:

Sorry to bug you again, but I’ve been hunting and hunting and can’t figure out where two things concerning apache2 in this testing image:

  1. where is the very generic default webpage that I see when go to http://my BBB’s URL:8080 located in the file system? It’s not in /var/www

  2. where does the default port for the apache3 server get changed to :8080 from the normal :80? I don’t use bone script and would like to have apache2 use port 80

Thanks

John

14

Robert:

Sorry to bug you again, but I've been hunting and hunting and can't figure
out where two things concerning apache2 in this testing image:

1) where is the very generic default webpage that I see when go to
http://my BBB's URL:8080 located in the file system? It's not in /var/www

It's /var/www in 2014-01-29

2) where does the default port for the apache3 server get changed to :8080
from the normal :80? I don't use bone script and would like to have apache2
use port 80

sudo systemctl disable bonescript.socket
sudo sed -i -e 's:8080:80:g' /etc/apache2/ports.conf
sudo sed -i -e 's:8080:80:g' /etc/apache2/sites-enabled/000-default
sudo /etc/init.d/apache2 restart

Regards,

15

Thank you!! You are so helpful. I really appreciate it

John

16

I’ve been having fun playing with the new images. So far things have worked well, but something new has popped up on the latest image that wasn’t there before.

I’m using bonescript and I get a failure if I try to use certain pins (P9_42 and P9_21) that worked in the earlier images.

On the first call to bonescript, via node, the following appears in dmesg

[ 189.216738] bone-capemgr bone_capemgr.9: part_number ‘bspm_P9_41_27’, version ‘N/A’
[ 189.216916] bone-capemgr bone_capemgr.9: slot #8: generic override
[ 189.216935] bone-capemgr bone_capemgr.9: bone: Using override eeprom data at slot 8
[ 189.216953] bone-capemgr bone_capemgr.9: slot #8: ‘Override Board Name,00A0,Override Manuf,bspm_P9_41_27’
[ 189.217067] bone-capemgr bone_capemgr.9: slot #8: Requesting part number/version based 'bspm_P9_41_27-00A0.dtbo
[ 189.217085] bone-capemgr bone_capemgr.9: slot #8: Requesting firmware ‘bspm_P9_41_27-00A0.dtbo’ for board-name ‘Override Board Name’, version ‘00A0’
[ 189.219961] bone-capemgr bone_capemgr.9: slot #8: dtbo ‘bspm_P9_41_27-00A0.dtbo’ loaded; converting to live tree
[ 189.220349] bone-capemgr bone_capemgr.9: slot #8: #2 overlays
[ 189.225997] bone-capemgr bone_capemgr.9: slot #8: Applied #2 overlays.

bonescript appears to work fine unless I do something like:

b.pinMode(‘P9_42’, b.INPUT);

Then it fails.

Any idea what’s changed, or how to fix it?

–Mark

17

It was requested by bb.org to enable a new default pinmux:

http://elinux.org/CircuitCo:Basic_Proto_Cape

So, P9.42 & P9.21 are now used by default.

For compatibity sake, i just set this up in a new overlay.. So it's
easy to disable..

sudo sed -i -e 's:CAPE=cape-bone-proto:#CAPE=cape-bone-proto:g'
/etc/default/capemgr
sudo reboot

Regards,

18

Robert, thanks for the quick response, that did it.
Two more questions:

  1. Do you have an idea when cloud9 will be back?
  2. Do you have a guess as to when the image will be stable? I’m scheduled to give a BeagleWorkshop to some faculty on 7-March and am wondering if I should plan on using the new Debian image.
    –Mark
19

Robert, thanks for the quick response, that did it.
Two more questions:

Do you have an idea when cloud9 will be back?

I'm hoping pretty soon.. Just waiting for the version compatible with
the node v0.10.x to be pushed to github.

Do you have a guess as to when the image will be stable?

After cloud9 gets added.. I believe that was the last major blocker
for 1 to 1 compatibility with the old Angstrom image. Other then
doc's..

There was one kernel fix (usb-gadget stuff filling /var/log/) just update via

cd /opt/scripts
git pull
./tools/update_kernel.sh

I'm scheduled to
give a BeagleWorkshop to some faculty on 7-March and am wondering if I
should plan on using the new Debian image.

Oh definitely before that timeframe..

Regards,

20

Another question (perhaps request) Since systems is now functional as well as the older style init.d scripts, and systemctl, where is journalctl? It is so useful and convenient…
Thanks