Op 20 apr. 2013, om 01:07 heeft Gary Oliver <g...@aerodesic.com> het volgende
geschreven:
> I've been working with Angstrom for beaglebone since late 2011 and have been
> comfortably using the analog access through the sysfs API, but since updating
> to V2012.12, it no longer works. I've Googled until my fingers almost bleed
> (a slight exaggeration) looking for clues, but all I can find is what appears
> to be motion toward inclusion of a touch-panel system causing conflicts with
> the analog channel access. I've seen a few questions by others about this,
> but no resolution nor information as to how the problem can be resolved.
>
> I've patched what appear to be the requisite files in arch/arm/boot/dts
> (found mentioned occasionally) so that the tsdadc stuff is 'enabled' so now
> the driver does get instantiated, but none of the channels appear and I can't
> seem to find any way they *would* appear from perusing the driver source.
> I'm no noob to linux (been hacking since 0.12 *way back when*) so I do know
> my way around the kernel and I've written quite a few drivers for my own
> purposes and some for custom user applications, so I *generally* understand
> things even though the ARM stuff have moved that in a significantly further
> direction than my current experience. Some messages suggest there is (or
> will be) a char driver in 3.8 (the current kernel is 3.8.2) but I find no
> evidence of that in the system, as built, nor do I find any kernel configs to
> create it.
Have a look at firmware/capes/cape-bone-iio-00A0.dts and on your bone do:
echo cape-bone-iio > /sys/devices/bone_capemgr.7/slots
You can check if it worked by 'dmesg | grep -i cape':
[165263.284977] bone-capemgr bone_capemgr.7: part_number 'cape-bone-iio',
version 'N/A'
[165263.285401] bone-capemgr bone_capemgr.7: slot #6: generic override
[165263.285463] bone-capemgr bone_capemgr.7: bone: Using override eeprom data
at slot 6
[165263.285522] bone-capemgr bone_capemgr.7: slot #6: 'Override Board
Name,00A0,Override Manuf,cape-bone-iio'
[165263.291534] bone-capemgr bone_capemgr.7: slot #6: Requesting part
number/version based 'cape-bone-iio-00A0.dtbo
[165263.291610] bone-capemgr bone_capemgr.7: slot #6: Requesting firmware
'cape-bone-iio-00A0.dtbo' for board-name 'Override Board Name', version '00A0'
[165263.291674] bone-capemgr bone_capemgr.7: slot #6: dtbo
'cape-bone-iio-00A0.dtbo' loaded; converting to live tree
[165263.292050] bone-capemgr bone_capemgr.7: slot #6: #1 overlays
[165263.318681] bone-capemgr bone_capemgr.7: slot #6: Applied #1 overlays.
And
root@beaglebone:~# find /sys/ | grep AIN
/sys/devices/ocp.2/helper.9/AIN0
/sys/devices/ocp.2/helper.9/AIN1
/sys/devices/ocp.2/helper.9/AIN2
/sys/devices/ocp.2/helper.9/AIN3
/sys/devices/ocp.2/helper.9/AIN4
/sys/devices/ocp.2/helper.9/AIN5
/sys/devices/ocp.2/helper.9/AIN6
/sys/devices/ocp.2/helper.9/AIN7
root@beaglebone:~# cat /sys/devices/ocp.2/helper.9/AIN7
4
> My confusion comes from not understanding motives of the development process.
> Even when building a standard 'cloud9-gnome-image' version, the ADC doesn't
> show up and yet it's part of the documented interfaces provided by
> information from TI.
At this point you just cannot trust any documentation from TI when it is about
the kernel :( At Circuitco we had to develop a lot of this on our own because
TI couldn't produce working drivers. And these interfaces will likely change
again in the 3.10 kernel when we can hopefully use upstream drivers.
The drivers for the on-SoC components are done by different teams in TI and as
with every company some teams are great, others are a waste of space. The EDMA,
HDMI, HDMI-audio drivers and u-boot integrations were done by rockstars, but
ADC, networking, USB came out of the software sweatshop.
> Considering I may have missed something, I'm hoping to find there is a
> simple configuration/patch step I've missed or that "real soon now" the
> kernel will be re-updated to include these missing features.
>
> I could drop back to V2012.05, but I appreciate the fact that power
> management works sufficiently for me to actually power down the device, so I
> can abandon my patches that fixed that missing functionality. Lots of
> progress has been made by this new release and moving to the Yocto environment
FWIW, Angstrom has been based on the Yocto Project since late 2010, so v2012.05
was already 'yocto'. It's just that we're officially compatible with Yocto
Project 1.3 with the v2012.12 release. Between yocto 1.2 and 1.3 a lot of work
was done to iron out host distro related bugs, so it tends to break less on
e.g. ubuntu. And combine that with 4 months of testing and polishing (yes,
v2012.12 slipped 4 months) you get a much better experience.
Anecdotal evidence: I tried to get v2012.05 to build on Centos yesterday and
gave up after an hour, v2012.12 "just worked".
> is a HUGE improvement (IMHO) so I don't want to 'go back.' I made a stab at
> moving to V2013.06 but was met with numerous compile issues, though I admit I
> may have pulled some incorrect updates (still learning the git mechanics of
> this project.)
I think I fixed most of the compile problems with v2013.06, but it's still not
ready for consumption, the resulting images will get stuck during init.
Feedback on that is very welcome, but keep in mind that it's not meant for the
masses yet.
> I don't want anyone to take this as a rant, even thought it probably sounds
> like one. That tone comes only from not understanding the motives of the
> developers and finding myself feeling stranded with respect to status of this
> particular subsystem.
I understand completely how you feel, the process of getting 3.8 working on
bone has been very frustrating. The Designwest tradeshow next week is the
deadline for number of projects at work featuring angstrom which means the rush
is over and I finally have time to read the user feedback and give
multi-sentence responses :)
regards,
Koen
_______________________________________________
Angstrom-distro-devel mailing list
Angstrom-distro-devel@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
