On Sun, Apr 30, 2017 at 10:03 PM, David Faulkner wrote:
> Ok, well I will try it out and let you know if it works. Do I have to
> disable the HDMI to avoid pin conflicts?
Yeapers..
Regards,
--
Robert Nelson
https://rcn-ee.com/
--
For more options, visit
Ok, well I will try it out and let you know if it works. Do I have to
disable the HDMI to avoid pin conflicts?
On Sunday, April 30, 2017 at 9:55:31 PM UTC-5, RobertCNelson wrote:
>
>
>
> On Sun, Apr 30, 2017 at 9:20 PM, David Faulkner > wrote:
>
>> That link is for
On Sun, Apr 30, 2017 at 9:58 PM, David Faulkner wrote:
> The link RNC provided was device tree source files for 3 different LCD's,
> not kernal builds.
> I am very confused by "dtbo should be included with the kernal" because I
> thought the whole point
> of using device
The link RNC provided was device tree source files for 3 different LCD's,
not kernal builds.
I am very confused by "dtbo should be included with the kernal" because I
thought the whole point
of using device trees was to avoid having to recompile the kernal...
In /lib/firmware you are correct,
On Sun, Apr 30, 2017 at 9:20 PM, David Faulkner
wrote:
> That link is for different dts files which I have seen before.
> So if I took one of them and compiled it to a dtbo file which is the
> correct way to enable it?
>
> I have seen it done 2 ways:
>
> 1) Through the
The dtbo file should be included in the kernel. The commit RCN linked
to was from two days ago.
...so, your issue has been fixed, but you need to update to a kernel
that includes the fix (ie: less than two days old).
On 4/30/2017 9:20 PM, David Faulkner wrote:
That link is for different
That link is for different dts files which I have seen before.
So if I took one of them and compiled it to a dtbo file which is the
correct way to enable it?
I have seen it done 2 ways:
1) Through the uEvt.txt file
2) Using the echo command to write to the slots file
Both were done with
I usually just delete these kind of posts without reading them, but I
recognized the name as someone whose posted recently so I did not delete
it, but no way I was going to try and read that wall of text. especially
when I'm writing software . . .
Do us a favor in the future Joseph.
On Sun, Apr 30, 2017 at 3:03 PM, Joseph Heller
wrote:
> I just stumbled upon an issue I had encountered a year ago as well, and
> would like to share some thoughts on this here. All help appreciated, don't
> get me wrong, and I'm sure it will be resolved but I recalled
So, I'd have to say there is no good advice on how to proceed in this
situation. Simply because it's not just hardware that needs to change. The
software, from the first stage boot loader all the way into the Linux
kernel and rootfs may have to be modified. Not to mention that it would be
hard
Justin:
>From your questions, you seemed to have an over-simplified view as to how
the clocks are generated in the Sitara.
It is not your grandfather's PIC.
It is a very modern, sophisticated, clock system, with many of the clock
subsystems being variable rate.
A "Clock Tree" is the generic
You may find this tool from TI
useful: http://processors.wiki.ti.com/index.php/AM335x_Clock_Tree_Tool
On Saturday, April 29, 2017 at 10:14:31 PM UTC+3, Justin Pearson wrote:
>
> Thanks Graham. What do you mean by "check and verify the clock tree
> behavior"? I searched the TRM for "clock tree"
12 matches
Mail list logo