Right now i have both the lcd4 (lcd4-01-00a1) and lcd7 (lcd7-01-00a3)
working in my git repo. Currently transitioning them to the 3.14 ti
branch and will update the wiki with what 'minimal' kernel is needed.
I'm looking for leads on the lcd7 (lcd7-01-00a4 (max touch model)) and
lcd3 (lcd3-01-00a2).
btw, what's your guys thoughts on the simplified dts file, here is the
black: Simple enough for end users to enable/disable things for their
custom capes?
Say you have a custom bbb, in which you need 2 uarts and the spi port
enabled. With overlay's you'd have to load ttyO1, ttyO4 and spidev. In
this case, you just uncomment:
Robert, I understood it perfectly, as I have a very strong C/C++ programming background. Was just saying when / if this is implemented, you’re going to need to explain it further for some.
One thing that I am curious about is the workflow for building the .dtb being used by the end user using this universal cape design. Will the boot .dtb be built at kernel compile time only? Or are there plans for the arch/arm/boot/am33*.dts* and associated files to be built independently of the kernel to allow for modifications of the boot .dtb without requiring a kernel rebuild?
If it is built only at kernel build time, is it possible to use #define preprocessor logic to selectively enable pieces of the universal cape .dts* files via menuconfig (and avoid end-users having to edit the .dts* files themselves)?
Also, is HDMI audio not included in the RCN 3.14 kernel? I was just looking through the current 3.14 BB kernel on github and saw the McASP pins and compatibility for the am33xx audio driver in the .dts files, but the RCN kernel only has McASP mappings for the audio cape. For the universal cape, will the HDMI audio functionality be rolled into the include file for the nxp-hdmi cape? I figure that the two kernel trees will converge together to include all functionality eventually, but I am curious how HDMI audio will be handled for the universal cape design. Two HDMI cape includes (one with audio, one without)? Or one for HDMI video and one for HDMI audio? It seems like the second one would be better to avoid trouble with people accidentally enabling both, since it turns a mutual exclusion setup into an additive one...
btw, what's your guys thoughts on the simplified dts file, here is the
black: Simple enough for end users to enable/disable things for their
custom capes?
not horribly awful, but I think we still want to enable every bit we can by default and use the pinmux helper.
One thing that I am curious about is the workflow for building the .dtb
being used by the end user using this universal cape design. Will the boot
.dtb be built at kernel compile time only? Or are there plans for the
arch/arm/boot/am33*.dts* and associated files to be built independently of
the kernel to allow for modifications of the boot .dtb without requiring a
kernel rebuild?
Today, they are the kernel directory. There is an external project
tracking just the *.dts files:
I'm going to fork that repo, and add our *.dts changes, then it'll be
really easy to generate a new *.dtb on the target with
customization's...
If it is built only at kernel build time, is it possible to use #define
preprocessor logic to selectively enable pieces of the universal cape .dts*
files via menuconfig (and avoid end-users having to edit the .dts* files
themselves)?
That would be a neat option. In the back of my mind i was also
thinking some kinda html5 gui -> dts -> dtb setup.
Also, is HDMI audio not included in the RCN 3.14 kernel? I was just looking
through the current 3.14 BB kernel on github and saw the McASP pins and
compatibility for the am33xx audio driver in the .dts files, but the RCN
kernel only has McASP mappings for the audio cape. For the universal cape,
will the HDMI audio functionality be rolled into the include file for the
nxp-hdmi cape? I figure that the two kernel trees will converge together to
include all functionality eventually, but I am curious how HDMI audio will
be handled for the universal cape design. Two HDMI cape includes (one with
audio, one without)? Or one for HDMI video and one for HDMI audio? It
seems like the second one would be better to avoid trouble with people
accidentally enabling both, since it turns a mutual exclusion setup into an
additive one...
Right now, in v3.14-ti we don't have hdmi audio, it was just posted
for v3.17-rc1, so let the backporting begin:
I want to separate the two.. There will be an option to enable hdmi
audio, or use a cape audio instead.
Aug 20 21:22 b14c60a94f59...successruntests #5 Build successful
Aug 20 21:20 20830c6f9585...failureruntests #4 Failed shell shell_1
When i pushed the branch yesterday... It decided to build twice...
The first build, took the first commit over the old branch, which
failed as bb.org_defconfig is the last commit.. The second build
completed correctly.
Looks like build#6 is a rebuild of build#4
can you add:
if [ -e arch/arm/configs/bb.org_defconfig ] ; then
build
fi
g_multi is flaky, doesn’t connect via usb0 to the host.
Then when connecting to the BBB via its network address over ethernet:
*Cannot GET /%7B%7Bsite.baseurl%7D%7D/Support/bone101/*
Then connecting to the ethernet IP:8080, gives and empty apache directory.
When first setting up the latest testing image, it took me a bit to figure out how everything needed to be setup, and finally I had to edit the boot partitions uEnv.txt and manually set ${uname_r} variables to hard paths. Not sure if this is normal or not, but I knew this would work. Also the first several times I tried to log in via ssh with puTTY or Linux ssh root/debian@ipaddress, I could not log in.
Overall I would have to ay the experience was rather disappointing. I had hopes of toying around with the cloud9 version that runs on Nodejs v0.10.x, but no joy . . .
Any chance of us normal people getting the source for the version of cloud9 that does run on Nodejs v0.10.25 ?