Any thoughts on adding a custom .dts to the build script to be included in the kernel?
I have some notes from someone else:
But it looks like it’s downloading a pre-build kernel?
Thanks!
-W.
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,
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…
Yes,
those 3 seem to grow very fast:
kern.log
syslog
debugI 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..
Regards,
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 )
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
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..
Regards,
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:
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§ion=all
make sure to refresh via:
apt-get update ; apt-get install xyz
Let me know what you need to make it work..
Regards,
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!
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
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
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..
Regards,
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.
But i'd really like someone to write a script to automate the resize
on bootup from the bbb..
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,*
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.
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
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..
Regards,
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…
