Re: [beagleboard] TI PRU_ADC_onChip example

[Jeff Andich]

This thread doesn’t appear to appear on the revamped beagleboard forums..
correct me if I'm wrong..

Should it be added retroactively or should we create a thread on the new
forums with a link to this?

Thanks!


On Tue, May 11, 2021 at 7:01 PM 'Mark Lazarewicz' via BeagleBoard <
beagleboard@googlegroups.com> wrote:

> Hello Walter and Cheng
>
> I spent 2 hours total doing following
>
> 1)Created Ubuntu 16.04 LTS  Dev Box using VBOX on Win 7
> 2) Created SDK linux SD card using image writer on Windows booted Linux on
> Beaglebone White
> 3) Rebuilt kernel sources created images of customized kernel and replaced
> these on SD card
>
> *I have a full development environ Now !*
>
> Next step add a kernel driver I wrote and understand how use the OCP
> shared RAM to get large amounts of data from PRU to linux
>
> ***
>
>  __   _ _
> |  _  |___ ___ ___ ___   |  _  |___ ___  |_|___ ___| |_
> | |  _| .'| . | . |  |   __|  _| . | | | -_|  _|  _|
> |__|__|_| |__,|_  |___|  |__|  |_| |___|_| |___|___|_|
>   |___||___|
>
> Arago Project http://arago-project.org am335x-evm ttyS0
>
> Arago 2019.11 am335x-evm ttyS0
>
> am335x-evm login: [  143.131162] NET: Registered protocol family 15
> [  143.545960] Initializing XFRM netlink socket
>
>  __   _ _
> |  _  |___ ___ ___ ___   |  _  |___ ___  |_|___ ___| |_
> | |  _| .'| . | . |  |   __|  _| . | | | -_|  _|  _|
> |__|__|_| |__,|_  |___|  |__|  |_| |___|_| |___|___|_|
>   |___||___|
>
> Arago Project http://arago-project.org am335x-evm ttyS0
>
> Arago 2019.11 am335x-evm ttyS0
>
> am335x-evm login:
>
>
>
> On Tuesday, May 11, 2021, 02:39:31 PM CDT, 'Mark Lazarewicz' via
> BeagleBoard  wrote:
>
>
> HI Cheng
>
> I have two Beaglebone White and the am335x SK both have JTAG on the board
> so no soldering.
> The key is to follow the labs 1 to 3 only dont use any RPMsg examples
> The other key is the PRU gel script is crucial there is a typo error in
> the instructions about correct .gel file name and how to execute it
> I used CCS 6.0 win 7 and CCS 10 on windows 10
>
> Id be glad to help if I can
>
> The power of the CCS/JTAG is reading memory locations and finding crashes
> quickly its worth the learning curve
>
> Any issues please ask but tell me your CCS version
>
> What I dont like about the PRU  tutorials is all use Linux interaction as
> in interrupts and they assume SDK linux not Debian
>
> Its some work but you could use Windows to create a SDK linux SD card for
> JTAG if problems
>
>  I have several jtags  one is USBV2 and I have yours I also have two BBB
> but even being EE I dont solder
>
> Let me know be glad to help trust me after you master CCS/JTAG you will be
> very happy and have an awesome tool in your belt
>
> Mark
>
>
> On Monday, May 10, 2021, 11:51:35 PM CDT, Cheng Chen 
> wrote:
>
>
> Hi Mark,
>
> Thanks a lot for the updates. I went through the SDK documents and I
> actually got a lot inspiration. Thanks for that.
> I bought an TMDSEMU110-U for debugging. That is recommended from TI
> tutorials of PRU debugging: PRU is connected with TMDSEMU110-U and then to
> the laptop. Is that how you debugged with JTAG ? I feel this approach is a
> little cumbersome since I need to set up a lot of environments manually.
> But it worked, so I just put up with it for now.
> I think both SDK and Beaglebone has a lot of interesting stuffs worth
> being explored. Appreciate your help!
>
> Regards,
> Cheng
> 在2021年5月8日星期六 UTC-4 下午7:52:41 写道：
>
> Hello Cheng
>
> I learned a few things this weekend I thought I would share
>
> The PRU  Labs examples 1 to 3 can be loaded with CCS and JTAG from Windows
> 10
>
> You can even debug both PRU0 and PRU1 at the same time examine memory and
> use HW  uart debug to speed up development
>
> The RPMSG example LAB  must be loaded by the linux or TI RTOS drivers
> running on ARM side
>
> I have win 7 and Windows 10 CCS/JTAG installations working one  a
> Beaglebone White and the other AM335X SK
> BBB is also supported
>
> My Last step is building the SDK  linux kernel from scratch  with rproc
> kernel modules loaded  from a VirtualBox Ubuntu VM on Win 7
>
> The Linux  SDK has binaries for the ARM side *so a  Native Linux BOX is
> NOT REQUIRED(but recommended )*
>
> *CCS DOES NOT require linux to load and debug PRU *
>
> For those that want to learn ARM TI RTOS Win 10 is required to build
>
> The SDK documents I saved as the wiki is disappearing are awesome I found
> some very detailed PRU documentation that talks about everything from
> running TI PRU firmware On PRU ICCS for complex Industrial protocols as
> well a custom PRU code
>
> The facts about clock cycles also were discussed. All of it in can be
> found by following the documentation tar ball I sent I you.
>
> I think too many people panic dont want to run SDK 

Re: [beagleboard] TI PRU_ADC_onChip example

[Jeff Andich]

Very informative thread guys!

Interesting article in E2E on accessing shared memory and RPMsg..

This statement by Jason Reader

“…Also, if you are testing an RPMsg project you will need to use the
pruss_remoteproc Linux module to load the code and not CCS over JTAG. …”

could be a clue as to the issue I was having attempting to load the C66
with JTAG after remoteproc initially loaded the RPMsg example project.  The
stock example program was referred to in a post a couple of months ago  (
https://forum.beagleboard.org/t/status-running-ti-sdk-built-c66-dsp-example-exe-on-bb-x15-beagleboard-debian/27469
). If I allowed remoteproc to load the C66 example program, and downloaded
only the symbol file for DSP1/C66 via CCS/JTAG, I was able to set and reach
breakpoints.  However, if I disabled remoteproc’s loading of the exe and
attempted to load the entire C66 executable via JTAG, I got an error
message ( from memory, remoteproc ID not found).  I will reproduce and post
up the detail  in a separate post…




On Tue, May 4, 2021 at 5:20 PM 'Mark Lazarewicz' via BeagleBoard <
beagleboard@googlegroups.com> wrote:

> Cheng
>
> Yes difference between the two Linux is why the E2E wants to know which
> Linux you running.
>
> Walter
>
> Here is a shared RAM CCS JTAG PRU discussion but as Cheng stated the user
> is using SDK Linux.
>
> Perhaps the code examples will help you solve your freeze up. It's
> possible ARM Linux is using that memory.
>
> Looks like the TI PRU expert is very helpful as long as your using the SDK.
>
>
> https://e2e.ti.com/support/processors/f/processors-forum/484479/issue-with-accessing-shared-memory-on-pru
>
>
> Sent from Yahoo Mail on Android
> 
>
> On Tue, May 4, 2021 at 3:02 PM, Walter Cromer
>  wrote:
>
> I am glad to have helped a little bit.   Stick with it.  When it clicks
> and you start really moving forward I think you'll be pleased.
>
> Can you share the changes to the Makefile that you made?  I'm curious if
> it might help me.
>
> Right now I am reading the ADC every 2.7ms.  I'm reading three channels.
> I include the step id too and check that.  I am using switch-case to check
> the step and put the analog input into the right variable in my code.   It
> might be slighter faster with an if-elseif but I like the neatness of the
> switch-case and until it causes me timing problems, I'm sticking with it.
>
> I am also fairly certain the ADC can be read faster.  I have the ADC in
> one-shot mode and delay before I kick it off again.   I've also run this
> with no averaging, 4 averages, and 16 averages and it makes very little
> difference in timing for me.
>
> Walter
>
> On Tuesday, May 4, 2021 at 11:33:51 AM UTC-4 chen...@gmail.com wrote:
>
> Hi Walter,
>
> Thank you so much for the reply. I think my setup is exactly the same as
> what you have (win10 and BBB wireless). That really motivated me to see
> somebody else successfully run the system with the same setup.
> I actually made some preliminary progress after two nights brooding and I
> am able to read out ADC data through rpmsg. Thanks a lot for your tips.
>
> I think the problem is still in the makefile and environment. As you
> mentioned, you are using makefile from PRUcookbook while I started off with
> TI's built-in makefile.  I believe there is a couple of slight difference
> between Debian system and TI SDK environment which turns out to be critical
> in compiling. I carefully compared the difference between two makefiles and
> created one which is close to the makefile in the PRUcookbook. That works
> like a charm.
>
> Next step I also want to explore precise timing and see how fast the adc
> can run. May I ask what is the speed you are reading out from ADC?
>
> Regards,
> Cheng
>
> 在2021年5月3日星期一 UTC-4 上午11:24:23 写道：
>
> I just went through this pain and the people in this group were awesome
> help.
>
> I needed to read three analog inputs and it was a bear but once I got it,
> it has been going well.
>
> You don't mention the OS of your development platform or I may have missed
> it.  I'm on a Windows 10 box and using a BBB Wireless.  TI's entire
> learning system for this expects a Linux development platform so it's not
> as useful as it could be if you are on Windows.  I didn't want to go to the
> trouble of even bringing up a virtual Linux on my Windows box for this.  I
> did install Code Composer Studio (CCS) from TI, but gave up on it.  There's
> no easy way to transfer your compiled firmware to the BBB from within it
> according to TI.   So I just do everything on the Beagle and it meets my
> needs.
>
> I use the cloud9 IDE that ships with the BeagleBones for coding both the
> ARM and PRU code.  This environment compiles the ARM-side code and executes
> it just like any normal host (aka Linux, aka ARM) program just fine.
>  However, to compile the PRU code 

Re: [beagleboard] Re: Debug tool for M4 processors in BBAI

[Jeff Andich]

Thanks Mark for providing us all this!

I tried starting to port one of the main examples from TI RTOS SDK into the
latest Beagleboard-X15 images this weekend. Built the IPC example under the
link you posted yesterday.  Scp'd server_dsp1.xe66 to the SD card and then
linked to it, and attempted to load.

It looks like it started to load but then complained that the resource
table is not found.  I have lots more homework to do..

My plan dejour is to try to see how far I can get with that example on BB
Debian and TI SDK Linux.

I do plan to develop the DSP application with CCS and JTAG, and deploy it
using remoteproc from Linux once it's debugged.

Don't know if there are currently any Linux tools for debugging the other
cores.

But at this point I'm not sure where this will all lead..

But it sounds like there's an appetite within the Beagle community to get
this tested and working...  My guess is the more applications that can
access the other processors on the SOC, the merrier for BB.org and TI..

On Mon, Feb 15, 2021, 12:34 PM Mark Lazarewicz  wrote:

> Looks like good examples here .I also saw M4 example on github.
>
>  Dont see any documents on using Debian Linux and DSP Why?
> and wonder if that OS will supply tools to get the DSP executable
> transferred in correct format
> Cant even imagine debugging this with printf LOL and no jtag
> The DSP has to be taken out of rest when  running linux
>
>
>
>  Its documented here below why in the world someone would not use CCS and
> JTAG? and expect to run IPC on 6 core chip with no documents is beyond me.
> Any commercial customer would never accept being stonewalled by a vendor
>
> Perhaps Debain/Beagle is for hobbyists only I  dont know
>
> And for Dimtry GCC is supported
>
>
> 10.1. Target — Processor SDK RTOS Documentation
> 
>
> 10.1. Target — Processor SDK RTOS Documentation
>
>
> 
>
>
>
>
>
> The following examples demonstrate some of the rudimentary IPC
> capabilities. They are mostly two processors examples. These examples may
> be built for any two processors on your device, but only for two at a time.
> An IPC Ping example using three processors is also presented at the end.
>
>
> Why?
>
>
>
> On Monday, February 15, 2021, 09:41:20 AM CST, 'Mark Lazarewicz' via
> BeagleBoard  wrote:
>
>
> OpenVX,cmem,PRU and remote proc support today
>
>
> https://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/linux/index.html
>
>
>
> Sent from Yahoo Mail on Android
> 
>
> On Tue, Feb 9, 2021 at 8:14 AM, jeff@gmail.com
>  wrote:
> I think I have a similar question in that I'm hoping to develop an
> application (as much of a software defined radio application as I can cram
> into this platform) which utilizes the C66 DSP's on the BB-X15.  I'm trying
> to converge on a process for developing a TI RTOS application for the C66's
> on the BB-X15 which is compatible with the BB Debian distro running on the
> A15's.  More on this later, hopefully.
>
> I imagine you've already stumbled upon the following, but it seems like a
> good starting point.
>
> https://e2e.ti.com/support/processors/f/791/t/765821.
>
> Also google all of the examples on of PRU applications .  My guess is that
> may also shed some light on how to develop and debug code for the other
> processors on the Sitara SOC of interest.
>
> I just received a USB100V2 JTAG cable, and I hope to start hacking on this
> on my BB-X15 in my spare time. I have a lot of questions on how this works,
> and I will post up when I think I have something worthwhile or relevant..
>
> Also, please post up as you make progress as I imagine there are others
> wanting guidance on developing applications on the other processors on the
> SOC and interfacing Linux to them.  There's not a lot of postings on the
> C66 or M4..
>
>
>
>
>
> On Wednesday, February 3, 2021 at 8:21:36 AM UTC-5 databac...@gmail.com
> wrote:
>
>
> Hi
> I and another student have been tasked with exploring ways to develop for
> the M4 processor using BBAI. We've had difficulty finding a good debug
> setup, preferably one where you could step through instructions in the M4
> processors.
>
> Could anyone point us towards whats worth looking in to?
>
> Regards, Fredrik Eriksson
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
>
> https://groups.google.com/d/msgid/beagleboard/024abb86-4ada-4b24-b801-5119a941796en%40googlegroups.com
> 

Re: [beagleboard] Compiling Out of Tree Driver with Different Version of Toolchain Than was Used to Compile Kernel

[Jeff Andich]

Thank you sir!

Good references.

Ok, the ABI is the standard interface at the machine code level, as opposed 
to API.

Yeah, you often see the name ABI/EABI with cross compilers for embedded 
systems.  I've seen that enough times that I should have looked there.  
Will forward this post onto my colleague..

Cheers,

Jeff



On Thursday, December 6, 2018 at 3:40:33 PM UTC-6, Charles Steinkuehler 
wrote:
>
> On 12/6/2018 1:59 PM, Jeff Andich wrote: 
> > Hi, 
> > 
> > General question.   
> > 
> > Is it valid to cross compile an out of tree driver with a different 
> version 
> > of the cross compiler/toolchain than the kernel was compiled with? If 
> not, 
> > where do you draw the line? 
> > 
> > Recently we re-compiled an out of tree WiFi driver for the BBB on a PC 
> host 
> > machine, pointing it at the kernel source tree with all of the build 
> > products/generated files in it. The kernel was built with the 6.4.x 
> Linaro 
> > toolchain, however the developer built the WiFi driver with the Linaro 
> 5.4 
> > toolchain.  The developer was able to deploy the WiFi driver to the 
> target, 
> > and it worked just fine. 
> > 
> > I mentioned to the developer that, in general, it's probably safer to 
> use 
> > the same brand and version of the cross toolchain to build the driver 
> and 
> > kernel, but now I'm so sure that this has to be the case.  For instance, 
> If 
> > the function call interface is standard for all versions of the Linaro 
> > toolchain, then maybe this doesn't matter.  However, if version 4.x uses 
> > one set of registers to pass function parameters to a driver, for 
> instance, 
> > and the driver is compiled with a different version of the compiler 
> which 
> > expects the parameters to be passed in a different set of registers, 
> then 
> > there would be an issue. 
> > 
> > What's the rule of thumb here or what's a good reference to better 
> > understand the interfaces? 
>
> What you mentioned (register use and parameter passing) is known as 
> calling conventions, which are part of the full ABI (Application 
> Binary Interface) which specifies those and other details of the 
> target platform: 
>
> https://en.wikipedia.org/wiki/Application_binary_interface 
>
> As long as the ABI is compatible, you should be able to compile kernel 
> modules using whatever compiler you want. 
>
> There are lots of different ABIs for the ARM platform because there 
> are a wide range of CPUs with different features (eg: hard floating 
> point, NEON support, thumb instructions, etc).  That's why you wind up 
> with long lists of cross-compiler tool chain variants, eg: 
>
> https://releases.linaro.org/components/toolchain/binaries/latest-7/ 
>
> -- 
> Charles Steinkuehler 
> cha...@steinkuehler.net  
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/a7a6494d-207c-4664-9e43-cf977f061c37%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Compiling Out of Tree Driver with Different Version of Toolchain Than was Used to Compile Kernel

[Jeff Andich]

Hi,

General question.  

Is it valid to cross compile an out of tree driver with a different version 
of the cross compiler/toolchain than the kernel was compiled with? If not, 
where do you draw the line?

Recently we re-compiled an out of tree WiFi driver for the BBB on a PC host 
machine, pointing it at the kernel source tree with all of the build 
products/generated files in it. The kernel was built with the 6.4.x Linaro 
toolchain, however the developer built the WiFi driver with the Linaro 5.4 
toolchain.  The developer was able to deploy the WiFi driver to the target, 
and it worked just fine.

I mentioned to the developer that, in general, it's probably safer to use 
the same brand and version of the cross toolchain to build the driver and 
kernel, but now I'm so sure that this has to be the case.  For instance, If 
the function call interface is standard for all versions of the Linaro 
toolchain, then maybe this doesn't matter.  However, if version 4.x uses 
one set of registers to pass function parameters to a driver, for instance, 
and the driver is compiled with a different version of the compiler which 
expects the parameters to be passed in a different set of registers, then 
there would be an issue.

What's the rule of thumb here or what's a good reference to better 
understand the interfaces?

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/3c60199f-1830-4455-acbd-7f24bf46db01%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] What to do about Denial of Service Vulnerability for Kernel version's 4.9+ ?

[Jeff Andich]

Thanks a lot Robert!!!

Will fetch it, build it, deploy, and test on our image..

Regards,

Jeff

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/3889f04f-778e-471b-80af-106b8b990d24%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] What to do about Denial of Service Vulnerability for Kernel version's 4.9+ ?

[Jeff Andich]

Ok thanks a lot Robert!!!

On Monday, October 22, 2018 at 2:24:58 PM UTC-5, RobertCNelson wrote:
>
> On Mon, Oct 22, 2018 at 2:10 PM Jeff Andich  > wrote: 
> > 
> > Robert, 
> > 
> > We've got a BBB where we're running, 
> bone-debian-9.3-console-armhf-2018-03-05-1gb.img.  It has kernel 
> 4.9.82-ti-r102. 
> > 
> > We need to stick with kernel version 4.9 as our WiFi driver (SI Labs 
> WF111) currently only compiles for kernels up to 4.9.  Compile breaks for 
> kernel 4.14.69. 
> > 
> > To apply the DoS patch to 4.9.82-ti-r102, is there an easier way than to 
> apply a kernel patch, then to have to re-build the kernel from the patched 
> kernel source??  For instance, is there a package which will apply the 
> patch? We're trying to stick as close as possible to stock images, if at 
> all possible, so that people less familiar with Linux can re-generate an 
> image. 
> > 
> > Also, if we need to re-build the kernel, the above links reference 2 
> patches with minor differences.  Is there a specific version of the patch 
> we need for kernel 4.9, or can we just apply the latest patch for 4.17.11? 
> > 
> > Thanks in advance!! 
>
> That patch got back-merged in v4.9.116 
>
>
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/?h=v4.9.116
>  
>
> My last v4.9.x build was: ABI:1 LTS49 4.9.105-ti-r114 
>
> I see ti has finally updated there repo: 
>
>
> http://git.ti.com/gitweb/?p=ti-linux-kernel/ti-linux-kernel.git;a=shortlog;h=refs/heads/ti-linux-4.9.y
>  
>
> RT is still stuck on: 4.9.115-rt93 
>
> https://mirrors.edge.kernel.org/pub/linux/kernel/projects/rt/4.9/ 
>
> So give me a moment, let's see if i can update it.. 
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/f29df229-9089-4866-aa72-150ebb9a3ae3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] What to do about Denial of Service Vulnerability for Kernel version's 4.9+ ?

[Jeff Andich]

Robert,

We've got a BBB where we're 
running, bone-debian-9.3-console-armhf-2018-03-05-1gb.img.  It has kernel 
4.9.82-ti-r102.  

We need to stick with kernel version 4.9 as our WiFi driver (SI Labs WF111) 
currently only compiles for kernels up to 4.9.  Compile breaks for kernel 
4.14.69.

To apply the DoS patch to 4.9.82-ti-r102, is there an easier way than to 
apply a kernel patch, then to have to re-build the kernel from the patched 
kernel source??  For instance, is there a package which will apply the 
patch? We're trying to stick as close as possible to stock images, if at 
all possible, so that people less familiar with Linux can re-generate an 
image.

Also, if we need to re-build the kernel, the above links reference 2 
patches with minor differences.  Is there a specific version of the patch 
we need for kernel 4.9, or can we just apply the latest patch for 4.17.11?

Thanks in advance!!


Jeff



On Tuesday, August 7, 2018 at 9:24:26 AM UTC-5, Jeff Andich wrote:
>
> Good to know!
>
> Thanks!!
>
> Jeff
>
>
> On Tuesday, August 7, 2018 at 9:14:46 AM UTC-5, RobertCNelson wrote:
>>
>> On Tue, Aug 7, 2018 at 8:50 AM Jeff Andich  wrote: 
>> > 
>> > Hello, 
>> > 
>> > We got an email at work about the following advisories about a denial 
>> of service vulnerability in the TCP implementation in kernel versions 4.9 
>> and greater: 
>> > 
>> > https://www.kb.cert.org/vuls/id/962459. 
>> > 
>> > There's a patch, called out in the above link, and the patch comments 
>> describe the issue and the current fix: 
>> > 
>> > 
>> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/patch/?id=1a4f14bab1868b443f0dd3c55b689a478f82e72e
>>  
>> > 
>> > If we're running kernel version 4.9 or greater on our 
>> beaglebone/beagleboard products, what do you recommend we do? 
>> > 
>> > Should we go ahead and apply the patch to every image we download from 
>> beagleboard.org with kernel 4.9 or greater if we're connecting our 
>> beagles on the internet and are concerned about the attack, or has the fix 
>> already be "rolled" into certain images? 
>>
>> Already included in: 
>>
>> 4.17.11 
>>
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v4.17.11=db11182a1e38e7149804962111622b15bd9aeff2
>>  
>>
>> 4.14.59 
>>
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v4.14.59=f3a5ba6310e11df370f6888ed716d1486896d983
>>  
>>
>> Our update script already pulls in: 
>>
>> http://repos.rcn-ee.net/latest/stretch-armhf/LATEST-ti 
>>
>> ABI:1 LTS414 4.14.60-ti-r67 
>>
>> and 
>>
>> http://repos.rcn-ee.net/latest/stretch-armhf/LATEST-armv7 
>>
>> ABI:1 LTS414 4.14.60-armv7-x5 
>> ABI:1 STABLE 4.17.12-armv7-x12 
>>
>> http://repos.rcn-ee.net/latest/stretch-armhf/LATEST-armv7-lpae 
>>
>> ABI:1 LTS414 4.14.60-armv7-lpae-x3 
>> ABI:1 STABLE 4.17.12-armv7-lpae-x12 
>>
>> Regards, 
>>
>> -- 
>> Robert Nelson 
>> https://rcn-ee.com/ 
>>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/2fde3d95-fc0c-424b-94ad-f476da1ecd26%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Android and PRUs

[Jeff Andich]

Also, could you please cross reference the Android forum you posted to so 
those interested can follow the status there?

Thanks!!



On Friday, August 10, 2018 at 10:37:16 AM UTC-5, Jeff Andich wrote:
>
> TI appears to offer an Android processor SDK for the Sitara 572x (BB-X15), 
> but I don't see one for the 335X (BeagleBone Black).
>
> http://www.ti.com/tool/PROCESSOR-SDK-AM57X
> http://www.ti.com/tool/PROCESSOR-SDK-AM335X
>
>
> The 572x, 571x platform has PRU's, so I'm assuming that TI provides a way 
> to load the PRU's from their Android SDK on that platform.  Maybe if you 
> peruse their forums and post questions on TI E2E, they can help provide 
> guidance on loading the PRU...
>
> Let us know what you find out..
>
> Regards,
>
> Jeff
>
>  
>
> On Friday, August 10, 2018 at 6:40:28 AM UTC-5, karl...@gmail.com wrote:
>>
>> Has anyone managed to communicate with PRUs from Android?
>> I am interested in running something on PRU0 that will send data to the 
>> CPU.
>> The main problem is that there is no remoteproc in precompiled android 
>> images. Is is possible for remoteproc to work under Android? Is there 
>> another way to communicate with PRUs from Android?
>>
>> I have no prior experience working with Android so for me it looks pretty 
>> much like linux with some features removed.
>>
>> I wasn't sure if it was better for me to ask this question here or on the 
>> Android thread so I posted it in both.
>>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/d23117f5-abee-47af-8b4c-fdc92a26ba64%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Android and PRUs

[Jeff Andich]

TI appears to offer an Android processor SDK for the Sitara 572x (BB-X15), 
but I don't see one for the 335X (BeagleBone Black).

http://www.ti.com/tool/PROCESSOR-SDK-AM57X
http://www.ti.com/tool/PROCESSOR-SDK-AM335X


The 572x, 571x platform has PRU's, so I'm assuming that TI provides a way 
to load the PRU's from their Android SDK on that platform.  Maybe if you 
peruse their forums and post questions on TI E2E, they can help provide 
guidance on loading the PRU...

Let us know what you find out..

Regards,

Jeff

 

On Friday, August 10, 2018 at 6:40:28 AM UTC-5, karl...@gmail.com wrote:
>
> Has anyone managed to communicate with PRUs from Android?
> I am interested in running something on PRU0 that will send data to the 
> CPU.
> The main problem is that there is no remoteproc in precompiled android 
> images. Is is possible for remoteproc to work under Android? Is there 
> another way to communicate with PRUs from Android?
>
> I have no prior experience working with Android so for me it looks pretty 
> much like linux with some features removed.
>
> I wasn't sure if it was better for me to ask this question here or on the 
> Android thread so I posted it in both.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/2abca2b7-46ac-4b94-88f1-6ed802b2514c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Beagleboard x15 speed

[Jeff Andich]

Well, is the usrp able to give you baseband data?

I did some very very rough benchmarks for each of the 2 C66DSP's, several 
months ago showing 

Each C66DSP:

Fs = 100kHz.
60, 152 tap FIR filters
Close to 100% utilization for each C66 core.
Assuming C66's are clocked at 750 MHz.

There's also a benchmark document from TI for the C66 (Think it is one of 
the technical documents you can view associated with the am5728 processor 
on TI's sites).  That document showed:

256 Point FFT
1782, c66x cycles
Execution time = 2.373 uS at 750 MHz clock speed.


If you're IQ samples are at Fs = 40 MHz, depending on what you want the 
C66's to do with them then this MAYBE an issue for the C66 DSP's,...


On Wednesday, August 8, 2018 at 8:38:18 AM UTC-5, syed hashir wrote:
>
> Thing is USRP can transmit data through USB 3.0 at max speed it can. But 
> Can this board process it ?. It should because it has USB 3.0 port. I am 
> not sure about the Bus speed of the board and other things
>
> On Tuesday, August 7, 2018 at 7:16:52 PM UTC+3, syed hashir wrote:
>>
>> Hello all,
>>
>> I want to use X15 with usrp b210,b205 and 2932. My question is if I 
>> connect usb series usrp with high speed 3.0 port of X15. then Will it 
>> support the highest sampling rate on USRP?. What is the maximum I can 
>> acheive?. Even with core i7 high speed ports it gives 40 MHZ hardly and 
>> sometimes overflows and underruns. 
>>
>> Another question. What is the maximum USB 3.0, Esata, main Data Bus 
>> (through which ports and emmc is connected) and eMMC read and write speed 
>> on X15 board?. 
>>
>> I want to use it as a single board computer for my mini usrp b205. I want 
>> to buy it soon. Need suggestions urgently. Whether to buy this thing for 
>> USRP or not.
>>
>>
>>
>> Thanks,
>>
>> Hashir
>>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/5517fbbd-c8f5-4c21-9782-d81b29ee8946%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Beagleboard x15 speed

[Jeff Andich]

So then data is coming from the IQ demodulator at 40 MHz on the USB 3.0 bus 
from the b210, and  you 'd like to have it fill up a buffer via DMA, and 
then generate an interrupt for one or both C66 DSP's to demodulate, filter, 
downsample, filter some more, perform error correction coding, until you 
end up with a data stream??


On Wednesday, August 8, 2018 at 8:18:27 AM UTC-5, syed hashir wrote:
>
> I want to use it to capture IQ data. 
>
> On Tuesday, August 7, 2018 at 7:16:52 PM UTC+3, syed hashir wrote:
>>
>> Hello all,
>>
>> I want to use X15 with usrp b210,b205 and 2932. My question is if I 
>> connect usb series usrp with high speed 3.0 port of X15. then Will it 
>> support the highest sampling rate on USRP?. What is the maximum I can 
>> acheive?. Even with core i7 high speed ports it gives 40 MHZ hardly and 
>> sometimes overflows and underruns. 
>>
>> Another question. What is the maximum USB 3.0, Esata, main Data Bus 
>> (through which ports and emmc is connected) and eMMC read and write speed 
>> on X15 board?. 
>>
>> I want to use it as a single board computer for my mini usrp b205. I want 
>> to buy it soon. Need suggestions urgently. Whether to buy this thing for 
>> USRP or not.
>>
>>
>>
>> Thanks,
>>
>> Hashir
>>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/e991213f-d22e-4f28-953a-37255849d13d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Beagleboard x15 speed

[Jeff Andich]

Hi.

I wish I knew the answers off hand.  But am just starting to work through 
gnuradio, and the 
https://www.ettus.com/product/category/USRP-Bus-Series LOOKS like it may be 
a good platform for hobbying around with gnuradio, and base band/bandpass 
processing blocks!  Albeit, it's $$$.  Been hoping to work on an SDR 
project involving the X15, but that hasn't really gotten off the ground 
yet.  But am making progress towards it..

Maybe if you can provide more insight into what the highest sampling rate 
on the USRP is, what information is being exchanged  over USB 3.0, and what 
you're wanting the X15 to do with the USRP data, specifically, what portion 
of the application will run on the X15's A15 cores, C66 DSP's, PRU's, 
MPU's, etc, then that may spawn some thought on this forum.

Also, TI E2E2 maybe able to answer some of the questions as the TI 572X EVM 
is very similar to the BB-X15.

On Tuesday, August 7, 2018 at 11:16:52 AM UTC-5, syed hashir wrote:
>
> Hello all,
>
> I want to use X15 with usrp b210,b205 and 2932. My question is if I 
> connect usb series usrp with high speed 3.0 port of X15. then Will it 
> support the highest sampling rate on USRP?. What is the maximum I can 
> acheive?. Even with core i7 high speed ports it gives 40 MHZ hardly and 
> sometimes overflows and underruns. 
>
> Another question. What is the maximum USB 3.0, Esata, main Data Bus 
> (through which ports and emmc is connected) and eMMC read and write speed 
> on X15 board?. 
>
> I want to use it as a single board computer for my mini usrp b205. I want 
> to buy it soon. Need suggestions urgently. Whether to buy this thing for 
> USRP or not.
>
>
>
> Thanks,
>
> Hashir
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/430bdb04-7dc4-4d60-a077-8c1ab7006fef%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Beagleboard x15 speed

[Jeff Andich]

Hi Hashir.

I wish I knew the answers off hand.  But am just starting to work through 
gnuradio, and the 
https://www.ettus.com/product/category/USRP-Bus-Series LOOKS like it may be 
a good platform for hobbying around with gnuradio, and base band/bandpass 
processing blocks!  Albeit, it's $$$.  Been hoping to work on an SDR 
project involving the X15, but that hasn't really gotten off the ground 
yet.  But am making progress towards it..

Maybe if you can provide more insight into what the highest sampling rate 
on the USRP is, what information is being exchanged  over USB 3.0, and what 
you're wanting the X15 to do with the USRP data, specifically, what portion 
of the application will run on the X15's A15 cores, C66 DSP's, PRU's, 
MPU's, etc, then that may spawn some thought on this forum.

Also, TI E2E2 maybe able to answer some of the questions as the TI 572X EVM 
is very similar to the BB-X15.



On Tuesday, August 7, 2018 at 11:16:52 AM UTC-5, syed hashir wrote:
>
> Hello all,
>
> I want to use X15 with usrp b210,b205 and 2932. My question is if I 
> connect usb series usrp with high speed 3.0 port of X15. then Will it 
> support the highest sampling rate on USRP?. What is the maximum I can 
> acheive?. Even with core i7 high speed ports it gives 40 MHZ hardly and 
> sometimes overflows and underruns. 
>
> Another question. What is the maximum USB 3.0, Esata, main Data Bus 
> (through which ports and emmc is connected) and eMMC read and write speed 
> on X15 board?. 
>
> I want to use it as a single board computer for my mini usrp b205. I want 
> to buy it soon. Need suggestions urgently. Whether to buy this thing for 
> USRP or not.
>
>
>
> Thanks,
>
> Hashir
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/91e01430-4d6f-46bf-8ad3-2c2df358dc88%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] eMMC flasher not working after update linux kernel

[Jeff Andich]

Would it maybe be helpful to add the above step to the kernel upgrade 
sections of the following procedure pages or other pages (for specific 
kernel versions)?

https://www.digikey.com/eewiki/display/linuxonarm/BeagleBone+Black

https://www.digikey.com/eewiki/display/linuxonarm/BeagleBoard-X15

https://www.digikey.com/eewiki/display/linuxonarm/*


I THINK you said that "newer kernels" don't need this step or will no 
longer need this step, as they don't use initramfs, right?

Thanks!



On Tuesday, August 7, 2018 at 11:37:25 AM UTC-5, RobertCNelson wrote:
>
> On Tue, Aug 7, 2018 at 11:16 AM > wrote: 
> > 
> > Hi, 
> > 
> > I try to prepare my Beagle Bone black image to new hardware using this 
> gist: 
> https://gist.github.com/RobertCNelson/39faf80ddc9fcefae74dce2c6ca2eb45 . 
> I was update from Linux kernel 3.8.13-bone59 to version 3.8.13-bone86. When 
> I start from SD card linux is booting and working well. My problem is that 
> flasher to eMMC not working. Script cannot find Source and Destination 
> devices and throw kernel panic. I'm posting below logs with enabled 
> flashing on booting. 
> > U-Boot SPL 2014.07-rc4-00015-g5bcd74d (Jul 04 2014 - 16:03:33) 
> > reading u-boot.img 
> > reading u-boot.img 
> > 
> > 
> > U-Boot 2014.07-rc4-00015-g5bcd74d (Jul 04 2014 - 16:03:33), Build: 
> jenkins-github_Bootloader-Builder-345 
> > 
> > I2C:   ready 
> > DRAM:  512 MiB 
> > NAND:  0 MiB 
> > MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1 
> > *** Warning - readenv() failed, using default environment 
> > 
> > Net:not set. Validating first E-fuse MAC 
> > cpsw, usb_ether 
> > Hit any key to stop autoboot:  0 
> > gpio: pin 53 (gpio 53) value is 1 
> > switch to partitions #0, OK 
> > mmc0 is current device 
> > gpio: pin 54 (gpio 54) value is 1 
> > SD/MMC found on device 0 
> > gpio: pin 55 (gpio 55) value is 1 
> > 373 bytes read in 16 ms (22.5 KiB/s) 
> > Loaded environment from /boot/uEnv.txt 
> > Checking if uname_r is set in /boot/uEnv.txt... 
> > gpio: pin 56 (gpio 56) value is 1 
> > loading /boot/vmlinuz-3.8.13-bone86 ... 
> > 5580368 bytes read in 337 ms (15.8 MiB/s) 
> > loading /boot/dtbs/3.8.13-bone86/am335x-boneblack.dtb ... 
> > 26118 bytes read in 28 ms (910.2 KiB/s) 
> > Kernel image @ 0x8200 [ 0x00 - 0x552650 ] 
> > ## Flattened Device Tree blob at 8800 
> >Booting using the fdt blob at 0x8800 
> >Loading Device Tree to 8fff6000, end 8605 ... OK 
>
> no "initrd" 
>
> run: 
>
> sudo update-initramfs -ck `uname -r` 
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/704d49ba-182d-4287-93a7-227c401bf3e1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] What to do about Denial of Service Vulnerability for Kernel version's 4.9+ ?

[Jeff Andich]

Good to know!

Thanks!!

Jeff


On Tuesday, August 7, 2018 at 9:14:46 AM UTC-5, RobertCNelson wrote:
>
> On Tue, Aug 7, 2018 at 8:50 AM Jeff Andich  > wrote: 
> > 
> > Hello, 
> > 
> > We got an email at work about the following advisories about a denial of 
> service vulnerability in the TCP implementation in kernel versions 4.9 and 
> greater: 
> > 
> > https://www.kb.cert.org/vuls/id/962459. 
> > 
> > There's a patch, called out in the above link, and the patch comments 
> describe the issue and the current fix: 
> > 
> > 
> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/patch/?id=1a4f14bab1868b443f0dd3c55b689a478f82e72e
>  
> > 
> > If we're running kernel version 4.9 or greater on our 
> beaglebone/beagleboard products, what do you recommend we do? 
> > 
> > Should we go ahead and apply the patch to every image we download from 
> beagleboard.org with kernel 4.9 or greater if we're connecting our 
> beagles on the internet and are concerned about the attack, or has the fix 
> already be "rolled" into certain images? 
>
> Already included in: 
>
> 4.17.11 
>
>
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v4.17.11=db11182a1e38e7149804962111622b15bd9aeff2
>  
>
> 4.14.59 
>
>
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v4.14.59=f3a5ba6310e11df370f6888ed716d1486896d983
>  
>
> Our update script already pulls in: 
>
> http://repos.rcn-ee.net/latest/stretch-armhf/LATEST-ti 
>
> ABI:1 LTS414 4.14.60-ti-r67 
>
> and 
>
> http://repos.rcn-ee.net/latest/stretch-armhf/LATEST-armv7 
>
> ABI:1 LTS414 4.14.60-armv7-x5 
> ABI:1 STABLE 4.17.12-armv7-x12 
>
> http://repos.rcn-ee.net/latest/stretch-armhf/LATEST-armv7-lpae 
>
> ABI:1 LTS414 4.14.60-armv7-lpae-x3 
> ABI:1 STABLE 4.17.12-armv7-lpae-x12 
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/ec6846d4-ec1a-4d40-bb53-aca92417dcae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] What to do about Denial of Service Vulnerability for Kernel version's 4.9+ ?

[Jeff Andich]

Hello,

We got an email at work about the following advisories about a denial of 
service vulnerability in the TCP implementation in kernel versions 4.9 and 
greater:

https://www.kb.cert.org/vuls/id/962459.

There's a patch, called out in the above link, and the patch comments 
describe the issue and the current fix:

https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/patch/?id=1a4f14bab1868b443f0dd3c55b689a478f82e72e

If we're running kernel version 4.9 or greater on our 
beaglebone/beagleboard products, what do you recommend we do?

Should we go ahead and apply the patch to every image we download from 
beagleboard.org with kernel 4.9 or greater if we're connecting our beagles 
on the internet and are concerned about the attack, or has the fix already 
be "rolled" into certain images?

Thanks

Jeff



-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/18db4726-4de1-4bf8-9f88-5d0eff0382e4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Ongoing Support for OMAP Serial Driver in Future Kernel Versions

[Jeff Andich]

And following is a link to the thread showing where we're at regarding 
connecting the BB-X15 to the FT4232 Mini Module, development board:

http://beagleboard.org/discuss?place=msg%2Fbeagleboard%2FLjrZqmp8dGA%2FciOgBxRBCgAJ



On Thursday, August 2, 2018 at 9:52:08 AM UTC-5, Jeff Andich wrote:
>
> Thanks Robert!!
>
> Would really like to test the 485 mode in the 8250 driver, but before 
> that, we're going to try to get 485 mode enabled on the FTDI FT4232 
> USB<->serial hub.   We've ordered some FT4232 Mini Module evaluation boards 
> for FT4232  (FT4232H chip + EEPROM + breakout pins + mini USB port).   
>
> The biggest what if at the moment is how to write to the onboard EEPROM 
> from Linux.  The FT4232 data sheet indicates that an external EEPROM needs 
> to be attached to the FT4232H, and the RI/TXDEN flag in the EEPROM needs to 
> be re-configured from the default state to enable 485 mode for each of the 
> 4 serial channels.  Thus far,  
> https://www.acmesystems.it/CM3-HOME_ft4232_setup 
> <https://www.google.com/url?q=https%3A%2F%2Fwww.acmesystems.it%2FCM3-HOME_ft4232_setup=D=1=AFQjCNFq8W9aFeQQRvaCyp6UYr4FGyiu-g>
>  looks 
> promising, as the EEPROM tools appear to be talking to our EEPROM-less 
> FT4232H chip on our custom board. .   
>
> Plan to post up on our findings/stumbling blocks here.  If we can get this 
> working, then this MAY be of interest to those looking for a quick RS 485 
> solution.   
>
> Regards,
>
> Jeff
>
>
> On Thursday, August 2, 2018 at 8:37:26 AM UTC-5, RobertCNelson wrote:
>>
>> On Thu, Aug 2, 2018 at 8:22 AM Jeff Andich  wrote: 
>> > 
>> > Hi, 
>> > 
>> > What's the best way to find out how long a legacy driver like the 
>> omap-serial driver will be supported in the kernel going forward? 
>>
>> It's not going anywhere till they are feature matching.. 
>>
>> > 
>> > We've swapped out the 8250 driver for the OMAP serial driver via the 
>> .config file, since the omap serial driver implements a 485 mode which, 
>> thus far, appears to be functioning correctly for our application.  On the 
>> next spin of our board, we plan to realize more 485 channels using the 
>> omap-serial driver and GPIO lines. 
>> > 
>> > We're currently "baselined" on kernel 4.4.110, but if we need to 
>> upgrade to a newer kernel version at some point, this could be an issue if 
>> the OMAP-serial driver is obsoleted in a later kernel. 
>> > 
>> > As of yet, we haven't tested the RS485 mode which has been implemented 
>> in the 8250 serial driver in kernel 4.6 and later, but if there are known 
>> plans for dropping support for the omap-serial driver, then we will 
>> definitely test the  8250/RS485 implementation. 
>> > 
>> > Thus far have looked at the following, and didn't SEE any plans for 
>> obsolescence: 
>> > 
>> > 
>> https://github.com/torvalds/linux/commits/master/drivers/tty/serial/omap-serial.c
>>  
>> > 
>> > Also, comments like the following lead me to believe that the 
>> omap-serial driver will be around as long as the omap platform 
>> > is still supported.  It SOUNDS almost like the 8250 driver is generic 
>> for other platforms (e.g. other than OMAP) which 
>> > don't support DMA. 
>> > 
>> > 
>> > * Note: This driver is made separate from 8250 driver as we cannot 
>> > * over load 8250 driver with omap platform specific configuration for 
>> > * features like DMA, it makes easier to implement features like DMA and 
>> > * hardware flow control and software flow control configuration with 
>> > * this driver as required for the omap-platform 
>>
>> Yeah, that "was" pretty much the state of the 8250 driver circa 2.6.32 
>>
>> 485 mode is really the only thing the omap driver does better at this 
>> point in today's kernel.. 
>>
>> Regards, 
>>
>> -- 
>> Robert Nelson 
>> https://rcn-ee.com/ 
>>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/522b7675-44ac-4e93-8257-7a303400da58%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Ongoing Support for OMAP Serial Driver in Future Kernel Versions

[Jeff Andich]

Thanks Robert!!

Would really like to test the 485 mode in the 8250 driver, but before that, 
we're going to try to get 485 mode enabled on the FTDI FT4232 USB<->serial 
hub.   We've ordered some FT4232 Mini Module evaluation boards for FT4232  
(FT4232H chip + EEPROM + breakout pins + mini USB port).   

The biggest what if at the moment is how to write to the onboard EEPROM 
from Linux.  The FT4232 data sheet indicates that an external EEPROM needs 
to be attached to the FT4232H, and the RI/TXDEN flag in the EEPROM needs to 
be re-configured from the default state to enable 485 mode for each of the 
4 serial channels.  Thus far,  
https://www.acmesystems.it/CM3-HOME_ft4232_setup 
<https://www.google.com/url?q=https%3A%2F%2Fwww.acmesystems.it%2FCM3-HOME_ft4232_setup=D=1=AFQjCNFq8W9aFeQQRvaCyp6UYr4FGyiu-g>
 looks 
promising, as the EEPROM tools appear to be talking to our EEPROM-less 
FT4232H chip on our custom board. .   

Plan to post up on our findings/stumbling blocks here.  If we can get this 
working, then this MAY be of interest to those looking for a quick RS 485 
solution.   

Regards,

Jeff


On Thursday, August 2, 2018 at 8:37:26 AM UTC-5, RobertCNelson wrote:
>
> On Thu, Aug 2, 2018 at 8:22 AM Jeff Andich  > wrote: 
> > 
> > Hi, 
> > 
> > What's the best way to find out how long a legacy driver like the 
> omap-serial driver will be supported in the kernel going forward? 
>
> It's not going anywhere till they are feature matching.. 
>
> > 
> > We've swapped out the 8250 driver for the OMAP serial driver via the 
> .config file, since the omap serial driver implements a 485 mode which, 
> thus far, appears to be functioning correctly for our application.  On the 
> next spin of our board, we plan to realize more 485 channels using the 
> omap-serial driver and GPIO lines. 
> > 
> > We're currently "baselined" on kernel 4.4.110, but if we need to upgrade 
> to a newer kernel version at some point, this could be an issue if the 
> OMAP-serial driver is obsoleted in a later kernel. 
> > 
> > As of yet, we haven't tested the RS485 mode which has been implemented 
> in the 8250 serial driver in kernel 4.6 and later, but if there are known 
> plans for dropping support for the omap-serial driver, then we will 
> definitely test the  8250/RS485 implementation. 
> > 
> > Thus far have looked at the following, and didn't SEE any plans for 
> obsolescence: 
> > 
> > 
> https://github.com/torvalds/linux/commits/master/drivers/tty/serial/omap-serial.c
>  
> > 
> > Also, comments like the following lead me to believe that the 
> omap-serial driver will be around as long as the omap platform 
> > is still supported.  It SOUNDS almost like the 8250 driver is generic 
> for other platforms (e.g. other than OMAP) which 
> > don't support DMA. 
> > 
> > 
> > * Note: This driver is made separate from 8250 driver as we cannot 
> > * over load 8250 driver with omap platform specific configuration for 
> > * features like DMA, it makes easier to implement features like DMA and 
> > * hardware flow control and software flow control configuration with 
> > * this driver as required for the omap-platform 
>
> Yeah, that "was" pretty much the state of the 8250 driver circa 2.6.32 
>
> 485 mode is really the only thing the omap driver does better at this 
> point in today's kernel.. 
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/0f603514-231c-4a17-a2cb-210a8ad351f8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Ongoing Support for OMAP Serial Driver in Future Kernel Versions

[Jeff Andich]

Thanks Robert!!

Would really like to test the 485 mode in the 8250 driver, but before that, 
we're going to try to get 485 mode enabled on the FTDI FT4232 USB<->serial 
hub.   We've ordered some FT4232 Mini Module evaluation boards for FT4232  
(FT4232H chip + EEPROM + breakout pins + mini USB port).   The biggest what 
if at the moment is how to write to the onboard EEPROM from Linux.  Thus 
far,  https://www.acmesystems.it/CM3-HOME_ft4232_setup looks promising, as 
the EEPROM tools appear to be talking to our EEPROM-less FT4232H chip on 
our custom board. .   

Plan to post up on our findings/stumbling blocks here.  If we can get this 
working, then this MAY be of interest to those looking for a quick RS 485 
solution.   

Regards,

Jeff


On Thursday, August 2, 2018 at 8:37:26 AM UTC-5, RobertCNelson wrote:
>
> On Thu, Aug 2, 2018 at 8:22 AM Jeff Andich  > wrote: 
> > 
> > Hi, 
> > 
> > What's the best way to find out how long a legacy driver like the 
> omap-serial driver will be supported in the kernel going forward? 
>
> It's not going anywhere till they are feature matching.. 
>
> > 
> > We've swapped out the 8250 driver for the OMAP serial driver via the 
> .config file, since the omap serial driver implements a 485 mode which, 
> thus far, appears to be functioning correctly for our application.  On the 
> next spin of our board, we plan to realize more 485 channels using the 
> omap-serial driver and GPIO lines. 
> > 
> > We're currently "baselined" on kernel 4.4.110, but if we need to upgrade 
> to a newer kernel version at some point, this could be an issue if the 
> OMAP-serial driver is obsoleted in a later kernel. 
> > 
> > As of yet, we haven't tested the RS485 mode which has been implemented 
> in the 8250 serial driver in kernel 4.6 and later, but if there are known 
> plans for dropping support for the omap-serial driver, then we will 
> definitely test the  8250/RS485 implementation. 
> > 
> > Thus far have looked at the following, and didn't SEE any plans for 
> obsolescence: 
> > 
> > 
> https://github.com/torvalds/linux/commits/master/drivers/tty/serial/omap-serial.c
>  
> > 
> > Also, comments like the following lead me to believe that the 
> omap-serial driver will be around as long as the omap platform 
> > is still supported.  It SOUNDS almost like the 8250 driver is generic 
> for other platforms (e.g. other than OMAP) which 
> > don't support DMA. 
> > 
> > 
> > * Note: This driver is made separate from 8250 driver as we cannot 
> > * over load 8250 driver with omap platform specific configuration for 
> > * features like DMA, it makes easier to implement features like DMA and 
> > * hardware flow control and software flow control configuration with 
> > * this driver as required for the omap-platform 
>
> Yeah, that "was" pretty much the state of the 8250 driver circa 2.6.32 
>
> 485 mode is really the only thing the omap driver does better at this 
> point in today's kernel.. 
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/e0a04cdd-4745-4a23-9ad8-9442df864a1a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Ongoing Support for OMAP Serial Driver in Future Kernel Versions

[Jeff Andich]

Hi,

What's the best way to find out how long a legacy driver like the 
omap-serial driver will be supported in the kernel going forward?

We've swapped out the 8250 driver for the OMAP serial driver via the 
.config file, since the omap serial driver implements a 485 mode which, 
thus far, appears to be functioning correctly for our application.  On the 
next spin of our board, we plan to realize more 485 channels using the 
omap-serial driver and GPIO lines.

We're currently "baselined" on kernel 4.4.110, but if we need to upgrade to 
a newer kernel version at some point, this could be an issue if the 
OMAP-serial driver is obsoleted in a later kernel. 

As of yet, we haven't tested the RS485 mode which has been implemented in 
the 8250 serial driver in kernel 4.6 and later, but if there are known 
plans for dropping support for the omap-serial driver, then we will 
definitely test the  8250/RS485 implementation.

Thus far have looked at the following, and didn't SEE any plans for 
obsolescence:

https://github.com/torvalds/linux/commits/master/drivers/tty/serial/omap-serial.c

Also, comments like the following lead me to believe that the omap-serial 
driver will be around as long as the omap platform 
is still supported.  It SOUNDS almost like the 8250 driver is generic for 
other platforms (e.g. other than OMAP) which 
don't support DMA.
 

* Note: This driver is made separate from 8250 driver as we cannot
* over load 8250 driver with omap platform specific configuration for
* features like DMA, it makes easier to implement features like DMA and
* hardware flow control and software flow control configuration with
* this driver as required for the omap-platform


Any insight here would be greatly appreciated..

Thanks!

Jeff

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/5e1d1509-3c73-4e8d-859b-d61a77c103ef%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] BeagleBone Black won't boot from SD card

[Jeff Andich]

Is your SD card correctly programmed with the image?

Is there an issue with your SD card?  Do you have another one to try?

Did you grab the right image file for the right product?

Are you able to stick that SD card containing the beaglebone image into a Linux 
PC via say a USB<->SD card adaptor, and do you see the expected files on it 
under the filesystem?

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/597c116e-dee0-4f2c-803b-9e4d933d303f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB: Using DMA with SPI

[Jeff Andich]

Would you please add a note in the following location (and/or other 
applicable pages) about running init-ramfs when updating the kernel?   And 
maybe even a blurb about why this is needed?

https://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-SetupmicroSDcard
 


Thanks!!



On Wednesday, May 16, 2018 at 5:12:40 PM UTC-5, Jeff Andich wrote:
>
> I ran into a similar issue when I upgraded my kernel on an existing BB-X15 
> image and then attempted to run the flasher script from the SD card on a 
> BB-X15:
>
>
> http://beagleboard.org/discuss?place=msg%2Fbeagleboard%2Fx1mxG7c-ilg%2F2Q8OROMCAwAJ
>
> Where Robert indicated to do:
>
> (1) depmod -a
>
> (2)  sudo update-initramfs -ck `uname -r`  (or update-initramfs -uk 'uname 
> -r')
>
>
> Not sure if updating the module dependency db is needed, but something to 
> consider..
>
>
>
> On Wednesday, May 16, 2018 at 4:05:31 PM UTC-5, RobertCNelson wrote:
>>
>> On Wed, May 16, 2018 at 3:56 PM, John B <john...@gmail.com> wrote: 
>> > I found that the eMMC flasher 
>> > (/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh) no longer appears to 
>> work 
>> > after I upgraded to Kernel 4.14.x.  I traced this to 
>> > /opt/scripts/tools/eMMC/functions.sh in prepare_environment().  It 
>> seems 
>> > that /proc and /sys are not mounted when the flasher script is executed 
>> from 
>> > init.  Needless to say, this caused agita for the rest of the script. 
>>  I'm 
>> > not sure if this has been addressed someplace else (maybe it has to do 
>> with 
>> > the fact I am using initrd.img-4.9.82-ti-r102? I doubt it though.) 
>> > 
>> > In any event, in case someone is running into the same issue, I have 
>> > attached my updated functions.sh which addresses the issue by mounting 
>> /proc 
>> > and /sys just after the script does /tmp.  This seems to work fine; it 
>> > should even work on a system where /proc and /sys are already mounted. 
>>
>>
>> before you run that script, just make sure you run: 
>>
>> sudo update-initramfs -ck `uname -r` 
>>
>> Regards, 
>>
>> -- 
>> Robert Nelson 
>> https://rcn-ee.com/ 
>>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/af4561d7-f278-40da-a3bd-afdea6044f94%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB: Using DMA with SPI

[Jeff Andich]

I ran into a similar issue when I upgraded my kernel on an existing BB-X15 
image and then attempted to run the flasher script from the SD card on a 
BB-X15:

http://beagleboard.org/discuss?place=msg%2Fbeagleboard%2Fx1mxG7c-ilg%2F2Q8OROMCAwAJ

Where Robert indicated to do:

(1) depmod -a

(2)  sudo update-initramfs -ck `uname -r`  (or update-initramfs -uk 'uname 
-r')


Not sure if updating the module dependency db is needed, but something to 
consider..



On Wednesday, May 16, 2018 at 4:05:31 PM UTC-5, RobertCNelson wrote:
>
> On Wed, May 16, 2018 at 3:56 PM, John B  
> wrote: 
> > I found that the eMMC flasher 
> > (/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh) no longer appears to 
> work 
> > after I upgraded to Kernel 4.14.x.  I traced this to 
> > /opt/scripts/tools/eMMC/functions.sh in prepare_environment().  It seems 
> > that /proc and /sys are not mounted when the flasher script is executed 
> from 
> > init.  Needless to say, this caused agita for the rest of the script. 
>  I'm 
> > not sure if this has been addressed someplace else (maybe it has to do 
> with 
> > the fact I am using initrd.img-4.9.82-ti-r102? I doubt it though.) 
> > 
> > In any event, in case someone is running into the same issue, I have 
> > attached my updated functions.sh which addresses the issue by mounting 
> /proc 
> > and /sys just after the script does /tmp.  This seems to work fine; it 
> > should even work on a system where /proc and /sys are already mounted. 
>
>
> before you run that script, just make sure you run: 
>
> sudo update-initramfs -ck `uname -r` 
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/3a76824b-02bb-46a6-bad7-eb41a4fb482d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Are console images not available from beagleboard.org?

[Jeff Andich]

I think we've wrestled with this issue as well.  We're still working with 
Jessie console images from 
https://rcn-ee.com/rootfs/bb.org/testing/2018-02-01/console/, and they seem 
to be pretty stable, from the testing we've done to date.  

I'm not yet sure and am still very curious about the test results/testing 
status of the images which are placed in the testing folder. I THINK what 
you need to do is look at the github revision/commit history for each 
component (e.g. uboot, debian, and kernel version) in a given image) to see 
why an image was updated (e.g. 2018-01-01 to 2018-02-10, but if there's a 
place which posts what the test results are (and a place for users to post 
their own experiences) for a given image, other than github, please let us 
know!!


Question(s):

For a given LXQT image, how much effort is involved in converting that 
"GUI" image to a console image?  Can't you just remove all of the "extra 
packages" from the LXQT image until you have the desired console image per 
the following procedure, or is it more involved than that?  Aren't the 
pinmuxes the same?


1) Spit out the debian package list for  an existing console image (even 
the weekly image).
2) Spit out the debian package list for the released LXQT image (from the 
same desired major Debian revision as #1 (e.g. jessie, stretch)
3) Compare the package lists from 1,2.
4) Use apt remove on the released LXQT image to remove the "excess" 
packages in the LXQT image until it's package list matches the package list 
of the console image?


Thanks!!

Jeff

On Monday, May 14, 2018 at 3:33:32 AM UTC-5, Chris Green wrote:
>
> Graham  wrote: 
> > [-- multipart/alternative, encoding 7bit, 176 lines --] 
> > 
> > [-- text/plain, encoding quoted-printable, charset: UTF-8, 73 lines 
> --] 
> > 
> > If what you want is the console version corresponding to 
> >Debian 9.3 2018-01-28 4GB SD LXQT image 
> > 
> > And you go to 
> > 
> https://debian.beagleboard.org/images/rcn-ee.net/rootfs/bb.org/testing/2018-01-28/stretch-console/
>  
> > 
> > it sure looks like Debian 9.3 to me. 
> > 
> > The one you want is: 
> > bone-debian-9.3-console-armhf-2018-01-28-1gb.img.xz 
> > 
> > Now this one is for running from the uSD card. 
> > If you want to turn it into a "flasher" you need to follow the 
> instructions 
> > about editing the correct uEnv.txt file 
> > 
> Yes, OK, that's a 9.3 console image but it's still only a weekly 
> 'snapshot'. 
>
> I'm not personally desperately after an old[er] console image, I'm 
> just saying that there isn't a 'recommended' default console image 
> like there is for the IOT and full GUI images. 
>
> -- 
> Chris Green 
> · 
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/b4eda095-ce02-4c0f-943c-8736b2e1e25d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Are console images not available from beagleboard.org?

[Jeff Andich]

Does this page contain what you need?

https://elinux.org/Beagleboard:BeagleBoneBlack_Debian

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/02cdf35a-3d23-498f-8fb5-47faaae24799%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] RS485 RTS Line Toggling Available in FTDI USB<->Serial Hub Chips - Has Anyone Tried This?

[Jeff Andich]

Hi,

Our custom board based on the BB-X15 has a(n) FT4232 USB<->serial hub to 
realize some of our serial ports.  From the data sheet and programming 
guide, it looks like the chip supports RS485 toggling of a DE pin on a 485 
chip via the chip's TXDEN line.  But the data sheet and programming guide 
suggest that the FTDI chip's EEPROM needs to be programmed with the 
appropriate flags enabled to enable auto-toggling of TXDEN around transmit 
and receive.  

I briefly looked throughKERNEL (uname-r = 
4.4.110-ti-r142)/drivers/usb/serial/ftdi_* to see if there's already an 
interface in the driver for initializing/re-initializing the FTDI chip's 
EEPROM to enable 485 mode.  I did see references to 485 for other devices, 
but I haven't yet found anything obvious about enabling TXDEN specifically 
for this family of chips...

Has anyone tried utilizing an FTDI USB<->serial hub for RS485 and is 
familiar with enabling the TXDEN line for this purpose in Linux?  If so, 
any insight would be greatly appreciated!!  Also are there any limitations 
in the driver or the chip that you're aware of?

Thanks!

Jeff

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/e0a9e0ec-3c06-4ca9-910c-3b32f29e73ed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: RS485 support for BBB

[Jeff Andich]

Note: For our custom hardware board based on the BB-X15, we ran into a 
potential timing issue with a C# application running in mon-runtime  
handling toggling of the RTS line around sending and receiving packets, so 
we re-tried getting the OMAP serial driver to auto-toggle the RTS line.

We're running kernel 4.4.110-ti-r142. 

Initially the results look  promising when we transmit 10 characters at 
9600 baud on the Oscilloscope, displaying 485_'+', 485_'-' and the signal 
for RTS. But I HOPE to post up more detailed results under BB-X15 once we 
get further along.

The one caveat is , from looking at the OMAP serial driver code, it LOOKS 
like you have to use a GPIO line for RS485 mode for the driver to 
automatically toggle the RTS line around transmitting a character out the 
respective serial port.  It doesn't LOOK like the version of the driver for 
the above uname -r supports auto toggling of UARTn_RTSn lines.  Wonder if 
this is due to the nature of RTS/CTS vs RS485??

Thus far, I've only been able to get the GPIO case to work. The neat thing 
is about the TI PINMUX, it appears like many of the pads on the Sitara 5728 
that have 'UART' in the name for MUXMODE0, the RTS line can easily be 
swapped out for a GPIO pin.  But in our case, only 2 of our UARTs have 
this, and the rest have higher MUXMODES so the GPIO cannot be swapped out 
for RTS.  We may need to look further into this and MAY wish to hack the 
OMAP 

When I get further along with my testing, I HOPE to generate a new post 
under the BB-X15 which re-packages everything I did to get these results 
(including what options were configured in the kernel '.config' file and 
upload some scope shots that show transmit and receive on a 2-wire RS485 
'bus.'

Here are some excerpts from our device tree for UART1:




uart1_pins: pinmux_uart1_pins {
pinctrl-single,pins = <
DRA7XX_CORE_IOPAD(0x37E0, (PIN_INPUT| 
SLEWCONTROL| MUX_MODE0)) /* uart1_rxd.uart1_rxd */
DRA7XX_CORE_IOPAD(0x37E4, (PIN_OUTPUT   | 
SLEWCONTROL| MUX_MODE0))   /* uart1_txd.uart1_txd */
DRA7XX_CORE_IOPAD(0x37E8, (PIN_INPUT_PULLDOWN   | 
MUX_MODE14)) */ /* uart1_ctsn.gpio7_24 */
DRA7XX_CORE_IOPAD(0x37EC, (PIN_OUTPUT   | 
MUX_MODE14))  /* uart1_rtsn.gpio7_25 */
>;
};


.
.
.
 {
pinctrl-names = "default";
pinctrl-0 = <_pins>;
status = "okay";
rts-gpio = < 25 GPIO_ACTIVE_HIGH>;
rs485-rts-active-high;
rs485-rts-delay = <0 0>;
linux,rs485-enabled-at-boot-time;
};


Note 1: The driver appears to support the 2 configurable RTS delays with 
down to 1ms resolution.  For MODBUS timing, requiring 3.5 character time 
delay in the protocol between transmitting parties, the 1ms resolution 
won't be granular enough at all baudrates.  Going to try setting these 
delays to 0,0 

Note: Temporarily experimenting with changing the pinmux in the device tree 
as opposed to u-boot-spl, and am aware of the glitch errata.  When we're 
done testing, we'll update our pad configuration arrays in u-boot to keep 
the 5728 pinmux glitch monster at bay...



On Tuesday, March 6, 2018 at 10:42:37 AM UTC-6, Jeff Andich wrote:
>
> Hi there.  Got your PM..
>
> Regarding the defconfig changes to enable the OMAP.
>
> I THINK your prescribed changes to the defconfig file are correct, just 
> please refer to the above thread, 
> https://groups.google.com/forum/#!topic/beagleboard/JGIm0Ej6jDI.
>
> You're going to need to tune the defconfig, and the re-build and deploy 
> the kernel until you see /dev/ttyO*.  And then you'll need to check that 
> the serial device of interest is enabled.  You can go into 
> /sys/class/tty/ttyO* directory and start looking at things like irq #'s to 
> make sure they're non-0.  Not sure how this changes if DMA is enabled.
>  
> One interesting thing.  If you want to enable UARTs (beyond #6), I found 
> that with the OMAP driver, all you need to do is enable it in the device 
> tree fragement.  But with the 8250 driver, you need to change another 
> defconfig define to increase the total # of UARTs..
>
> Regarding updating/building the kernel on the BBB (?? 
> /opt/scripts/tools/update_kernel.sh??), I'm afraid I still haven't done 
> this or used Robert's image Builder on target.  I hope to get some practice 
> with that next-week.  Then I can hopefully speak more intelligently on that.
>
> To build/re-build the kernel, I follow the instructions on how to fetch 
> and build the kernel, here, 
> https://eewiki.net/display/linuxonarm/BeagleBoard-X15.
>
> And then, inintially I call root_kernel_build_dir/build_kernel.sh, 
> allow makemenuconfig to run.
> Set the defconfig options I need.
> Then every subsequent build, I t

[beagleboard] Re: beagleboard-x15 cape fpga microcontroller adc dac sdram

[Jeff Andich]

Hi,

One of my pet projects which isn’t off the ground yet is SDR with the
B.B.-X15.  My progress will
be to slow to warrant getting one of the SDR capes for free, but I hope the
free cape goes to a student, researcher, or hobbiest who will help show how
all of the processors on the X15 can utilized to implement baseband (and
maybe bandpass) processing for the SDR.  There are really a lot of neat
experiments one could do.  It would also be cool if they could show design
trade offs since there are so many options on the X-15.  I hope that the
SDR project will help demonstrate what kinds of applications the X-15 can
be utilized for..  I believe this board (or the TI57xx EVM/IDK) is being
used in industry, but I don’t THINK there’s a good window yet into
applications being developed on this SoC. Please correct me if I’m wrong.

I greatly look forward to when your cape goes on sale and when the
benificiary of this cape starts posting up info about his/her example
application!

Thanks!!

Jeff


On Sun, Apr 22, 2018 at 5:54 PM 何海宇MHE  wrote:

>
> Hi,
>
>I would like to offer my sponsorship of a software defined radio
> board to student engineer or researcher to work on any open source project
> that will involve emt he the community. My hardware will be the BeagleSDR
> add-on board as best current cape for the Beagleboard-x15. It has a FPGA,
> AVR microcontroller, and high speed ADC/DAC, i2c programmable clock... This
> open source project probably last at least one month or more as your hobby,
> and as the mine too because I'll provide some technical support to you.
> We'll review all together. It will definitely depends on your speed on work
> and your final interest. It would suit a student, researcher, hobbyist,
> technology idealist, with as much as possible spare time. If you are
> familiar with FPGA, Microcontroller, Linux, Gnuradio, C/C++/Python, DSP
> optimization programming, if you have strong embedded linux experience, and
> you have the conviction to make an open source project for people and
> ideally have a goal in Global Navigation Satellite Systems, or Outer Space
> Wave, Astrophysics, Wireless control, Radio, or doing research like in data
> processing, have an antenna, a telescope, a microscope, would like to see
> interaction of waveform... Please apply with your short bio, CV, your
> postal address and relevant experience. I will send a free sample of
> BeagleSDR to your office or home. Thanks for your trust !
>
>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "beagleboard-x15" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard-x15/B3D5qa0PNTM/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard-x15+unsubscr...@googlegroups.com.
> To post to this group, send email to beagleboard-...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard-x15/61916e33-b3ef-43f0-8443-0d0ead6aa0d4%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALJg6gRnfv_LuyXR3agraiMkzDuVN0m-pSFqi8ksT0npWqdbQA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Stretch Image, debian-9.3-lxqt, for BeagleBoard-X15 Doesn't Boot Normally - Boots into initramfs

[Jeff Andich]

Thanks John!!

Will pass along this suggestion to my management and that its potentially 
worth tracking SD card reliability by make, model, size, etc in the event 
that we're not able to stick to SanDisk..

Rgds,

jeff



On Wednesday, April 18, 2018 at 3:22:55 PM UTC-5, john3909 wrote:
>
> I’ve gone through my fair share of bad SDCards (Pariot, Kingston, etc), so 
> I know what you are going through. I decided a few years ago to stay with 
> one make that always seems to work and that is SanDisk Ultra and SanDisk 
> Extreme. Since then, I haven’t had any more SDCard issues. 
>
> Regards,
> John
>
>
>
>
>
> On Apr 18, 2018, at 6:56 AM, Jeff Andich <jeff@gmail.com > 
> wrote:
>
> Ok John,
>
> In the case of the 32 GB Kingston #10 card I tried yesterday, I think it's 
> the card, as I get the same result today ([3.896022] mmc0: error -110 
> whilst initialising SD card ).  However, when I tried a different 32 GB 
> Kingston uSD of the same type, it boots (see boot log below).  I'm not sure 
> why subsequently trying it on the 16 GB Kingston uSD card yesterday yielded 
> the same mmc error..
>
> Anyhow, I'm sorry.  I  should have tried flashing multiple cards and 
> configurations before posting this error... As indicated before, Robert 
> gave me a Beagleboard-X15 image to try on the TI 5718 IDK a while back, and 
> we kept getting MMC errors on SD cards larger than 4GB.  But Robert 
> mentioned at the 2018 ELC what the issue was there, but I don't recall what 
> it was..
>
> If I see any other issues, I'll first try to perform more sanity checks 
> and then post up..
>
> Thanks!
>
> jeff
>
>
> Following is the successful boot log of this image.
>
> U-Boot 2017.01-00360-gc604741cb3 (Aug 11 2017 - 15:47:09 -0500), Build: 
> jenkins-github_Bootl2
>
> CPU  : DRA752-GP ES2.0
> Model: TI AM5728 BeagleBoard-X15
> Board: AM572x EVM REV A.3A
> DRAM:  2 GiB
> MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
>
> ** Unable to use mmc 0:1 for loading the env **
> Using default environment
>
> setup_board_eeprom_env: am57xx_evm_reva3
> SCSI:  SATA link 0 timeout.
> AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
> flags: 64bit ncq stag pm led clo only pmp pio slum part ccc apst 
> scanning bus for devices...
> Found 0 device(s).
> Net:not set. Validating first E-fuse MAC
> cpsw
> Press SPACE to abort autoboot in 2 seconds
> usb_boot is currently disabled
> scsi_boot is currently disabled
> switch to partitions #0, OK
> mmc0 is current device
> Scanning mmc device 0
> Checking for: /uEnv.txt ...
> Checking for: /boot/uEnv.txt ...
> 445 bytes read in 24 ms (17.6 KiB/s)
> Loaded environment from /boot/uEnv.txt
> Checking if uname_r is set in /boot/uEnv.txt ...
> debug: [uname_r=4.9.78-ti-r94] ...
> loading /boot/vmlinuz-4.9.78-ti-r94 ...
> 9960536 bytes read in 454 ms (20.9 MiB/s)
> loading /boot/dtbs/4.9.78-ti-r94/am57xx-evm-reva3.dtb ...
> 155403 bytes read in 100 ms (1.5 MiB/s)
> loading /boot/initrd.img-4.9.78-ti-r94 ...
> 6300596 bytes read in 291 ms (20.6 MiB/s)
> debug: [console=ttyO2,115200n8 root=/dev/mmcblk0p1 ro rootfstype=ext4 
> rootwait coherent_pool.
> debug: [bootz 0x8200 0x8808:6023b4 0x8800] ...
> ## Flattened Device Tree blob at 8800
>Booting using the fdt blob at 0x8800
>Loading Ramdisk to 8f9fd000, end 83b4 ... OK
>Loading Device Tree to 8f9d4000, end 8f9fcf0a ... OK
>
> Starting kernel ...
>
> [0.072556] /cpus/cpu@0 missing clock-frequency property
> [0.072580] /cpus/cpu@1 missing clock-frequency property
> [2.430461] dra7-pcie 5100.pcie: phy link never came up
> [2.705777] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr25 mode
> [2.721471] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr12 mode
> [2.835224] omap_voltage_late_init: Voltage driver support not added
> [FAILED] Failed to start TI MultiCore Tools Daemon.
> See 'systemctl status ti-mct-daemon.service' for details.
> [  OK  ] Started Connection service.
> [  OK  ] Reached target Network.
>  Starting Permit User Sessions...
> [  OK  ] Reached target Network is Online.
>  Starting LSB: Advanced IEEE 802.11 management daemon...
>  Starting The Apache HTTP Server...
>  Starting OpenBSD Secure Shell server...
> [  OK  ] Started LSB: Start daemon at boot time.
> [  OK  ] Started Permit User Sessions.
> [  OK  ] Started LSB: Advanced IEEE 802.11 management daemon.
>  Starting Light Display Manager...
> [  OK  ] Started Getty on tty1.
> [  OK  ] Started LSB: Load kernel modules needed to enable cpufreq scaling.
>  Starting LSB: set CPUFreq kernel parameters...
> [  OK  ] Started Gene

Re: [beagleboard] Re: Stretch Image, debian-9.3-lxqt, for BeagleBoard-X15 Doesn't Boot Normally - Boots into initramfs

[Jeff Andich]

Also, it's probably worth noting that Etcher 1.3.1 successfully verified 
the image on the SD card which produced the above error. 



On Wednesday, April 18, 2018 at 8:56:34 AM UTC-5, Jeff Andich wrote:
>
> Ok John,
>
> In the case of the 32 GB Kingston #10 card I tried yesterday, I think it's 
> the card, as I get the same result today ([3.896022] mmc0: error -110 
> whilst initialising SD card ).  However, when I tried a different 32 GB 
> Kingston uSD of the same type, it boots (see boot log below).  I'm not sure 
> why subsequently trying it on the 16 GB Kingston uSD card yesterday yielded 
> the same mmc error..
>
> Anyhow, I'm sorry.  I  should have tried flashing multiple cards and 
> configurations before posting this error... As indicated before, Robert 
> gave me a Beagleboard-X15 image to try on the TI 5718 IDK a while back, and 
> we kept getting MMC errors on SD cards larger than 4GB.  But Robert 
> mentioned at the 2018 ELC what the issue was there, but I don't recall what 
> it was..
>
> If I see any other issues, I'll first try to perform more sanity checks 
> and then post up..
>
> Thanks!
>
> jeff
>
>
> Following is the successful boot log of this image.
>
> U-Boot 2017.01-00360-gc604741cb3 (Aug 11 2017 - 15:47:09 -0500), Build: 
> jenkins-github_Bootl2
>
> CPU  : DRA752-GP ES2.0
> Model: TI AM5728 BeagleBoard-X15
> Board: AM572x EVM REV A.3A
> DRAM:  2 GiB
> MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
>
> ** Unable to use mmc 0:1 for loading the env **
> Using default environment
>
> setup_board_eeprom_env: am57xx_evm_reva3
> SCSI:  SATA link 0 timeout.
> AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
> flags: 64bit ncq stag pm led clo only pmp pio slum part ccc apst 
> scanning bus for devices...
> Found 0 device(s).
> Net:not set. Validating first E-fuse MAC
> cpsw
> Press SPACE to abort autoboot in 2 seconds
> usb_boot is currently disabled
> scsi_boot is currently disabled
> switch to partitions #0, OK
> mmc0 is current device
> Scanning mmc device 0
> Checking for: /uEnv.txt ...
> Checking for: /boot/uEnv.txt ...
> 445 bytes read in 24 ms (17.6 KiB/s)
> Loaded environment from /boot/uEnv.txt
> Checking if uname_r is set in /boot/uEnv.txt ...
> debug: [uname_r=4.9.78-ti-r94] ...
> loading /boot/vmlinuz-4.9.78-ti-r94 ...
> 9960536 bytes read in 454 ms (20.9 MiB/s)
> loading /boot/dtbs/4.9.78-ti-r94/am57xx-evm-reva3.dtb ...
> 155403 bytes read in 100 ms (1.5 MiB/s)
> loading /boot/initrd.img-4.9.78-ti-r94 ...
> 6300596 bytes read in 291 ms (20.6 MiB/s)
> debug: [console=ttyO2,115200n8 root=/dev/mmcblk0p1 ro rootfstype=ext4 
> rootwait coherent_pool.
> debug: [bootz 0x8200 0x8808:6023b4 0x8800] ...
> ## Flattened Device Tree blob at 8800
>Booting using the fdt blob at 0x8800
>Loading Ramdisk to 8f9fd000, end 83b4 ... OK
>Loading Device Tree to 8f9d4000, end 8f9fcf0a ... OK
>
> Starting kernel ...
>
> [0.072556] /cpus/cpu@0 missing clock-frequency property
> [0.072580] /cpus/cpu@1 missing clock-frequency property
> [2.430461] dra7-pcie 5100.pcie: phy link never came up
> [2.705777] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr25 mode
> [2.721471] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr12 mode
> [2.835224] omap_voltage_late_init: Voltage driver support not added
> [FAILED] Failed to start TI MultiCore Tools Daemon.
> See 'systemctl status ti-mct-daemon.service' for details.
> [  OK  ] Started Connection service.
> [  OK  ] Reached target Network.
>  Starting Permit User Sessions...
> [  OK  ] Reached target Network is Online.
>  Starting LSB: Advanced IEEE 802.11 management daemon...
>  Starting The Apache HTTP Server...
>  Starting OpenBSD Secure Shell server...
> [  OK  ] Started LSB: Start daemon at boot time.
> [  OK  ] Started Permit User Sessions.
> [  OK  ] Started LSB: Advanced IEEE 802.11 management daemon.
>  Starting Light Display Manager...
> [  OK  ] Started Getty on tty1.
> [  OK  ] Started LSB: Load kernel modules needed to enable cpufreq scaling.
>  Starting LSB: set CPUFreq kernel parameters...
> [  OK  ] Started Generic Board Startup.
>  Starting Hostname Service...
>  Starting WPA supplicant...
> [  OK  ] Started LSB: set CPUFreq kernel parameters.
> [7.212091] remoteproc remoteproc0: request_firmware failed: -2
> [  OK  ] Started OpenBSD Secure Shell server.
> [  OK  ] Found device /dev/ttyS2.
> [  OK  ] Started Serial Getty on ttyS2.
> [  OK  ] Reached target Login Prompts.
>  Starting BB WL18xx Bluetooth Service...
> [  OK  ] Started WPA supplicant.
> [  OK  ] Started BB WL18xx B

Re: [beagleboard] Re: Stretch Image, debian-9.3-lxqt, for BeagleBoard-X15 Doesn't Boot Normally - Boots into initramfs

[Jeff Andich]

BeagleBoard.org Debian Image 2018-01-28
debian@BeagleBoard-X15:~$ cat /etc/debian_version 
9.3
debian@BeagleBoard-X15:~$ uname -r
4.9.78-ti-r94


On Tuesday, April 17, 2018 at 8:12:32 PM UTC-5, john3909 wrote:
>
> I use San Disk Ultra 32GB in my X15 and it works fine.
>
> Regards,
> John
>
>
>
>
>
> On Apr 17, 2018, at 5:59 PM, Jeff Andich <jeff@gmail.com > 
> wrote:
>
> Hi,
>
> First run:  32GB
> Second:   16GB
> Third: 4GB
>
> Will redo the first run but with a different 32 GB SD as Etcher hung 
> during verifying that card (but subsequently Win32DiskImager didn’t 
> complain)..  That card maybe bad.  However, the same result occurred on the 
> 16 GB card...
>
> Thanks!
>
> -- 
> For more options, visit http://beagleboard.org/discuss
> --- 
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/37465c0f-a787-4490-b3c3-8531d3b7ee7d%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/9acd3ee3-a7ef-42ed-8433-9d27ec125a13%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Stretch Image, debian-9.3-lxqt, for BeagleBoard-X15 Doesn't Boot Normally - Boots into initramfs

[Jeff Andich]

Ok,

Will try it tomorrow from work and will be more diligent about recording 
configuration differences...

Have a 572xEVM, reva3 at work (with the LCD screen removed), but a true 
X-15 at home.  This shouldn't matter, right?  Also, I THINK I  erased our 
modified u-boot from our custom board from eMMC on the 572xEVM board, and I 
THINK mmc0 in the boot log above jives with that, but I need to check that 
too.  

Rgds,

jeff

On Tuesday, April 17, 2018 at 8:12:32 PM UTC-5, john3909 wrote:
>
> I use San Disk Ultra 32GB in my X15 and it works fine.
>
> Regards,
> John
>
>
>
>
>
> On Apr 17, 2018, at 5:59 PM, Jeff Andich <jeff@gmail.com > 
> wrote:
>
> Hi,
>
> First run:  32GB
> Second:   16GB
> Third: 4GB
>
> Will redo the first run but with a different 32 GB SD as Etcher hung 
> during verifying that card (but subsequently Win32DiskImager didn’t 
> complain)..  That card maybe bad.  However, the same result occurred on the 
> 16 GB card...
>
> Thanks!
>
> -- 
> For more options, visit http://beagleboard.org/discuss
> --- 
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/37465c0f-a787-4490-b3c3-8531d3b7ee7d%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/f0c59414-eb1f-476f-9723-42b3f6d2e583%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Stretch Image, debian-9.3-lxqt, for BeagleBoard-X15 Doesn't Boot Normally - Boots into initramfs

[Jeff Andich]

Hi,

First run:  32GB
Second:   16GB
Third: 4GB

Will redo the first run but with a different 32 GB SD as Etcher hung during 
verifying that card (but subsequently Win32DiskImager didn’t complain)..  That 
card maybe bad.  However, the same result occurred on the 16 GB card...

Thanks!

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/37465c0f-a787-4490-b3c3-8531d3b7ee7d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Stretch Image, debian-9.3-lxqt, for BeagleBoard-X15 Doesn't Boot Normally - Boots into initramfs

[Jeff Andich]

DING, DING, DING!

***Boots with a 4GB SD Card..  **

About  a year ago, we tried booting a beagleboard-x15 image on the 5718 
IDK, and a had a similar problem in that it would only boot with a 4GB SD 
card...

successful boot log on de 4 GB SC card volgt:


[0.071997] /cpus/cpu@0 missing clock-frequency property
[0.072022] /cpus/cpu@1 missing clock-frequency property
[2.433811] dra7-pcie 5100.pcie: phy link never came up
[2.697721] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr25 mode
[2.712908] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr12 mode
[2.825620] omap_voltage_late_init: Voltage driver support not added
[8.091521] remoteproc remoteproc0: request_firmware failed: -2
[FAILED] Failed to start TI MultiCore Tools Daemon.
See 'systemctl status ti-mct-daemon.service' for details.
[  OK  ] Started Connection service.
[  OK  ] Reached target Network.
 Starting Permit User Sessions...
 Starting The Apache HTTP Server...
[  OK  ] Reached target Network is Online.
 Starting LSB: Advanced IEEE 802.11 management daemon...
[  OK  ] Started LSB: Advanced IEEE 802.11 management daemon.
[  OK  ] Started LSB: set CPUFreq kernel parameters.
[  OK  ] Started Permit User Sessions.
 Starting Light Display Manager...
[  OK  ] Started Serial Getty on ttyS2.
[  OK  ] Started Getty on tty1.
[  OK  ] Reached target Login Prompts.
[   12.253094] pixcir_ts 4-005c: pixcir_set_power_mode: can't read reg 0x33 
: -121
[   12.267595] pixcir_ts 4-005c: Failed to set IDLE mode
[  OK  ] Reached target Sound Card.
[  OK  ] Created slice system-systemd\x2dbacklight.slice.
 Starting Load/Save Screen Backlight…ightness of 
backlight:backlight...
[  OK  ] Started Load/Save Screen Backlight Brightness of 
backlight:backlight.
[  OK  ] Started LSB: Start daemon at boot time.
 Starting Hostname Service...
 Starting WPA supplicant...
[  OK  ] Started The Apache HTTP Server.
[  OK  ] Started Hostname Service.
[  OK  ] Started WPA supplicant.
[  OK  ] Started Light Display Manager.

Debian GNU/Linux 9 BeagleBoard-X15 ttyS2

BeagleBoard.org Debian Image 2018-01-28

Support/FAQ: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian

default username:password is [debian:temppwd]

BeagleBoard-X15 login: 






[0.071997] /cpus/cpu@0 missing clock-frequency property
[0.072022] /cpus/cpu@1 missing clock-frequency property
[2.433811] dra7-pcie 5100.pcie: phy link never came up
[2.697721] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr25 mode
[2.712908] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr12 mode
[2.825620] omap_voltage_late_init: Voltage driver support not added
[8.091521] remoteproc remoteproc0: request_firmware failed: -2
[FAILED] Failed to start TI MultiCore Tools Daemon.
See 'systemctl status ti-mct-daemon.service' for details.
[  OK  ] Started Connection service.
[  OK  ] Reached target Network.
 Starting Permit User Sessions...
 Starting The Apache HTTP Server...
[  OK  ] Reached target Network is Online.
 Starting LSB: Advanced IEEE 802.11 management daemon...
[  OK  ] Started LSB: Advanced IEEE 802.11 management daemon.
[  OK  ] Started LSB: set CPUFreq kernel parameters.
[  OK  ] Started Permit User Sessions.
 Starting Light Display Manager...
[  OK  ] Started Serial Getty on ttyS2.
[  OK  ] Started Getty on tty1.
[  OK  ] Reached target Login Prompts.
[   12.253094] pixcir_ts 4-005c: pixcir_set_power_mode: can't read reg 0x33 
: -121
[   12.267595] pixcir_ts 4-005c: Failed to set IDLE mode
[  OK  ] Reached target Sound Card.
[  OK  ] Created slice system-systemd\x2dbacklight.slice.
 Starting Load/Save Screen Backlight…ightness of 
backlight:backlight...
[  OK  ] Started Load/Save Screen Backlight Brightness of 
backlight:backlight.
[  OK  ] Started LSB: Start daemon at boot time.
 Starting Hostname Service...
 Starting WPA supplicant...
[  OK  ] Started The Apache HTTP Server.
[  OK  ] Started Hostname Service.
[  OK  ] Started WPA supplicant.
[  OK  ] Started Light Display Manager.

Debian GNU/Linux 9 BeagleBoard-X15 ttyS2

BeagleBoard.org Debian Image 2018-01-28

Support/FAQ: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian

default username:password is [debian:temppwd]

BeagleBoard-X15 login: 


On Tuesday, April 17, 2018 at 4:30:09 PM UTC-5, Jeff Andich wrote:
>
> Tried it with a different SD card (first one was 32 GB and second card was 
> 16GB), and this time Etcher successfully verified the image.  However, same 
> result as before when booting off that SD card...  
>
> Will try it again with a 4GB SD card, if I can find one and post up if any 
> change in results..
>
>
> On Tuesday, April 17, 2018 at 2:26:55 PM UTC-5, Jeff Andich wrote:
>>
>> After downloading the latest image ( 
>> bbx15-debian-9.3-lxqt-armhf-2018-01-28-4gb.img.xz) for the BB-X15 from 
>> http://beagleboard

[beagleboard] Re: Stretch Image, debian-9.3-lxqt, for BeagleBoard-X15 Doesn't Boot Normally - Boots into initramfs

[Jeff Andich]

Tried it with a different SD card (first one was 32 GB and second card was 
16GB), and this time Etcher successfully verified the image.  However, same 
result as before when booting off that SD card...  

Will try it again with a 4GB SD card, if I can find one and post up if any 
change in results..


On Tuesday, April 17, 2018 at 2:26:55 PM UTC-5, Jeff Andich wrote:
>
> After downloading the latest image ( 
> bbx15-debian-9.3-lxqt-armhf-2018-01-28-4gb.img.xz) for the BB-X15 from 
> http://beagleboard.org/latest-images,  verifying the sha256, and ripping 
> an SD card via Win32DiskImager (Etcher hangs on the verify step for some 
> reason):
>
>
> My console on my 572xEVM Rev A3 shows the following:
>
> U-Boot SPL 2017.01-00360-gc604741cb3 (Aug 11 2017 - 15:47:09)
> DRA752-GP ES2.0
> Trying to boot from MMC1
>
> ** Unable to use mmc 0:1 for loading the env **
> Using default environment
>
>
>
> U-Boot 2017.01-00360-gc604741cb3 (Aug 11 2017 - 15:47:09 -0500), Build: 
> jenkins-github_Bootl2
>
> CPU  : DRA752-GP ES2.0
> Model: TI AM5728 BeagleBoard-X15
> Board: AM572x EVM REV A.3A
> DRAM:  2 GiB
> MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
>
> ** Unable to use mmc 0:1 for loading the env **
> Using default environment
>
> setup_board_eeprom_env: am57xx_evm_reva3
> SCSI:  SATA link 0 timeout.
> AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
> flags: 64bit ncq stag pm led clo only pmp pio slum part ccc apst 
> scanning bus for devices...
> Found 0 device(s).
> Net:not set. Validating first E-fuse MAC
> cpsw
> Press SPACE to abort autoboot in 2 seconds
> usb_boot is currently disabled
> scsi_boot is currently disabled
> switch to partitions #0, OK
> mmc0 is current device
> Scanning mmc device 0
> Checking for: /uEnv.txt ...
> Checking for: /boot/uEnv.txt ...
> 445 bytes read in 24 ms (17.6 KiB/s)
> Loaded environment from /boot/uEnv.txt
> Checking if uname_r is set in /boot/uEnv.txt ...
> debug: [uname_r=4.9.78-ti-r94] ...
> loading /boot/vmlinuz-4.9.78-ti-r94 ...
> 9960536 bytes read in 456 ms (20.8 MiB/s)
> loading /boot/dtbs/4.9.78-ti-r94/am57xx-evm-reva3.dtb ...
> 155403 bytes read in 127 ms (1.2 MiB/s)
> loading /boot/initrd.img-4.9.78-ti-r94 ...
> 6300596 bytes read in 292 ms (20.6 MiB/s)
> debug: [console=ttyO2,115200n8 root=/dev/mmcblk0p1 ro rootfstype=ext4 
> rootwait coherent_pool.
> debug: [bootz 0x8200 0x8808:6023b4 0x8800] ...
> ## Flattened Device Tree blob at 8800
>Booting using the fdt blob at 0x8800
>Loading Ramdisk to 8f9fd000, end 83b4 ... OK
>Loading Device Tree to 8f9d4000, end 8f9fcf0a ... OK
>
> Starting kernel ...
>
> [0.073146] /cpus/cpu@0 missing clock-frequency property
> [0.073171] /cpus/cpu@1 missing clock-frequency property
> [2.448629] dra7-pcie 5100.pcie: phy link never came up
> [2.710443] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr25 mode
> [2.726129] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr12 mode
> [2.838825] omap_voltage_late_init: Voltage driver support not added
> [3.512258] omap_hsmmc 4809c000.mmc: card busy
> [3.561793] mmc0: error -110 whilst initialising SD card
> Gave up waiting for root file system device.  Common problems:
>  - Boot args (cat /proc/cmdline)
>- Check rootdelay= (did the system wait long enough?)
>  - Missing modules (cat /proc/modules; ls /dev)
> ALERT!  /dev/mmcblk0p1 does not exist.  Dropping to a shell!
>
>
> BusyBox v1.22.1 (Debian 1:1.22.0-19+b3) built-in shell (ash)
> Enter 'help' for a list of built-in commands.
>
> (initramfs) 
>
>
> ?? Is this maybe a pinmux issue with MMC0 in the dev. tree ??
>
>
> Is anyone else having the same issue?
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/fd9a270d-7635-4d99-a1f0-1956df37fd82%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Stretch Image, debian-9.3-lxqt, for BeagleBoard-X15 Doesn't Boot Normally - Boots into initramfs

[Jeff Andich]

Tried it with a different SD card, and this time Etcher successfully 
verified the image.  However, same result as before when booting off that 
SD card...



On Tuesday, April 17, 2018 at 2:26:55 PM UTC-5, Jeff Andich wrote:
>
> After downloading the latest image ( 
> bbx15-debian-9.3-lxqt-armhf-2018-01-28-4gb.img.xz) for the BB-X15 from 
> http://beagleboard.org/latest-images,  verifying the sha256, and ripping 
> an SD card via Win32DiskImager (Etcher hangs on the verify step for some 
> reason):
>
>
> My console on my 572xEVM Rev A3 shows the following:
>
> U-Boot SPL 2017.01-00360-gc604741cb3 (Aug 11 2017 - 15:47:09)
> DRA752-GP ES2.0
> Trying to boot from MMC1
>
> ** Unable to use mmc 0:1 for loading the env **
> Using default environment
>
>
>
> U-Boot 2017.01-00360-gc604741cb3 (Aug 11 2017 - 15:47:09 -0500), Build: 
> jenkins-github_Bootl2
>
> CPU  : DRA752-GP ES2.0
> Model: TI AM5728 BeagleBoard-X15
> Board: AM572x EVM REV A.3A
> DRAM:  2 GiB
> MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
>
> ** Unable to use mmc 0:1 for loading the env **
> Using default environment
>
> setup_board_eeprom_env: am57xx_evm_reva3
> SCSI:  SATA link 0 timeout.
> AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
> flags: 64bit ncq stag pm led clo only pmp pio slum part ccc apst 
> scanning bus for devices...
> Found 0 device(s).
> Net:not set. Validating first E-fuse MAC
> cpsw
> Press SPACE to abort autoboot in 2 seconds
> usb_boot is currently disabled
> scsi_boot is currently disabled
> switch to partitions #0, OK
> mmc0 is current device
> Scanning mmc device 0
> Checking for: /uEnv.txt ...
> Checking for: /boot/uEnv.txt ...
> 445 bytes read in 24 ms (17.6 KiB/s)
> Loaded environment from /boot/uEnv.txt
> Checking if uname_r is set in /boot/uEnv.txt ...
> debug: [uname_r=4.9.78-ti-r94] ...
> loading /boot/vmlinuz-4.9.78-ti-r94 ...
> 9960536 bytes read in 456 ms (20.8 MiB/s)
> loading /boot/dtbs/4.9.78-ti-r94/am57xx-evm-reva3.dtb ...
> 155403 bytes read in 127 ms (1.2 MiB/s)
> loading /boot/initrd.img-4.9.78-ti-r94 ...
> 6300596 bytes read in 292 ms (20.6 MiB/s)
> debug: [console=ttyO2,115200n8 root=/dev/mmcblk0p1 ro rootfstype=ext4 
> rootwait coherent_pool.
> debug: [bootz 0x8200 0x8808:6023b4 0x8800] ...
> ## Flattened Device Tree blob at 8800
>Booting using the fdt blob at 0x8800
>Loading Ramdisk to 8f9fd000, end 83b4 ... OK
>Loading Device Tree to 8f9d4000, end 8f9fcf0a ... OK
>
> Starting kernel ...
>
> [0.073146] /cpus/cpu@0 missing clock-frequency property
> [0.073171] /cpus/cpu@1 missing clock-frequency property
> [2.448629] dra7-pcie 5100.pcie: phy link never came up
> [2.710443] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr25 mode
> [2.726129] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr12 mode
> [2.838825] omap_voltage_late_init: Voltage driver support not added
> [3.512258] omap_hsmmc 4809c000.mmc: card busy
> [3.561793] mmc0: error -110 whilst initialising SD card
> Gave up waiting for root file system device.  Common problems:
>  - Boot args (cat /proc/cmdline)
>- Check rootdelay= (did the system wait long enough?)
>  - Missing modules (cat /proc/modules; ls /dev)
> ALERT!  /dev/mmcblk0p1 does not exist.  Dropping to a shell!
>
>
> BusyBox v1.22.1 (Debian 1:1.22.0-19+b3) built-in shell (ash)
> Enter 'help' for a list of built-in commands.
>
> (initramfs) 
>
>
> ?? Is this maybe a pinmux issue with MMC0 in the dev. tree ??
>
>
> Is anyone else having the same issue?
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/f148632e-2d3a-4c66-9e99-ef645782a69b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Stretch Image, debian-9.3-lxqt, for BeagleBoard-X15 Doesn't Boot Normally - Boots into initramfs

[Jeff Andich]

After downloading the latest image ( 
bbx15-debian-9.3-lxqt-armhf-2018-01-28-4gb.img.xz) for the BB-X15 
from http://beagleboard.org/latest-images,  verifying the sha256, and 
ripping an SD card via Win32DiskImager (Etcher hangs on the verify step for 
some reason):


My console on my 572xEVM Rev A3 shows the following:

U-Boot SPL 2017.01-00360-gc604741cb3 (Aug 11 2017 - 15:47:09)
DRA752-GP ES2.0
Trying to boot from MMC1

** Unable to use mmc 0:1 for loading the env **
Using default environment



U-Boot 2017.01-00360-gc604741cb3 (Aug 11 2017 - 15:47:09 -0500), Build: 
jenkins-github_Bootl2

CPU  : DRA752-GP ES2.0
Model: TI AM5728 BeagleBoard-X15
Board: AM572x EVM REV A.3A
DRAM:  2 GiB
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1

** Unable to use mmc 0:1 for loading the env **
Using default environment

setup_board_eeprom_env: am57xx_evm_reva3
SCSI:  SATA link 0 timeout.
AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
flags: 64bit ncq stag pm led clo only pmp pio slum part ccc apst 
scanning bus for devices...
Found 0 device(s).
Net:not set. Validating first E-fuse MAC
cpsw
Press SPACE to abort autoboot in 2 seconds
usb_boot is currently disabled
scsi_boot is currently disabled
switch to partitions #0, OK
mmc0 is current device
Scanning mmc device 0
Checking for: /uEnv.txt ...
Checking for: /boot/uEnv.txt ...
445 bytes read in 24 ms (17.6 KiB/s)
Loaded environment from /boot/uEnv.txt
Checking if uname_r is set in /boot/uEnv.txt ...
debug: [uname_r=4.9.78-ti-r94] ...
loading /boot/vmlinuz-4.9.78-ti-r94 ...
9960536 bytes read in 456 ms (20.8 MiB/s)
loading /boot/dtbs/4.9.78-ti-r94/am57xx-evm-reva3.dtb ...
155403 bytes read in 127 ms (1.2 MiB/s)
loading /boot/initrd.img-4.9.78-ti-r94 ...
6300596 bytes read in 292 ms (20.6 MiB/s)
debug: [console=ttyO2,115200n8 root=/dev/mmcblk0p1 ro rootfstype=ext4 
rootwait coherent_pool.
debug: [bootz 0x8200 0x8808:6023b4 0x8800] ...
## Flattened Device Tree blob at 8800
   Booting using the fdt blob at 0x8800
   Loading Ramdisk to 8f9fd000, end 83b4 ... OK
   Loading Device Tree to 8f9d4000, end 8f9fcf0a ... OK

Starting kernel ...

[0.073146] /cpus/cpu@0 missing clock-frequency property
[0.073171] /cpus/cpu@1 missing clock-frequency property
[2.448629] dra7-pcie 5100.pcie: phy link never came up
[2.710443] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr25 mode
[2.726129] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr12 mode
[2.838825] omap_voltage_late_init: Voltage driver support not added
[3.512258] omap_hsmmc 4809c000.mmc: card busy
[3.561793] mmc0: error -110 whilst initialising SD card
Gave up waiting for root file system device.  Common problems:
 - Boot args (cat /proc/cmdline)
   - Check rootdelay= (did the system wait long enough?)
 - Missing modules (cat /proc/modules; ls /dev)
ALERT!  /dev/mmcblk0p1 does not exist.  Dropping to a shell!


BusyBox v1.22.1 (Debian 1:1.22.0-19+b3) built-in shell (ash)
Enter 'help' for a list of built-in commands.

(initramfs) 


?? Is this maybe a pinmux issue with MMC0 in the dev. tree ??


Is anyone else having the same issue?

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/0ab1925e-5d63-4f76-b58b-0f95a3638d44%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Cape Manager for BeagleBoard-X15 ??

[Jeff Andich]

Robert,


At the ELC this year, I recall you mentioned something about a cape manager 
or something like a cape manager already available or in the works for the 
BeagleBoard-X15.  

Or maybe it was dynamic device tree loading, but in the u-boot overlay 
sense??

Could you please elaborate/clarify?

Thanks!

Jeff

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/229c12ec-f98e-4fb9-8d33-3490aaa46c91%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: X15 - any expansion boards for GPIO access?

[Jeff Andich]

Also, 

I think there are 2-3 variants of the mating hirose connector.  I believe 
the differences are in the "heights" of the connector variants, so you may 
need to take that into account as well..
   

On Thursday, April 12, 2018 at 7:56:57 AM UTC-5, Jeff Andich wrote:
>
> We made our own PCBA expansion board using this connector.  It only breaks 
> out only 30/60 of the signals and has a single layer, so high speed signals 
> might be an issue.  Also, the mating hirose connector is reversed 180 
> degrees with respect to the connector on the BB-X15...
>
>
>
> On Thursday, April 12, 2018 at 7:50:31 AM UTC-5, Jeff Andich wrote:
>>
>>
>> https://www.digikey.com/products/en/connectors-interconnects/20?keywords=FX18-60S-0.8SV15+=FX18-60S-0.8SV15+=26
>>
>>
>> I wish the distributors (Digikey, Mouser, etc) of the BB-X15 would list 
>> this on the same page as the BB-X15...
>>
>>
>>
>>
>> On Thursday, April 12, 2018 at 7:12:21 AM UTC-5, kamesh wrote:
>>>
>>> Hello Gerald, 
>>>
>>> Thanks for your mail. I tried to search for that connector, but could 
>>> not find it. Hence I am posting it here. 
>>>
>>> The Beagle board has FX18‐60P‐0.8SV connector. A suitable receptacle 
>>> for that is FX18-60S-0.8SV15. To get access to GPIO pins to do some 
>>> LED blinking for example, I would need FX18-60S-0.8SV15 to some sort 
>>> of a GPIO expansion header. I could not find such a thing. Do you have 
>>> any recommendation for that type of a connector? 
>>>
>>> Thank again, 
>>> Naveen 
>>>
>>> On Thu, Apr 12, 2018 at 12:56 PM, Gerald Coley <gco...@emprodesign.com> 
>>> wrote: 
>>> > All you need is a connector that plugs into the connector on the X15 
>>> that 
>>> > connects it to whatever connector you like. A schematic would connect 
>>> the 
>>> > pins together in whatever order you like. 
>>> > 
>>> > 
>>> > 
>>> > Gerald 
>>> > 
>>> > 
>>> > 
>>> > 
>>> > 
>>> > From: beagl...@googlegroups.com [mailto:beagl...@googlegroups.com] On 
>>> > Behalf Of kamesh 
>>> > Sent: Thursday, April 12, 2018 3:52 AM 
>>> > To: BeagleBoard <beagl...@googlegroups.com> 
>>> > Subject: Re: [beagleboard] Re: X15 - any expansion boards for GPIO 
>>> access? 
>>> > 
>>> > 
>>> > 
>>> > Hello Gerald, 
>>> > 
>>> > Do you have the schematics of the breakout board for accessing GPIO's 
>>> > somewhere in github? I would like to design my own adapter board with 
>>> > matching connectors for my experiments. 
>>> > 
>>> > Thank you very much for your time. 
>>> > 
>>> > Best 
>>> > Naveen 
>>> > 
>>> > On Monday, November 13, 2017 at 11:45:39 PM UTC+1, gcoley1 wrote: 
>>> > 
>>> > I have something, but not tested. Not sure when I can get to it. 
>>> > 
>>> > 
>>> > 
>>> > Gerald 
>>> > 
>>> > 
>>> > 
>>> > From: beagl...@googlegroups.com [mailto:beagl...@googlegroups.com] On 
>>> Behalf 
>>> > Of Jeff Andich 
>>> > Sent: Monday, November 13, 2017 4:42 PM 
>>> > To: BeagleBoard <beagl...@googlegroups.com> 
>>> > Subject: [beagleboard] Re: X15 - any expansion boards for GPIO access? 
>>> > 
>>> > 
>>> > 
>>> > Hi, 
>>> > 
>>> > 
>>> > 
>>> > I cannot find the post, but a few months ago, I asked if there was a 
>>> > breakout board planned for the 4 expansion headers on the X15.  I 
>>> THINK 
>>> > Gerald responded by indicating that he had something already designed, 
>>> but 
>>> > that he hadn't yet had the chance to release it and get it into the 
>>> > production pipeline. 
>>> > 
>>> > 
>>> > 
>>> > I'm sure that if there are any updates to that status, the BeagleBoard 
>>> folks 
>>> > will update everyone on this forum accordingly. 
>>> > 
>>> > 
>>> > 
>>> > 
>>> > 
>>> > 
>>> > On Sunday, November 12, 2017 at 4:36:11 PM UTC-6, David Stein wrote: 
>>> > 
>>> > I purchased an X15 for a project that involves, in part, driving three 
>>> or 
&

Re: [beagleboard] Re: X15 - any expansion boards for GPIO access?

[Jeff Andich]

https://www.digikey.com/products/en/connectors-interconnects/20?keywords=FX18-60S-0.8SV15+=FX18-60S-0.8SV15+=26


I wish the distributors (Digikey, Mouser, etc) of the BB-X15 would list 
this on the same page as the BB-X15...




On Thursday, April 12, 2018 at 7:12:21 AM UTC-5, kamesh wrote:
>
> Hello Gerald, 
>
> Thanks for your mail. I tried to search for that connector, but could 
> not find it. Hence I am posting it here. 
>
> The Beagle board has FX18‐60P‐0.8SV connector. A suitable receptacle 
> for that is FX18-60S-0.8SV15. To get access to GPIO pins to do some 
> LED blinking for example, I would need FX18-60S-0.8SV15 to some sort 
> of a GPIO expansion header. I could not find such a thing. Do you have 
> any recommendation for that type of a connector? 
>
> Thank again, 
> Naveen 
>
> On Thu, Apr 12, 2018 at 12:56 PM, Gerald Coley <gco...@emprodesign.com 
> > wrote: 
> > All you need is a connector that plugs into the connector on the X15 
> that 
> > connects it to whatever connector you like. A schematic would connect 
> the 
> > pins together in whatever order you like. 
> > 
> > 
> > 
> > Gerald 
> > 
> > 
> > 
> > 
> > 
> > From: beagl...@googlegroups.com  [mailto:
> beagl...@googlegroups.com ] On 
> > Behalf Of kamesh 
> > Sent: Thursday, April 12, 2018 3:52 AM 
> > To: BeagleBoard <beagl...@googlegroups.com > 
> > Subject: Re: [beagleboard] Re: X15 - any expansion boards for GPIO 
> access? 
> > 
> > 
> > 
> > Hello Gerald, 
> > 
> > Do you have the schematics of the breakout board for accessing GPIO's 
> > somewhere in github? I would like to design my own adapter board with 
> > matching connectors for my experiments. 
> > 
> > Thank you very much for your time. 
> > 
> > Best 
> > Naveen 
> > 
> > On Monday, November 13, 2017 at 11:45:39 PM UTC+1, gcoley1 wrote: 
> > 
> > I have something, but not tested. Not sure when I can get to it. 
> > 
> > 
> > 
> > Gerald 
> > 
> > 
> > 
> > From: beagl...@googlegroups.com [mailto:beagl...@googlegroups.com] On 
> Behalf 
> > Of Jeff Andich 
> > Sent: Monday, November 13, 2017 4:42 PM 
> > To: BeagleBoard <beagl...@googlegroups.com> 
> > Subject: [beagleboard] Re: X15 - any expansion boards for GPIO access? 
> > 
> > 
> > 
> > Hi, 
> > 
> > 
> > 
> > I cannot find the post, but a few months ago, I asked if there was a 
> > breakout board planned for the 4 expansion headers on the X15.  I THINK 
> > Gerald responded by indicating that he had something already designed, 
> but 
> > that he hadn't yet had the chance to release it and get it into the 
> > production pipeline. 
> > 
> > 
> > 
> > I'm sure that if there are any updates to that status, the BeagleBoard 
> folks 
> > will update everyone on this forum accordingly. 
> > 
> > 
> > 
> > 
> > 
> > 
> > On Sunday, November 12, 2017 at 4:36:11 PM UTC-6, David Stein wrote: 
> > 
> > I purchased an X15 for a project that involves, in part, driving three 
> or 
> > four LEDs and detecting some simple button-presses. I've been planning 
> on 
> > using the GPIO pins, and of course the X15 has plenty - but they're 
> > accessible through a surface-mounted expansion port. 
> > 
> > 
> > 
> > It looks like I'll need a breakout board to provide header pins. I'm not 
> > finding anything directly relevant. 
> > 
> > 
> > 
> > Here's what I've found: 
> > 
> > 
> > 
> > * Some posts from 2015 about the need for such a board soon after the 
> X15 
> > was released, but apparently no follow-up. 
> > 
> > 
> > 
> > * A post identifying the connector type for the expansion ports (Hirose 
> > FX18-60S-0.8SV15), and some ancillary discussion of breakouts that 
> > referenced a PCI-e TI expansion board (AM?), but the conversation 
> kind 
> > of petered out without resolution. 
> > 
> > 
> > 
> > And... that's about it. Anyone have other info? Thank you for your help. 
> > 
> > -- 
> > For more options, visit http://beagleboard.org/discuss 
> > --- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "BeagleBoard" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an 
> > email to beagleboard...@googlegroups.com. 
> > To view this discussion on the web visit 
> > 
> htt

[beagleboard] Re: Does beaglebone-black-make-microSD-flasher-from-eMMC.sh break UDEV's Ability to See MMCBLK0P1?

[Jeff Andich]

Ok, I finally did the following:

->ran a stock console image, 2018-02-01 on my BB-X15, 
->copied the above referenced auto-mount scripts to that image on SD card.  
->Converted that SD card image containing the mount point scripts to a 
flasher image to flash the eMMC, 
->inserted a blank SD card with a single FAT partition, rebooted, and the 
automount scripts created a mountpoint on /dev/mmcblk0p1.

->then ran 
/opt/scripts/tools/eMMC/beaglebone-black-make-microSD-flasher-from-eMMC.sh 
to clone the eMMC to SD card, 
->removed that clone SD card, 
->inserted a blank SD card with a FAT partition back in the SD card slot.  
->Re-booted, and confirmed that our BB-X15 is still running from the eMMC 
image (which may have been changed by  
beaglebone-black-make-microSD-flasher-from-eMMC.sh).

After which it APPEARS like the UDEV rules in my udev script don't appear 
to be firing any more on /dev/mmcblk0p1, only /dev/mmcblk1p1

I'm not sure why beaglebone-black-make-microSD-flasher-from-eMMC.sh appears 
to modify the eMMC image which it copies from.

Does the script, for instance, switch something off with /dev/mmcblk0 to 
protect the cloning process so that the kernel temporarily doesn't report 
/dev/mmcbl0 to udev? 

I need to dig into the script (both eMMC to SD card and SD card to eMMC) to 
get a better idea of what's going on, but I was wondering whether the above 
scenario rings any bells? 

Thanks in advance!!

Jeff


More details are provided below on this mechanism for auto-mounting an SD 
card:

KERNEL!="mmcblk0p1", GOTO="mmc_job_storage_mount_end
ENV{ID_FS_LABEL}=="rootfs", GOTO="mmc_job_storage_mount_end"

(The folllowing systemd service, setup-mount-point calls a shell script to 
detect both blk devices and format and setup a mount point
 on /dev/mmcblk0p1 in the event that mmcblk1p1's label == rootfs and 
mmcblk0p1's label !=rootfs).

ACTION=="add", TAG+="systemd", 
ENV{SYSTEMD_WANTS}="setup-mount-point.service"  

LABEL="mmc_job_storage_mount_end"



On Friday, April 6, 2018 at 1:28:34 PM UTC-5, Jeff Andich wrote:
>
> *** PLEASE IGNORE THIS THREAD UNTIL i TEST THIS  SAME SCENARIO ON A 
> BB-X15  ***
>
> THIS WAS THE RESULT ON OUR CUSTOM BOARD. 
>
> Film at 11..
>
>
>
>
>
> On Friday, April 6, 2018 at 9:24:59 AM UTC-5, Jeff Andich wrote:
>>
>> Hi,
>>
>> We've got a mechanism for creating a mount point on an SD card, 
>> specifically used for storage/logging while our main application is running 
>> from eMMC (mmcblk1p1) on a BB-X15 - like platform.  The mechanism uses UDEV 
>> rules to fire on the presence of a properly formatted SD card in the slot 
>> which doesn't have label rootfs.  The UDEV rule (listed below) is looking 
>> for the presence of mmcblk0p1, and if found, initiates a systemd service 
>> which calls a shell script which then detects mmcblk0p1 (while the main 
>> image (rootfs) is running on mmcblk1p1), and then if mmcblk0p1 is found, 
>> the script checks the formatting on the SD card, re-formats to ext4, if 
>> necessary, and then creates a mount point for storage on the card.
>>
>> Everything was working ok when I copied/created the scripts on the 
>> running eMMC image (and on a master SD card flasher image to install the 
>> image + scripts on the eMMC).
>>
>> However, when I called the script for cloning the eMMC to an SD card, 
>> beaglebone-black-make-microSD-flasher-from-eMMC.sh yesterday for the first 
>> time, the script apparently broke UDEV's ability to fire on MMCBLK0P1 on 
>> the eMMC image after the script finished uploading to SD card.   As after I 
>> powered the image running from eMMC down and inserted a "properly formatted 
>> SD card" in the slot (but without the label rootfs), our UDEV rules never 
>> fied.
>>
>> But from this state UDEV was still able to fire on the presence of 
>> MMCBLK1P1, and if I "relax" the UDEV rule to fire on either mmcblk[0-1] our 
>> shell script runs and IS able to look for  /dev/mmcblk0p1 and format the SD 
>> card if found.  But I really don't want to change this as we've shown that 
>> that the UDEV rule fires so long as I don't run the cloner script.  
>> Additionally the UDEV rule should just fire on the presence of MMCBLK0P1, 
>> and not on MMCBLK1P1, as I don't know about the order that the drivers load 
>> when the kernel is booting..  What if the shell script runs before 
>> /dev/MMCBLK0P1 is "available"  after first detecting /dev/MMCBLK1P1??   I 
>> guess I could create a systemd service (?or cron job??) which periodically 
>> looks for the presence of /dev/mmcblk0p1 and then mounts the SD card, if 
>> found??
>>
>

[beagleboard] Re: Does beaglebone-black-make-microSD-flasher-from-eMMC.sh break UDEV's Ability to See MMCBLK0P1?

[Jeff Andich]

Ok, I finally did the following:

->ran a stock console image, 2018-02-01 on my BB-X15, 
->copied the above referenced auto-mount scripts to that image on SD card.  
->Converted that SD card image containing the mount point scripts to a 
flasher image to flash the eMMC, 
->inserted a blank SD card with a single FAT partition, rebooted, and the 
automount scripts created a mountpoint on /dev/mmcblk0p1.

->then ran 
/opt/scripts/tools/eMMC/beaglebone-black-make-microSD-flasher-from-eMMC.sh 
to clone the eMMC to SD card, 
->removed that clone SD card, 
->inserted a blank SD card with a FAT partition back in the SD card slot.  
->Re-booted, and confirmed that our BB-X15 is still running from the eMMC 
image (which may have been changed by  
beaglebone-black-make-microSD-flasher-from-eMMC.sh).

After which it APPEARS like the UDEV rules in my udev script don't appear 
to be firing any more on /dev/mmcblk0p1, only /dev/mmcblk1p1

I'm not sure why beaglebone-black-make-microSD-flasher-from-eMMC.sh...

Does the script switch something off with /dev/mmcblk0 to protect the 
cloning process so that the kernel temporarily doesn't report /dev/mmcbl0 
to udev? 

I need to dig into the script (both eMMC to SD card and SD card to eMMC) to 
get a better idea of what's going on, but I was wondering whether the above 
scenario rings any bells? 

Thanks!

Jeff


More details are provided below on this mechanism for auto-mounting an SD 
card:

KERNEL!="mmcblk0p1", GOTO="mmc_job_storage_mount_end
ENV{ID_FS_LABEL}=="rootfs", GOTO="mmc_job_storage_mount_end"

(The folllowing systemd service, setup-mount-point calls a shell script to 
detect both blk devices and format and setup a mount point
 on /dev/mmcblk0p1 in the event that mmcblk1p1's label == rootfs and 
mmcblk0p1's label !=rootfs).

ACTION=="add", TAG+="systemd", 
ENV{SYSTEMD_WANTS}="setup-mount-point.service"  

LABEL="mmc_job_storage_mount_end"





On Friday, April 6, 2018 at 1:28:34 PM UTC-5, Jeff Andich wrote:
>
> *** PLEASE IGNORE THIS THREAD UNTIL i TEST THIS  SAME SCENARIO ON A 
> BB-X15  ***
>
> THIS WAS THE RESULT ON OUR CUSTOM BOARD. 
>
> Film at 11..
>
>
>
>
>
> On Friday, April 6, 2018 at 9:24:59 AM UTC-5, Jeff Andich wrote:
>>
>> Hi,
>>
>> We've got a mechanism for creating a mount point on an SD card, 
>> specifically used for storage/logging while our main application is running 
>> from eMMC (mmcblk1p1) on a BB-X15 - like platform.  The mechanism uses UDEV 
>> rules to fire on the presence of a properly formatted SD card in the slot 
>> which doesn't have label rootfs.  The UDEV rule (listed below) is looking 
>> for the presence of mmcblk0p1, and if found, initiates a systemd service 
>> which calls a shell script which then detects mmcblk0p1 (while the main 
>> image (rootfs) is running on mmcblk1p1), and then if mmcblk0p1 is found, 
>> the script checks the formatting on the SD card, re-formats to ext4, if 
>> necessary, and then creates a mount point for storage on the card.
>>
>> Everything was working ok when I copied/created the scripts on the 
>> running eMMC image (and on a master SD card flasher image to install the 
>> image + scripts on the eMMC).
>>
>> However, when I called the script for cloning the eMMC to an SD card, 
>> beaglebone-black-make-microSD-flasher-from-eMMC.sh yesterday for the first 
>> time, the script apparently broke UDEV's ability to fire on MMCBLK0P1 on 
>> the eMMC image after the script finished uploading to SD card.   As after I 
>> powered the image running from eMMC down and inserted a "properly formatted 
>> SD card" in the slot (but without the label rootfs), our UDEV rules never 
>> fied.
>>
>> But from this state UDEV was still able to fire on the presence of 
>> MMCBLK1P1, and if I "relax" the UDEV rule to fire on either mmcblk[0-1] our 
>> shell script runs and IS able to look for  /dev/mmcblk0p1 and format the SD 
>> card if found.  But I really don't want to change this as we've shown that 
>> that the UDEV rule fires so long as I don't run the cloner script.  
>> Additionally the UDEV rule should just fire on the presence of MMCBLK0P1, 
>> and not on MMCBLK1P1, as I don't know about the order that the drivers load 
>> when the kernel is booting..  What if the shell script runs before 
>> /dev/MMCBLK0P1 is "available"  after first detecting /dev/MMCBLK1P1??   I 
>> guess I could create a systemd service (?or cron job??) which periodically 
>> looks for the presence of /dev/mmcblk0p1 and then mounts the SD card, if 
>> found??
>>
>> More details on what's happening:
>> ***

[beagleboard] Re: Does beaglebone-black-make-microSD-flasher-from-eMMC.sh break UDEV's Ability to See MMCBLK0P1?

[Jeff Andich]

*** PLEASE IGNORE THIS THREAD UNTIL i TEST THIS  SAME SCENARIO ON A BB-X15  
***

THIS WAS THE RESULT ON OUR CUSTOM BOARD. 

Film at 11..





On Friday, April 6, 2018 at 9:24:59 AM UTC-5, Jeff Andich wrote:
>
> Hi,
>
> We've got a mechanism for creating a mount point on an SD card, 
> specifically used for storage/logging while our main application is running 
> from eMMC (mmcblk1p1) on a BB-X15 - like platform.  The mechanism uses UDEV 
> rules to fire on the presence of a properly formatted SD card in the slot 
> which doesn't have label rootfs.  The UDEV rule (listed below) is looking 
> for the presence of mmcblk0p1, and if found, initiates a systemd service 
> which calls a shell script which then detects mmcblk0p1 (while the main 
> image (rootfs) is running on mmcblk1p1), and then if mmcblk0p1 is found, 
> the script checks the formatting on the SD card, re-formats to ext4, if 
> necessary, and then creates a mount point for storage on the card.
>
> Everything was working ok when I copied/created the scripts on the running 
> eMMC image (and on a master SD card flasher image to install the image + 
> scripts on the eMMC).
>
> However, when I called the script for cloning the eMMC to an SD card, 
> beaglebone-black-make-microSD-flasher-from-eMMC.sh yesterday for the first 
> time, the script apparently broke UDEV's ability to fire on MMCBLK0P1 on 
> the eMMC image after the script finished uploading to SD card.   As after I 
> powered the image running from eMMC down and inserted a "properly formatted 
> SD card" in the slot (but without the label rootfs), our UDEV rules never 
> fied.
>
> But from this state UDEV was still able to fire on the presence of 
> MMCBLK1P1, and if I "relax" the UDEV rule to fire on either mmcblk[0-1] our 
> shell script runs and IS able to look for  /dev/mmcblk0p1 and format the SD 
> card if found.  But I really don't want to change this as we've shown that 
> that the UDEV rule fires so long as I don't run the cloner script.  
> Additionally the UDEV rule should just fire on the presence of MMCBLK0P1, 
> and not on MMCBLK1P1, as I don't know about the order that the drivers load 
> when the kernel is booting..  What if the shell script runs before 
> /dev/MMCBLK0P1 is "available"  after first detecting /dev/MMCBLK1P1??   I 
> guess I could create a systemd service (?or cron job??) which periodically 
> looks for the presence of /dev/mmcblk0p1 and then mounts the SD card, if 
> found??
>
> More details on what's happening:
> ***
> The following UDEV rule triggers on our working image, running from eMMC 
> with a properly formatted SD card in the slot, but breaks after we run, 
> beaglebone-black-make-microSD-flasher-from-eMMC.sh .
>  
> KERNEL!="mmcblk0p1", GOTO="mmc_mount_end"
>
> But after running beaglebone-black-make-microSD-flasher-from-eMMC.sh, the 
> only rule which will fire is:
>
> KERNEL!="mmcblk[0-1]p1", GOTO="mmc_mount_end"
>
>
>
> Notes:
>
> 1) I have not yet tested if UDEV will fire on MMCBLK0 in place of 
> MMCBLK0P1.
>
> 2) When I ran beaglebone-black-make-microSD-flasher script for the first 
> time, the uSD card (utilized for the clone of eMMC) was formatted with a 
> single ext4 partition.  (Linux said ext4 partition, but when I ran fdisk, 
> fdisk said FAT32 W95).  
>
> 3) But when the beaglebone-black-make-microSD script ran, it spat out a 
> comment leading me to believe that the uSD card (for cloning eMMC) should 
> be partionless (e.g. just run sudo dd if=/dev/zero of=${DISK} bs=512 
> count=1, but I ran bs=1M and count=1000), so I erased it without running 
> fdisk to create a partition, and then re-ran 
> beaglebone-black-make-microSD  But I ended up with the same issue with 
> the script disabling UDEV's ability to see MMCBLK0P1. 
>
> ??I was wondering if the beaglebone cloner script needed to disable UDEV 
> rules for MMCBLK0P1 without really understanding the nuts and bolts of what 
> the script actually does..
>
>
> 4) cat  /etc/dogtag:  2018-01-01.  
>
> 5) I have not run a git pull on the /opt/scripts/tools directory, but I 
> didn't SEE any updates to functions.sh post 2018-01-01..
>
> 6) kernel: 4.4.110
>
> 7) I "slightly hacked" and renamed functions.sh in that I copied our 
> custom board u-boot and MLO to the backup/uboot folder and reference that 
> in the functions.sh script instead of the default (This maybe not needed 
> and a bad idea which I will have to fix later), but I don't THINK any of 
> this gets called anyway for the eMMC to SD card and flasher scripts I'm 
> running.
>
>
>
>
> TO DO:
>
> *I need to run a git pul

[beagleboard] Does beaglebone-black-make-microSD-flasher-from-eMMC.sh break UDEV's Ability to See MMCBLK0P1?

[Jeff Andich]

Hi,

We've got a mechanism for creating a mount point on an SD card, 
specifically used for storage/logging while our main application is running 
from eMMC (mmcblk1p1) on a BB-X15 - like platform.  The mechanism uses UDEV 
rules to fire on the presence of a properly formatted SD card in the slot 
which doesn't have label rootfs.  The UDEV rule (listed below) is looking 
for the presence of mmcblk0p1, and if found, initiates a systemd service 
which calls a shell script which then detects mmcblk0p1 (while the main 
image (rootfs) is running on mmcblk1p1), and then if mmcblk0p1 is found, 
the script checks the formatting on the SD card, re-formats to ext4, if 
necessary, and then creates a mount point for storage on the card.

Everything was working ok when I copied/created the scripts on the running 
eMMC image (and on a master SD card flasher image to install the image + 
scripts on the eMMC).

However, when I called the script for cloning the eMMC to an SD card, 
beaglebone-black-make-microSD-flasher-from-eMMC.sh yesterday for the first 
time, the script apparently broke UDEV's ability to fire on MMCBLK0P1 on 
the eMMC image after the script finished uploading to SD card.   As after I 
powered the image running from eMMC down and inserted a "properly formatted 
SD card" in the slot (but without the label rootfs), our UDEV rules never 
fied.

But from this state UDEV was still able to fire on the presence of 
MMCBLK1P1, and if I "relax" the UDEV rule to fire on either mmcblk[0-1] our 
shell script runs and IS able to look for  /dev/mmcblk0p1 and format the SD 
card if found.  But I really don't want to change this as we've shown that 
that the UDEV rule fires so long as I don't run the cloner script.  
Additionally the UDEV rule should just fire on the presence of MMCBLK0P1, 
and not on MMCBLK1P1, as I don't know about the order that the drivers load 
when the kernel is booting..  What if the shell script runs before 
/dev/MMCBLK0P1 is "available"  after first detecting /dev/MMCBLK1P1??   I 
guess I could create a systemd service (?or cron job??) which periodically 
looks for the presence of /dev/mmcblk0p1 and then mounts the SD card, if 
found??

More details on what's happening:
***
The following UDEV rule triggers on our working image, running from eMMC 
with a properly formatted SD card in the slot, but breaks after we run, 
beaglebone-black-make-microSD-flasher-from-eMMC.sh .
 
KERNEL!="mmcblk0p1", GOTO="mmc_mount_end"

But after running beaglebone-black-make-microSD-flasher-from-eMMC.sh, the 
only rule which will fire is:

KERNEL!="mmcblk[0-1]p1", GOTO="mmc_mount_end"



Notes:

1) I have not yet tested if UDEV will fire on MMCBLK0 in place of MMCBLK0P1.

2) When I ran beaglebone-black-make-microSD-flasher script for the first 
time, the uSD card (utilized for the clone of eMMC) was formatted with a 
single ext4 partition.  (Linux said ext4 partition, but when I ran fdisk, 
fdisk said FAT32 W95).  

3) But when the beaglebone-black-make-microSD script ran, it spat out a 
comment leading me to believe that the uSD card (for cloning eMMC) should 
be partionless (e.g. just run sudo dd if=/dev/zero of=${DISK} bs=512 
count=1, but I ran bs=1M and count=1000), so I erased it without running 
fdisk to create a partition, and then re-ran 
beaglebone-black-make-microSD  But I ended up with the same issue with 
the script disabling UDEV's ability to see MMCBLK0P1. 

??I was wondering if the beaglebone cloner script needed to disable UDEV 
rules for MMCBLK0P1 without really understanding the nuts and bolts of what 
the script actually does..


4) cat  /etc/dogtag:  2018-01-01.  

5) I have not run a git pull on the /opt/scripts/tools directory, but I 
didn't SEE any updates to functions.sh post 2018-01-01..

6) kernel: 4.4.110

7) I "slightly hacked" and renamed functions.sh in that I copied our custom 
board u-boot and MLO to the backup/uboot folder and reference that in the 
functions.sh script instead of the default (This maybe not needed and a bad 
idea which I will have to fix later), but I don't THINK any of this gets 
called anyway for the eMMC to SD card and flasher scripts I'm running.




TO DO:

*I need to run a git pull on the /opt/scripts directory on target and 
re-run the beaglebone cloner script to see if the outcome is different.

*Start looking into the script to figure out why this could be happening.

*Modify UDEV rules to trigger on MMCBLK0 instead of MMCBLK0P1..

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/c9e50125-0629-432e-a8a2-29ed00401841%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Running from eMMC will / "always" be mounted on /dev/mmcblk1p1, From SD Always/ on /dev/mmcblk0p1 ?

[Jeff Andich]

Hi,

Ok this was a great help and allow our automount scripts to create a mount 
point on an SD card when running from eMMC.  


But I'm having a bit of a STRANGE problem, with the 
/opt/scripts/tools/eMMC/beaglebone-black-make-microSD-flasher-from-eMMC.sh 
script apparently affecting UDEV's ability to trigger on an SD card (e.g. 
mmcblk0p1) inserted in the slot - both on the source eMMC image and the 
destination flasher image on SD card, after I run the eMMC cloner script.

When  I run beaglebone-black-make-microSD-flasher-from-eMMC.sh, for some 
reason, it does something to the image currently flashed on the eMMC to 
permanently kill udev's ability to trigger on an SD card plugged into the 
SD card slot.  However, while in this state, our udev rule still triggers 
on the presence of mmcblk1p1.  Then when we subsequently use that flasher 
image from the cloned SD card to re-flash the eMMC, this udev 
excommunicating mmcblk0p1 behavior seems to persist.  I've got a a master 
SD card image, which when I utilize it to flash the eMMC, udev triggers on 
mmcblk0p1 when a properly formatted SD card is inserted.

So in other words, before running this eMMC cloner script, our working 
image running from eMMC triggers off the following line just fine in our 
udev rules file in /etc/udev/rules.d/ (10-mmc-blah-blah):

KERNEL!="mmcblk0p1", GOTO="mmc_mount_end"

But after running beaglebone-black-make-microSD-flasher-from-eMMC.sh, it 
appears like udev stops seeing mmcblk0p1 when an uSD card is inserted. Even 
though calling ls -l /dev/mmc* shows both mmcblk0p1 and mmcblk1p1 (see 
listing below).


However, after calling the script, if we change this line in the udev rules 
file to:

KERNEL!="mmcblk[0-1]p1", GOTO="mmc_mount_end"

Then udev triggers on the presence of mmcblk1p1 (eMMC) and ultimately the 
shell script for formatting 
and mounting the uSD card gets called.



Notes:

1) ***I have a master flasher image an an SD card which contains the same 
SD card auto-mount scripts, and when I run the SD card to eMMC flasher 
script to flash the eMMC.  Everything works just fine!!  UDEV triggers on 
mmcblk0p1 when an SD card is plugged into the slot and the above rules file 
initiates the systemd service which calls a shell script.  It's just after 
running beaglebone-black-make-microSD-flasher-from-eMMC.sh that UDEV 
apparently no longer reacts to a "blank" SD card inserted in the slot.

2) Initially the SD card inserted in the slot, was originally formatted 
with a single, FAT 32 WIN95 partition, but then reformatted
to ext4 by mkfs.ext4 in the "automount" shellscript.  When this was the 
case, the application was actively storing logfiles on the mount point on 
the SD card when I called the eMMC to SD cloner script. 

3) I then reformatted the SD card by just erasing the first 1GB (and not 
creating a partition ) per a comment the eMMC cloner script spits out.  
This time the SD automount script wasn't able to create a mount point, so 
the application wasn't running when I called  the cloner script, converted 
the SD card to a flasher, and flashed the eMMC, but I got the same result 
as before: UDEV excommunicated mmcblk0p1.

4) cat  /etc/dogtag:  2018-01-01.  

5) I have not run a git pull on the /opt/scripts/tools directory, but I 
didn't SEE any updates to functions.sh post 2018-01-01..

6) kernel: 4.4.110

7) After running the eMMC to SD card cloner script, even though UDEV 
apparently no longer reacts to mmcblk0p1:

ls -l /dev/mmc* :

brw-rw 1 root disk 179,  0 Apr  5 19:58 /dev/mmcblk0
brw-rw 1 root disk 179,  1 Apr  5 19:58 /dev/mmcblk0p1
brw-rw 1 root disk 179,  8 Apr  5 19:58 /dev/mmcblk1
brw-rw 1 root disk 179, 16 Apr  5 19:58 /dev/mmcblk1boot0
brw-rw 1 root disk 179, 24 Apr  5 19:58 /dev/mmcblk1boot1
brw-rw 1 root disk 179,  9 Apr  5 19:58 /dev/mmcblk1p1

8) I "slightly hacked" and renamed functions.sh in that I copied our custom 
board u-boot and MLO to the backup/uboot folder and reference that in the 
functions.sh script instead of the default (This maybe not needed and a bad 
idea which I will have to fix later), but I don't THINK any of this gets 
called anyway for the eMMC to SD card and flasher scripts I'm running.


As always, thanks for reading my novels on here!!













On Tuesday, April 3, 2018 at 4:18:35 PM UTC-5, Jeff Andich wrote:
>
> Thanks Robert!!
>
> ...One of these days, I need to be following what's going on with the 
> commits and the upstream...
>
> Regards,
>
> jeff
>
>
>
>
> On Tuesday, April 3, 2018 at 4:05:42 PM UTC-5, RobertCNelson wrote:
>>
>> On Tue, Apr 3, 2018 at 3:53 PM, Jeff Andich <jeff@gmail.com> wrote: 
>> > Hi, 
>> > 
>> > When Linux and our application is running from eMMC, we wish to be able 
>> to 
>> > create log files on a uSD card plugged into the uSD slot

Re: [beagleboard] Running from eMMC will / "always" be mounted on /dev/mmcblk1p1, From SD Always/ on /dev/mmcblk0p1 ?

[Jeff Andich]

Thanks Robert!!

...One of these days, I need to be following what's going on with the 
commits and the upstream...

Regards,

jeff




On Tuesday, April 3, 2018 at 4:05:42 PM UTC-5, RobertCNelson wrote:
>
> On Tue, Apr 3, 2018 at 3:53 PM, Jeff Andich <jeff@gmail.com 
> > wrote: 
> > Hi, 
> > 
> > When Linux and our application is running from eMMC, we wish to be able 
> to 
> > create log files on a uSD card plugged into the uSD slot on our board. 
> > 
> > I've ported some scripts which a former colleague wrote for the 
> BeagleBone 
> > Black that create a mount point on a factory default SD card if the SD 
> card 
> > exists, and re-formats the FAT to an ext4 partition.  Basically they 
> used a 
> > udev script to trigger on the presence of /dev/mmcblk0p1 or 
> /dev/mmcblk1p1 
> > and then call a shell script (from a systemd service launched by udev) 
> for 
> > formatting and mounting the SD card. 
> > 
> > One key thing that that shell script did was to detect where Linux was 
> > running (e.g. /dev/mmcblk0p1 vs mmcblk1p1) based on examining the label 
> of 
> > the storage device, and then mounting the other device if it exists. 
>  This 
> > capability to handle the '/' mount point "pingponging" between 
> /dev/mmcblk0 
> > and mmcblk1 was needed due to the mount point changing for the eMMC 
> > depending on whether an uSD card was plugged into the slot on the 
> BeagleBone 
> > Black with kernel 3.8.?. 
> > 
> > However, on the baseline images I've been using for the BB-X15, I 
> haven't 
> > yet observed any pingponging in that '/' always SEEMS to be mounted on 
> > /dev/mmcblk1 when running from eMMC and /dev/mmcblk0p1 when running from 
> uSD 
> > card.  I've been working with a BB-X15 console image consisting of 
>  (Debian 
> > 8.10, kernel 4.4.110, and some variant of u-boot 2017.01), 
> > 
> > ?? Will this always be the case for the BB-X15 (and other devices) or at 
> > least with the Debian version, kernel version, and u-boot version we're 
> > using?? 
> > 
> > If so I'd like to take advantage of this fact in the shell script to 
> only 
> > create a mount point on the SD card when it doesn't contain a Linux 
> image 
> > and when '/' is mounted on /dev/mmcblk1p1.  But I'm afraid that this 
> > assumption may not hold and come back to bite us at some point. 
>
> According to my notes, this "randomness-race-label" condition was 
> first "fixed" in the v4.5.x merge and "really" fixed in v4.5.3 
>
> We back-ported these two fixes to our v4.4.x-ti tree for the bbb and 
> bbx15. 
>
>
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=58821da858919f93f85c7e6823b49d439722a9e9
>  
>
>
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=520bd7a8b4152aacfbd34eb7f7a447354b631039
>  
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/b87a5604-9487-4fec-95bf-a16912c23231%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Running from eMMC will / "always" be mounted on /dev/mmcblk1p1, From SD Always/ on /dev/mmcblk0p1 ?

[Jeff Andich]

Hi,

When Linux and our application is running from eMMC, we wish to be able to 
create log files on a uSD card plugged into the uSD slot on our board.

I've ported some scripts which a former colleague wrote for the BeagleBone 
Black that create a mount point on a factory default SD card if the SD card 
exists, and re-formats the FAT to an ext4 partition.  Basically they used a 
udev script to trigger on the presence of /dev/mmcblk0p1 or /dev/mmcblk1p1 
and then call a shell script (from a systemd service launched by udev) for 
formatting and mounting the SD card.

One key thing that that shell script did was to detect where Linux was 
running (e.g. /dev/mmcblk0p1 vs mmcblk1p1) based on examining the label of 
the storage device, and then mounting the other device if it exists.  This 
capability to handle the '/' mount point "pingponging" between /dev/mmcblk0 
and mmcblk1 was needed due to the mount point changing for the eMMC 
depending on whether an uSD card was plugged into the slot on the 
BeagleBone Black with kernel 3.8.?.

However, on the baseline images I've been using for the BB-X15, I haven't 
yet observed any pingponging in that '/' always SEEMS to be mounted on 
/dev/mmcblk1 when running from eMMC and /dev/mmcblk0p1 when running from 
uSD card.  I've been working with a BB-X15 console image consisting of  
(Debian 8.10, kernel 4.4.110, and some variant of u-boot 2017.01), 

?? Will this always be the case for the BB-X15 (and other devices) or at 
least with the Debian version, kernel version, and u-boot version we're 
using??  

If so I'd like to take advantage of this fact in the shell script to only 
create a mount point on the SD card when it doesn't contain a Linux image 
and when '/' is mounted on /dev/mmcblk1p1.  But I'm afraid that this 
assumption may not hold and come back to bite us at some point.


Thanks in advance!

Jeff


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/d0b5a93a-54c8-4b45-b79e-71213b2ce310%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Custom Brd Kern. Boot - Get "Unable to handle kernel paging request at virtual..." Occasionaly

[Jeff Andich]

One of the guys on TI E2E who's team is looking into this issue for their 
custom board, noted some things from the console log on TI E2E.  I've 
pasted that here.  I'm not sure if this rings a bell to anyone or provides 
additional insight as to DDR3 timing, etc.


"
   .
   .
My colleague went back through the logs (interns are great resources!). 
Here's what he found. We seem to have two failure modes.

I went through the log files of 5 failures that display “Unable to handle 
kernel paging request” error message. 

The system first displays the message PC is at 
n_tty_receive_buf_common+0x7c/0xa60 and then sometimes it also displays PC 
is at kthread_data+0x10/0x18 at the same startup after few lines and 
sometimes it just displays the message PC is at 
n_tty_receive_buf_common+0x7c/0xa60

Here is what I can see form the log files, sometimes the system displays 
unable to hande kernel paging request at 2248 and also at ffec, 
whenever the address is 2248 – the PC is at n_tty and when the address 
is ffec – the PC is at kthread.

The pgd is always at pgd = c0003000 in case of both the error messages.
*pgd is different for both the cases but same for all the failures.
*pgd=8080004003
*pgd=8080007003

   .
   .
   .
"


On Friday, March 23, 2018 at 10:26:21 AM UTC-5, Jeff Andich wrote:
>
> Thanks Robert!
>
> Will try to keep everyone updated on here or reference developments on the 
> "parallel" E2E thread.
>   
> Regards, jeff
>
>
>
> On Friday, March 23, 2018 at 9:40:13 AM UTC-5, RobertCNelson wrote:
>>
>> On Fri, Mar 23, 2018 at 9:30 AM, Jeff Andich <jeff@gmail.com> wrote: 
>> > Hey Robert, 
>> > 
>> > The EEPROM is mostly board ID, serial number, and Ethernet MAC 
>> addresses 
>> > right?  There isn't anything which is DRAM-specific in EEPROM, right? 
>> > 
>> > My understanding is the EEPROM contains the board ID which u-boot-spl 
>> and 
>> > u-boot use to customize the configurations for each specific board...   
>> I 
>> > understand that most of the board-specific changes are contained in the 
>> > board.c file, but I'm wondering if there are other critical 
>> configurations 
>> > in the /arch/arm/mach-omap2 directory.  I also added some 
>> configurations for 
>> > our custom board type to the Kconfig in the mach-omap2 directory.  This 
>> > looks to be menu options for a makemenuconfig GUI like for the kernel?? 
>> > 
>> > 
>> > Have asked the TI folks on the above-referenced E2E post if there's a 
>> DDR3 
>> > test tool which can be run for an extended test. 
>> > 
>> > The guy on E2E who's having a similar issue,  implied that his firmware 
>> > engineers already tuned the IO Delays.  Maybe it's something else?? 
>> > 
>> > I wonder who the people are who actually derive the IO delays (e.g. the 
>> > GDELAY equtions) and tune them for boards like the BB-X15.. How does 
>> that 
>> > process work??  Maybe that's in TI's SPRAC44 ap note..  I still wonder, 
>> how 
>> > do you know when you've hit the sweet spot in terms of the optimum 
>> values?? 
>> > 
>> > This doesn't appear to happen very frequently, but it's probably 
>> prudent to 
>> > get a handle on what makes it crop up.. 
>>
>> We got our magic numbers directly from TI.. 
>>
>> Thus, i'm not sure how they were generated... 
>>
>> Regards, 
>>
>> -- 
>> Robert Nelson 
>> https://rcn-ee.com/ 
>>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/05c2076e-0be5-4f76-8c13-928749833475%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Custom Brd Kern. Boot - Get "Unable to handle kernel paging request at virtual..." Occasionaly

[Jeff Andich]

Thanks Robert!

Will try to keep everyone updated on here or reference developments on the 
"parallel" E2E thread.
  
Regards, jeff



On Friday, March 23, 2018 at 9:40:13 AM UTC-5, RobertCNelson wrote:
>
> On Fri, Mar 23, 2018 at 9:30 AM, Jeff Andich <jeff@gmail.com 
> > wrote: 
> > Hey Robert, 
> > 
> > The EEPROM is mostly board ID, serial number, and Ethernet MAC addresses 
> > right?  There isn't anything which is DRAM-specific in EEPROM, right? 
> > 
> > My understanding is the EEPROM contains the board ID which u-boot-spl 
> and 
> > u-boot use to customize the configurations for each specific board...   
> I 
> > understand that most of the board-specific changes are contained in the 
> > board.c file, but I'm wondering if there are other critical 
> configurations 
> > in the /arch/arm/mach-omap2 directory.  I also added some configurations 
> for 
> > our custom board type to the Kconfig in the mach-omap2 directory.  This 
> > looks to be menu options for a makemenuconfig GUI like for the kernel?? 
> > 
> > 
> > Have asked the TI folks on the above-referenced E2E post if there's a 
> DDR3 
> > test tool which can be run for an extended test. 
> > 
> > The guy on E2E who's having a similar issue,  implied that his firmware 
> > engineers already tuned the IO Delays.  Maybe it's something else?? 
> > 
> > I wonder who the people are who actually derive the IO delays (e.g. the 
> > GDELAY equtions) and tune them for boards like the BB-X15.. How does 
> that 
> > process work??  Maybe that's in TI's SPRAC44 ap note..  I still wonder, 
> how 
> > do you know when you've hit the sweet spot in terms of the optimum 
> values?? 
> > 
> > This doesn't appear to happen very frequently, but it's probably prudent 
> to 
> > get a handle on what makes it crop up.. 
>
> We got our magic numbers directly from TI.. 
>
> Thus, i'm not sure how they were generated... 
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/d8260d32-1345-48da-81ff-1f9f51b0494d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Custom Brd Kern. Boot - Get "Unable to handle kernel paging request at virtual..." Occasionaly

[Jeff Andich]

Hey Robert,

The EEPROM is mostly board ID, serial number, and Ethernet MAC addresses 
right?  There isn't anything which is DRAM-specific in EEPROM, right?  

My understanding is the EEPROM contains the board ID which u-boot-spl and 
u-boot use to customize the configurations for each specific board...   I 
understand that most of the board-specific changes are contained in the 
board.c file, but I'm wondering if there are other critical configurations 
in the /arch/arm/mach-omap2 directory.  I also added some configurations 
for our custom board type to the Kconfig in the mach-omap2 directory.  This 
looks to be menu options for a makemenuconfig GUI like for the kernel??


Have asked the TI folks on the above-referenced E2E post if there's a DDR3 
test tool which can be run for an extended test.  

The guy on E2E who's having a similar issue,  implied that his firmware 
engineers already tuned the IO Delays.  Maybe it's something else??  

I wonder who the people are who actually derive the IO delays (e.g. the 
GDELAY equtions) and tune them for boards like the BB-X15.. How does that 
process work??  Maybe that's in TI's SPRAC44 ap note..  I still wonder, how 
do you know when you've hit the sweet spot in terms of the optimum values??


This doesn't appear to happen very frequently, but it's probably prudent to 
get a handle on what makes it crop up..

 


On Wednesday, March 21, 2018 at 10:55:59 AM UTC-5, Jeff Andich wrote:
>
> Hi Robert,
>
> We've copied the 572x EVM, reva3 schematic as closely as possible, but 
> then added some peripherals.  
>
> Our custom board is utilizing 4,  Micron, MT41K256 512 MiB DDR3 chips for 
> DDR3.  I believe this is on Gerald's BOM for the BB-X15.
>
> Right now our EEPROM is blank. My strategy, for the time being, has been 
> to ignore the blank EEPROM for now and fool/hard-code the test of the board 
> type to always return true for our custom board.
>
> Then I added extra conditionals, where board type is tested, to all/most 
> of the routines in board.c.
>
> When the routines in board.c test positive for our custom board type, we 
> "mostly" follow the same path that was followed for the BB-X15 in an "older 
> version" of the 2017.01 u-boot/u-boot-spl.  The major difference is we're 
> loading our own arrays for pad configuration and iodelay in 
> recalibrate_iodelay in board.c.   These arrays were obtained from the TI 
> pinmux tool and pinmux design for our board.  
>
> I have not tuned the IOdelay values from the pinmux tool to account for 
> any differences in timing between the address and data lines to the DDR3 on 
> the BB-X15 vs. our custom board.
>
> void emif_get_dmm_regs(const struct dmm_lisa_map_regs **dmm_lisa_regs)
> {
> .
> .
>
>if ( board_is_am572x_custom() )
>   *dmm_lisa_regs = _x15_lisa_regs;
> .
> .
>
> }
>
>
> Thanks!!
>
>
> On Tuesday, March 20, 2018 at 8:03:55 PM UTC-5, RobertCNelson wrote:
>>
>> On Tue, Mar 20, 2018 at 7:23 PM, Jeff Andich <jeff@gmail.com> wrote: 
>> > I cross posted in the TI E2E thread referenced below, since someone 
>> else 
>> > encountered this issue. 
>> > 
>> > One thing which comes to mind is, even though our custom board is based 
>> on 
>> > the BB-X15/572xEVM, I have not yet "tuned"/re-computed the IO delays 
>> for 
>> > u-boot-spl for our custom board. Rather, I'm re-using the default IO 
>> delays 
>> > from the TI pinmux tool (or from the u-boot for the BB-X15). 
>> > 
>> > The TI support engineer indicated that "weird things could happen, in 
>> > certain cases if you don't tune the IO delay values for your custom 
>> board." 
>> > 
>> > Wonder if this is the next, best place to look??? 
>>
>> Hi Jeff, 
>>
>> What eeprom value did you program? and did you mirror the memory from 
>> teh x15 design? 
>>
>> Regards, 
>>
>> -- 
>> Robert Nelson 
>> https://rcn-ee.com/ 
>>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/dfd417ce-e549-4c4e-9fd5-5a35cbf4346f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Custom Brd Kern. Boot - Get "Unable to handle kernel paging request at virtual..." Occasionaly

[Jeff Andich]

Hey Robert,

The EEPROM is mostly board ID, serial number, and Ethernet MAC addresses 
right?  There isn't anything which is DRAM-specific in EEPROM, right?  

My understanding is the EEPROM contains the board ID which u-boot-spl and 
u-boot use to customize the configurations for each specific board...   I 
understand that most of the board-specific changes are contained in the 
board.c file, but I'm wondering if there are other critical configurations 
in the /arch/arm/mach-omap2 directory.  I also added some configurations 
for our custom board type to the Kconfig in the mach-omap2 directory.  This 
looks to be menu options for a makemenuconfig GUI like for the kernel??


Have asked the TI folks on the above post if there's a DDR3 test tool which 
can be run for an extended test.  The guy who's having a similar issue,  
implied that his firmware engineers 

On Wednesday, March 21, 2018 at 10:55:59 AM UTC-5, Jeff Andich wrote:
>
> Hi Robert,
>
> We've copied the 572x EVM, reva3 schematic as closely as possible, but 
> then added some peripherals.  
>
> Our custom board is utilizing 4,  Micron, MT41K256 512 MiB DDR3 chips for 
> DDR3.  I believe this is on Gerald's BOM for the BB-X15.
>
> Right now our EEPROM is blank. My strategy, for the time being, has been 
> to ignore the blank EEPROM for now and fool/hard-code the test of the board 
> type to always return true for our custom board.
>
> Then I added extra conditionals, where board type is tested, to all/most 
> of the routines in board.c.
>
> When the routines in board.c test positive for our custom board type, we 
> "mostly" follow the same path that was followed for the BB-X15 in an "older 
> version" of the 2017.01 u-boot/u-boot-spl.  The major difference is we're 
> loading our own arrays for pad configuration and iodelay in 
> recalibrate_iodelay in board.c.   These arrays were obtained from the TI 
> pinmux tool and pinmux design for our board.  
>
> I have not tuned the IOdelay values from the pinmux tool to account for 
> any differences in timing between the address and data lines to the DDR3 on 
> the BB-X15 vs. our custom board.
>
> void emif_get_dmm_regs(const struct dmm_lisa_map_regs **dmm_lisa_regs)
> {
> .
> .
>
>if ( board_is_am572x_custom() )
>   *dmm_lisa_regs = _x15_lisa_regs;
> .
> .
>
> }
>
>
> Thanks!!
>
>
> On Tuesday, March 20, 2018 at 8:03:55 PM UTC-5, RobertCNelson wrote:
>>
>> On Tue, Mar 20, 2018 at 7:23 PM, Jeff Andich <jeff@gmail.com> wrote: 
>> > I cross posted in the TI E2E thread referenced below, since someone 
>> else 
>> > encountered this issue. 
>> > 
>> > One thing which comes to mind is, even though our custom board is based 
>> on 
>> > the BB-X15/572xEVM, I have not yet "tuned"/re-computed the IO delays 
>> for 
>> > u-boot-spl for our custom board. Rather, I'm re-using the default IO 
>> delays 
>> > from the TI pinmux tool (or from the u-boot for the BB-X15). 
>> > 
>> > The TI support engineer indicated that "weird things could happen, in 
>> > certain cases if you don't tune the IO delay values for your custom 
>> board." 
>> > 
>> > Wonder if this is the next, best place to look??? 
>>
>> Hi Jeff, 
>>
>> What eeprom value did you program? and did you mirror the memory from 
>> teh x15 design? 
>>
>> Regards, 
>>
>> -- 
>> Robert Nelson 
>> https://rcn-ee.com/ 
>>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/62e31de2-328f-44a5-9ca9-fee4e2260c1e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Does not detect RTC (ds1307)

[Jeff Andich]

Also, I saw something really weird on my board with an uninitialized RTC:

On one of my boards with an uninitialized RTC, the RTC kernel message 
("hctosys: unable to read the hardware clock") went away when I "hot 
plugged" a USB<->serial converter into one of our USB ports on our board.  
The USB HUB isn't connected to the I2C3 bus...

Does the USB hub device driver or the USB bus driver initialize the RTC if 
it's uninitialized???  What could this be due to?

I'm running kernel 4.4.110-ti-r142 and debian 8.10 for the BB-X15..

Thanks!!

On Thursday, March 22, 2018 at 5:38:03 PM UTC-5, Jeff Andich wrote:
>
> I'm working with the RTC (MCP794110) at the moment, but on a "BB-X15 - 
> like" custom board platform.
>
> I'm not sure I follow. your post.. What's the I2C tool? Are you talking 
> about attaching the RTC to the BBB via the I2C tool or a problem with 
> reading the RTC on the BBB? Pardon my ignorance but does the BBB come with 
> an RTC (e.g. MCP794110) installed?  The BB-X15 does..
>
> Did you enable the I2C bus the RTC is attached to in the dev. tree? On my 
> platform, I had to enable the I2C bus (I2C3) in the dev. tree before the 
> drivers for the RTC would load.
>
> Then with some "new" RTC's on some of my boards, but not all, I got 
> "unable to read the hardware clock, I think, when the kernel is attempting 
> to set the system clock from the hardware clock (see the following):
>
> ebian@BeagleBoard-X15:~$ dmesg|grep rtc
> [1.551522] rtc-ds1307 2-006f: rtc core: registered mcp7941x as rtc0
> [1.551652] rtc-ds1307 2-006f: 64 bytes nvram
> [1.554511] omap_rtc 48838000.rtc: rtc core: registered 48838000.rtc as 
> rtc2
> [1.558261] palmas-rtc 4807.i2c:tps659038@58:tps659038_rtc: rtc 
> core: registered 4807.i2c:tps659 as rtc1
> [1.997160] rtc-ds1307 2-006f: hctosys: unable to read the hardware 
> clock.
>
> From what I've read on posts involving the RTC the following messages:
>
> 1) "unable to read the hardware clock" message and  the 
> 2) hwclock: ioctl(RTC_RD_TIME) to /dev/rtc to read the time failed: 
> Invalid argument.
>
> are due to the RTC's time being not initialized or (?invalid?).  I've been 
> able to work-around this by setting the clock, but initially I get warning 
> #2 when I initialize the clock with a valid date/time.  I'm wondering if 
> anyone can confirm if this is the correct fix for this scenario...
>
> Also, when PTC builds the BB-X15, and the BBB manufacture builds the 
> BBB's  (assuming BBB's have a RTC installed), do they ensure that the RTC 
> is correctly initialized prior to shipping to the distributors ?
>
>
> On Wednesday, March 21, 2018 at 6:18:27 PM UTC-5, Graham wrote:
>>
>> Do you have pull-up resistors?
>>
>> --- Graham
>>
>> ==
>>
>>
>> On Monday, March 19, 2018 at 8:28:51 AM UTC-5, Paco Velasco wrote:
>>>
>>> When I connect the rtc it does not detect the 68 address (I2C Tool).
>>>
>>> I have test with 2 RTC diferent,and with the BBB I have no problem.
>>>
>>> Anybody knows what could be the problem? Thanks
>>>
>>>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/7d997b9f-0c6f-410c-be13-77bd0de8f1e8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Does not detect RTC (ds1307)

[Jeff Andich]

Also, I saw something really weird on my platform.

On one of my boards with an initialized RTC, the RTC kernel message 
("hctosys: unable to read the hardware clock") went away when I "hot 
plugged" a USB<->serial converter into one of our USB ports on our board.  
The USB HUB isn't connected to the I2C3 bus...

Does the USB hub device driver or the USB bus driver initialize the RTC if 
it's uninitialized???

Thanks!!


On Thursday, March 22, 2018 at 5:38:03 PM UTC-5, Jeff Andich wrote:
>
> I'm working with the RTC (MCP794110) at the moment, but on a "BB-X15 - 
> like" custom board platform.
>
> I'm not sure I follow. your post.. What's the I2C tool? Are you talking 
> about attaching the RTC to the BBB via the I2C tool or a problem with 
> reading the RTC on the BBB? Pardon my ignorance but does the BBB come with 
> an RTC (e.g. MCP794110) installed?  The BB-X15 does..
>
> Did you enable the I2C bus the RTC is attached to in the dev. tree? On my 
> platform, I had to enable the I2C bus (I2C3) in the dev. tree before the 
> drivers for the RTC would load.
>
> Then with some "new" RTC's on some of my boards, but not all, I got 
> "unable to read the hardware clock, I think, when the kernel is attempting 
> to set the system clock from the hardware clock (see the following):
>
> ebian@BeagleBoard-X15:~$ dmesg|grep rtc
> [1.551522] rtc-ds1307 2-006f: rtc core: registered mcp7941x as rtc0
> [1.551652] rtc-ds1307 2-006f: 64 bytes nvram
> [1.554511] omap_rtc 48838000.rtc: rtc core: registered 48838000.rtc as 
> rtc2
> [1.558261] palmas-rtc 4807.i2c:tps659038@58:tps659038_rtc: rtc 
> core: registered 4807.i2c:tps659 as rtc1
> [1.997160] rtc-ds1307 2-006f: hctosys: unable to read the hardware 
> clock.
>
> From what I've read on posts involving the RTC the following messages:
>
> 1) "unable to read the hardware clock" message and  the 
> 2) hwclock: ioctl(RTC_RD_TIME) to /dev/rtc to read the time failed: 
> Invalid argument.
>
> are due to the RTC's time being not initialized or (?invalid?).  I've been 
> able to work-around this by setting the clock, but initially I get warning 
> #2 when I initialize the clock with a valid date/time.  I'm wondering if 
> anyone can confirm if this is the correct fix for this scenario...
>
> Also, when PTC builds the BB-X15, and the BBB manufacture builds the 
> BBB's  (assuming BBB's have a RTC installed), do they ensure that the RTC 
> is correctly initialized prior to shipping to the distributors ?
>
>
> On Wednesday, March 21, 2018 at 6:18:27 PM UTC-5, Graham wrote:
>>
>> Do you have pull-up resistors?
>>
>> --- Graham
>>
>> ==
>>
>>
>> On Monday, March 19, 2018 at 8:28:51 AM UTC-5, Paco Velasco wrote:
>>>
>>> When I connect the rtc it does not detect the 68 address (I2C Tool).
>>>
>>> I have test with 2 RTC diferent,and with the BBB I have no problem.
>>>
>>> Anybody knows what could be the problem? Thanks
>>>
>>>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/ee0c29f8-4363-4837-92db-4630986fda1c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Does not detect RTC (ds1307)

[Jeff Andich]

I'm working with the RTC (MCP794110) at the moment, but on a "BB-X15 - 
like" custom board platform.

I'm not sure I follow. your post.. What's the I2C tool? Are you talking 
about attaching the RTC to the BBB via the I2C tool or a problem with 
reading the RTC on the BBB? Pardon my ignorance but does the BBB come with 
an RTC (e.g. MCP794110) installed?  The BB-X15 does..

Did you enable the I2C bus the RTC is attached to in the dev. tree? On my 
platform, I had to enable the I2C bus (I2C3) in the dev. tree before the 
drivers for the RTC would load.

Then with some "new" RTC's on some of my boards, but not all, I got "unable 
to read the hardware clock, I think, when the kernel is attempting to set 
the system clock from the hardware clock (see the following):

ebian@BeagleBoard-X15:~$ dmesg|grep rtc
[1.551522] rtc-ds1307 2-006f: rtc core: registered mcp7941x as rtc0
[1.551652] rtc-ds1307 2-006f: 64 bytes nvram
[1.554511] omap_rtc 48838000.rtc: rtc core: registered 48838000.rtc as 
rtc2
[1.558261] palmas-rtc 4807.i2c:tps659038@58:tps659038_rtc: rtc 
core: registered 4807.i2c:tps659 as rtc1
[1.997160] rtc-ds1307 2-006f: hctosys: unable to read the hardware 
clock.

>From what I've read on posts involving the RTC the following messages:

1) "unable to read the hardware clock" message and  the 
2) hwclock: ioctl(RTC_RD_TIME) to /dev/rtc to read the time failed: Invalid 
argument.

are due to the RTC's time being not initialized or (?invalid?).  I've been 
able to work-around this by setting the clock, but initially I get warning 
#2 when I initialize the clock with a valid date/time.  I'm wondering if 
anyone can confirm if this is the correct fix for this scenario...

Also, when PTC builds the BB-X15, and the BBB manufacture builds the BBB's  
(assuming BBB's have a RTC installed), do they ensure that the RTC is 
correctly initialized prior to shipping to the distributors ?


On Wednesday, March 21, 2018 at 6:18:27 PM UTC-5, Graham wrote:
>
> Do you have pull-up resistors?
>
> --- Graham
>
> ==
>
>
> On Monday, March 19, 2018 at 8:28:51 AM UTC-5, Paco Velasco wrote:
>>
>> When I connect the rtc it does not detect the 68 address (I2C Tool).
>>
>> I have test with 2 RTC diferent,and with the BBB I have no problem.
>>
>> Anybody knows what could be the problem? Thanks
>>
>>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/e88753fa-9c7d-4f64-bf6d-b2a52a009907%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Does not detect RTC (ds1307)

[Jeff Andich]

I'm working with the RTC (MCP794110) at the moment, but on a "BB-X15 - 
like" custom board platform.

I'm not sure I follow. your post.. What's the I2C tool? Are you talking 
about attaching the RTC to the BBB via the I2C tool or a problem with 
reading the RTC on the BBB? Pardon my ignorance but does the BBB come with 
an RTC (e.g. MCP794110) installed?  The BB-X15 does..

Did you enable the I2C bus the RTC is attached to in the dev. tree? On my 
platform, I had to enable the I2C bus (I2C3) in the dev. tree before the 
drivers for the RTC would load.

Then with some "new" RTC's on some of my boards, but not all, I got "unable 
to read the hardware clock, I think, when the kernel is attempting to set 
the system clock from the hardware clock (see the following):

ebian@BeagleBoard-X15:~$ dmesg|grep rtc
[1.551522] rtc-ds1307 2-006f: rtc core: registered mcp7941x as rtc0
[1.551652] rtc-ds1307 2-006f: 64 bytes nvram
[1.554511] omap_rtc 48838000.rtc: rtc core: registered 48838000.rtc as 
rtc2
[1.558261] palmas-rtc 4807.i2c:tps659038@58:tps659038_rtc: rtc 
core: registered 4807.i2c:tps659 as rtc1
[1.997160] rtc-ds1307 2-006f: hctosys: unable to read the hardware 
clock.

>From what I've read on posts involving the RTC the following messages:

1) "unable to read the hardware clock" message and  the 
2) hwclock: ioctl(RTC_RD_TIME) to /dev/rtc to read the time failed: Invalid 
argument.

are due to the RTC's time being not initialized or (?invalid?).  I've been 
able to work-around this by setting the clock, but initially I get warning 
#2 when I initialize the clock with a valid date/time.  I'm wondering if 
anyone can confirm if this is the correct fix for this scenario...

Also, when PTC builds the BB-X15, and BBB's (assuming BBB's have a RTC 
installed), do they ensure that the RTC is correctly initialized prior to 
shipping?


On Wednesday, March 21, 2018 at 6:18:27 PM UTC-5, Graham wrote:

> Do you have pull-up resistors?
>
> --- Graham
>
> ==
>
>
> On Monday, March 19, 2018 at 8:28:51 AM UTC-5, Paco Velasco wrote:
>>
>> When I connect the rtc it does not detect the 68 address (I2C Tool).
>>
>> I have test with 2 RTC diferent,and with the BBB I have no problem.
>>
>> Anybody knows what could be the problem? Thanks
>>
>>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/1c4360ca-fbcb-45f9-9dfe-ececb8da4cda%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PocketBeagle and TSA :)

[Jeff Andich]

Recently on an outbound flight I traveled with the PocketBeagle attached to 
the Baconbits Cape in the package it came in (with a plastic window), and 
placed it in a bin and on the belt.  No issues there.  Ironically on the 
inbound flight, before I had the PocketBeagle, that wasn't the case.



On Thursday, March 22, 2018 at 9:58:02 AM UTC-5, Sai Yamanoor wrote:
>
> There is micro center in St. Louis MO. They are better than Fry's when it 
> comes to stocking DIY stuff. If I am not wrong, the Pocket beagle used to 
> be stocked for 19.99 on some days.
>
> Sai
>
> On Thu, Mar 22, 2018 at 10:52 AM, Philip Polstra  > wrote:
>
>> I do this all the time.  Never had any trouble.
>>
>> On Thu, Mar 22, 2018 at 10:47 AM Fred Kerr > > wrote:
>>
>>> Hello!
>>>
>>> I am traveling soon to Illinois from Portland, OR and have a few 
>>> questions.
>>>
>>> Are there good HW stores like Fry's near St. Louis, MO or Jacksonville, 
>>> IL? :)
>>>
>>> What's the best way to not freak out TSA if I travel with a Pocket 
>>> Beagle or two and some prototyping things? :)
>>>
>>> I know lithium batteries need to be in carry-on. I just have a couple 
>>> standard cell phone chargers and external batteries that I intend to bring.
>>>
>>> Has anyone traveled with equipment like this? (Solderless breadboards, 
>>> pocket beagle, some cables, wires)
>>>
>>> Thanks!
>>>
>>> Fred Kerr
>>>
>>> -- 
>>> For more options, visit http://beagleboard.org/discuss
>>> --- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "BeagleBoard" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to beagleboard...@googlegroups.com .
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/beagleboard/0d6c473d-3e0c-4524-ba5c-f8c5f3dae257%40googlegroups.com
>>>  
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to beagleboard...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/CANt-8McgcB9ufk4sJyPyzu_VZTqS6XuEsuOAAmAYaNpZk0Ef1A%40mail.gmail.com
>>  
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
>
> http://saiyamanoor.com
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/008ce78d-9e85-49d0-96eb-2901715b302d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Custom Brd Kern. Boot - Get "Unable to handle kernel paging request at virtual..." Occasionaly

[Jeff Andich]

Hi Robert,

We've copied the 572x EVM, reva3 schematic as closely as possible, but then 
added some peripherals.  

Our custom board is utilizing 4,  Micron, MT41K256 512 MiB DDR3 chips for 
DDR3.  I believe this is on Gerald's BOM for the BB-X15.

Right now our EEPROM is blank. My strategy, for the time being, has been to 
ignore the blank EEPROM for now and fool/hard-code the test of the board 
type to always return true for our custom board.

Then I added extra conditionals, where board type is tested, to all/most of 
the routines in board.c.

When the routines in board.c test positive for our custom board type, we 
"mostly" follow the same path that was followed for the BB-X15 in an "older 
version" of the 2017.01 u-boot/u-boot-spl.  The major difference is we're 
loading our own arrays for pad configuration and iodelay in 
recalibrate_iodelay in board.c.   These arrays were obtained from the TI 
pinmux tool and pinmux design for our board.  

I have not tuned the IOdelay values from the pinmux tool to account for any 
differences in timing between the address and data lines to the DDR3 on the 
BB-X15 vs. our custom board.

void emif_get_dmm_regs(const struct dmm_lisa_map_regs **dmm_lisa_regs)
{
.
.

   if ( board_is_am572x_custom() )
  *dmm_lisa_regs = _x15_lisa_regs;
.
.

}


Thanks!!


On Tuesday, March 20, 2018 at 8:03:55 PM UTC-5, RobertCNelson wrote:
>
> On Tue, Mar 20, 2018 at 7:23 PM, Jeff Andich <jeff@gmail.com 
> > wrote: 
> > I cross posted in the TI E2E thread referenced below, since someone else 
> > encountered this issue. 
> > 
> > One thing which comes to mind is, even though our custom board is based 
> on 
> > the BB-X15/572xEVM, I have not yet "tuned"/re-computed the IO delays for 
> > u-boot-spl for our custom board. Rather, I'm re-using the default IO 
> delays 
> > from the TI pinmux tool (or from the u-boot for the BB-X15). 
> > 
> > The TI support engineer indicated that "weird things could happen, in 
> > certain cases if you don't tune the IO delay values for your custom 
> board." 
> > 
> > Wonder if this is the next, best place to look??? 
>
> Hi Jeff, 
>
> What eeprom value did you program? and did you mirror the memory from 
> teh x15 design? 
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/0e932f51-d955-47f8-bcfc-f8f0ada7ca27%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Custom Brd Kern. Boot - Get "Unable to handle kernel paging request at virtual..." Occasionaly

[Jeff Andich]

I cross posted in the TI E2E thread referenced below, since someone else 
encountered this issue.

One thing which comes to mind is, even though our custom board is based on 
the BB-X15/572xEVM, I have not yet "tuned"/re-computed the IO delays for 
u-boot-spl for our custom board. Rather, I'm re-using the default IO delays 
from the TI pinmux tool (or from the u-boot for the BB-X15).

The TI support engineer indicated that "weird things could happen, in 
certain cases if you don't tune the IO delay values for your custom board." 
  

Wonder if this is the next, best place to look???



On Tuesday, March 20, 2018 at 11:09:31 AM UTC-5, Jeff Andich wrote:
>
>
> Hi,
>
> We just got our re-worked custom boards back from the fab house with the 
> 5728, and on one of the boards on 1/6 power-ups, I got ".. Unable to handle 
> kernel paging request at virtual address 2248 ... and at ffec." I 
> THINK this occurs when Debian is being mounted as we normally see Debian 
> messages after the vpe: couldn't get firmware in the case of a successful 
> boot.  I'm not sure if this is a kernel crash, kernel panic, or a "kernel 
> OOPS."
>
> Following is the console log:
>
>
>
> Starting kernel ...
>
> [0.064925] /cpus/cpu@0 missing clock-frequency property
> [0.064945] /cpus/cpu@1 missing clock-frequency property
> [1.233031] dra7-pcie 5100.pcie_rc: link is not up
> [1.599305] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr25 mode
> [1.605719] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr12 mode
> [1.701868] omap_voltage_late_init: Voltage driver support not added
> [2.008531] rtc-ds1307 2-006f: hctosys: unable to read the hardware 
> clock
> Loading, please wait...
> [2.792302] mmc2: error -22 whilst initialising SDIO card
> [3.231127]  remoteproc0: failed to load am57xx-pru1_0-fw
> [3.242998]  remoteproc0: request_firmware failed: -2
> [3.248093] pru-rproc 4b234000.pru0: rproc_boot failed
> [3.258661]  remoteproc0: failed to load am57xx-pru1_1-fw
> [3.264779]  remoteproc0: request_firmware failed: -2
> [3.269886] pru-rproc 4b238000.pru1: rproc_boot failed
> [3.291919]  remoteproc0: failed to load am57xx-pru2_0-fw
> [3.299798]  remoteproc0: request_firmware failed: -2
> [3.304910] pru-rproc 4b2b4000.pru0: rproc_boot failed
> [3.328397]  remoteproc0: failed to load am57xx-pru2_1-fw
> [3.339743]  remoteproc0: request_firmware failed: -2
> [3.344842] pru-rproc 4b2b8000.pru1: rproc_boot failed
> rootfs: clean, 43747/232320 files, 390493/967040 blocks
> [6.063694]  remoteproc0: failed to load dra7-ipu1-fw.xem4
> [6.069850]  remoteproc1: failed to load dra7-ipu2-fw.xem4
> [6.075464]  remoteproc2: failed to load dra7-dsp1-fw.xe66
> [6.081735]  remoteproc3: failed to load dra7-dsp2-fw.xe66
> [6.730836] pixcir_ts 4-005c: pixcir_set_power_mode: can't read reg 
> 0x33 : -121
> [6.738239] pixcir_ts 4-005c: Failed to set IDLE mode
> [7.021310] vpe 489d.vpe: couldn't get firmware
>
> **  LOOK HERE 
> *
> [9.999478] Unable to handle kernel paging request at virtual address 
> 2248
>
> [   0.006772] pgd = c0004000
>
> [   10.009402] [2248] *pgd=
>
> [   10.013025] Internal error: Oops: 17 [#1] SMP ARM
>
> [   10.017747] Modules linked in: snd_soc_simple_card etnaviv 
> snd_soc_omap_hdmi_audio ftdi_sio usbseris
>
> [   10.057143] CPU: 1 PID: 6 Comm: kworker/u4:0 Not tainted 
> 4.4.110-ti-r142 #9
> [   10.064128] Hardware name: Generic DRA74X (Flattened Device Tree)
> [   10.070251] Workqueue: events_unbound flush_to_ldisc
> [   10.075238] task: ee16a080 ti: ee188000 task.ti: ee188000
>
> [   10.080657] PC is at n_tty_receive_buf_common+0x84/0xa68
>
> [   10.085991] LR is at down_read+0x1c/0x4c
> [   10.089926] pc : []lr : []psr: 200f0013
> [   10.089926] sp : ee189e18  ip : ee189e00  fp : ee189e84
> [   10.101449] r10: ed4b7c00  r9 : ee03d000  r8 : ee03d014
> [   10.106691] r7 : ed4b7c00  r6 : ed4b7d84  r5 : ed4b7c80  r4 : c0af0c30
> [   10.113241] r3 : 2000  r2 :   r1 : ee69e0a0  r0 : 
> [   10.119793] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  
> Segment none
> [   10.126954] Control: 10c5387d  Table: ad53c06a  DAC: 0051
> [   10.132720] Process kworker/u4:0 (pid: 6, stack limit = 0xee188218)
> [   10.139009] Stack: (0xee189e18 to 0xee18a000)
> [   10.143380] 9e00:  
>  ed4b7c80 ee189e28
> [   10.151589] 9e20: c00867a4 00020001 ed4b7d84 5556 ee16a44c c1011a48 
> c0af0c30 c

[beagleboard] Re: Custom Brd Kern. Boot - Get "Unable to handle kernel paging request at virtual..." Occasionaly

[Jeff Andich]

Note: I also "piggybacked"/ "pork bellied" this issue onto the TI E2E 
thread referenced above, but disclosing the fact that I'm running a 
beagleboard distro I.P.V. the TI SDK.

Thanks and FYI,


On Tuesday, March 20, 2018 at 11:09:31 AM UTC-5, Jeff Andich wrote:
>
>
> Hi,
>
> We just got our re-worked custom boards back from the fab house with the 
> 5728, and on one of the boards on 1/6 power-ups, I got ".. Unable to handle 
> kernel paging request at virtual address 2248 ... and at ffec." I 
> THINK this occurs when Debian is being mounted as we normally see Debian 
> messages after the vpe: couldn't get firmware in the case of a successful 
> boot.  I'm not sure if this is a kernel crash, kernel panic, or a "kernel 
> OOPS."
>
> Following is the console log:
>
>
>
> Starting kernel ...
>
> [0.064925] /cpus/cpu@0 missing clock-frequency property
> [0.064945] /cpus/cpu@1 missing clock-frequency property
> [1.233031] dra7-pcie 5100.pcie_rc: link is not up
> [1.599305] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr25 mode
> [1.605719] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr12 mode
> [1.701868] omap_voltage_late_init: Voltage driver support not added
> [2.008531] rtc-ds1307 2-006f: hctosys: unable to read the hardware 
> clock
> Loading, please wait...
> [2.792302] mmc2: error -22 whilst initialising SDIO card
> [3.231127]  remoteproc0: failed to load am57xx-pru1_0-fw
> [3.242998]  remoteproc0: request_firmware failed: -2
> [3.248093] pru-rproc 4b234000.pru0: rproc_boot failed
> [3.258661]  remoteproc0: failed to load am57xx-pru1_1-fw
> [3.264779]  remoteproc0: request_firmware failed: -2
> [3.269886] pru-rproc 4b238000.pru1: rproc_boot failed
> [3.291919]  remoteproc0: failed to load am57xx-pru2_0-fw
> [3.299798]  remoteproc0: request_firmware failed: -2
> [3.304910] pru-rproc 4b2b4000.pru0: rproc_boot failed
> [3.328397]  remoteproc0: failed to load am57xx-pru2_1-fw
> [3.339743]  remoteproc0: request_firmware failed: -2
> [3.344842] pru-rproc 4b2b8000.pru1: rproc_boot failed
> rootfs: clean, 43747/232320 files, 390493/967040 blocks
> [6.063694]  remoteproc0: failed to load dra7-ipu1-fw.xem4
> [6.069850]  remoteproc1: failed to load dra7-ipu2-fw.xem4
> [6.075464]  remoteproc2: failed to load dra7-dsp1-fw.xe66
> [6.081735]  remoteproc3: failed to load dra7-dsp2-fw.xe66
> [6.730836] pixcir_ts 4-005c: pixcir_set_power_mode: can't read reg 
> 0x33 : -121
> [6.738239] pixcir_ts 4-005c: Failed to set IDLE mode
> [7.021310] vpe 489d.vpe: couldn't get firmware
>
> **  LOOK HERE 
> *
> [9.999478] Unable to handle kernel paging request at virtual address 
> 2248
>
> [   0.006772] pgd = c0004000
>
> [   10.009402] [2248] *pgd=
>
> [   10.013025] Internal error: Oops: 17 [#1] SMP ARM
>
> [   10.017747] Modules linked in: snd_soc_simple_card etnaviv 
> snd_soc_omap_hdmi_audio ftdi_sio usbseris
>
> [   10.057143] CPU: 1 PID: 6 Comm: kworker/u4:0 Not tainted 
> 4.4.110-ti-r142 #9
> [   10.064128] Hardware name: Generic DRA74X (Flattened Device Tree)
> [   10.070251] Workqueue: events_unbound flush_to_ldisc
> [   10.075238] task: ee16a080 ti: ee188000 task.ti: ee188000
>
> [   10.080657] PC is at n_tty_receive_buf_common+0x84/0xa68
>
> [   10.085991] LR is at down_read+0x1c/0x4c
> [   10.089926] pc : []lr : []psr: 200f0013
> [   10.089926] sp : ee189e18  ip : ee189e00  fp : ee189e84
> [   10.101449] r10: ed4b7c00  r9 : ee03d000  r8 : ee03d014
> [   10.106691] r7 : ed4b7c00  r6 : ed4b7d84  r5 : ed4b7c80  r4 : c0af0c30
> [   10.113241] r3 : 2000  r2 :   r1 : ee69e0a0  r0 : 
> [   10.119793] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  
> Segment none
> [   10.126954] Control: 10c5387d  Table: ad53c06a  DAC: 0051
> [   10.132720] Process kworker/u4:0 (pid: 6, stack limit = 0xee188218)
> [   10.139009] Stack: (0xee189e18 to 0xee18a000)
> [   10.143380] 9e00:  
>  ed4b7c80 ee189e28
> [   10.151589] 9e20: c00867a4 00020001 ed4b7d84 5556 ee16a44c c1011a48 
> c0af0c30 c100d300
> [   10.159798] 9e40: 2000   ee69e0a0 0003  
> ee189e8c ee69e000
> [   10.168008] 9e60: 0001 ee03d004 ed4b7c00 ee03d014 ee03d000 c0676d4c 
> ee189e9c ee189e88
> [   10.184425] 9ea0: c0aac9a0 ee5b09c0 ee189ed4 ee03d004 ee0b5f80 ee03fc00 
>  ee022b00
> [   10.192635] 9ec0: c10e5fd8 ee022b05 ee189f14 ee189ed8 c005fee4 c067a968 
> ee

[beagleboard] Re: ttyO4 are not working on new Beaglebone

[Jeff Andich]

When you type ls /dev/ttyO* on your new BeagleBone, what do you get??

I assume nothing... 

TI switched the default serial driver back in (??) from OMAP (ttyOn) to the 
8250 driver, ttySn. I believe the rationalle is documented in the kernel 
source code for the driver and other places.  

You should be able to switch back to the old OMAP serial drivers with the 
later kernels, but you have to re-build the kernel... There are other posts 
on here (beagleboard.og) describing part of that procedure.

Thanks!



On Tuesday, March 20, 2018 at 10:44:21 AM UTC-5, Fohnbit wrote:
>
> Hello,
>
> I setup a new beaglebone black and use a own cape.
> I use UART4 ... at my old beaglebone, I put the cape on, start my software 
> and it is working.
>
> On the new Beagelbone i get no communication with my cape.
>
> I communicate via ser2net ... this is working on many boards without 
> problems.
>
> I see ttyO4 in the /dev folder.
>
> ser2net.conf I copy from old beaglebone and I can connect to the IP:port 
> ... but no communication.
> Baudrate is 57600
>
> Are the new Debian Images different to someone from 2015?
>
> Is there a hind to bring ttyO4 working or is it blocked?
>
> Thank you!
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/4d7d6713-ccee-4b62-8813-3a3204dabd7e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Custom Brd Kern. Boot - Get "Unable to handle kernel paging request at virtual..." Occasionaly

[Jeff Andich]

Hi,

We just got our re-worked custom boards back from the fab house with the 
5728, and on one of the boards on 1/6 power-ups, I got ".. Unable to handle 
kernel paging request at virtual address 2248 ... and at ffec." I 
THINK this occurs when Debian is being mounted as we normally see Debian 
messages after the vpe: couldn't get firmware in the case of a successful 
boot.  I'm not sure if this is a kernel crash, kernel panic, or a "kernel 
OOPS."

Following is the console log:



Starting kernel ...

[0.064925] /cpus/cpu@0 missing clock-frequency property
[0.064945] /cpus/cpu@1 missing clock-frequency property
[1.233031] dra7-pcie 5100.pcie_rc: link is not up
[1.599305] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr25 mode
[1.605719] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr12 mode
[1.701868] omap_voltage_late_init: Voltage driver support not added
[2.008531] rtc-ds1307 2-006f: hctosys: unable to read the hardware clock
Loading, please wait...
[2.792302] mmc2: error -22 whilst initialising SDIO card
[3.231127]  remoteproc0: failed to load am57xx-pru1_0-fw
[3.242998]  remoteproc0: request_firmware failed: -2
[3.248093] pru-rproc 4b234000.pru0: rproc_boot failed
[3.258661]  remoteproc0: failed to load am57xx-pru1_1-fw
[3.264779]  remoteproc0: request_firmware failed: -2
[3.269886] pru-rproc 4b238000.pru1: rproc_boot failed
[3.291919]  remoteproc0: failed to load am57xx-pru2_0-fw
[3.299798]  remoteproc0: request_firmware failed: -2
[3.304910] pru-rproc 4b2b4000.pru0: rproc_boot failed
[3.328397]  remoteproc0: failed to load am57xx-pru2_1-fw
[3.339743]  remoteproc0: request_firmware failed: -2
[3.344842] pru-rproc 4b2b8000.pru1: rproc_boot failed
rootfs: clean, 43747/232320 files, 390493/967040 blocks
[6.063694]  remoteproc0: failed to load dra7-ipu1-fw.xem4
[6.069850]  remoteproc1: failed to load dra7-ipu2-fw.xem4
[6.075464]  remoteproc2: failed to load dra7-dsp1-fw.xe66
[6.081735]  remoteproc3: failed to load dra7-dsp2-fw.xe66
[6.730836] pixcir_ts 4-005c: pixcir_set_power_mode: can't read reg 0x33 
: -121
[6.738239] pixcir_ts 4-005c: Failed to set IDLE mode
[7.021310] vpe 489d.vpe: couldn't get firmware

**  LOOK HERE 
*
[9.999478] Unable to handle kernel paging request at virtual address 
2248

[   0.006772] pgd = c0004000

[   10.009402] [2248] *pgd=

[   10.013025] Internal error: Oops: 17 [#1] SMP ARM

[   10.017747] Modules linked in: snd_soc_simple_card etnaviv 
snd_soc_omap_hdmi_audio ftdi_sio usbseris

[   10.057143] CPU: 1 PID: 6 Comm: kworker/u4:0 Not tainted 4.4.110-ti-r142 
#9
[   10.064128] Hardware name: Generic DRA74X (Flattened Device Tree)
[   10.070251] Workqueue: events_unbound flush_to_ldisc
[   10.075238] task: ee16a080 ti: ee188000 task.ti: ee188000

[   10.080657] PC is at n_tty_receive_buf_common+0x84/0xa68

[   10.085991] LR is at down_read+0x1c/0x4c
[   10.089926] pc : []lr : []psr: 200f0013
[   10.089926] sp : ee189e18  ip : ee189e00  fp : ee189e84
[   10.101449] r10: ed4b7c00  r9 : ee03d000  r8 : ee03d014
[   10.106691] r7 : ed4b7c00  r6 : ed4b7d84  r5 : ed4b7c80  r4 : c0af0c30
[   10.113241] r3 : 2000  r2 :   r1 : ee69e0a0  r0 : 
[   10.119793] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment 
none
[   10.126954] Control: 10c5387d  Table: ad53c06a  DAC: 0051
[   10.132720] Process kworker/u4:0 (pid: 6, stack limit = 0xee188218)
[   10.139009] Stack: (0xee189e18 to 0xee18a000)
[   10.143380] 9e00:  
 ed4b7c80 ee189e28
[   10.151589] 9e20: c00867a4 00020001 ed4b7d84 5556 ee16a44c c1011a48 
c0af0c30 c100d300
[   10.159798] 9e40: 2000   ee69e0a0 0003  
ee189e8c ee69e000
[   10.168008] 9e60: 0001 ee03d004 ed4b7c00 ee03d014 ee03d000 c0676d4c 
ee189e9c ee189e88
[   10.184425] 9ea0: c0aac9a0 ee5b09c0 ee189ed4 ee03d004 ee0b5f80 ee03fc00 
 ee022b00
[   10.192635] 9ec0: c10e5fd8 ee022b05 ee189f14 ee189ed8 c005fee4 c067a968 
ee188000 c0061030
[   10.200846] 9ee0: ee189efc  c0061030 ee0b5f80 ee0b5f98 ee03fc00 
0088 ee03fc14
[   10.209055] 9f00: ee188000 ee03fc00 ee189f54 ee189f18 c0060284 c005fd9c 
c1033e04 c0d48010
[   10.217264] 9f20: ee188000 c10e5bb9   ee0b7400 ee188000 
ee0b5f80 c0060224
[   10.225473] 9f40:   ee189fac ee189f58 c00664a8 c0060230 
 2dd1a000
[   10.233683] 9f60: ee0b5f80   ee189f6c ee189f6c  
 ee189f7c
[   10.241892] 9f80: ee189f7c dc8ba66e c00747b4 ee0b7400 c0066390  
 
[   10.250101] 9fa0:  ee189fb0 c0010ef8 c006639c   
 
[   10.258310] 9fc0:       
 

Re: [beagleboard] Reading Image with Win32 Disk Imager - Why Does Boot Get Copied with Read Only Allocated Partitions

[Jeff Andich]

Thanks Robert!.

I wasn't sure what that README statement meant either.

Maybe there's somewhere where a bug report can be issued against their 
documentation to clarify...

Regards and see y'all in P.O.



On Thursday, March 8, 2018 at 2:05:00 PM UTC-6, RobertCNelson wrote:
>
> On Thu, Mar 8, 2018 at 1:58 PM, Jeff Andich <jeff@gmail.com 
> > wrote: 
> > Hi, 
> > 
> > I was needing a utility to read/clone an SD card without copying all of 
> the 
> > additional wasted space on an SD card like the original Win32 Disk 
> Imager 
> > Does.  From what I can tell, the latest Etcher for Windows only writes 
> to SD 
> > card. 
> > 
> > So I just tried the latest Win32 Disk Imager which now has a checkbox, 
> "Read 
> > Only Allocated Partitions."  With the beaglebone/beagleboard images, I 
> > thought (in order to clone an SD card image without wasted space) for 
> sure 
> > that with the structure of the BeagleBone/BeagleBoard images having a 
> single 
> > ext4 partition and then MLO/u-boot in the "holes" below the partition 
> > somewhere, I would have to: 
> > 
> > 1) upload/read just the ext4 partition, clicking the Read Only Allocated 
> > Partition checkbox with Win32 Disk Imager 
> > 2) Write that uploaded partition to the target SD card. 
> > 3) Re-'dd' MLO and u-boot to the target SD card. 
> > 
> > But low and behold, I tried booting my board after step #2, and it boots 
> > with my modified MLO.. 
> > 
> > Either Win32 Disk imager, when you click that checkbox, is reading from 
> the 
> > start of the SD card to the end of the ext4 partition (and not reading 
> past 
> > that point), or something else is going on. 
> > 
> > Why is the MLO/u-boot which reside in the "holes" copied as well? 
> > 
> > 
> > Granted, I didn't google this in advance, so if this has already been 
> > discussed somewhere, then please don't answer... 
>
> From their readme: 
>
> "Read Only Allocated Partitions - Option to read only to the end of 
> the defined partition(s).  Ex:  Write a 2G image to a 32G device, 
> reading it to a new file will only read to the end of 
> the defined partition (2G)." 
>
> My guess, it starts from zero -> end of partition... Not the start of 
> the partition.. 
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/58bc5aaa-c262-41c4-8045-c7aedda20ba8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Reading Image with Win32 Disk Imager - Why Does Boot Get Copied with Read Only Allocated Partitions

[Jeff Andich]

Hi,

I was needing a utility to read/clone an SD card without copying all of the 
additional wasted space on an SD card like the original Win32 Disk Imager 
Does.  From what I can tell, the latest Etcher for Windows only writes to 
SD card.

So I just tried the latest Win32 Disk Imager which now has a checkbox, 
"Read Only Allocated Partitions."  With the beaglebone/beagleboard images, 
I thought (in order to clone an SD card image without wasted space) for 
sure that with the structure of the BeagleBone/BeagleBoard images having a 
single ext4 partition and then MLO/u-boot in the "holes" below the 
partition somewhere, I would have to:

1) upload/read just the ext4 partition, clicking the Read Only Allocated 
Partition checkbox with Win32 Disk Imager
2) Write that uploaded partition to the target SD card.
3) Re-'dd' MLO and u-boot to the target SD card.

But low and behold, I tried booting my board after step #2, and it boots 
with my modified MLO..

Either Win32 Disk imager, when you click that checkbox, is reading from the 
start of the SD card to the end of the ext4 partition (and not reading past 
that point), or something else is going on. 

Why is the MLO/u-boot which reside in the "holes" copied as well?


Granted, I didn't google this in advance, so if this has already been 
discussed somewhere, then please don't answer...

Thanks!

Jeff

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/d2dfa178-f6a4-45a8-b086-8e86cb263d56%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Custom Board doesnt run with Angström Image

[Jeff Andich]

I just did a 10 second google and it appears like tda998x is related to 
HDMI which you pulled from your board.

Just a couple of basic questions:

1) Did you remove the HDMI from either/both the u-boot pinmux and/or the 
cape manager?

2) If you start with a console image, does this yield the same result?  

I'm assuming that the console image doesn't access the HDMI port, but I DID 
see what appeared to be plain text appear on the HDMI port before X-windows 
started up on an LXQT image, so I could be mistaken..



On Wednesday, March 7, 2018 at 4:13:27 AM UTC-6, El Smiedro wrote:
>
> Hello community,
>
> I use the Angström Image v2012.12 - Kernel 3.8.13 with U-Boot SPL 
> 2013.04-dirty (Jun 19 2013 - 09:57:14) and I can login on my BBB. 
>
> I also try to run a custom board similar to the BBB. I only removed the 
> HDMI part and use a MT41K256M16TW-107 ITP DDR3. When I try to boot, it 
> stops while running the kernel:
>
> Code hier eingeben...
> U-Boot SPL 2013.04-dirty (Jun 19 2013 - 09:57:14)
> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, 
> SoftConn)
> musb-hdrc: MHDRC RTL version 2.0
> musb-hdrc: setup fifo_mode 4
> musb-hdrc: 28/31 max ep, 16384/16384 memory
> USB Peripheral mode controller at 47401000 using PIO, IRQ 0
> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, 
> SoftConn)
> musb-hdrc: MHDRC RTL version 2.0
> musb-hdrc: setup fifo_mode 4
> musb-hdrc: 28/31 max ep, 16384/16384 memory
> USB Host mode controller at 47401800 using PIO, IRQ 0
> OMAP SD/MMC: 0
> reading u-boot.img
> reading u-boot.img
>
>
> U-Boot 2013.04-dirty (Jun 19 2013 - 09:57:14)
>
> I2C:   ready
> DRAM:  512 MiB
> WARNING: Caches not enabled
> NAND:  No NAND device found!!!
> 0 MiB
> MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
> *** Warning - readenv() failed, using default environment
>
> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, 
> SoftConn)
> musb-hdrc: MHDRC RTL version 2.0
> musb-hdrc: setup fifo_mode 4
> musb-hdrc: 28/31 max ep, 16384/16384 memory
> USB Peripheral mode controller at 47401000 using PIO, IRQ 0
> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, 
> SoftConn)
> musb-hdrc: MHDRC RTL version 2.0
> musb-hdrc: setup fifo_mode 4
> musb-hdrc: 28/31 max ep, 16384/16384 memory
> USB Host mode controller at 47401800 using PIO, IRQ 0
> Net:not set. Validating first E-fuse MAC
> cpsw, usb_ether
> Hit any key to stop autoboot:  0
> gpio: pin 53 (gpio 53) value is 1
> mmc0 is current device
> micro SD card found
> mmc0 is current device
> gpio: pin 54 (gpio 54) value is 1
> SD/MMC found on device 0
> reading uEnv.txt
> 33 bytes read in 3 ms (10.7 KiB/s)
> Loaded environment from uEnv.txt
> Importing environment from mmc ...
> gpio: pin 55 (gpio 55) value is 1
> 4270840 bytes read in 770 ms (5.3 MiB/s)
> gpio: pin 56 (gpio 56) value is 1
> 24129 bytes read in 49 ms (480.5 KiB/s)
> Booting from mmc ...
> ## Booting kernel from Legacy Image at 80007fc0 ...
>Image Name:   Angstrom/3.8.13/beaglebone
>Image Type:   ARM Linux Kernel Image (uncompressed)
>Data Size:4270776 Bytes = 4.1 MiB
>Load Address: 80008000
>Entry Point:  80008000
>Verifying Checksum ... OK
> ## Flattened Device Tree blob at 80f8
>Booting using the fdt blob at 0x80f8
>XIP Kernel Image ... OK
> OK
>Using Device Tree in place at 80f8, end 80f88e40
>
> Starting kernel ...
>
> Uncompressing Linux... done, booting the kernel.
> [0.19] omap2_mbox_probe: platform not supported
> [0.204990] tps65217-bl tps65217-bl: no platform data provided
> [0.281512] bone-capemgr bone_capemgr.8: slot #0: No cape found
> [0.318618] bone-capemgr bone_capemgr.8: slot #1: No cape found
> [0.355726] bone-capemgr bone_capemgr.8: slot #2: No cape found
> [0.392836] bone-capemgr bone_capemgr.8: slot #3: No cape found
> [0.412862] bone-capemgr bone_capemgr.8: slot #6: BB-BONELT-HDMIN 
> conflict P8   .45 (#5:BB-BONELT-HDMI)
> [0.422487] bone-capemgr bone_capemgr.8: slot #6: Failed verification
> [0.429266] bone-capemgr bone_capemgr.8: loader: failed to load slot-6 
> BB-BON   ELT-HDMIN:00A0 (prio 2)
> [0.451930] omap_hsmmc mmc.4: of_parse_phandle_with_args of 'reset' 
> failed
> [0.516301] pinctrl-single 44e10800.pinmux: pin 44e10854 already 
> requested by44e10800.pinmux; cannot 
> claim for gpio-leds.7
> [0.528016] pinctrl-single 44e10800.pinmux: pin-21 (gpio-leds.7) 
> status -22
> [0.535334] pinctrl-single 44e10800.pinmux: could not request pin 21 
> on devic   e pinctrl-single
> [0.568496] dummy 0-0034: Error -121 writing to cec:0xff
> [0.574309] tda998x 0-0070: Error -121 reading from 0xa
> [0.580038] tda998x 0-0070: Error -121 writing to 0xa
> [0.637061] tda998x 0-0070: Error -121 reading from 0xa
> [0.642639] tda998x 0-0070: Error 

Re: [beagleboard] Re: RS485 support for BBB

[Jeff Andich]

Hi there.  Got your PM..

Regarding the defconfig changes to enable the OMAP.

I THINK your prescribed changes to the defconfig file are correct, just 
please refer to the above thread, 
https://groups.google.com/forum/#!topic/beagleboard/JGIm0Ej6jDI.

You're going to need to tune the defconfig, and the re-build and deploy the 
kernel until you see /dev/ttyO*.  And then you'll need to check that the 
serial device of interest is enabled.  You can go into /sys/class/tty/ttyO* 
directory and start looking at things like irq #'s to make sure they're 
non-0.  Not sure how this changes if DMA is enabled.
 
One interesting thing.  If you want to enable UARTs (beyond #6), I found 
that with the OMAP driver, all you need to do is enable it in the device 
tree fragement.  But with the 8250 driver, you need to change another 
defconfig define to increase the total # of UARTs..

Regarding updating/building the kernel on the BBB (?? 
/opt/scripts/tools/update_kernel.sh??), I'm afraid I still haven't done 
this or used Robert's image Builder on target.  I hope to get some practice 
with that next-week.  Then I can hopefully speak more intelligently on that.

To build/re-build the kernel, I follow the instructions on how to fetch and 
build the kernel, 
here, https://eewiki.net/display/linuxonarm/BeagleBoard-X15.

And then, inintially I call root_kernel_build_dir/build_kernel.sh, 
allow makemenuconfig to run.
Set the defconfig options I need.
Then every subsequent build, I think you can call 
root_kernel_build_dir/tools/rebuild.sh which will leave your 
defconfig/.config file in tact.  
I promise I won't tell anyone if you modify, KERNEL/.config directly, but I 
think this is not the recommended procedure.

Regarding and updated OS for 485, I'm not aware of any.  If you compile in 
the OMAP serial driver, then the driver has a 485 interface, so you can add 
lines to the respective UART's fragment such as the following and the 
referenced gpio line in the fragement below will toggle when you do 
setRTS(True/False) in python-serial.  

This won't work with the 8250 serial driver.  However, what will work with 
the 8250 driver is if you allocate a dedicated uart5_rtsn line and then tie 
that to your DE input on a 485 chip, you will be able to call 
setRTS(True/False) from Python (and I assume C/C++/C#), and the line will 
actually change state.  But I don't think the 8250 driver will handle the 
automatic flow control with intercharacter timeouts needed for full 
hardware flow control.  I haven't tried this.

Also another question you need to ask is for 485, are you using 2-wire or 
4-wire RS485 chips.  If 4-wire, then, depending on your application, you 
maybe able to tie the DE signal high and allow the 485 chip to operate in 
full-duplex mode.  If 2 wire, then presumably, someone will need to toggle 
the DE line to multiplex internally the BBB UART's Rxd vs Txd onto the 
differential signal end of the 485 chip.  For our purposes, since our 
application knows when its transmitting vs receiving, the application can 
toggle the RTS line around transmit and receive sentences/packets.

Another thing I don't yet know.  Say that your application program refuses 
to add toggling of the RTS line between transmit and receive packets and 
s/he wants you to handle this at the driver level (which is understandable 
given application software portability requirements).  What all do you need 
to implement for the OMAP serial driver and the UART to handle automatic 
toggling of the RTS line so that the driver "senses" when the transmitter 
is done transmitting and can then toggle RTS/CTS to allow the other party 
to speak on the half-duplex line?  Do you need to wire up DE to UARTn_RTS 
and DE_INV to UARTn_CTS or can you leave CTS floating (or tie it to a known 
state if your mux mode permits)?  If someone has tried this (granted 
hardware flow control is probably an anachronism), please chime in.  But 
the test data probably exists somewhere in this thread or a related thread 
on this forum.
 


 {
pinctrl-names = "default";
pinctrl-0 = <_pins>;
status = "okay";
rts-gpio = < 8 GPIO_ACTIVE_HIGH>;
rs485-rts-active-high;
rs485-rts-delay = <0 0>;
linux,rs485-enabled-at-boot-time;
};

On Tuesday, March 6, 2018 at 8:12:41 AM UTC-6, Jeff Andich wrote:
>
> p.s. - I'm currently running a patched version of kernel version 
> 4.4.110... for the BB-X15, but I believe the underlying principles are the 
> same between the BBB and BB-X15 with respect to UART (except for the pinmux 
> which is more straight forward to configure in BBB world).
>
> On Monday, March 5, 2018 at 9:12:06 AM UTC-6, Jeff Andich wrote:
>>
>> Hi,
>>
>> There have been a number of posts on here on how to switch between the 
>> 8250 and OMAP drivers.  Above in this same thread, Robert showed which 
>> defines within th

Re: [beagleboard] Re: RS485 support for BBB

[Jeff Andich]

p.s. - I'm currently running a patched version of kernel version 4.4.110... 
for the BB-X15, but I believe the underlying principles are the same 
between the BBB and BB-X15 with respect to UART (except for the pinmux 
which is more straight forward to configure in BBB world).

On Monday, March 5, 2018 at 9:12:06 AM UTC-6, Jeff Andich wrote:
>
> Hi,
>
> There have been a number of posts on here on how to switch between the 
> 8250 and OMAP drivers.  Above in this same thread, Robert showed which 
> defines within the kernel defconfig file to change, and I experimented with 
> this and was able to see and use /dev/ttyO* instead of /dev/ttyS*.  I had 
> to search for and swtich additional defines, as initially, I ended-up 
> losing my console and still had /dev/ttyS*..  If you look through the 
> following post, you can see how I switched from the 8250 to the OMAP 
> driver.   Someone else on here proposed a way to have a mixture of OMAP and 
> 8250 serial drivers, but I haven't been brave enough to try that yet.
>
> https://groups.google.com/forum/#!topic/beagleboard/JGIm0Ej6jDI
>
> I never attempted to get full-blown hardware flow control up and running, 
> since our hardware board has RS485 chips which only have the DE pin 
> connected.  RTS and CTS lines don't interconnect the different parties on 
> the MODBUS network in our case, only the RS485 differential signals (e.g. 
> TXp, TXn).  
>
> Initially we connected GPIO lines to the DE pins, but then more recently, 
> our hardware engineer swapped out GPIO lines for the  "dedicated RTS" line 
> for a given UART.  
>
> One thing that's really interesting, IMO, is if you use a dedicated RTS 
> line (e.g. UART5 RTSn), you can still toggle RTS from the application layer 
> **using the 8250 driver**.  Whereas when I attempted to use  a GPIO line 
> and couple that to the UART through the UART device tree fragment (refer to 
> the above thread for an example), I was not able to toggle the RTS line 
> with the 8250 serial driver, but only the OMAP serial driver.  So as a test 
> I installed python-serial on my beagleBoard-X15.  When I issued 
> serial_object.setRTS(False/True) which was connected to DE on the 485 chip, 
> I would see the chip transmit and not transmit using the 8250 driver.  But 
> when using the GPIO line for RTS, I could only switch between transmit and 
> receive on the 485 chip when I compiled in and used the OMAP drivers.
>
> On Monday, March 5, 2018 at 7:12:50 AM UTC-6, erc...@gmail.com wrote:
>>
>> Hi Micka,
>>
>> We are having lots of trouble with RS485 with Kernel 4.4.x or kernel 
>> 3.8.13.
>>
>> Is there any guideline about how to use OMAP rather than 8250 or can you 
>> please explain the steps how can we do that?
>>
>> On Tuesday, April 26, 2016 at 10:00:19 AM UTC+3, Micka wrote:
>>>
>>> I dont know about 8250, but omap work well. I'm more confident about 
>>> omap handling the gpio than the driver 8250.
>>>
>>> I've been using omap for rs485 since the driver 3.8 and I've nothing to 
>>> complain about. 
>>>
>>> I will also switch to the driver 8250 when it will be ready ( a lot of 
>>> test need to be done )
>>>
>>>
>>> Micka,
>>>
>>>
>>>
>>> Le mar. 26 avr. 2016 08:05, 'Artur Festyn' via BeagleBoard <
>>> beagl...@googlegroups.com> a écrit :
>>>
>>>> Hi Micka.
>>>> no ttyO, its 8250 driver.
>>>> shouldn't 4.5 kernel work after these patches are applied or is it 
>>>> still too early?
>>>>
>>>> -rw-r--r--  1 root root 1440 Apr 21 12:26 
>>>> 0001-tty-serial-8250-fix-RS485-half-duplex-RX.patch
>>>> -rw-r--r--  1 root root 8243 Apr 21 12:26 
>>>> 0002-tty-serial-8250-make-UART_MCR-register-access-consis.patch
>>>> -rw-r--r--  1 root root 2743 Apr 21 12:26 
>>>> 0003-serial-mctrl_gpio-add-modem-control-read-routine.patch
>>>> -rw-r--r--  1 root root 1347 Apr 21 12:26 
>>>> 0004-serial-mctrl_gpio-add-IRQ-locking.patch
>>>> -rw-r--r--  1 root root 7924 Apr 21 12:26 
>>>> 0005-tty-serial-8250-use-mctrl_gpio-helpers.patch
>>>>
>>>> the last one clearly states that use of any gpio as rts should be 
>>>> possible
>>>>
>>>>
>>>> 2016-04-26 6:54 GMT+01:00 Micka <micka...@gmail.com>:
>>>>
>>>>> Can you show me what this command show : 
>>>>>
>>>>> dmesg|grep ttyO*
>>>>>
>>>>> I repeat only omap driver work for rs485
>>>>>
>>>&

Re: [beagleboard] Re: RS485 support for BBB

[Jeff Andich]

p.s. - I'm currently running a patched version of kernel version 4.4.110...


On Monday, March 5, 2018 at 9:12:06 AM UTC-6, Jeff Andich wrote:
>
> Hi,
>
> There have been a number of posts on here on how to switch between the 
> 8250 and OMAP drivers.  Above in this same thread, Robert showed which 
> defines within the kernel defconfig file to change, and I experimented with 
> this and was able to see and use /dev/ttyO* instead of /dev/ttyS*.  I had 
> to search for and swtich additional defines, as initially, I ended-up 
> losing my console and still had /dev/ttyS*..  If you look through the 
> following post, you can see how I switched from the 8250 to the OMAP 
> driver.   Someone else on here proposed a way to have a mixture of OMAP and 
> 8250 serial drivers, but I haven't been brave enough to try that yet.
>
> https://groups.google.com/forum/#!topic/beagleboard/JGIm0Ej6jDI
>
> I never attempted to get full-blown hardware flow control up and running, 
> since our hardware board has RS485 chips which only have the DE pin 
> connected.  RTS and CTS lines don't interconnect the different parties on 
> the MODBUS network in our case, only the RS485 differential signals (e.g. 
> TXp, TXn).  
>
> Initially we connected GPIO lines to the DE pins, but then more recently, 
> our hardware engineer swapped out GPIO lines for the  "dedicated RTS" line 
> for a given UART.  
>
> One thing that's really interesting, IMO, is if you use a dedicated RTS 
> line (e.g. UART5 RTSn), you can still toggle RTS from the application layer 
> **using the 8250 driver**.  Whereas when I attempted to use  a GPIO line 
> and couple that to the UART through the UART device tree fragment (refer to 
> the above thread for an example), I was not able to toggle the RTS line 
> with the 8250 serial driver, but only the OMAP serial driver.  So as a test 
> I installed python-serial on my beagleBoard-X15.  When I issued 
> serial_object.setRTS(False/True) which was connected to DE on the 485 chip, 
> I would see the chip transmit and not transmit using the 8250 driver.  But 
> when using the GPIO line for RTS, I could only switch between transmit and 
> receive on the 485 chip when I compiled in and used the OMAP drivers.
>
> On Monday, March 5, 2018 at 7:12:50 AM UTC-6, erc...@gmail.com wrote:
>>
>> Hi Micka,
>>
>> We are having lots of trouble with RS485 with Kernel 4.4.x or kernel 
>> 3.8.13.
>>
>> Is there any guideline about how to use OMAP rather than 8250 or can you 
>> please explain the steps how can we do that?
>>
>> On Tuesday, April 26, 2016 at 10:00:19 AM UTC+3, Micka wrote:
>>>
>>> I dont know about 8250, but omap work well. I'm more confident about 
>>> omap handling the gpio than the driver 8250.
>>>
>>> I've been using omap for rs485 since the driver 3.8 and I've nothing to 
>>> complain about. 
>>>
>>> I will also switch to the driver 8250 when it will be ready ( a lot of 
>>> test need to be done )
>>>
>>>
>>> Micka,
>>>
>>>
>>>
>>> Le mar. 26 avr. 2016 08:05, 'Artur Festyn' via BeagleBoard <
>>> beagl...@googlegroups.com> a écrit :
>>>
>>>> Hi Micka.
>>>> no ttyO, its 8250 driver.
>>>> shouldn't 4.5 kernel work after these patches are applied or is it 
>>>> still too early?
>>>>
>>>> -rw-r--r--  1 root root 1440 Apr 21 12:26 
>>>> 0001-tty-serial-8250-fix-RS485-half-duplex-RX.patch
>>>> -rw-r--r--  1 root root 8243 Apr 21 12:26 
>>>> 0002-tty-serial-8250-make-UART_MCR-register-access-consis.patch
>>>> -rw-r--r--  1 root root 2743 Apr 21 12:26 
>>>> 0003-serial-mctrl_gpio-add-modem-control-read-routine.patch
>>>> -rw-r--r--  1 root root 1347 Apr 21 12:26 
>>>> 0004-serial-mctrl_gpio-add-IRQ-locking.patch
>>>> -rw-r--r--  1 root root 7924 Apr 21 12:26 
>>>> 0005-tty-serial-8250-use-mctrl_gpio-helpers.patch
>>>>
>>>> the last one clearly states that use of any gpio as rts should be 
>>>> possible
>>>>
>>>>
>>>> 2016-04-26 6:54 GMT+01:00 Micka <micka...@gmail.com>:
>>>>
>>>>> Can you show me what this command show : 
>>>>>
>>>>> dmesg|grep ttyO*
>>>>>
>>>>> I repeat only omap driver work for rs485
>>>>>
>>>>> Le mar. 26 avr. 2016 00:40, 'Artur Festyn' via BeagleBoard <
>>>>> beagl...@googlegroups.com> a écrit :
>>>>>
>>>>>> It is easy and already disabl

Re: [beagleboard] Re: RS485 support for BBB

[Jeff Andich]

Hi,

There have been a number of posts on here on how to switch between the 8250 
and OMAP drivers.  Above in this same thread, Robert showed which defines 
within the kernel defconfig file to change, and I experimented with this 
and was able to see and use /dev/ttyO* instead of /dev/ttyS*.  I had to 
search for and swtich additional defines, as initially, I ended-up losing 
my console and still had /dev/ttyS*..  If you look through the following 
post, you can see how I switched from the 8250 to the OMAP driver.  
 Someone else on here proposed a way to have a mixture of OMAP and 8250 
serial drivers, but I haven't been brave enough to try that yet.

https://groups.google.com/forum/#!topic/beagleboard/JGIm0Ej6jDI

I never attempted to get full-blown hardware flow control up and running, 
since our hardware board has RS485 chips which only have the DE pin 
connected.  RTS and CTS lines don't interconnect the different parties on 
the MODBUS network in our case, only the RS485 differential signals (e.g. 
TXp, TXn).  

Initially we connected GPIO lines to the DE pins, but then more recently, 
our hardware engineer swapped out GPIO lines for the  "dedicated RTS" line 
for a given UART.  

One thing that's really interesting, IMO, is if you use a dedicated RTS 
line (e.g. UART5 RTSn), you can still toggle RTS from the application layer 
**using the 8250 driver**.  Whereas when I attempted to use  a GPIO line 
and couple that to the UART through the UART device tree fragment (refer to 
the above thread for an example), I was not able to toggle the RTS line 
with the 8250 serial driver, but only the OMAP serial driver.  So as a test 
I installed python-serial on my beagleBoard-X15.  When I issued 
serial_object.setRTS(False/True) which was connected to DE on the 485 chip, 
I would see the chip transmit and not transmit using the 8250 driver.  But 
when using the GPIO line for RTS, I could only switch between transmit and 
receive on the 485 chip when I compiled in and used the OMAP drivers.

On Monday, March 5, 2018 at 7:12:50 AM UTC-6, erc...@gmail.com wrote:
>
> Hi Micka,
>
> We are having lots of trouble with RS485 with Kernel 4.4.x or kernel 
> 3.8.13.
>
> Is there any guideline about how to use OMAP rather than 8250 or can you 
> please explain the steps how can we do that?
>
> On Tuesday, April 26, 2016 at 10:00:19 AM UTC+3, Micka wrote:
>>
>> I dont know about 8250, but omap work well. I'm more confident about omap 
>> handling the gpio than the driver 8250.
>>
>> I've been using omap for rs485 since the driver 3.8 and I've nothing to 
>> complain about. 
>>
>> I will also switch to the driver 8250 when it will be ready ( a lot of 
>> test need to be done )
>>
>>
>> Micka,
>>
>>
>>
>> Le mar. 26 avr. 2016 08:05, 'Artur Festyn' via BeagleBoard <
>> beagl...@googlegroups.com> a écrit :
>>
>>> Hi Micka.
>>> no ttyO, its 8250 driver.
>>> shouldn't 4.5 kernel work after these patches are applied or is it still 
>>> too early?
>>>
>>> -rw-r--r--  1 root root 1440 Apr 21 12:26 
>>> 0001-tty-serial-8250-fix-RS485-half-duplex-RX.patch
>>> -rw-r--r--  1 root root 8243 Apr 21 12:26 
>>> 0002-tty-serial-8250-make-UART_MCR-register-access-consis.patch
>>> -rw-r--r--  1 root root 2743 Apr 21 12:26 
>>> 0003-serial-mctrl_gpio-add-modem-control-read-routine.patch
>>> -rw-r--r--  1 root root 1347 Apr 21 12:26 
>>> 0004-serial-mctrl_gpio-add-IRQ-locking.patch
>>> -rw-r--r--  1 root root 7924 Apr 21 12:26 
>>> 0005-tty-serial-8250-use-mctrl_gpio-helpers.patch
>>>
>>> the last one clearly states that use of any gpio as rts should be 
>>> possible
>>>
>>>
>>> 2016-04-26 6:54 GMT+01:00 Micka :
>>>
 Can you show me what this command show : 

 dmesg|grep ttyO*

 I repeat only omap driver work for rs485

 Le mar. 26 avr. 2016 00:40, 'Artur Festyn' via BeagleBoard <
 beagl...@googlegroups.com> a écrit :

> It is easy and already disabled.
> My question is about RS485 and custom gpio to drive DE pin of RS485 
> chip.
>
>
> 2016-04-25 23:22 GMT+01:00 evilwulfie :
>
>> read this. disabling I2C2 is not as easy as using an overlay
>> if you are not using capes sure but IMHO is always best to leave the 
>> default things enabled and just work with overlays
>>
>>
>> http://www.embedded-things.com/bbb/enable-canbus-on-the-beaglebone-black/
>>
>>
>>
>>
>>
>> On 4/25/2016 2:09 PM, 'Artur Festyn' via BeagleBoard wrote:
>>
>> Honestly I don't know. I though this might be useful info :) 
>> Three is no problem to disable I2C-2, but I am using those pins for 
>> CAN0.
>> That is why I want to use custom gpio to drive RS485 DE which doesn't 
>> work.
>>
>> 2016-04-25 21:56 GMT+01:00 William Hermans :
>>
>>> *cat /proc/tty/driver/serial*
>>>
>>> *serinfo:1.0 driver revision:*
>>> *0: uart:8250 mmio:0x44E09000 irq:158 tx:2451 

Re: [beagleboard] Re: RS485 support for BBB

[Jeff Andich]

Hi,

There have been a number of posts on here on how to switch between the 8250 
and OMAP drivers.  Here's one post where Robert showed which defines within 
the kernel defconfig file to change, and I experimented with this and was 
able to see and use /dev/ttyO* instead of /dev/ttyS*.  I had to search for 
and swtich additional defines, as initially, I ended-up losing my console 
and still had /dev/ttyS*..

https://groups.google.com/forum/#!topic/beagleboard/JGIm0Ej6jDI

I never attempted to get full-blown hardware flow control up and running, 
since our hardware board has RS485 chips which only have the DE pin 
connected.  RTS and CTS lines don't interconnect the different parties on 
the MODBUS network in our case, only the RS485 differential signals (e.g. 
TXp, TXn).  

Initially we connected GPIO lines to the DE pins, but then more recently, 
our hardware engineer swapped out GPIO lines for the  "dedicated RTS" line 
for a given UART.  

One thing that's really interesting, IMO, is if you use a dedicated RTS 
line (e.g. UART5 RTSn), you can still toggle RTS from the application layer 
**using the 8250 driver**.  Whereas when I attempted to use  a GPIO line 
and couple that to the UART through the UART device tree fragment (refer to 
the above thread for an example), I was not able to toggle the RTS line 
with the 8250 serial driver, but only the OMAP serial driver.  So as a test 
I installed python-serial on my beagleBoard-X15.  When I issued 
serial_object.setRTS(False/True) which was connected to DE on the 485 chip, 
I would see the chip transmit and not transmit using the 8250 driver.  But 
when using the GPIO line for RTS, I could only switch between transmit and 
receive on the 485 chip when I compiled in and used the OMAP drivers.





On Monday, March 5, 2018 at 7:12:50 AM UTC-6, erc...@gmail.com wrote:
>
> Hi Micka,
>
> We are having lots of trouble with RS485 with Kernel 4.4.x or kernel 
> 3.8.13.
>
> Is there any guideline about how to use OMAP rather than 8250 or can you 
> please explain the steps how can we do that?
>
> On Tuesday, April 26, 2016 at 10:00:19 AM UTC+3, Micka wrote:
>>
>> I dont know about 8250, but omap work well. I'm more confident about omap 
>> handling the gpio than the driver 8250.
>>
>> I've been using omap for rs485 since the driver 3.8 and I've nothing to 
>> complain about. 
>>
>> I will also switch to the driver 8250 when it will be ready ( a lot of 
>> test need to be done )
>>
>>
>> Micka,
>>
>>
>>
>> Le mar. 26 avr. 2016 08:05, 'Artur Festyn' via BeagleBoard <
>> beagl...@googlegroups.com> a écrit :
>>
>>> Hi Micka.
>>> no ttyO, its 8250 driver.
>>> shouldn't 4.5 kernel work after these patches are applied or is it still 
>>> too early?
>>>
>>> -rw-r--r--  1 root root 1440 Apr 21 12:26 
>>> 0001-tty-serial-8250-fix-RS485-half-duplex-RX.patch
>>> -rw-r--r--  1 root root 8243 Apr 21 12:26 
>>> 0002-tty-serial-8250-make-UART_MCR-register-access-consis.patch
>>> -rw-r--r--  1 root root 2743 Apr 21 12:26 
>>> 0003-serial-mctrl_gpio-add-modem-control-read-routine.patch
>>> -rw-r--r--  1 root root 1347 Apr 21 12:26 
>>> 0004-serial-mctrl_gpio-add-IRQ-locking.patch
>>> -rw-r--r--  1 root root 7924 Apr 21 12:26 
>>> 0005-tty-serial-8250-use-mctrl_gpio-helpers.patch
>>>
>>> the last one clearly states that use of any gpio as rts should be 
>>> possible
>>>
>>>
>>> 2016-04-26 6:54 GMT+01:00 Micka :
>>>
 Can you show me what this command show : 

 dmesg|grep ttyO*

 I repeat only omap driver work for rs485

 Le mar. 26 avr. 2016 00:40, 'Artur Festyn' via BeagleBoard <
 beagl...@googlegroups.com> a écrit :

> It is easy and already disabled.
> My question is about RS485 and custom gpio to drive DE pin of RS485 
> chip.
>
>
> 2016-04-25 23:22 GMT+01:00 evilwulfie :
>
>> read this. disabling I2C2 is not as easy as using an overlay
>> if you are not using capes sure but IMHO is always best to leave the 
>> default things enabled and just work with overlays
>>
>>
>> http://www.embedded-things.com/bbb/enable-canbus-on-the-beaglebone-black/
>>
>>
>>
>>
>>
>> On 4/25/2016 2:09 PM, 'Artur Festyn' via BeagleBoard wrote:
>>
>> Honestly I don't know. I though this might be useful info :) 
>> Three is no problem to disable I2C-2, but I am using those pins for 
>> CAN0.
>> That is why I want to use custom gpio to drive RS485 DE which doesn't 
>> work.
>>
>> 2016-04-25 21:56 GMT+01:00 William Hermans :
>>
>>> *cat /proc/tty/driver/serial*
>>>
>>> *serinfo:1.0 driver revision:*
>>> *0: uart:8250 mmio:0x44E09000 irq:158 tx:2451 rx:0 RTS|CTS|DTR|DSR*
>>> *1: uart:8250 mmio:0x48022000 irq:159 tx:24 rx:0 CTS|DSR|CD|RI*
>>> *2: uart:8250 mmio:0x48024000 irq:160 tx:0 rx:0 CTS|DSR*
>>> *3: uart:unknown port: irq:0*
>>> *4: uart:8250 mmio:0x481A8000 

[beagleboard] Re: Yocto buil for PocketBeagle

[Jeff Andich]

Don't know if the TI processor SDK 
(http://www.ti.com/tool/PROCESSOR-SDK-AM335X) for the BBB will run on the 
pocket beagle, but last-I checked the  TI processor SDK follows the 
OE/Yocto paradigm.  I apologize for forgetting the differences between 
Yocto and OE. 

The SDK contains canned build scripts and the FS, but then then if you 
follow the TI wiki pages, there's a link to (if you want to develop your 
own filesystem) which then downloads the whole Arago distribution 
associated with that TI SDK version, where you get all of the Yocto layers 
and bitbake.  I tried building it several months ago, and had issues with a 
missing library from git.ti.com.  Plus if you're on a corporate LAN and 
your company firewall doesn't allow git via git://, then you'll have that 
to deal with.

First thing would be to find out of the am335x ti SDK runs on the pocket 
beagle..

If you're interested in pursuing, I could try to fish up some links on how 
to download the associated Arago distribution if you're unable to find 
them..


On Thursday, February 15, 2018 at 7:50:48 AM UTC-6, no...@vytopna.com wrote:
>
> Hello, we are developing custom system on OSD3358 with PocketBeagle as 
> development platform. We need to buld own small linux distribution. We try 
> Yocto for that, but we cannot boot to that image. We try projects with 
> rocko or master release with meta-ti layer and beaglebone as target. Image 
> recipe we try core-image-base. We succes with build and write wic file to 
> micro SD, there are 2 partitions, one FAT16 with MLO and u-boot and another 
> with root filesystem. Whenever put SD card to pocketbeagle and power up it, 
> nothing hapened, only power LED is lighting. Nothing is even on UART0. When 
> we try oficial image it is working.
> We try to write MLO and u-boot RAW to sd card, but nothing hapenes. Does 
> anyone have any experience with yocto and PocketBeagle?
>
> Thank for any advice.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/adfabd59-3a0a-495b-95ea-3dbac9581da0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Can't stat /proc/sys/vm & K Panic when Flashing eMMC while Running with a Kernel built from Source

[Jeff Andich]

f-0109-4b9b-8598-eb34ae259aca
Superblock backups stored on blocks: 
32768, 98304, 163840, 229376, 294912, 819200, 884736

Allocating group tables: done
Writing inode tables: done
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done 


==> Formatting rootfs: /dev/mmcblk1p1 complete
==> Creating temporary rootfs directory (/tmp/rootfs)
==> Mounting /dev/mmcblk1p1 to /tmp/rootfs
[   53.866332] EXT4-fs (mmcblk1p1): mounted filesystem with ordered data 
mode. Opts:)




Copying: Current rootfs to /dev/mmcblk1p1

==> rsync: / -> /tmp/rootfs

[   54.047765] random: nonblocking pool is initialized

==> Copying: Kernel modules
===> Creating directory for modules
===> rsync: /lib/modules/4.4.110-ti-r142/ -> 
/tmp/rootfs/lib/modules/4.4.110-ti-r142/

rsync: change_dir "/lib/modules/4.4.110-ti-r142" failed: No such file or 
directory ()
rsync error: some files/attrs were not transferred (see previous errors) 
(code 23) a]
writing to [/dev/mmcblk1] failed...





On Tuesday, February 13, 2018 at 5:25:57 PM UTC-6, RobertCNelson wrote:
>
> Weird, for now just nuke that sysctr setting, it's not mandatory, it fixed 
> some randomness on the bones, which have a quarter the memory of the x15..
>
> Regards,
>
> On Feb 13, 2018 5:17 PM, "Jeff Andich" <jeff@gmail.com > 
> wrote:
>
>> Hi,
>>
>> I burned a uSD card with 
>> bbx15-debian-8.10-console-armhf-2018-01-01-1gb.img.xz which I got from 
>> elinux.org.  The kernel which comes with that image is 4.4.91-ti-r141.  
>> But I have been building kernel version 4.4.110-ti-r142  from source 
>> following the instructions on eewiki.net for the BB-X15, and copying the 
>> kernel image, dtbs, and modules to that same uSD card which still has the 
>> stock kernel on it. Both kernel's appear to run just fine from uSD card 
>> when uname-r is changed in uEnv.txt.  
>>
>> But when I run try to run the eMMC flasher script with the 4.4.110 (built 
>> from source) kernel running instead of the "stock kernel" running the 
>> flasher script dies when /proc/sys/vm/min_free_kbytes isn't there and then 
>> you see a  kernel panic (please see console dump below).  However, when I 
>> switch the running kernel back to the stock kernel, 4.4.91-ti-r141 which 
>> came with that image, the eMMC flasher script again works.  I've tried 
>> running both, /opt/scripts/tools/eMMC/init-eMMC-flasher-v3-no-eeprom.sh 
>> and init-eMMC-flasher-v3-x15_b1.sh, both with the same result (I think).
>>
>> I'm wondering what other crucial step needs to be followed which I 
>> missed... I didn't touch the filesystem which was already part of the 
>> 2018-01-01 console BB-X15 image on that uSD card, but when I run "mount" on 
>> both kernels, I get differences (see below).
>>
>>
>> Please take a look at what I've posted below and give me some clues as to 
>> where to look or what to read up on next..
>>
>> Thanks!!
>>
>>
>>
>>
>> *When the kernel built from source (4.4.110) is running from uSD card, 
>> and I'm logged in as debian (or have typed sudo su from debian), I'm able 
>> to run /sbin/sysctl -n vm.min_free_kbytes both as "debian" and su.  So proc 
>> appears to be present on the 4.4.110 kernel running from uSD card once 
>> logged in:
>>
>> *When running both kernels from the uSD card, I ran "zcat 
>> /proc/config.gz" and the configurations were "pretty similar." (see diff 
>> below):
>>
>> < # Linux/arm 4.4.91 Kernel Configuration
>> ---
>> > # Linux/arm 4.4.110 Kernel Configuration
>> 1208a1209
>> > # CONFIG_NET_DSA is not set
>> 2809,2810c2810,2811
>> < CONFIG_SERIAL_8250_NR_UARTS=6
>> < CONFIG_SERIAL_8250_RUNTIME_UARTS=6
>> ---
>> > CONFIG_SERIAL_8250_NR_UARTS=9
>> > CONFIG_SERIAL_8250_RUNTIME_UARTS=9
>>
>>
>> *One thing that's different is the outputs of the "mount" command run on 
>> the two kernels: 
>>
>> > /dev/mmcblk0p1 on / type ext4 
>> (rw,relatime,errors=remount-ro,data=ordered)
>> > devtmpfs on /dev type devtmpfs 
>> (rw,rela

[beagleboard] Can't stat /proc/sys/vm & K Panic when Flashing eMMC while Running with a Kernel built from Source

[Jeff Andich]

Hi,

I burned a uSD card with 
bbx15-debian-8.10-console-armhf-2018-01-01-1gb.img.xz which I got from 
elinux.org.  The kernel which comes with that image is 4.4.91-ti-r141.  But 
I have been building kernel version 4.4.110-ti-r142  from source following 
the instructions on eewiki.net for the BB-X15, and copying the kernel 
image, dtbs, and modules to that same uSD card which still has the stock 
kernel on it. Both kernel's appear to run just fine from uSD card when 
uname-r is changed in uEnv.txt.  

But when I run try to run the eMMC flasher script with the 4.4.110 (built 
from source) kernel running instead of the "stock kernel" running the 
flasher script dies when /proc/sys/vm/min_free_kbytes isn't there and then 
you see a  kernel panic (please see console dump below).  However, when I 
switch the running kernel back to the stock kernel, 4.4.91-ti-r141 which 
came with that image, the eMMC flasher script again works.  I've tried 
running both, /opt/scripts/tools/eMMC/init-eMMC-flasher-v3-no-eeprom.sh 
and init-eMMC-flasher-v3-x15_b1.sh, both with the same result (I think).

I'm wondering what other crucial step needs to be followed which I 
missed... I didn't touch the filesystem which was already part of the 
2018-01-01 console BB-X15 image on that uSD card, but when I run "mount" on 
both kernels, I get differences (see below).


Please take a look at what I've posted below and give me some clues as to 
where to look or what to read up on next..

Thanks!!




*When the kernel built from source (4.4.110) is running from uSD card, and 
I'm logged in as debian (or have typed sudo su from debian), I'm able to 
run /sbin/sysctl -n vm.min_free_kbytes both as "debian" and su.  So proc 
appears to be present on the 4.4.110 kernel running from uSD card once 
logged in:

*When running both kernels from the uSD card, I ran "zcat /proc/config.gz" 
and the configurations were "pretty similar." (see diff below):

< # Linux/arm 4.4.91 Kernel Configuration
---
> # Linux/arm 4.4.110 Kernel Configuration
1208a1209
> # CONFIG_NET_DSA is not set
2809,2810c2810,2811
< CONFIG_SERIAL_8250_NR_UARTS=6
< CONFIG_SERIAL_8250_RUNTIME_UARTS=6
---
> CONFIG_SERIAL_8250_NR_UARTS=9
> CONFIG_SERIAL_8250_RUNTIME_UARTS=9


*One thing that's different is the outputs of the "mount" command run on 
the two kernels: 

> /dev/mmcblk0p1 on / type ext4 (rw,relatime,errors=remount-ro,data=ordered)
> devtmpfs on /dev type devtmpfs 
(rw,relatime,size=824360k,nr_inodes=97302,mode=755)
3,6d4
< udev on /dev type devtmpfs 
(rw,relatime,size=10240k,nr_inodes=96053,mode=755)
< devpts on /dev/pts type devpts 
(rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
< tmpfs on /run type tmpfs (rw,nosuid,relatime,size=372500k,mode=755)
< /dev/mmcblk0p1 on / type ext4 (rw,relatime,errors=remount-ro,data=ordered)
8a7,8
> devpts on /dev/pts type devpts 
(rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
> tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
13,17d12
< cgroup on /sys/fs/cgroup/freezer type cgroup 
(rw,nosuid,nodev,noexec,relatime,freezer)
< cgroup on /sys/fs/cgroup/blkio type cgroup 
(rw,nosuid,nodev,noexec,relatime,blkio)
< cgroup on /sys/fs/cgroup/perf_event type cgroup 
(rw,nosuid,nodev,noexec,relatime,perf_event)
< cgroup on /sys/fs/cgroup/devices type cgroup 
(rw,nosuid,nodev,noexec,relatime,devices)
< cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup 
(rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
19c14,15
< cgroup on /sys/fs/cgroup/cpuset type cgroup 
(rw,nosuid,nodev,noexec,relatime,cpuset)
---
> cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup 
(rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
> cgroup on /sys/fs/cgroup/perf_event type cgroup 
(rw,nosuid,nodev,noexec,relatime,perf_event)
21c17,20
< systemd-1 on /proc/sys/fs/binfmt_misc type autofs 
(rw,relatime,fd=22,pgrp=1,timeout=0,minproto=5,maxproto=5,direct)
---
> cgroup on /sys/fs/cgroup/cpuset type cgroup 
(rw,nosuid,nodev,noexec,relatime,cpuset)
> cgroup on /sys/fs/cgroup/freezer type cgroup 
(rw,nosuid,nodev,noexec,relatime,freezer)
> cgroup on /sys/fs/cgroup/devices type cgroup 
(rw,nosuid,nodev,noexec,relatime,devices)
> cgroup on /sys/fs/cgroup/blkio type cgroup 
(rw,nosuid,nodev,noexec,relatime,blkio)
24c23
< configfs on /sys/kernel/config type configfs (rw,relatime)
---
> systemd-1 on /proc/sys/fs/binfmt_misc type autofs 
(rw,relatime,fd=33,pgrp=1,timeout=0,minproto=5,maxproto=5,direct)
26c25,26
< tmpfs on /run/user/1000 type tmpfs 
(rw,nosuid,nodev,relatime,size=186252k,mode=700,uid=1000,gid=1000)
---
> configfs on /sys/kernel/config type configfs (rw,relatime)
> tmpfs on /run/user/1000 type tmpfs 
(rw,nosuid,nodev,relatime,size=186248k,mode=700,uid=1000,gid=1000)




 Console dump when attempting to flash the eMMC using kernel 
4.4.110-ti-r142 compiled from source *


Starting eMMC Flasher from microSD media
Version: [1.20171220: btrfs...]

Re: [beagleboard] Is there a "Smaller Footprint" LXQT Image for BB-X15 (preferably Jessie)?

[Jeff Andich]

Note: This is a problem with my DVI monitor (and my lack of knowledge on 
the subject), not the image..

I've only seen the timeout error when I plug into my DVI monitor, not when 
plugging into HDMI monitors (and I've tried 2 of the latter thus far).

I think what's going on with the timeout error (at a very high level) and 
from reading 

https://www.extron.com/company/article.aspx?id=uedid 

is my DVI monitor isn't able to provided the EDID information to the BB-X15 
either due to protocol incompatibility or the monitor isn't able to provide 
that information, period.

Granted, I haven't tried any other DVI monitors which are known to provide 
EDID.

Thanks and FYI,

Jeff


On Friday, February 9, 2018 at 9:28:17 AM UTC-6, Jeff Andich wrote:

>
> One thing I'm noticing on my 572xEVM-Rev a3 at work (which I don't THINK I 
> saw on my BB-X15 (?revC?) at home last-night is the following error message 
> whenever I plug in an HDMI cable which is connected to a DELL monitor 
> through an HDMI<->DVI adaptor:
>
> [   42.531433] omapdss error: HDMI I2C timeout reading EDID
>
> But I can still see and use X-windows
>
> Also, I'm not sure what's different about the BB-X15 vs. Debian base 
> images, but that's my job to hash through and then ask the TA questions 
> during office hours
>
> Thanks and regards,
>
> jeff
>
>
>
>
>
>
> On Thursday, February 8, 2018 at 9:02:52 PM UTC-6, Jeff Andich wrote:
>>
>> Great!  Thanks!
>>
>>
>>
>> On Thursday, February 8, 2018 at 3:32:14 PM UTC-6, RobertCNelson wrote:
>>>
>>> On Thu, Feb 8, 2018 at 12:25 PM, Jeff Andich <jeff@gmail.com> 
>>> wrote: 
>>> > Hi, 
>>> > 
>>> > Is there a 2GB LXQT (or LXDE) image available for the BB-X15 
>>> somewhere, 
>>> > preferably Debian 8.x or is it better to start with a console image, 
>>> and add 
>>> > all of the X packages (maybe something like the following FLIR Lepton 
>>> > example)?  We have only 4GB of eMMC and looks like we need Xinit, X11, 
>>> > Xserver, and a bunch of other stuff like mono and chromium for our 
>>> > application 
>>> > 
>>> > 
>>> > 
>>> https://eewiki.net/display/linuxonarm/FLIR+Lepton+on+BeagleBone+Black+and+Green#FLIRLeptononBeagleBoneBlackandGreen-Setupbasicwindowmanager
>>>  
>>> > 
>>> > When trying to find a 2GB LXQT image, I looked in the following 
>>> locations, 
>>> > and I apologize in advance if I missed something!! 
>>> > 
>>> > 
>>> > 1) 
>>> > 
>>> https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Jessie_Snapshot_lxqt 
>>> > 
>>> > and 
>>> > 
>>> > 2) https://rcn-ee.net/rootfs/bb.org/testing/ 
>>>
>>> So you can take the base image: 
>>>
>>> wget 
>>> https://rcn-ee.net/rootfs/bb.org/testing/2018-02-01/lxqt-2gb/debian-8.10-lxqt-2gb-armhf-2018-02-01.tar.xz
>>>  
>>> tar xf debian-8.10-lxqt-2gb-armhf-2018-02-01.tar.xz 
>>> cd debian-8.10-lxqt-2gb-armhf-2018-02-01/ 
>>>
>>> sudo ./setup_sdcard.sh --mmc /dev/sdX --dtb am57xx-beagle-x15 
>>>
>>> replacing /dev/sdX with your actual microSD adapter on your development 
>>> pc.. 
>>>
>>> Regards, 
>>>
>>> -- 
>>> Robert Nelson 
>>> https://rcn-ee.com/ 
>>>
>>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/bb0569ae-1cc4-4714-9af9-30123b076c1c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Is there a "Smaller Footprint" LXQT Image for BB-X15 (preferably Jessie)?

[Jeff Andich]

sorry - half baked question...

Let me pull in the correct device tree for my image and get back to you.

On Friday, February 9, 2018 at 9:28:17 AM UTC-6, Jeff Andich wrote:
>
>
> One thing I'm noticing on my 572xEVM-Rev a3 at work (which I don't THINK I 
> saw on my BB-X15 (?revC?) at home last-night is the following error message 
> whenever I plug in an HDMI cable which is connected to a DELL monitor 
> through an HDMI<->DVI adaptor:
>
> [   42.531433] omapdss error: HDMI I2C timeout reading EDID
>
> But I can still see and use X-windows
>
> Also, I'm not sure what's different about the BB-X15 vs. Debian base 
> images, but that's my job to hash through and then ask the TA questions 
> during office hours
>
> Thanks and regards,
>
> jeff
>
>
>
>
>
>
> On Thursday, February 8, 2018 at 9:02:52 PM UTC-6, Jeff Andich wrote:
>>
>> Great!  Thanks!
>>
>>
>>
>> On Thursday, February 8, 2018 at 3:32:14 PM UTC-6, RobertCNelson wrote:
>>>
>>> On Thu, Feb 8, 2018 at 12:25 PM, Jeff Andich <jeff@gmail.com> 
>>> wrote: 
>>> > Hi, 
>>> > 
>>> > Is there a 2GB LXQT (or LXDE) image available for the BB-X15 
>>> somewhere, 
>>> > preferably Debian 8.x or is it better to start with a console image, 
>>> and add 
>>> > all of the X packages (maybe something like the following FLIR Lepton 
>>> > example)?  We have only 4GB of eMMC and looks like we need Xinit, X11, 
>>> > Xserver, and a bunch of other stuff like mono and chromium for our 
>>> > application 
>>> > 
>>> > 
>>> > 
>>> https://eewiki.net/display/linuxonarm/FLIR+Lepton+on+BeagleBone+Black+and+Green#FLIRLeptononBeagleBoneBlackandGreen-Setupbasicwindowmanager
>>>  
>>> > 
>>> > When trying to find a 2GB LXQT image, I looked in the following 
>>> locations, 
>>> > and I apologize in advance if I missed something!! 
>>> > 
>>> > 
>>> > 1) 
>>> > 
>>> https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Jessie_Snapshot_lxqt 
>>> > 
>>> > and 
>>> > 
>>> > 2) https://rcn-ee.net/rootfs/bb.org/testing/ 
>>>
>>> So you can take the base image: 
>>>
>>> wget 
>>> https://rcn-ee.net/rootfs/bb.org/testing/2018-02-01/lxqt-2gb/debian-8.10-lxqt-2gb-armhf-2018-02-01.tar.xz
>>>  
>>> tar xf debian-8.10-lxqt-2gb-armhf-2018-02-01.tar.xz 
>>> cd debian-8.10-lxqt-2gb-armhf-2018-02-01/ 
>>>
>>> sudo ./setup_sdcard.sh --mmc /dev/sdX --dtb am57xx-beagle-x15 
>>>
>>> replacing /dev/sdX with your actual microSD adapter on your development 
>>> pc.. 
>>>
>>> Regards, 
>>>
>>> -- 
>>> Robert Nelson 
>>> https://rcn-ee.com/ 
>>>
>>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/4bb4d38b-cf63-477a-b070-941895c3101b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Is there a "Smaller Footprint" LXQT Image for BB-X15 (preferably Jessie)?

[Jeff Andich]

One thing I'm noticing on my 572xEVM-Rev a3 at work (which I don't THINK I 
saw on my BB-X15 (?revC?) at home last-night is the following error message 
whenever I plug in an HDMI cable which is connected to a DELL monitor 
through an HDMI<->DVI adaptor:

[   42.531433] omapdss error: HDMI I2C timeout reading EDID

But I can still see and use X-windows

Also, I'm not sure what's different about the BB-X15 vs. Debian base 
images, but that's my job to hash through and then ask the TA questions 
during office hours

Thanks and regards,

jeff






On Thursday, February 8, 2018 at 9:02:52 PM UTC-6, Jeff Andich wrote:
>
> Great!  Thanks!
>
>
>
> On Thursday, February 8, 2018 at 3:32:14 PM UTC-6, RobertCNelson wrote:
>>
>> On Thu, Feb 8, 2018 at 12:25 PM, Jeff Andich <jeff@gmail.com> wrote: 
>> > Hi, 
>> > 
>> > Is there a 2GB LXQT (or LXDE) image available for the BB-X15 somewhere, 
>> > preferably Debian 8.x or is it better to start with a console image, 
>> and add 
>> > all of the X packages (maybe something like the following FLIR Lepton 
>> > example)?  We have only 4GB of eMMC and looks like we need Xinit, X11, 
>> > Xserver, and a bunch of other stuff like mono and chromium for our 
>> > application 
>> > 
>> > 
>> > 
>> https://eewiki.net/display/linuxonarm/FLIR+Lepton+on+BeagleBone+Black+and+Green#FLIRLeptononBeagleBoneBlackandGreen-Setupbasicwindowmanager
>>  
>> > 
>> > When trying to find a 2GB LXQT image, I looked in the following 
>> locations, 
>> > and I apologize in advance if I missed something!! 
>> > 
>> > 
>> > 1) 
>> > 
>> https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Jessie_Snapshot_lxqt 
>> > 
>> > and 
>> > 
>> > 2) https://rcn-ee.net/rootfs/bb.org/testing/ 
>>
>> So you can take the base image: 
>>
>> wget 
>> https://rcn-ee.net/rootfs/bb.org/testing/2018-02-01/lxqt-2gb/debian-8.10-lxqt-2gb-armhf-2018-02-01.tar.xz
>>  
>> tar xf debian-8.10-lxqt-2gb-armhf-2018-02-01.tar.xz 
>> cd debian-8.10-lxqt-2gb-armhf-2018-02-01/ 
>>
>> sudo ./setup_sdcard.sh --mmc /dev/sdX --dtb am57xx-beagle-x15 
>>
>> replacing /dev/sdX with your actual microSD adapter on your development 
>> pc.. 
>>
>> Regards, 
>>
>> -- 
>> Robert Nelson 
>> https://rcn-ee.com/ 
>>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/2ed3f6a9-e71d-424e-bc96-6dc20203eec0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Is there a "Smaller Footprint" LXQT Image for BB-X15 (preferably Jessie)?

[Jeff Andich]

Great!  Thanks!



On Thursday, February 8, 2018 at 3:32:14 PM UTC-6, RobertCNelson wrote:
>
> On Thu, Feb 8, 2018 at 12:25 PM, Jeff Andich <jeff@gmail.com 
> > wrote: 
> > Hi, 
> > 
> > Is there a 2GB LXQT (or LXDE) image available for the BB-X15 somewhere, 
> > preferably Debian 8.x or is it better to start with a console image, and 
> add 
> > all of the X packages (maybe something like the following FLIR Lepton 
> > example)?  We have only 4GB of eMMC and looks like we need Xinit, X11, 
> > Xserver, and a bunch of other stuff like mono and chromium for our 
> > application 
> > 
> > 
> > 
> https://eewiki.net/display/linuxonarm/FLIR+Lepton+on+BeagleBone+Black+and+Green#FLIRLeptononBeagleBoneBlackandGreen-Setupbasicwindowmanager
>  
> > 
> > When trying to find a 2GB LXQT image, I looked in the following 
> locations, 
> > and I apologize in advance if I missed something!! 
> > 
> > 
> > 1) 
> > 
> https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Jessie_Snapshot_lxqt 
> > 
> > and 
> > 
> > 2) https://rcn-ee.net/rootfs/bb.org/testing/ 
>
> So you can take the base image: 
>
> wget 
> https://rcn-ee.net/rootfs/bb.org/testing/2018-02-01/lxqt-2gb/debian-8.10-lxqt-2gb-armhf-2018-02-01.tar.xz
>  
> tar xf debian-8.10-lxqt-2gb-armhf-2018-02-01.tar.xz 
> cd debian-8.10-lxqt-2gb-armhf-2018-02-01/ 
>
> sudo ./setup_sdcard.sh --mmc /dev/sdX --dtb am57xx-beagle-x15 
>
> replacing /dev/sdX with your actual microSD adapter on your development 
> pc.. 
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/b3c91489-8766-4c7e-a928-b5f6a3a07a50%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Is there a "Smaller Footprint" LXQT Image for BB-X15 (preferably Jessie)?

[Jeff Andich]

Hi,

Is there a 2GB LXQT (or LXDE) image available for the BB-X15 somewhere, 
preferably Debian 8.x or is it better to start with a console image, and 
add all of the X packages (maybe something like the following FLIR Lepton 
example)?  We have only 4GB of eMMC and looks like we need Xinit, X11, 
Xserver, and a bunch of other stuff like mono and chromium for our 
application


https://eewiki.net/display/linuxonarm/FLIR+Lepton+on+BeagleBone+Black+and+Green#FLIRLeptononBeagleBoneBlackandGreen-Setupbasicwindowmanager



When trying to find a 2GB LXQT image, I looked in the following locations, 
and I apologize in advance if I missed something!!


1) 
https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Jessie_Snapshot_lxqt

and 

2) https://rcn-ee.net/rootfs/bb.org/testing/


Thanks!

jeff

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/501a15da-823b-4c6f-af45-b6879dea83f3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Pin map spreadsheet for X15

[Jeff Andich]

Thanks!

I'm sure this will come in handy..



On Wednesday, February 7, 2018 at 6:32:35 PM UTC-6, gcoley1 wrote:
>
>  
>
>  
>
> *From:* beagl...@googlegroups.com  [mailto:
> beagl...@googlegroups.com ] *On Behalf Of *Jeff Andich
> *Sent:* Wednesday, February 7, 2018 5:11 PM
> *To:* BeagleBoard <beagl...@googlegroups.com >
> *Subject:* [beagleboard] Re: Pin map spreadsheet for X15
>
>  
>
> One of the things I failed to mention is the support engineers on TI E2E 
> helped me through some of my BB-X15/ 5728EVM expansion header pad 
> configuration/pinmux issues.  You can see the issues I was having and the 
> steps the TI support engineer had me walk through to examine the pad 
> configuration from user space on our BB-X15/5728 here:
>
>  
>
> https://e2e.ti.com/support/arm/sitara_arm/f/791/t/649900
>
>  
>
>  
>
> Thanks..
>
>  
>
> Jeff
>
>  
>
>
>
> On Wednesday, February 7, 2018 at 4:53:39 PM UTC-6, Jeff Andich wrote:
>
> Hi,
>
>  
>
> I don't think the pinmap spreadsheet has been posted yet (
> http://beagleboard.org/discuss?place=msg%2Fbeagleboard%2FKAVSkC15EkA%2FlG4AHCoxCAAJ).
>   
> A lot of this information can be found on TI's website as well.  I 
> struggled with re-configuring the expansion header pins for a while, but I 
> think I'm finally starting to get the hang of it.
>
>  
>
> But I THINK what really matters is the specific BeagleBoard-X15 image you 
> are using (e.g. console, LXQT, etc) and the pinmux which has been 
> incorporated into the u-boot image and kernel image (e.g. the device tree) 
> associated with that specific beagleboard-X15 image.  If you look at that 
> pinmux configuration, then that will tell you exactly how the pins on the 
> expansion header are configured for the image your BB-X15 is running.
>
>  
>
> Note: Most of the PINMUX for the 5728 is done within the SPL (per TI's 
> advice for the 5728 based on the glitch errata for the 5728).  Only the MMC 
> pinmux is supposed to be configured within the device tree per TI's 
> guidance.  Note:  I've configured/re-configured the pinmux for non-MMC 
> peripherals within the device tree for testing purposes without it 
> affecting me, but you should be aware of TI's errata and the implications 
> for your application and your hardware before determining that it's ok to 
> configure the non-MMC pinmux from the device tree..
>
>  
>
> Once you've located the correct pad configuration array in mux_data.h 
> which your BB-X15 is actively using, then you can correlate the expansion 
> header pinout on the BB-X15 schematic (page 27 on rev. B of the schematic) 
> with the pinmux configured for the device.  The first element of each of 
> the rows in that array contains the M0 muxmode for each pad, so that will 
> help you find which pad # each array element configures.
>
>  
>
> Then you need to look at the 5728 datasheet (and/or chapter 18 of the TRM) 
> to determine the possible mux modes for each pad.  This will tell you 
> whether a GPIO line on the expansion header can be reconfigured as a SPI 
> CLK line, for instance. 
>
>  
>
>  
>
> I hope this helps you get started..  Let me know if you have questions, 
> and I will try to get around to it when I can..
>
>  
>
> Thanks!
>
>  
>
> Jeff
>
>  
>
>
> On Tuesday, February 6, 2018 at 2:34:40 PM UTC-6, Dermot Murphy wrote:
>
> Hi there - can anyone help me locate the pin map spreadsheet for the X15 
> expansion headers (P16-P19)?  Page 84 of the BeagleBoard X15 System 
> Reference Manual suggests that this can be found on the X15 Support Wiki...
>
> http://elinux.org/BeagleBoard:BeagleBoard-X15
>
> ...but I'm unable to find any links or references.  All I can find is the 
> schematic on page 27 of BEAGLEBOARD_X15_REV_B1.pdf
>
> I have some experience with BBB but none yet with the X15 so I'm currently 
> assuming that something like the SPI bus is accessible via GPIO pins set in 
> some mode or other.  I'm just having difficulty getting this information.
>
> Thanks,
> Dermot
>
> -- 
> For more options, visit http://beagleboard.org/discuss
> --- 
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/7bd2ff3c-1d76-4eb4-8c4b-52fb872b5e18%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/beagleboard/7bd2ff3c-1d76-4eb4-8c4b-52fb872b5e18%40googlegroups.com?utm_medium=email_source=footer>
> .
&g

[beagleboard] Re: Pin map spreadsheet for X15

[Jeff Andich]

One of the things I failed to mention is the support engineers on TI E2E 
helped me through some of my BB-X15/ 5728EVM expansion header pad 
configuration/pinmux issues.  You can see the issues I was having and the 
steps the TI support engineer had me walk through to examine the pad 
configuration from user space on our BB-X15/5728 here:

https://e2e.ti.com/support/arm/sitara_arm/f/791/t/649900
 

Thanks..

Jeff



On Wednesday, February 7, 2018 at 4:53:39 PM UTC-6, Jeff Andich wrote:
>
> Hi,
>
> I don't think the pinmap spreadsheet has been posted yet (
> http://beagleboard.org/discuss?place=msg%2Fbeagleboard%2FKAVSkC15EkA%2FlG4AHCoxCAAJ).
>   
> A lot of this information can be found on TI's website as well.  I 
> struggled with re-configuring the expansion header pins for a while, but I 
> think I'm finally starting to get the hang of it.
>
> But I THINK what really matters is the specific BeagleBoard-X15 image you 
> are using (e.g. console, LXQT, etc) and the pinmux which has been 
> incorporated into the u-boot image and kernel image (e.g. the device tree) 
> associated with that specific beagleboard-X15 image.  If you look at that 
> pinmux configuration, then that will tell you exactly how the pins on the 
> expansion header are configured for the image your BB-X15 is running.
>
> Note: Most of the PINMUX for the 5728 is done within the SPL (per TI's 
> advice for the 5728 based on the glitch errata for the 5728).  Only the MMC 
> pinmux is supposed to be configured within the device tree per TI's 
> guidance.  Note:  I've configured/re-configured the pinmux for non-MMC 
> peripherals within the device tree for testing purposes without it 
> affecting me, but you should be aware of TI's errata and the implications 
> for your application and your hardware before determining that it's ok to 
> configure the non-MMC pinmux from the device tree..
>
> Once you've located the correct pad configuration array in mux_data.h 
> which your BB-X15 is actively using, then you can correlate the expansion 
> header pinout on the BB-X15 schematic (page 27 on rev. B of the schematic) 
> with the pinmux configured for the device.  The first element of each of 
> the rows in that array contains the M0 muxmode for each pad, so that will 
> help you find which pad # each array element configures.
>
> Then you need to look at the 5728 datasheet (and/or chapter 18 of the TRM) 
> to determine the possible mux modes for each pad.  This will tell you 
> whether a GPIO line on the expansion header can be reconfigured as a SPI 
> CLK line, for instance. 
>
>
> I hope this helps you get started..  Let me know if you have questions, 
> and I will try to get around to it when I can..
>
> Thanks!
>
> Jeff
>
>
> On Tuesday, February 6, 2018 at 2:34:40 PM UTC-6, Dermot Murphy wrote:
>>
>> Hi there - can anyone help me locate the pin map spreadsheet for the X15 
>> expansion headers (P16-P19)?  Page 84 of the BeagleBoard X15 System 
>> Reference Manual suggests that this can be found on the X15 Support Wiki...
>>
>> http://elinux.org/BeagleBoard:BeagleBoard-X15
>>
>> ...but I'm unable to find any links or references.  All I can find is the 
>> schematic on page 27 of BEAGLEBOARD_X15_REV_B1.pdf
>>
>> I have some experience with BBB but none yet with the X15 so I'm 
>> currently assuming that something like the SPI bus is accessible via GPIO 
>> pins set in some mode or other.  I'm just having difficulty getting this 
>> information.
>>
>> Thanks,
>> Dermot
>>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/7bd2ff3c-1d76-4eb4-8c4b-52fb872b5e18%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Pin map spreadsheet for X15

[Jeff Andich]

Hi,

I don't think the pinmap spreadsheet has been posted yet 
(http://beagleboard.org/discuss?place=msg%2Fbeagleboard%2FKAVSkC15EkA%2FlG4AHCoxCAAJ).
  
A lot of this information can be found on TI's website as well.  I 
struggled with re-configuring the expansion header pins for a while, but I 
think I'm finally starting to get the hang of it.

But I THINK what really matters is the specific BeagleBoard-X15 image you 
are using (e.g. console, LXQT, etc) and the pinmux which has been 
incorporated into the u-boot image and kernel image (e.g. the device tree) 
associated with that specific beagleboard-X15 image.  If you look at that 
pinmux configuration, then that will tell you exactly how the pins on the 
expansion header are configured for the image your BB-X15 is running.

Note: Most of the PINMUX for the 5728 is done within the SPL (per TI's 
advice for the 5728 based on the glitch errata for the 5728).  Only the MMC 
pinmux is supposed to be configured within the device tree per TI's 
guidance.  Note:  I've configured/re-configured the pinmux for non-MMC 
peripherals within the device tree for testing purposes without it 
affecting me, but you should be aware of TI's errata and the implications 
for your application and your hardware before determining that it's ok to 
configure the non-MMC pinmux from the device tree..

Once you've located the correct pad configuration array in mux_data.h which 
your BB-X15 is actively using, then you can correlate the expansion header 
pinout on the BB-X15 schematic (page 27 on rev. B of the schematic) with 
the pinmux configured for the device.  The first element of each of the 
rows in that array contains the M0 muxmode for each pad, so that will help 
you find which pad # each array element configures.

Then you need to look at the 5728 datasheet (and/or chapter 18 of the TRM) 
to determine the possible mux modes for each pad.  This will tell you 
whether a GPIO line on the expansion header can be reconfigured as a SPI 
CLK line, for instance. 


I hope this helps you get started..  Let me know if you have questions, and 
I will try to get around to it when I can..

Thanks!

Jeff


On Tuesday, February 6, 2018 at 2:34:40 PM UTC-6, Dermot Murphy wrote:
>
> Hi there - can anyone help me locate the pin map spreadsheet for the X15 
> expansion headers (P16-P19)?  Page 84 of the BeagleBoard X15 System 
> Reference Manual suggests that this can be found on the X15 Support Wiki...
>
> http://elinux.org/BeagleBoard:BeagleBoard-X15
>
> ...but I'm unable to find any links or references.  All I can find is the 
> schematic on page 27 of BEAGLEBOARD_X15_REV_B1.pdf
>
> I have some experience with BBB but none yet with the X15 so I'm currently 
> assuming that something like the SPI bus is accessible via GPIO pins set in 
> some mode or other.  I'm just having difficulty getting this information.
>
> Thanks,
> Dermot
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/8503c027-1dbc-4877-8138-16e11ab6e4af%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Getting started: Step #2 and #3 just dont work on Windows 10 (or 8, or 7)

[Jeff Andich]

Do you still get the same driver install problems on the Windows 7 PC as 
you see on your Windows 10 host or is that primarily a problem with 
accessing the URL in your web browser?


On Wednesday, February 7, 2018 at 8:19:41 AM UTC-6, Jon Lundstrom wrote:
>
>
> I just unpacked a Beaglebone Black board and try to get it started as 
> tethered to a PC via USB. I can find and read START.HTM from the BBB.
> When it comes to Step #2, Install drivers, I start getting problems: 4 of 
> the drivers fail to install on my Windows10 host:
> Linux Developer Community (usbser) Ports
> BeagleBone CDM Driver Package - Bus/D2XX Driver
> BeagleBone CDM Driver Package - VCP Driver
> Linux Developer Community Net
>
> After that step #3 fails, probably as a consequense of above. My web 
> browser (either Firefox or Chrome) will not find http://192.168.7.2.
>
> I've also tried on other computers, running Windows 8 and Windows 7, with 
> no further success.
>
>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/8ee16037-1506-43b3-88c1-4c31bdf4af43%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Web browser in LCD (4D) using IoT image

[Jeff Andich]

Hi someone on our team tried to run chromium on an external 
touchscreen/display connected to the BeagleBone Black, and noted similar 
slow response.

Is there a way to improve performance of chromium running on BBB or are 
there better alternatives?

Thanks!


On Wednesday, February 7, 2018 at 6:51:26 AM UTC-6, Michael Dalby wrote:
>
> Hi Rob,
>
> Many thanks for the help. 
> Adding the Xorg got the LCD screen up and running. I do have a couple of 
> question that you may be able to answer??
> Firstly, when the BBB initially loads it goes to the user logon screen 
> which seems to be incorrectly scaled - do you know if there is a way to 
> correct scaling?
>
>
>
>
> 
>
>
> Secondly, when I load a page into the chromium browser it seems really 
> slow laggy & unresponsive - I am running Node Red and wanted the browser to 
> view the output dashboard. Is this a problem with Chromium on the BBB - 
> should I be using a different browser or are there some Xorg settings I can 
> change to improve things?? If I monitor the dashboard through my PCs 
> webbrowser via HTTP connection it is buttery smooth *with the BBB acting as 
> the web server)
>
> Many thanks for any help you can offer
>
> Cheers
>
> Michael
>
>
> On Friday, 2 February 2018 15:34:48 UTC, RobertCNelson wrote:
>>
>> On Fri, Feb 2, 2018 at 9:32 AM, Robert Nelson  
>> wrote: 
>> > On Fri, Feb 2, 2018 at 9:12 AM, Michael Dalby  
>> wrote: 
>> >> Hi All 
>> >> 
>> >> I hope someone can help ? 
>> >> 
>> >> I am running a Debian IoT (non GUI) image on my BBB. I have a  4D LCD 
>> cape 
>> >> installed which is working and shows the Linux command line. 
>> >> I would like to run a web browser in order to show the Node-Red 
>> dashboard of 
>> >> my running Node-Red instance. 
>> >> 
>> >> I have successfully installed Chromium-browser (it didn't show any 
>> errors), 
>> >> but if I try to run 'chromium-browser' from the command line it does 
>> nothing 
>> >> - I want the web browser to show in the LCD window. 
>> >> Is this possible ?? 
>> >> Do I need to install any other applications (can this be done without 
>> >> installing something like LDXE)?? 
>> >> 
>> >> Thanks in advance for any help you can offer 
>> >> 
>> >> P.s. I am using the IoT version of Debian as I wanted to try and keep 
>> the 
>> >> memory foorprint to below 4Gb 
>> > 
>> > You'll need Xorg installed 
>> > 
>> > Follow "some" of this example i did for show: 
>> > 
>> > 
>> https://eewiki.net/display/linuxonarm/FLIR+Lepton+on+BeagleBone+Black+and+Green#FLIRLeptononBeagleBoneBlackandGreen-Setupbasicwindowmanager
>>  
>> > 
>> > aka ignore the lepton, qt5, and spi stuff.  But the minimal 
>> > openbox/slim/autostart can be easily used for your application. 
>>
>> ps ignore the 16 bit depth in xorg.conf, newer kernels' auto do this.. 
>>
>> i should just create a new x11 example, or redo that project with 
>> todays kernel. ;) 
>>
>> Regards, 
>>
>> -- 
>> Robert Nelson 
>> https://rcn-ee.com/ 
>>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/2799d6f1-3a7e-4c52-9a74-e205a3a90b57%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] What's Going on with EEWIKI.NET?

[Jeff Andich]

It looks like eewiki.net is down.  

Been trying to access it since yesterday.  

Please advise.

Thanks!

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/ad8aed07-457e-4245-9013-79ba2d1cb268%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Beagle Bone black debain gpio access denied

[Jeff Andich]

Switching to root before doing sysfs operations, (e.g. sudo su), typically 
seems to work for me..

On Friday, February 2, 2018 at 12:01:43 PM UTC-6, Hemant Kapoor wrote:
>
> Hello, 
>
> Yet another newbie question. 
>
> I have got latest debian image on my beagle bone black.
> uname - r output: 4.9.45-ti-r57
>
> and I noticed various gpio directory in /sys/class/gpio
>
> when I tried
> echo 69 > unexport 
> it gave me permission denied.
> so I changed the permission of unexport file to be 666
>
> and now when I try to use the same command it gives me an error: 
> -bash: echo: write error: Invalid argument
>
> Can anyone please help...
>
> Ultimately I want to develop a C++ project to toggle LED which is 
> connected to one of the pins...
>
> Any help regarding this matter is deeply appreciated.
>
> Regards, 
> Hemant Kapoor
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/36fcc8b7-726d-42d0-ba04-a219dffc7a46%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Serial Communication on Beaglebone Black

[Jeff Andich]

Hi,

I'm running on a BB-X15 with kernel 4.4.110-ti-r142 and Debian, 8.10 
(2018-01-01).

I have not yet correctly run hardware flow control on Beagleboard-X15/BBB, 
but I BELIEVE I saw evidence that the non-default, OMAP serial driver (as 
opposed to the default 8250 serial driver) was auto-toggling the RTS line 
when the RTS line was using a GPIO line instead of a "dedicated RTS line" 
for the respective UART.  Caution: it could be that the driver was treating 
the GPIO line differently than the dedicated RTS line, so I need to go back 
and flush all of this out (unless someone on here already knows the 
answer)...  I also need to show you the difference in how my device tree 
fragment for this UART was specified.  

Furthermore, since we're doing RS485/MODBUS for our work project, our 
strategy (at the moment) is to manually toggle the dedicated RTS line which 
is connected to the "DE switch" on a 2-wire RS485 chip.  Toggling the DE 
switch switches whether the half-duplex RS485 chip is transmitting (e.g. 
UART port's Txd line is connected) or receiving  (e.g. UART port's Rxd line 
is connected).  One interesting thing to note, is that so long as we use a 
"dedicated RTS line from the UART, we can manually toggle that RTS line (in 
Python, for instance) regardless of whether we're using the OMAP driver or 
the 8250 driver. 

My BB-X15 is currently setup for UART 9.  The pinmux has been configured to 
expose UART9's Rxd, Txd, RTS, and CTS. I just need a good, easy way of 
testing hardware flow control maybe in some kind of real time data 
exchange.  So maybe something like a Python program running on both my PC 
and my BB-X15 which boomerangs back what the other party sends???

I will TRY to test this this week in my spare time, but there's some stuff 
at work and outside of work this week which could easily necessitate 
pushing this back..  So bare with me, and follow-up if I drop the ball. 

Thanks! 

Jeff
 
 

On Saturday, February 3, 2018 at 8:30:27 PM UTC-6, marc.a@gmail.com 
wrote:
>
> I've been using a beaglebone black (in debian) to communicate with my 
> Matsuura MC800 VF (1993). It's got an old yasnac I-80 controller on it, and 
> I have to drip feed most stuff because I've only got about 30k of program 
> memory. For the record I was unable to get this to work with USB to serial 
> adapters, in both Windows and Linux. As soon as I went directly to the UART 
> pins it was easy.
>
> I recommend using stty to set the serial port, and the just copy the file 
> you want to the serial port. For example, I run at 4800 baud, 7 data bits 
> even parity 1 stop bit with software "flow control". Here's how I set the 
> port settings for the beaglebone black:
>
> stty -F /dev/ttyS1 4800 parenb cs7 -icrnl ixon nl1 cr1
>
>
> then do something like this to copy the file to the serial port and have 
> the beaglebone spit it out. In my case I'm using serial (uart) 1:
>
> cp /pathtofile/mycncfile.nc /dev/ttyS1
>
>
> You can do it in Python, but I'd get it working at the most basic level 
> first. With Python there could be additional software buffers between you 
> and the cnc machine that could cause issues.
>
>
> I use a max232 between the beaglebone and the machine for level shifting. 
> I'm currently using an old one a buddy soldered up and had laying around, 
> but I'm going to put in a more professional max232 in the next couple days. 
> The one I got was on Amazon link here:
>
>
> https://www.amazon.com/gp/product/B00HKIMBZW/ref=oh_aui_search_detailpage?ie=UTF8=1
>
>
> It looks, good, but I haven't tested it yet.
>
>
>
> Now, I've got a question for you guys. Has anyone been able to get 
> hardware flow control working on the beaglebone black in debian?
>
>
> -Marc
>
>
>
> On Wednesday, November 15, 2017 at 1:49:26 AM UTC-8, Jeff Andich wrote:
>>
>> Yeah we also stumbled last-week on Tx and Rx being swapped/ ‘crossed’ for 
>> UART1 (?only?) on the BB-X15 AND TI 572x evm REVA3 schematics.  The other 
>> UARTS appear fine.  Details to follow.
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/13bd8cf2-5482-4d4f-bbda-fd624b4b57ff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: HDMI not working in new BeagleboardX15

[Jeff Andich]

Hi,

My BB-X15 which arrived just prior to Harvey boots into some form of X 
windows from the internal eMMC image and the beagleboard.org desktop is 
displayed on my TV via HDMI.  I haven't yet updated the internal eMMC image 
as I'm running mainly from uSD cards..

My BB-X15 default eMMC image consists of the following:

debian@BeagleBoard-X15:~$ uname -r
4.9.35-ti-r44

debian@BeagleBoard-X15:~$ cat /etc/dogtag
BeagleBoard.org Debian Image 2017-07-02
debian@BeagleBoard-X15:~$ 


The console port isn't displayed on the HDMI.  Not sure if there's a way to 
do this

Thanks and FYI...

Jeff





On Monday, January 29, 2018 at 8:33:34 AM UTC-6, Jeff Andich wrote:
>
> Hi,
>
> I have a BB-X15 at home still with the default image (kernel 4.9.??)  on 
> the eMMC.  Regrettably, I've never tried running X on it (not even remote 
> desktop). 
>
> I will test it tonight by plugging an HDMI cable into it..
>
> I HAVE plugged an HDMI cable into our  572xEVM/BB-X15 at work a few months 
> ago, with a "base" BeagleBoard.org LXQT image on SD Card for BB-X15 from 
> BeagleBoard.org, and X worked fine on that.  Note, that the 572x LCD 
> touchscreen was attached when I tried this.
>
>
> Please ping me if I forget to follow-up...
>
>  Monday, January 29, 2018 at 4:44:36 AM UTC-6, vivek...@gmail.com wrote:
>
>> Hi,
>>
>> I just purchased a new BBX15 from mouser and connected to the suggested 
>> 12v 5a power adaptor. On switching the power button, I don't see any 
>> activity in the monitor connected through the HDMI port of BBX15. Does the 
>> new board come default with debian OS booting from eMMC?
>>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/cdf4821f-36ac-4af5-8c81-e2a91ec46543%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: HDMI not working in new BeagleboardX15

[Jeff Andich]

Hi,

I have a BB-X15 at home still with the default image (kernel 4.9.??)  on 
the eMMC.  Regrettably, I've never tried running X on it (not even remote 
desktop). 

I will test it tonight by plugging an HDMI cable into it..

I HAVE plugged an HDMI cable into our  572xEVM/BB-X15 at work a few months 
ago, with a "base" BeagleBoard.org LXQT image on SD Card for BB-X15 from 
BeagleBoard.org, and X worked fine on that.  Note, that the 572x LCD 
touchscreen was attached when I tried this.


Please ping me if I forget to follow-up...

 Monday, January 29, 2018 at 4:44:36 AM UTC-6, vivek...@gmail.com wrote:

> Hi,
>
> I just purchased a new BBX15 from mouser and connected to the suggested 
> 12v 5a power adaptor. On switching the power button, I don't see any 
> activity in the monitor connected through the HDMI port of BBX15. Does the 
> new board come default with debian OS booting from eMMC?
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/e3638c5c-5cc3-47fb-a121-9da01d20f5c5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: JTAG or OpenOCD

[Jeff Andich]

https://elinux.org/BeagleBoardJTAG

>From looking at a picture of the JTAG connector on the pocket beagle ( 
http://uk.farnell.com/beagleboard/bb-pocket/pocket-beagle-board-arm-cortex/dp/2806159
 
) , it looks like there are 7 JTAG connectors signals which appear to 
follow the TI signals as opposed to the ARM JTAG signals.

Here's a crazy thought..

I've often wondered what the boot loader developers (or BeagleBone patch 
wizards) do when developing SPL/u-boot for a new platform like the Pocket 
Beagle Do they resort to JTAG debugging to debug the SPL and u-boot for 
the new platform or is everything similar enough to other platforms where 
the console is already up-and-running, so they can spool debug messages out 
the console 

If the u-boot maintainers routinely use JTAG to debug SPL/u-boot, then is 
there another discussion forum which discusses JTAG debugging and more 
detailed u-boot debugging techniques??




On Tuesday, January 16, 2018 at 10:52:08 AM UTC-6, 
rob.d...@design-complex.com wrote:
>
> Has anyone had any success with JTAG emulation on the pocket beagle yet? I 
> have both Segger and NI debuggers as well as a variety of adaptors for 
> Other demo boards from tag-connect and others, though I can’t get any of 
> them to work, either because the pads are not aligned or because the 
> protocol settings must differ. 
>
> I can’t find any documentation about the jtag interface on the pocket, and 
> the documents that do exist (for the black) discuss the 20-pin header and 
> the TI adaptor only. 
>
> If I can’t step through using JTAG, is it possible to do so with either of 
> the USB interfaces on the pocket? There isn’t any documentation on that 
> either, so I figured it was prudent to ask.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/89364143-e5e7-424d-b0c1-a86f84bae324%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: JTAG or OpenOCD

[Jeff Andich]

Hi,

(Here's a newbie answer so take that for what it's worth).

Have only done limited JTAG debugging on the BB-X15 with CCS 7.x - when 
bringing up the SPL on a custom board with the same Sitara SOC as on the 
BB-X15.  

I THINK I recall that only a hand full of the 20 pins (like 7 maybe?) 
actually carry data and or clock for JTAG debugging on the 20 pin 
connector  So the subset of JTAG connections on the Pocket Beagle may be 
identical as on the 20 pin connector??

.  ***But please look this up and correct me if I'm in error!***

There's a TI board port series on how to setup CCS to debug the Linux SPL 
on the BeagleBone Black.  It's old, but TI mentioned on E2E that they're 
working on updating this video series.

When debugging the SPL, breakpoints couldn't be set in CCS.  This is a 
known problem, and I don't know if TI has a solution yet.  Alternatively in 
the SPL, we were able to click "run until" in the disassembly window to 
determine the flow of execution.  Just that it was in assembly, yuck.

Haven't tried debugging anything but the SPL using JTAG.  I think there 
have been other discussion threads on the merits of using JTAG vs. GDB and 
other techniques for debugging LInux.  I've heard that it can be useful for 
debugging drivers, but I THINK part of the issue maybe kernel context 
switching??
  


On Tuesday, January 16, 2018 at 10:52:08 AM UTC-6, 
rob.d...@design-complex.com wrote:
>
> Has anyone had any success with JTAG emulation on the pocket beagle yet? I 
> have both Segger and NI debuggers as well as a variety of adaptors for 
> Other demo boards from tag-connect and others, though I can’t get any of 
> them to work, either because the pads are not aligned or because the 
> protocol settings must differ. 
>
> I can’t find any documentation about the jtag interface on the pocket, and 
> the documents that do exist (for the black) discuss the 20-pin header and 
> the TI adaptor only. 
>
> If I can’t step through using JTAG, is it possible to do so with either of 
> the USB interfaces on the pocket? There isn’t any documentation on that 
> either, so I figured it was prudent to ask.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/93c4d35a-3d31-4e98-ae07-ace279c8bd47%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: TI BSP failed to build kernel

[Jeff Andich]

Ok thanks Robert!!

When the next-spin of our custom board comes in and we get more of the 
peripherals working, I'll TRY to submit something generic and compatible 
with BB-X15 like am57xx-4UARTs-wifi with embedded comments like what all we 
had to do to the kernel and u-boot to get working..
 



On Friday, January 5, 2018 at 10:20:01 AM UTC-6, RobertCNelson wrote:
>
> On Fri, Jan 5, 2018 at 10:13 AM, Jeff Andich <jeff@gmail.com 
> > wrote: 
> > Ok thanks! 
> > 
> > Then when you do a full re-build, does it delete the entire local tree 
> and 
> > re-git evertyhing from the same 4.4.y branch that you checkedout locally 
> on 
> > the server? 
> > 
> > I generated a custom device tree, am57xx-custom,dts which essentially 
> uses 
> > am57xx-evm-reva3.dts as a starting point and relies on all of the other 
> dts 
> > and dtsi files that it pulls in.  I build am57xx-custom.dtb by copying 
> > am57xx-custom.dts into the 4.4.y tree's arch/arm/boot/dts directory and 
> > adding it to Makefile.  Whenever FULL_REBUILD is defined, 
> > am57xx-custom.dts/dtb get deleted from arch/arm/boot/dts and the 
> > corresponding Makefile.. 
> > 
> > Maybe I should try your device tree builder... 
>
> Yeah, stick it in the device-tree builder, then submit a merge to me 
> thru that and i'll route it thru the tree. ;) 
>
> Just use something other then: 
>
> -custom.dtb ;) 
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/b3e280df-abfb-400c-97dd-6aa2b296e6b2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: TI BSP failed to build kernel

[Jeff Andich]

Ok thanks!

Then when you do a full re-build, does it delete the entire local tree and 
re-git evertyhing from the same 4.4.y branch that you checkedout locally on 
the server?

I generated a custom device tree, am57xx-custom,dts which essentially uses 
am57xx-evm-reva3.dts as a starting point and relies on all of the other dts 
and dtsi files that it pulls in.  I build am57xx-custom.dtb by copying 
am57xx-custom.dts into the 4.4.y tree's arch/arm/boot/dts directory and 
adding it to Makefile.  Whenever FULL_REBUILD is defined, 
am57xx-custom.dts/dtb get deleted from arch/arm/boot/dts and the 
corresponding Makefile..

Maybe I should try your device tree builder...

On Friday, January 5, 2018 at 8:58:40 AM UTC-6, RobertCNelson wrote:
>
> On Thu, Jan 4, 2018 at 9:25 AM, Jeff Andich <jeff@gmail.com 
> > wrote: 
> > Ok, so if I understand correctly, if I git the kernel and checkout the 
> 4.4.y 
> > or 4.9.y branches and then build the kernel using build_kernel.sh with 
> > FULL_REBUILD defined, any updates to the mainline or the patchset could 
> > affect my build or functionality, right? 
>
> Nope, once you do a checkout, the kernel version and kernel sha are 
> locked into the script.. 
>
> So if you lock everything 'down' including your OS (aka no updates), 
> the script will work and pull all the same stuff 10 years from now.. 
> (well as long as github.com and kernel.org git servers don't change 
> anything).. 
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/74a9fd36-f80c-4769-b9a9-e58fb18a2d9f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: TI BSP failed to build kernel

[Jeff Andich]

Is the best place to look for updates to the kernel and/or patches to the 
kernel here?  In other words, all inclusive..

https://github.com/RobertCNelson/ti-linux-kernel-dev.git


Thanks!

jeff

 

On Thursday, January 4, 2018 at 9:25:13 AM UTC-6, Jeff Andich wrote:
>
> Ok, so if I understand correctly, if I git the kernel and checkout the 
> 4.4.y or 4.9.y branches and then build the kernel using build_kernel.sh 
> with FULL_REBUILD defined, any updates to the mainline or the patchset 
> could affect my build or functionality, right?
>
> What is the best way to get updated when either the kernel and/or patch 
> set(s) change?  What mailing lists do we need to join?
>
> Thanks!!
>
> jeff  
>
> On Tuesday, January 2, 2018 at 8:48:10 AM UTC-6, RobertCNelson wrote:
>>
>> On Tue, Jan 2, 2018 at 8:41 AM, Jeff Andich <jeff@gmail.com> wrote: 
>> > 
>> > FYI, I THINK I ran into something similar over the holidays when I 
>> tried to 
>> > fetch and build the 4.4.y and 4.9.y kernels using eewiki.  I tried both 
>> BBB 
>> > and BB-X15.  I ran into an issue with a build error in an assembly file 
>> > which apparently had to do with some kind of networking package.  The 
>> kernel 
>> > built again, when this package was de-selected in makemenuconfig.  I 
>> was 
>> > getting ready to post something on this, but then some time after 
>> Christmas, 
>> > I re-fetched everything using the instructions on eewiki and everything 
>> > built again 
>> > 
>> > 
>> > Regards and happy new year! 
>>
>> for 4.9.x it was me last week, i fubared up the pocketbeagle 
>> simplegaming device tree binary. 
>>
>> also the wireguard patchset merge the last few weeks had some issues with 
>> thumb2 
>>
>> But Wireguard + https://github.com/StreisandEffect/streisand + linode 
>> (or any of the other supported ones) has been working awesome for me. 
>> ;) 
>>
>> Regards, 
>>
>> -- 
>> Robert Nelson 
>> https://rcn-ee.com/ 
>>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/4c70114a-0054-4d65-981d-7706c7279a8e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: TI BSP failed to build kernel

[Jeff Andich]

Ok, so if I understand correctly, if I git the kernel and checkout the 
4.4.y or 4.9.y branches and then build the kernel using build_kernel.sh 
with FULL_REBUILD defined, any updates to the mainline or the patchset 
could affect my build or functionality, right?

What is the best way to get updated when either the kernel and/or patch 
set(s) change?  What mailing lists do we need to join?

Thanks!!

jeff  

On Tuesday, January 2, 2018 at 8:48:10 AM UTC-6, RobertCNelson wrote:
>
> On Tue, Jan 2, 2018 at 8:41 AM, Jeff Andich <jeff@gmail.com 
> > wrote: 
> > 
> > FYI, I THINK I ran into something similar over the holidays when I tried 
> to 
> > fetch and build the 4.4.y and 4.9.y kernels using eewiki.  I tried both 
> BBB 
> > and BB-X15.  I ran into an issue with a build error in an assembly file 
> > which apparently had to do with some kind of networking package.  The 
> kernel 
> > built again, when this package was de-selected in makemenuconfig.  I was 
> > getting ready to post something on this, but then some time after 
> Christmas, 
> > I re-fetched everything using the instructions on eewiki and everything 
> > built again 
> > 
> > 
> > Regards and happy new year! 
>
> for 4.9.x it was me last week, i fubared up the pocketbeagle 
> simplegaming device tree binary. 
>
> also the wireguard patchset merge the last few weeks had some issues with 
> thumb2 
>
> But Wireguard + https://github.com/StreisandEffect/streisand + linode 
> (or any of the other supported ones) has been working awesome for me. 
> ;) 
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/25803f4d-5d82-40b7-a040-fcfd60b2e152%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: TI BSP failed to build kernel

[Jeff Andich]

Yep, wireguard was what I ended up removing from makemenuconfig..

Had no idea Streisand switched from singing/showbiz to Linux development!!

On Tuesday, January 2, 2018 at 8:48:10 AM UTC-6, RobertCNelson wrote:
>
> On Tue, Jan 2, 2018 at 8:41 AM, Jeff Andich <jeff@gmail.com 
> > wrote: 
> > 
> > FYI, I THINK I ran into something similar over the holidays when I tried 
> to 
> > fetch and build the 4.4.y and 4.9.y kernels using eewiki.  I tried both 
> BBB 
> > and BB-X15.  I ran into an issue with a build error in an assembly file 
> > which apparently had to do with some kind of networking package.  The 
> kernel 
> > built again, when this package was de-selected in makemenuconfig.  I was 
> > getting ready to post something on this, but then some time after 
> Christmas, 
> > I re-fetched everything using the instructions on eewiki and everything 
> > built again 
> > 
> > 
> > Regards and happy new year! 
>
> for 4.9.x it was me last week, i fubared up the pocketbeagle 
> simplegaming device tree binary. 
>
> also the wireguard patchset merge the last few weeks had some issues with 
> thumb2 
>
> But Wireguard + https://github.com/StreisandEffect/streisand + linode 
> (or any of the other supported ones) has been working awesome for me. 
> ;) 
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/3e8b6c33-6d57-4ea1-83a0-cf89f7a6ea93%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: u-boot failed to build

[Jeff Andich]

Hi,

Don’t know if this is your issue but...

How are you generating the .config file? When I build u-boot for the X15, I 
typically do a distclean, call another make command to generate the correct 
.config file from the appropriate defconfig  , and then throw the command to 
build u-boot.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/3191f159-87b3-41e4-a975-2b460af97a05%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Beagle Board X15 android

[Jeff Andich]

Hi,

*There was a post on BeagleBoard.org about a year ago which referenced this 
website where there appear to be more recent posts on Android for BBB:.
http://www.2net.co.uk/android4beagle.html

*It looks like TI now has an Android TI processor SDK for BB-X15.  Maybe 
you could compare the Marshmellow branch you built against the TI SDK 
(assuming the latter runs the way you expect) and then post up what you 
found on this site or the 2net site..

Thanks!

Jeff


On Wednesday, December 27, 2017 at 7:23:19 AM UTC-6, tony wrote:
>
>
> Hi ,
>
> I am trying to flash android in beagleboard-x15. I have cloned the source 
> from https://github.com/beagleboard/Android-X15  and am able to build and 
> flash the binaries successfully. While booting android it just hangs on 
> boot animation. 
>
> logcat 
> ---
> - beginning of main
> 01-01 00:00:00.579   139   139 W auditd  : type=2000 audit(0.0:1): 
> initialized
> 01-01 00:00:03.589   139   139 I auditd  : type=1403 audit(0.0:2): policy 
> loaded auid=4294967295 ses=4294967295
> 01-01 00:00:03.869 1 1 I init: type=1400 audit(0.0:3): avc: 
> denied { write } for name="ttyS2" dev="tmpfs" ino=3931 scontext=u:r:init:s0 
> tc
> ontext=u:object_r:hci_attach_dev:s0 tclass=chr_file permissive=1
> 01-01 00:00:07.779   155   155 I init: type=1400 audit(0.0:4): avc: 
> denied { execute_no_trans } for path="/system/bin/
> init.am57xevmboard.cpuset.sh
> " dev="mmcblk1p10" ino=211 scontext=u:r:init:s0 
> tcontext=u:object_r:system_file:s0 tclass=file permissive=1
> 01-01 00:00:07.821   151   151 I lowmemorykiller: Using in-kernel low 
> memory killer interface
> 01-01 00:00:08.269   154   154 I pvrsrvinit: type=1400 audit(0.0:5): avc: 
> denied { module_load } for scontext=u:r:pvr:s0 tcontext=u:r:pvr:s0 tclass=sy
> stem permissive=1
> - beginning of system
> 01-01 00:00:08.370   140   140 I vold: Vold 3.0 (the awakening) firing 
> up
> 01-01 00:00:08.370   140   140 V vold: Detected support for: ext4 vfat
> 01-01 00:00:08.386   140   159 V vold: /system/bin/sgdisk
> 01-01 00:00:08.386   140   159 V vold: --android-dump
> 01-01 00:00:08.386   140   159 V vold: /dev/block/vold/disk:179,0
> 01-01 00:00:08.479   165   165 I init: type=1400 audit(0.0:6): avc: 
> denied { ioctl } for path="/dev/ttyS2" dev="tmpfs" ino=3931 ioctlcmd=540e 
> scon
> text=u:r:init:s0 tcontext=u:object_r:hci_attach_dev:s0 tclass=chr_file 
> permissive=1
> 01-01 00:00:08.479   165   165 I sh  : type=1400 audit(0.0:7): avc: 
> denied { read write } for path="/dev/ttyS2" dev="tmpfs" ino=3931 
> scontext=u:r:
> shell:s0 tcontext=u:object_r:hci_attach_dev:s0 tclass=chr_file permissive=1
> 01-01 00:00:08.499   165   165 I sh  : type=1400 audit(0.0:8): avc: 
> denied { getattr } for path="/dev/ttyS2" dev="tmpfs" ino=3931 
> scontext=u:r:she
> ll:s0 tcontext=u:object_r:hci_attach_dev:s0 tclass=chr_file permissive=1
> 01-01 00:00:08.499   165   165 I sh  : type=1400 audit(0.0:9): avc: 
> denied { ioctl } for path="/dev/ttyS2" dev="tmpfs" ino=3931 ioctlcmd=5401 
> scon
> text=u:r:shell:s0 tcontext=u:object_r:hci_attach_dev:s0 tclass=chr_file 
> permissive=1
> 01-01 00:00:08.569   140   159 V vold: DISK mbr
> 01-01 00:00:08.569   140   159 V vold: PART 1 c
> 01-01 00:00:08.569   140   159 V vold: PART 2 83
> 01-01 00:00:08.978   153   153 I SurfaceFlinger: SurfaceFlinger is starting
> 01-01 00:00:09.000   153   153 I SurfaceFlinger: SurfaceFlinger's main 
> thread ready to run. Initializing graphics H/W...
> 01-01 00:00:09.037   153   153 D libEGL  : loaded 
> /vendor/lib/egl/libEGL_POWERVR_SGX544_116.so
> 01-01 00:00:09.378   153   153 D libEGL  : loaded 
> /vendor/lib/egl/libGLESv1_CM_POWERVR_SGX544_116.so
> 01-01 00:00:09.401   153   153 D libEGL  : loaded 
> /vendor/lib/egl/libGLESv2_POWERVR_SGX544_116.so
> 01-01 00:00:09.501   153   153 I ti_hwc  : Open omapdrm drm device (20)
> 01-01 00:00:09.762   153   153 I ti_hwc  : Set drm fd (20) to gralloc
> 01-01 00:00:09.762   153   153 D ti_hwc  : Transforming FB (1920x1080) => 
> (1920x1080) rot0
> 01-01 00:00:09.762   153   153 I ti_hwc  : Expecting h/w vsync for am57xevm
> 01-01 00:00:09.762   153   153 I ti_hwc  : Initializing hw vsync thread
> 01-01 00:00:09.762   153   153 I ti_hwc  : clone region is set to (0,0) to 
> (1920,1080)
> 01-01 00:00:09.762   153   153 I ti_hwc  : open_device(rgb_order=1 
> nv12_only=0)
> 01-01 00:00:09.762   153   153 I ti_hwc  : loading blitter module
> 01-01 00:00:09.762   153   153 E ti_hwc  : blitter module not found
> 01-01 00:00:09.762   153   153 I SurfaceFlinger: Using composer version 1.1
> 01-01 00:00:09.762   153   153 I SurfaceFlinger: EGL information:
> 01-01 00:00:09.763   153   153 I SurfaceFlinger: vendor: Android
> 01-01 00:00:09.763   153   153 I SurfaceFlinger: version   : 1.4 Android 
> META-EGL
> 01-01 00:00:09.763   153   153 I SurfaceFlinger: extensions: 
> EGL_KHR_get_all_proc_addresses 

[beagleboard] Re: Has Anyone Had Difficulty Outputting GPIO, UART, or I2C on the BB-X15's Expansion Header?

[Jeff Andich]

Ok, this is the kind of thing you just can't make up and I'm REALLY not 
trying to be the laughing stock of the internet, but here's what my issue 
was.  

The orientation of the mating Hirose connector on our PCBA breakout board 
(which plugs up under the BB-X15/572Xevm) is rotated 180 degrees w.r.t. the 
socket it connects to on the BB-X15. The Hirose connectors are keyed, so 
you cannot just rotate them around - probably for a good reason..

 So TestPoint #9 on our breakout board really interfaces with Pin #52 
instead of Pin #9 on the BB-X15's expansion header sockets.  So for 
instance, if you look at the BB-X15 schematic (e.g. REV_B1), instead of 
GPIO3_29, you would get VOUT1_D22.

So, I switched over to the latest Linux TI processor SDK, so I could post 
up questions on E2E, and the support engineer over there advised me to try 
all kinds of debugging techniques which turned out to be a pretty good 
tutorial.  

He had me use the DEVMEM2 command to examine and write to the pad control 
registers as well as the GPIO registers for the GPIO I was trying to 
enable. This seems potentially useful in that it could be used to confirm 
at least some of what the device tree is doing in addition to confirming 
that the pad configuration from u-boot jives with what you can read back 
from user space.

I'm still mystified by why  "you're supposed to" write to most of the pad 
control registers from the boot loader in isolation mode on the 57xx.  I 
remember one of the TI support engineers a while back mentioning something  
about a driver which can write to those registers from the kernel without 
causing glitch problems, but I never heard anything else about this.. 

In any case, I'll try to enable UARTs and GPIO's tomorrow, and will post up 
if there are continued issues, but I'm hoping this is the end of it...  
ARGH




On Monday, December 11, 2017 at 2:22:52 PM UTC-6, Jeff Andich wrote:
>
>
> My comments above about configuring the pinmux in u-boot SPL vs. the 
> kernel device tree are somewhat misleading per the  comments at the top of 
> the following commit:
>
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/am57xx-beagle-x15.dts?h=v4.15-rc2=d20f997b4d1f3fc41703c95e4f4bb4ebca90da42
>
> Except for the MMC, pinmuxing for the 5728 should only be done in 
> isolation mode (e.g. by a program such as the SPL running from internal 
> SRAM) and not in the kernel device tree
>
> If you attempt to re-configure the pinmux for everything else (not the 
> MMC), IO glitches can occur. I'm not sure what the implications of these 
> glitches are.
>
> Also, our TI rep advised to only do pinmuxing for the 5728 while in 
> isolation mode, except for the MMC, which has to be done in the kernel 
> device tree.
>
>
> On Friday, December 8, 2017 at 6:06:04 PM UTC-6, Jeff Andich wrote:
>>
>> Ok, here's some of what we tried today on the 572xEVM/BB-X15. Once again, 
>> we were able to get GPIO working on our custom hardware board with the 
>> 5728, but not yet on the 5728EVM/BB-X15.
>>
>>
>> 1) We re-configured a pin (VOUT1_D6 on header P18) on the expansion 
>> header which is normally used for LCD video on the 572xEVM/BB-X15.  
>>
>> 2) We first confirmed that this pin, VOUT1_D6, was producing signals on 
>> the p18 expansion header, pin #45 (which I'm guessing is video for the LCD 
>> touchscreen) with a running BB-X15 LXQT image.  This gave a measure of 
>> confidence that this expansion port pin is connected to something on the 
>> 5728, so it should be possible to put out GPIO on this expansion header 
>> pin, since the attached solder ball on the 5728 also has GPIO8_6 when you 
>> change MUX mode from 0 to 14..
>>
>> 3) We modified the pad configuration of VOUT_D6 in the SPL from  MuxMode, 
>> M0 to MuxMode 14 M14 by hacking the change directly into the operative pad 
>> configuration array entry (pad conf array delta array) for mux_data.h.  
>> {VOUT1_D6, (M14 | PIN_OUTPUT)}, /* vout1_d6.gpio8_6*/
>>
>> 4) We left the Pullup/Pulldown and slewcontrol bits the same as in 
>> VOUT_D6.  just changed M0 to M14!  I wasn't sure if this was correct, 
>> because other GPIO outputs like the 4 USR LEDs are configured as 
>> PIN_INPUT_PULLDOWN.  Not sure if the PU/PD state is related to the 
>> peripheral the PAD is connected to on the 5728 or what the peripheral 
>> connects to downstream.
>>
>> 5) We didn't change the IO delay array, as I didn't see any entries in 
>> the existing table for vout signals.
>>
>> 6) We then switched to a console image (uname_r 4.4.89-ti-r130 and 
>> /etc/dogtag= BeagleBoard.org Debian Image 2017-10-02) and then DD'ed the 
>> re-built SPL and u-boot.img t

[beagleboard] Re: Has Anyone Had Difficulty Outputting GPIO, UART, or I2C on the BB-X15's Expansion Header?

[Jeff Andich]

And the investigation continues in the following thread on E2E:


https://e2e.ti.com/support/arm/sitara_arm/f/791/p/649900/2388226#pi316653=1


Thanks and FYI,



On Monday, December 11, 2017 at 2:22:52 PM UTC-6, Jeff Andich wrote:
>
>
> My comments above about configuring the pinmux in u-boot SPL vs. the 
> kernel device tree are somewhat misleading per the  comments at the top of 
> the following commit:
>
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/am57xx-beagle-x15.dts?h=v4.15-rc2=d20f997b4d1f3fc41703c95e4f4bb4ebca90da42
>
> Except for the MMC, pinmuxing for the 5728 should only be done in 
> isolation mode (e.g. by a program such as the SPL running from internal 
> SRAM) and not in the kernel device tree
>
> If you attempt to re-configure the pinmux for everything else (not the 
> MMC), IO glitches can occur. I'm not sure what the implications of these 
> glitches are.
>
> Also, our TI rep advised to only do pinmuxing for the 5728 while in 
> isolation mode, except for the MMC, which has to be done in the kernel 
> device tree.
>
>
> On Friday, December 8, 2017 at 6:06:04 PM UTC-6, Jeff Andich wrote:
>>
>> Ok, here's some of what we tried today on the 572xEVM/BB-X15. Once again, 
>> we were able to get GPIO working on our custom hardware board with the 
>> 5728, but not yet on the 5728EVM/BB-X15.
>>
>>
>> 1) We re-configured a pin (VOUT1_D6 on header P18) on the expansion 
>> header which is normally used for LCD video on the 572xEVM/BB-X15.  
>>
>> 2) We first confirmed that this pin, VOUT1_D6, was producing signals on 
>> the p18 expansion header, pin #45 (which I'm guessing is video for the LCD 
>> touchscreen) with a running BB-X15 LXQT image.  This gave a measure of 
>> confidence that this expansion port pin is connected to something on the 
>> 5728, so it should be possible to put out GPIO on this expansion header 
>> pin, since the attached solder ball on the 5728 also has GPIO8_6 when you 
>> change MUX mode from 0 to 14..
>>
>> 3) We modified the pad configuration of VOUT_D6 in the SPL from  MuxMode, 
>> M0 to MuxMode 14 M14 by hacking the change directly into the operative pad 
>> configuration array entry (pad conf array delta array) for mux_data.h.  
>> {VOUT1_D6, (M14 | PIN_OUTPUT)}, /* vout1_d6.gpio8_6*/
>>
>> 4) We left the Pullup/Pulldown and slewcontrol bits the same as in 
>> VOUT_D6.  just changed M0 to M14!  I wasn't sure if this was correct, 
>> because other GPIO outputs like the 4 USR LEDs are configured as 
>> PIN_INPUT_PULLDOWN.  Not sure if the PU/PD state is related to the 
>> peripheral the PAD is connected to on the 5728 or what the peripheral 
>> connects to downstream.
>>
>> 5) We didn't change the IO delay array, as I didn't see any entries in 
>> the existing table for vout signals.
>>
>> 6) We then switched to a console image (uname_r 4.4.89-ti-r130 and 
>> /etc/dogtag= BeagleBoard.org Debian Image 2017-10-02) and then DD'ed the 
>> re-built SPL and u-boot.img to the uSD card.
>>
>> 7) We then checked the pin configuration by looking at 
>> /sys/kerne/debug/pinctl/4a003400.pinmux:
>> root@BeagleBoard-X15:/sys/kernel/debug/pinctrl/4a003400.pinmux# 
>> grep 35f4 *
>> pinmux-pins:pin 125 (4a0035f4.0): (MUX UNCLAIMED) (GPIO UNCLAIMED)
>> pins:pin 125 (4a0035f4.0) 0001000e pinctrl-single
>>
>> Note: The change from 0 to E in the least significant nibble confirms 
>> change in pad configuration from M0 to M14.
>> Note: My assumption is that the kernel reads in an has knowledge of the 
>> pad configuration on the BB-X15.  Assume that you don't have to configure 
>> the pad again in the device tree.  The only peripheral which gets its 
>> pinmux setup in the device tree on the 5728 is the MMC.  I believe this is 
>> all described in TI's SPRAC44 app note.  Please correct and clarify this 
>> statement as you see fit..
>>
>> 8) We attempted to set the gpio pin, gpio8_6 via sysfs (Note, there are 
>> no GPIO enable directives in the device tree yet!)
>>
>> Assume gpio8_6 is gpio 230 = [(8-1) * 32 + 6] = 230.
>>
>> /sys/class/gpio/echo 230 > export
>>
>> cat gpio230/direction = in
>>
>> echo out > gpio230/direction
>>
>> echo 1 >gpio230/value  ==> scope indicates pin #45 on connector, 
>> P18 is 0V.
>>
>> echo 0 >gpio230/value  ==> scope indicates pin #45 on connector, 
>> P18 is 0V.
>>
>>
>> So this didn't affect the voltage on pin #45 on the P18

Re: [beagleboard] Control de una protesis mioelectrica en BBB

[Jeff Andich]

I know nothing about myoelectric prosthesis and the processing and real 
time requirements for what this device is required to do.

Sounds like the thesis could entail an analysis of existing myoelectric 
prosthesis currently available, and selection of a range of 
computers/processors which are capable of realizing the requirements of a 
myoelectric prosthesis.  Maybe you can analyze requirements of existing 
systems and then work with a computer engineer to help pick suitable 
candidate processor platforms, and then  implement a prototype, and write 
that up??


 

On Wednesday, December 13, 2017 at 11:24:48 AM UTC-6, Wulf Man wrote:
>
> we do english here if you please
>
> On 12/13/2017 5:58 AM, juberth.r...@usc.edu.co  wrote:
>
> Cordial saludo 
>
> en este proceso de investigación se a sugeridor, realizar mi tesis sobre 
> el control de una prótesis mioelectrica utilizando beaglebone black, para 
> crear un entorno de aprendizaje para personas con discapacidad total 
> parcial de un miembro ya sea inferior o superior, utilizando la beaglebone 
> black comunicando esta poderoso hardware por medio de socket.
>
> estoy en proceso de investigación y recopilando información al respecto, 
> seria de mucha ayuda para poder perfilar la propuesta del proyecto su 
> posible vialidad del mismo en su desarrollo si alguna persona posee 
> información al respecto seria de gran ayuda. Al momento solo cuento con lo 
> investigado, y seria para hacer una propuesta seria y viable.
>
> Si posee información sobre la programación de la beaglebone black o 
> consejos que debo tomar en cuenta para su programación.
>
> Dicho lo anterior si no es claro, es para realizar una propuesta en un 
> semillo de investigación de mi universidad, con el nombre de entorno 
> didáctico para el control de una prótesis Mioelectrica en scilab utilizando 
> la beaglebone black, si alguna persona posee información al respecto o cree 
> que este proyecto no es de importancia por favor espero sus comentarios ya 
> que  es de vital importancia para realizar la propuesta a este semillo de 
> investigación. 
>
>   
>
> *La información de este mensaje y sus anexos son propiedad de la USC, es 
> de uso exclusivo de su destinatario intencional y puede contener 
>  información de carácter privado o confidencial. Cualquier revisión, 
> retransmisión, divulgación,  copia  o  uso  indebido de este documento y/o 
> sus anexos, está estrictamente prohibida y será sancionada legalmente.*
>
> Q Antes de imprimir este mensaje, asegúrate de que es necesario. Proteger 
> el medio ambiente está también en tu mano. 
> -- 
> For more options, visit http://beagleboard.org/discuss
> --- 
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/d7b49f33-30ed-4bab-9838-0757cb9291f1%40googlegroups.com
>  
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/8b564670-73c3-4443-aa22-ff21fb94934e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.