These commands are for LCD. Connecting any other device but the ULCD
panel to the expansion causes these errors. Ideally we'd want to check
if defaultdisplay=lcd and then execute the commands if true. Can you
comment out the i2c commands in the the uEnv.txt on your SD Card?
It's a headless system, I don't have anything attached to the display/lcd ports.
Errors disappeared after commenting out the lcd* and uenvcmd lines.
No idea why! Devices connected to i2c2 on the expansion such as LCD
panel and camera are working fine. I am not sure but aren't these
device nodes created after a device successfully acquires the bus?
Second bus is routed to the main expansion connector and the camera,
bus 3 controls the displays. With the 2.3.39 kernel from Angstrom
repository all buses have nodes in /dev and are accessible from user
programs, so I don't think this is caused by a conflict with camera
driver in the kernel. Especially that the camera is disabled in uEnv:
camera=none .
Looks that the kernel detects only buses 1 and 3:
------- cut here -------
root@new-host-6:~# dmesg |grep -i i2c
[ 0.067077] omap_i2c omap_i2c.1: bus 1 rev4.0 at 2600 kHz
[ 0.077239] omap_i2c omap_i2c.3: bus 3 rev4.0 at 100 kHz
[ 3.408142] input: twl4030_pwrbutton as
/devices/platform/omap/omap_i2c.1/i2c-1/1-0049/twl4030_pwrbutton/input/input1
[ 3.419891] i2c /dev entries driver
root@new-host-6:~#
------- cut here -------
j.
Hi Jason,
Joel,
Can you start doing regular rebuilds as the repositories are updated?
Perhaps you can somehow use the existing build servers?
Ideally we'll want to run through testing, and after adding any
features requested. Are you ok with pushing images just build-tested
from updated repositories (regularly)?
Yes, as long as we are clear when something is tested or not and how. We can automate some testing as well.
Also, can you include all the specific tags for the repositories such
that things can be rebuilt? With your current layers.txt approach,
not only do you fork people from upstream work, you don't let them
know which particular commit id works. If you want to provide a
layers.txt, include the exact commit ids in that file.
I'd rather dump this information into /etc/angstrom-version , unless
its already doing so. Much cleaner no?
Can you propose a patch?
Also, can you include all the specific tags for the repositories such
that things can be rebuilt? With your current layers.txt approach,
not only do you fork people from upstream work, you don't let them
know which particular commit id works. If you want to provide a
layers.txt, include the exact commit ids in that file.
I'd rather dump this information into /etc/angstrom-version , unless
its already doing so. Much cleaner no?
Can you propose a patch?
Koen just wrote a patch for this [1]. This will do what you're asking
From an easy image rebuild-ability standpoint, the cleanest solution
would be to provide a setup-scripts fork with git-tags for the various
image release versions with the appropriate layers.txt modifications.
This fork should go on a beagleboard.org git repository if possible.
Thanks,
Joel
[1] http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-angstrom/commit/?id=9039f715810ca4d40944a6f369e605d1d75f0c9f