debian: test images (2014-01-10)

[Robert Nelson]

It's Friday and everyone is probally kicking back and enjoying a cold
beverage... Well enough of that crap, time to start actually testing
something... ;)

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

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

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

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

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

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

http://rcn-ee.net/deb/testing/2014-01-10/bone-debian-7.3-2014-01-10-4gb.img.xz
096915309ec4a8fe41b1e8076a0c436b bone-debian-7.3-2014-01-10-4gb.img.xz

It takes about 20-30 Minutes to dd microSD (4GB)

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

http://rcn-ee.net/deb/testing/2014-01-10/debian-7.3-console-armhf-2014-01-10.tar.xz
526adb40799a8e060df020ed1cd47c12 debian-7.3-console-armhf-2014-01-10.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.10 -b tmp
./beagleboard.org_image.sh

Thoughts/rants/list/etc?

Go Test!

--
Robert Nelson
http://www.rcn-ee.com/

[Robert Nelson]

Laughs, gmail broke every link..

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

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

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

Regards,

[David Lambert]

On 01/10/2014 04:11 PM, Robert Nelson wrote:
>
> 4GB standalone image that can be flashed to any 4GB or greater.
> [bone-debian-7.3-2014-01-10-4gb.img.xz]
>
> http://rcn-ee.net/deb/testing/2014-01-10/bone-debian-7.3-2014-01-10-4gb.img.xz
> 096915309ec4a8fe41b1e8076a0c436b bone-debian-7.3-2014-01-10-4gb.img.xz
>
> It takes about 20-30 Minutes to dd microSD (4GB)
>

OK It only took my system a tad over 8 minutes to a Transcend 8G SD:
time xzcat
/home/dlambert/downloads/bone-debian-7.3-2014-01-10-4gb.img.xz | dd
bs=10M of=/dev/sdc
0+345858 records in
0+345858 records out
3932160000 bytes (3.9 GB) copied, 493.82 s, 8.0 MB/s

real 8m13.823s
user 0m38.910s
sys 0m6.756s

First impressions great, came right up systemd, avahi, etc. I will keep
on testing over the weekend.

BTW is the kernel the same as the default in
git://github.com/RobertCNelson/linux-dev.git?

Any hints yet on how to handle pinmux GPIO etc. now that capemgr is not
yet there?

Regards,

Dave.

[David Lambert]

On 01/10/2014 04:11 PM, Robert Nelson wrote:

> It's Friday and everyone is probally kicking back and enjoying a cold
> beverage... Well enough of that crap, time to start actually testing
> something... ;)
>
> First, for tracking please report all bugs to:
> http://bugs.elinux.org/projects/debian-image-releases
>

OK I registered, but awaiting approval. In the meantime, I got the
following:

Uncompressing Linux... done, booting the kernel.
[ 0.369399] omap2_mbox_probe: platform not supported
[ 0.526579] tps65217-bl tps65217-bl: no platform data provided
[ 0.591595] bone-capemgr bone_capemgr.9: slot #0: No cape found
[ 0.628702] bone-capemgr bone_capemgr.9: slot #1: No cape found
[ 0.665810] bone-capemgr bone_capemgr.9: slot #2: No cape found
[ 0.702918] bone-capemgr bone_capemgr.9: slot #3: No cape found
[ 0.718940] bone-capemgr bone_capemgr.9: slot #6: BB-BONELT-HDMIN
conflict P8.45 (#5:BB-BONELT-HDMI)
[ 0.728585] bone-capemgr bone_capemgr.9: slot #6: Failed verification
[ 0.735360] bone-capemgr bone_capemgr.9: loader: failed to load
slot-6 BB-BONELT-HDMIN:00A0 (prio 2)
[ 0.752808] omap_hsmmc mmc.5: of_parse_phandle_with_args of 'reset'
failed
[ 0.814570] pinctrl-single 44e10800.pinmux: pin 44e10854 already
requested by 44e10800.pinmux; cannot claim for gpio-leds.8
[ 0.826308] pinctrl-single 44e10800.pinmux: pin-21 (gpio-leds.8)
status -22
[ 0.833623] pinctrl-single 44e10800.pinmux: could not request pin 21
on device pinctrl-single

Don't know whether this is a bug or not, but I am also a bit confused as
I thought the capemgr was not yet in 3.13....?

Dave.

[Robert Nelson]

On Fri, Jan 10, 2014 at 5:09 PM, David Lambert <da...@lambsys.com> wrote:
> On 01/10/2014 04:11 PM, Robert Nelson wrote:
>>
>>
>> 4GB standalone image that can be flashed to any 4GB or greater.
>> [bone-debian-7.3-2014-01-10-4gb.img.xz]
>>
>>
>> http://rcn-ee.net/deb/testing/2014-01-10/bone-debian-7.3-2014-01-10-4gb.img.xz
>> 096915309ec4a8fe41b1e8076a0c436b bone-debian-7.3-2014-01-10-4gb.img.xz
>>
>> It takes about 20-30 Minutes to dd microSD (4GB)
>>
> OK It only took my system a tad over 8 minutes to a Transcend 8G SD:

Should i also push out a 8GB image? it's all zero's and it just
compresses very well..

> time xzcat /home/dlambert/downloads/bone-debian-7.3-2014-01-10-4gb.img.xz |
> dd bs=10M of=/dev/sdc
> 0+345858 records in
> 0+345858 records out
> 3932160000 bytes (3.9 GB) copied, 493.82 s, 8.0 MB/s
>
> real 8m13.823s
> user 0m38.910s
> sys 0m6.756s
>
> First impressions great, came right up systemd, avahi, etc. I will keep on
> testing over the weekend.
>
> BTW is the kernel the same as the default in
> git://github.com/RobertCNelson/linux-dev.git?

specifially: 3.8.13-bone35

>
> Any hints yet on how to handle pinmux GPIO etc. now that capemgr is not yet
> there?

By default it's still 3.8 so that all books/guides/etc written for
Angstrom work.. Down the road it'll be v3.13..

Regards,

[Robert Nelson]

That same error occurs on angstrom's 3.8.. HDMI no audio is trying to
load on top of hdmi with audio...

Regards,

[David Lambert]

On 01/10/2014 05:36 PM, Robert Nelson wrote:
>
> Should i also push out a 8GB image? it's all zero's and it just
> compresses very well..
>

I know but I think most of the time is writing to the SD, so it would be
nice if there was a good way to resize the root using parted or something?

> specifially: 3.8.13-bone35
>
>> Any hints yet on how to handle pinmux GPIO etc. now that capemgr is not yet
>> there?
> By default it's still 3.8 so that all books/guides/etc written for
> Angstrom work.. Down the road it'll be v3.13..

Yes, I know how to do that on 3.8, but I'm lost with 3.13. Looks like I
will have to roll my own pinmux for now to get the USB improvements ;)
Regards,
>

[David Lambert]

On 01/10/2014 05:52 PM, David Lambert wrote:
> On 01/10/2014 05:36 PM, Robert Nelson wrote:
>>
>> Should i also push out a 8GB image? it's all zero's and it just
>> compresses very well..
>>
> I know but I think most of the time is writing to the SD, so it would
> be nice if there was a good way to resize the root using parted or
> something?

I just used parted - it worked fine:
root@beaglebone:~# df
Filesystem 1K-blocks Used Available Use% Mounted on
rootfs 7537984 1220976 5930864 18% /
udev 10240 0 10240 0% /dev
tmpfs 101464 548 100916 1% /run
/dev/mmcblk0p2 7537984 1220976 5930864 18% /
tmpfs 253652 0 253652 0% /dev/shm
tmpfs 253652 0 253652 0% /sys/fs/cgroup
tmpfs 102400 0 102400 0% /run/user
tmpfs 5120 0 5120 0% /run/lock
/dev/mmcblk0p1 98094 70260 27834 72% /boot/uboot

[David Lambert]

On 01/10/2014 04:11 PM, Robert Nelson wrote:

> It's Friday and everyone is probally kicking back and enjoying a cold
> beverage... Well enough of that crap, time to start actually testing
> something... ;)
>
> First, for tracking please report all bugs to:
> http://bugs.elinux.org/projects/debian-image-releases
>

Still not confirmed on the bug tracker, but I see this panic on halt:

root@beaglebone:~# halt

Broadcast message from root@beaglebone (ttyO0) (Fri Jan 10 17:17:21 2014):
The system is going down for system halt NOW!
root@beaglebone:~# Sending SIGTERM to remaining processes...
Sending SIGKILL to remaining processes...
Unmounting file systems.
Unmounted /sys/fs/fuse/connections.
Unmounted /dev/mqueue.
Unmounted /sys/kernel/debug.
Unmounted /sys/kernel/security.
Disabling swaps.
Detaching loop devices.
Detaching DM devices.
[ 40.057138] (NULL device *): gadget not registered.
[ 40.072972] Power down.
[ 40.079180] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x00000000
[ 40.079180]
[ 40.088830] [<c0013270>] (unwind_backtrace+0x0/0xe0) from
[<c0630514>] (panic+0x84/0x1e0)
[ 40.097438] [<c0630514>] (panic+0x84/0x1e0) from [<c0040364>]
(do_exit+0x470/0x88c)
[ 40.105501] [<c0040364>] (do_exit+0x470/0x88c) from [<c004ed30>]
(sys_reboot+0x128/0x1b4)
[ 40.114106] [<c004ed30>] (sys_reboot+0x128/0x1b4) from [<c000d580>]
(ret_fast_syscall+0x0/0x30)
[ 40.123242] drm_kms_helper: panic occurred, switching back to text
console


Regards,

Dave.

[Michael Long]

Is this beta specifically for the Beaglebones or should it work on the Beagleboard xM?  I tried the setup_sdcard.sh method, substituting "--uboot beagle_xm", but the resulting card didn't get very far in the boot process.

  -Michael

[Robert Nelson]

On Sat, Jan 11, 2014 at 4:37 PM, Michael Long <nik...@gmail.com> wrote:
> Is this beta specifically for the Beaglebones or should it work on the
> Beagleboard xM? I tried the setup_sdcard.sh method, substituting "--uboot
> beagle_xm", but the resulting card didn't get very far in the boot process.

Just the BeagleBone... The 'script' supports many different boards,
however this image only contains the kernel for the BeagleBone..

The "xM" is already fully supported here:
http://elinux.org/BeagleBoardDebian#Demo_Image

This beta is specifically addressing:
http://beagleboard.org/blog/2014-01-04-happy-new-year/

Regards,

[Walter Schilling]

Robert:

Downloaded this build and have started playing with it.  So far so good.  That being said, I'm running into a slight issue.  I've got a small issue that I'm not sure how to fix with Debian.  I'm using the LCD7 with the black, and it is out of calibration.  On the angstrom image, there was a calibration tool I could run, but I'm not seeing on the Debian port.  Am I missing something obvious or just being clueless about how to do this with Debian?

[Robert Nelson]

On Sun, Jan 12, 2014 at 9:55 PM, Walter Schilling <schi...@msoe.edu> wrote:
> Robert:
>
> Downloaded this build and have started playing with it. So far so good.
> That being said, I'm running into a slight issue. I've got a small issue
> that I'm not sure how to fix with Debian. I'm using the LCD7 with the
> black, and it is out of calibration. On the angstrom image, there was a
> calibration tool I could run, but I'm not seeing on the Debian port. Am I
> missing something obvious or just being clueless about how to do this with
> Debian?

xinput
( http://packages.debian.org/wheezy/xinput )

Is installed by default, i just don't have it setup yet to run when
the system detects an lcd..

[Robert Nelson]

Just added this as:
http://bugs.elinux.org/issues/39

(i'm not sure how to approve people to the bug tracker either..)

I can confirm the issue on my board too..

However, since the board does actually shutdown. (5volt 0amps) I think
we'll just leave that bug. wonder if it exists in 3.13-rc8?

Regards,

[Bas Laarhoven]

FYI: I've been getting the same oops (other adresses, same symbols) with
Angstrom for ages.
Since it seems to shut down properly and doesn't cause any fs issues,
I've ignored it thus far.

-- Bas

[David Lambert]

Just tried a quick test on 3.13-rc8 - no panic, but no shutdown either!

Regards,

>
> Regards,
>

[Robert Nelson]

>
> Just tried a quick test on 3.13-rc8 - no panic, but no shutdown either!

and no xorg...

been hacking on it all morning.. regression from v3.12.x

[Louis McCarthy]

Thanks for all of your hard work Robert!

Not sure if this is really a "bug" or more of a optimization.

I downloaded and installed (via Win32 Disk Imager) the eMMC Flasher to a 4 Gb Kingston card. When I booted the new card on a BBB A5A, it loaded all the way into the GUI, performed the rsync, and then the lights went solid.

My question is, is it necessary to boot the flasher all the way into the GUI? It may shave a couple minutes off of the "flash" time by limiting the run level.

Another interesting note, is that once the rsync is done and the lights all go solid, the GUI is still responsive and usable. I guess I was assuming that it would go to a halt state. Once again, not a problem, just a comment.

On to the live tests.....

Louis

[Robert Nelson]

On Wed, Jan 15, 2014 at 9:05 AM, Louis McCarthy <comp...@gmail.com> wrote:
> Thanks for all of your hard work Robert!
>
> Not sure if this is really a "bug" or more of a optimization.
>
> I downloaded and installed (via Win32 Disk Imager) the eMMC Flasher to a 4
> Gb Kingston card. When I booted the new card on a BBB A5A, it loaded all the
> way into the GUI, performed the rsync, and then the lights went solid.
>
> My question is, is it necessary to boot the flasher all the way into the
> GUI? It may shave a couple minutes off of the "flash" time by limiting the
> run level.

Well, I guess we could get a little more creative with the image.
I've kept to really simple... Right now the only difference between
the dd/microSD image with the dd/flasher is one file in the boot
partition..

/boot/uboot/flash-eMMC.txt

https://github.com/beagleboard/image-builder/blob/master/scripts_device/boot/am335x_evm.sh#L56

Otherwise the biggest cpu hog was actually the screensaver. (xorg/lxde
wasn't too resource intensive..)

Which i've now disabled by default:

https://github.com/beagleboard/image-builder/commit/6fe60d9a2f28d8f9f28747fd05f3cb0c96ef61ed

So when i push out new image this week, it should shave a few more
minutes.. (even without that change it's still not the 45 minutes it
took Angstrom.. ;) )

> Another interesting note, is that once the rsync is done and the lights all
> go solid, the GUI is still responsive and usable. I guess I was assuming
> that it would go to a halt state. Once again, not a problem, just a comment.

Do we want it to "halt" ? I wish we could "eject" the microSD, as if
we halt, the user is just probably going to hit the power button and
the flash starts all over..

Regards,

[Louis McCarthy]

I'm all for simple. 

I wan't going to mention the screen saver, but now that you did, I think that is a good call. The other option would be to extend the delay to 15 minutes, instead of disabling it entirely, but I would rather see it disabled.

Yeah, no complaints from me compared to the Angstrom eMMC flasher :)

If nothing is being written to the uSD, then a halt is not necessary. I would just go with whatever would be the most reliable/simple.

Louis

[Robert Nelson]

On Wed, Jan 15, 2014 at 10:13 AM, Louis McCarthy <comp...@gmail.com> wrote:
> I'm all for simple.
>
> I wan't going to mention the screen saver, but now that you did, I think
> that is a good call. The other option would be to extend the delay to 15
> minutes, instead of disabling it entirely, but I would rather see it
> disabled.

The screensaver was also causing an annoying 'flash' for me, as lxde
seems to fully loaded about 2 seconds before ntp would get the updated
time info. (thus turning on the screen saver..)

> Yeah, no complaints from me compared to the Angstrom eMMC flasher :)
>
> If nothing is being written to the uSD, then a halt is not necessary. I
> would just go with whatever would be the most reliable/simple.

Yeah once the led flash full, we are 100% done with the eMMC, it's
fully synced/umounted/etc. Pretty much safe to just yank power and
pull out the microSD with no ill effects to the eMMC..

[Louis McCarthy]

I am awaiting approval in the bug tracker, but I saw your comment related to Wicd/Connman. If I remember correctly, there were issues with multiple connections (wired and wireless) and DHCP (only assigned an IP to the first adapter) with connman. Not sure if those were resolved.

Louis

On Wednesday, January 15, 2014 9:23:59 AM UTC-6, RobertCNelson wrote:

[Robert Nelson]

On Wed, Jan 15, 2014 at 10:22 AM, Louis McCarthy <comp...@gmail.com> wrote:
> I am awaiting approval in the bug tracker, but I saw your comment related to
> Wicd/Connman. If I remember correctly, there were issues with multiple
> connections (wired and wireless) and DHCP (only assigned an IP to the first
> adapter) with connman. Not sure if those were resolved.

Yuck that's even worse.. I'd like to find something that'll work with
both networks..

Here's a version of connman i'm thinking of replacing wicd with:

http://rcn-ee.net/pkgs/connman/connman_1.15/connman_1.15-0ubuntu2_armhf.deb

another option is network-manager, but like some gtk apps it's
randomly locking.. (i might have a fix, just need to test it..)

[Louis McCarthy]

I have wicd showing wireless networks now....

You need to go to the Preferences and enter "wlan0" into the Wireless interface section of the "General Settings" tab.

I'm still testing, but it appears to connect to the internet.

[Robert Nelson]

On Wed, Jan 15, 2014 at 10:53 AM, Louis McCarthy <comp...@gmail.com> wrote:
> I have wicd showing wireless networks now....
>
> You need to go to the Preferences and enter "wlan0" into the Wireless
> interface section of the "General Settings" tab.

Yeah, i had tried that too today.. For some reason my Atheros adapter
is just acting up. I have a few dozen more at home i could test.

> I'm still testing, but it appears to connect to the internet.

Cool, maybe we'll keep wicd.. It has all the fancy gui setting so end
users can easily configure it. Please let me know if any other issues
pop up..

[Louis McCarthy]

I forgot to mention, I am using a D-LINK DWA-121 [Realtek RTL8188CUS] using the kernel rtl8192cu module. But I didn't have to do anything, manually, to get the drivers/modules loaded.

I just did a 'ps -A' to check for wpa_supplicant and then used 'iwconfig' to see if the wireless extensions were working, and that provided me with the interface name to put into wicd.

Louis

[Bill Traynor]

On Wed, Jan 15, 2014 at 11:22 AM, Louis McCarthy <comp...@gmail.com> wrote:
> I am awaiting approval in the bug tracker, but I saw your comment related to
> Wicd/Connman. If I remember correctly, there were issues with multiple
> connections (wired and wireless) and DHCP (only assigned an IP to the first
> adapter) with connman. Not sure if those were resolved.

Sorry about that, Louis. You should be active in the bug tracker now.

> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[smith.wi...@gmail.com]

On Friday, January 10, 2014 5:11:09 PM UTC-5, RobertCNelson wrote:

It's Friday and everyone is probally kicking back and enjoying a cold
beverage... Well enough of that crap, time to start actually testing
something... ;)

Firstly, many thanks for your hard work here!

Now that the move to debian is official, I'm scrambling to move my custom images over.  With Angstrom, I had a custom .bb file that was based on the ti-hw-bringup-image.bb script and added a few extra things.

With the new scripts, I'm looking to do a number of things:

1) Omit some packages, such as Cloud9, Node and Xorg as I don't need them

2) Add some of my own packages

3) Build a custom kernel (to include a .dts)

4) Customize the resulting rootfs (e.g. add users, systemd service scripts etc)

5) Ultimately, automate this

Initially, I could just clone the script and edit the lines that set bborg_pkg_list to omit what I don't want (#1) and include what I do #2.  I could add a further function to modify the root filesystem before it gets zipped up (although I'm not sure how I create new users etc ...).

Is there some way of being able to extend the script in this manner without having to change it so that it doesn't get clobbered when updating?

Thanks!

-W.

[Robert Nelson]

The easiest thing to do, is first just fork the repo, then:

cp beagleboard.org_image.sh custom_image.sh

Then edit the "chroot_script" line, so you can run your own chroot
customization script..

For example we are calling: ( chroot_script="beagleboard.org.sh" )
https://github.com/beagleboard/image-builder/blob/master/beagleboard.org_image.sh#L342

dump your script here:
https://github.com/beagleboard/image-builder/tree/master/chroot_script

The main chroot script does set some sane defaults,

https://github.com/beagleboard/image-builder/blob/master/scripts/chroot.sh#L289

Just ping us if something is enabled by default that you need off..

Doing that other then just do a git pull everyonce in awhile to get updates..

git pull --no-edit git://github.com/beagleboard/image-builder.git master

If your project gets big, i have issues with adding it to the
readme.md list like I did with MachineKit then i just randomly pull
from those tree when they have updates..

[smith.wi...@gmail.com]

On Wednesday, January 15, 2014 1:05:33 PM UTC-5, RobertCNelson wrote:

The easiest thing to do, is first just fork the repo, then:

cp beagleboard.org_image.sh custom_image.sh

Then edit the "chroot_script" line, so you can run your own chroot
customization script..

For example we are calling: ( chroot_script="beagleboard.org.sh" )
https://github.com/beagleboard/image-builder/blob/master/beagleboard.org_image.sh#L342

dump your script here:
https://github.com/beagleboard/image-builder/tree/master/chroot_script

The main chroot script does set some sane defaults,

https://github.com/beagleboard/image-builder/blob/master/scripts/chroot.sh#L289

Just ping us if something is enabled by default that you need off..

Doing that other then just do a git pull everyonce in awhile to get updates..

git pull --no-edit git://github.com/beagleboard/image-builder.git master

If your project gets big, i have issues with adding it to the
readme.md list like I did with MachineKit then i just randomly pull
from those tree when they have updates..

Fantastic, thanks for this, I'm in the process of running my first build.

However, it occurs to me that perhaps I don't need to copy the beagleboard.org_image.sh script ... it seems to write all of the things I want to change to the .project file ... If I drop in my own version of this, will the "stock" beagleboard.org_image.sh pick those up?

Couple of other questions:

1) I'm working out of master, should I be using the 01.10.2014 branch?  I'm happy to work on the bleeding edge, as long as I can load my capes .dts via EEPROM

2) I need to load some "unstable" packages from sid, is there any way in the script to do this? -- specifically, golang-go (2:1.2-2) for Go 1.2

3) I'm curious as to what is QEMU used for?  I actually need it to cross compile Erlang for the BBB, so I'd like to see how it's getting used.

Again, many thanks for your efforts!!!

-W.

[Robert Nelson]

>
> Fantastic, thanks for this, I'm in the process of running my first build.
>
> However, it occurs to me that perhaps I don't need to copy the
> beagleboard.org_image.sh script ... it seems to write all of the things I
> want to change to the .project file ... If I drop in my own version of this,
> will the "stock" beagleboard.org_image.sh pick those up?

Hey someone noticed the heart of the script.

Correct, just setup ".project" and run

/bin/sh ./RootStock-NG.sh

> Couple of other questions:
>
> 1) I'm working out of master, should I be using the 01.10.2014 branch? I'm
> happy to work on the bleeding edge, as long as I can load my capes .dts via
> EEPROM

Master is fine.. I only tag releases for ease of looking back...

> 2) I need to load some "unstable" packages from sid, is there any way in the
> script to do this? -- specifically, golang-go (2:1.2-2) for Go 1.2

I haven't setup any apt-pinning yet, so in the script it's dangerous..
When i need something from sid, i just try to back port it first..

Follow:

https://wiki.debian.org/sbuild

(sid -> wheezy, amd64 -> armhf)

Make sure to set:

$build_arch_all = 1;
$build_source = 1;

Then just:
sbuild http://ftp.us.debian.org/debian/pool/main/g/golang/golang_1.2-2.dsc

hopefully you have enough memory/cpu for it to build.. (and wheezy has
the dependices, if it doesn't well it gets funner...)

> 3) I'm curious as to what is QEMU used for? I actually need it to cross
> compile Erlang for the BBB, so I'd like to see how it's getting used.

So the script can run on an x86 machine.. Back when all the script did
was: debootstrap/dpkg/apt-get qemu worked well, howver anything like
"git clone xyz" qemu can fail.. So run it native, but in some cases
on x86 is fine..

[smith.wi...@gmail.com]

On Thursday, January 16, 2014 12:10:35 PM UTC-5, smith.wi...@gmail.com wrote:

Fantastic, thanks for this, I'm in the process of running my first build.

Success! ... I think.  Don't seem to have working ethernet, here's the console output:

[    0.361322] omap2_mbox_probe: platform not supported

[    0.528826] tps65217-bl tps65217-bl: no platform data provided

[    0.593518] bone-capemgr bone_capemgr.9: slot #0: No cape found

[    0.630626] bone-capemgr bone_capemgr.9: slot #1: No cape found

[    0.667733] bone-capemgr bone_capemgr.9: slot #2: No cape found

[    0.704842] bone-capemgr bone_capemgr.9: slot #3: No cape found

[    0.720846] bone-capemgr bone_capemgr.9: slot #6: BB-BONELT-HDMIN conflict P8.45 (#5:BB-BONELT-HDMI)

[    0.730428] bone-capemgr bone_capemgr.9: slot #6: Failed verification

[    0.737160] bone-capemgr bone_capemgr.9: loader: failed to load slot-6 BB-BONELT-HDMIN:00A0 (prio 2)

[    0.753514] omap_hsmmc mmc.5: of_parse_phandle_with_args of 'reset' failed

[    0.816446] pinctrl-single 44e10800.pinmux: pin 44e10854 already requested by 44e10800.pinmux; cannot claim for gpio-leds.8

[    0.828157] pinctrl-single 44e10800.pinmux: pin-21 (gpio-leds.8) status -22

[    0.835441] pinctrl-single 44e10800.pinmux: could not request pin 21 on device pinctrl-single

Loading, please wait...

Scanning for Btrfs filesystems

systemd-fsck[201]: rootfs: clean, 32162/111104 files, 140904/444160 blocks

[    6.087883] libphy: PHY 4a101000.mdio:01 not found

[    6.092953] net eth0: phy 4a101000.mdio:01 not found on slave 1

Any thoughts?

Thanks!

[Robert Nelson]

Give it a few more seconds, currently "wicd" is under control of eth0
(not /etc/network/interfaces) on 3.8 it takes wicd about 2-3 calls
before it gets it..

The only reason i'm using wicd over /etc/network/interfaces is to
remove the 2 minute timeout if eth0 isn't connected...

[Louis McCarthy]

Anyone else having trouble loading cape dtbo files at boot? I cannot get cape manager to manually load/override/overlay either:

sudo echo ANY-CAPE > /sys/devices/bone-cape.9/slots

"Permission denied"

I've tried an A1 audio cape and a couple of capes that I built. I've tried recompiling the dts sources. The dmesg logs (just one example) say "failed to load firmware 'BB-BONE-AUDI-01-00A1.dtbo'", which I know exists in /lib/firmware and has the same permissions as the other dtbo files.

Louis

[Robert Nelson]

On Thu, Jan 16, 2014 at 3:49 PM, Louis McCarthy <comp...@gmail.com> wrote:
> Anyone else having trouble loading cape dtbo files at boot? I cannot get
> cape manager to manually load/override/overlay either:
> sudo echo ANY-CAPE > /sys/devices/bone-cape.9/slots
> "Permission denied"

sudo sh -c "echo 'something' >> /etc/privilegedfile"

> I've tried an A1 audio cape and a couple of capes that I built. I've tried
> recompiling the dts sources. The dmesg logs (just one example) say "failed
> to load firmware 'BB-BONE-AUDI-01-00A1.dtbo'", which I know exists in
> /lib/firmware and has the same permissions as the other dtbo files.

[Louis McCarthy]

Thanks, that did help me troubleshoot. I also ran as root (sudo su) and was getting error messages, but some of those errors were bogus. A quick check with 'dmesg' showed that the command actually went through.

Manual loading now finds the dtbo files, but still no love on auto loading capes at boot....looking into it some more. 

Is it possible that the boot system is trying to find the files in the boot image and not the eMMC root filesystem? I haven't had this much trouble with capes before (on other distros).....

Louis

[Robert Nelson]

On Thu, Jan 16, 2014 at 5:19 PM, Louis McCarthy <comp...@gmail.com> wrote:
> Thanks, that did help me troubleshoot. I also ran as root (sudo su) and was
> getting error messages, but some of those errors were bogus. A quick check
> with 'dmesg' showed that the command actually went through.
>
> Manual loading now finds the dtbo files, but still no love on auto loading
> capes at boot....looking into it some more.
>
> Is it possible that the boot system is trying to find the files in the boot
> image and not the eMMC root filesystem? I haven't had this much trouble with
> capes before (on other distros).....

in /boot/uboot/uEnv.txt did you enable it via:

optargs=capemgr.enable_partno=xzy

It's also got to be built-in..

https://github.com/RobertCNelson/linux-dev/blob/am33x-v3.8/patches/defconfig#L1305

We had problems the past with loading dtbo's from /lib/firmware/

[smith.wi...@gmail.com]

Ok, I had removed wicd-gtk.  I replaced it with wicd-cli and the ethernet is fine!

Couple of things I noticed:

1) Setting user_name in .project (or the main build script) gets overwritten with 'debian'

2) No console getty respawn.

    - I logged on to the console, ended up logging out (see #2), never got a prompt back on the console (nothing in dmesg)

3) Terminal got screwed up.

    - At somepoint during the boot (I removed systemd=quiet so I can see what's going on), the terminal got screwed up and the formatting went haywire:

openbsd-inetd[496]: Not starting internet superserver: no services enabled.

Started LSB: Start or stop the inetd daemon.                           [  OK  ]

Started Provide limited super user privileges to specific users        [  OK  ]

Started LSB: Run /etc/rc.local if it exist                             [  OK  ]

                                                                               Started Avahi mDNS/DNS-SD Stack                                        [  OK  ]

                                                                              Started Login Service                                                  [  OK  ]

                                                                             Started WPA supplicant                                                 [  OK  ]

                                                                            boot_scripts.sh[492]: Thu Jan 16 17:02:00 UTC 2014

                                              cron[510]: Starting periodic command scheduler: cron.

    - 'reset' and resetting the terminal locally didn't fix it

4) Fails to halt properly with /sbin/halt (kernel panic)

    - If you do it via an ssh login, it just doesn't halt

    - If you do it from the console, it does halt, but you get:

[  146.037995] (NULL device *): gadget not registered.

[  146.050219] musb-hdrc musb-hdrc.0.auto: remove, state 4

[  146.055772] usb usb2: USB disconnect, device number 1

[  146.061907] musb-hdrc musb-hdrc.0.auto: USB bus 2 deregistered

[  146.068906] Disabling non-boot CPUs ...

[  146.073001] Power down.

[  146.075595] System will go to power_off state in approx. 2 secs

[  146.083999] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000

[  146.083999] 

[  146.093558] [<c0010443>] (unwind_backtrace+0x1/0x8a) from [<c0455b2d>] (panic+0x51/0x148)

[  146.102101] [<c0455b2d>] (panic+0x51/0x148) from [<c002f799>] (do_exit+0x345/0x618)

[  146.110107] [<c002f799>] (do_exit+0x345/0x618) from [<c0039279>] (sys_reboot+0xcb/0x13e)

[  146.118560] [<c0039279>] (sys_reboot+0xcb/0x13e) from [<c000c021>] (ret_fast_syscall+0x1/0x46)

[  146.127546] drm_kms_helper: panic occurred, switching back to text console

But otherwise, great progress!

Thanks!

-W.

[Robert Nelson]

On Thu, Jan 16, 2014 at 8:02 PM, <smith.wi...@gmail.com> wrote:
> On Thursday, January 16, 2014 3:01:17 PM UTC-5, RobertCNelson wrote:
>>
>> On Thu, Jan 16, 2014 at 1:41 PM, <smith.wi...@gmail.com> wrote:
>>
>> Give it a few more seconds, currently "wicd" is under control of eth0
>> (not /etc/network/interfaces) on 3.8 it takes wicd about 2-3 calls
>> before it gets it..
>>
>> The only reason i'm using wicd over /etc/network/interfaces is to
>> remove the 2 minute timeout if eth0 isn't connected...
>
>
> Ok, I had removed wicd-gtk. I replaced it with wicd-cli and the ethernet is
> fine!
>
> Couple of things I noticed:
>
> 1) Setting user_name in .project (or the main build script) gets overwritten
> with 'debian'

Yeah, for some reason it's not sourcing it from ".project" correctly
at the moment..
https://github.com/RobertCNelson/omap-image-builder/blob/master/chroot_script/beagleboard.org.sh#L14

Working on that..

> 2) No console getty respawn.
> - I logged on to the console, ended up logging out (see #2), never got a
> prompt back on the console (nothing in dmesg)

Is this with the main ttyO2 debug serial console or one of the video
console's tty0?

> 3) Terminal got screwed up.
> - At somepoint during the boot (I removed systemd=quiet so I can see
> what's going on), the terminal got screwed up and the formatting went
> haywire:
> openbsd-inetd[496]: Not starting internet superserver: no services enabled.
> Started LSB: Start or stop the inetd daemon. [ OK
> ]
> Started Provide limited super user privileges to specific users [ OK
> ]
> Started LSB: Run /etc/rc.local if it exist [ OK
> ]
>
> Started Avahi mDNS/DNS-SD Stack [ OK
> ]
>
> Started Login Service [ OK
> ]
>
> Started WPA supplicant [ OK
> ]
>
> boot_scripts.sh[492]: Thu Jan 16 17:02:00 UTC 2014
> cron[510]: Starting periodic
> command scheduler: cron.
>
> - 'reset' and resetting the terminal locally didn't fix it

You need to re-size your serial terminal to fix this. systemd is also
a lot more noiser, hence the quiet..

> 4) Fails to halt properly with /sbin/halt (kernel panic)
> - If you do it via an ssh login, it just doesn't halt
> - If you do it from the console, it does halt, but you get:
> [ 146.037995] (NULL device *): gadget not registered.
> [ 146.050219] musb-hdrc musb-hdrc.0.auto: remove, state 4
> [ 146.055772] usb usb2: USB disconnect, device number 1
> [ 146.061907] musb-hdrc musb-hdrc.0.auto: USB bus 2 deregistered
> [ 146.068906] Disabling non-boot CPUs ...
> [ 146.073001] Power down.
> [ 146.075595] System will go to power_off state in approx. 2 secs
> [ 146.083999] Kernel panic - not syncing: Attempted to kill init!
> exitcode=0x00000000
> [ 146.083999]
> [ 146.093558] [<c0010443>] (unwind_backtrace+0x1/0x8a) from [<c0455b2d>]
> (panic+0x51/0x148)
> [ 146.102101] [<c0455b2d>] (panic+0x51/0x148) from [<c002f799>]
> (do_exit+0x345/0x618)
> [ 146.110107] [<c002f799>] (do_exit+0x345/0x618) from [<c0039279>]
> (sys_reboot+0xcb/0x13e)
> [ 146.118560] [<c0039279>] (sys_reboot+0xcb/0x13e) from [<c000c021>]
> (ret_fast_syscall+0x1/0x46)
> [ 146.127546] drm_kms_helper: panic occurred, switching back to text
> console

The kernel panic with halt is known..
http://bugs.elinux.org/issues/39

The system still correctly shut's off just fine.. It also affects the
older angstrom 3.8 images..

[smith.wi...@gmail.com]

On Thursday, January 16, 2014 9:33:13 PM UTC-5, RobertCNelson wrote:

> 1) Setting user_name in .project (or the main build script) gets overwritten
> with 'debian'

Yeah, for some reason it's not sourcing it from ".project" correctly
at the moment..
https://github.com/RobertCNelson/omap-image-builder/blob/master/chroot_script/beagleboard.org.sh#L14

Working on that..

Cool, thanks!

 

> 2) No console getty respawn.
>     - I logged on to the console, ended up logging out (see #2), never got a
> prompt back on the console (nothing in dmesg)

Is this with the main ttyO2 debug serial console or one of the video
console's tty0?

It was the serial console, ttyO2

 

> 3) Terminal got screwed up.

You need to re-size your serial terminal to fix this. systemd is also
a lot more noiser, hence the quiet..

Yeah, I don't think the resize is the issue.  I have a Mac Terminal set at 80x55.  I think it's some kind of stty mode that's changing.  However, retrying it a number of times, I have only seen it "screw up" the terminal I/O a couple of times.  Mostly it's ok.

I always disable the "quiet" mode, I find it disconcerting to not see output when the system boots ... kind of Windows like.

 

> 4) Fails to halt properly with /sbin/halt (kernel panic)

The kernel panic with halt is known..
http://bugs.elinux.org/issues/39

The system still correctly shut's off just fine..  It also affects the
older angstrom 3.8 images..  

I only had the one occasion when it failed to stop (that is the leds kept flashing and I could log back in via ssh).  Every other time it's halted (with the panic).

Thanks!

-W.

 

[smith.wi...@gmail.com]

On Wednesday, January 15, 2014 1:05:33 PM UTC-5, RobertCNelson wrote:

> With the new scripts, I'm looking to do a number of things:
>

> 3) Build a custom kernel (to include a .dts)

Any thoughts on adding a custom .dts to the build script to be included in the kernel?

I have some notes from someone else:

1. Copy the dts file to $KERNEL/firmware/capes

2. Add it to the build list in $KERNEL/firmware/Makefile

But it looks like it's downloading a pre-build kernel?

Thanks!

-W.

[mikh...@firmsolutionsinc.com]

Got an image from http://rcn-ee.net/deb/testing/2014-01-16/.

Boots up, runs fine with LCD7 cape...... 

Problem I see is that disk usage is grows at very fast rate.  I run it from SD card ( 4Gb image ), every reboot seems to bump roortf usage by 1%

On Friday, January 10, 2014 2:11:09 PM UTC-8, RobertCNelson wrote:

It's Friday and everyone is probally kicking back and enjoying a cold
beverage... Well enough of that crap, time to start actually testing
something... ;)

[Robert Nelson]

On Tue, Jan 21, 2014 at 7:43 PM, <mikh...@firmsolutionsinc.com> wrote:
> Got an image from http://rcn-ee.net/deb/testing/2014-01-16/.
>
> Boots up, runs fine with LCD7 cape......
>
> Problem I see is that disk usage is grows at very fast rate. I run it from
> SD card ( 4Gb image ), every reboot seems to bump roortf usage by 1%

My first guess is something in /var/log/

It would be nice to track what's growing and if it just safely rolls's
over without taking too much extra space..

Regards,

[mikh...@firmsolutionsinc.com]

Yes,

those 3 seem to grow very fast:

kern.log

syslog

debug

I installed iotop and it was showing rsyslog running very often, writing bunch of data to the card.

what is interesting is that after I shut down LXDE they don't seem to grow much and rsyslod doesn't show up in iotop anymore.....  I have no working theory, except that I found this in kern.log:

Jan 16 18:56:39 beaglebone kernel: [    1.076132] bone-capemgr bone_capemgr.9: slot #5: BB-BONELT-HDMI conflict P8.45 (#1:BB-BONE-LCD7-01)

Jan 16 18:56:39 beaglebone kernel: [    1.122583] bone-capemgr bone_capemgr.9: slot #6: BB-BONELT-HDMIN conflict P8.45 (#1:BB-BONE-LCD7-01)

have no idea if this has anything to do with anything.....

To answer the second part of your question:

no, it doesn't roll's over safely..... I left the board powered overnight ( accidentally ) and it was at 100% rootfs usage this morning....

[Robert Nelson]

On Tue, Jan 21, 2014 at 10:14 PM, <mikh...@firmsolutionsinc.com> wrote:
> Yes,
>
> those 3 seem to grow very fast:
> kern.log
> syslog
> debug
>
> I installed iotop and it was showing rsyslog running very often, writing
> bunch of data to the card.
>
> what is interesting is that after I shut down LXDE they don't seem to grow
> much and rsyslod doesn't show up in iotop anymore..... I have no working
> theory, except that I found this in kern.log:
>
> Jan 16 18:56:39 beaglebone kernel: [ 1.076132] bone-capemgr
> bone_capemgr.9: slot #5: BB-BONELT-HDMI conflict P8.45 (#1:BB-BONE-LCD7-01)
> Jan 16 18:56:39 beaglebone kernel: [ 1.122583] bone-capemgr
> bone_capemgr.9: slot #6: BB-BONELT-HDMIN conflict P8.45 (#1:BB-BONE-LCD7-01)
>
> have no idea if this has anything to do with anything.....

That's fine.. The hdmi (audio) and hdmi (no audio) got denied loading
as you have the lcd7 plugged in and that pin wasn't available.. (it's
an error condition, just not useful for obvious reasons. ;) ..)

> To answer the second part of your question:
> no, it doesn't roll's over safely..... I left the board powered overnight (
> accidentally ) and it was at 100% rootfs usage this morning....

yeah, that's no good, can you dump:

ls -lh /var/log/

Then i'll fix that..

[mikh...@firmsolutionsinc.com]

debian@beaglebone:~$ ls -lh /var/log

total 76M

drwxr-xr-x 2 root root 4.0K Jan 16 18:49 ConsoleKit

-rw-r--r-- 1 root root  15K Jan 16 18:49 Xorg.0.log

-rw-r--r-- 1 root root  27K Jan 16 19:45 alternatives.log

drwxr-x--- 2 root adm  4.0K Jan 16 18:49 apache2

drwxr-xr-x 2 root root 4.0K Jan 16 18:49 apt

-rw-r----- 1 root adm  2.4K Jan 22 06:38 auth.log

-rw-r--r-- 1 root root  60K Jan 16 18:48 bootstrap.log

-rw------- 1 root utmp    0 Jan 16 18:43 btmp

-rw-r----- 1 root adm   27K Jan 22 06:30 daemon.log

-rw-r----- 1 root adm   25M Jan 22 06:39 debug

-rw-r----- 1 root adm   27K Jan 16 18:49 dmesg

-rw-r----- 1 root adm    31 Jan 16 18:45 dmesg.0

-rw-r--r-- 1 root root 456K Jan 22 06:34 dpkg.log

-rw-r--r-- 1 root root  24K Jan 16 19:12 faillog

-rw-r--r-- 1 root root  781 Jan 16 19:07 fontconfig.log

drwxr-xr-x 2 root root 4.0K Jan 16 18:45 fsck

-rw-r----- 1 root adm   25M Jan 22 06:39 kern.log

-rw-rw-r-- 1 root utmp 286K Jan 22 06:31 lastlog

drwx--x--x 2 root root 4.0K Jan 16 18:49 lightdm

-rw-r----- 1 root adm     0 Jan 16 18:49 lpr.log

-rw-r----- 1 root adm     0 Jan 16 18:49 mail.err

-rw-r----- 1 root adm     0 Jan 16 18:49 mail.info

-rw-r----- 1 root adm     0 Jan 16 18:49 mail.log

-rw-r----- 1 root adm     0 Jan 16 18:49 mail.warn

-rw-r----- 1 root adm   35K Jan 16 18:50 messages

drwxr-xr-x 2 root root 4.0K Jan 16 18:49 news

-rw-r----- 1 root adm   25M Jan 22 06:39 syslog

-rw-r----- 1 root adm     0 Jan 16 18:49 user.log

drwxr-xr-x 2 root root 4.0K Jan 16 18:50 wicd

-rw-rw-r-- 1 root utmp 3.4K Jan 22 06:36 wtmp

-rw-r--r-- 1 root root  237 Jan 16 19:11 wvdialconf.log

debug grows by a meg every 30 seconds or so....

I also think I know where the problem is coming from:  by looking at iotop trace the rsyslog active only when USB cable is plugged in ( to PC )

[Louis McCarthy]

Wow, Robert, you have been busy today! I was going to comment on xinput-calibrate, but you made a commit about 15 minutes before I did a clone, then I was trying to deal with touchscreen jitter and saw your patch of 3.8.13-bone37....thanks for your work. I will test those out as soon as I can get them built :)

On the capemgr front......I am looking into ways to get the dtbo files accessible at boot time. 

Option 1) Get capemgr to find /lib/firmware on startup

Option 2) Put dtbo files into boot partition

What are your, and anyone else's, thoughts on this? I will start delving deeper into the kernel source tomorrow, especially the capemgr sections. But I am new to kernel patches and exactly how capemgr does its thing.

Louis

[Robert Nelson]

On Wed, Jan 22, 2014 at 5:06 PM, Louis McCarthy <comp...@gmail.com> wrote:
> Wow, Robert, you have been busy today! I was going to comment on
> xinput-calibrate, but you made a commit about 15 minutes before I did a
> clone, then I was trying to deal with touchscreen jitter and saw your patch
> of 3.8.13-bone37....thanks for your work. I will test those out as soon as I
> can get them built :)

Oh we got lucky on xinput-calibrate, i was starting to look up writing
lightdm scripts, when i just hooked up the one found in their repo and
rebooted.. It worked, so ship it. ;)

> On the capemgr front......I am looking into ways to get the dtbo files
> accessible at boot time.
> Option 1) Get capemgr to find /lib/firmware on startup
> Option 2) Put dtbo files into boot partition

Couples issues,

The *.dtbo's already compiled under /lib/firmware should work via the
uEnv.txt *_enable call..
The kernel .config, build firmware in kernel is enabled.
We are using an initrd. (helps hide the lack of rtc problem for rootfs
and allows us to us uuid's for the eMMC, aka allowing single/multi mmc
card combinations..)

So, any modifications to any of the existing /lib/firmware/*.dtbo file
will be ignored, as the kernel has it built-in.

Any additions to /lib/firmware/*.dtbo are ignored as they are too late
on boot (uEnv.txt *_enable call) and are not in the initrd.

So.. I "think" we can fix the problem, by making sure all *.dtbo's
(including new ones from users) are re-pulled into the initrd when
it's regenerated. Here's the current initrd.img update routine.

if [ ! -f /boot/initrd.img-$(uname -r) ] ; then
update-initramfs -c -k $(uname -r)
else
update-initramfs -u -k $(uname -r)
fi
cp -v /boot/initrd.img-$(uname -r) /boot/uboot/initrd.img

I'm guessing we just have to add the *.dtbo to one of the /etc/xyz
files that update-initramfs utilizes..

[Walter Schilling]

Robert:

So far great work.  It's overall working very well.

That being said, I have a pair of questions:

#1 I'm trying to use the camera cape with the board, and I get the following error message when I try to read from it using openCV: VIDIOC_REQBUFS: Cannot allocate memory.  I believe this has something to do with the dd for the camera, but I'm not sure if it is something that requires mods to the dd or just a change in configuration.

#2 I'm assuming this is by design, but when i try to read from the camera using gstreamer, I get a package not found error.  It seems as if gstreamer isn't in this package, yet I aloso run into problems when I try to do an apt-get in that it can not be located.  This may very well be by design and I just haven't overcome the issues.

Thanks again for your hard work on this codebase.

Walt

[Robert Nelson]

On Wed, Jan 22, 2014 at 7:18 PM, Walter Schilling <schi...@msoe.edu> wrote:
> Robert:
>
> So far great work. It's overall working very well.
>
> That being said, I have a pair of questions:

Which camera cape? Is this the Radium or the 3.1MP cape? ( in only
have the 3.1MP )

> #1 I'm trying to use the camera cape with the board, and I get the following
> error message when I try to read from it using openCV: VIDIOC_REQBUFS:
> Cannot allocate memory. I believe this has something to do with the dd for
> the camera, but I'm not sure if it is something that requires mods to the dd
> or just a change in configuration.

Not really sure, I've gone so far as cat /dev/video0 on the 3.1 just
to make sure it works.. Has anyone else in the beagleboard group tried
opencv?

> #2 I'm assuming this is by design, but when i try to read from the camera
> using gstreamer, I get a package not found error. It seems as if gstreamer
> isn't in this package, yet I aloso run into problems when I try to do an
> apt-get in that it can not be located. This may very well be by design and
> I just haven't overcome the issues.

Here's all the gstreamer options:
http://packages.debian.org/search?keywords=gstreamer&searchon=names&suite=stable&section=all

make sure to refresh via:

apt-get update ; apt-get install xyz

Let me know what you need to make it work..

[smith.wi...@gmail.com]

This would be good ... I have a custom .dts for a cape that I need to get loaded at boot time (via the cape's EEPROM) without the 60s timeout for rootfs.

Also, one of the items on my cape is RTC (ds1307 via i2c2) -- yes, it actually has a battery too!  Any thoughts on how to get it to be "used" by the kernel?   It is detected and shows up as /dev/rtc1, but if I try to symlink /dev/rtc to /dev/rtc1, it gets reset at boot time and the kernel ignores it ... eventually getting it's time from ntpdate (if network is available).

Would be nice if there was a way to connect a battery to the onboard RTC!

[Walter Schilling]

Well, there's good news and bad news.  The good news, thanks to my own lack of knowledge, I was using the wrong packages for gstreamer.  Thus, it wasn't finding them when I tried to install it.  Alas, after installing gstreamer, I was able to construct the pipeline with the following command:

gst-launch v4l2src device=/dev/video0 num-buffers=1 ! videoscale ! video/x-raw-yuv, width=640,height=480 ! jpegenc ! filesink location=test.jpg

When I run this, I get the following error log:

root@beaglebone:~/boneCV# gst-launch v4l2src device=/dev/video0 num-buffers=1 ! videoscale ! video/x-raw-yuv, width=640,height=480 ! jpegenc ! filesink location=test.jpg

Setting pipeline to PAUSED ...

Pipeline is live and does not need PREROLL ...

WARNING: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Could not get parameters on device '/dev/video0'

Additional debug info:

v4l2src_calls.c(235): gst_v4l2src_set_capture (): /GstPipeline:pipeline0/GstV4l2Src:v4l2src0:

system error: Inappropriate ioctl for device

Setting pipeline to PLAYING ...

New clock: GstSystemClock

Got EOS from element "pipeline0".

Execution ended after 140674416 ns.

Setting pipeline to PAUSED ...

Setting pipeline to READY ...

Setting pipeline to NULL ...

Freeing pipeline ...

root@beaglebone:~/boneCV# 

There is a test.jpg image created, but it is all black, as if the camera image is not read.  

This is being done with the 3.1 mp camera cape from circuitco.

It's possible that I've got something wrong in my gstreamer pipeline, as I'm not an expert on it, but it does seem like there may be something with the driver.  I'm going to try the same exact procedure with a USB camera to check my pipeline and go from there.

Thanks again for your help.

Walt

[Eric Fort]

yes,

having an 8G option would be really nice. 4G to an 8G card wastes
half the card and makes it a pain to ever recover the other 4G.
Finally found a utility that restores full capacity but 8G would be
quite nice if it's not much more trouble to produce.

Eric

On Fri, Jan 10, 2014 at 3:36 PM, Robert Nelson <robert...@gmail.com> wrote:
> On Fri, Jan 10, 2014 at 5:09 PM, David Lambert <da...@lambsys.com> wrote:

>> On 01/10/2014 04:11 PM, Robert Nelson wrote:
>>>
>>>
>>> 4GB standalone image that can be flashed to any 4GB or greater.
>>> [bone-debian-7.3-2014-01-10-4gb.img.xz]
>>>
>>>
>>> http://rcn-ee.net/deb/testing/2014-01-10/bone-debian-7.3-2014-01-10-4gb.img.xz
>>> 096915309ec4a8fe41b1e8076a0c436b bone-debian-7.3-2014-01-10-4gb.img.xz
>>>
>>> It takes about 20-30 Minutes to dd microSD (4GB)
>>>

>> OK It only took my system a tad over 8 minutes to a Transcend 8G SD:
>
> Should i also push out a 8GB image? it's all zero's and it just
> compresses very well..
>
>> time xzcat /home/dlambert/downloads/bone-debian-7.3-2014-01-10-4gb.img.xz |
>> dd bs=10M of=/dev/sdc
>> 0+345858 records in
>> 0+345858 records out
>> 3932160000 bytes (3.9 GB) copied, 493.82 s, 8.0 MB/s
>>
>> real 8m13.823s
>> user 0m38.910s
>> sys 0m6.756s
>>
>> First impressions great, came right up systemd, avahi, etc. I will keep on
>> testing over the weekend.
>>
>> BTW is the kernel the same as the default in
>> git://github.com/RobertCNelson/linux-dev.git?
>
> specifially: 3.8.13-bone35
>
>>
>> Any hints yet on how to handle pinmux GPIO etc. now that capemgr is not yet
>> there?
>
> By default it's still 3.8 so that all books/guides/etc written for
> Angstrom work.. Down the road it'll be v3.13..

>
> Regards,
>
> --
> Robert Nelson
> http://www.rcn-ee.com/
>

> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Robert Nelson]

On Thu, Jan 23, 2014 at 3:22 AM, Eric Fort <eric...@gmail.com> wrote:
> yes,
>
> having an 8G option would be really nice. 4G to an 8G card wastes
> half the card and makes it a pain to ever recover the other 4G.
> Finally found a utility that restores full capacity but 8G would be
> quite nice if it's not much more trouble to produce.

Yeah i can easily add a 8G option, once compressed it's the same size
as the 4G on the server.

It's only painful for 8G users, as dd has to dump all the zero's..

But i'd really like someone to write a script to automate the resize
on bootup from the bbb.. ;) We have the initrd.img, so it could be
done before the root partition is first loaded..

[Charles Steinkuehler]

On 1/23/2014 9:12 AM, Robert Nelson wrote:
> But i'd really like someone to write a script to automate the resize
> on bootup from the bbb.. ;) We have the initrd.img, so it could be
> done before the root partition is first loaded..

I'm not sure you'd want to put everything required to resize the root
partition into the initrd.

What about something similar to /forcefsck where an init script runs and
checks for the presence of /resizerootfs or somesuch and then makes the
various required checks (that there is actually space available, the
filesystem is clean, the filesystem is a type that can be extende3d, etc).

Can any simplifying assumptions be made about things like the root
device, partition layout, etc?

It would be nice if you could just have a 2G raw image (saves time
writing) and expand the filesystem on the first boot. How long does it
take to expand an ext4 filesystem, anyway? I use jfs on my x86 boxes
because you can expand the fs live while it's mounted (very handy for
virtual machines and systems with SAN back-ends, where I'm always
growing the storage!). Last I checked, resizing ext3 was a royal PITA
by comparison...I hope this is improved with ext4.

--
Charles Steinkuehler
cha...@steinkuehler.net

[Robert Nelson]

On Thu, Jan 23, 2014 at 8:58 AM, Charles Steinkuehler
<cha...@steinkuehler.net> wrote:
> On 1/23/2014 9:12 AM, Robert Nelson wrote:
>> But i'd really like someone to write a script to automate the resize
>> on bootup from the bbb.. ;) We have the initrd.img, so it could be
>> done before the root partition is first loaded..
>
> I'm not sure you'd want to put everything required to resize the root
> partition into the initrd.

I was thinking about doing it in the initrd to remove the reboot in
the process..

use fdisk to re-partition drive:
reboot
run resize2fs

> What about something similar to /forcefsck where an init script runs and
> checks for the presence of /resizerootfs or somesuch and then makes the
> various required checks (that there is actually space available, the
> filesystem is clean, the filesystem is a type that can be extende3d, etc).

adding /resizerootfs to the fat boot partition would be a good trigger
for the script..

> Can any simplifying assumptions be made about things like the root
> device, partition layout, etc?

with sfdisk we can easily dump/restore..

sfdisk -d /dev/mmcblk0 > part_table
sfdisk /dev/mmcblk0 < part_table

For the default images i've been using:

sudo sfdisk --in-order --Linux --unit M /dev/mmcblk0 <<-__EOF__
1,96,0xE,*
,,,-
__EOF__

Could just cheat and always force that..

> It would be nice if you could just have a 2G raw image (saves time
> writing) and expand the filesystem on the first boot. How long does it
> take to expand an ext4 filesystem, anyway? I use jfs on my x86 boxes
> because you can expand the fs live while it's mounted (very handy for
> virtual machines and systems with SAN back-ends, where I'm always
> growing the storage!). Last I checked, resizing ext3 was a royal PITA
> by comparison...I hope this is improved with ext4.

All play with ideas, as i've fixed most of the things on my bug list
and pushed that out as 2014.01.22..

[Charles Steinkuehler]

On 1/23/2014 9:40 AM, Robert Nelson wrote:
> All play with ideas, as i've fixed most of the things on my bug list
> and pushed that out as 2014.01.22..

Let me know if you need help. I've done a lot of initrd hacking from my
Linux Router Project / LEAF days, and am comfortable playing with disk
partitions at a low level.

--
Charles Steinkuehler
cha...@steinkuehler.net

[John Syn]

On 1/22/14, 4:38 PM, "Robert Nelson" <robert...@gmail.com> wrote:

>
>The *.dtbo's already compiled under /lib/firmware should work via the
>uEnv.txt *_enable call..
>The kernel .config, build firmware in kernel is enabled.
>We are using an initrd. (helps hide the lack of rtc problem for rootfs
>and allows us to us uuid's for the eMMC, aka allowing single/multi mmc
>card combinations..)
>
>So, any modifications to any of the existing /lib/firmware/*.dtbo file
>will be ignored, as the kernel has it built-in.
>
>Any additions to /lib/firmware/*.dtbo are ignored as they are too late
>on boot (uEnv.txt *_enable call) and are not in the initrd.

Hi Robert,

Doesn¹t this defeat the original purpose of DeviceTree? The idea that one
could change the I/O configuration without having to rebuild the kernel.
Also, I think this whole cape manager concept needs to be revisited. Since
it isn¹t possible to hot plug capes, why enable users to install and
remove dtbo files from the command line. I think all dtbo files should be
configured from the uEnv file and not built into the kernel. We can still
install and remove kernel modules from the command line, so development
won¹t be affected.

Regards,
John

>
>
>
>Regards,
>
>--
>Robert Nelson
>http://www.rcn-ee.com/
>

[Robert Nelson]

On Thu, Jan 23, 2014 at 9:35 AM, Charles Steinkuehler
<cha...@steinkuehler.net> wrote:
> On 1/23/2014 9:40 AM, Robert Nelson wrote:
>> All play with ideas, as i've fixed most of the things on my bug list
>> and pushed that out as 2014.01.22..
>
> Let me know if you need help. I've done a lot of initrd hacking from my
> Linux Router Project / LEAF days, and am comfortable playing with disk
> partitions at a low level.

Okay, I've cobbled together a few things to make it work.. (this using
the 2014-01-22 images as a base)

cd /opt/scripts/tools
git pull

# df -h | grep mmc
/dev/mmcblk0p2 3.5G 1.3G 2.1G 38% /
/dev/mmcblk0p1 96M 69M 27M 72% /boot/uboot
/dev/mmcblk1p2 1.7G 1.3G 351M 78% /media/rootfs
/dev/mmcblk1p1 96M 72M 25M 75% /media/boot

./grow_partition.sh
( https://github.com/RobertCNelson/boot-scripts/blob/master/tools/grow_partition.sh
)

(ignore all errors)
reboot

(this is run by:
https://github.com/RobertCNelson/boot-scripts/blob/master/boot/am335x_evm.sh#L102
)

# cat /boot/uboot/debug/resize.log
resize2fs 1.42.5 (29-Jul-2012)
Filesystem at /dev/mmcblk0p2 is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 1
The filesystem on /dev/mmcblk0p2 is now 1915648 blocks long.

# df -h | grep mmc
/dev/mmcblk0p2 7.2G 1.3G 5.6G 18% /
/dev/mmcblk0p1 96M 69M 27M 72% /boot/uboot
/dev/mmcblk1p2 1.7G 1.3G 351M 78% /media/rootfs
/dev/mmcblk1p1 96M 72M 25M 75% /media/boot


Details:
"/opt/scripts/tools" stuff gets populated by default:
https://github.com/RobertCNelson/omap-image-builder/blob/master/scripts/chroot.sh#L557

Issues:
64MB -> 96MB (for years we used a 64MB boot partition, but switched to
96MB recently)

Grow is hard-coded to 96M:
https://github.com/RobertCNelson/boot-scripts/blob/master/tools/grow_partition.sh#L60

A better option is to use sfdisk-'s -N2 option to only expand that..
https://github.com/RobertCNelson/boot-scripts/blob/master/tools/grow_partition.sh#L52

I couldn't get that to work..

[Louis McCarthy]

So, evidently you cannot log out / shutdown / or reboot from LXDE if there is a ssh session open with super user active.....It fails with "Authentication needed". Log out of the ssh session and LXDE has full control again.....

[Robert Nelson]

On Mon, Jan 27, 2014 at 9:16 PM, Louis McCarthy <comp...@gmail.com> wrote:
> So, evidently you cannot log out / shutdown / or reboot from LXDE if there
> is a ssh session open with super user active.....It fails with
> "Authentication needed". Log out of the ssh session and LXDE has full
> control again.....

Yeah, that is annoying. I have not found a working workaround for
that situation..

In a way it seems sane.. A normal user is not allowed to reboot a
machine when the root user is logged in over serial.

[Charles Steinkuehler]

I had this issue with my MachineKit images until I switched to lightdm
instead of xdm. Lightdm is trusted by consolekit (no relation to
MachineKit! :) and thus allows things like rebooting and user mounting
of USB devices.

I was running xfce4, however, so lxde might be different.

--
Charles Steinkuehler
cha...@steinkuehler.net

[Robert Nelson]

> I had this issue with my MachineKit images until I switched to lightdm
> instead of xdm. Lightdm is trusted by consolekit (no relation to
> MachineKit! :) and thus allows things like rebooting and user mounting
> of USB devices.
>
> I was running xfce4, however, so lxde might be different.

Yeah, it's lxpanel that can't get the permissions.. We are using
lightdm/systemd underneath lxde..

[Robert Nelson]

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

[Louis McCarthy]

Thanks Robert, I will check it out....

Did we get that GTK bug fixed? File dragging doesn't halt the system anymore, on my bbb. Wondering if it something I did.....custom 3.8.13-bone37, 3 custom capes compiled in, and touchscreen driver mods.....

Louis

[Robert Nelson]

On Wed, Jan 29, 2014 at 3:39 PM, Louis McCarthy <comp...@gmail.com> wrote:
> Thanks Robert, I will check it out....
>
> Did we get that GTK bug fixed? File dragging doesn't halt the system
> anymore, on my bbb. Wondering if it something I did.....custom
> 3.8.13-bone37, 3 custom capes compiled in, and touchscreen driver mods.....

Nope, still hard locks for me..

sudo apt-get install gpicview
lxde -> Accessories -> "Image Viewer" - "Open File" -> boot -> Docs ->
images -> beagle.png -> Open -> HARDLOCK...

Hopefully TI has an answer in our call tomorrow. ;)

Regards,

[Louis McCarthy]

Dude, mine is working! 

Here are the changes that I remember:

Custom compiled 3.8.13-bone37 kernel, with no config changes

  modified ti_am335x_tsc.c for BB-VIEW LCD7

  added a 3 dts files to the firmware/capes folder

  modified firmware/Makefile to add those cape drivers to the kernel

  copied 3.8.13-bone37.zImage to /boot/uboot/zImage

apt-get install libqtgui4 qt4-demos gpicview

My guess is that libqt installed something to fix it...

--
For more options, visit http://beagleboard.org/discuss
---

You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/9EG0SbhwTx0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--

“If we can prevent the government from wasting the labors of the people, under the pretense of taking care of them, they must become happy." - Thomas Jefferson

[Robert Nelson]

On Wed, Jan 29, 2014 at 4:34 PM, Louis McCarthy <comp...@gmail.com> wrote:
> Dude, mine is working!
>
> Here are the changes that I remember:
> Custom compiled 3.8.13-bone37 kernel, with no config changes
> modified ti_am335x_tsc.c for BB-VIEW LCD7
> added a 3 dts files to the firmware/capes folder
> modified firmware/Makefile to add those cape drivers to the kernel
> copied 3.8.13-bone37.zImage to /boot/uboot/zImage
>
> apt-get install libqtgui4 qt4-demos gpicview
>
> My guess is that libqt installed something to fix it...

Humm.. No such luck here.. What resolution are you running. I'm using
a monitor at 1280x1024.. It really feels like a graphics hardware
lockup..

[Louis McCarthy]

Darn , I was hoping I narrowed it down.... 800 x 480 is my resolution. Come to think of it, I think the last lock ups were through HDMI, to a 1680 x 1050 monitor.

[Robert Nelson]

On Wed, Jan 29, 2014 at 8:38 PM, Louis McCarthy <comp...@gmail.com> wrote:
> Darn , I was hoping I narrowed it down.... 800 x 480 is my resolution. Come
> to think of it, I think the last lock ups were through HDMI, to a 1680 x
> 1050 monitor.

Nope there goes that theory, 480x272..

[Louis McCarthy]

I was going to do more testing, but an unexpected power outage corrupted my sd card.....I will see if I can retrace my steps with a fresh image....

[Louis McCarthy]

I found it! Switching from 16 bit video mode to 24 bit fixes GTK.

I added this to /usr/share/X11/xorg.conf.d/10-evdev.conf

Section "Screen"

        Identifier "Builtin Default fbdev Screen 0"

        Monitor "Configured Monitor"

        Device "Configured Video Device"

        DefaultDepth 24

EndSection

[Robert Nelson]

On Thu, Jan 30, 2014 at 3:40 PM, Louis McCarthy <comp...@gmail.com> wrote:
> I found it! Switching from 16 bit video mode to 24 bit fixes GTK.
>
> I added this to /usr/share/X11/xorg.conf.d/10-evdev.conf
>
>
> Section "Screen"
>
> Identifier "Builtin Default fbdev Screen 0"
>
> Monitor "Configured Monitor"
>
> Device "Configured Video Device"
>
> DefaultDepth 24
>
> EndSection

Nice find!! It's too bad the colors are psychedelic, so it's unusable..

sudo sed -i -e 's:16:24:g' /etc/X11/xorg.conf
sudo reboot

But the core finally doesn't lock up!

[Robert Nelson]

On Thu, Jan 30, 2014 at 3:40 PM, Louis McCarthy <comp...@gmail.com> wrote:
> I found it! Switching from 16 bit video mode to 24 bit fixes GTK.
>
> I added this to /usr/share/X11/xorg.conf.d/10-evdev.conf
>
>
> Section "Screen"
>
> Identifier "Builtin Default fbdev Screen 0"
>
> Monitor "Configured Monitor"
>
> Device "Configured Video Device"
>
> DefaultDepth 24
>
> EndSection

Nice find!! It's too bad the colors are psychedelic, so it's unusable..

sudo sed -i -e 's:16:24:g' /etc/X11/xorg.conf
sudo reboot

But the core finally doesn't lock up!

[Louis McCarthy]

I'm still working on testing this image, but thought I would comment on a couple things before they slipped my mind.

I've flashed the eMMC on A6 and A6A BBBs and have run the flasher image as a live system by removing the flash-eMMC.txt file. 

The BB-BONE-AUDI-01:00A1 cape does not have a driver compiled into the kernel (A0 is there).

The LCD backlight frequency of 500000 is causing audible whine (BB-VIEW4/LCD7/BB-VIEW7) when the brightness is less than 100%. I fixed this by changing the frequency defined in the dts file (32768 works, but I just chose that randomly). Which repository are these being pulled from? I can fork that, make changes, and issue a pull request if that would help.

With the LCD7, I don't detect much, if any, of a change between the two versions of touchscreen drivers. I am not saying that we should discard the new version, but that the new version doesn't negatively affect the system.

My thoughts, with respect to networking, are to make it easy to get a wireless connection up and running. Wicd is pretty good at that, but I notice that every 8 to 20 minutes the wireless connection is dropped. That could be the AP I am connected to, so I will continue to test with other APs. I still need to test a couple more USB adapters too.

Another comment is the screen blanking. I noticed that the LCD7 goes white instead of just blanking to black. Not a problem, just noticed the change. But in trying to disable the power saving, I open the screen saver settings and am greeted with a warning message that the XScreenSaver daemon isn't running. This may give new users the impression that something is broken in the image. Is there another place to disable the screen blanking timer? 

Thanks,

Louis

On Wednesday, January 29, 2014 3:09:44 PM UTC-6, RobertCNelson wrote:

[James Valleroy]

On Wed, Jan 29, 2014 at 4:09 PM, Robert Nelson <robert...@gmail.com> wrote:
> 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

I attempted to rebuild the image (mainly for educational purposes) but
the build hangs when attempting to clone boot-scripts:

Log: (chroot) adding admin group to /etc/sudoers
Enter new UNIX password: Retype new UNIX password: passwd: password
updated successfully
Log: (chroot) Warning, qemu can fail here... (run on real armv7l
hardware for production images)
Log: (chroot): [git clone
https://github.com/RobertCNelson/boot-scripts /opt/scripts/ --depth 1
|| true]
Cloning into '/opt/scripts'...
remote: Counting objects: 32, done.
remote: Compressing objects: 100% (26/26), done.
remote: Total 32 (delta 6), reused 21 (delta 0)

[stops here]

$ ps aux | grep git
root 29272 0.0 0.0 4136812 4788 pts/0 S+ 21:06 0:00
/usr/bin/qemu-arm-static /usr/bin/git clone
https://github.com/RobertCNelson/boot-scripts /opt/scripts/ --depth 1
root 29273 0.2 0.0 4203256 13480 pts/0 S+ 21:06 0:02
/usr/bin/qemu-arm-static /usr/lib/git-core/git-remote-https origin
https://github.com/RobertCNelson/boot-scripts
root 29275 0.0 0.0 4203228 5380 pts/0 S+ 21:06 0:00
/usr/bin/qemu-arm-static /usr/lib/git-core/git fetch-pack
--stateless-rpc --stdin --lock-pack --include-tag --thin --depth=1
https://github.com/RobertCNelson/boot-scripts/
root 29278 0.0 0.0 4137840 3792 pts/0 S+ 21:06 0:00
/usr/bin/qemu-arm-static /usr/lib/git-core/git fetch-pack
--stateless-rpc --stdin --lock-pack --include-tag --thin --depth=1
https://github.com/RobertCNelson/boot-scripts/
jvaller+ 32164 0.0 0.0 10288 880 pts/1 S+ 21:28 0:00 grep git

If I git clone the boot-scripts repository outside of this script, I
have no issues. It only hangs when run from the
beagleboard.org_image.sh script. This is on 64-bit Debian "jessie".
Any ideas on what might be causing this?

[Robert Nelson]

It boils down to... qemu is bitrotten and just plain sucks... At one
time it worked really great. (okay that's a lie, but it worked..)

See the note right before the git clone.. ;)

Log: (chroot) Warning, qemu can fail here... (run on real armv7l
hardware for production images)

Regards,

[daw...@gmail.com]

On Wednesday, January 29, 2014 4:09:44 PM UTC-5, RobertCNelson wrote:

 

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

Found this thread via google search, so I am probably missing something.  But I can't run these commands because I don't know the root password. 

I can say that on boot with my LCD7, there is really no difference with the Angstrom version.  When the calibrate routine comes up at boot, I can click the first target with finger or stylus, but when the second comes up, the only way it will click is if I touch about half an inch to the left.  Only once have I managed to click the third target.  Usually I get a misclick message and it starts over.  If I let it time out, it moves on.  If I then touch the screen, the mouse pointer starts shaking.  

I do have a mouse connected, and eventually this build gives me mouse control back, which is better than the Angstrom build where I had to press reset to get it to stop.

This is my first week with this board, and while I'm a long time Linux user, and long time software developer, I am a brand new Linux software developer, so I'm still in the steep portion of the learning curve.  I'm following Malloy's guides mostly, in a VirtualBox VM so I can move my dev image around between work and home.

 

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

Wicd finds my network via my USB wifi adapter.  RaLink RT3572.  I can connect, then load chromium and surf the net just fine.

I'm a little hesitant to try connman.  If it isn't broke, don't fix it...

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

Is there a place I can learn more about this?

My eventual goal is to strip this down to a non X system running QT embedded apps on the framebuffer for an embedded kiosk style system.  Most of my peripherals are either USB or serial, so my "cape" will be more like a USB hub than anything else, combining LCD interface and power supplies with the hub electronics and USB to serial chips all on the same board.  Around four discrete GPIO inputs and a 4x4 matrix keyboard are about it for other I/O, so I don't anticipate this being terribly difficult.  I'm hoping that the USB serial ports will always come up in the same /dev/ttyXXX locations (may have to learn udev for that) but that shouldn't be much different than desktop linux.  I really don't see the need for X and a full desktop for this.  Wired Ethernet and WLAN (USB) 3G cell modem support will be needed, but not WiFi (using that now just because there is no cable to my kitchen table).

Jeff.

[Robert Nelson]

On Mon, Feb 10, 2014 at 8:59 PM, <daw...@gmail.com> wrote:

On Wednesday, January 29, 2014 4:09:44 PM UTC-5, RobertCNelson wrote:

 

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

First, there is a newer release of this test image posted here:

https://groups.google.com/d/msg/beagleboard/D1ioNrzzXfQ/LdfJ2ccuiY4J

 

Found this thread via google search, so I am probably missing something.  But I can't run these commands because I don't know the root password. 

The root password is blank, the default user's "debian" password is "temppwd" this should be detailed on the serial prompt login.

 

I can say that on boot with my LCD7, there is really no difference with the Angstrom version.  When the calibrate routine comes up at boot, I can click the first target with finger or stylus, but when the second comes up, the only way it will click is if I touch about half an inch to the left.  Only once have I managed to click the third target.  Usually I get a misclick message and it starts over.  If I let it time out, it moves on.  If I then touch the screen, the mouse pointer starts shaking.  

Please retry with last week's image, there was a few xinput fixes pulled in..

 

I do have a mouse connected, and eventually this build gives me mouse control back, which is better than the Angstrom build where I had to press reset to get it to stop.

This is my first week with this board, and while I'm a long time Linux user, and long time software developer, I am a brand new Linux software developer, so I'm still in the steep portion of the learning curve.  I'm following Malloy's guides mostly, in a VirtualBox VM so I can move my dev image around between work and home.

 

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

Wicd finds my network via my USB wifi adapter.  RaLink RT3572.  I can connect, then load chromium and surf the net just fine.

I'm a little hesitant to try connman.  If it isn't broke, don't fix it...

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

Is there a place I can learn more about this?

./setup_sdcard.sh --help

More docs here:

http://elinux.org/BeagleBoardDebian#Debian_Stable_.28wheezy.29

 

My eventual goal is to strip this down to a non X system running QT embedded apps on the framebuffer for an embedded kiosk style system.  Most of my peripherals are either USB or serial, so my "cape" will be more like a USB hub than anything else, combining LCD interface and power supplies with the hub electronics and USB to serial chips all on the same board.  Around four discrete GPIO inputs and a 4x4 matrix keyboard are about it for other I/O, so I don't anticipate this being terribly difficult.  I'm hoping that the USB serial ports will always come up in the same /dev/ttyXXX locations (may have to learn udev for that) but that shouldn't be much different than desktop linux.  I really don't see the need for X and a full desktop for this.  Wired Ethernet and WLAN (USB) 3G cell modem support will be needed, but not WiFi (using that now just because there is no cable to my kitchen table).

Regards,

[daw...@gmail.com]

On Tuesday, February 11, 2014 9:35:48 AM UTC-5, RobertCNelson wrote:

The root password is blank, the default user's "debian" password is "temppwd" this should be detailed on the serial prompt login.

For some reason, when I tried that on the terminal (via keyboard on the board itself) it kept asking for password, but I tried via SSH and it worked.

 

Please retry with last week's image, there was a few xinput fixes pulled in..

Will try this tomorrow.  We're likely to have a snow day tomorrow and I'll be at loose ends at home.

 

Is there a place I can learn more about this?

./setup_sdcard.sh --help

More docs here:

http://elinux.org/BeagleBoardDebian#Debian_Stable_.28wheezy.29

 

Will also give this a go tomorrow as well.

 

 Jeff.

[Jason Kridner]

On Wed, Jan 29, 2014 at 4:09 PM, Robert Nelson <robert...@gmail.com> wrote:

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

I have to say, I don't like this on by default. It drove my robot crazy! Driving pins without detection seems like an overall BAD(tm) idea.

 

--
For more options, visit http://beagleboard.org/discuss
---

You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

[Micka]

Hi,

I'm using the image http://rcn-ee.net/deb/testing/2014-01-29/debian-7.3-lxde-armhf-2014-01-29.tar.xz because I needed the x server already installed .

But I can't find how to disable lxde from starting .... anyone know ?

[Robert Nelson]

On Tue, Feb 25, 2014 at 7:47 AM, Micka <micka...@gmail.com> wrote:
> Hi,
>
> I'm using the image
> http://rcn-ee.net/deb/testing/2014-01-29/debian-7.3-lxde-armhf-2014-01-29.tar.xz
> because I needed the x server already installed .
>
> But I can't find how to disable lxde from starting .... anyone know ?

I told lightdm to autostart lxde

https://github.com/RobertCNelson/omap-image-builder/blob/master/target/chroot/beagleboard.org.sh#L108

so change it

Regards,

[Micka]

Ok thx, I figured out how to disable lightdm :

sudo update-rc.d lightdm disable

thx,