debian: test images (2014-01-10)

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

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!

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,

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.

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.

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,

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

Regards,

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 :wink:
Regards,

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

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

root@beaglebone:~# halt
a
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.

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

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,

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

Regards,

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,

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

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

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

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?

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

Regards,

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

Regards,

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

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.. :wink: )

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,

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 :slight_smile:

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