debian: test images (2014-02-24) Cloud9 BETA!

GoogleGroups
1

So here’s a special gift from Jason, Cloud9 on node 0.10.x

So, can we call it an RC? :wink:

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

Kernel:
3.8.13-bone40

Changes:
npm/nodejs/libsoc all from: beagle.s3.amazonaws.com/debian now.

Cloud9:
http://beaglebone.local:3000/
Note, there’s a last minute glaring Cloud9/Debugging bug, any demo once ran, just stops in the debugger

http://elinux.org/Beagleboard:Updating_The_Software

http://rcn-ee.net/deb/testing/2014-02-24/

8f8955574329c6b17b7c515cac9798f3 ./BBB-blank-eMMC-flasher-debian-7.4-2014-02-24-2gb.img.xz
98bef60e1494fa5dca4bb65b76365fda ./BBB-eMMC-flasher-debian-7.4-2014-02-24-2gb.img.xz
95ec80f131f5e8f1ca4833d5c6acb8fe ./bone-debian-7.4-2014-02-24-2gb.img.xz
c08a919876d02d71fcfebd01c502a9d5 ./debian-7.4-lxde-armhf-2014-02-24.tar.xz

The “blank flasher” this is for eeprom less beaglebone blacks, do NOT run on a classic beaglebone white. (this is designed to flash factory blank boards)

An eMMC “flasher” which can be installed to any 2GB or greater microSD
card. [BBB-eMMC-flasher-debian-7.4-2014-02-24-2gb.img.xz]

http://rcn-ee.net/deb/testing/2014-02-24/BBB-eMMC-flasher-debian-7.4-2014-02-24-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.4-2014-02-24-2gb.img.xz]

http://rcn-ee.net/deb/testing/2014-02-24/bone-debian-7.4-2014-02-24-2gb.img.xz

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

To resize once booted:

  • cd /opt/scripts/
  • ./tools/grow_partition.sh
  • sudo reboot

Finally one of my classic “setup_sdcard.sh”.
[debian-7.4-lxde-armhf-2014-02-24.tar.xz]

http://rcn-ee.net/deb/testing/2014-02-24/debian-7.4-lxde-armhf-2014-02-24.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-02-24 -b tmp
touch release
./beagleboard.org_image.sh

2

You didn’t actually make the “bb.org-v2014-02-24” tag.
And just for my own curiosity, how long are we going to be stuck with the obsolete 3.8 kernel? I’ve seen some things here using the bleeding-edge 3.13, but nothing with the reasonably stable and current 3.12.

3

You didn't actually make the "bb.org-v2014-02-24" tag.

It's there:

And just for my own curiosity, how long are we going to be stuck with the
obsolete 3.8 kernel?

As soon as there is a working solution to support all xyz capes.

I've seen some things here using the bleeding-edge
3.13, but nothing with the reasonably stable and current 3.12.

3.14-rc4 bleeding edge.. I've been pushing v3.13 over v3.12 in the
repo for awhile now..

http://rcn-ee.net/deb/wheezy-armhf/LATEST-omap-psp
"TESTING"

to install it just:

cd /opt/scripts/
git pull
./tools/update_kernel.sh --beta-kernel
reboot

Regards,

4

It’s nice to have cloud9 back. I even have the latest prerelease of Mathematica running on it.

–Mark

5

Robert:
When I plug in an HDMI monitor into my BBB, a black background appears with the beagleboard.org logo on the bottom right, but it never get further. I take the same SD card and plug it into a BBW with an LCD attached, and a desktop appears and everything works as I expect. Below is the tail of dmesg and cat $SLOTS

How do I get the desktop to appear on the HDMI monitor?

–Mark

[ 25.101322] bone-capemgr bone_capemgr.9: slot #7: ‘Override Board Name,00A0,O
verride Manuf,bspm_P9_42_27’
[ 25.101429] bone-capemgr bone_capemgr.9: slot #7: Requesting part number/vers
ion based 'bspm_P9_42_27-00A0.dtbo
[ 25.101447] bone-capemgr bone_capemgr.9: slot #7: Requesting firmware ‘bspm_P
9_42_27-00A0.dtbo’ for board-name ‘Override Board Name’, version ‘00A0’
[ 25.105623] bone-capemgr bone_capemgr.9: slot #7: dtbo ‘bspm_P9_42_27-00A0.dt
bo’ loaded; converting to live tree
[ 25.106516] bone-capemgr bone_capemgr.9: slot #7: #2 overlays
[ 25.117970] bone-capemgr bone_capemgr.9: slot #7: Applied #2 overlays.
[ 25.178994] bone-capemgr bone_capemgr.9: part_number ‘bspm_P9_41_27’, version
‘N/A’
[ 25.179073] bone-capemgr bone_capemgr.9: slot #8: generic override
[ 25.179092] bone-capemgr bone_capemgr.9: bone: Using override eeprom data at
slot 8
[ 25.179110] bone-capemgr bone_capemgr.9: slot #8: ‘Override Board Name,00A0,O
verride Manuf,bspm_P9_41_27’
[ 25.179329] bone-capemgr bone_capemgr.9: slot #8: Requesting part number/vers
ion based 'bspm_P9_41_27-00A0.dtbo
[ 25.179348] bone-capemgr bone_capemgr.9: slot #8: Requesting firmware ‘bspm_P9_41_27-00A0.dtbo’ for board-name ‘Override Board Name’, version ‘00A0’
[ 25.184291] bone-capemgr bone_capemgr.9: slot #8: dtbo ‘bspm_P9_41_27-00A0.dtbo’ loaded; converting to live tree
[ 25.184585] bone-capemgr bone_capemgr.9: slot #8: #2 overlays
[ 25.196180] bone-capemgr bone_capemgr.9: slot #8: Applied #2 overlays.
[ 25.218431] bone-capemgr bone_capemgr.9: part_number ‘bspm_P9_21_27’, version ‘N/A’
[ 25.218507] bone-capemgr bone_capemgr.9: slot #9: generic override
[ 25.218526] bone-capemgr bone_capemgr.9: bone: Using override eeprom data at slot 9
[ 25.218544] bone-capemgr bone_capemgr.9: slot #9: ‘Override Board Name,00A0,Override Manuf,bspm_P9_21_27’
[ 25.218642] bone-capemgr bone_capemgr.9: slot #9: Requesting part number/version based 'bspm_P9_21_27-00A0.dtbo
[ 25.218659] bone-capemgr bone_capemgr.9: slot #9: Requesting firmware ‘bspm_P9_21_27-00A0.dtbo’ for board-name ‘Override Board Name’, version ‘00A0’
[ 25.229022] bone-capemgr bone_capemgr.9: slot #9: dtbo ‘bspm_P9_21_27-00A0.dtbo’ loaded; converting to live tree
[ 25.229332] bone-capemgr bone_capemgr.9: slot #9: #2 overlays
[ 25.233659] bone-capemgr bone_capemgr.9: slot #9: Applied #2 overlays.
[ 28.646589] EXT4-fs (mmcblk1p2): mounted filesystem with ordered data mode. Opts: (null)
[ 29.112485] net eth0: initializing cpsw version 1.12 (0)
[ 29.115514] net eth0: phy found : id is : 0x7c0f1
[ 29.115642] libphy: PHY 4a101000.mdio:01 not found
[ 29.120677] net eth0: phy 4a101000.mdio:01 not found on slave 1
[ 29.134176] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready

cat $SLOTS
0: 54:PF—
1: 55:PF—
2: 56:PF—
3: 57:PF—
4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
7: ff:P-O-L Override Board Name,00A0,Override Manuf,bspm_P9_42_27
8: ff:P-O-L Override Board Name,00A0,Override Manuf,bspm_P9_41_27
9: ff:P-O-L Override Board Name,00A0,Override Manuf,bspm_P9_21_27

6

Robert:
I see this image is running the 3.8.13-bone40 kernel. I followed your online instructions a few months ago and was successful in compiling an earlier version of the kernel. What’s the process for bringing the months-old kernel sources up to date and merging my changes so I’ll be compiling the 3.8.13-bone40 kernel?

–Mark

7

cd /opt/scripts/
git pull
./tools/update_kernel.sh --beta-kernel
reboot

Thanks, it’s working well, but I can’t seem to find the source for it on any of your Github repositories. Is this really just a mainline kernel compiled with the given config and dts with no patches? If so, that’s great, I’ll just download the kernel from the source (perhaps even a different version) and go to town. But my previous kernel-building (mostly with Angstrom) always involved patches or other complications.

8

Every deb "release" is tagged, usually from one of 3 branches on:

https://github.com/RobertCNelson/linux-dev

Regards,

9

Awesome thanks for this image, I’ve been trying to update Cloud9 on my previous install with next to zero luck on either the Angstrom or Debian releases and this build seems to do the trick.

My own efforts to eliminate the debugging console issue in this build have also been futile, is there a work-around or a fix available yet? In the mid-term Resume (F8) seems to work, but it would be nice to be able to bypass the debugging console all-together like in previous releases.

10

Does this image contain all the patches that are in your linux-dev git repository?
I have problems installing them and image would save my time.
Kind Regards

11

Define "all":

The: "2014-05-14" release at http://beagleboard.org/latest-images

contains the "v3.8.13-bone50" kernel which is tagged in the linux-dev repo.

Regards,

12

Hi Robert.
I have got BBB and wired in RS485 receiver (MAX13487EESA+, has got auto redirection).
Started to do test with libmodbus and that I have found out that I need a RS485 patch for my BBB.
My original kernel was 3.8.13-bone56.
I found your git repository for linux-dev for version 3.8.13-bone53.
There are many patches listed there (including RS485) so I thought, ok, would be nice to have them all.
I have installed this kernel using:
wget https://rcn-ee.net/deb/wheezy-armhf/v3.8.13-bone53/install-me.sh

then I did:
git clone git://github.com/RobertCNelson/linux-dev.git

copied system.sh sample to system.sh
then
git checkout am33x-v3.8 (I have no idea what it does)

then ./build_kernel
First I had some problems with xt_tcpmss.c and some other files, error saying that I have modified them already :slight_smile: yeah, right, would be nice if I could :slight_smile:
but have entered KERNEL folder and typed:

git reset --soft HEAD^
git stash

(found on some website, have no idea what it does)
that solved this problem but when your script starts patching, I have got error just at the first patch:

Applying: Without MACH_ option Early printk (DEBUG_LL)
error: arch/arm/mach-omap2/Kconfig: does not match index
Patch failed at 0001 Without MACH_ option Early printk (DEBUG_LL)
When you have resolved this problem run “git am --resolved”.
If you would prefer to skip this patch, instead run “git am --skip”.
To restore the original branch and stop patching run “git am --abort”.

I even edited patch.sh and commented first pacth, then build_kernel process fails on the second patch.

I spent 4 days crawling through internet, building, stashing, cloning almost everything you have got on github and I couldn’t make it work.

It would be nice to have ./build_kernel working properly, but It looks like am not skilled enough to do this.

It is very nice to receive reply from you. Will it be possible for you to guide me through ./build_kernel.sh process?
Any known website which explains it completely?
What I would like to have is the most up to date kernel for BBB (with cape manager) alongside with the patches that exist and are not implemented in this kernel.

Thank you
Artur

P.S

I thought that for RS485 it would be nice to download any image which have all patches included.
I will then face another problem in the future as I need to test CANBUS and J1939 stack, so back to build_kernel.sh again.

that is what I have got:

root@arm:/mnt/mstick/linux-dev# ./build_kernel.sh

  • Detected build host [Debian GNU/Linux 7.5 (wheezy)]
  • host: [armv7l]
  • git HEAD commit: [4131cd2e8f782a718efac625b7100b94c872e7b9]
13

Second ago I followed your directions from http://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-Debian7:

Will take a while, but maybe this is going to work

git clone https://github.com/RobertCNelson/bb-kernel.git
cd bb-kernel/
git checkout origin/am33x-v3.8 -b tmp
./build_kernel.sh

14

From your previous message, i see your building it natively on the
beaglebone black. The script will download 2-3Gb of data from
kernel.org.

The "./build_kernel.sh" script is setup to always work, but when run
natively, sometimes git has troubles (those unstage error messages) on
wheezy.

Regards,

15

Hi Robert.
I have got 8GB memory stick in BB and I clone to this memory stick.
Sorry for dumb question, what does it mean natively and how to do this not natively?
:slight_smile:
build_kernel from bb-kernel behaves exactly the same as build_kernel from linux-dev
Thank you for all your help
Kind REgards

16

Hi Robert.
I have got 8GB memory stick in BB and I clone to this memory stick.
Sorry for dumb question, what does it mean natively and how to do this not
natively?
:slight_smile:

Natively = running the build script on the same hardware platform you
are going to run the kernel on it.

build_kernel from bb-kernel behaves exactly the same as build_kernel from
linux-dev

Yeap, my previous statement still stands. For some people, git just
fails for them when running natively. I haven't been able to
re-produce it, as it works for me. Besides i do most of my kernel
maintenance on x86, where the script works fine.

So just grab the kernel patch + config and build it the old way on your target.

Everything you need is on the host server:
http://rcn-ee.net/deb/wheezy-armhf/v3.8.13-bone59/

Regards,

17

:slight_smile: Thank you very much Robert.
old way will be new way for me.
Do you know any website where I can read what needs to be done?
Kind Regards

18

Maybe i need to be more verbose on this. i wrote the script, such that
i wouldn't have to look that info up. :wink:

Just fire up an x86 linux machine and run the script.

Regards,

19

Hi Robert.
That is what I probably will do. Have got spare laptop
Just one more question.
This patch-3.8.13-bone59.diff.gz file, does it contain all the patches (including RS485) inside?
Kind Regards

20

It includes all the patches enabled in "patch.sh" with that tag, against 3.8.13

Regards,