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...
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
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?
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..
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
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.
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?
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.
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...
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.
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..
Otherwise the biggest cpu hog was actually the screensaver. (xorg/lxde
wasn't too resource intensive..)
Which i've now disabled by default:
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..
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.
