[beagleboard] Re: GPIO from PRU via OCP on a Beaglebone Black - Timing Issues

[Daniel Kulp]

One more thing you can try with the TI kernel if your kernel build has 
issues:

The biggest problem is the CPU going in and out of idle states.   Thus, you 
can install the cpufrequtils and linux-cpupower packages and then at boot 
run:

cpufreq-set -g performance
cpupower idle-set -d 1

(and maybe cpupower idle-set -d 0 )

The first will lock the cpu freq at 1Ghz.   The second will disable the 
very costly idle states in the processor.   I believe the M3 processor in 
the L4_WAKEUP is in charge of the power management stuff which includes the 
CPU idle settings.   Flipping the CPU out of idle seems to take a long time 
and blocks the bus while it waits.   Disabling that state helped a lot.
Alternatively, you can install the "bone" kernel which doesn't have the 
idle driver (or at least didn't early last year, not sure anymore).  
 Anyway, those had a huge impact, but still wasn't 100% which is why we 
decided to compile our own kernel completely disabling everything on the 
L4-WAKEUP.


Dan


On Thursday, March 25, 2021 at 3:01:56 PM UTC-4 Remy Porter wrote:

> > Personal plug:  I'd be happy to sell capes that don't use gpio0.  
> https://kulplights.com
> Heh, we've already got all the boards for this project. Maybe we'll 
> revisit that design in future projects, though. 
>
> Your software is definitely doing a *lot* more than ours, and certainly 
> much more than we need- we just listen for RGB data on a UDP socket. We, 
> uh… don't really treat them like lights, and instead as very large pixels 
> in a screen. All the mapping/direction/orientation stuff is handled in the 
> render stack, which we build custom for pretty much every project. Last one 
> was a Unity App that was part of a kiosk connected to a gigantic 
> chandelier. Our current project is *kinda* like an architectural scale 
> video wall with a C++/OpenCV app driving the pixels.
>
> I might give the FPP image a shot though, if building my own custom kernel 
> doesn't help. Your guidance on that was *super* helpful, though your FPP 
> kernel did *not* get along with our software (LEDs just didn't work- in 
> lieu of diagnosing that, I just opted to compile my own, which is going on… 
> right now).  Thanks a bunch!
>
> On Tuesday, March 23, 2021 at 4:17:37 PM UTC-4 d...@kulp.com wrote:
>
>> The debs for the kernel are at:
>> https://github.com/FalconChristmas/fpp-linux-kernel/tree/master/debs
>> do you should be able to update to our kernel fairly easy.If you need 
>> to start building your own kernel, I'd suggest grabbing a Beaglebone AI and 
>> building on that.   It's WAY faster for kernel building.  :).You can 
>> cross-compile from a debian x86_64, but I was never able to get that to 
>> actually produce proper .deb files that could be installed cleanly on the 
>> BBB so I pretty much just use the AI for kernel builds.  (It's actually the 
>> ONLY thing I use my AI for.)
>>
>> FPP provides a complete UI frontend for configuring the pixel strings and 
>> such and we do allow the various 4 channel types. It does a lot of 
>> other things as well.   That said, most of these things are done on the ARM 
>> side and not the PRU.  Part of trying to figure out the latency issue was 
>> seeing what make sense to do on the arm side and what works best on the PRU 
>> side.If you actually wanted to try FPP and see if FPP's optimized PRU 
>> code and kernel combination would work, you could use the FPP 4.6.1 image 
>> on an SD card (see the release assets at github).   You would just need to 
>> create a small json file in /opt/fpp/capes/bbb/strings to describe the 
>> pinout of your cape (use any of them in that directory as a starting point) 
>> and it should then "just work".  You would need to configure e1.31/artnet 
>> input universes on the Channel Input tab, put FPP in "bridge" mode, and 
>> then it should work like a normal light controller and accept pixel data.  
>>  (Or use DDP protocol which doesn't require configuring the input)
>>
>> Personal plug:  I'd be happy to sell capes that don't use gpio0.  
>> https://kulplights.com [image: Screen Shot 2021-03-23 at 4.01.22 PM.png]
>>
>>
>>
>> On Tuesday, March 23, 2021 at 3:49:47 PM UTC-4 Remy Porter wrote:
>>
>>> That is *super* helpful. Thanks a bunch. The pinlayout we're using on 
>>> our boards uses a lot of GPIO0 already, so it's definitely too late to 
>>> change on this. The way we're banging things out, all the GPIOs are being 
>>> hit at the same time, so the latency does appear to hit our strings. I'll 
>>> try giving your kernel a shot, though- that'll definitely help. And maybe 
>>> I'll move the GPIO0 bits over to the other PRU. I hate to have to do that, 
>>> but if it's what needs done, it's what needs done.
>>>
>>> Also, off topic, but poking at FPP: SK6182s support the WS281x protocol, 
>>> so you mostly already support them, but if you poke around at 
>>> ThrowingBagels approach a little, it's not a big push to get 32-bit support 
>>> for RGBW LEDs (we 

[beagleboard] Re: GPIO from PRU via OCP on a Beaglebone Black - Timing Issues

[Daniel Kulp]

Wow... You should have contact us before doing a lot of that.   I 
completely re-wrote most of the LEDScape code over the last couple years to 
completely optimize things in attempts to reduce some of the timing 
issues.   Porting to clpru and rproc was already part of that.   All my 
updates are in FPP ( https://github.com/FalconChristmas/fpp ).

Anyway, to answer your question, the issue is specific to GPIO0.   GPIO1-3 
is not affected by the massive latency issues.   Thus, the best option is 
to chose GPIO pins on GPIO1-3 and not use the GPIO0 pins.   That wasn't an 
option for me as we needed to output 48 strings.   In the FPP code, if 
nothing is using the second PRU (the second PRU could be used for DMX or 
pixelnet output), we divide the work and have one pru do the GPIO1-3 and 
the other do the GPIO0.If something IS using the other PRU, and the 
strings are short enough, then we split it on the one pru and do GPIO1-3 
first, then do the GPIO0's.   For the most part, that keeps the GPIO0 
problems from affecting all the strings so the random flashes would really 
just be on the GPIO0 strings.   In the case where the second PRU is used 
for something else AND the strings are longer, then we do have to do all 4 
GPIO's at once and all of them can be affected so it's definitely not a 
perfect solution.   

To minimize the issues (but not entirely eliminate) I do now build a custom 
4.19 kernel that disables most of the devices on the L4_WAKEUP 
interconnect.  Any power management and frequency scaling stuff causes huge 
issues with GPIO0 latencies so those are the most important things to 
disable. I think my notes are at:

https://github.com/FalconChristmas/fpp-linux-kernel/tree/master/bbb-kernel

Not sure if that helps enough for you.  Feel free to ask more questions.  :)
Dan





On Tuesday, March 23, 2021 at 1:45:51 PM UTC-4 Remy Porter wrote:

> For those that may remember the old LEDScape library, I've been working on 
> an updated version of that library, which focuses on strips instead of 
> matrices, uses rproc instead of UIO PRUSS, and updates the PRU assembly to 
> clpru from pasm. 
>
> Link: https://github.com/iontank/ThrowingBagels
>
> The key thing you need to know is that we hook up 32 addressable LED 
> strips and then use the PRU to bitbang out RGB(W) data. We use the PRU 
> because our timings need to be pretty precise- a few hundred nanoseconds 
> for each key phase of the operation. 
>
> Here's the important issue: we need to address all 32 GPIO pins from the 
> PRU, but not all of them are bound to the r30 register. So we need to go 
> through the OCP port. This is exactly how LEDScape worked, and continues to 
> work, just fine. We've never been able to get LEDScape working under 4.x 
> kernels, mostly because of UIO problems (which is what kicked off this 
> whole "move to rproc" thing).
>
> My upgrade, ThrowingBagels, uses basically the same core logic on the PRU, 
> just ported to clpru assembly and running on a 4.19 kernel. And seemingly 
> randomly, the timings hitch which causes the LEDs to flicker to the wrong 
> color. Phases of our bitbang operation will sometimes take almost twice as 
> long as they should- a sleep that should have been 600ns ends up taking 
> 1100ns. The only operation happening that doesn't have guaranteed timings 
> is writing to the GPIO pins via OCP, everything else we do happens entirely 
> in PRU DRAM. Since this appears to happen randomly, the hitch *must* be 
> coming from that OCP step, I assume.
>
> In support of that hypothesis, if I upgrade from the kernel that ships 
> with the "AM3358 Debian 10.3 2020-04-06 4GB eMMC IoT Flasher 
> "
>  
> image to the most recent 4.19 kernel, the problem becomes a lot more 
> infrequent. We're blasting this data out at 30fps, like video, and when cut 
> down on the number of services running and update the kernel, I can get the 
> glitches down from happening every few seconds, to happening every few tens 
> of seconds.
>
> My suspicion, and I can't quite prove anything, is that on 4.19 there's 
> something about the kernel or configuration that sometimes adds latency to 
> OCP writes, which wasn't there on 3.16. So my key question is: how do I 
> improve the timing consistency when the PRU uses OCP to write to DDR RAM? I 
> understand that it will never have *guaranteed* timing, but sometimes 
> it's hitting me with latencies of up to 500ns. Anything I can do to 
> minimize that latency would be a huge help.
>
> TL;DR: how can I make PRU->OCP->GPIO more consistent in its timing under a 
> 4.19 kernel?
>

-- 
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 

Re: [beagleboard] Google Summer of Code

[Daniel Block]

Jason (or anyone else), what would you recommend to a person just getting
started programming the C66x DSP cores on the BeagleBone AI board for this
summer of code?  If you recall I use the BBX-15 in my mechatronics class at
the University of Illinois and program the C66x DSP cores both with JTAG
and I have written my own Linux program running on the A15 cores to load
and run code on the C66x cores given a Hex file compiled by CCS 10.  This
DSP Load program works great in the release of Linux that I am running on
the A15 cores but I am afraid that as I upgrade to newer releases of Linux
my solution may break.  I would like to figure out remoteproc.  I have been
monitoring the beagleboard and TI forums and I have not come across a
simple example that programs the C66x cores to just toggle an LED or
something like that.  A simple example like that would help me understand
how to use remoteproc to load and run programs on the DSP cores.  Or if the
idea is to stick with OpenCL, from what I have been able to gather, a
default starter program is loaded to both DSP cores on boot.  Then when you
run your Linux app you are able to run code on the DSP cores somehow using
OpenCL.  Again a simple example here blinking an LED would be super
helpful, and even better if the LED was being blinked inside a SYS/BIOS
Clock object.
What are your thoughts?
 Dan

On Thu, Feb 4, 2021 at 3:49 PM Jason Kridner 
wrote:

> The BeagleBoard.org community has been a mentoring organization in Google
> Summer of code for 9 years now. This will be the first year students will
> have the opportunity to propose RISC-V projects!
>
> Also, with PRU support now uptream in GCC, doing low-latency projects on
> BeagleBone might be especially fun. Also, having the C66x DSP (also
> supported by GCC) in BeagleBone AI is another chance for some heterogenous
> processing fun.
>
> Visit beagleboard.org/gsoc to learn more and please help with the ideas
> page on the eLinux wiki.
> --
> BeagleBoard.org Foundation is a US-based 501(c)3 non-profit providing
> education and collaboration around open source hardware and software
>
> Use https://beagleboard.org/about/jkridner to schedule a meeting
>
> --
> 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/CAK8RMs3X_7pLpMC%2BHkhM0V91jwNRQuMs8aZCQHHN3b0vvB2Q0w%40mail.gmail.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/CAMTPGNaAps%2BP4Ef%3D-uKe7cpA9_OY%2B_C8ZgTBa0CV0-ntRn5UKQ%40mail.gmail.com.

Re: [beagleboard] TI AM335x vs. Octavio OSD3358

[Daniel Kulp]

> On Jan 30, 2021, at 10:36 PM, Richard Sewell  wrote:
> 
> Thanks Daniel, (cool site btw!) I have headers exactly the same on my 
> prototype board set up. Do you have any automation for soldering the female 
> headers or do you hand solder them? Someone has made an automatic header 
> soldering machine which is interesting, but quite a project 
> https://hackaday.com/2015/05/05/open-source-diy-soldering-robot/ 
> <https://hackaday.com/2015/05/05/open-source-diy-soldering-robot/> . I have 
> also heard of 'pin in paste' headers,  which would require some kind of 
> reflow process only on the edge of the board. I'm trying to avoid as many 
> manual assembly processes as possible. 

I’ve gone two different directions with this..

When volume was lower, I actually paid my 13yo son to solder them.  He wanted 
to save up for a new composite Baseball Bat so I paid him $3 for each one that 
he soldered.   At one point, he got good enough to do about 8 an hour (I can do 
about 9/10) so he made out pretty well.However, you could use this idea and 
maybe find a couple enterprising high school students or something that would 
like a socially distant work from home job that could be just a couple hours a 
day.   Give them $3 or $4 each and they’d make out really well once they got 
good at it.  (Assuming they have the soldering station or you could loan them 
one or something)

With higher volume, I’m just having the cape manufacturer do it.   They are 
more than happy to solder headers on and mount them onto the capes.   The trick 
here is getting them to the board manufacturer since the PB’s aren’t available 
everywhere or is very expensive in some locations.  Thus, it kind of depends on 
where you have your boards made.   I’ve had bunches of PB’s shipped to me, I’ve 
ripped them out of the retail packaging (to save weight/space) and then shipped 
them off to manufacture.   Anyway, talk to your board manufacturer. 

-- 
Daniel Kulp
d...@kulp.com - http://dankulp.com/blog

-- 
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/2BBA50A8-3325-41FE-A578-E8998DFE6913%40kulp.com.

Re: [beagleboard] TI AM335x vs. Octavio OSD3358

[Daniel Kulp]

On Friday, January 29, 2021 at 9:47:08 AM UTC-5 richard wrote:

> I'm prototyping on a pocketbeagle, but how to scale up for production or 
> ~1000 units is unclear. I can buy pocketbeagle retail for $25, but the 
> Octavia SIP lists on Digikey at $36 and I have to but 500 parts to get that 
> price . So it seems like integrating a pocketbeagle into my product would 
> be easier and more cost effective. The only bit I don't know is how to 
> solder down a pocketbeagle onto a larger board with automation, any ideas


I ended up with the same conclusion of just using the PocketBeagle.   My 
"capes" have the male pinheaders on them and we solder female headers on 
the underside of the PB.  

https://kulplights.com/product/k8-pb/
https://kulplights.com/product/k40d-pb/
https://kulplights.com/product/pocketscroller/
https://kulplights.com/product/k4-pb/

They all use the same "PocketBeagle with headers".



 

-- 
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/2c1a570e-34e8-47db-86ba-33828017a2f4n%40googlegroups.com.

Re: [beagleboard] BeagleV?

[Daniel Kulp]

Interesting…. It’s not in the functional diagram.   Awesome that they are 
there. 

Dan



> On Jan 13, 2021, at 8:52 PM, Raul Rathmann  wrote:
> 
> Yes,  what Vinicius said:
> 
> From TD4VM doc at: https://www.ti.com/product/TDA4VM
> 
> 7.11.5.24 PRU_ICSSG
> The device has integrated two identical PRU_ICSSG subsystems (PRU_ICSSG0 and 
> PRU_ICSSG1). The programmable nature of the PRU cores, along with their 
> access to pins, events and all device resources, provides flexibility in 
> implementing fast real-time responses, specialized data handling operations, 
> custom peripheral interfaces, and in offloading tasks from the other 
> processor cores in the device.  
> 
> That TD4VM is a real beast. I really look forward to being able to use the 
> 64-bit ARM cores as the 32-bit Linux world seems to be fading a bit. I also 
> use the PRUs for low-level I/O, need that hard real-time access.
> 
> I would really like to see a bunch more I/Os available. The Beaglebone format 
> is nice size-wise but really seems to constrict access to more of the IO 
> goodness.
> 
> Maybe a carrier-board format similar to Pi Compute or Jetson?
> 
> 
> On Wednesday, January 13, 2021 at 4:27:50 PM UTC-8 vinicius...@gmail.com 
> wrote:
> I was looking the TD4VM and there is 2 prus :)
> 
> Em qua., 13 de jan. de 2021 às 20:43, Vinicius Juvinski 
> > 
> escreveu:
> I have the same question as you Daniel,
> the PRU in my opinion is one of the most killer feature of beaglebone and I'm 
> already using BBAI Pru and the 4 PRU's on AI is extremely welcome.
> Jason, any chance to have PRU with this revision 2 BBAI board?
> 
> Em qua., 13 de jan. de 2021 às 20:38, Daniel Kulp  > escreveu:
> The TDA4VM doesn't have PRU's.   Does that mean use of PRU's is now 
> "deprecated" and discouraged?
> 
> Dan
> 
> 
> On Wednesday, January 13, 2021 at 1:43:02 PM UTC-5 Jason Kridner wrote:
> BeagleV is something new in addition to BeagleBoard and BeagleBone offerings 
> from BeagleBoard.org. It is meant to address the needs coming from the RISC-V 
> community for a low-cost development board, ultimately with a path to 
> production. We still have a roadmap for BeagleBone!
> 
> So, I'll share what I should have shared before, but am still ironing out 
> details on schedule as we are executing this...
> 
> There's a minor tweak to BeagleBone AI rev A1a to rev A2, but I'm not sure if 
> it'll go into full production as we have started a rev B with the TDA4VM 
> device from TI. It jumps to A72s and has better software support for the AI 
> accelerators.
> 
> One project I'm most excited about is an update to BeagleBone Blue (rev C, 
> rev B used the smaller SIP but had unrelated issues that never got resolved 
> and therefore never got released). I need some more stuff to be released from 
> TI to share more details there, but the motor drive capability will be 
> boosted to enable direct drive of BLDC quadrotors and 3-phase steppers.
> 
> And, I'm very, very excited about BeagleConnect technology being worked on at 
> https://github.com/jadonk/beagleconnect 
> <https://github.com/jadonk/beagleconnect> based on TI CC1352. This still has 
> a long way to productize, but it is really interesting tech!
> 
> We also have some cool stuff being worked by BeagleBoard Compatible makers in 
> the BeagleBone space. For that matter, SeeedStudio BeagleBone Green Gateway 
> hasn't been out very long.
> 
> Anyway, the short answer is BeagleV an in-addition-to-BeagleBone thing, not 
> moving away from it.
> 
> If interested in BeagleV, please register your interest at BeagleV.org. If 
> you already did so with Seeed, no need to replicate.
> 
> On Wed, Jan 13, 2021 at 8:39 AM johan.he...@gmail.com <> 
> > wrote:
> 
> I got a mail message from seeed that introduced the BeagleV. 
> 
> Although I am very hopeful for a complete opensource hardware and software 
> platform, I noticed that the pin-layout and the compatibility of the 
> ARM-Beagleboards has been abandoned. 
> 
> I also noticed on the specs that the GPIO pins could be used for any kind of 
> communication protocol, be it UART, SPI, SDIO etc. 
> 
> I am currently using 3 UART ports on a BeagleBone to communicate with some 
> peripherals. 
> 
> Would that still be possible in the new design?
> 
> I also noted the RS485, or Canbus was not described in the IO.
> 
> Can anyone involved in the design comment on these observations?
> (Why abandon the old pin layout, how to implement three UARTS or 2 I2C's, and 
> why no CANBus  availability)
> 
> Kind Regards
> Johan Henselmans
> 
> 
> 
> -- 
> For 

Re: [beagleboard] BeagleV?

[Daniel Kulp]

The TDA4VM doesn't have PRU's.   Does that mean use of PRU's is now 
"deprecated" and discouraged?

Dan


On Wednesday, January 13, 2021 at 1:43:02 PM UTC-5 Jason Kridner wrote:

> BeagleV is something new in addition to BeagleBoard and BeagleBone 
> offerings from BeagleBoard.org. It is meant to address the needs coming 
> from the RISC-V community for a low-cost development board, ultimately with 
> a path to production. We still have a roadmap for BeagleBone!
>
> So, I'll share what I should have shared before, but am still ironing out 
> details on schedule as we are executing this...
>
> There's a minor tweak to BeagleBone AI rev A1a to rev A2, but I'm not sure 
> if it'll go into full production as we have started a rev B with the TDA4VM 
> device from TI. It jumps to A72s and has better software support for the AI 
> accelerators.
>
> One project I'm most excited about is an update to BeagleBone Blue (rev C, 
> rev B used the smaller SIP but had unrelated issues that never got resolved 
> and therefore never got released). I need some more stuff to be released 
> from TI to share more details there, but the motor drive capability will be 
> boosted to enable direct drive of BLDC quadrotors and 3-phase steppers.
>
> And, I'm very, very excited about BeagleConnect technology being worked on 
> at https://github.com/jadonk/beagleconnect based on TI CC1352. This still 
> has a long way to productize, but it is really interesting tech!
>
> We also have some cool stuff being worked by BeagleBoard Compatible makers 
> in the BeagleBone space. For that matter, SeeedStudio BeagleBone Green 
> Gateway hasn't been out very long.
>
> Anyway, the short answer is BeagleV an in-addition-to-BeagleBone thing, 
> not moving away from it.
>
> If interested in BeagleV, please register your interest at BeagleV.org. If 
> you already did so with Seeed, no need to replicate.
>
> On Wed, Jan 13, 2021 at 8:39 AM johan.he...@gmail.com <
> johan.he...@gmail.com> wrote:
>
>>
>> I got a mail message from seeed that introduced the BeagleV. 
>>
>> Although I am very hopeful for a complete opensource hardware and 
>> software platform, I noticed that the pin-layout and the compatibility of 
>> the ARM-Beagleboards has been abandoned. 
>>
>> I also noticed on the specs that the GPIO pins could be used for any kind 
>> of communication protocol, be it UART, SPI, SDIO etc. 
>>
>> I am currently using 3 UART ports on a BeagleBone to communicate with 
>> some peripherals. 
>>
>> Would that still be possible in the new design?
>>
>> I also noted the RS485, or Canbus was not described in the IO.
>>
>> Can anyone involved in the design comment on these observations?
>> (Why abandon the old pin layout, how to implement three UARTS or 2 I2C's, 
>> and why no CANBus  availability)
>>
>> Kind Regards
>> Johan Henselmans
>>
>>
>> -- 
>> 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/3cc933a3-b647-4fe4-b24b-9ba03c478f1fn%40googlegroups.com
>>  
>> 
>> .
>>
>
>
> -- 
> https://beagleboard.org/about/jkridner - a 501c3 non-profit educating 
> around open hardware computing
>

-- 
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/63df07cc-33ac-4be3-8860-93111ccdf3c3n%40googlegroups.com.

[beagleboard] Correct way to Update BBX15 Kernel to preempt_rt Kernel?

[Daniel Block]

I found Mark Yoder's instructions for updating the BeagleBone's kernel to 
the preempt_rt kernel at https://elinux.org/EBC_Exercise_36_PREEMPT_RT  
 Thanks Mark.
  
I performed the same steps on my BeagleBoard X15 board except I used the 
command:
sudo ./update_kernel.sh --ti-rt-kernelinstead of  sudo 
./update_kernel.sh --bone-rt-kernel

Was that correct for the BBX15?  It ran and seems to have updated the 
kernel to the rt kernel according to uname -a.  I saw a few warnings as the 
install printed messages to the console so I want to make sure I performed 
this correctly.  

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/d748db93-850f-48b3-8fa2-c68962902683o%40googlegroups.com.

[beagleboard] Re: Problems reading PRU data RAM from host side on beaglebone black

[Daniel Kulp]

For the pure asm  part of this  

You can look at the FPP PRU code:
https://github.com/FalconChristmas/fpp/tree/master/src/pru
and the sh scripts in there used to compile the asm.The FPP PRU code is 
all hand tuned assembly and does NOT use the C runtime/stack at all.  Thus, 
the entire memory blocks are available to the pru assembly code.   

You basically need to get the "ResourceTable.asm" included, set the "main" 
section text segment, and then pass the right flags to clpru.  The results 
"out" can then be loaded via rproc.

Dan


On Monday, July 20, 2020 at 4:58:13 PM UTC-4 hans...@gmail.com wrote:

>
> Another option I am trying is to have the PRUs write data to DRAM memory 
> directly.  I really want to do this in assembly because my PRU code has 
> some tight timing.  I couldn't find any examples online to do this with the 
> rproc driver however. Any ideas?
>

-- 
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/75b11b9a-85e8-4b4d-a13a-e8004bff78ccn%40googlegroups.com.

[beagleboard] Re: PocketScroller pin out

[Daniel Kulp]

The newer pocketscrollers are use a slightly different pinout than the 
originals.  The OE line was moved to a pin that could use the PWM hardware 
in hopes of updating the PRU code to use that, but I never got around to 
doing that. 

If you are using one of the newer PocketScrollers with the OLED 
header/buttons, then you can SSH into the FPP instance and look in 
/home/fpp/media/tmp/panels and there is a JSON file that describes the pins 
the various outputs use.  If using the older PocketScroller without the 
eeprom, you would look in /opt/fpp/capes/pb/panels/PocketScroller.json.

Dan


On Friday, June 12, 2020 at 4:39:13 PM UTC-4, Mark A. Yoder wrote:
>
> I have a PocketScroller on my Pocket Beagle.  In the past I've had no 
> trouble running fpp on it.
>
> Now I want to drive it directly from by own PRU code[1].  The code worked 
> fine when I hand wired the P10 panel to my Pocket Beagle, but I don't know 
> how things are attached internally so the
> code doesn't work.  
>
> Is there a schematic I could reference?
>
> Thanks...
>
> --Mark
>
> [1] 
> https://github.com/MarkAYoder/PRUCookbook/blob/master/docs/05blocks/code/rgb1.c
>

-- 
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/88ac14cf-b75f-4d9c-9da3-a07ad206e936o%40googlegroups.com.

Re: [beagleboard] config-pin for gpio output

[Daniel Kulp]

The GPIO utils in FPP use a combination 
of /sys/devices/platform/ocp/ocp:%s_pinmux/state 
and /sys/class/gpio/gpio%u/ locations to configure the pin in various 
ways.   See:

https://github.com/FalconChristmas/fpp/blob/master/src/util/BBBUtils.cpp#L228

Some of it is a bit complex as some pins may need to boot up in i2c mode 
but then be flipped to gpio/out. 

The idea of using libgpiod is "ok" but doesn't allow configuring the 
internal pull ups for the input (at least until kernel 5.4 and a newer 
version of libgpiod)

Dan



On Friday, June 5, 2020 at 7:06:48 AM UTC-4, Drew Fustini wrote:
>
> On Fri, Jun 5, 2020 at 6:58 AM TJF > 
> wrote: 
> > 
> > Am Mittwoch, 3. Juni 2020 16:27:38 UTC+2 schrieb RobertCNelson: 
> >> 
> >> The proper way is to use libgpiod tools such as gpioset ;) 
> > 
> > 
> > The proper way is to use libpruio and do pinmuxing single source in the 
> code ;) 
> > 
> > pruio_gpio_setValue(io, P9_11, [0,1]); 
>
> How does the library change the pinmux during runtime? 
>
> Does it use /sys/devices/platform/ocp/ocp:P9_11_pinmux/state? (which 
> is created by bone-pinmux-helper) 
>
> thanks, 
> drew 
>

-- 
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/22759d88-d8da-431b-bf4c-6ada232fefc6o%40googlegroups.com.

Re: [beagleboard] Re: Trouble using config-pin to config P9.28 pin as spi or gpio

[Daniel Kulp]

On Monday, May 18, 2020 at 2:17:36 PM UTC-4, pstei...@gmail.com wrote:
>
> It is a BBGW.  Sorry I forgot to mention that initially.  So this is the 
> answer, i.e. these pins are not available on the BBGW, I'm assuming there 
> is no way to make the available either. Thanks Dan.  I'll go to mark your 
> answer as correct.
>

Not if you want WIFI and/or bluetooth to work, no.   This is the main 
reason I regard the BBBW as the worst of the Beagles and strongly recommend 
my customer/users to not get one.   The BBBW put the wifi adapter on pins 
that were otherwise unused so all the pins that are pulled out to the 
header still "work".   The BBGW, on the other hand, uses a bunch of the 
pins for wifi and bluetooth.   I'm not really sure why.  There is likely 
some sort of history that I'm not aware of.  Maybe a "wifi" cape (which 
would obviously need to use pins on the headers) that they then just moved 
the cape components right onto the beagle as-is.  

Dan


 

>
> Paul
>
> On Monday, May 18, 2020 at 11:06:36 AM UTC-5, evilwulfie wrote:
>>
>> LOL   i had this issue on a bunch of boards i bought.
>>
>> They misprogrammed the eeprom. you will need to write the correct info 
>> into
>> the eeprom. When i notified the company that made the boards they did not 
>> give a shit.
>>
>>
>> On 5/18/2020 6:47 AM, Daniel Kulp wrote:
>>
>>
>> This looks like it's being detected as a BBG Wireless and not a regular 
>> BBG.None of those pins are available on the BBGW. 
>>
>> Dan
>>
>>
>> On Saturday, May 16, 2020 at 9:29:10 PM UTC-4, pstei...@gmail.com wrote: 
>>>
>>> Hi,
>>> I'm trying to fix an error in my beaglebone green in which several PRU 
>>> pin directories are not available.  I'm using image 4.19.50-ti-r20. I'm 
>>> using, Debian 10.2 which I have experienced as working well with the BBB 
>>> and BBG.  The pins directories that don't show up are a sub-set of the 35 
>>> or so real time PRU I/O pins. These pins are supposed to be available are 
>>> subdirectories of /sys/devices/platform/ocp/, as  follows:
>>>  ocp:P8_11_pinmux
>>>  ocp:P8_12_pinmux*
>>>  ocp:P8_14_pinmux
>>>  ocp:P8_15_pinmux*
>>>  ocp:P8_16_pinmux
>>>  ocp:P8_17_pinmux
>>>  ocp:P8_18_pinmux
>>>  ocp:P9_28_pinmux*
>>>  ocp:P9_29_pinmux*
>>>  ocp:P9_30_pinmux*
>>>  ocp:P9_31_pinmux*
>>>
>>> The ones (6 of them) with the asterisk are the real time PRU Input / 
>>> Output pins that I really really need for my application.
>>>
>>> Notes: 
>>> This is on the Beaglebone Green, not the Beaglebone Black, I'll check if 
>>> the same problem shows up on BBB as well a little later...
>>> This is image 4.19
>>> I have already gone into the /boot/uEnv.txt file and disabled the 
>>> following: HDMI, audio, emmc.  But I still have this same problem.
>>>
>>> Is this a bug in the kernel / image ?  
>>>
>>> In reviewing page 211 of Derek Molloy's Exploring Beaglebone book, I 
>>> can't see a pattern of all these pins belonging to a certain interface, so 
>>> I cannot even guess  what interface might be causing them to become not 
>>> available.
>>>
>>> Please let me know if you have any ideas on this.
>>> Thanks!!
>>>
>>>
>>>
>>> On Tuesday, January 24, 2017 at 6:42:30 AM UTC-6, Lindo wrote: 
>>>>
>>>> Hi,
>>>>
>>>> I'm trying to use cdsteinkuehler's beaglebone-universal-io 
>>>> <https://github.com/cdsteinkuehler/beaglebone-universal-io> to config 
>>>> P9_28-31 as spi interface. After loading cape-universal overlay first, I 
>>>> got the "P9_28 pinmux file not found!" message when I configure P9_28 pin 
>>>>
>>>> config-pin P9.28 spi
>>>> P9_28 pinmux file not found!
>>>> cape-universala overlay not found
>>>> run "config-pin overlay cape-universala" to load the cape
>>>>
>>>>
>>>> I think P9.28 might not actually exported, and then I found that the 
>>>> cape-univeral-00A0.dts file on the github website is different with 
>>>> RobertCNelson's version(I found this file under 
>>>> /opt/source/bb.org-overlays/src/arm/). see detail here: 
>>>> https://www.diffchecker.com/BivnZllE
>>>>
>>>> Is this a bug? or I was doi

[beagleboard] Re: Trouble using config-pin to config P9.28 pin as spi or gpio

[Daniel Kulp]

This looks like it's being detected as a BBG Wireless and not a regular 
BBG.None of those pins are available on the BBGW.

Dan


On Saturday, May 16, 2020 at 9:29:10 PM UTC-4, pstei...@gmail.com wrote:
>
> Hi,
> I'm trying to fix an error in my beaglebone green in which several PRU pin 
> directories are not available.  I'm using image 4.19.50-ti-r20. I'm using, 
> Debian 10.2 which I have experienced as working well with the BBB and BBG.  
> The pins directories that don't show up are a sub-set of the 35 or so real 
> time PRU I/O pins. These pins are supposed to be available are 
> subdirectories of /sys/devices/platform/ocp/, as  follows:
>  ocp:P8_11_pinmux
>  ocp:P8_12_pinmux*
>  ocp:P8_14_pinmux
>  ocp:P8_15_pinmux*
>  ocp:P8_16_pinmux
>  ocp:P8_17_pinmux
>  ocp:P8_18_pinmux
>  ocp:P9_28_pinmux*
>  ocp:P9_29_pinmux*
>  ocp:P9_30_pinmux*
>  ocp:P9_31_pinmux*
>
> The ones (6 of them) with the asterisk are the real time PRU Input / 
> Output pins that I really really need for my application.
>
> Notes: 
> This is on the Beaglebone Green, not the Beaglebone Black, I'll check if 
> the same problem shows up on BBB as well a little later...
> This is image 4.19
> I have already gone into the /boot/uEnv.txt file and disabled the 
> following: HDMI, audio, emmc.  But I still have this same problem.
>
> Is this a bug in the kernel / image ?  
>
> In reviewing page 211 of Derek Molloy's Exploring Beaglebone book, I can't 
> see a pattern of all these pins belonging to a certain interface, so I 
> cannot even guess  what interface might be causing them to become not 
> available.
>
> Please let me know if you have any ideas on this.
> Thanks!!
>
>
>
> On Tuesday, January 24, 2017 at 6:42:30 AM UTC-6, Lindo wrote:
>>
>> Hi,
>>
>> I'm trying to use cdsteinkuehler's beaglebone-universal-io 
>>  to config 
>> P9_28-31 as spi interface. After loading cape-universal overlay first, I 
>> got the "P9_28 pinmux file not found!" message when I configure P9_28 pin
>>
>> config-pin P9.28 spi
>> P9_28 pinmux file not found!
>> cape-universala overlay not found
>> run "config-pin overlay cape-universala" to load the cape
>>
>>
>> I think P9.28 might not actually exported, and then I found that the 
>> cape-univeral-00A0.dts file on the github website is different with 
>> RobertCNelson's version(I found this file under 
>> /opt/source/bb.org-overlays/src/arm/). see detail here: 
>> https://www.diffchecker.com/BivnZllE
>>
>> Is this a bug? or I was doing wrong somewhere? 
>>
>> Thanks!
>> Lindo
>>
>>

-- 
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/e0a42c84-84c4-42c1-b4d0-a1dfc6be2649%40googlegroups.com.

[beagleboard] How to build u-boot for BBB from the TI SDK and flash u-boot into BBB?

[Daniel Cheng]

Hi all

I am newer for BBB.

I read the document:
https://www.digikey.com/eewiki/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-Bootloader:U-Boot
But the source code is not from TI SDK.

I want to build u-boot from TI SDK and flash u-boot into BBB.

Could anyone help me?

Thanks

Daniel

-- 
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/84e175ce-e466-45c4-9958-3059097941be%40googlegroups.com.

Re: [beagleboard] Re: PocketBeagle Boot Time

[Daniel Kulp]

The first step would be to delete any initrd images in /boot.   That will 
likely chop about 10 seconds off the "kernel" time.   I'm not sure why 
we're creating the initrd things.  



On Sunday, April 19, 2020 at 3:38:00 PM UTC-4, rpau...@gmail.com wrote:
>
> Thanks.  I will look at that thread.  My recent efforts have resulted in 
> negative process.  
>
> Startup finished in 17.476s (kernel) + 41.899s (userspace) = 59.376s
>
>  
>
> *From:* beagl...@googlegroups.com   > *On Behalf Of *TJF
> *Sent:* Saturday, April 18, 2020 2:04 PM
> *To:* BeagleBoard >
> *Subject:* [beagleboard] Re: PocketBeagle Boot Time
>
>  
>
> On BBB:
>
>  
>
> $ systemd-analyze 
>
> Startup finished in 1.067s (kernel) + 15.828s (userspace) = 16.896s
>
>  
>
> Booting with USB WiFi stick including connection with static IP adress. 
> Should be possible with PocketBeagle as well. Find details at
>
>  
>
> https://groups.google.com/d/msg/beagleboard/CN5qKSmPIbc/9yNlI-w1AQAJ
>
>  
>
>  
>
> -- 
> 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 beagl...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/2a75d9fa-0cfa-4c4c-b29a-98c7a424caeb%40googlegroups.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/9de2a436-e717-4cc0-8571-8803f46bfb4d%40googlegroups.com.

[beagleboard] Re: Help getting started with modifying the Device Tree

[Daniel Block]

Just want to confirm the correct way to proceed.  What I did was login to 
my BB-X15 in a terminal.  I changed directory to
/opt/source/dtb-4.14-ti/ and then I typed  
make
and it performed the build.
I did not do a, sudo make install, because I did not make any changes to 
the .dts files
So now that I know how to do that, what is my next step when I want to make 
changes?  Do I find the .dts file that has the I/O pins I need to change or 
add and then in a text editor make my changes and then build?  Or is it 
recommended that I clone the repository over top of the files in the 
/opt/source/dtb-4.14-ti/ folder and then make modifications to those files 
in a text editor and build, doing this all on the BB-X15?
Also which dts files are used by the BB-X15 and BBAI?  The obvious ones are 
the AM57xx-bealge-x15- files but are any of the dra7 and OMAP5 files used 
for the BBX15?  Finally if I find an I/O pin that is not set in any of the 
.dts files how do I determine the best file to modify to add that pin?  

Thanks  


On Monday, April 6, 2020 at 9:19:06 AM UTC-5, Daniel Block wrote:
>
> Can anyone give me some good web links and/or documents that would get me 
> started working with and modifying the Device Tree for both the BeagleBone 
> AI and BeagleBoard X15?  (Or probably for BeagleBone Black would also help 
> a bunch)  I have been monitoring these Beagleboard Google groups for a 
> while now and I believe I have some idea of what needs to be done but if 
> there is a "how to" out there it would save me time.  From what I have 
> gathered, it sounds like the modified device tree can be modified and 
> recompiled on the BeagleBoard X15 (or AI) itself not requiring a separate 
> cross compiling computer.  (If I need to, I can setup a cross compiling 
> system).  I come at these TI processors looking at the DSP cores first when 
> it comes to I/O and peripherals and then Linux comes second.  I am 
> switching from the OMAPL138 processor to these AM5729 processors.  Because 
> I come at these processors from the DSP end I find it much easier to 
> perform I/O and peripheral setup from Linux using dev/mem like this 
> discussion 
> https://groups.google.com/forum/#!category-topic/beagleboard/beaglebone-ai/uKoSJUQaXH4
>   
> During this time of COVID-19 shutdown I thought I could figure out how to 
> doing things the correct Linux way and device trees is the first step.
>

-- 
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/bf5d54f6-2aea-413d-b775-722177b9bbca%40googlegroups.com.

[beagleboard] Re: Help getting started with modifying the Device Tree

[Daniel Block]

Thanks Robert I will look at this repository.  
Dan


On Monday, April 6, 2020 at 9:19:06 AM UTC-5, Daniel Block wrote:
>
> Can anyone give me some good web links and/or documents that would get me 
> started working with and modifying the Device Tree for both the BeagleBone 
> AI and BeagleBoard X15?  (Or probably for BeagleBone Black would also help 
> a bunch)  I have been monitoring these Beagleboard Google groups for a 
> while now and I believe I have some idea of what needs to be done but if 
> there is a "how to" out there it would save me time.  From what I have 
> gathered, it sounds like the modified device tree can be modified and 
> recompiled on the BeagleBoard X15 (or AI) itself not requiring a separate 
> cross compiling computer.  (If I need to, I can setup a cross compiling 
> system).  I come at these TI processors looking at the DSP cores first when 
> it comes to I/O and peripherals and then Linux comes second.  I am 
> switching from the OMAPL138 processor to these AM5729 processors.  Because 
> I come at these processors from the DSP end I find it much easier to 
> perform I/O and peripheral setup from Linux using dev/mem like this 
> discussion 
> https://groups.google.com/forum/#!category-topic/beagleboard/beaglebone-ai/uKoSJUQaXH4
>   
> During this time of COVID-19 shutdown I thought I could figure out how to 
> doing things the correct Linux way and device trees is the first step.
>

-- 
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/3e478c37-b7a4-4523-aefd-7e8ce8a498dc%40googlegroups.com.

[beagleboard] Help getting started with modifying the Device Tree

[Daniel Block]

Can anyone give me some good web links and/or documents that would get me 
started working with and modifying the Device Tree for both the BeagleBone 
AI and BeagleBoard X15?  (Or probably for BeagleBone Black would also help 
a bunch)  I have been monitoring these Beagleboard Google groups for a 
while now and I believe I have some idea of what needs to be done but if 
there is a "how to" out there it would save me time.  From what I have 
gathered, it sounds like the modified device tree can be modified and 
recompiled on the BeagleBoard X15 (or AI) itself not requiring a separate 
cross compiling computer.  (If I need to, I can setup a cross compiling 
system).  I come at these TI processors looking at the DSP cores first when 
it comes to I/O and peripherals and then Linux comes second.  I am 
switching from the OMAPL138 processor to these AM5729 processors.  Because 
I come at these processors from the DSP end I find it much easier to 
perform I/O and peripheral setup from Linux using dev/mem like this 
discussion 
https://groups.google.com/forum/#!category-topic/beagleboard/beaglebone-ai/uKoSJUQaXH4
  
During this time of COVID-19 shutdown I thought I could figure out how to 
doing things the correct Linux way and device trees is the first step.

-- 
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/e78952e8-c963-459a-86a4-02c532634848%40googlegroups.com.

Re: [beagleboard] Re: Need advice on how to reduce boot time

[Daniel Kulp]

The first big gap is likely due to an initrd image.   For my apps, we do a 
"rm -rf /boot/initrd.img*" after creating the image which easily cuts 10 
seconds or so off of boot time.

After boot, you can run "systemd-analyze plot > plot.svg" and view the svg 
to see what's going on.   I definitely found a few of our own scripts were 
taking a LONG time but splitting them into separate services that can be 
run in parallel helped a lot.

On Tuesday, March 3, 2020 at 2:46:13 PM UTC-5, Hans Leeuw wrote:
>
> Hi all,
>
> I am following this discussion with great interest. I am using the 
> PocketBeagle on a musical instrument and it should not take too long to 
> start it up or I miss that all important firsts note!! I am using a 
> PocketBeagle with Linux beaglebone 4.14.108-ti-r127 #1 SMP PREEMPT Wed 
> Jan 29 04:10:14 UTC 2020 armv7l GNU/Linux. I used the console image from e
> linux.org.
> I see a few big gaps in the start up as well. Apart from the filesystem 
> mount which takes a long time (in my case 16+ seconds), there is also a 
> huge gap before the PRU comes online (a gap of 28 seconds!!!). I am 
> suspecting the Edimax USB Wifi driver since I see the same even larger gap 
> on my other (standard) image around the startup of that device. Is this 
> normal, is this something to report or does anyone know a solution or 
> direction in which to look?
>
> dmesg
>
> ..
>
> [1.438453] usb 2-1: new high-speed USB device number 2 using musb-hdrc
>
> [1.586756] usb 2-1: New USB device found, idVendor=1a40, 
> idProduct=0101
>
> [1.586773] usb 2-1: New USB device strings: Mfr=0, Product=1, 
> SerialNumber=0
>
> [1.586781] usb 2-1: Product: USB 2.0 Hub
>
> [1.587979] hub 2-1:1.0: USB hub found
>
> [1.588121] hub 2-1:1.0: 4 ports detected
>
> [1.590052] PM*: bootloader does not support rtc-only!*
>
> [   18.885434] EXT4-fs (mmcblk0p1): mounted filesystem with ordered data 
> mode. Opts: (null)
>
> [   19.524350] systemd[1]: System time before build time, advancing clock.
>
> [   19.629059] ip_tables: (C) 2000-2006 Netfilter Core Team
>
> [   19.670063] systemd[1]: systemd 232 running in system mode. (+PAM 
> +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP 
> +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN)
>
> [   19.671004] systemd[1]: Detected architecture arm.
>
> [   19.673162] systemd[1]: Set hostname to .
>
> [   20.251318] systemd[1]: Listening on fsck to fsckd communication 
> Socket.
>
> [   20.252772] systemd[1]: Listening on Journal Audit Socket.
>
> [   20.253398] systemd[1]: Started Forward Password Requests to Wall 
> Directory Watch.
>
> [   20.253851] systemd[1]: Listening on udev Control Socket.
>
> [   20.255661] systemd[1]: Created slice System Slice.
>
> [   20.260328] systemd[1]: Mounting /sys/kernel/debug...
>
> [   20.262000] systemd[1]: Created slice system-getty.slice.
>
> [   21.187890] EXT4-fs (mmcblk0p1): re-mounted. Opts: errors=remount-ro
>
> [   21.782096] systemd-journald[1387]: Received request to flush runtime 
> journal from PID 1
>
> [   25.913687] nf_conntrack version 0.5.0 (8192 buckets, 32768 max)
>
> [   27.173192] *using random self ethernet address*
>
> [   27.173212] *using random host ethernet address*
>
> [   27.387371] *using random self ethernet address*
>
> [   27.387390] *using random host ethernet address*
>
> [   27.491447] usb0: HOST MAC 5a:4e:7b:a0:01:c1
>
> [   27.495152] usb0: MAC 52:08:20:37:1b:cf
>
> [   27.502656] usb1: HOST MAC 0e:0d:48:41:f9:e3
>
> [   27.502828] usb1: MAC ea:2d:e9:92:95:d8
>
> [   27.823542] IPv6: ADDRCONF(NETDEV_UP): usb0: link is not ready
>
> [   27.928126] IPv6: ADDRCONF(NETDEV_UP): usb1: link is not ready
>
> [   29.902568] usb 1-1: new high-speed USB device number 2 using musb-hdrc
>
> [   30.051126] usb 1-1: New USB device found, idVendor=7392, 
> idProduct=b822
>
> [   30.051147] usb 1-1: New USB device strings: Mfr=1, Product=2, 
> SerialNumber=3
>
> [   30.051156] usb 1-1: Product: AC1200 MU-MIMO USB2.0 Adapter
>
> [   30.051164] usb 1-1: Manufacturer: Realtek
>
> [   30.051171] usb 1-1: SerialNumber: 123456
>
> [   58.475688] pruss 4a30.pruss: creating PRU cores and other child 
> platform devices
>
> [   59.117552] remoteproc remoteproc1: 4a334000.pru is available
>
> [   59.117694] pru-rproc 4a334000.pru: PRU rproc node 
> /ocp/pruss_soc_bus@4a326004/pruss@0/pru@34000 probed successfully
>
> [   59.147747] remoteproc remoteproc2: 4a338000.pru is available
>
> [   59.147890] pru-rproc 4a338000.pru: PRU rproc node 
> /ocp/pruss_soc_bus@4a326004/pruss@0/pru@38000 probed successfully
>
> [   59.868881] 88x2bu*: loading out-of-tree module taints kernel.*
>
> [   60.536781] RTW*: module init start*
>
> [   60.536803] RTW*: rtl88x2bu v5.3.1_27678.20180430_COEX20180427-5959*
>
> [   60.536808] RTW*: rtl88x2bu BT-Coex version = COEX20180427-5959*
>
> [   60.536887] RTW*: rtw_inetaddr_notifier_register*
>
>
> On standard image
>
>
> [   39.810511] usb 1-1: n

[beagleboard] Re: Breakout Board for Beagle Board X15

[Daniel Block]

I use all the same two row pin headers.  I purchase 2 by 36 pin row headers 
and simply cut them to the size I need.  Are there certain SV connector 
numbers that you are having trouble finding?  Or are you talking about the 
connectors that connect to the BBX15 four connectors?  Their part number is 
in the BBX15 users guide but I could find you the DigiKey part number for 
those if you wish.  
Dan


On Tuesday, February 25, 2020 at 5:00:09 PM UTC-6, paul...@gmail.com wrote:
>
> Dan,
> I know this is 7 months old at this point, but would you happen to have 
> the BOM for this board? Eagle's exported parts list contains insufficient 
> information to find everything (namely the pin headers). This looks like a 
> sweet board, and I am hoping to get some fabbed soon, thank you for posting 
> it!
> Paul
>
> On Tuesday, October 8, 2019 at 8:57:58 AM UTC-6, Daniel Block wrote:
>>
>> Heads up for anyone using the expansion connectors on the BB X15.  I 
>> spent much of yesterday debugging this issue.  The BB X15 ships with a 
>> small piece of tape on each of the underneath expansion headers.  I didn't 
>> realize this and connected the new BB X15 to my expansion board and the 
>> piece of tape got shoved inside the connector.  Because of this some of my 
>> pins where not connected to the expansion board because they were blocked 
>> by the tape.  
>> So when unpacking a new BB X15 make sure the remove those small pieces of 
>> tape from the connectors if you plan to use them.  I bet the tape is left 
>> on the connectors because many people do not use the expansion and debris 
>> could get in the connectors.  
>> Dan  
>>
>> On Wednesday, June 12, 2019 at 11:17:49 AM UTC-5, Daniel Block wrote:
>>>
>>> I thought I would post this to the BB x15 group in case some else would 
>>> find this board helpful.  I created this board in EagleCAD 7.  It breaks 
>>> out most of the PINs of the 4 expansion connectors of the BBx15.  Hopefully 
>>> the schematic is documented enough that you can solder up the board 
>>> yourself.  If you want to use the board to just break out the expansion 
>>> connectors you do not need to solder any of the chips except for the  7 
>>> SN74CBTD16211DL chips that are level converters that would allow 5V 
>>> signals.  
>>>
>>> Dan
>>>
>>>

-- 
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/66cbe4c1-55ae-4219-a2e0-68753ee4f0ce%40googlegroups.com.

[beagleboard] Enabling the DSP Cores in Uboot?

[Daniel Block]

Is there a setting that will enable the DSP cores of the AM5728 in Uboot?  
I am developing DSP applications using the JTAG connection and CCStudio for 
the AM5728.  It would be nice to be able to boot the ARM cores just to the 
Uboot prompt and then be able to connect to the DSP cores through the 
JTAG.  By default the DSP cores are not enabled and in CCS I have to 
connect first to one of the ARM cores, enable the DSP cores with a GEL 
script command and then connect to the DSP core.  I know with a version of 
Uboot for the OMAPL138 processor there was an option in the Uboot 
"printenv" that allowed you to enable the DSP core.  Is there anything like 
that for the AM5728 Uboot?  
Thanks
Dan
 

-- 
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/1f78f688-9da9-4069-98f8-b87ee85fcb48%40googlegroups.com.

[beagleboard] Re: Breakout Board for Beagle Board X15

[Daniel Block]

Heads up for anyone using the expansion connectors on the BB X15.  I spent 
much of yesterday debugging this issue.  The BB X15 ships with a small 
piece of tape on each of the underneath expansion headers.  I didn't 
realize this and connected the new BB X15 to my expansion board and the 
piece of tape got shoved inside the connector.  Because of this some of my 
pins where not connected to the expansion board because they were blocked 
by the tape.  
So when unpacking a new BB X15 make sure the remove those small pieces of 
tape from the connectors if you plan to use them.  I bet the tape is left 
on the connectors because many people do not use the expansion and debris 
could get in the connectors.  
Dan  

On Wednesday, June 12, 2019 at 11:17:49 AM UTC-5, Daniel Block wrote:
>
> I thought I would post this to the BB x15 group in case some else would 
> find this board helpful.  I created this board in EagleCAD 7.  It breaks 
> out most of the PINs of the 4 expansion connectors of the BBx15.  Hopefully 
> the schematic is documented enough that you can solder up the board 
> yourself.  If you want to use the board to just break out the expansion 
> connectors you do not need to solder any of the chips except for the  7 
> SN74CBTD16211DL chips that are level converters that would allow 5V 
> signals.  
>
> Dan
>
>

-- 
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/8e5afd22-55ff-474b-8a9d-481b16c32417%40googlegroups.com.

Re: [beagleboard] Re: BeagleBone AI and real time applicatio

[Daniel Block]

OK send me an email at dblocki...@gmail.com and I will send you the code.

On Mon, Sep 23, 2019 at 5:54 PM 'Mark Lazarewicz' via BeagleBoard <
beagleboard@googlegroups.com> wrote:

> Yes I'm interested I'll dig out my L138 I think I bought the JTAG too we
> can correspond. I Took early retirement 2 years ago my mom has Dementia
> it's become obvious I'm gonna need to get back to work I'm 60 and bored
> silly
>
> Sent from Yahoo Mail on Android
> <https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature>
>
> On Mon, Sep 23, 2019 at 5:46 PM, Daniel Block
>  wrote:
> Mark, also if you would like the DSP_Load source code I can email it to
> you.  It may not be the best to put it on this thread as it is not code for
> the BB x15 and BBAI.
>
> On Mon, Sep 23, 2019 at 5:31 PM Daniel Block  wrote:
>
> Mark, you are preaching to the choir and I love hearing what you said from
> industry experts.  I teach and help teach both control systems and robotics
> courses.  In each of these classes I stress the real-time capability of the
> system they are programming.  I do feel it is important to teach the use of
> embedded Linux but when I do I always have another processor in the system
> that can run real-time code.  For example the TMS320F28379D floating point
> processors are great for motor control and have 2 full cores and 2 partial
> cores TI calls Control Law Accelerators.  You may also be interested in the
> new TMS320F28388D chips which add an ARM core.
>
>
> On Sun, Sep 22, 2019 at 9:58 PM 'Mark Lazarewicz' via BeagleBoard <
> beagleboard@googlegroups.com> wrote:
>
> Thanks for replying.
> It's been 2 year's we didn't allow the DSP to start before the ARM device
> properly initialized safely. product was a safety critical device as well
> as a network safety device which was the ARM side had the network stack .
> The DSP was loaded by ARM after DSP cache was configured that program came
> from TI cache config. Besides your loading not  being automated on boot (
> our DSP hex file was in flash) our loader validated the DSP hex file thats
> essential in safety critical. It's all irrelevant since my interest is
> skills refresher I spent my career using RTOS it's not a hard requirement
> to not use Linux it's more a comfort zone and desire to use baremetal or
> RTOS on ARM those are the jobs that's get floated my way especially low
> level and you see Very little support or interest in this amongst the
> hobbyist arena.I prefer to focus on ARM boot and BSP as a EE and parsing
> hex files is not my interest that's why I asked if this loader was in
> public domain. I've never seen a c Linux program I couldn't port to C RTOS.
> I'm curious your an educator there's a big demand in industry for hard
> real-time RTOS based systems. Free RTOS is Free
> TI Sysbios is Free so is TI RTOS. Why Not give US Engineeers this
> skillset? I see Foreign student asking about this surely the realize the
> need here for the skills. Shouldn't our students get skills that
> Industry needs.  I attended MSOE I'm not sure what they offer in classes
> now. When I graduated we used Altair 8080 and used switches to toggle in
> machine code.
>
> I understand Linux is open and fits some products needs but yet all the
> companies that use this TI Chip in large quantities and required very hard
> real-time I've encountered in industry don't use Linux. Aircraft require a
> safety certificate of RTOS they won't pay to certify linux. Not trying to
> be controversial I'm thinking this barebones)RTOS skillset is still
> relavent and if no one else sees this I might need to unretire just for fun
> and some part time work. I find it alarming other countries see the need to
> learn this skillset and have made effort to sell themselves as better
> Engineeers and replace US Engineeers as superior educated (I don't believe
> this) and Industry claims they can't find enough US Engineeers. Looks like
> robots and are your Target's for classwork.
> Surely your school teaches control theory, guidance Navigation and control
> used in spacecraft control yet last time I checked Lockheed Martin uses
> Vxworks on spacecraft and missle GNC not Linux. Thanks for inspiring me by
> sharing your project it brought back memories of when work was still
> inspiring and enjoyable for 4 hours of 8 every day until I encountered a
> foreign Engineeer at work on Visa who reminded me he was better trained and
> I  should retire and leave Engineeering Linux and And

Re: [beagleboard] Re: BeagleBone AI and real time applicatio

[Daniel Block]

Mark, also if you would like the DSP_Load source code I can email it to
you.  It may not be the best to put it on this thread as it is not code for
the BB x15 and BBAI.

On Mon, Sep 23, 2019 at 5:31 PM Daniel Block  wrote:

> Mark, you are preaching to the choir and I love hearing what you said from
> industry experts.  I teach and help teach both control systems and robotics
> courses.  In each of these classes I stress the real-time capability of the
> system they are programming.  I do feel it is important to teach the use of
> embedded Linux but when I do I always have another processor in the system
> that can run real-time code.  For example the TMS320F28379D floating point
> processors are great for motor control and have 2 full cores and 2 partial
> cores TI calls Control Law Accelerators.  You may also be interested in the
> new TMS320F28388D chips which add an ARM core.
>
>
> On Sun, Sep 22, 2019 at 9:58 PM 'Mark Lazarewicz' via BeagleBoard <
> beagleboard@googlegroups.com> wrote:
>
>> Thanks for replying.
>> It's been 2 year's we didn't allow the DSP to start before the ARM device
>> properly initialized safely. product was a safety critical device as well
>> as a network safety device which was the ARM side had the network stack .
>> The DSP was loaded by ARM after DSP cache was configured that program came
>> from TI cache config. Besides your loading not  being automated on boot (
>> our DSP hex file was in flash) our loader validated the DSP hex file thats
>> essential in safety critical. It's all irrelevant since my interest is
>> skills refresher I spent my career using RTOS it's not a hard requirement
>> to not use Linux it's more a comfort zone and desire to use baremetal or
>> RTOS on ARM those are the jobs that's get floated my way especially low
>> level and you see Very little support or interest in this amongst the
>> hobbyist arena.I prefer to focus on ARM boot and BSP as a EE and parsing
>> hex files is not my interest that's why I asked if this loader was in
>> public domain. I've never seen a c Linux program I couldn't port to C RTOS.
>> I'm curious your an educator there's a big demand in industry for hard
>> real-time RTOS based systems. Free RTOS is Free
>> TI Sysbios is Free so is TI RTOS. Why Not give US Engineeers this
>> skillset? I see Foreign student asking about this surely the realize the
>> need here for the skills. Shouldn't our students get skills that
>> Industry needs.  I attended MSOE I'm not sure what they offer in classes
>> now. When I graduated we used Altair 8080 and used switches to toggle in
>> machine code.
>>
>> I understand Linux is open and fits some products needs but yet all the
>> companies that use this TI Chip in large quantities and required very hard
>> real-time I've encountered in industry don't use Linux. Aircraft require a
>> safety certificate of RTOS they won't pay to certify linux. Not trying to
>> be controversial I'm thinking this barebones)RTOS skillset is still
>> relavent and if no one else sees this I might need to unretire just for fun
>> and some part time work. I find it alarming other countries see the need to
>> learn this skillset and have made effort to sell themselves as better
>> Engineeers and replace US Engineeers as superior educated (I don't believe
>> this) and Industry claims they can't find enough US Engineeers. Looks like
>> robots and are your Target's for classwork.
>> Surely your school teaches control theory, guidance Navigation and
>> control used in spacecraft control yet last time I checked Lockheed Martin
>> uses Vxworks on spacecraft and missle GNC not Linux. Thanks for inspiring
>> me by sharing your project it brought back memories of when work was still
>> inspiring and enjoyable for 4 hours of 8 every day until I encountered a
>> foreign Engineeer at work on Visa who reminded me he was better trained and
>> I  should retire and leave Engineeering Linux and Android to non US
>> Engineeers. Funny my Verizon 4G hotspot designed by these very same visa
>> Engineeers at Verizon in Dallas continually goes through reset our 737
>> planes are grounded and our products are worse than ever wherever offshore
>> or visa labor is used.
>> I am encouraged our universities continue to attract the brightest
>> student from around the world.
>>  Since I'm obviously missing my old profession and have way too much time
>> on my hands maybe it's time I revisit my Alma Matter and see what Johnson
>> Controls and Nividia have donated to MSOE a school

Re: [beagleboard] Re: BeagleBone AI and real time applicatio

[Daniel Block]

Mark, you are preaching to the choir and I love hearing what you said from
industry experts.  I teach and help teach both control systems and robotics
courses.  In each of these classes I stress the real-time capability of the
system they are programming.  I do feel it is important to teach the use of
embedded Linux but when I do I always have another processor in the system
that can run real-time code.  For example the TMS320F28379D floating point
processors are great for motor control and have 2 full cores and 2 partial
cores TI calls Control Law Accelerators.  You may also be interested in the
new TMS320F28388D chips which add an ARM core.


On Sun, Sep 22, 2019 at 9:58 PM 'Mark Lazarewicz' via BeagleBoard <
beagleboard@googlegroups.com> wrote:

> Thanks for replying.
> It's been 2 year's we didn't allow the DSP to start before the ARM device
> properly initialized safely. product was a safety critical device as well
> as a network safety device which was the ARM side had the network stack .
> The DSP was loaded by ARM after DSP cache was configured that program came
> from TI cache config. Besides your loading not  being automated on boot (
> our DSP hex file was in flash) our loader validated the DSP hex file thats
> essential in safety critical. It's all irrelevant since my interest is
> skills refresher I spent my career using RTOS it's not a hard requirement
> to not use Linux it's more a comfort zone and desire to use baremetal or
> RTOS on ARM those are the jobs that's get floated my way especially low
> level and you see Very little support or interest in this amongst the
> hobbyist arena.I prefer to focus on ARM boot and BSP as a EE and parsing
> hex files is not my interest that's why I asked if this loader was in
> public domain. I've never seen a c Linux program I couldn't port to C RTOS.
> I'm curious your an educator there's a big demand in industry for hard
> real-time RTOS based systems. Free RTOS is Free
> TI Sysbios is Free so is TI RTOS. Why Not give US Engineeers this
> skillset? I see Foreign student asking about this surely the realize the
> need here for the skills. Shouldn't our students get skills that
> Industry needs.  I attended MSOE I'm not sure what they offer in classes
> now. When I graduated we used Altair 8080 and used switches to toggle in
> machine code.
>
> I understand Linux is open and fits some products needs but yet all the
> companies that use this TI Chip in large quantities and required very hard
> real-time I've encountered in industry don't use Linux. Aircraft require a
> safety certificate of RTOS they won't pay to certify linux. Not trying to
> be controversial I'm thinking this barebones)RTOS skillset is still
> relavent and if no one else sees this I might need to unretire just for fun
> and some part time work. I find it alarming other countries see the need to
> learn this skillset and have made effort to sell themselves as better
> Engineeers and replace US Engineeers as superior educated (I don't believe
> this) and Industry claims they can't find enough US Engineeers. Looks like
> robots and are your Target's for classwork.
> Surely your school teaches control theory, guidance Navigation and control
> used in spacecraft control yet last time I checked Lockheed Martin uses
> Vxworks on spacecraft and missle GNC not Linux. Thanks for inspiring me by
> sharing your project it brought back memories of when work was still
> inspiring and enjoyable for 4 hours of 8 every day until I encountered a
> foreign Engineeer at work on Visa who reminded me he was better trained and
> I  should retire and leave Engineeering Linux and Android to non US
> Engineeers. Funny my Verizon 4G hotspot designed by these very same visa
> Engineeers at Verizon in Dallas continually goes through reset our 737
> planes are grounded and our products are worse than ever wherever offshore
> or visa labor is used.
> I am encouraged our universities continue to attract the brightest student
> from around the world.
>  Since I'm obviously missing my old profession and have way too much time
> on my hands maybe it's time I revisit my Alma Matter and see what Johnson
> Controls and Nividia have donated to MSOE a school that's selling point was
> we talk to Industry to understand what industry needs.
>
> Sadly I'm afraid their going to be teaching Linux on NVDA ARM Chip's 😭 as
> part of any embedded curriculum.
>
> Sent from Yahoo Mail on Android
> <https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature>
>
> On Sun, Se

Re: [beagleboard] Re: BeagleBone AI and real time applications (SMPS and motor control)

[Daniel Block]

I am running Angstrom Linux on the ARM core.  So once I have built my 
SYS/BIOS DSP application in windows, I use putty's scp program "pscp" to 
copy the hex file to Linux.  Then I run the DSP_Load program from Angstrom 
using a putty terminal.If you are going to get ride of Angstrom or 
another Linux from the ARM core you will not be able to use the DSP_Load 
program. 
I have also written a DSP_Flash application that again from the embedded 
Linux writes the DSP program to the SPI flash of the LogicPD's OMAPL138 
SOM.  Then on power up I change the UBL to load the DSP application and 
then launch Linux.  This way the DSP program is running before Linux 
finishes booting.  Sounds something like what you had setup on your OMAP 
system. 




On Saturday, September 21, 2019 at 10:55:21 PM UTC-5, lazarman wrote:
>
>
>
> Hi Dan
> Interesting I worked on high end commercial motor controller which used 
> L138. the ARM ran Green Hills Integrity and the DSP Sysbios. This system 
> intialized the DSP caches first before loading the DSP to RAM. the 
> executable was stored on flash that could be NFS mounted for ARM and DSP 
> executable update by PC. The IPC was done using shared  Low and High 
> priority Queues in the DSP shared RAM. Our application was extremely hard 
> Real Time and proprietary and I'm retired but probably have a a TI L138 
> eval Board I purchased sitting around I might dig out .
> If this load DSP code is available  it might provide a refresher for me as 
> a hobby. I'd like to ditch Linux on the ARM for my purposes maybe use TI 
> RTOS. Are you emulating both cores simultaneously with JTAG or using serial 
> debug on the DSP? How are you getting DSP hex file into Linux.
> Thanks
>
> Sent from Yahoo Mail on Android 
> <https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature>
>
> On Sat, Sep 21, 2019 at 9:07 PM, Daniel Block
> > wrote:
> Richard,  I have been working with the BeagleBoard X15 the past four 
> months off and on and have made some good progress in using the DSP cores 
> running SYS/BIOS applications while the A15 cores are running Debian 
> Linux.  I develop my DSP programs in CCS and generate Hex files that I can 
> copy to Linux.  Then from Linux I have created a DSP_Load application that 
> loads and runs the DSP core with the hex file.  To date my DSP program uses 
> Timer 4 as the SYS/BIOS timer and timer 5 as a HWI timer, an external GPIO 
> interrupt (which would be helpful for your external ADCs) and communicates 
> with UART 8, 9 and 10.  I teach a Mechatronics class at the University of 
> Illinois where currently I instruct the class using the OMAPL138 processor 
> where I use a very similar Linux program to load the DSP core of the 
> OMAPL138.  I am hoping to switch my Mechatronics class to the BB x15 this 
> Spring 2020.  Currently I have a student working on developing a DSP 
> program that uses the MCSPI3 and MCSPI4 serial ports of the AM572x.  Once I 
> have the McSPIs working and a communication scheme, I hope to use IPC, 
> between Linux and the DSPs I will switch my class to the BB x15.  Once I 
> switch my class I will be writing up instructions on how to program the 
> DSPs and that may be useful to you when using the BeagleBoneAI.  I can give 
> you what I have done so far, but it is not documented super well.
> The question I have with the BeagleBoneAI is does it bring out to its 
> headers any of the McSPI pins?  I have not looked at the schematics closely 
> to know the answer.  You may want to check that and if the pins do not come 
> out you could switch to the BB x15 which has four headers that bring out 
> many more of the pins.  If you are interested in my OMAPL138 work you can 
> see my course web site at http://coecsl.ece.illinois.edu/se423 
>  
>
> On Friday, September 20, 2019 at 11:43:43 PM UTC-5, Richard Tarbell wrote:
>
>
> Greetings All!
>
> Is there/will there be tutorials, on how to run Linux on the Beaglebone 
> AI, but run real time code on its two DSP processors?
>
> For instance, I am looking to do a motor control application (100kHz 
> sampling with external ADCs connected via SPI).  Is this possible to run on 
> the DSP cores?  
>
> -- 
> 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 beagl...@googlegroups.com .
> To view this discussion on the web visit 
>
> https://groups.google.com/d/msgid/beagleboard/5bd8dfa8-8cd1-

[beagleboard] Re: BeagleBone AI and real time applications (SMPS and motor control)

[Daniel Block]

Richard,  I have been working with the BeagleBoard X15 the past four months 
off and on and have made some good progress in using the DSP cores running 
SYS/BIOS applications while the A15 cores are running Debian Linux.  I 
develop my DSP programs in CCS and generate Hex files that I can copy to 
Linux.  Then from Linux I have created a DSP_Load application that loads 
and runs the DSP core with the hex file.  To date my DSP program uses Timer 
4 as the SYS/BIOS timer and timer 5 as a HWI timer, an external GPIO 
interrupt (which would be helpful for your external ADCs) and communicates 
with UART 8, 9 and 10.  I teach a Mechatronics class at the University of 
Illinois where currently I instruct the class using the OMAPL138 processor 
where I use a very similar Linux program to load the DSP core of the 
OMAPL138.  I am hoping to switch my Mechatronics class to the BB x15 this 
Spring 2020.  Currently I have a student working on developing a DSP 
program that uses the MCSPI3 and MCSPI4 serial ports of the AM572x.  Once I 
have the McSPIs working and a communication scheme, I hope to use IPC, 
between Linux and the DSPs I will switch my class to the BB x15.  Once I 
switch my class I will be writing up instructions on how to program the 
DSPs and that may be useful to you when using the BeagleBoneAI.  I can give 
you what I have done so far, but it is not documented super well.
The question I have with the BeagleBoneAI is does it bring out to its 
headers any of the McSPI pins?  I have not looked at the schematics closely 
to know the answer.  You may want to check that and if the pins do not come 
out you could switch to the BB x15 which has four headers that bring out 
many more of the pins.  If you are interested in my OMAPL138 work you can 
see my course web site at http://coecsl.ece.illinois.edu/se423 
 

On Friday, September 20, 2019 at 11:43:43 PM UTC-5, Richard Tarbell wrote:
>
>
> Greetings All!
>
> Is there/will there be tutorials, on how to run Linux on the Beaglebone 
> AI, but run real time code on its two DSP processors?
>
> For instance, I am looking to do a motor control application (100kHz 
> sampling with external ADCs connected via SPI).  Is this possible to run on 
> the DSP cores?  
>

-- 
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/5bd8dfa8-8cd1-4f7d-8c03-de023fc22685%40googlegroups.com.

[beagleboard] Invalid Mode Errors When Trying to Configure GPIO

[Daniel Koenig]

I'm a huge newbie when it comes to the BBB, so bear with me here. Please 
also forgive me if this isn't the sort of topic that I ask about here. 

I am trying to use the BBB with the PurpleVLC cape in order to perform some 
VLC research. Unfortunately, I've run into some problems getting PurpleVLC 
to function, and the developers did not have any idea how to fix the 
problem.

Essentially, I'm following the tutorial listed on the PurpleVLC webpage here 
.

As part of the tutorial, I reload the pru_rproc, then try to run the repo's 
Makefile . When I 
run the Makefile, it attempts to copy the contents of 
/config/pru_gpio_config to /dev/null (./config/pru_gpio_config >> 
/dev/null). When this part of the Makefile runs, however, I get a massive 
amount of errors related to the pru_gpio_config file 
, 
which you can see in the attached picture: 

[image: Capture.PNG]

The ": not found" errors seem to pop up whenever the system reads an empty 
line, but I think the problematic errors are the "invalid mode" errors. And 
while I've tried to find a way to fix these errors, I'm not really finding 
much. The Universal IO page 
 linked in 
pru_gpio_config was no help, and blog posts about the PRU and GPIO system 
aren't really helping me figure out what's going on either. I'd like to 
avoid digging too deep into the BBB documentation if possible since my 
focus is on an application running on top of the BBB, not the BBB itself. 

Does anyone have any idea what exactly is going on and how I could go about 
addressing this? 

Please let me know if you have any further questions. Please also let me 
know if this is not the right place to post this sort of question, and I'll 
delete. 

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/38103aec-9281-4a88-84d9-6a2bb536680c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Kernel 4.14: how to enable PRU access to PWMSS?

[Daniel Kulp]

I really just use the cape-universal.   I use the /sys stuff to export the 
pin as pwm.  I also use the sysfs interface to setup initial PWM values 
(period/duty_cycle/enable) and after that, the PRU seems to be able to 
manipulate the PWM registers to change the dutyscycles and such as needed.  

Dan


On Sunday, June 30, 2019 at 7:56:45 AM UTC-4, Super Duper88 wrote:
>
> Hi Daniel,
>
> thanks for reply. Which kernel and overlay do you use?
> How do you enable the PWM pins using PWM devices?
> Usually I configure the pins in a overlay.
>
> On Kernel 3.8 and 4.1 it seems to work. But on 4.9 and 4.14 PRU can't 
> access PWMSS.
>
> Best regards
>
> Am So., 30. Juni 2019 um 02:57 Uhr schrieb Daniel Kulp  >:
>
>>
>> I wasn't able to get access to the PWM registers from the ARM side (same 
>> bus error), but the PRU can still access them fine.   For what I was doing 
>> a few weeks ago, I used the normal linux PWM devices to enable the PWM pin, 
>> but then used the PRU to configure the registers and such.  Seemed to work 
>> OK.
>>
>> Dan
>>
>>
>>
>> On Saturday, June 29, 2019 at 4:23:14 PM UTC-4, masl...@gmail.com wrote:
>>>
>>>
>>> Hi,
>>>
>>> during change from 3.8 kernel to 4.14 I struggled with an issue 
>>> regarding PWMSS accessed by PRU.
>>> On old kernel I load overlay am33xx_pwm to activate the PWMSS.
>>> I verified this with: devmem2 0x48300 (base address of PWMSS0)
>>>
>>> With 4.14 kernel I get 'bus error' when I execute same 'devmem2 
>>> 0x48300'
>>> Also PRU have no access to PWMSS.
>>>
>>> But loading the am33xx_pwm seems succesful, at least the sysfs folder is 
>>> populated with pwm folders.
>>>
>>> How can the PRU gain access to PWMSS?
>>>
>>> Best regards
>>>
>> -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "BeagleBoard" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/beagleboard/Ia2OC_8wArE/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> beagl...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/e0bc70ce-afab-491d-b716-c742df377b7c%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/beagleboard/e0bc70ce-afab-491d-b716-c742df377b7c%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> 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/7619f2ca-d1d4-4ef7-9e8f-42b4caa20383%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Kernel 4.14: how to enable PRU access to PWMSS?

[Daniel Kulp]

I wasn't able to get access to the PWM registers from the ARM side (same 
bus error), but the PRU can still access them fine.   For what I was doing 
a few weeks ago, I used the normal linux PWM devices to enable the PWM pin, 
but then used the PRU to configure the registers and such.  Seemed to work 
OK.

Dan



On Saturday, June 29, 2019 at 4:23:14 PM UTC-4, masl...@gmail.com wrote:
>
>
> Hi,
>
> during change from 3.8 kernel to 4.14 I struggled with an issue regarding 
> PWMSS accessed by PRU.
> On old kernel I load overlay am33xx_pwm to activate the PWMSS.
> I verified this with: devmem2 0x48300 (base address of PWMSS0)
>
> With 4.14 kernel I get 'bus error' when I execute same 'devmem2 
> 0x48300'
> Also PRU have no access to PWMSS.
>
> But loading the am33xx_pwm seems succesful, at least the sysfs folder is 
> populated with pwm folders.
>
> How can the PRU gain access to PWMSS?
>
> Best regards
>

-- 
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/e0bc70ce-afab-491d-b716-c742df377b7c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Breakout Board for Beagle Board X15

[Daniel Block]

Yes.  Glad you can use the board.  I have attached the EagleCAD library for
the Hirose connector that I made.  This library has two other parts for a
different board I was working on at the time, so ignore those.

Dan

On Tue, Jun 18, 2019 at 9:23 PM Calvin Slater 
wrote:

> Wow Dan!
>
> This is perfect. I was looking for something like this.
>
> Did you create the Hirose header footprints yourself? They are very nice.
>
> Calvin
>
>
>
> On Wed, 12 Jun 2019 at 09:18, Daniel Block  wrote:
>
>> I thought I would post this to the BB x15 group in case some else would
>> find this board helpful.  I created this board in EagleCAD 7.  It breaks
>> out most of the PINs of the 4 expansion connectors of the BBx15.  Hopefully
>> the schematic is documented enough that you can solder up the board
>> yourself.  If you want to use the board to just break out the expansion
>> connectors you do not need to solder any of the chips except for the  7
>> SN74CBTD16211DL chips that are level converters that would allow 5V
>> signals.
>>
>> Dan
>>
>> --
>> 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/37a0a372-58db-4fb0-8c0b-c15b9e66bb36%40googlegroups.com
>> <https://groups.google.com/d/msgid/beagleboard/37a0a372-58db-4fb0-8c0b-c15b9e66bb36%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> 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/CAN%2BNdyi13jbYrXbtNNmu7S284cXowxaaczVUsVxCsZ_wX9gctQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/beagleboard/CAN%2BNdyi13jbYrXbtNNmu7S284cXowxaaczVUsVxCsZ_wX9gctQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> 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/CAMTPGNZsM9cW2GDAUuzEKWPYKzVrKque3G%2BzO-N0goS3YYDz%2BA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


custom7.lbr
Description: Binary data

[beagleboard] prussdrv_map_extmem analog using pru_rproc

[Ethan Daniel Shea]

The old UIO drivers had access to the prussdrv_map_extmem function which 
could be used to expose DDR3 memory to the pru, and prussdrv_get_phys_addr 
which could be used to communicate where the PRU should access data. This 
is useful when you want to transfer large amounts of data between the PRU 
and the ARM core. This can be seen in action here 

.

Is the same functionality available in the newer pru_rproc drivers? If not, 
what's the best way to do about doing large transfers between the PRU and 
the ARM core?

-- 
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/803d3849-1a82-4e4b-bf8e-4288be3ef884%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] I2C GPIO expanders and the BeagleBoneBlack and PocketBeagle...

[Daniel Kulp]

> On Jun 10, 2019, at 7:36 PM, Robert Heller  wrote:
> 
> At Mon, 10 Jun 2019 18:29:33 -0400 Daniel Kulp  <mailto:d...@kulp.com>> wrote:
>> 
>> “bone kernel”
>> 
>> That’s important.   The TI kernels are not usable for my application.  I 
>> need to use the bone kernel.   (At least for the 4.9 and 4.14 series… 
>> haven’t had time to test with the TI 4.19 series kernels)
> 
> Ah.  I see.  What sorts of differences are there between the TI kernels and 
> the Bone kernels?  Is there some reason the Bone don't have the MCP23S08 
> module enabled?  Wondering if a bug/feature request might make sense…

Honestly, I have no idea what the “official” differences are and why some 
modules are available in one and not the other.   Likely just someone requested 
something.At some point, a “diff” of the configs and unifying the optional 
modules of it may make sense, not really sure.

In my particular case, I *believe* the power management stuff that is in the TI 
kernel is screwing up the timing to access anything in the L4_WKUP interconnect 
(which includes GPIO0).   For folks that value the power management stuff, the 
TI kernel is much better.  It contains the cpu IDLE driver and a bunch of other 
things that allow it to lower the power usage.  In my case, I don’t care about 
any of that.  Even with the bone kernel, I lock the CPU at 1ghz.   I need more 
predictable and consistent access to the gpio pins (all of them).   With the TI 
kernel, access to GPIO1-3 (via the PRU) is very consistent, but access to GPIO0 
can have several hundred ns delays which I cannot have (relatively infrequent, 
once or twice a second, but still too often).   I KNOW the CPU idle stuff in 
the TI kernel plays a large part of the problem. If I use cpupower to turn 
off the idle states, 90% of the delays go away (so once every 10 seconds or 
so).   Anyway, the bone kernel doesn’t have a bunch of the PM things so I don’t 
see any of the issues with it. Of course, it might not be PM at all.  Could 
be something else completely different between the kernels.


-- 
Daniel Kulp
d...@kulp.com <mailto:d...@kulp.com> - http://dankulp.com/blog 
<http://dankulp.com/blog>

-- 
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/6F907568-CC97-42FA-BBBC-E84C28203ADD%40kulp.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] I2C GPIO expanders and the BeagleBoneBlack and PocketBeagle...

[Daniel Kulp]

> On Jun 10, 2019, at 6:08 PM, Robert Heller  wrote:
> At Mon, 10 Jun 2019 16:34:53 -0400 Daniel Kulp  wrote:
>> On Jun 10, 2019, at 4:26 PM, Robert Heller  wrote:
>>> 
>>> At Mon, 10 Jun 2019 12:48:56 -0700 (PDT) beagleboard@googlegroups.com wrote:
>>>> It's not enabled in the bone kernels:
>>>> 
>>>> 
>>>> # CONFIG_PINCTRL_MCP23S08 is not set
>>> 
>>> In the updated kernel is is enabled.
>> 
>> I don't see a bone kernel with it enabled, either 4.14 or 4.19:

“bone kernel”

That’s important.   The TI kernels are not usable for my application.  I need 
to use the bone kernel.   (At least for the 4.9 and 4.14 series… haven’t had 
time to test with the TI 4.19 series kernels)

My initial reply was to RobertCNelson’s response that it’s enabled in the newer 
kernels to point out that it’s not enabled in ALL the newer kernels, just the 
“ti” channel kernels.

I’ve been playing around with a pcf8574 i2c gpio expander as that module is 
available in the bone kernel.   The main problem with the pcf8574 is it only 
supports the 100khz i2c speed which sucks when you also have an i2c OLED on the 
bus.Updating to 400khz is important with that thing.  Your mention of the 
MCP23008 is very timely as I was just beginning to start looking at other 
options.   Just kind of hoping that future bone kernels would have the driver 
built in.  Would be a big help if I don’t have to rebuild kernels.  


-- 
Daniel Kulp
d...@kulp.com <mailto:d...@kulp.com> - http://dankulp.com/blog 
<http://dankulp.com/blog>

-- 
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/A4F5BF3A-2EB9-498F-818B-6948C4DF2E11%40kulp.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] I2C GPIO expanders and the BeagleBoneBlack and PocketBeagle...

[Daniel Kulp]

> On Jun 10, 2019, at 4:26 PM, Robert Heller  wrote:
> 
> At Mon, 10 Jun 2019 12:48:56 -0700 (PDT) beagleboard@googlegroups.com wrote:
>> It's not enabled in the bone kernels:
>> 
>> 
>> # CONFIG_PINCTRL_MCP23S08 is not set
> 
> In the updated kernel is is enabled.

I don’t see a bone kernel with it enabled, either 4.14 or 4.19:

config-4.14.108-ti-r104:CONFIG_PINCTRL_MCP23S08=m
config-4.14.109-bone21:# CONFIG_PINCTRL_MCP23S08 is not set
config-4.14.115-bone22:# CONFIG_PINCTRL_MCP23S08 is not set
config-4.19.31-bone31:# CONFIG_PINCTRL_MCP23S08 is not set
config-4.19.37-bone33:# CONFIG_PINCTRL_MCP23S08 is not set

I believe the 115-bone22 and 37-bone33 are the latest on the two branches.


-- 
Daniel Kulp
d...@kulp.com <mailto:d...@kulp.com> - http://dankulp.com/blog 
<http://dankulp.com/blog>

-- 
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/6894AD8B-F0A2-4DC9-82E6-D4F78C6B0A81%40kulp.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] I2C GPIO expanders and the BeagleBoneBlack and PocketBeagle...

[Daniel Kulp]

It's not enabled in the bone kernels:


# CONFIG_PINCTRL_MCP23S08 is not set


While I'm pointing some of this out, is there any way to get CONFIG_SND_DUMMY 
added to bone kernel as well as getting a few of the more readily available 
sound codecs added to both kernels?   Probably the PCM512X, SGTL5000, and 
WM8960 as there are a bunch of hats/addons available on Amazon that have 
those.

Dan


On Sunday, June 9, 2019 at 8:23:46 PM UTC-4, RobertCNelson wrote:
>
> On Sun, Jun 9, 2019 at 7:19 PM Robert Heller  > wrote: 
> > 
> > OK, I have made use of the MCP23008 and MCP23017, 8 bit and 16 bit GPIO 
> > expanders that are I2C connected on Raspberry Pis.  The Raspberry Pi 
> kernels 
> > include both an overlay (Device Tree Blob) and a driver module for the 
> > MCP23008 and MCP23017 chips.  I would also like to make use of these 
> chips on 
> > my beagle boards (a BeagleBoneBlack and a PocketBeagle). 
> > 
> > I just did some poking around on my BBB, and there are neither Device 
> Tree 
> > Blobs nor driver modules for the MCP23008 and MCP23017 chips. 
> > 
> > So, my question is:  What is involved in building the missing driver 
> modules 
> > and Device Tree Blobs -- I have built driver modules and even rebuilt 
> whole 
> > kernels on x86 Linux boxen, so I have passing knowledge of how that 
> goes, what 
> > I am really wondering: is there a repo with .deb files containing the 
> "extra" 
> > ko files?  Or tarballs containing the additional sources?  I realize the 
> BBB 
> > and PB are rather slow, so maybe I should cross build this on one of my 
> Pis? 
> > Or is there an alternitive kernel I can upgrade to that includes these 
> > modules? 
> > 
> > Right now my two Beagles are running 4.14.71-ti-r80, Debian GNU/Linux 9, 
> > BeagleBoard.org Debian Image 2018-10-07.  I did do a apt-get 
> update/apt-get 
> > dist-upgrade about a month ago (May 14). 
>
> it's enabled, just after r80 came out..  Just run, and then reboot.. 
>
> sudo /opt/scripts/tools/update_kernel.sh 
>
> 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/57ea6b63-70ed-4d28-bb4b-e63233c43905%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Change MAC on Beaglebone Black with RTnet framework

[daniel . wenninger92]

Hello,

I got two Beaglebone Blacks. I am sending data from one BBB to the other 
BBB with the ping script.

For my real time framework there are some different commands.

My problem is:
When the BBB's start up they do not have an Ethernet IP but a random MAC 
adress. Every time they start up they get a random MAC adress.

What I need to do that the "ping-script" works is the following:

rtifconfig rteth0 up 192.168.127.11 --> just give one IP to one BBB
rtroute add   dev rteth0 --> tell your BBB 
which MAC belong to which IP
rtping 

That is working fine. But i do not like to write these commands every time 
after start up. So I just integrate these comments in a script on the BBB's 
which is executed while start up.
For changing the MAC address I use the command: rtifconfig rteth0 up hw 
ether .

If I change my MAC address and do the "rtifconfig" command everything looks 
great (MAC address changed).
But if I do the "rtroute add" command now the data will get lost. It's like 
the MAC address has changed but not to the address I have just tipped in. 
If I want have a ping again, I need to restart BBB and let give them the 
random MAC from the script (I have tried to search the script giving that 
random MAC but did not find anything).

Can it be possible that it is changing the MAC to another one nevermind 
what I am tipping in?

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/32ba9854-2572-443a-83a5-07ffd2cfcc00%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] bone kernel questions.....

[Daniel Kulp]

> On Apr 1, 2019, at 5:34 PM, Robert Nelson  wrote:
> 
> On Mon, Apr 1, 2019 at 4:04 PM Daniel Kulp  <mailto:d...@kulp.com>> wrote:
>> 
>> 
>> Are you sure?With the above and:
>> disable_uboot_overlay_video=1
>> disable_uboot_overlay_audio=1
>> 
>> I get a total of 59 pins that are queryable with config-pin which is the 
>> same number I get on a regular BBB:
> 
> You should see a good dozen issue here:
> 
> dmesg | grep pinctrl
> 
> The ./*-uboot-univ.dts start out as a basic empty dts:
> 
> https://github.com/RobertCNelson/dtb-rebuilder/blob/4.14-ti/src/arm/am335x-boneblack-uboot-univ.dts
>  
> <https://github.com/RobertCNelson/dtb-rebuilder/blob/4.14-ti/src/arm/am335x-boneblack-uboot-univ.dts>


root@FPPTest:/opt/fpp/src# dmesg | grep pinc
[0.221676] pinctrl core: initialized pinctrl subsystem
[0.809050] pinctrl-single 44e10800.pinmux: 142 pins, size 568
[1.245538] pinctrl-single 44e10800.pinmux: pin PIN107 already requested by 
ocp:P9_25_pinmux; cannot claim for 48038000.mcasp
[1.257270] pinctrl-single 44e10800.pinmux: pin-107 (48038000.mcasp) status 
-22
[1.264684] pinctrl-single 44e10800.pinmux: could not request pin 107 
(PIN107) from group mcasp0_pins  on device pinctrl-single
[1.390227] pinctrl-single 44e10800.pinmux: pin PIN40 already requested by 
ocp:P8_45_pinmux; cannot claim for 0-0070
[1.400871] pinctrl-single 44e10800.pinmux: pin-40 (0-0070) status -22
[1.407460] pinctrl-single 44e10800.pinmux: could not request pin 40 (PIN40) 
from group nxp_hdmi_bonelt_pins  on device pinctrl-single



-- 
Daniel Kulp
d...@kulp.com <mailto:d...@kulp.com> - http://dankulp.com/blog 
<http://dankulp.com/blog>

-- 
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/51DE834B-ECEA-4ADB-9970-B1F6107F797B%40kulp.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] bone kernel questions.....

[Daniel Kulp]

> On Apr 1, 2019, at 4:55 PM, Robert Nelson  wrote:
> On Sat, Mar 30, 2019 at 12:26 PM Daniel Kulp  wrote:
>> 
>> As an FYI, I checked out the kernel source and updated the 
>> arch/arm/boot/dts/Makefile file to do:
>> 
>> +am335x-sancloud-bbe-uboot-univ.dtb \
>> 
>> and then copied arch/arm/boot/dts/am335x-sancloud-bbe.dts to 
>> arch/arm/boot/dts/am335x-sancloud-bbe-uboot-univ.dts and added the line:
>> 
>> #include "am335x-bone-common-univ.dtsi"
>> 
>> to the top (below the am335x-boneblack-common.dtsi) and rebuilt the dtbs and 
>> installed just the new one, and everything works.  :)   config-pin works.
> 
> Except for the pin's tied up via hdmi and eMMC on the header..


Are you sure?With the above and:
disable_uboot_overlay_video=1
disable_uboot_overlay_audio=1 

I get a total of 59 pins that are queryable with config-pin which is the same 
number I get on a regular BBB:

fpp@FPPTest:/opt/fpp/scripts$ ./bbb-reportpins.sh
P8_07 Mode: default Direction: in Value: 1
P8_08 Mode: default Direction: in Value: 1
P8_09 Mode: default Direction: in Value: 1
P8_10 Mode: default Direction: in Value: 1
P8_11 Mode: default Direction: in Value: 0
P8_12 Mode: default Direction: in Value: 0
P8_13 Mode: gpio_pu Direction: in Value: 1
P8_14 Mode: gpio_pu Direction: in Value: 1
P8_15 Mode: default Direction: in Value: 0
P8_16 Mode: default Direction: in Value: 0
P8_17 Mode: default Direction: in Value: 0
P8_18 Mode: default Direction: in Value: 0
P8_19 Mode: default Direction: in Value: 0
P8_26 Mode: default Direction: in Value: 1
P8_27 Mode: gpio Direction: out Value: 0
P8_28 Mode: gpio Direction: out Value: 0
P8_29 Mode: default Direction: in Value: 0
P8_30 Mode: default Direction: in Value: 0
P8_31 Mode: default Direction: in Value: 0
P8_32 Mode: default Direction: in Value: 0
P8_33 Mode: default Direction: in Value: 0
P8_34 Mode: default Direction: in Value: 0
P8_35 Mode: default Direction: in Value: 0
P8_36 Mode: default Direction: in Value: 0
P8_37 Mode: default Direction: in Value: 0
P8_38 Mode: default Direction: in Value: 0
P8_39 Mode: default Direction: in Value: 0
P8_40 Mode: default Direction: in Value: 0
P8_41 Mode: default Direction: in Value: 0
P8_42 Mode: default Direction: in Value: 0
P8_43 Mode: default Direction: in Value: 0
P8_44 Mode: default Direction: in Value: 0
P8_45 Mode: default Direction: in Value: 0
P8_46 Mode: default Direction: in Value: 0
P9_11 Mode: default Direction: in Value: 1
P9_12 Mode: default Direction: in Value: 1
P9_13 Mode: default Direction: in Value: 1
P9_14 Mode: default Direction: in Value: 0
P9_15 Mode: default Direction: in Value: 1
P9_16 Mode: default Direction: in Value: 0
P9_17 Mode: default Direction: in Value: 1
P9_18 Mode: default Direction: in Value: 1
P9_19 Mode: default Direction: in Value: 0
P9_20 Mode: default Direction: in Value: 0
P9_21 Mode: default Direction: in Value: 1
P9_22 Mode: default Direction: in Value: 1
P9_23 Mode: default Direction: in Value: 0
P9_24 Mode: default Direction: in Value: 1
P9_25 Mode: default Direction: in Value: 0
P9_26 Mode: default Direction: in Value: 1
P9_27 Mode: default Direction: in Value: 0
P9_28 Mode: default Direction: in Value: 0
P9_29 Mode: default Direction: in Value: 0
P9_30 Mode: default Direction: in Value: 0
P9_31 Mode: default Direction: in Value: 0
P9_41 Mode: default Direction: in Value: 0
P9_42 Mode: default Direction: in Value: 0
P9_91 Mode: default Direction: in Value: 0
P9_92 Mode: default Direction: in Value: 0

I suppose I should stick an actual cape on there and check….  I’ll try that 
tomorrow.

Dan



> 
> Forgot to dig out this board before i left for work this morning..



-- 
Daniel Kulp
d...@kulp.com <mailto:d...@kulp.com> - http://dankulp.com/blog 
<http://dankulp.com/blog>

-- 
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/30A6207F-DF65-4107-B70D-94700A2E2C20%40kulp.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] bone kernel questions.....

[Daniel Kulp]

As an FYI, I checked out the kernel source and updated 
the arch/arm/boot/dts/Makefile file to do:

+am335x-sancloud-bbe-uboot-univ.dtb \

and then copied arch/arm/boot/dts/am335x-sancloud-bbe.dts 
to arch/arm/boot/dts/am335x-sancloud-bbe-uboot-univ.dts and added the line:

#include "am335x-bone-common-univ.dtsi"

to the top (below the am335x-boneblack-common.dtsi) and rebuilt the dtbs 
and installed just the new one, and everything works.  :)   config-pin 
works. 

Dan





On Friday, March 29, 2019 at 12:59:49 PM UTC-4, RobertCNelson wrote:
>
> On Fri, Mar 29, 2019 at 11:45 AM Daniel Kulp > 
> wrote: 
> > 
> > 
> > Any progress?   If need/want to send me a dtb to test with, that would 
> be fine. 
>
> I haven't had any free time to work on this. I think my board is at home.. 
>
> > Also, I noticed there isn't a "pocketbeagle-univ" version in there.   
> Should there be? 
>
> Nope, the whole idea behind the *-univ.dtbo setup was first tested 
> with the PocketBeagle by default...  Then ported to the other devices. 
>
> 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/7e734ce4-0091-4f6d-8163-3fc2b6dd0c50%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] bone kernel questions.....

[Daniel Kulp]

Any progress?   If need/want to send me a dtb to test with, that would be 
fine.

Also, I noticed there isn't a "pocketbeagle-univ" version in there.  
 Should there be?  

Dan



On Wednesday, March 27, 2019 at 1:15:10 PM UTC-4, RobertCNelson wrote:
>
> On Wed, Mar 27, 2019 at 12:04 PM Daniel Kulp > 
> wrote: 
> > 
>
> > eeprom:[A335BNLTSE0A4518BBE911FC] 
> > model:[SanCloud_BeagleBone_Enhanced]:WiFi AP Enabled:[
> https://github.com/lwfinger/rtl8723bu] 
>
> There's the problem, why didn't i see this before in your previous emails? 
>
> For the cape-universal "rewrite" to work, u-boot needs to load 
> "am335x-sancloud-bbe-uboot-univ.dtb" however today v4.19.x-bone only 
> has: 
>
> debian@beaglebone:/boot/dtbs/4.19.29-bone29$ find . | grep univ 
> ./am335x-bone-uboot-univ.dtb 
> ./am335x-boneblack-uboot-univ.dtb 
> ./am335x-bonegreen-wireless-uboot-univ.dtb 
>
> debian@beaglebone:/boot/dtbs/4.19.25-ti-r16$ find . | grep univ 
> ./am335x-bone-uboot-univ.dtb 
> ./am335x-boneblack-uboot-univ.dtb 
> ./am335x-bonegreen-wireless-uboot-univ.dtb 
>
> debian@beaglebone:/boot/dtbs/4.14.103-ti-r100$ find . | grep univ 
> ./am335x-bone-uboot-univ.dtb 
> ./am335x-boneblack-uboot-univ.dtb 
> ./am335x-bonegreen-wireless-uboot-univ.dtb 
>
> debian@beaglebone:/boot/dtbs/4.14.103-ti-r100$ find . | grep bbe 
> ./am335x-sancloud-bbe.dtb 
>
> So yeah, i need to grab my bbe, (pretty sure it's at home) and build 
> the *-univ.dtb" files.. 
>
> > dogtag:[BeagleBoard.org Debian Image 2018-10-07] 
> > bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
> 2018.09-2-g9d95a561c9]:[location: dd MBR] 
> > bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
> 2018.09-2-g9d95a561c9]:[location: dd MBR] 
> > kernel:[4.19.29-bone29] 
> > uboot_overlay_options:[enable_uboot_overlays=1] 
> > 
> uboot_overlay_options:[uboot_overlay_addr4=/lib/firmware/BB-I2C2-FAST-00A0.dtbo]
>  
>
> > uboot_overlay_options:[disable_uboot_overlay_video=1] 
> > uboot_overlay_options:[disable_uboot_overlay_audio=1] 
> > 
> uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo]
>  
>
> > uboot_overlay_options:[enable_uboot_cape_universal=1] 
> > pkg check: to individually upgrade run: [sudo apt install --only-upgrade 
> ] 
> > pkg:[bb-cape-overlays]:[4.4.20190320.1-0rcnee0~stretch+20190320] 
> > pkg:[bb-wl18xx-firmware]:[1.20190227.1-0rcnee0~stretch+20190227] 
> > pkg:[kmod]:[23-2rcnee1~stretch+20171005] 
> > WARNING:pkg:[librobotcontrol]:[NOT_INSTALLED] 
> > pkg:[firmware-ti-connectivity]:[20180825+dfsg-1rcnee1~stretch+20181217] 
> > groups:[debian : debian adm kmem dialout cdrom floppy audio dip video 
> plugdev users systemd-journal netdev gpio pwm eqep admin spi i2c tisdk 
> weston-launch xenomai bluetooth cloud9ide] 
> > cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
> root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
> net.ifnames=0 rootwait quiet] 
> > dmesg | grep remote 
> > [0.628740] remoteproc remoteproc0: wkup_m3 is available 
> > [0.940053] remoteproc remoteproc0: powering up wkup_m3 
> > [0.940074] remoteproc remoteproc0: Booting fw image 
> am335x-pm-firmware.elf, size 217168 
> > [0.942727] remoteproc remoteproc0: remote processor wkup_m3 is now 
> up 
> > dmesg | grep pru 
> > 
> > root@FPPTest:/opt/scripts/tools# config-pin -q P9.11 
> > P9_11 pinmux file not found! 
> > Cannot read pinmux file: 
> /sys/devices/platform/ocp/ocp*P9_11_pinmux/state 
> > 
> > If I can get it working with 4.19, I'd be OK with that, but right now, 
> it's not.   Since I'm trying to create new images for my devices, I can 
> definitely move everything to 4.19.  The "problem" I have is a couple of 
> the out-of-kernel wifi drivers I build/include don't yet build properly 
> with 4.19 which is why I've considered staying on 4.14.   That's a minor 
> issue though. 
>
> it looks like the rtl8723bu built.. does it not work?  are they 
> shipping with the  rtl8821cu now too? 
>
> 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/b320e77e-32b4-49ec-9a52-f7384d0a14f0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] bone kernel questions.....

[Daniel Kulp]

On Wednesday, March 27, 2019 at 1:15:10 PM UTC-4, RobertCNelson wrote:
>
>
> it looks like the rtl8723bu built.. does it not work?  are they 
> shipping with the  rtl8821cu now too? 
>
>
The one I got a couple months ago is still using the 8723bu.   I haven't 
gotten it to connect yet though.   The wlan devices appear and I can scan 
services, but I haven't gotten it to connect.  Not sure what's going on 
with it.   

That said, my bigger issue my users that are using my pocketbeagle based 
capes and grabbing some random USB wifi adapter off Amazon that "claims" to 
have Linux support.   I have 6 other external drivers that I have currently 
been building for various use cases.  (mostly around adapters on the 5ghz 
bands)A couple of those aren't building with 4.19 yet.  I just haven't 
had time to look into those. Not your issue to deal with.  

-- 
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/e84e1432-0fb8-4763-8e48-131d277f5fc8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] bone kernel questions.....

[Daniel Kulp]

Right after I posted that I realized the same thing and decided to flip the 
SD card over to a BBB Industrial (don't have a  regular "black" sitting 
here, need to go digging). It does work there as long as I get the 
bootloader updated to 2018.09.   Doesn't work with 2018.01.OK.  At 
least we know where the issue is.  ;)That's a good step.

Dan


On Wednesday, March 27, 2019 at 1:15:10 PM UTC-4, RobertCNelson wrote:
>
> On Wed, Mar 27, 2019 at 12:04 PM Daniel Kulp > 
> wrote: 
> > 
>
> > eeprom:[A335BNLTSE0A4518BBE911FC] 
> > model:[SanCloud_BeagleBone_Enhanced]:WiFi AP Enabled:[
> https://github.com/lwfinger/rtl8723bu] 
>
> There's the problem, why didn't i see this before in your previous emails? 
>
> For the cape-universal "rewrite" to work, u-boot needs to load 
> "am335x-sancloud-bbe-uboot-univ.dtb" however today v4.19.x-bone only 
> has: 
>
> debian@beaglebone:/boot/dtbs/4.19.29-bone29$ find . | grep univ 
> ./am335x-bone-uboot-univ.dtb 
> ./am335x-boneblack-uboot-univ.dtb 
> ./am335x-bonegreen-wireless-uboot-univ.dtb 
>
> debian@beaglebone:/boot/dtbs/4.19.25-ti-r16$ find . | grep univ 
> ./am335x-bone-uboot-univ.dtb 
> ./am335x-boneblack-uboot-univ.dtb 
> ./am335x-bonegreen-wireless-uboot-univ.dtb 
>
> debian@beaglebone:/boot/dtbs/4.14.103-ti-r100$ find . | grep univ 
> ./am335x-bone-uboot-univ.dtb 
> ./am335x-boneblack-uboot-univ.dtb 
> ./am335x-bonegreen-wireless-uboot-univ.dtb 
>
> debian@beaglebone:/boot/dtbs/4.14.103-ti-r100$ find . | grep bbe 
> ./am335x-sancloud-bbe.dtb 
>
> So yeah, i need to grab my bbe, (pretty sure it's at home) and build 
> the *-univ.dtb" files.. 
>
> > dogtag:[BeagleBoard.org Debian Image 2018-10-07] 
> > bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
> 2018.09-2-g9d95a561c9]:[location: dd MBR] 
> > bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
> 2018.09-2-g9d95a561c9]:[location: dd MBR] 
> > kernel:[4.19.29-bone29] 
> > uboot_overlay_options:[enable_uboot_overlays=1] 
> > 
> uboot_overlay_options:[uboot_overlay_addr4=/lib/firmware/BB-I2C2-FAST-00A0.dtbo]
>  
>
> > uboot_overlay_options:[disable_uboot_overlay_video=1] 
> > uboot_overlay_options:[disable_uboot_overlay_audio=1] 
> > 
> uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo]
>  
>
> > uboot_overlay_options:[enable_uboot_cape_universal=1] 
> > pkg check: to individually upgrade run: [sudo apt install --only-upgrade 
> ] 
> > pkg:[bb-cape-overlays]:[4.4.20190320.1-0rcnee0~stretch+20190320] 
> > pkg:[bb-wl18xx-firmware]:[1.20190227.1-0rcnee0~stretch+20190227] 
> > pkg:[kmod]:[23-2rcnee1~stretch+20171005] 
> > WARNING:pkg:[librobotcontrol]:[NOT_INSTALLED] 
> > pkg:[firmware-ti-connectivity]:[20180825+dfsg-1rcnee1~stretch+20181217] 
> > groups:[debian : debian adm kmem dialout cdrom floppy audio dip video 
> plugdev users systemd-journal netdev gpio pwm eqep admin spi i2c tisdk 
> weston-launch xenomai bluetooth cloud9ide] 
> > cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
> root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
> net.ifnames=0 rootwait quiet] 
> > dmesg | grep remote 
> > [0.628740] remoteproc remoteproc0: wkup_m3 is available 
> > [0.940053] remoteproc remoteproc0: powering up wkup_m3 
> > [0.940074] remoteproc remoteproc0: Booting fw image 
> am335x-pm-firmware.elf, size 217168 
> > [0.942727] remoteproc remoteproc0: remote processor wkup_m3 is now 
> up 
> > dmesg | grep pru 
> > 
> > root@FPPTest:/opt/scripts/tools# config-pin -q P9.11 
> > P9_11 pinmux file not found! 
> > Cannot read pinmux file: 
> /sys/devices/platform/ocp/ocp*P9_11_pinmux/state 
> > 
> > If I can get it working with 4.19, I'd be OK with that, but right now, 
> it's not.   Since I'm trying to create new images for my devices, I can 
> definitely move everything to 4.19.  The "problem" I have is a couple of 
> the out-of-kernel wifi drivers I build/include don't yet build properly 
> with 4.19 which is why I've considered staying on 4.14.   That's a minor 
> issue though. 
>
> it looks like the rtl8723bu built.. does it not work?  are they 
> shipping with the  rtl8821cu now too? 
>
> 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/5582690d-4857-45ef-bd31-5ccf440c896d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] bone kernel questions.....

[Daniel Kulp]

#2 is definitely NOT working for me... 

root@FPPTest:/opt/scripts/tools# ./version.sh
git:/opt/scripts/:[2f062cfde221878a2bcb4ea87d0622aab74728e0]
eeprom:[A335BNLTSE0A4518BBE911FC]
model:[SanCloud_BeagleBone_Enhanced]:WiFi AP 
Enabled:[https://github.com/lwfinger/rtl8723bu]
dogtag:[BeagleBoard.org Debian Image 2018-10-07]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
2018.09-2-g9d95a561c9]:[location: dd MBR]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
2018.09-2-g9d95a561c9]:[location: dd MBR]
kernel:[4.19.29-bone29]
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[uboot_overlay_addr4=/lib/firmware/BB-I2C2-FAST-00A0.dtbo]
uboot_overlay_options:[disable_uboot_overlay_video=1]
uboot_overlay_options:[disable_uboot_overlay_audio=1]
uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
pkg check: to individually upgrade run: [sudo apt install --only-upgrade 
]
pkg:[bb-cape-overlays]:[4.4.20190320.1-0rcnee0~stretch+20190320]
pkg:[bb-wl18xx-firmware]:[1.20190227.1-0rcnee0~stretch+20190227]
pkg:[kmod]:[23-2rcnee1~stretch+20171005]
WARNING:pkg:[librobotcontrol]:[NOT_INSTALLED]
pkg:[firmware-ti-connectivity]:[20180825+dfsg-1rcnee1~stretch+20181217]
groups:[debian : debian adm kmem dialout cdrom floppy audio dip video 
plugdev users systemd-journal netdev gpio pwm eqep admin spi i2c tisdk 
weston-launch xenomai bluetooth cloud9ide]
cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
net.ifnames=0 rootwait quiet]
dmesg | grep remote
[0.628740] remoteproc remoteproc0: wkup_m3 is available
[0.940053] remoteproc remoteproc0: powering up wkup_m3
[0.940074] remoteproc remoteproc0: Booting fw image 
am335x-pm-firmware.elf, size 217168
[0.942727] remoteproc remoteproc0: remote processor wkup_m3 is now up
dmesg | grep pru

root@FPPTest:/opt/scripts/tools# config-pin -q P9.11
P9_11 pinmux file not found!
Cannot read pinmux file: /sys/devices/platform/ocp/ocp*P9_11_pinmux/state

If I can get it working with 4.19, I'd be OK with that, but right now, it's 
not.   Since I'm trying to create new images for my devices, I can 
definitely move everything to 4.19.  The "problem" I have is a couple of 
the out-of-kernel wifi drivers I build/include don't yet build properly 
with 4.19 which is why I've considered staying on 4.14.   That's a minor 
issue though.  

Dan



On Wednesday, March 27, 2019 at 12:49:56 PM UTC-4, RobertCNelson wrote:
>
> On Wed, Mar 27, 2019 at 11:32 AM Daniel Kulp > 
> wrote: 
> > 
> > 
> > Couple of questions regarding the bone kernels 
> > 
> > 1) Is there a reason update_kernel doesn't install the various "extras" 
> for the bone kernel like it does for the ti kernels?   I don't really care 
> as I don't need them, but it kind of surprised me that libpruio and such 
> were not installed. 
>
>
> https://github.com/RobertCNelson/boot-scripts/blob/2f062cfde221878a2bcb4ea87d0622aab74728e0/tools/update_kernel.sh#L565-L567
>  
>
> So yes, this should be extended to 4.19.x-bone, v4.14.x-bone-rt and 
> v4.19.x-bone-rt.. 
>
> > 2) Is there any indication if/when the problem of BB-I2C2-FAST-00A0 not 
> allowing cape-universal to work will be fixed for the bone kernels?  At 
> least for 4.19 but preferably also for 4.14.  I'm kind of working around 
> the issue by explicitly adding cape-universalh-00A0 to the overlays, but 
> that's kind of a crappy way to do it. 
>
> This "works" fine in 4.19.x, the issue is you want me to spend time 
> back-porting this feature i originally started working in on 
> v4.16.x-bone back to v4.14.x-bone..  My big question is why? everyone 
> hated v4.14.x-bone-rt so they either stayed on v4.4.x-bone-rt or now 
> jumped to 4.19.x-bone-rt..  Thus give me an actual use case why 
> v4.14.x-bone vs v4.19.x-bone at this point.. 
>
> debian@beaglebone:~$ sudo /opt/scripts/tools/version.sh 
> git:/opt/scripts/:[2f062cfde221878a2bcb4ea87d0622aab74728e0] 
> eeprom:[A335BNLT000C1830BBBG0785] 
> model:[TI_AM335x_BeagleBone_Black] 
> dogtag:[BeagleBoard.org Debian Image 2019-03-24] 
> bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
> 2018.09-2-g9d95a561c9]:[location: dd MBR] 
> bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
> 2018.09-2-g0b54a51eee]:[location: dd MBR] 
> kernel:[4.19.29-bone29] 
> nodejs:[v6.17.0] 
> uboot_overlay_options:[enable_uboot_overlays=1] 
> uboot_overlay_options:[uboot_overlay_addr4=/lib/firmware/BB-I2C2-FAST-00A0.dtbo]
>  
>
> uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo]
>  
>
> uboot_overlay_options:[enable_uboot_c

[beagleboard] bone kernel questions.....

[Daniel Kulp]

Couple of questions regarding the bone kernels

1) Is there a reason update_kernel doesn't install the various "extras" for 
the bone kernel like it does for the ti kernels?   I don't really care as I 
don't need them, but it kind of surprised me that libpruio and such were 
not installed.   

2) Is there any indication if/when the problem of BB-I2C2-FAST-00A0 not 
allowing cape-universal to work will be fixed for the bone kernels?  At 
least for 4.19 but preferably also for 4.14.  I'm kind of working around 
the issue by explicitly adding cape-universalh-00A0 to the overlays, but 
that's kind of a crappy way to do it.   

Related to #2: if we include BB-I2C2-FAST-00A0 , then it excludes those 
pins from cape-universal/pinmux entirely.   Thus, we cannot "config-pin" 
them to be output pins if we don't need the i2c bus. I've created my 
own dts that only configures the i2c clock and leaves the pins alone.   I'm 
trying to determine if there are any issues with that, and if not, why 
isn't that the default?


Thanks!
Dan

-- 
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/851027d4-a42c-4d3e-8cdd-31d9392cc89f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] i2c bus speed and cape universal...

[Daniel Kulp]

Got around to actually testing and I was completely wrong.   With the 
latest bone kernel (4.19.26-bone26), I cannot get the faster i2c bus and 
still have universal working.   As soon as I add 
the BB-I2C2-FAST-FPP-00A0.dtbo overlay, all the pinmux files are gone and 
thus none of the "config-pin" things work.  :(

Dan



On Tuesday, February 19, 2019 at 4:41:47 PM UTC-5, Daniel Kulp wrote:
>
>
> OK.   Just updated to 4.19.23-bone22.Faster i2c seems to work and UIO 
> at least doesn’t crash my app.  Haven’t actually tested anything, but it at 
> least starts.
>
> Thanks!
> Dan
>
>
>
> On Feb 19, 2019, at 4:06 PM, Robert Nelson wrote:
>
> On Tue, Feb 19, 2019 at 2:20 PM Daniel Kulp wrote:
>
>
>
> It shouldn't.. which means something else is going on..
>
> Can you share:
>
> sudo /opt/scripts/tools/version.sh
>
>
>
>
> root@FPPTest:/opt/scripts/tools# ./version.sh
> git:/opt/scripts/:[e9bcff232834702c1c810710706ee815d77b080b]
> eeprom:[A335BNLTEIA03116BBBK0A88]
> model:[TI_AM335x_BeagleBone_Black]
> dogtag:[BeagleBoard.org Debian Image 2018-10-07]
> bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
> 2018.09-2-gbc653b9d91]:[location: dd MBR]
> bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
> 2018.09-2-gbc653b9d91]:[location: dd MBR]
> kernel:[4.14.71-bone17]
> uboot_overlay_options:[enable_uboot_overlays=1]
>
> uboot_overlay_options:[uboot_overlay_addr4=/lib/firmware/BB-I2C2-FAST-00A0.dtbo]
> uboot_overlay_options:[disable_uboot_overlay_video=1]
> uboot_overlay_options:[disable_uboot_overlay_audio=1]
>
> uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo]
> uboot_overlay_options:[enable_uboot_cape_universal=1]
> pkg check: to individually upgrade run: [sudo apt install --only-upgrade 
> ]
> pkg:[bb-cape-overlays]:[4.4.20181019.0-0rcnee0~stretch+20181019]
> pkg:[bb-wl18xx-firmware]:[1.20180517-0rcnee0~stretch+20180517]
> pkg:[kmod]:[23-2rcnee1~stretch+20171005]
> WARNING:pkg:[librobotcontrol]:[NOT_INSTALLED]
> pkg:[firmware-ti-connectivity]:[20170823-1rcnee1~stretch+20180328]
> groups:[debian : debian adm kmem dialout cdrom floppy audio dip video 
> plugdev users systemd-journal netdev gpio pwm eqep admin spi i2c tisdk 
> weston-launch xenomai bluetooth cloud9ide]
> cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
> root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
> net.ifnames=0 rootwait quiet]
> dmesg | grep pinctrl-single
> [0.635136] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 
> size 568
> dmesg | grep gpio-of-helper
> [0.636374] gpio-of-helper ocp:cape-universal: ready
> END
> root@FPPTest:/opt/scripts/tools# config-pin -q P9-41
> P9_41 pinmux file not found!
> Cannot read pinmux file: /sys/devices/platform/ocp/ocp*P9_41_pinmux/state
> root@FPPTest:/opt/scripts/tools#
>
>
> Okay, reproduced:
>
> loading /boot/vmlinuz-4.14.93-bone17 ...
> 8937984 bytes read in 585 ms (14.6 MiB/s)
> debug: [enable_uboot_overlays=1] ...
> debug: [enable_uboot_cape_universal=1] ...
> debug: [uboot_base_dtb_univ=am335x-boneblack-uboot-univ.dtb] ...
> uboot_overlays: [uboot_base_dtb=am335x-boneblack-uboot-univ.dtb] ...
> debug: unable to find [am335x-boneblack-uboot-univ.dtb] using
> [am335x-boneblack-uboot.dtb] instead ...
> debug: [uboot_base_dtb_univ=am335x-boneblack-uboot.dtb] ...
> uboot_overlays: [uboot_base_dtb=am335x-boneblack-uboot.dtb] ...
> uboot_overlays: Switching too: dtb=am335x-boneblack-uboot.dtb ...
> loading /boot/dtbs/4.14.93-bone17/am335x-boneblack-uboot.dtb ...
>
> So looking back at my development log, I started the "cape universal
> rewrite" during the v4.16.x-bone cycle, didn't fully finalize things
> till v4.19.x-bone, and back ported it to v4.14.x-ti..
>
> So yeah, i didn't back port it to v4.14.x-bone..
>
> Regards,
>
> -- 
> Robert Nelson
> https://rcn-ee.com/
>
>
> -- 
> Daniel Kulp
> http://dankulp.com/blog
>
>

-- 
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/e852b052-c932-4872-ab34-5df8c0572513%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] i2c bus speed and cape universal...

[Daniel Kulp]

OK.   Just updated to 4.19.23-bone22.Faster i2c seems to work and UIO at 
least doesn’t crash my app.  Haven’t actually tested anything, but it at least 
starts.

Thanks!
Dan



> On Feb 19, 2019, at 4:06 PM, Robert Nelson  wrote:
> 
> On Tue, Feb 19, 2019 at 2:20 PM Daniel Kulp  <mailto:d...@kulp.com>> wrote:
>> 
>> 
>> It shouldn't.. which means something else is going on..
>> 
>> Can you share:
>> 
>> sudo /opt/scripts/tools/version.sh
>> 
>> 
>> 
>> 
>> root@FPPTest:/opt/scripts/tools# ./version.sh
>> git:/opt/scripts/:[e9bcff232834702c1c810710706ee815d77b080b]
>> eeprom:[A335BNLTEIA03116BBBK0A88]
>> model:[TI_AM335x_BeagleBone_Black]
>> dogtag:[BeagleBoard.org Debian Image 2018-10-07]
>> bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
>> 2018.09-2-gbc653b9d91]:[location: dd MBR]
>> bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
>> 2018.09-2-gbc653b9d91]:[location: dd MBR]
>> kernel:[4.14.71-bone17]
>> uboot_overlay_options:[enable_uboot_overlays=1]
>> uboot_overlay_options:[uboot_overlay_addr4=/lib/firmware/BB-I2C2-FAST-00A0.dtbo]
>> uboot_overlay_options:[disable_uboot_overlay_video=1]
>> uboot_overlay_options:[disable_uboot_overlay_audio=1]
>> uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo]
>> uboot_overlay_options:[enable_uboot_cape_universal=1]
>> pkg check: to individually upgrade run: [sudo apt install --only-upgrade 
>> ]
>> pkg:[bb-cape-overlays]:[4.4.20181019.0-0rcnee0~stretch+20181019]
>> pkg:[bb-wl18xx-firmware]:[1.20180517-0rcnee0~stretch+20180517]
>> pkg:[kmod]:[23-2rcnee1~stretch+20171005]
>> WARNING:pkg:[librobotcontrol]:[NOT_INSTALLED]
>> pkg:[firmware-ti-connectivity]:[20170823-1rcnee1~stretch+20180328]
>> groups:[debian : debian adm kmem dialout cdrom floppy audio dip video 
>> plugdev users systemd-journal netdev gpio pwm eqep admin spi i2c tisdk 
>> weston-launch xenomai bluetooth cloud9ide]
>> cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
>> root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
>> net.ifnames=0 rootwait quiet]
>> dmesg | grep pinctrl-single
>> [0.635136] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 
>> 568
>> dmesg | grep gpio-of-helper
>> [0.636374] gpio-of-helper ocp:cape-universal: ready
>> END
>> root@FPPTest:/opt/scripts/tools# config-pin -q P9-41
>> P9_41 pinmux file not found!
>> Cannot read pinmux file: /sys/devices/platform/ocp/ocp*P9_41_pinmux/state
>> root@FPPTest:/opt/scripts/tools#
> 
> Okay, reproduced:
> 
> loading /boot/vmlinuz-4.14.93-bone17 ...
> 8937984 bytes read in 585 ms (14.6 MiB/s)
> debug: [enable_uboot_overlays=1] ...
> debug: [enable_uboot_cape_universal=1] ...
> debug: [uboot_base_dtb_univ=am335x-boneblack-uboot-univ.dtb] ...
> uboot_overlays: [uboot_base_dtb=am335x-boneblack-uboot-univ.dtb] ...
> debug: unable to find [am335x-boneblack-uboot-univ.dtb] using
> [am335x-boneblack-uboot.dtb] instead ...
> debug: [uboot_base_dtb_univ=am335x-boneblack-uboot.dtb] ...
> uboot_overlays: [uboot_base_dtb=am335x-boneblack-uboot.dtb] ...
> uboot_overlays: Switching too: dtb=am335x-boneblack-uboot.dtb ...
> loading /boot/dtbs/4.14.93-bone17/am335x-boneblack-uboot.dtb ...
> 
> So looking back at my development log, I started the "cape universal
> rewrite" during the v4.16.x-bone cycle, didn't fully finalize things
> till v4.19.x-bone, and back ported it to v4.14.x-ti..
> 
> So yeah, i didn't back port it to v4.14.x-bone..
> 
> Regards,
> 
> -- 
> Robert Nelson
> https://rcn-ee.com/ <https://rcn-ee.com/>
-- 
Daniel Kulp
d...@kulp.com <mailto:d...@kulp.com> - http://dankulp.com/blog 
<http://dankulp.com/blog>

-- 
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/80727CFE-CB70-4108-9A07-995EE72C7377%40kulp.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] i2c bus speed and cape universal...

[Daniel Kulp]

> 
> It shouldn't.. which means something else is going on..
> 
> Can you share:
> 
> sudo /opt/scripts/tools/version.sh



root@FPPTest:/opt/scripts/tools# ./version.sh
git:/opt/scripts/:[e9bcff232834702c1c810710706ee815d77b080b]
eeprom:[A335BNLTEIA03116BBBK0A88]
model:[TI_AM335x_BeagleBone_Black]
dogtag:[BeagleBoard.org Debian Image 2018-10-07]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
2018.09-2-gbc653b9d91]:[location: dd MBR]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
2018.09-2-gbc653b9d91]:[location: dd MBR]
kernel:[4.14.71-bone17]
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[uboot_overlay_addr4=/lib/firmware/BB-I2C2-FAST-00A0.dtbo]
uboot_overlay_options:[disable_uboot_overlay_video=1]
uboot_overlay_options:[disable_uboot_overlay_audio=1]
uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
pkg check: to individually upgrade run: [sudo apt install --only-upgrade ]
pkg:[bb-cape-overlays]:[4.4.20181019.0-0rcnee0~stretch+20181019]
pkg:[bb-wl18xx-firmware]:[1.20180517-0rcnee0~stretch+20180517]
pkg:[kmod]:[23-2rcnee1~stretch+20171005]
WARNING:pkg:[librobotcontrol]:[NOT_INSTALLED]
pkg:[firmware-ti-connectivity]:[20170823-1rcnee1~stretch+20180328]
groups:[debian : debian adm kmem dialout cdrom floppy audio dip video plugdev 
users systemd-journal netdev gpio pwm eqep admin spi i2c tisdk weston-launch 
xenomai bluetooth cloud9ide]
cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 
rootwait quiet]
dmesg | grep pinctrl-single
[0.635136] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 568
dmesg | grep gpio-of-helper
[0.636374] gpio-of-helper ocp:cape-universal: ready
END
root@FPPTest:/opt/scripts/tools# config-pin -q P9-41
P9_41 pinmux file not found!
Cannot read pinmux file: /sys/devices/platform/ocp/ocp*P9_41_pinmux/state
root@FPPTest:/opt/scripts/tools#



-- 
Daniel Kulp
d...@kulp.com <mailto:d...@kulp.com> - http://dankulp.com/blog 
<http://dankulp.com/blog>

-- 
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/AA2039AC-04CF-43C6-9E5E-81A5D80BFCC7%40kulp.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] i2c bus speed and cape universal...

[Daniel Kulp]

> On Feb 19, 2019, at 2:54 PM, Robert Nelson  wrote:
> 
> On Tue, Feb 19, 2019 at 1:05 PM Daniel Kulp  wrote:
>> 
>> 
>> Question:  has anyone figured out how to set the I2C bus speed without 
>> disabling cape-universal?I'd like to increase the bus speed from 100khz 
>> to 400, but every attempt I make using overlays from uEnv.txt seems to also 
>> disable cape-universal which I also need.   Do I need to explicitly  add the 
>> appropriate cape-universal overlay to the list of overlays? It seem like 
>> if I do:
>> 
>> uboot_overlay_addr4=/lib/firmware/cape-universalh-00A0.dtbo
>> uboot_overlay_addr5=/lib/firmware/BB-I2C2-FAST-FPP-00A0.dtbo
>> 
>> then the universal stuff works, but is that really what I'm supposed to do?  
>>   Seems a bit more error prone as the disable_uboot_overlay_* stuff doesn't 
>> seem to come into play and I need to grab the appropriate cape-universal* 
>> file manually.
> 
> It sounds like you missed something in your "custom": 
> BB-I2C2-FAST-FPP-00A0.dtbo
> 
> Compare with:
> 
> https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-I2C2-FAST-00A0.dts
> 
> Then cape-universal should work automatically..

No..   The reason I created the custom one was to try and see if I can get it 
to work.If I use BB-I2C2-FAST-00A0, all the universal stuff isn’t working 
either.   


-- 
Daniel Kulp
d...@kulp.com <mailto:d...@kulp.com> - http://dankulp.com/blog 
<http://dankulp.com/blog>

-- 
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/C16FFC92-D35F-4F4A-91EE-07D5E09B7325%40kulp.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] i2c bus speed and cape universal...

[Daniel Kulp]

Question:  has anyone figured out how to set the I2C bus speed without 
disabling cape-universal?I'd like to increase the bus speed from 100khz 
to 400, but every attempt I make using overlays from uEnv.txt seems to also 
disable cape-universal which I also need.   Do I need to explicitly  add 
the appropriate cape-universal overlay to the list of overlays? It seem 
like if I do:

uboot_overlay_addr4=/lib/firmware/cape-universalh-00A0.dtbo
uboot_overlay_addr5=/lib/firmware/BB-I2C2-FAST-FPP-00A0.dtbo

then the universal stuff works, but is that really what I'm supposed to 
do?Seems a bit more error prone as the disable_uboot_overlay_* stuff 
doesn't seem to come into play and I need to grab the appropriate 
cape-universal* file manually.   

Thanks!
Dan

-- 
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/a9496404-10af-4a81-9d9a-03ccfe292f72%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: What's the easiest way to update kernel?

[Daniel Kulp]

On Friday, February 15, 2019 at 3:48:25 PM UTC-5, Chris Green wrote:
>
>
> Anyway, are there any particular reasons for going for any specific 
> kernel other than the latest?  Presumably 3.8.x will start getting 
> less support (if it hasn't already). 
>

There are certain apps that behave very differently with various kernels.  
 I know my application does not work nearly as well with the "-ti" kernels 
but works perfectly with the "-bone" kernels.   We've had major issues with 
4.19 (looks like that is getting resolved soon).  The -rt and non-rt 
kernels have various uses cases where they are either needed or should not 
be used.   Boot times are also affected by the kernel selection.So yes, 
there are definite reasons for being able to control exactly which kernel 
is used on your device.   

-- 
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/7a335f6c-dbf1-4619-9b72-e3039e8d3233%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] 4.19 bone kernel with uio_pruss?

[Daniel Kulp]

> On Feb 15, 2019, at 2:49 PM, Robert Nelson  wrote:
> 
> On Fri, Feb 15, 2019 at 1:47 PM Daniel Kulp  wrote:
>> 
>> 
>> My app seems to work fine with 4.19.15-ti-r9 and the ORIGINAL PRU-UIO 
>> overlay, but crashes hard on startup with the new PRU-UIO.
>> 
>> Not sure if that helps much.   Definitely a step in the right direction.   
>> The app runs and my LED panels light up and everything with just the kernel 
>> update.
>> 
> 
> Thanks for testing! I'll remove that notes on the newer uio overlay.
> 

Next question:  I kind of had a hard time trying to follow this entire 
discussion.   I know you really just deal with the “ti” kernel, but my app has 
never run very well on the ti kernel but works perfectly with the “bone” 
kernel.  Do you happen to know if the changes you incorporated into this new ti 
kernel will also be put into the bone kernel?   

-- 
Daniel Kulp
d...@kulp.com <mailto:d...@kulp.com> - http://dankulp.com/blog 
<http://dankulp.com/blog>

-- 
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/8241DF12-5FC6-4B47-B7FF-1E40E639E092%40kulp.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] 4.19 bone kernel with uio_pruss?

[Daniel Kulp]

My app seems to work fine with 4.19.15-ti-r9 and the ORIGINAL PRU-UIO overlay, 
but crashes hard on startup with the new PRU-UIO.

Not sure if that helps much.   Definitely a step in the right direction.   The 
app runs and my LED panels light up and everything with just the kernel update. 


Dan






> On Feb 15, 2019, at 2:14 PM, Robert Nelson  wrote:
> 
> Hi Daniel,
> 
> Can you please test:
> 
> sudo apt update
> sudo apt install --only-upgrade bb-cape-overlays
> sudo /opt/scripts/tools/update_kernel.sh
> 
> then in /boot/uEnv.txt and set:
> 
> uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-4-19-00A0.dtbo
> 
> debian@beaglebone:~$ uname -r
> 4.19.15-ti-r9
> 
> Regards,
> 
> -- 
> Robert Nelson
> https://rcn-ee.com/
> 
> -- 
> For more options, visit http://beagleboard.org/discuss
> --- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/beagleboard/poKd5tCRD04/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/CAOCHtYhDNONwBWekk3FqEWw4814jFD8bopyTC6sS9kHT1oPxMQ%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
Daniel Kulp
d...@kulp.com <mailto:d...@kulp.com> - http://dankulp.com/blog 
<http://dankulp.com/blog>

-- 
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/268DDB7F-D2CA-4A27-9C0B-D61156A2F69D%40kulp.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] 4.19 bone kernel with uio_pruss?

[Daniel Kulp]

> On Feb 12, 2019, at 8:31 PM, Matthijs van Duin  
> wrote:
> 
> On Tue, 12 Feb 2019 at 19:56, Robert Nelson  <mailto:robertcnel...@gmail.com>> wrote:
> I just enabled the first patch by default:
> 
> https://github.com/RobertCNelson/ti-linux-kernel-dev/blob/ti-linux-4.19.y/patch.sh#L489-L492
>  
> <https://github.com/RobertCNelson/ti-linux-kernel-dev/blob/ti-linux-4.19.y/patch.sh#L489-L492>
> 
> Ahh, I missed that. I just saw the merge in the git commits and didn't 
> realize it was a merge with modifications.
> 
> I wonder what's going on then, I'll see if I can replicate the problem.
> 
> Daniel, when you say "crash", you mean a SIGBUS presumably?
> 

Yep.  SIGBUS.


-- 
Daniel Kulp
d...@kulp.com <mailto:d...@kulp.com> - http://dankulp.com/blog 
<http://dankulp.com/blog>

-- 
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/2614F983-9A99-48D4-AC4C-D2585B4310CB%40kulp.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] 4.19 bone kernel with uio_pruss?

[Daniel Kulp]

On Tuesday, February 12, 2019 at 1:06:51 PM UTC-5, Matthijs van Duin wrote:
>
> I just realized that enabling it in the base dts for beaglebone using a 
> remoteproc-pru compatible structure was probably a bad idea... While it is 
> safe to apply the remoteproc-pru overlay on top of it (albeit pointless 
> since it hasn't been ported to 4.19 yet), applying the uio-pruss overlay on 
> top of it would create a mess.
>
> Assuming you have the UIO-PRUSS overlay enabled, try disabling it.
>
>
Without the uio-pruss overlay, I don't get any /dev/uio entries and then 
nothing works.Is there a different overlay I need?
 

-- 
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/4c18b8e9-4a43-439c-9c13-304c26880e99%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] 4.19 bone kernel with uio_pruss?

[Daniel Kulp]

Well,  it's still not working for our application.   :(Something isn't 
working the same as it used to.  

If you grab the old am335x_pru_package stuff 
from https://github.com/beagleboard/am335x_pru_package and build/install, 
none of the examples work either.They all crash:

#0  0xb5ac6ffc in __pruss_detect_hw_version () from 
/usr/local/lib/libprussdrv.so
#1  0xb5ac717e in __prussdrv_memmap_init () from 
/usr/local/lib/libprussdrv.so
#2  0xb5ac74b8 in prussdrv_open () from /usr/local/lib/libprussdrv.so

so it looks like something is behaving differently or is laid out in memory 
differently or something.   Not sure.

Dan



On Monday, February 11, 2019 at 1:18:25 PM UTC-5, RobertCNelson wrote:
>
> On Sun, Feb 10, 2019 at 3:52 PM Daniel Kulp > 
> wrote: 
> > 
> > 
> > Many thanks for digging through this... once this is available in a 
> kernel I can install via "update_kernel.sh", I'd be more than happy to test 
> my UIO based apps and such. 
>
> Matthijs patchset is now merged into 4.19.15-ti-r8, should be pushed 
> out in a few hours. 
>
> 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/efa1a028-cedf-4cc1-8f9a-556fd0e9d32f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] 4.19 bone kernel with uio_pruss?

[Daniel Kulp]

Many thanks for digging through this... once this is available in a kernel 
I can install via "update_kernel.sh", I'd be more than happy to test my UIO 
based apps and such.

Dan


On Saturday, February 9, 2019 at 6:00:27 PM UTC-5, Matthijs van Duin wrote:
>
> I've forward-ported the uio-pruss driver to the 4.19 kernel series, and 
> cleaned it up a bit in the process. I've done a quick test on beaglebone 
> black and on beagleboard-x15 (both pru instances), including that irqs work.
>
> Here's the patchset:
>
> https://github.com/mvduin/ti-linux-kernel-dev/tree/ti-linux-4.19.y-uio-pruss/patches/pruss
> Only the first patch is needed on beaglebone, the second one is 
> beagleboard-x15 specific. The third patch enables uio-pruss in the base 
> dts, which you'll need for beagleboard-x15 but on beaglebone you can also 
> just use the AM335X-PRU-UIO overlay instead.
>
> Matthijs
>

-- 
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/26944dca-2318-4405-96d3-a137e4531cfd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] SanCloud BBE and P8-10

[Daniel Kulp]

I've been testing my apps/capes with a couple of the SanCloud BBE devices 
to see how they work and did run into a little problem.   I contacted 
SanCloud and they confirmed that P8-10 on the BBE is a "no connect".   This 
is documented on their web site (see pin mapping section 
of https://www.sancloud.co.uk/?page_id=254 ) but I completely missed it. 

In any case, cape-universal and such still shows the pin as configurable 
and config-pin and such can be used to set the pin as gpio out and such.  
Is still appears in /sys/class/gpio/.  Etc...  It just doesn't work as it's 
a no-connect.  The question is:  should the device tree or whatever remove 
that pin on the BBE?  For me, it was confusing as, from the OS level, it 
looks like it should work and it looks like I can configure it and use it, 
but then it didn't work.   However, on the flip side, my C++ code would 
have crashed (poor programming on my side) if the stuff in /sys wasn't 
there as I kind of assumed on the BBB's that it's there. I can 
definitely update my code (working on that), but the question does remain: 
should the devices that cannot work exist in the tree?


-- 
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/5306bb34-c70a-430f-8d73-634adae403d6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Starting up a freshly built BBB

[Daniel N]

I have a developer working on integrating the BBB design with a cape into a 
single PCB.  When the board is assembled, I assume that at a minimum, we 
need to program the onboard EEPROM with parameters to tell the system what 
it's booting up with.  Is this done through the JTAG port?  Do any of other 
parts need to be flashed before it will recognize and boot from uSD?

-- 
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/b1dce8f8-c23d-42dc-bbc2-2bfc6b77a20b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: 4.19 bone kernel with uio_pruss?

[Daniel Kulp]

On Monday, January 28, 2019 at 4:20:33 PM UTC-5, Jason Kridner wrote:
>
> On Monday, January 28, 2019 at 1:57:56 PM UTC-5, Daniel Kulp wrote:
>>
>>
>> I tried to update our app image from the 4.14 bone kernel to the 4.19 
>> bone kernel and ran into a big problem:  uio_pruss is not configured in as 
>> it is with 4.14.  Is this an oversight?  Is there anyone I need to contact 
>> to try and convince them to re-enable uio_pruss? I'd like to 
>> get CONFIG_SND_DUMMY also enabled (module) as that would allow us to use 
>> some same configuration between Pi's and BBB's, but that's really minor.  
>>  uio_pruss is a must-have.  
>>
>> The ti kernels also don't have it, but I cannot use the ti kernels due to 
>> other timing reasons.  Mostly concerned about the bone kernels right now.
>>
>>
> For your use case, does it work if CONFIG_SND_DUMMY is added to Robert's 
> 4.14-ti builds? 
>
 
No idea... I've never tried building a kernel for the BBB's.  I've always 
just relied on the the update_kernel script providing a usable kernel.  For 
the most part, you guys have done a great job providing kernels that works 
for us (or have fixed things we've run into real quick).   The lack of 
uio_pruss is the first real issue  that I'm concerned about. 

The dummy snd device is just "useful" cause a boot time, we can detect if 
there isn't a sound device and load the module.  Then the rest of the app 
can assume there is a sound device available and things "just work".   It's 
mostly just a nice to have.

I cannot use the TI kernel as the cpu idle state driver in the TI kernel 
really screws up the GPIO0 timing.The bone kernels don't have the idle 
states so GPIO0 timing is much more consistent.  At some point, I'd like to 
dig through the TI kernel stuff to see if there is a way to completely turn 
off the cpu idle driver, but haven't had the time.   I've used the cpupower 
to turn off the various cpuidle states and that helped 95% of the time, but 
it's still not as predictable as with the bone kernel. 


-- 
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/d1c161ec-9f23-4989-abb4-814a57704564%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] 4.19 bone kernel with uio_pruss?

[Daniel Kulp]

Does this mean it's something that is being worked on to be fixed for an 
upcoming 4.19 kernel update or are UIO folks completely SOL and stuck on 
4.14 kernels?

Dan



On Monday, January 28, 2019 at 2:15:48 PM UTC-5, RobertCNelson wrote:
>
> On Mon, Jan 28, 2019 at 12:58 PM Daniel Kulp > 
> wrote: 
> > 
> > 
> > I tried to update our app image from the 4.14 bone kernel to the 4.19 
> bone kernel and ran into a big problem:  uio_pruss is not configured in as 
> it is with 4.14.  Is this an oversight?  Is there anyone I need to contact 
> to try and convince them to re-enable uio_pruss? I'd like to get 
> CONFIG_SND_DUMMY also enabled (module) as that would allow us to use some 
> same configuration between Pi's and BBB's, but that's really minor.   
> uio_pruss is a must-have. 
> > 
> > The ti kernels also don't have it, but I cannot use the ti kernels due 
> to other timing reasons.  Mostly concerned about the bone kernels right 
> now. 
>
> Actually, uio_pruss broke in v4.18.x... Congrats's your the first to 
> notice and mention it! ;) 
>
> Roger @ TI with comments from David posted an RFC for ti's remotproc 
> for mainline..  That's what i have in v4.19.x-bone "today" (and 
> v4.20.x-bone/v5.0.x-bone).. 
>
> Last i looked at v4.19.x-bone and uio_pruss, you'll need to revert all 
> uio changes in v4.18.x/v4.19.x/etc.. (essentially revert that module 
> to v4.17.x) and it should work fine.. 
>
> 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/6f355027-6fef-4947-9683-94854898debe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] 4.19 bone kernel with uio_pruss?

[Daniel Kulp]

I tried to update our app image from the 4.14 bone kernel to the 4.19 bone 
kernel and ran into a big problem:  uio_pruss is not configured in as it is 
with 4.14.  Is this an oversight?  Is there anyone I need to contact to try 
and convince them to re-enable uio_pruss? I'd like to 
get CONFIG_SND_DUMMY also enabled (module) as that would allow us to use 
some same configuration between Pi's and BBB's, but that's really minor.  
 uio_pruss is a must-have.  

The ti kernels also don't have it, but I cannot use the ti kernels due to 
other timing reasons.  Mostly concerned about the bone kernels right now.

-- 
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/8f36ef2e-8452-45b1-84fb-731e2761c90a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Trouble in getting started with PRU

[Daniel Kulp]

Also note that using GPIO0 pins is slower and more unpredictable that the 
other GPIO's, particularly with the TI kernel.   The power management stuff 
is in the interconnect as GPIO0 so anything that triggers any sort of PM 
activity can cause longer delays for any action with GPIO0.   In 
particular, the CPU idle state driver can add an extra 150ns or more delay 
to writing things to GPIO0.  You can limit that by using "cpupower idle-set 
-d 1" to disable the idle states that take a long time to transition in/out 
of, but it's still not perfect. 

Dan


On Tuesday, November 20, 2018 at 7:27:32 PM UTC-5, Charles Steinkuehler 
wrote:
>
> On 11/20/2018 6:08 PM, Gerhard Hoffmann wrote: 
> > 
> > Am 20.11.18 um 23:15 schrieb Mark A. Yoder: 
> >> 
> >>   Using the PRU interface is faster.  I think my students measured 
> >> it as being a couple times faster.  Using the PRU interface you can 
> >> toggle a pin every 5ns. 
> >> 
> >> 
> > Yes, R30/R31 is about 3 times as fast and more predictable. Going 
> > through the OCP interface 
> > 
> > has to wait sometimes if there is already CPU or DMA activity. 
>
> PRU writes to the direct I/O are 8 times faster than writing to a GPIO 
> pin via the OCP (40 ns for the GPIO vs. 5 ns for direct I/O).  Note 
> that while the write competes on the PRU side within 40 ns, it takes 
> about another 100 nS until the actual GPIO pin value is updated (this 
> is the time needed for the write transaction to flow through the 
> interconnect fabric and actually update the GPIO register). 
>
> Reads, however are much worse, since they are not posted by the 
> interconnect fabric and stall the PRU until the read value is 
> returned.  Reading from a GPIO pin via the OCP port takes apx. 165 ns 
> vs. 5 ns for a direct I/O read. 
>
> I did some tests and measurements of this when I was writing the PRU 
> code for Machinekit, and documented the details in some comments: 
>
>
> https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_pru_generic/pru_generic.p#L137-L165
>  
>
> -- 
> 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/c66e2e2a-1b84-40e5-8189-a6a0270a9c7c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Falcon Christmas Pocket Beagle Wifi Issue

[Daniel Kulp]

> On Oct 31, 2018, at 12:01 AM, devonadai...@gmail.com wrote:
> 
> What wifi adapter were you successfully using? i have tried them all that i 
> have and none of them work. :/ I will hopefully end up getting the one you go 
> to work and try that.

In general, non of the “dual band” wifi adapters will work very well, if at 
all.  There are drivers for a couple of them, but most don’t work at all. 

For the most part, we recommend the Edimax 150MBit adapters.   They seem to 
work the most reliably.   I personally use the EDUP 300Mbit adapters, but I 
cannot find them anymore.  :(For the most part, if you go to Amazon and 
search for “Raspberry Pi Wifi”, what comes up should work.


> I tried the linux driver option and none of them came up with wlan0. I also 
> tried lsusb and none of them showed up as a device.
> 
> Is there a way to install the drivers/ enable them on falcon??

Yea, if you can find drivers.  The script that we use to install drivers on the 
image is at:
https://github.com/FalconChristmas/fpp/blob/master/SD/FPP-Wifi-Drivers.sh 
<https://github.com/FalconChristmas/fpp/blob/master/SD/FPP-Wifi-Drivers.sh>

So you can likely use that as a starting point to see what you need to do.   As 
I said, though, the issue is actually finding drivers for the appropriate 
chipset.  

Dan


> 
> 
> On Tuesday, October 30, 2018 at 9:06:29 AM UTC-4, Daniel Kulp wrote:
> 
> 
>> On Oct 29, 2018, at 10:16 PM, devona...@gmail.com <> wrote:
>> Thanks for sending me those projects! I will take a look over those tomorrow 
>> during class!
>> 
>> The project i am doing is a graduation cap led matrix for a class I am in. 
>> More info here: 
>> https://elinux.org/ECE497_Project_-_LED_Matrix_Graduation_Cap 
>> <https://elinux.org/ECE497_Project_-_LED_Matrix_Graduation_Cap>. The page 
>> isn't complete yet but has a link of what we are trying to do. Feel free to 
>> follow our progress if you want.
>> 
>> The adapter is Realtek RTL8188CUS i think. How do i see what drivers are 
>> installed and how to install them if i need to? 
> 
> rtl8188cus is not one of them.  :( 
> 
> Two options:
> 1) Use a different adapter if you have one available.
> 
> 2) Flip to the kernel adapters and hope it works for your use case.   With 
> FPP 2.0/2.1 images, the setting was on the FPP Setting page.  With 2.2 and 
> 2.3, the setting is on the Network settings page.  
> 
> 
>> I will try the Linux drivers option tomorrow. Where on the network page can 
>> i find the network name/ password? Is that under the tether? 
> 
> No.  Once you get it to recognize the wlan0 device, you would select it from 
> the list box of devices and then the SSID and password fields will appear.   
> Your need to get wlan0 found first though.
> 
> Dan
> 
> 
> 
>> 
>> I was looking for explanation of these options but was unsuccessful in 
>> finding them.
>> 
>> Thanks,
>> 
>> Devon
>> 
>> On Monday, October 29, 2018 at 9:56:57 PM UTC-4, Daniel Kulp wrote:
>> 
>> 
>>> On Oct 29, 2018, at 9:15 PM, devona...@gmail.com <> wrote:
>>> The board is being powered off the micro USB port from my computer at the 
>>> moment. 
>>> 
>>> The voltage from VI is 5 Volts and VB is 0 Volts. ID is about .8 Volts. I 
>>> do have 5 Volts on the USB.
>>> 
>>> I would be interested in seeing those KiCad projects if possible!
>> 
>> 
>> PocketScroller:
>> https://www.dropbox.com/sh/6xks5tl5l4vr8cm/AAD10ftxImjgVQZbDLvcBRhMa?dl=0 
>> <https://www.dropbox.com/sh/6xks5tl5l4vr8cm/AAD10ftxImjgVQZbDLvcBRhMa?dl=0>
>> 
>> F8-PB:
>> https://www.dropbox.com/sh/evuux5o7ogv2j50/AABsyxNA2QenPpanllb5lZ5Ha?dl=0 
>> <https://www.dropbox.com/sh/evuux5o7ogv2j50/AABsyxNA2QenPpanllb5lZ5Ha?dl=0>
>> 
>> 
>> Just recently updated them to KiCad 5 so hopefully they work.   Not sure I 
>> got all the components re-mapped.
>> 
>> Couple more questions:
>> What WIFI adapter?  By default, FPP blacklists the kernel drivers as they, 
>> in general, suck for our use.   I have a bunch of the various Realtek blob 
>> drivers installed, but by no means all of them.   On the network page, you 
>> could try flipping to using the Kernel drivers and see if that helps.   
>> 
>> BTW:  can I ask what you are trying to do?  What kind of thing are you 
>> trying to design?  
>> 
>> Dan
>> 
>> 
>>> 
>>> Falcon doesn't seem to be seeing the adapter.
>>> 
>>> Thanks,
>>> 
>>> Devon
>>> 
>>> On Monday, October 29, 2018 at 2:

Re: [beagleboard] Re: Falcon Christmas Pocket Beagle Wifi Issue

[Daniel Kulp]

> On Oct 29, 2018, at 10:16 PM, devonadai...@gmail.com wrote:
> Thanks for sending me those projects! I will take a look over those tomorrow 
> during class!
> 
> The project i am doing is a graduation cap led matrix for a class I am in. 
> More info here: 
> https://elinux.org/ECE497_Project_-_LED_Matrix_Graduation_Cap. The page isn't 
> complete yet but has a link of what we are trying to do. Feel free to follow 
> our progress if you want.
> 
> The adapter is Realtek RTL8188CUS i think. How do i see what drivers are 
> installed and how to install them if i need to? 

rtl8188cus is not one of them.  :( 

Two options:
1) Use a different adapter if you have one available.

2) Flip to the kernel adapters and hope it works for your use case.   With FPP 
2.0/2.1 images, the setting was on the FPP Setting page.  With 2.2 and 2.3, the 
setting is on the Network settings page.  


> I will try the Linux drivers option tomorrow. Where on the network page can i 
> find the network name/ password? Is that under the tether? 

No.  Once you get it to recognize the wlan0 device, you would select it from 
the list box of devices and then the SSID and password fields will appear.   
Your need to get wlan0 found first though.

Dan



> 
> I was looking for explanation of these options but was unsuccessful in 
> finding them.
> 
> Thanks,
> 
> Devon
> 
> On Monday, October 29, 2018 at 9:56:57 PM UTC-4, Daniel Kulp wrote:
> 
> 
>> On Oct 29, 2018, at 9:15 PM, devona...@gmail.com <> wrote:
>> The board is being powered off the micro USB port from my computer at the 
>> moment. 
>> 
>> The voltage from VI is 5 Volts and VB is 0 Volts. ID is about .8 Volts. I do 
>> have 5 Volts on the USB.
>> 
>> I would be interested in seeing those KiCad projects if possible!
> 
> 
> PocketScroller:
> https://www.dropbox.com/sh/6xks5tl5l4vr8cm/AAD10ftxImjgVQZbDLvcBRhMa?dl=0 
> <https://www.dropbox.com/sh/6xks5tl5l4vr8cm/AAD10ftxImjgVQZbDLvcBRhMa?dl=0>
> 
> F8-PB:
> https://www.dropbox.com/sh/evuux5o7ogv2j50/AABsyxNA2QenPpanllb5lZ5Ha?dl=0 
> <https://www.dropbox.com/sh/evuux5o7ogv2j50/AABsyxNA2QenPpanllb5lZ5Ha?dl=0>
> 
> 
> Just recently updated them to KiCad 5 so hopefully they work.   Not sure I 
> got all the components re-mapped.
> 
> Couple more questions:
> What WIFI adapter?  By default, FPP blacklists the kernel drivers as they, in 
> general, suck for our use.   I have a bunch of the various Realtek blob 
> drivers installed, but by no means all of them.   On the network page, you 
> could try flipping to using the Kernel drivers and see if that helps.   
> 
> BTW:  can I ask what you are trying to do?  What kind of thing are you trying 
> to design?  
> 
> Dan
> 
> 
>> 
>> Falcon doesn't seem to be seeing the adapter.
>> 
>> Thanks,
>> 
>> Devon
>> 
>> On Monday, October 29, 2018 at 2:26:13 PM UTC-4, devona...@gmail.com 
>> <http://gmail.com/> wrote:
>> Hello Everyone!
>> 
>> I am currently working on a project with Falcon Christmas on the Pocket 
>> Beagle. I have a USB WIFI dongle to add WIFI to the pocket beagle.
>> 
>> I was following this guide to add the USB type A to it: 
>> https://www.teachmemicro.com/pocketbeagle-wifi/ 
>> <https://www.teachmemicro.com/pocketbeagle-wifi/>.
>> 
>> I am sure that it is wired properly but it doesn't show up on Falcon as a 
>> device when i do "ifconfig". 
>> The USB however doesn't seem to be on because the LED on the dongle isn't 
>> lighting up even though there is 5 volts to the USB.
>> 
>> I have made sure that the USB pins are not being used by Falcon through the 
>> web interface. 
>> 
>> The last thing i have tried was going through "connmanctl" but I get this 
>> error when i try to enable WIFI.
>> "Error wifi: Method "SetProperty" with signature "sv" on interface 
>> "net.connman.Technology" doesn't exist"
>> 
>> Are there any suggestions as to what to try or where to debug this issue?
>> 
>> Thanks for your help!
>> 
>> 
>> 
>> -- 
>> For more options, visit http://beagleboard.org/discuss 
>> <http://beagleboard.org/discuss>
>> --- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "BeagleBoard" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/beagleboard/U9AFVUM5G4U/unsubscribe 
>> <https://groups.google.com/d/topic/beagleboard/U9AFVUM5G4U/unsubscribe>.
>> To unsubscribe fro

Re: [beagleboard] Re: Falcon Christmas Pocket Beagle Wifi Issue

[Daniel Kulp]

> On Oct 29, 2018, at 9:15 PM, devonadai...@gmail.com wrote:
> The board is being powered off the micro USB port from my computer at the 
> moment. 
> 
> The voltage from VI is 5 Volts and VB is 0 Volts. ID is about .8 Volts. I do 
> have 5 Volts on the USB.
> 
> I would be interested in seeing those KiCad projects if possible!


PocketScroller:
https://www.dropbox.com/sh/6xks5tl5l4vr8cm/AAD10ftxImjgVQZbDLvcBRhMa?dl=0 
<https://www.dropbox.com/sh/6xks5tl5l4vr8cm/AAD10ftxImjgVQZbDLvcBRhMa?dl=0>

F8-PB:
https://www.dropbox.com/sh/evuux5o7ogv2j50/AABsyxNA2QenPpanllb5lZ5Ha?dl=0 
<https://www.dropbox.com/sh/evuux5o7ogv2j50/AABsyxNA2QenPpanllb5lZ5Ha?dl=0>


Just recently updated them to KiCad 5 so hopefully they work.   Not sure I got 
all the components re-mapped.

Couple more questions:
What WIFI adapter?  By default, FPP blacklists the kernel drivers as they, in 
general, suck for our use.   I have a bunch of the various Realtek blob drivers 
installed, but by no means all of them.   On the network page, you could try 
flipping to using the Kernel drivers and see if that helps.   

BTW:  can I ask what you are trying to do?  What kind of thing are you trying 
to design?  

Dan


> 
> Falcon doesn't seem to be seeing the adapter.
> 
> Thanks,
> 
> Devon
> 
> On Monday, October 29, 2018 at 2:26:13 PM UTC-4, devona...@gmail.com wrote:
> Hello Everyone!
> 
> I am currently working on a project with Falcon Christmas on the Pocket 
> Beagle. I have a USB WIFI dongle to add WIFI to the pocket beagle.
> 
> I was following this guide to add the USB type A to it: 
> https://www.teachmemicro.com/pocketbeagle-wifi/ 
> <https://www.teachmemicro.com/pocketbeagle-wifi/>.
> 
> I am sure that it is wired properly but it doesn't show up on Falcon as a 
> device when i do "ifconfig". 
> The USB however doesn't seem to be on because the LED on the dongle isn't 
> lighting up even though there is 5 volts to the USB.
> 
> I have made sure that the USB pins are not being used by Falcon through the 
> web interface. 
> 
> The last thing i have tried was going through "connmanctl" but I get this 
> error when i try to enable WIFI.
> "Error wifi: Method "SetProperty" with signature "sv" on interface 
> "net.connman.Technology" doesn't exist"
> 
> Are there any suggestions as to what to try or where to debug this issue?
> 
> Thanks for your help!
> 
> 
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> <http://beagleboard.org/discuss>
> --- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/beagleboard/U9AFVUM5G4U/unsubscribe 
> <https://groups.google.com/d/topic/beagleboard/U9AFVUM5G4U/unsubscribe>.
> To unsubscribe from this group and all its topics, send an email to 
> beagleboard+unsubscr...@googlegroups.com 
> <mailto:beagleboard+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/96dd2698-fb12-486b-9e52-76cb4abe76d6%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/beagleboard/96dd2698-fb12-486b-9e52-76cb4abe76d6%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
Daniel Kulp
d...@kulp.com <mailto:d...@kulp.com> - http://dankulp.com/blog 
<http://dankulp.com/blog>

-- 
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/4D7CB156-AD22-4E6B-B4CF-A2964BDC62A9%40kulp.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Falcon Christmas Pocket Beagle Wifi Issue

[Daniel Kulp]

I'm surprised you haven't contacted me since I have both PocketScroller 
(P10/5 controller for PocketBeagle) and F8-PB (ws28xx string controller for 
PocketBeagle), both based on Falcon/FPP.I have USB wifi working for 
both of them.   I have the KiCad projects I'd be happy to share if you are 
interested. 

The big question is how are you powering the PB?   The diagrams you see on 
the wiki and such only work if you power the PocketBeagle via the micro-usb 
port.  If you are planning on powering the PB via P1/1, then you need to 
route power separately and handle the switching and such.  

Dan



On Monday, October 29, 2018 at 2:26:13 PM UTC-4, devona...@gmail.com wrote:
>
> Hello Everyone!
>
> I am currently working on a project with Falcon Christmas on the Pocket 
> Beagle. I have a USB WIFI dongle to add WIFI to the pocket beagle.
>
> I was following this guide to add the USB type A to it: 
> https://www.teachmemicro.com/pocketbeagle-wifi/.
>
> I am sure that it is wired properly but it doesn't show up on Falcon as a 
> device when i do "ifconfig". 
> The USB however doesn't seem to be on because the LED on the dongle isn't 
> lighting up even though there is 5 volts to the USB.
>
> I have made sure that the USB pins are not being used by Falcon through 
> the web interface. 
>
> The last thing i have tried was going through "connmanctl" but I get this 
> error when i try to enable WIFI.
> "Error wifi: Method "SetProperty" with signature "sv" on interface 
> "net.connman.Technology" doesn't exist"
>
> Are there any suggestions as to what to try or where to debug this issue?
>
> Thanks 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/9a0239aa-65d2-47a2-96a1-012dc92638f4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Networking/internet issues

[Daniel Kulp]

I have the wifi working on mine using the 4.14.55-bone16 kernel and the 
kernel drivers/firmware.   That said, I think there is an antenna issue or 
something.   I snagged an antenna off my BBGW and plugged into the little 
port and its still very picky about location.   Depending on where I move 
it around, it won't pick up the access point.   

Dan



On Thursday, August 9, 2018 at 6:01:54 PM UTC-4, uk...@pdx.edu wrote:
>
> (I posted this before, but I wasn't a member of the group then, so I 
> deleted that post, joined the group, and am posting this again. Apologies 
> if this is seen as spam.)
>
> Hello,
>
> This post is actually with regards to the SanCloud BeagleBone Enhanced, 
> but there doesn't seem to be a specific forum for that board, so I'm 
> posting to its closest relative, the BeagleBone Black.
>
> I've been having trouble getting Internet to my BeagleBone, which is 
> running the latest image (Debian 9.4 2018-06-17 4GB SD IoT). Please note 
> that the WiFi card installed on this board simply does not work, as far as 
> I know, so that's not an option. I can get Internet if I simply attach it 
> via Ethernet directly to my router, but that is not ideal since I move 
> locations a fair amount. Ideally, I need to share my laptop's WiFi 
> connection to the BeagleBone, either over USB or Ethernet. (My laptop runs 
> Ubuntu 18.04)
>
> One major roadblock is that the web server (not sure if that's the 
> appropriate term) doesn't seem to boot up correctly when the board is 
> powered on and connected to my laptop. I get a notification on my laptop 
> that says "Network activation failed" or something to that effect, which is 
> usually accompanied by my desktop (GNOME) crashing and restarting. 
> Afterwards, the classic 192.168.7.2 doesn't work. Can't SSH in, and 
> visiting 192.168.7.2 on my laptop's browser returns a timeout. The only way 
> I can actually get into the BeagleBone is by using screen and going into 
> /dev/ttyACM0. And ifconfig on my laptop shows that the BeagleBone has some 
> incredibly long and weird registered name, not the eth[#] that it usually 
> is.
>
> That's the first problem. The second problem is that I'm not sure how to 
> share my laptop's Internet connection, since I'm pretty new to Linux. I've 
> tried following this 
> 
>  
> guide, but that doesn't work, and various futzing around with sharing over 
> Ethernet in nm-connection-editor doesn't work either. I'm assuming that the 
> fundamental problem here is the first thing I described -- the failure of 
> the BeagleBone's web server -- which in turn is causing these auxiliary 
> failures with my Internet sharing.
>
> Anyone have similar issues or have any suggestions? Thanks in advance for 
> any responses!
>

-- 
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/8f9622d5-791f-4ae9-9a6f-3a261b601e7b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] USB performance vs governor

[Daniel Kulp]

This was with the latest debian stretch image from beaglebone.org with an 
updated kernel.  It seems to be using ondemand by default.   

I need wifi support as well. :(

Dan


On Monday, August 6, 2018 at 8:08:26 PM UTC-4, RobertCNelson wrote:
>
> On Mon, Aug 6, 2018 at 6:42 PM Daniel Kulp > 
> wrote: 
> > 
> > 
> > I'm been trying to track down why the USB performance on my BBB's has 
> been abysmal.  I've discovered that the default on-demand governor is 
> definitely a major contributor to the slowdown. 
> > 
> > Basically, with the ondemand governor, I'm seeing read performance off 
> of a USB3 thumb drive of well under 2MB/sec.   In other words, really slow. 
>   For example: 
> > 
> > root@FPP:/home/fpp# uname -a 
> > Linux FPP 4.14.60-ti-r67 #1 SMP PREEMPT Sat Aug 4 19:54:06 UTC 2018 
> armv7l GNU/Linux 
> > root@FPP:/home/fpp# cpufreq-set -g ondemand 
> > root@FPP:/home/fpp# dd if=/dev/sda1 of=/dev/null bs=1048576 count=32 
> > 32+0 records in 
> > 32+0 records out 
> > 33554432 bytes (34 MB, 32 MiB) copied, 24.9291 s, 1.3 MB/s 
> > root@FPP:/home/fpp# dd if=/dev/sda1 of=/dev/null bs=1048576 count=32 
> > 32+0 records in 
> > 32+0 records out 
> > 33554432 bytes (34 MB, 32 MiB) copied, 22.283 s, 1.5 MB/s 
> > 
> >   (yes.. "dd" isn't a great benchmark, but it's trivial to show the 
> issue).  Once I switch to the performance governor, things improve quite a 
> bit: 
> > 
> > root@FPP:/home/fpp# cpufreq-set -g performance 
> > root@FPP:/home/fpp# dd if=/dev/sda1 of=/dev/null bs=1048576 count=64 
> > 64+0 records in 
> > 64+0 records out 
> > 67108864 bytes (67 MB, 64 MiB) copied, 6.96759 s, 9.6 MB/s 
> > root@FPP:/home/fpp# dd if=/dev/sda1 of=/dev/null bs=1048576 count=64 
> > 64+0 records in 
> > 64+0 records out 
> > 67108864 bytes (67 MB, 64 MiB) copied, 6.98015 s, 9.6 MB/s 
> > 
> > 
> > It's still not anywhere near what a Raspberry Pi is able to do with the 
> same thumb drive (30MB/s), but it's a huge improvement. 
> > 
> > Is there any setting or anything that can be used to improve the read 
> performance of the USB besides locking the CPU at 1Ghz? 
>
> PERFORMANCE should be the default governor, for a long time it was 
> on-demand.. 
>
> If you know what USB devices you'll be plugging in, switch the MUSB 
> DMA mode from the cpu to cppi4.1 via: 
>
> diff --git a/patches/defconfig b/patches/defconfig 
> index 661d1a5..31a8caf 100644 
> --- a/patches/defconfig 
> +++ b/patches/defconfig 
> @@ -4601,7 +4601,8 @@ CONFIG_USB_MUSB_AM335X_CHILD=y 
>  # 
>  # MUSB DMA mode 
>  # 
> -CONFIG_MUSB_PIO_ONLY=y 
> +# CONFIG_MUSB_PIO_ONLY is not set 
> +CONFIG_USB_TI_CPPI41_DMA=y 
>  CONFIG_USB_DWC3=y 
>  # CONFIG_USB_DWC3_HOST is not set 
>  # CONFIG_USB_DWC3_GADGET is not set 
>
> You "will" lose compatibly with some usb devices. (most the wifi 
> ones..).. But for mass storage it should be fine.. 
>
> 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/0564ce20-0711-40e3-bf8b-f0c472565fdb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] USB performance vs governor

[Daniel Kulp]

I'm been trying to track down why the USB performance on my BBB's has been 
abysmal.  I've discovered that the default on-demand governor is definitely 
a major contributor to the slowdown.   

Basically, with the ondemand governor, I'm seeing read performance off of a 
USB3 thumb drive of well under 2MB/sec.   In other words, really slow.  
 For example:

root@FPP:/home/fpp# uname -a
Linux FPP 4.14.60-ti-r67 #1 SMP PREEMPT Sat Aug 4 19:54:06 UTC 2018 armv7l 
GNU/Linux
root@FPP:/home/fpp# cpufreq-set -g ondemand
root@FPP:/home/fpp# dd if=/dev/sda1 of=/dev/null bs=1048576 count=32
32+0 records in
32+0 records out
33554432 bytes (34 MB, 32 MiB) copied, 24.9291 s, 1.3 MB/s
root@FPP:/home/fpp# dd if=/dev/sda1 of=/dev/null bs=1048576 count=32
32+0 records in
32+0 records out
33554432 bytes (34 MB, 32 MiB) copied, 22.283 s, 1.5 MB/s

  (yes.. "dd" isn't a great benchmark, but it's trivial to show the 
issue).  Once I switch to the performance governor, things improve quite a 
bit:

root@FPP:/home/fpp# cpufreq-set -g performance
root@FPP:/home/fpp# dd if=/dev/sda1 of=/dev/null bs=1048576 count=64
64+0 records in
64+0 records out
67108864 bytes (67 MB, 64 MiB) copied, 6.96759 s, 9.6 MB/s
root@FPP:/home/fpp# dd if=/dev/sda1 of=/dev/null bs=1048576 count=64
64+0 records in
64+0 records out
67108864 bytes (67 MB, 64 MiB) copied, 6.98015 s, 9.6 MB/s


It's still not anywhere near what a Raspberry Pi is able to do with the 
same thumb drive (30MB/s), but it's a huge improvement.   

Is there any setting or anything that can be used to improve the read 
performance of the USB besides locking the CPU at 1Ghz?

-- 
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/70a6d8da-052f-444f-8ef5-7ccb3121a4c5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: PocketBeagle IoT

[Daniel Escasa]

OK, here's general info on how to interface the ESP8266 with another 
device: 
http://rancidbacon.com/files/kiwicon8/ESP8266_WiFi_Module_Quick_Start_Guide_v_1.0.4.pdf
 
-- scroll down to page 3. Caveat: he says that powering the ESP8266 from, 
e.g., a Beagle, is a bad idea. What I would do is supply power to the 
former using a YuRobot or similar power supply, an 18650 battery shield, or 
even a power bank through USB if the ESP8266 you choose supports 
power-through-USB

-- 
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/ffc082fa-c656-45ca-879a-6c70c215f102%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Differences between kernels?

[Daniel Kulp]

On Monday, March 12, 2018 at 12:04:23 PM UTC-4, RobertCNelson wrote:
>
>
> Bone = am335x targets, no smp
>
> Ti = utilizes TI sdk kernel.. aka ti engineers get paid to support that 
> kernel.. patches end up mainline..
>

If I'm ONLY targeting the BeagleBone Blacks and PocketBeagles where we know 
we don't need SMP, is there a reason to go -ti vs. -bone?

The -bone images seems to boot slightly faster.

 

> I've been using the --ti --lts-4_14, but recent versions are completely 
> broken for advanced WIFI use cases so I'm kind of trying to figure out what 
> options I have to replace it.Sometime between 4.14.13-ti-r25 and the 
> current 4.14 version, someone made the boneheaded (pun intended, no offense 
> intended) to include the USB wifi adapters as builtins instead of modules.  
>  This completely breaks any usage of external wifi modules that work 
> "better" (or in some cases, actually work).  We cannot blacklist the 
> builtin modules (even tried the command line params, didn't work).   And 
> even without blacklist, they don't work as the firmwares needed by the wifi 
> adapters are not included in the initial rd.  I'm not sure why they are now 
> built in instead of modules, but it's certainly a huge step backwards IMO.
>
>
> That's me, was trying to speed up boot times, we can revert it back to 
> modules.
>

That would be great if we could.They really aren't working as modules.  
  With the -bone kernel, I can easily get the Wifi built onto the SanCloud 
BeagleBone Enhanced to work.   I haven't managed to get it to work at all 
with the  latest -ti  4.14 kernels.  wlan0 doesn't even appear due to the 
lack of firmware.

I'm also getting a strange stack trace in dmsg with 4.14.25-ti-r38.  It 
seems to be ignorable, but it's concerning to see:
[   71.453332] WARNING: CPU: 0 PID: 1119 at fs/sysfs/dir.c:31 
sysfs_warn_dup+0x78/0x88
[   71.453338] sysfs: cannot create duplicate filename 
'/bus/platform/devices/4a30.pruss'
[   71.453343] Modules linked in: pruss_soc_bus(+) uio_pruss(+) btusb btrtl 
btbcm btintel bluetooth ecdh_generic 8021q garp mrp stp llc evdev 
uio_pdrv_genirq uio usb_f_acm u_serial usb_f_ecm usb_f_rndis u_ether 
libcomposite iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 
nf_nat nf_conntrack iptable_mangle iptable_filter ip_tables x_tables
[   71.453467] CPU: 0 PID: 1119 Comm: systemd-udevd Not tainted 
4.14.25-ti-r38 #1
[   71.453472] Hardware name: Generic AM33XX (Flattened Device Tree)
[   71.453516] [] (unwind_backtrace) from [] 
(show_stack+0x20/0x24)
[   71.453537] [] (show_stack) from [] 
(dump_stack+0x8c/0xa0)
[   71.453553] [] (dump_stack) from [] 
(__warn+0xf8/0x110)
[   71.453564] [] (__warn) from [] 
(warn_slowpath_fmt+0x58/0x74)
[   71.453576] [] (warn_slowpath_fmt) from [] 
(sysfs_warn_dup+0x78/0x88)
[   71.453590] [] (sysfs_warn_dup) from [] 
(sysfs_do_create_link_sd+0xc4/0xd4)
[   71.453601] [] (sysfs_do_create_link_sd) from [] 
(sysfs_create_link+0x38/0x44)
[   71.453614] [] (sysfs_create_link) from [] 
(bus_add_device+0x78/0x134)
[   71.453637] [] (bus_add_device) from [] 
(device_add+0x298/0x5d0)
[   71.453654] [] (device_add) from [] 
(of_device_add+0x44/0x4c)
[   71.453667] [] (of_device_add) from [] 
(of_platform_device_create_pdata+0x84/0xb4)
[   71.453678] [] (of_platform_device_create_pdata) from 
[] (of_platform_bus_create+0x178/0x310)
[   71.453689] [] (of_platform_bus_create) from [] 
(of_platform_populate+0x84/0x120)
[   71.453721] [] (of_platform_populate) from [] 
(pruss_soc_bus_probe+0x13c/0x26c [pruss_soc_bus])
[   71.453766] [] (pruss_soc_bus_probe [pruss_soc_bus]) from 
[] (platform_drv_probe+0x60/0xc0)
[   71.453777] [] (platform_drv_probe) from [] 
(driver_probe_device+0x2a8/0x460)
[   71.453787] [] (driver_probe_device) from [] 
(__driver_attach+0x100/0x10c)
[   71.453799] [] (__driver_attach) from [] 
(bus_for_each_dev+0x8c/0xd0)
[   71.453810] [] (bus_for_each_dev) from [] 
(driver_attach+0x2c/0x30)
[   71.453819] [] (driver_attach) from [] 
(bus_add_driver+0x16c/0x26c)
[   71.453828] [] (bus_add_driver) from [] 
(driver_register+0x88/0x104)
[   71.453838] [] (driver_register) from [] 
(__platform_driver_register+0x50/0x58)
[   71.453854] [] (__platform_driver_register) from [] 
(pruss_soc_bus_driver_init+0x20/0x1000 [pruss_soc_bus])
[   71.453873] [] (pruss_soc_bus_driver_init [pruss_soc_bus]) 
from [] (do_one_initcall+0x64/0x19c)
[   71.453894] [] (do_one_initcall) from [] 
(do_init_module+0x74/0x20c)
[   71.453907] [] (do_init_module) from [] 
(load_module+0x21c4/0x2890)
[   71.453919] [] (load_module) from [] 
(SyS_init_module+0x1b8/0x1d4)
[   71.453936] [] (SyS_init_module) from [] 
(__sys_trace_return+0x0/0x10)






I can stay on 4.14.13-ti-r25 which works fine, but I'm not sure what fixes 
> and such I'd be missing out on going forward.The --bone  kernels don't 
> seem to have btrfs which, while not critical, is something we've been 
> looking closer at for the COW and compression.   The armv7 kernel s

[beagleboard] Differences between kernels?

[Daniel Kulp]

Is there a document or something that describes the differences between the 
--bone, --armv7, and --ti kernels?   Why to choose one over the other?  
etc

I've been using the --ti --lts-4_14, but recent versions are completely 
broken for advanced WIFI use cases so I'm kind of trying to figure out what 
options I have to replace it.Sometime between 4.14.13-ti-r25 and the 
current 4.14 version, someone made the boneheaded (pun intended, no offense 
intended) to include the USB wifi adapters as builtins instead of modules.  
 This completely breaks any usage of external wifi modules that work 
"better" (or in some cases, actually work).  We cannot blacklist the 
builtin modules (even tried the command line params, didn't work).   And 
even without blacklist, they don't work as the firmwares needed by the wifi 
adapters are not included in the initial rd.  I'm not sure why they are now 
built in instead of modules, but it's certainly a huge step backwards IMO.

I can stay on 4.14.13-ti-r25 which works fine, but I'm not sure what fixes 
and such I'd be missing out on going forward.The --bone  kernels don't 
seem to have btrfs which, while not critical, is something we've been 
looking closer at for the COW and compression.   The armv7 kernel seems to 
work for both btrfs and wifi, but I really don't know what else I'm missing 
out on with that version.


-- 
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/31fc75f9-8fb4-474d-95f9-e0cce232eee2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] WIFI problems with 4.14.20-ti-r36

[Daniel Kulp]

I'm updating my images to new kernels and such and have run into a problem 
on the SanCloud BeagleBone Enhanced.

Basically, in the recent kernel images, several of the wifi and other 
modules are built into the kernel and thus loaded and initialized at boot.  
However, the firmware that they require are not added to the initialrd.  
 Thus, wlan0 is never created.

I've worked around that issue by adding the firmware to the initrd.   That 
creates the wlan0 device.  But I cannot get wlan0 to connect to anything.  
I can list all the services in connmanctl, but any attempt to connect 
fails.  Everything times out.  "authentication with 78:8a:20:24:54:83 timed 
out"

Can I ask why the modules were built into the kernel?   With them in the 
kernel I cannot even use the normal modprobe.d stuff to blacklist them and 
use the realtek drivers.


-- 
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/89ee05c7-47cd-4d82-ae93-7cc487ac9dd7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Trouble using DLPDLCR2000EVM in BBBlack with Debian Jessie 9.3

[Daniel Grabert]

Thanks! I didnt find MLO file, but I zeroed the beginning of eMMC with dd 
if=/dev/zero of=/dev/mmcblk1 bs=1M count=100, and now it boot from sd card!

Em segunda-feira, 5 de fevereiro de 2018 18:24:31 UTC-3, RobertCNelson 
escreveu:
>
> On Mon, Feb 5, 2018 at 3:11 PM, Daniel Grabert  > wrote: 
> >  I have already both 5c jacks plugged in, the splash screen is ok. 
> > 
> > 
> > Output for command 
> > 
> > 
> > root@beaglebone:/opt/scripts/device/bone/capes/DLPDLCR2000# sudo 
> > /opt/scripts/tools/version.sh 
> > git:/opt/scripts/:[ea6ea9fca05f36f5044398884375b0231348d6e2] 
> > eeprom:[A335BNLT0A5C3313BBBK1427] 
> > model:[TI_AM335x_BeagleBone_Black] 
> > dogtag:[BeagleBoard.org Debian Image 2018-01-28] 
> > bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
> > 2018.01-2-g9aa111a004] 
> > bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
> 2015.10-1-g143c9ee] 
>
> ^ this old bootloader is getting in the way, so U-Boot Overlays is not 
> working.. (This cape requires U-Boot Overlays) 
>
> i think 2015.10 was the era we used a fat partition in the eMMC.. So 
> mount it and remove the "MLO" file.. 
>
> 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/27faf641-e0d7-4610-add6-d90f88f57739%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Trouble using DLPDLCR2000EVM in BBBlack with Debian Jessie 9.3

[Daniel Grabert]

 I have already both 5c jacks plugged in, the splash screen is ok.
 

Output for command


root@beaglebone:/opt/scripts/device/bone/capes/DLPDLCR2000# sudo 
/opt/scripts/tools/version.sh
git:/opt/scripts/:[ea6ea9fca05f36f5044398884375b0231348d6e2]
eeprom:[A335BNLT0A5C3313BBBK1427]
model:[TI_AM335x_BeagleBone_Black]
dogtag:[BeagleBoard.org Debian Image 2018-01-28]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
2018.01-2-g9aa111a004]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 2015.10-1-g143c9ee]
kernel:[4.9.78-ti-r94]
nodejs:[v6.12.3]
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[enable_uboot_cape_universal=1]
pkg:[bb-cape-overlays]:[4.4.20180126.0-0rcnee0~stretch+20180126]
pkg:[bb-wl18xx-firmware]:[1.20170829-0rcnee2~stretch+20180104]
pkg:[firmware-ti-connectivity]:[20170823-1rcnee0~stretch+20170830]
groups:[debian : debian adm kmem dialout cdrom floppy audio dip video 
plugdev users systemd-journal i2c bluetooth netdev cloud9ide gpio pwm eqep 
admin spi tisdk weston-launch xenomai]
dmesg | grep pinctrl-single
[1.392696] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 
568
[2.049822] pinctrl-single 44e10800.pinmux: pin PIN40 already requested 
by 0-0070; cannot claim for panel
[2.071354] pinctrl-single 44e10800.pinmux: pin-40 (panel) status -22
[2.079225] pinctrl-single 44e10800.pinmux: could not request pin 40 
(PIN40) from group pinmux_bb_lcd_lcd_pins  on device pinctrl-single
END

   It's strange because other scripts change the DLP screen (like 
Splash.py) normally, when i run Mplayer.py i get:

root@beaglebone:/opt/scripts/device/bone/capes/DLPDLCR2000# DISPLAY=:0; 
export DISPLAY=:0 ; python MplayerTest.py
set slave address: 27
Make sure the display port is set. For example export DISPLAY=:0 

1
SourceSel.EXTERNAL_VIDEO_PARALLEL_I_F_
2
Resolution.NHD_LANDSCAPE
##
play video
nhd_test.mp4
MPlayer 1.3.0 (Debian), built with gcc-6.2.1 (C) 2000-2016 MPlayer Team
do_connect: could not connect to socket
connect: No such file or directory
Failed to open LIRC support. You will not be able to use your remote 
control.

Playing nhd_test.mp4.
libavformat version 57.56.101 (external)
Mismatching header version 57.56.100
libavformat file format detected.
[mov,mp4,m4a,3gp,3g2,mj2 @ 0xb69183a8]Protocol name not provided, cannot 
determine if input is local or a network protocol, buffers and access 
patterns cannot be configured optimally without knowing the protocol
[lavf] stream 0: video (h264), -vid 0
VIDEO:  [H264]  640x360  24bpp  30.000 fps  3600.5 kbps (439.5 kbyte/s)
No protocol specified
vo: couldn't open the X11 display (:0)!
No protocol specified
vo: couldn't open the X11 display (:0)!
No protocol specified
vo: couldn't open the X11 display (:0)!
No protocol specified
No protocol specified
No protocol specified
No protocol specified
No protocol specified
vo: couldn't open the X11 display (:0)!
VO XOverlay need a subdriver
No protocol specified
(and goes on...)


Em segunda-feira, 5 de fevereiro de 2018 17:28:58 UTC-3, RobertCNelson 
escreveu:
>
> On Mon, Feb 5, 2018 at 2:23 PM, Daniel Grabert  > wrote: 
> >  Hi everybody! 
> >  I  bought a DLP2000EVM from Ti, and installed with Debian Jessie 8.9 
> > without problems, but when I put version 9.3 i cannot get to work. 
> > 
> >  Here are some outputs: 
> > 
> > root@beaglebone:/opt/scripts/device/bone/capes/DLPDLCR2000# 
> > /opt/scripts/device/bone/capes/cape_eeprom_check.sh 
> > checking: /sys/bus/i2c/devices/2-0054/eeprom 
> > hexdump: /sys/bus/i2c/devices/2-0054/eeprom: Connection timed out 
> > cape: [] 
> > checking: /sys/bus/i2c/devices/2-0055/eeprom 
> > hexdump: /sys/bus/i2c/devices/2-0055/eeprom: Connection timed out 
> > cape: [] 
> > checking: /sys/bus/i2c/devices/2-0056/eeprom 
> > hexdump: /sys/bus/i2c/devices/2-0056/eeprom: Connection timed out 
> > cape: [] 
> > checking: /sys/bus/i2c/devices/2-0057/eeprom 
> > cape: [  aa 55 33 ee 41 31 44 4c  50 44 4c 43 52 32 30 30 
> > |.U3.A1DLPDLCR200| 
> > 0010  30 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 
> > |0...| 
> > 0020] 
> > root@beaglebone:/opt/scripts/device/bone/capes/DLPDLCR2000#  i2cdetect 
> -r -y 
> > 2 
> >  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f 
> > 00:  -- -- -- -- -- -- -- -- -- -- -- -- -- 
> > 10: -- -- -- -- -- -- -- -- -- -- -- 1b -- -- -- -- 
> > 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
> > 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
> > 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
> > 50: -- -- -- -- UU UU UU UU -- -- -- -- -- -- -- -- 
> > 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
> > 70: -- -- -

[beagleboard] Trouble using DLPDLCR2000EVM in BBBlack with Debian Jessie 9.3

[Daniel Grabert]

 Hi everybody!
 I  bought a DLP2000EVM from Ti, and installed with Debian Jessie 8.9 
without problems, but when I put version 9.3 i cannot get to work.
 
 Here are some outputs:

root@beaglebone:/opt/scripts/device/bone/capes/DLPDLCR2000# 
/opt/scripts/device/bone/capes/cape_eeprom_check.sh
checking: /sys/bus/i2c/devices/2-0054/eeprom
hexdump: /sys/bus/i2c/devices/2-0054/eeprom: Connection timed out
cape: []
checking: /sys/bus/i2c/devices/2-0055/eeprom
hexdump: /sys/bus/i2c/devices/2-0055/eeprom: Connection timed out
cape: []
checking: /sys/bus/i2c/devices/2-0056/eeprom
hexdump: /sys/bus/i2c/devices/2-0056/eeprom: Connection timed out
cape: []
checking: /sys/bus/i2c/devices/2-0057/eeprom
cape: [  aa 55 33 ee 41 31 44 4c  50 44 4c 43 52 32 30 30 
 |.U3.A1DLPDLCR200|
0010  30 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 
 |0...|
0020]
root@beaglebone:/opt/scripts/device/bone/capes/DLPDLCR2000#  i2cdetect -r 
-y 2
 0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:  -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- 1b -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- UU UU UU UU -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- -- 
root@beaglebone:/opt/scripts/device/bone/capes/DLPDLCR2000# 

 I saw in Quick Start guide for DLP2000EVM that the version 8.9 was the 
only version stable with DLP, this information still true or outdated?
 If someone have a clue i really appreciate.



-- 
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/6e304e57-9e98-49d5-b799-bcc020aa444f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] btrfs filesystem instead of ext4

[Daniel Kulp]

There are definitely still problems with btrfs compression and uboot.   If 
I take this image, update /etc/fstab to add compress=zlib, reboot to 
remount, and then run "btrfs fi defrag -c -r /" to compress the full 
filesystem, then it refuses to boot.   All I see on the console is 
"starting the kernel" and then nothing.  All the usr lights come on 
full and it sits there.

I'm still experimenting a bit.   I think an attribute can be added to the 
/boot directory to have it not compress stuff in /boot.   I want to see if 
that helps at all. 

Dan


On Wednesday, January 31, 2018 at 9:21:02 PM UTC-5, RobertCNelson wrote:
>
> On Wed, Jan 31, 2018 at 8:18 PM, Robert Nelson  > wrote: 
> > On Wed, Jan 31, 2018 at 8:09 PM, Stuart Longland 
> > > wrote: 
> >> On 01/02/18 10:07, Mone wrote: 
> >>> I tried with a new snapshot and it works very well. Alongside that, I 
> am 
> >>> curious and would like to learn about the BBB conversion from ext4 to 
> >>> flash filesystem. Are there any documentation/manual online that could 
> >>> explain/hint/guide through the filesystem  conversion from ext4 to 
> flash 
> >>> filesystem like btrfs? 
> >> 
> >> It's worth pointing out that btrfs is not a flash filesystem, it needs 
> a 
> >> FTL (Flash Transition Layer) to do wear levelling on a NAND flash the 
> >> same as EXT4 does. 
> >> 
> >> Your biggest hurdle is the fact that U-Boot does not understand btrfs, 
> >> so you'll need a /boot partition formatted EXT4.  Not sure that this is 
> >> likely to change, as porting btrfs to U-Boot could be a major 
> >> undertaking as it's much more complex. 
> > 
> > Actually U-Boot has btrfs support as of v2018.01 (even ZLIB 
> > compression! lzo is broken). 
> > 
> > We got a patch merged in v2018.03-rc1 that fixes (lzo compression..) 
>
> if you want to give it a go, use this base image: 
>
>
> https://rcn-ee.net/rootfs/bb.org/testing/2018-01-28/buster-iot/bone-debian-buster-iot-armhf-2018-01-28-4gb.img.xz
>  
>
> it's one partition btrfs. 
>
> 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/0e2d1750-05fc-47c0-9e48-7f021c5a5bb2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: PocketBeagle IoT

[Daniel Escasa]

Sabi ni Adam noong Monday, November 6, 2017 at 10:01:08 AM UTC+8:
>
> Hey all, 
>
> First up – I'm a Beagle newbie. More than that, I have some serious black 
> spots when it comes to tech, coding, etc. But I enjoy the pain of learning, 
> so here I am... 
>
> Basically my question is in regards to a project I'm scoping out involving 
> a PocketBeagle. Essentially, I was to use a Pocket as a wearable device, 
> running a display that will periodically display information from a server. 
> For that, I'll need some kind of IoT connectivity – WiFi or Bluetooth. 
>
> From my initial digging, there's no immediate solution specific to the 
> Pocket. It's very important that the module or board is small enough to 
> embed in a wearable device (in this instance, a baseball cap). 
>
> Any ideas?
>
> Thanks in advance, 
> Adam
> adamandothers.com
>
>
One way to do it would be with a USB breakout board, available from Adafruit 
, or possibly the HUZZAH 
ESP8266 Breakout  which also shows 
up in that link. Not having done enough reading, I can't be sure how to 
interface the HUZZA and the like with the Pocket, let alone if they would 
work. The USB breakout boards, OTOH, in conjunction with a WiFi dongle, 
probably will, and in fact show up in a Google search. That does involve a 
dongle though, which would look kinda odd sticking out of a baseball cap :).

Adafruit has a couple of breakout boards that incorporate not only WiFi but 
Bluetooth as well. Look into BT for connectivity, as WiFi may be an 
overkill, depending of course on what you want to do. Also look into GSM 
breakout boards for cellular connectivity. Prices are low enough to tempt 
me into switching on experimental mode

-- 
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/03a81ab4-153b-4d99-abeb-e4f6cd9c3ab3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Compressed btrfs root on eMMC

[Daniel Kulp]

That's awesome.Will definitely help breath some new life into the 
little 4GB eMMC.   :)

Thanks for looking into this.

Dan



On Friday, December 15, 2017 at 12:08:01 PM UTC-5, RobertCNelson wrote:
>
> On Wed, Dec 13, 2017 at 2:19 PM, Robert Nelson  > wrote: 
> > On Wed, Dec 13, 2017 at 2:11 PM, Robert Nelson  > wrote: 
> >> Got it! 
> >> 
> >> u-boot just needs: 
> >> 
> >> CONFIG_FS_BTRFS=y 
> >> 
> >> and we need to pass: 
> >> 
> >> mmcrootfstype=btrfs rootwait 
> >> 
> >> thru /boot/uEnv.txt 
> >> 
> >> and it just works: 
> >> 
> >> https://gist.github.com/RobertCNelson/d2ba5d74c8bc7407ce7bd8a521424b20 
> >> 
> >> I'll add that config to u-boot by default... 
> > 
> > Uhoh.. 
> > 
> > Running uname_boot ... 
> > Failed to mount ext2 filesystem... 
> > loading /boot/vmlinuz-4.14.5-bone8 ... 
> > Failed to mount ext2 filesystem... 
> > data abort 
> > pc : [<9ff6fa90>]lr : [<>] 
> > reloc pc : [<80825a90>]lr : [] 
> > sp : 9df29148  ip : 8202 fp : 0001f000 
> > r10: 00cf  r9 : 9df29ed8 r8 : 82001000 
> > r7 : 0001d62f  r6 : 1000 r5 : 0001df29  r4 : 9df542b7 
> > r3 : 1000  r2 : 8200 r1 : 1000  r0 :  
> > Flags: nzCv  IRQs off  FIQs on  Mode SVC_32 
> > Resetting CPU ... 
> > 
> > resetting ... 
> > 
> > Don't compress files under /boot/* 
>
> So btrfs in u-boot should handle both zlib and lzo 
>
> So while lzo has a bug at the moment, zlib works! 
>
> btrfs filesystem defragment -r -v -czlib / 
>
> root@beaglebone:~# df -h | grep mmc 
> /dev/mmcblk0p1   15G  956M   13G   8% / 
>
> (originally 1.7G) 
>
> I'm going to submit a bug to u-boot for lzo.. 
>
> 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/a1e12345-3a23-4fcc-95f8-c549859502df%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Compressed btrfs root on eMMC

[Daniel Kulp]

On Monday, December 11, 2017 at 4:18:31 PM UTC-5, RobertCNelson wrote:
>
>
> btrfs got added in u-boot v2017.11... ;) 
>
>
> https://github.com/u-boot/u-boot/commit/0c936ee3194ac5b533a18fcd08e5d285853af5fe#diff-09d710108823b360adf225b17cef57f9
>  
>
>
Doesn't seem to work

U-Boot 2018.01-rc1-2-g87ef84e094 (Dec 06 2017 - 14:58:04 -0600), Build: 
jenkins-github_Bootloader-Builder-16

CPU  : AM335X-GP rev 2.1
I2C:   ready
DRAM:  512 MiB
No match for driver 'omap_hsmmc'
No match for driver 'omap_hsmmc'
Some drivers were not found
Reset Source: Power-on reset has occurred.
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
Using default environment

Board: BeagleBone Black
 not set. Validating first E-fuse MAC
BeagleBone Black:
Model: Element14 BeagleBone Black Industrial:
BeagleBone: cape eeprom: i2c_probe: 0x54:
BeagleBone: cape eeprom: i2c_probe: 0x55:
BeagleBone: cape eeprom: i2c_probe: 0x56:
BeagleBone: cape eeprom: i2c_probe: 0x57:
Net:   eth0: MII MODE
cpsw, usb_ether
Press SPACE to abort autoboot in 2 seconds
board_name=[A335BNLT] ...
board_rev=[EIA0] ...
Card did not respond to voltage select!
mmc_init: -95, time 13
Card did not respond to voltage select!
mmc_init: -95, time 12
Card did not respond to voltage select!
mmc_init: -95, time 13
gpio: pin 56 (gpio 56) value is 0
gpio: pin 55 (gpio 55) value is 0
gpio: pin 54 (gpio 54) value is 0
gpio: pin 53 (gpio 53) value is 1
Card did not respond to voltage select!
mmc_init: -95, time 13
Card did not respond to voltage select!
mmc_init: -95, time 13
switch to partitions #0, OK
mmc1(part 0) is current device
Failed to mount ext2 filesystem...
** Unrecognized filesystem type **
gpio: pin 56 (gpio 56) value is 0
gpio: pin 55 (gpio 55) value is 0
gpio: pin 54 (gpio 54) value is 0
gpio: pin 53 (gpio 53) value is 1
switch to partitions #0, OK
mmc1(part 0) is current device
gpio: pin 54 (gpio 54) value is 1
Failed to mount ext2 filesystem...
** Unrecognized filesystem type **
Checking for: /uEnv.txt ...
Failed to mount ext2 filesystem...
** Unrecognized filesystem type **
Checking for: /boot.scr ...
Failed to mount ext2 filesystem...
** Unrecognized filesystem type **
Checking for: /boot/boot.scr ...
Failed to mount ext2 filesystem...
** Unrecognized filesystem type **
Checking for: /boot/uEnv.txt ...
Failed to mount ext2 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/e79d301b-6e16-477e-8428-e3c61e385485%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Compressed btrfs root on eMMC

[Daniel Kulp]

On Monday, December 11, 2017 at 4:18:31 PM UTC-5, RobertCNelson wrote:
>
>
> btrfs got added in u-boot v2017.11... ;) 
>
>
> https://github.com/u-boot/u-boot/commit/0c936ee3194ac5b533a18fcd08e5d285853af5fe#diff-09d710108823b360adf225b17cef57f9
>  
> 
>  
>

Hmm... I couldn't get it to work.   I could never get it to actually find 
any of the files on the btrfs root.I'll try again.It would 
certainly simplify things.
 

> > 
> > For my app, this leaves well over 2GB of free space on the eMMC as 
> compared 
> > to about 500MB before.   Performance is about the same. Anyway, I 
> > thought I'd share it with others in case they want to try it out, play 
> with 
> > it, suggest enhancements, etc 
>
> Careful around v4.14.x+ "I" dropped btrfs, it saves a good second or 
> two on bootup, from all the raid6 calculations that are done. (if we 
> could force it to always use one mode, and thus not waste bootup time, 
> i'll gladly reenable it) 
>

Ick... That would be REALLY bad for me.   I've switch over to btrfs on 
pretty much all my beaglebones, even on the SD cards.  The files I have 
are large (>500MB) but highly compressible so it's much faster to read them 
from btrfs than ext4.That said, I'm still on 4.4 as we use uio-pruss 
for working with the PRU's and have not plans/desire to change that (and 
last I looked, there were issues with it on 4.9+, maybe those issues are 
now fixed).

For me, an extra second or two on a bootup that takes almost 75 seconds is 
irrelevant when the beaglebone is up for weeks/months on end.  

-- 
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/a46794b3-a9fa-48e8-a114-f66ea289f09c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Compressed btrfs root on eMMC

[Daniel Kulp]

For my application, the space on the eMMC is beginning to get a little 
tight.   I decided to write a new "flash" script that would flash the eMMC, 
but set it up using btrfs with compression for the root.   It's a bit 
tricky since the uboot stuff doesn't support it so the /boot needs to be 
ext2/4 and all the device tree files it needs also needs to be on that 
partition.Anyway, I did get it all working.I've attached my script.

Basically, it creates a 128MB /boot  (/dev/mmcblk1p1) to hold the kernel 
and initial filesystem and a /lib/firmware that just houses the various 
Beaglebone devicetree files.   It then uses the rest of the eMMC 
(/dev/mmcblk1p2) as a btrfs filesystem with zlib compression for the 
flash.   It then rsyncs everything over and creates a new /etc/fstab file, 
updates the boot/uEnv.txt to mark the root as btrfs, and builds and copies 
all the bb overlay dts things over. For the fstab, I have it mounting 
with compression=lzo as the data for my app works very well for that (I 
need the extra CPU when loading/saving my files), but you could keep that 
as zlib as well.

For my app, this leaves well over 2GB of free space on the eMMC as compared 
to about 500MB before.   Performance is about the same. Anyway, I 
thought I'd share it with others in case they want to try it out, play with 
it, suggest enhancements, etc  


-- 
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/d0a0a946-a5d9-4eb1-ac01-dc50c83039bd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
#!/bin/sh

DEVICE="/dev/mmcblk1"

echo "---"
echo "Creating partitions"
echo ""

# create partitions
sfdisk --force ${DEVICE} <<-__EOF__
4M,124M,,*
128M,,,-
__EOF__

blockdev --rereadpt ${DEVICE}
fdisk -l ${DEVICE}

echo "---"
echo "Formating partitions"
echo ""


#format partitions
mkfs.ext4 -F -O ^metadata_csum,^64bit ${DEVICE}p1  -L bootfs
mkfs.btrfs -f ${DEVICE}p2 -L rootfs

echo "---"
echo "Installing bootloader "
echo ""

#install bootloader
dd if=/opt/backup/uboot/MLO of=/dev/mmcblk1 count=1 seek=1 conv=notrunc bs=128k
dd if=/opt/backup/uboot/u-boot.img of=/dev/mmcblk1 count=2 seek=1 conv=notrunc bs=384k

echo "---"
echo "Creating mount points and mounting rootfs"
echo ""

#mount
mkdir /tmp/rootfs
mount -t btrfs -o noatime,nodiratime,compress-force=zlib ${DEVICE}p2 /tmp/rootfs
mkdir /tmp/rootfs/boot
mount -t ext4 -o noatime ${DEVICE}p1 /tmp/rootfs/boot

echo "---"
echo "Copy files rootfs"
echo ""

#copy files
rsync -aAx --human-readable --info=name0,progress2 /ID.txt /bin /boot /dev /etc /home /lib /lost+found /media /mnt /opt /proc /root /run /sbin /srv /sys /tmp /usr /var /tmp/rootfs --exclude=/dev/* --exclude=/proc/* --exclude=/sys/* --exclude=/tmp/* --exclude=/run/* --exclude=/mnt/* --exclude=/media/* --exclude=/lost+found --exclude=/uEnv.txt

echo "---"
echo "Configure /boot"
echo ""

#configure /boot
cd /tmp/rootfs/boot
ln -s . boot
cd /

cd /opt/source/bb.org-overlays
make clean
make

mkdir /tmp/rootfs/boot/lib
mkdir /tmp/rootfs/boot/lib/firmware
cp /opt/source/bb.org-overlays/src/arm/* /tmp/rootfs/boot/lib/firmware

echo ""  >> /tmp/rootfs/boot/uEnv.txt
echo "mmcrootfstype=btrfs" >> /tmp/rootfs/boot/uEnv.txt
echo "rootfstype=btrfs" >> /tmp/rootfs/boot/uEnv.txt
echo "mmcpart=2" >> /tmp/rootfs/boot/uEnv.txt
echo ""  >> /tmp/rootfs/boot/uEnv.txt

echo "---"
echo "Configure /etc/fstab"
echo ""

#configure fstab
echo "/dev/mmcblk1p2  /  btrfs  noatime,nodiratime,compress-force=lzo  0  1" > /tmp/rootfs/etc/fstab
echo "/dev/mmcblk1p1  /boot  ext4  defaults,noatime,nodiratime  0  2" >> /tmp/rootfs/etc/fstab
echo "debugfs  /sys/kernel/debug  debugfs  defaults  0  0" >> /tmp/rootfs/etc/fstab


echo "---"
echo "Cleaning up"
echo ""
rm -rf /tmp/rootfs/etc/ssh/*key*
rm -rf /tmp/rootfs/var/lib/connman/eth*
rm /tmp/rootfs/var/log/*
rm /tmp/rootfs/var/log/samba/*



echo "---"
echo "Unmounting filesystems"
echo ""
umount /tmp/rootfs/boot
umount /tmp/rootfs

echo "---"
echo "Done flashing eMMC, powering down"
echo ""
systemctl poweroff || halt

Re: [beagleboard] Re: Beaglebone Black Industrial universal cape not working...

[Daniel Kulp]

Things are definitely working better.   My GPIO's are available and 
working, config-pin works, etc...   Major thanks! 

Question:  Longer term,  should the /proc/device-tree/model continue to 
read "TI AM335x BeagleBone Black" or should that eventually be updated to 
give a unique name like "TI AM335x BeagleBone Black Industrial" or 
something to distinguish the model like there is for the "Wireless" 
versions and Blue and Green and such?   I don't really care, but I'd like 
to get an idea so I can plan on updating my own scripts if needed.

Thanks for the quick turnaround!
Dan


On Wednesday, December 6, 2017 at 3:22:14 PM UTC-5, RobertCNelson wrote:
>
> On Wed, Dec 6, 2017 at 12:47 PM, Jose Valenzuela San Juan 
> > wrote: 
> > Is there a workaround while we wait for the fix? 
> > 
> > Looking forward for when its ready, I'm also working on an Element14 
> > BeagleBone Black Industrial. 
> > Please let us know when ready. 
>
> Okay, i found the issue and pretty sure it's resolved. 
>
> Of course i can't find that board at my desk.. 
>
> Plese run: 
>
> cd /opt/scripts/tools/developers/ 
> git pull 
> sudo ./update_bootloader.sh --beta 
> sudo reboot 
>
> and then share with us your serial boot log, so we can verify.. 
>
> Then i'll move that version from "beta" to "normal".. 
>
> 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/732a55e2-e5c3-4535-9617-20718fa214df%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Beaglebone Black Industrial universal cape not working...

[Daniel Kulp]

MUCH MUCH better...  The GPIO's all come up correctly. 

U-Boot 2018.01-rc1-2-g965cb1b342 (Dec 06 2017 - 13:32:27 -0600), Build: 
jenkins-github_Bootloader-Builder-15

CPU  : AM335X-GP rev 2.1
I2C:   ready
DRAM:  512 MiB
No match for driver 'omap_hsmmc'
No match for driver 'omap_hsmmc'
Some drivers were not found
Reset Source: Power-on reset has occurred.
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
Using default environment

Board: BeagleBone Black
 not set. Validating first E-fuse MAC
BeagleBone Black:
Model: Element14 BeagleBone Black Industrial:
BeagleBone: cape eeprom: i2c_probe: 0x54:
BeagleBone: cape eeprom: i2c_probe: 0x55:
BeagleBone: cape eeprom: i2c_probe: 0x56:
BeagleBone: cape eeprom: i2c_probe: 0x57:
Net:   eth0: MII MODE
cpsw, usb_ether
Press SPACE to abort autoboot in 2 seconds
board_name=[A335BNLT] ...
board_rev=[EIA0] ...
switch to partitions #0, OK
mmc0 is current device
SD/MMC found on device 0
** Bad device 0:2 0x8200 **
** Bad device 0:2 0x8200 **
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
gpio: pin 56 (gpio 56) value is 0
gpio: pin 55 (gpio 55) value is 0
gpio: pin 54 (gpio 54) value is 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
Checking for: /uEnv.txt ...
Checking for: /boot.scr ...
Checking for: /boot/boot.scr ...
Checking for: /boot/uEnv.txt ...
gpio: pin 55 (gpio 55) value is 1
2042 bytes read in 36 ms (54.7 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
Running uname_boot ...
loading /boot/vmlinuz-4.4.91-ti-r137 ...
8889560 bytes read in 601 ms (14.1 MiB/s)
uboot_overlays: [uboot_base_dtb=am335x-boneblack-uboot.dtb] ...
uboot_overlays: Switching too: dtb=am335x-boneblack-uboot.dtb ...
loading /boot/dtbs/4.4.91-ti-r137/am335x-boneblack-uboot.dtb ...
57290 bytes read in 262 ms (212.9 KiB/s)
uboot_overlays: [fdt_buffer=0x6] ...
uboot_overlays: loading /lib/firmware/BB-BONE-eMMC1-01-00A0.dtbo ...
1105 bytes read in 107 ms (9.8 KiB/s)
uboot_overlays: uboot loading of [/lib/firmware/BB-HDMI-TDA998x-00A0.dtbo] 
disabled by /boot/uEnv.txt [disable_uboot_overlay_video=1]...
uboot_overlays: uboot loading of [/lib/firmware/BB-ADC-00A0.dtbo] disabled 
by /boot/uEnv.txt [disable_uboot_overlay_adc=1]...
uboot_overlays: loading /lib/firmware/AM335X-PRU-UIO-00A0.dtbo ...
853 bytes read in 467 ms (1000 Bytes/s)
uboot_overlays: loading /lib/firmware/univ-bbb-Exx-00A0.dtbo ...
92641 bytes read in 517 ms (174.8 KiB/s)
loading /boot/initrd.img-4.4.91-ti-r137 ...
6259413 bytes read in 439 ms (13.6 MiB/s)
debug: [console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
net.ifnames=0 quiet] ...
debug: [bootz 0x8200 0x8808:5f82d5 8800] ...
## Flattened Device Tree blob at 8800
   Booting using the fdt blob at 0x8800
   Loading Ramdisk to 8fa07000, end 82d5 ... OK
   reserving fdt memory region: addr=8800 size=83000
   Loading Device Tree to 8f981000, end 8fa06fff ... OK

Starting kernel ...


Thanks!
Dan




On Wednesday, December 6, 2017 at 3:22:14 PM UTC-5, RobertCNelson wrote:
>
> On Wed, Dec 6, 2017 at 12:47 PM, Jose Valenzuela San Juan 
> > wrote: 
> > Is there a workaround while we wait for the fix? 
> > 
> > Looking forward for when its ready, I'm also working on an Element14 
> > BeagleBone Black Industrial. 
> > Please let us know when ready. 
>
> Okay, i found the issue and pretty sure it's resolved. 
>
> Of course i can't find that board at my desk.. 
>
> Plese run: 
>
> cd /opt/scripts/tools/developers/ 
> git pull 
> sudo ./update_bootloader.sh --beta 
> sudo reboot 
>
> and then share with us your serial boot log, so we can verify.. 
>
> Then i'll move that version from "beta" to "normal".. 
>
> 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/bb1d54d2-aac3-4581-9f4e-30b157cdb33a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Beaglebone Black Industrial universal cape not working...

[Daniel Kulp]

Using the 9.1 based image, I get:

eeprom:[A335BNLTEIA03716BBBK1337]
model:[TI_AM335x_BeagleBone_Black]
dogtag:[BeagleBoard.org Debian Image 2017-08-31]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
2017.09-2-g0f3f1c7907]
kernel:[4.4.91-ti-r137]
nodejs:[v6.12.0]
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[disable_uboot_overlay_video=1]
uboot_overlay_options:[disable_uboot_overlay_audio=1]
uboot_overlay_options:[disable_uboot_overlay_adc=1]
uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
pkg:[bb-cape-overlays]:[4.4.20171107.0-0rcnee1~stretch+20171107]
pkg:[bb-wl18xx-firmware]:[1.20170829-0rcnee1~stretch+20170829]
pkg:[firmware-ti-connectivity]:[20170823-1rcnee0~stretch+20170830]

Using the latest stuff, I get:
git:/opt/scripts/:[e5c23dc2a45f5c9ace291dd32e7c3d79edc1932d]
eeprom:[A335BNLTEIA03716BBBK1337]
model:[Octavo_Systems_OSD3358-SM-RED]
dogtag:[BeagleBoard.org Debian Image 2017-10-10]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
2017.11-2-g7b415acfc1]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
2017.11-2-g7b415acfc1]
kernel:[4.4.91-ti-r137]
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[disable_uboot_overlay_video=1]
uboot_overlay_options:[disable_uboot_overlay_audio=1]
uboot_overlay_options:[disable_uboot_overlay_adc=1]
uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
pkg:[bb-cape-overlays]:[4.4.20171126.0-0rcnee1~stretch+20171126]
pkg:[bb-wl18xx-firmware]:[1.20170829-0rcnee1~stretch+20170829]
pkg:[firmware-ti-connectivity]:[20170823-1rcnee0~stretch+20170830]







On Tuesday, December 5, 2017 at 5:19:18 PM UTC-5, RobertCNelson wrote:
>
> On Tue, Dec 5, 2017 at 4:13 PM, Daniel Kulp > 
> wrote: 
> > 
> > Uhgg... also just discovered that the /proc/device-tree-model now reads: 
> > 
> > Octavo Systems OSD3358-SM-RED 
> > 
> > On the older stretch 9.1 based image I have, it reads "TI AM335x 
> BeagleBone 
> > Black" just like the black's.That's going to break a bunch of things 
> for 
> > me as well.  :(I need to use the industrial version as we hit 
> > temperatures well below freezing.   Is this a uBoot thing?   Would 
> dropping 
> > back to the older uBoot help? 
>
>
> Your board has a weird eeprom, please run: 
>
> sudo /opt/scripts/tools/version.sh 
>
> That board should have: 
>
> https://github.com/beagleboard/image-builder/blob/master/readme.md 
>
> Element14 BeagleBone Black Industrial: 
>
>   A0: [aa 55 33 ee 41 33 33 35  42 4e 4c 54 45 49 41 30 
> |.U3.A335BNLTEIA0|] 
>
> 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/20ad5de5-8a5c-4554-b75c-7e9c575370f5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Beaglebone Black Industrial universal cape not working...

[Daniel Kulp]

Uhgg... also just discovered that the /proc/device-tree-model now reads:

Octavo Systems OSD3358-SM-RED

On the older stretch 9.1 based image I have, it reads "TI AM335x BeagleBone 
Black" just like the black's.That's going to break a bunch of things 
for me as well.  :(I need to use the industrial version as we hit 
temperatures well below freezing.   Is this a uBoot thing?   Would dropping 
back to the older uBoot help?




On Tuesday, December 5, 2017 at 4:46:22 PM UTC-5, Daniel Kulp wrote:
>
>
> I have an image that works fine on a Beaglebone Black and Beaglebone 
> green, but it's not working properly on the "red" industrial version.   For 
> some reason, the uboot_capemgr isn't being loaded by uboot on the Red 
> whereas it is using the exact same SD card/Image as I use on the others.   
>
> Connecting a serial cable, on the normal black, I see:
>
> loading /boot/dtbs/4.4.91-ti-r137/am335x-boneblack-uboot.dtb ...
> 57290 bytes read in 263 ms (211.9 KiB/s)
> uboot_overlays: [fdt_buffer=0x6] ...
> uboot_overlays: loading /lib/firmware/AM335X-20-00A0.dtbo ...
> 378 bytes read in 363 ms (1000 Bytes/s)
> uboot_overlays: loading /lib/firmware/BB-BONE-eMMC1-01-00A0.dtbo ...
> 1105 bytes read in 108 ms (9.8 KiB/s)
> uboot_overlays: uboot loading of [/lib/firmware/BB-HDMI-TDA998x-00A0.dtbo] 
> disabled by /boot/uEnv.txt [disable_uboot_overlay_video=1]...
> uboot_overlays: uboot loading of [/lib/firmware/BB-ADC-00A0.dtbo] disabled 
> by /boot/uEnv.txt [disable_uboot_overlay_adc=1]...
> uboot_overlays: loading /lib/firmware/AM335X-PRU-UIO-00A0.dtbo ...
> 853 bytes read in 466 ms (1000 Bytes/s)
> uboot_overlays: loading /lib/firmware/univ-bbb-Exx-00A0.dtbo ...
> 92641 bytes read in 515 ms (174.8 KiB/s)
> loading /boot/initrd.img-4.4.91-ti-r137 ...
> 6259413 bytes read in 438 ms (13.6 MiB/s)
> debug: [console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
> root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
> net.ifnames=0 quiet] ...
>
>
> But on the Red, I see:
>
> loading /boot/dtbs/4.4.91-ti-r137/am335x-boneblack-uboot.dtb ...
> 57290 bytes read in 262 ms (212.9 KiB/s)
> uboot_overlays: [fdt_buffer=0x6] ...
> uboot_overlays: loading /lib/firmware/OSD3358-00A0.dtbo ...
> 441 bytes read in 532 ms (0 Bytes/s)
> uboot_overlays: loading /lib/firmware/M-BB-OSD3358-SM-RED-00A0.dtbo ...
> 285 bytes read in 450 ms (0 Bytes/s)
> uboot_overlays: loading /lib/firmware/BB-BONE-eMMC1-01-00A0.dtbo ...
> 1105 bytes read in 107 ms (9.8 KiB/s)
> uboot_overlays: uboot loading of [/lib/firmware/BB-HDMI-TDA998x-00A0.dtbo] 
> disabled by /boot/uEnv.txt [disable_uboot_overlay_video=1]...
> uboot_overlays: uboot loading of [/lib/firmware/BB-ADC-00A0.dtbo] disabled 
> by /boot/uEnv.txt [disable_uboot_overlay_adc=1]...
> uboot_overlays: loading /lib/firmware/AM335X-PRU-UIO-00A0.dtbo ...
> 853 bytes read in 459 ms (1000 Bytes/s)
> loading /boot/initrd.img-4.4.91-ti-r137 ...
> 6259413 bytes read in 438 ms (13.6 MiB/s)
> debug: [console=ttyO0,115200n8 root=/dev/mmcblk0p1 ro rootfstype=ext4 
> rootwait coherent_pool=1M net.ifnames=0 quiet] 
>
> Is there something about the OSD3358-00A0 and M-BB-OSD3358-SM-RED-00A0 
> compared to the normal AM335X-20-00A0 that would cause the universal cape 
> manager to not be detected or loaded? Is there an easy workaround?   
>

-- 
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/3bdb4f7f-58f7-494d-8139-83d934d2f030%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Beaglebone Black Industrial universal cape not working...

[Daniel Kulp]

It's the Element14 Beaglebone Black Industrial

BBONE-BLACK-IND-4G

http://www.newark.com/element14/bbone-black-ind-4g/beaglebone-black-rev-c-cortex/dp/53Y3717?CMP=KNC-GUSA-GEN-KWL&mckv=|pcrid|190494657105|&gclid=EAIaIQobChMIlpfu1fDz1wIVk0sNCh1XjAUUEAAYAyAAEgIGLvD_BwE

Thanks!
Dan


On Tuesday, December 5, 2017 at 4:56:37 PM UTC-5, RobertCNelson wrote:
>
> On Tue, Dec 5, 2017 at 3:46 PM, Daniel Kulp > 
> wrote: 
> > 
> > I have an image that works fine on a Beaglebone Black and Beaglebone 
> green, 
> > but it's not working properly on the "red" industrial version.   For 
> some 
> > reason, the uboot_capemgr isn't being loaded by uboot on the Red whereas 
> it 
> > is using the exact same SD card/Image as I use on the others. 
> > 
> > Connecting a serial cable, on the normal black, I see: 
> > 
> > loading /boot/dtbs/4.4.91-ti-r137/am335x-boneblack-uboot.dtb ... 
> > 57290 bytes read in 263 ms (211.9 KiB/s) 
> > uboot_overlays: [fdt_buffer=0x6] ... 
> > uboot_overlays: loading /lib/firmware/AM335X-20-00A0.dtbo ... 
> > 378 bytes read in 363 ms (1000 Bytes/s) 
> > uboot_overlays: loading /lib/firmware/BB-BONE-eMMC1-01-00A0.dtbo ... 
> > 1105 bytes read in 108 ms (9.8 KiB/s) 
> > uboot_overlays: uboot loading of 
> [/lib/firmware/BB-HDMI-TDA998x-00A0.dtbo] 
> > disabled by /boot/uEnv.txt [disable_uboot_overlay_video=1]... 
> > uboot_overlays: uboot loading of [/lib/firmware/BB-ADC-00A0.dtbo] 
> disabled 
> > by /boot/uEnv.txt [disable_uboot_overlay_adc=1]... 
> > uboot_overlays: loading /lib/firmware/AM335X-PRU-UIO-00A0.dtbo ... 
> > 853 bytes read in 466 ms (1000 Bytes/s) 
> > uboot_overlays: loading /lib/firmware/univ-bbb-Exx-00A0.dtbo ... 
> > 92641 bytes read in 515 ms (174.8 KiB/s) 
> > loading /boot/initrd.img-4.4.91-ti-r137 ... 
> > 6259413 bytes read in 438 ms (13.6 MiB/s) 
> > debug: [console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
> > root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
> > net.ifnames=0 quiet] ... 
> > 
> > 
> > But on the Red, I see: 
> > 
> > loading /boot/dtbs/4.4.91-ti-r137/am335x-boneblack-uboot.dtb ... 
> > 57290 bytes read in 262 ms (212.9 KiB/s) 
> > uboot_overlays: [fdt_buffer=0x6] ... 
> > uboot_overlays: loading /lib/firmware/OSD3358-00A0.dtbo ... 
> > 441 bytes read in 532 ms (0 Bytes/s) 
> > uboot_overlays: loading /lib/firmware/M-BB-OSD3358-SM-RED-00A0.dtbo ... 
> > 285 bytes read in 450 ms (0 Bytes/s) 
> > uboot_overlays: loading /lib/firmware/BB-BONE-eMMC1-01-00A0.dtbo ... 
> > 1105 bytes read in 107 ms (9.8 KiB/s) 
> > uboot_overlays: uboot loading of 
> [/lib/firmware/BB-HDMI-TDA998x-00A0.dtbo] 
> > disabled by /boot/uEnv.txt [disable_uboot_overlay_video=1]... 
> > uboot_overlays: uboot loading of [/lib/firmware/BB-ADC-00A0.dtbo] 
> disabled 
> > by /boot/uEnv.txt [disable_uboot_overlay_adc=1]... 
> > uboot_overlays: loading /lib/firmware/AM335X-PRU-UIO-00A0.dtbo ... 
> > 853 bytes read in 459 ms (1000 Bytes/s) 
> > loading /boot/initrd.img-4.4.91-ti-r137 ... 
> > 6259413 bytes read in 438 ms (13.6 MiB/s) 
> > debug: [console=ttyO0,115200n8 root=/dev/mmcblk0p1 ro rootfstype=ext4 
> > rootwait coherent_pool=1M net.ifnames=0 quiet]  
> > 
> > Is there something about the OSD3358-00A0 and M-BB-OSD3358-SM-RED-00A0 
> > compared to the normal AM335X-20-00A0 that would cause the universal 
> cape 
> > manager to not be detected or loaded? Is there an easy workaround? 
>
> Which red board? 
>
> 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/07c68fac-ff4e-4e2c-9c75-7bec4802c03c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Beaglebone Black Industrial universal cape not working...

[Daniel Kulp]

I have an image that works fine on a Beaglebone Black and Beaglebone green, 
but it's not working properly on the "red" industrial version.   For some 
reason, the uboot_capemgr isn't being loaded by uboot on the Red whereas it 
is using the exact same SD card/Image as I use on the others.   

Connecting a serial cable, on the normal black, I see:

loading /boot/dtbs/4.4.91-ti-r137/am335x-boneblack-uboot.dtb ...
57290 bytes read in 263 ms (211.9 KiB/s)
uboot_overlays: [fdt_buffer=0x6] ...
uboot_overlays: loading /lib/firmware/AM335X-20-00A0.dtbo ...
378 bytes read in 363 ms (1000 Bytes/s)
uboot_overlays: loading /lib/firmware/BB-BONE-eMMC1-01-00A0.dtbo ...
1105 bytes read in 108 ms (9.8 KiB/s)
uboot_overlays: uboot loading of [/lib/firmware/BB-HDMI-TDA998x-00A0.dtbo] 
disabled by /boot/uEnv.txt [disable_uboot_overlay_video=1]...
uboot_overlays: uboot loading of [/lib/firmware/BB-ADC-00A0.dtbo] disabled 
by /boot/uEnv.txt [disable_uboot_overlay_adc=1]...
uboot_overlays: loading /lib/firmware/AM335X-PRU-UIO-00A0.dtbo ...
853 bytes read in 466 ms (1000 Bytes/s)
uboot_overlays: loading /lib/firmware/univ-bbb-Exx-00A0.dtbo ...
92641 bytes read in 515 ms (174.8 KiB/s)
loading /boot/initrd.img-4.4.91-ti-r137 ...
6259413 bytes read in 438 ms (13.6 MiB/s)
debug: [console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
net.ifnames=0 quiet] ...


But on the Red, I see:

loading /boot/dtbs/4.4.91-ti-r137/am335x-boneblack-uboot.dtb ...
57290 bytes read in 262 ms (212.9 KiB/s)
uboot_overlays: [fdt_buffer=0x6] ...
uboot_overlays: loading /lib/firmware/OSD3358-00A0.dtbo ...
441 bytes read in 532 ms (0 Bytes/s)
uboot_overlays: loading /lib/firmware/M-BB-OSD3358-SM-RED-00A0.dtbo ...
285 bytes read in 450 ms (0 Bytes/s)
uboot_overlays: loading /lib/firmware/BB-BONE-eMMC1-01-00A0.dtbo ...
1105 bytes read in 107 ms (9.8 KiB/s)
uboot_overlays: uboot loading of [/lib/firmware/BB-HDMI-TDA998x-00A0.dtbo] 
disabled by /boot/uEnv.txt [disable_uboot_overlay_video=1]...
uboot_overlays: uboot loading of [/lib/firmware/BB-ADC-00A0.dtbo] disabled 
by /boot/uEnv.txt [disable_uboot_overlay_adc=1]...
uboot_overlays: loading /lib/firmware/AM335X-PRU-UIO-00A0.dtbo ...
853 bytes read in 459 ms (1000 Bytes/s)
loading /boot/initrd.img-4.4.91-ti-r137 ...
6259413 bytes read in 438 ms (13.6 MiB/s)
debug: [console=ttyO0,115200n8 root=/dev/mmcblk0p1 ro rootfstype=ext4 
rootwait coherent_pool=1M net.ifnames=0 quiet] 

Is there something about the OSD3358-00A0 and M-BB-OSD3358-SM-RED-00A0 
compared to the normal AM335X-20-00A0 that would cause the universal cape 
manager to not be detected or loaded? Is there an easy workaround?   

-- 
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/9f065fdf-80c0-4ed0-affa-5bc3ae4cd980%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Rose-Hulman Embedded Linux Project Demos

[Daniel Neelappa]

Hi,

I was able to communicate with my car through my beaglebone blue. 

It is still an active project, as I'm trying to decipher what message 
causes a certain action.

https://elinux.org/ECE497_Car_CANBUS#Highlights


Thanks,
Daniel

-- 
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/ba3f68dd-e6f3-467d-8f0c-ac2fc4dba0f2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: PocketBeagle cape KiCad template?

[Daniel Kulp]

This is perfect.   Thanks!
Dan


On Sunday, October 22, 2017 at 9:08:50 AM UTC-4, mwell...@gmail.com wrote:
>
> https://github.com/mwelling/pocketbeagle-cape-template
>
> On Friday, October 20, 2017 at 11:29:49 AM UTC-5, Daniel Kulp wrote:
>>
>>
>> Has anyone started on (or has completed) a KiCad template for a 
>> PocketBeagle cape?I used the BeagleBone Black template from 
>> https://github.com/KiCad/kicad-library/tree/master/template as a 
>> starting point for a cape previously and it worked great.   Was hoping 
>> someone has done something similar for the PocketBeagle. 
>>
>

-- 
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/4d399ffe-59ea-4849-bd1e-46b3ced15568%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] PocketBeagle cape KiCad template?

[Daniel Kulp]

Has anyone started on (or has completed) a KiCad template for a 
PocketBeagle cape?I used the BeagleBone Black template 
from https://github.com/KiCad/kicad-library/tree/master/template as a 
starting point for a cape previously and it worked great.   Was hoping 
someone has done something similar for the PocketBeagle. 

-- 
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/cff05cd0-484a-41b1-aea9-d3e3029f40fe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Failed to enable UART1, Ubuntu 16.04

[daniel . diaz . benito]

Thanks Robert, you saved my day.
I lost a couple of days with UART not working after upgrading to Debian 9.
Finally after having a look at the posts in the mailing list I found this 
and figured out 'cape_enable=bone_capemgr.enable_partno=BB-UART1' is not 
enough anymore.
It is perhaps worthed to include an entry in the wiki 
 with 
specific information on this change and how to enable the UART, as not all 
of us who work with overlays have a full understanding on how they work and 
interact with uboot.

Thanks a log again! :)

El dilluns, 17 juliol de 2017 20:01:24 UTC+2, RobertCNelson va escriure:
>
> On Mon, Jul 17, 2017 at 12:18 PM, Hồng Quân Nguyễn 
> > wrote: 
> > I installed Ubuntu 16.04 to my BeagleBone Black and tried to enable 
> UART1, 
> > but it seems to not works. 
> > 
> > Content of /etc/default/capemgr: 
> > 
> > # Default settings for capemgr. This file is sourced by /bin/sh from 
> > # /etc/init.d/capemgr.sh 
> > 
> > # Options to pass to capemgr 
> > CAPE=BB-UART1,BB-PWM1 
> > 
> > 
> > 
> > Content of /sys/devices/platform/bone_capemgr/slots: 
> > 
> >  0: ---l--  -1 
> >  1: --  -1 
> >  2: ---l--  -1 
> >  3: ---l--  -1 
> >  4: --O---  -1 
> > 
> > 
> > 
> > Log related to BB-UART1 cape: 
> > 
> > $ journalctl 
> > Jul 17 16:15:00 beaglebone-glass sh[612]: generic-board-startup: 
> > [model=TI_AM335x_BeagleBone_Black] 
> > Jul 17 16:15:00 beaglebone-glass sh[612]: generic-board-startup: 
> [startup 
> > script=/opt/scripts/boot/am335x_evm.sh] 
> > Jul 17 16:15:00 beaglebone-glass kernel: bone_capemgr bone_capemgr: 
> > part_number 'BB-UART1', version 'N/A' 
> > Jul 17 16:15:00 beaglebone-glass kernel: bone_capemgr bone_capemgr: slot 
> #4: 
> > override 
> > Jul 17 16:15:00 beaglebone-glass kernel: bone_capemgr bone_capemgr: slot 
> #4: 
> > auto loading handled by U-Boot 
> > Jul 17 16:15:00 beaglebone-glass cron[676]: (CRON) INFO (pidfile fd = 3) 
> > Jul 17 16:15:00 beaglebone-glass systemd[1]: Starting System Logging 
> > Service... 
> > Jul 17 16:15:01 beaglebone-glass systemd[1]: Started D-Bus System 
> Message 
> > Bus. 
> > 
> > Linux info: 
> > 
> > $ uname -a 
> > Linux beaglebone-glass 4.4.62-ti-r104 #1 SMP Thu May 18 18:00:40 UTC 
> 2017 
> > armv7l armv7l armv7l GNU/Linux 
> > 
> > $ cat /etc/dogtag 
> > rcn-ee.net console Ubuntu Image 2017-05-21 
> > 
> > How to fix it? 
>
> That image uses u-boot overlays: 
>
> http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays 
>
> in /boot/uEnv.txt set: 
>
> uboot_overlay_addr4=/lib/firmware/BB-UART1-00A0.dtbo 
> uboot_overlay_addr5=/lib/firmware/BB-PWM1-00A0.dtbo 
>
> 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/9a51a0ba-2f14-43ec-b05a-40ea1e96de2b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Change PySerial or other module similar

[daniel . diaz . benito]

If you just have to send bytes, you can find useful to use a bytearray.
*[Python 3]*
serial.write(bytearray([255]))
serial.write(bytearray([2, 75, 250]))

The struct module is still useful to send C style values, but I suggest you 
make explicit whether you are using little or big-endian to avoid confusion 
(default will use otherwise the machine running the code default which may 
change when you move the code to other machine):
struct.pack('>L', 75655)

El dijous, 9 març de 2017 19:09:12 UTC+1, David Caniceiro va escriure:
>
> Thanks for your answers guys,
>
> testing the Dennis answer, and after read the struct information,i reached 
> a solution:
>
> if i use -> struct.pack('B',255)
> now only use one byte on serial communication, instead of 3 bytes like i 
> was doing before(sending a string '255')
>
> But after some tests, i confirmed if i use the hex string directly on 
> write. its works too.
>  Ex::  serial.write('\xFF')
>
> Thanks again for the answers, and sorry for being newbie.
>
> Best Regards,
> David 
>
>
>
>
>
>
>
> 2017-03-09 14:57 GMT+00:00 Dennis Lee Bieber  >:
>
>> On Thu, 9 Mar 2017 04:34:43 -0800 (PST),
>> davidvaran...@gmail.com  declaimed the
>> following:
>>
>> >
>> >I want to know this because, PySerial only communicate with "string", 
>> and i
>>
>> It sends bytes (at least, in Python 2.x -- not sure if Python 3.x 
>> uses
>> unicode or byte as the native component for PySerial), packaged in a 
>> Python
>> string data type.
>>
>> There is no constraint on what those bytes contain, beyond that 
>> imposed
>> by the console (console output -- print theString -- may try to convert
>> non-ASCII values to something unusable).
>>
>> >
>> >Saying this, i want to send data in int/hex or binary format instead of
>> >string from the BeagleBone side, other solution can be change the 
>> PySerial
>> >module to do this.
>> >
>>
>> "hex" is, to most people, a character string representation of a 
>> binary
>> value using a radix of 16 -- which means each byte of the raw data is
>> represented by two characters, one for each four bits.
>>
>> >Any help will be aprecciated.
>>
>> Read the library reference manual section describing the struct 
>> module.
>>
>>
>> >>> import struct
>> >>> it = 202
>> >>> bt = "6"
>> >>> ft = 3.14159
>> >>> pck = struct.pack("!hiqBBifd",
>> ... it, it, it, it, ord(bt), ord(bt), ft, ft)
>> >>>
>> >>> repr(pck)
>>
>> "'\\x00\\xca\\x00\\x00\\x00\\xca\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\xca\\xca6\\x00\\x00\\x006@I\\x0f\\xd0@\\t!\\xf9\\xf0\\x1b\\x86n'"
>> >>>
>>
>>
>> The format string is (repr() shows each byte, and if printable, 
>> does
>> not show the xNN format):
>>
>> !   network byte order
>> h   (signed) short  202 => x00ca
>> i   (signed) integer202 => x00ca
>> q   (signed) long-long  202 => x00ca
>> B   unsigned char (integer data type -- "c" is 1-character string) 
>> 202 =>
>> xca
>> B   unsigned char (need ord() to get integer)   ord("6") 
>> => 54 => '6'
>> i   (signed) integerord("6") => 54 => 
>> x00 and '6'
>> f   float   3.14159 => '@I' 
>> and x04d0
>> d   double  3.14159 =>
>> '@' and  and '!' and xf9f01b86 and 'n'
>>
>>
>> --
>> Wulfraed Dennis Lee Bieber AF6VN
>> wlf...@ix.netcom.com HTTP://wlfraed.home.netcom.com/
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "BeagleBoard" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/beagleboard/C6m1B9PNxmk/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> beagleboard...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/b8p2cc16t0ei7qklbtfba89oerst3drm6e%404ax.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/f1c0a78e-0c6f-4921-9345-bd27bb6e9fa0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Porting from BeagleBone Black (BBB) to BeagleBone Green Wireless (BBGW)

[Daniel Kulp]

I've had no issues with the PRU (using the latest jessie IoT image) on the 
BBGW.   The biggest issue I had was that the wireless stuff on the BBGW is 
wired very differently than the BBBW and it consumes a bunch (13) of GPIO 
pins.   I had to completely redesign a cape I had to work on the the BBGW 
to avoid all the pins it sucks up. Pins not available:  P8_11, P8_12, 
P8_14-P8_18, P8_26, P9_12, P9_28-31. I definitely prefer the BBBW for 
this reason.The wireless stuff on there doesn't consume any of the 
gpios.  

Basically, check your board.  You list SPI as something you need.   SPI1 is 
on P9_28-31 and thus wouldn't work.   (you MIGHT be able to get it to work 
with a custom overlay.  Those pins I *think* are just used for bluetooth 
audio so a custom overlay for BBGW that disables that might work, no idea)

Dan


On Friday, February 24, 2017 at 3:55:53 PM UTC-5, agm...@gmail.com wrote:
>
> Hello All,
>
> I've been working with BBB on a project which uses Xenomai (2.6.4 and 3), 
> PRU and bunch of serial devices (UART, I2C and SPI). I want to move my 
> application to BBGW (for WiFi and Bluetooth). 
>
> I know there are images for BBGW (i'm still unclear which image to use), 
> but can someone confirm if they have used Xenomai and PRUs with BBGW and if 
> they had any difficulty. 
>
> I'd really appreciate any advice on which image/kernel version to use. 
>
> 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/3845a8e3-e787-4fa0-b042-6c5da54fbe60%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Making a custom SD image of BBB's eMMC

[daniel . diaz . benito]

Mount the SD with the resulting copy of your eMMC, then edit the file 
/boot/uEnv.txt

If the following line is commented, the SD card will NOT autoflash:
#cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh

Uncomment the line and it will auto-flash on boot time.

Daniel

El divendres, 10 març de 2017 18:24:18 UTC+1, Justin Pearson va escriure:
>
> On Fri, Mar 10, 2017 at 6:37 AM, Charlie Rysenga  > wrote:
>
>>
>>- Boot master BBB with no SD card in
>>- Insert SD card
>>- Log in (e.g. with serial terminal, SSH etc.) and run sudo 
>>
>> /opt/scripts/tools/eMMC/beaglebone-black-make-microSD-flasher-from-eMMC.sh 
>>(you may have to cd /opt/scripts and git pull before this.) LEDs will 
>> flash 
>>in sequence whilst SD card is being written.
>>- When the LEDs stop and the script terminates, remove the SD card.
>>- Insert SD card into new BBB then power on.
>>- eMMC will be flashed; LEDs on new BBB will flash in sequence until 
>>complete.
>>
>>
> This sounds like what I'm looking for, thanks. 
>
> Follow-up: Is there an easy way to modify this procedure so the new BBB 
> simply boots from the SD card instead of wiping out its eMMC with the image 
> on the SD card? 
>
> Thanks,
> Justin
>
>
>  
>
>>
>>- 
>>
>>
>> On Monday, March 6, 2017 at 12:46:13 PM UTC-5, Justin Pearson wrote:
>>>
>>> I'd like to help a fellow BBB user by sending him a disk image of my 
>>> working BBB configuration for him to install on his own BBB.
>>>
>>> However, I'm not sure how to copy my BBB's eMMC. I was hoping that it 
>>> would be as simple as using dd to copy my BBB's entire 2GB eMMC into some 
>>> .img.xz file. But then I found this article:
>>>
>>>
>>> http://blog.logikonlabs.com/how-to-create-a-custom-microsd-card-image-for-the-beaglebone-black/
>>>
>>> It's a long procedure. Is this the correct method for creating an image 
>>> of an entire BBB configuration, suitable for copying to another BBB?
>>>
>>> Thanks,
>>> Justin
>>>
>>> -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "BeagleBoard" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/beagleboard/DuLpDvzrmAE/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> beagleboard...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/9e599566-4b82-4520-8065-41b2aae88119%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/beagleboard/9e599566-4b82-4520-8065-41b2aae88119%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>> 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/aee7f3f5-ceb2-42cc-bcac-470cb6ee7e48%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] beaglebone auto loading handled by U-Boot

[daniel . eric . carlson]

I have two beaglebone boards...both SanCloud

I am trying to use /boot/uEnv.txt to load cape overlays...

One board the cape loads, the other board the cape does not...

dmesg showing board #1 below the cape loads @ 2.526116...

[2.368226] bone_capemgr bone_capemgr: Baseboard: 
'A335BNLT,SE0A,0617BBEF49D3'
[2.368259] bone_capemgr bone_capemgr: 
compatible-baseboard=ti,beaglebone-black - #slots=4
[2.406037] bone_capemgr bone_capemgr: slot #0: No cape found
[2.446033] bone_capemgr bone_capemgr: slot #1: No cape found
[2.486034] bone_capemgr bone_capemgr: slot #2: No cape found
[2.526036] bone_capemgr bone_capemgr: slot #3: No cape found
[2.526074] bone_capemgr bone_capemgr: enabled_partno PARTNO 
'BB-SPI1-01' VER 'N/A' PR '0'
[2.526085] bone_capemgr bone_capemgr: slot #4: override
[2.526100] bone_capemgr bone_capemgr: Using override eeprom data at 
slot 4
[2.526116] bone_capemgr bone_capemgr: slot #4: 'Override Board 
Name,00A0,Override Manuf,BB-SPI1-01'



vs. this board #2 below that doesn't work shows "auto loading handled by 
U-Boot" @ 2.373229

[2.373029] bone_capemgr bone_capemgr: Baseboard: 
'A335BNLT,SE0A,0617BBEF494F'
[2.373063] bone_capemgr bone_capemgr: 
compatible-baseboard=ti,beaglebone-black - #slots=4
[2.373098] bone_capemgr bone_capemgr: slot #0: auto loading handled by 
U-Boot
[2.373120] bone_capemgr bone_capemgr: slot #1: auto loading handled by 
U-Boot
[2.373159] bone_capemgr bone_capemgr: slot #2: auto loading handled by 
U-Boot
[2.373181] bone_capemgr bone_capemgr: slot #3: auto loading handled by 
U-Boot
[2.373205] bone_capemgr bone_capemgr: enabled_partno PARTNO 
'BB-SPI1-01' VER 'N/A' PR '0'
[2.373216] bone_capemgr bone_capemgr: slot #4: override
[2.373229] bone_capemgr bone_capemgr: slot #4: auto loading handled by 
U-Boot


Both have the same uboot version string 
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
2017.05-2-gc0970ed183]

cape overlay files are present on both boards @ /lib/firmware

When I update initramfs I see this...
update-initramfs: Generating /boot/initrd.img-4.4.62-ti-r105


My /boot/uEnv.txt looks like this on both boards...

#Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0

uname_r=4.4.62-ti-r105
#uuid=
#dtb=


###U-Boot Overlays###
###Documentation: 
http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays
###Master Enable
enable_uboot_overlays=1
###
###Overide capes with eeprom
#uboot_overlay_addr0=/lib/firmware/.dtbo
#uboot_overlay_addr1=/lib/firmware/.dtbo
#uboot_overlay_addr2=/lib/firmware/.dtbo
#uboot_overlay_addr3=/lib/firmware/.dtbo
###
###Additional custom capes
#uboot_overlay_addr4=/lib/firmware/.dtbo
#uboot_overlay_addr5=/lib/firmware/.dtbo
#uboot_overlay_addr6=/lib/firmware/.dtbo
#uboot_overlay_addr7=/lib/firmware/.dtbo
###
###Custom Cape
#dtb_overlay=/lib/firmware/.dtbo
###
###Disable auto loading of virtual capes (emmc/video/wireless/adc)
#disable_uboot_overlay_emmc=1
#disable_uboot_overlay_video=1
#disable_uboot_overlay_audio=1
#disable_uboot_overlay_wireless=1
#disable_uboot_overlay_adc=1
###
###PRUSS OPTIONS
###pru_rproc (4.4.x-ti kernel)
uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-4-TI-00A0.dtbo
###pru_uio (mainline kernel)
#uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo
###
###Cape Universal Enable
#enable_uboot_cape_universal=1
###
###Debug: disable uboot autoload of Cape
#disable_uboot_overlay_addr0=1
#disable_uboot_overlay_addr1=1
#disable_uboot_overlay_addr2=1
#disable_uboot_overlay_addr3=1
###
###U-Boot fdt tweaks...
#uboot_fdt_buffer=0x6
###U-Boot Overlays###

cmdline=coherent_pool=1M net.ifnames=0 quiet

#In the event of edid real failures, uncomment this next line:
#cmdline=coherent_pool=1M net.ifnames=0 quiet video=HDMI-A-1:1024x768@60e

##Example v3.8.x
#cape_disable=capemgr.disable_partno=
#cape_enable=capemgr.enable_partno=

##Example v4.1.x
cape_disable=bone_capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN
cape_enable=bone_capemgr.enable_partno=BB-SPI1-01
##enable Generic eMMC Flasher:
##make sure, these tools are installed: dosfstools rsync
#cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh

I presently don't have access to boot console traffic.

Why does one board report auto loading handled by U-Boot, while the other 
board does not (and seems to load overlays and work properly)?

-- 
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/934874f6-bcde-43f5-af74-7c4644141825%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Linux/BEAGLEBK: PRU-ICSS Ethernet issue

[Daniel Gorsulowski]

Hi!

Are you talking about the PHYs?
The normal way should be (as far as I understand) to cede the reset-timing 
to the prueth driver. But if I do so (define reset-gpios and reset-delay-us 
in pruss-mdio node), the PHY reset is never released.
So I handle the PHY-reset manually via GPIO access within a script. (The 
same script works fine if I use the PRU ports with EtherCAT or ProfiNet 
firmware)

Btw. the CPSW ethernet port (eth0) works fine, if I didn't mention it 
clearly enough.

Am Sonntag, 18. Dezember 2016 03:34:29 UTC+1 schrieb c2h2:
>
> Hi, are the power sequence /reset timing on the 3 ports correct? 
>
> On Fri, Dec 16, 2016 at 3:50 PM, Daniel Gorsulowski <
> daniel.go...@gmail.com > wrote:
>
>> Hi!
>>
>> I have an issue with a custom board, based on BeagleBone Black (BEAGLEBK) 
>> and AM3359 ICS (TMDSICE3359) design.
>> ...
>>
>

-- 
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/0b43b341-3941-4a4b-b922-22da28778787%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Spam on the list

[Daniel Escasa]

Sabi ni Rick M noong Monday, October 3, 2016 at 2:46:47 PM UTC+8:
>
> There's so much spam lately. I know it's been discussed, but I didn't 
> really follow the threads. What puzzles me is that this is the only one of 
> the couple-dozen lists I'm on that gets spam. Is it because we insist on a 
> lenient post or subscribe policy? Perhaps we can tighten that up? 
>

I've set my delivery to abridged summary. That way, the spam doesn't wind 
up in my inbox, and it's also a neat way for me to skip posts I may not be 
interested in 

-- 
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/43557650-1b85-40c4-8872-2f82cf96c358%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] OpenGL and SGX-PVR drivers on custom hardware

[Daniel Gorsulowski]

Hello!
Im working on custom Hardware, related to Beaglebone black. The main part 
is equal to this board, so I hope you can help me.
The major hardware difference is, there is a LVDS transmitter in place of 
the HDMI transmitter.
The major software difference is: I'm using an old ELDK 5.3 toolchain and 
RootFS - details follow.

My problem is:
I build the kernel and the SGX modules, everything seems fine, including 
the installation on target. But executing tests, i.e. pvr2d_test, 
sgx_init_test, sgx_*_test causes segmentation faults.
(And I dont't know if this correlates with my other issue: Qt5 EGLFS apps 
show nothing but a black screen without error messages)

My steps are:
I'm following 
http://elinux.org/BeagleBoardDebian#SGX_BeagleBone.2FBeagleBone_Black
git clone https://github.com/RobertCNelson/bb-kernel.git
cd bb-kernel
git checkout origin/am33x-v4.1 -b bb300
git am ../0001-add-bb300-board-support.patch
./build_kernel.sh
./sgx_build_modules.sh

sudo tar xf deploy/GFX_5.01.01.02_es8.x.tar.gz -C /tftpboot/bb300/linux/
rootfs/
sed -i -e 's\distro=$(lsb_release -si)\distro=Ubuntu\' 
/tftpboot/bb300/linux/rootfs/opt/gfxinstall/sgx-install.sh
sudo tar xf deploy/4.1.3324-modules.tar.gz -C /tftpboot/bb300/linux/rootfs/ 
--exclude=lib/modules/4.1.3324/kernel/crypto 
--exclude=lib/modules/4.1.3324/kernel/drivers/bluetooth 
--exclude=lib/modules/4.1.3324/kernel/net/bluetooth




0001-add-bb300-board-support.patch:
diff --git a/.gitignore b/.gitignore
index c16aff6..7cfbbe2 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,6 +1,6 @@
 .CC
 recipe.sh
-system.sh
+#system.sh
 KERNEL
 dl
 deploy
@@ -12,3 +12,4 @@ patches/previous_defconfig
 patches/bisect_defconfig
 patches/HEAD_omap2plus_defconfig
 patches/MOD_omap2plus_defconfig
+patches/ref_bb300_defconfig
diff --git a/build_kernel.sh b/build_kernel.sh
index 10a58b1..0fd4cb8 100755
--- a/build_kernel.sh
+++ b/build_kernel.sh
@@ -71,10 +71,10 @@ make_kernel () {
 
 unset address
 
-##uImage, if you really really want a uImage, zreladdr needs to be 
defined on the build line going forward...
-##make sure to install your distro's version of mkimage
-#image="uImage"
-#address="LOADADDR=${ZRELADDR}"
+#uImage, if you really really want a uImage, zreladdr needs to be 
defined on the build line going forward...
+#make sure to install your distro's version of mkimage
+image="uImage"
+address="LOADADDR=${ZRELADDR}"
 
 cd "${DIR}/KERNEL" || exit
 echo "-"
diff --git a/patch.sh b/patch.sh
index 4e9a8b5..7634dd4 100644
--- a/patch.sh
+++ b/patch.sh
@@ -612,6 +612,23 @@ sgx () {
 fi
 }
 
+bb300 () {
+echo "dir: bb300"
+#regenerate="enable"
+if [ "x${regenerate}" = "xenable" ] ; then
+start_cleanup
+fi
+
+${git} 
"${DIR}/patches/bb300/0001-reset-is_reset-and-clear_reset-api-s.patch"
+${git} "${DIR}/patches/bb300/0003-arm-add-bb300-board-support.patch"
+
+if [ "x${regenerate}" = "xenable" ] ; then
+number=2
+cleanup
+fi
+}
+
 ###
 reverts
 backports
@@ -622,6 +639,7 @@ bbb_overlays
 beaglebone
 quieter
 sgx
+bb300
 
 packaging () {
 echo "dir: packaging"
diff --git a/patches/defconfig b/patches/defconfig
index 4688ec4..a96e82b 100644
--- a/patches/defconfig
+++ b/patches/defconfig
@@ -1,17 +1,13 @@
 #
 # Automatically generated file; DO NOT EDIT.
-# Linux/arm 4.1.22 Kernel Configuration
+# Linux/arm 4.1.33 Kernel Configuration
 #
 CONFIG_ARM=y
 CONFIG_ARM_HAS_SG_CHAIN=y
...
>>> cut, let me know if you need it <<<
...
diff --git a/patches/bb300/0001-reset-is_reset-and-clear_reset-api-s.patch b
/patches/bb300/0001-reset-is_reset-and-clear_reset-api-s.patch
new file mode 100644
index 000..9fd5977
--- /dev/null
+++ b/patches/bb300/0001-reset-is_reset-and-clear_reset-api-s.patch
@@ -0,0 +1,94 @@
+From c2fcba10eac12885dbe50c8fd5ce5d0653e92cf3 Mon Sep 17 00:00:00 2001
+From: Daniel G 
+Date: Fri, 7 Oct 2016 09:10:33 +0200
+Subject: [PATCH 1/3] reset: is_reset and clear_reset api's
+
+Enhance reset framework with "is_reset" and "clear_reset" api's.
+is_reset - used by client driver to know reset status
+clear_reset - used by client driver to clear reset status
+
+These functionalities may sometimes be achieved by using existing api
+like deassert. But in some scenarios, steps to achieve reset requires
+clearing reset, deassert reset, enabling clock to module and then
+checking reset status. Here enabling clock module is coming in between
+reset procedure, hence enhance framework with additional api's.
+
+Signed-off-by: Afzal Mohammed 
+---
+ drivers/reset/core.c | 32 
+ include/linux/reset-controller.h |  2 ++
+ include/linux/reset.h|  2 ++
+ 3 files chan