Re: [beagleboard] Beagle forum has MOVED!

[Jason Kridner]

You can get forum.beagleboard.org content in your Inbox as well.

See
https://forum.beagleboard.org/t/about-the-general-discussion-category/27532
.

On Tue, Jul 6, 2021 at 12:47 PM evilwulfie  wrote:

> Why move?  I like getting this in my thunderbird inbox.
>
> On 7/6/2021 8:37 AM, Jason Kridner wrote:
>
> Please visit forum.beagleboard.org/c/general/.
>
> Previous announcement:
> https://groups.google.com/g/beagleboard/c/gXb9lqT0yfM/m/88diLWRZDgAJ
> --
> 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/0360647a-e095-46e3-a81a-7a6228a171acn%40googlegroups.com
> <https://groups.google.com/d/msgid/beagleboard/0360647a-e095-46e3-a81a-7a6228a171acn%40googlegroups.com?utm_medium=email_source=footer>
> .
>
>
> --
> 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/e9822cd8-04c9-b6cc-06c7-a25cfef698b0%40gmail.com
> <https://groups.google.com/d/msgid/beagleboard/e9822cd8-04c9-b6cc-06c7-a25cfef698b0%40gmail.com?utm_medium=email_source=footer>
> .
>


-- 
https://beagleboard.org/about/jkridner - a 501c3 non-profit educating
around open hardware computing
-- 
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/CA%2BT6QPnWgBbVpQogHDuTDodWZ%3DGnw2gQLTVXZHXnr3z63L2SKg%40mail.gmail.com.

[beagleboard] Beagle forum has MOVED!

[Jason Kridner]

Please visit forum.beagleboard.org/c/general/.

Previous announcement: 
https://groups.google.com/g/beagleboard/c/gXb9lqT0yfM/m/88diLWRZDgAJ 

-- 
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/0360647a-e095-46e3-a81a-7a6228a171acn%40googlegroups.com.

Re: [beagleboard] Beaglebone AI Device Tree Overlay syntax

[Jason Kridner]

thought i already switched to google group to read-only. i will do so. 

> On Jun 9, 2021, at 6:05 PM, Robert Nelson  wrote:
> 
> On Wed, Jun 9, 2021 at 4:03 PM John Allwine  wrote:
>> 
>> Are we still posting here or should be be posting on the Discourse forum?
>> 
>> https://forum.beagleboard.org/t/beaglebone-ai-device-tree-overlay-syntax/30044
> 
> The discourse forum should be the place.
> 
> @Jason Kridner is our 2-3 weeks migration up? ;)
> 
> -- 
> 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/48F88825-EBF0-4AC0-84AA-9A22CAD37B33%40gmail.com.

[beagleboard] This BeagleBoard Google Group is MOVING to forum.beagleboard.org

[Jason Kridner]

Please start new threads on forum.beagleboard.org/c/general/, rather than
the Google Group.

forum.beagleboard.org is running Discourse on our own dedicated server. I
feel we can better serve the needs of the community through an open source
tool we can customize as needed without asynchronous changes from Google
Groups.

We will be making the BeagleBoard Google Group read-only in about 2-3
weeks, so please try to wrap up any on-going threads while you start new
threads on forum.beagleboard.org. Please start all new threads on
forum.beagleboard.org as of now.

Announcements with roughly the same news via social media will follow in
the next few days.

Please provide feedback via https://forum.beagleboard.org/c/site-feedback.
Note that replies here will also be addressed up until the time this Google
Group goes read-only.

We have validated that e-mail-only subscriptions work. We have had some
notable issues around Google spam filters and encourage you to add
beagleboard.org to your "safe senders list"
https://forum.beagleboard.org/t/mail-link-goes-to-spam-google-chrome/29236

Answers to frequently asked questions regarding usage of the new general
discussion category will be added to
https://forum.beagleboard.org/t/about-the-general-discussion-category.

NOTE: If you are running an archiver or bridge, like gmane, spinics or
markmail, please feel free to subscribe and archive content being posted on
the new forum. Please continue to respect people's e-mail addresses and
filter them to avoid spam. Feel free to contact me (
https://beagleboard.org/about/jkridner) to assist in maintaining a
continuity of the archive.

-- 
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/CA%2BT6QPkDwWo1wsMcWPC%3DQ3g3gzw1kzysAyWQMayvn6E06fJadQ%40mail.gmail.com.

Re: [beagleboard] Re: PRU I/O max speed

[Jason Kridner]

https://pub.pages.cba.mit.edu/ring/


On Thu, Apr 22, 2021 at 11:02 AM Gerhard Hoffmann <
g...@hoffmann-hochfrequenz.de> wrote:

> I think I can read in about 3 pcs. LT2500-32 via the PRU in Software.
>
> The LT2500 ADC delivers 32 bit results via SPI, and with the capture and
>
> conversion time slots it needs 100 MHz SPI to process each 1MHz sample.
>
> The ADC feeds its data to a shift register in a Xilinx 2c64 Coolrunner.
>
> The PRU then reads it bytewise and writes the collected 32 bit words
>
> into a ring buffer in the shared RAM.
>
> Up to now I have tested 1 ADC, but bandwidth should be enough for 3,
>
> just so.
>
> regards, Gerhard
>
>
>
> Am 22.04.21 um 15:53 schrieb rpaulb...@gmail.com:
>
> I got it working, and I hope to never revisit it.  It was kind of a
> surprise.  I selected a 1MS/s 16-bit SPI ADC and assumed a 16 Mhz SPI clock
> to get the data out.  I totally missed that the ADC can’t sample, convert,
> and send at the same time, so I basically have 300nS to get my 16 bit out.
> Everything else I had done with the PRU monitored and responded to an
> external clock, so this is the first time I was generating the clock and
> sampling the incoming data.  I had noticed a previous oddity where I had
> some debugging statements (set an output pin) and when I removed them
> things stopped working.  There is definitely a speed limit.
>
>
>
>
>
>
>
>
>
>
> *From:* beagleboard@googlegroups.com 
>  *On Behalf Of *Andrew P. Lentvorski
> *Sent:* Thursday, April 22, 2021 5:01 AM
> *To:* BeagleBoard 
> 
> *Subject:* [beagleboard] Re: PRU I/O max speed
>
>
>
> I would be stunned if the GPIOs don't have synchronizer flip-flops as they
> are sampling a signal asynchronous to the 200MHz clock.  That would account
> for 2 clocks.  You probably need one extra to clock data into R31.  And
> then one clock to read R31.
>
>
>
> 50MHz is a pretty smoking speed for SPI--you normally need to start
> thinking about series termination and some basic signal integrity.  You
> normally need the clock to capture to flop directly if you want things to
> work.
>
>
>
> I suspect you probably need to use the 16-bit Parallel Capture Mode while
> feeding your clock out back as clock in.  You'll still probably be 4 clocks
> behind when the data hits R31, but the data will get *captured* by the
> PRU_CLOCKIN edge properly so the delay will now be deterministic if you
> are generating the 50MHz clock yourself.
>
>
>
> On Thursday, February 25, 2021 at 12:15:18 PM UTC-8 rpau...@gmail.com
> wrote:
>
> With a sample size of one, r31 appears to be 4 instructions behind the
> state of the pin.
>
> On Thursday, February 25, 2021 at 12:26:16 PM UTC-5 Paul Beam wrote:
>
> I am, unfortunately, bit-banging SPI with the PRU, and I seem to be
> running into a speed limit < 50 MHz I desire.  I can certainly create a
> clock that fast, but reading data seems to be delayed.  I can see on the
> logic analyzer a "0" clearly being read as a '1" so there is either a delay
> in my clock output or a delay in my input or both.  I would like to think
> that r30 and r31 are tied directly to the outside world, but now I am
> thinking there is something in between that is either clocked or just has
> significant output delays.  Anyone else encountered this?
>
> --
> 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/9GdOGgGv-eY/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/f88c700e-69c2-4ac4-bc64-d44a1715460dn%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/02f301d7377e%24d9e9e3b0%248dbdab10%24%40gmail.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/78b77aa0-0115-7281-8319-78e14b26a6ce%40hoffmann-hochfrequenz.de
> 

[beagleboard] Google Summer of Code 2021

[Jason Kridner]

https://beagleboard.org/blog/2021-03-30-students-can-submit-proposals-now-for-google-summer-of-code

BeagleBoard.org has been selected as a mentoring organization for 2021 and
the project possibilities this year, I believe, are especially interesting.
With BeagleBone AI  in production and BeagleV
 (RISC-V) and BeagleConnect
 (6lowpan subGHz wireless MCU
running Zephyr) designs available in prototypes, there’s a lot of new open
hardware looking for more open software to run. There are FPGA project
ideas and also the new PocketBeagle Grove Kit
 has some nice Python-based tutorials
using Linux where new user contributions would be rather welcome. Mentors
from the real-time audio Bela.io  team are even
participating this year!

Catch up on the latest ideas , hop on
our new forum , and join the live chat
 to start interacting with mentors and
students now! Make sure to get drafts for any proposals out on the wiki and
get community feedback to see if community members feel any project idea
could be valuable.

Final student proposals are due on April 13, so don’t delay!
-- 
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/CA%2BT6QP%3DeD-D-bFv8X2TjL%2BhZ855HkpPuwQFpR73O6R6o02NXBg%40mail.gmail.com.

Re: [beagleboard] RE: http://beagleboard.org/librobotcontrol/

[Jason Kridner]

Yes, I'm maintaining it as I have time.

Can you be more explicit in your question? What functions are you calling?

Are you using the latest version?

On Fri, Mar 19, 2021 at 2:01 PM set_  wrote:

> Hello,
>
> Is LibRobotControl still being pursued and maintained by anyone?
>
> I am asking b/c I have a BBBlue and I just wired up some motors and
> wheels. The tests all pass, i.e. except for some PRU lib.
>
> Anyway, I keep trying to use the lib. I am receiving errors.
>
> The errors are dedicated to this idea:
>
> *the function is deprecated...*
>
> Are the docs still being kept?
>
> Seth
>
> --
> 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/3dfc1b12-8697-4f84-b3b6-4b391eeda9a9n%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/CA%2BT6QP%3DFL12DE6BxmW1ecpsvcDz%2BYLy4%2BTSK230%3D2J2pxdosbQ%40mail.gmail.com.

Re: [beagleboard] Re: Beaglebone Ai overheating

[Jason Kridner]

Did you update the software? We tuned down the clock a bit to keep it from
overheating. We are working on a lower voltage operating point still.

On Tue, Mar 16, 2021 at 4:38 AM Peter Read  wrote:

>
> I have just powered up and updated my BBAI one hour after delivery of
> same.  The board shut down at 95 degC, which it reached within fifteen
> minutes of power-up!
> After waiting for cool down and restarting, I upgraded all the software as
> advised, by blowing on the heatsink during the process.
> When finished, I ran 'top' command and the board shut down after 10
> minutes - reaching 80 deg C.
> I restarted again as before without running a command and the board shut
> down on over-temperature again with only the standard processes running -
> no user commands.
>
> The unit obviously needs a fan - something not  mentioned in the
> literature.  A fan cape is purchasable for about $35, but really ???
>  I would not have bought the board had I known, since it was destined to
> become part of a remote and unattended SDR (Radio Receiver)
> and fans are a no-no.
> This does not seem to be a software or firmware fault - it is a design
> issue - and the board should be sold with fan, as it is not fit for purpose
> as-is.
> Very disappointed, as I have sunk further cost because I bought a cape for
> the thing - which is yet to arrive.
> Gah!!!
> On Wednesday, November 6, 2019 at 9:11:47 AM UTC+8 robert.sty...@gmail.com
> wrote:
>
>> Several people upgraded OS, then processor temperature speed slow down
>> stops working and processor overheats.
>>
>> For full speed operation, several people have reported using a fan,
>> particularly small 25 mm square fan mounted on heatsink, works.
>>
>> Other suggestion, huge heat-sink for fanless.
>>
>> On Tuesday, 5 November 2019 19:08:25 UTC, Nicholas Talbot wrote:
>>>
>>> I have noticed that my just purchased beaglebone AI is overheating and
>>> shutting down.  The heatsink does in fact get quite hot.  I get a message
>>> like:
>>>
>>> Message from syslogd@beaglebone at Nov  1 14:57:00 ...
>>>  kernel:[ 1219.684296] thermal thermal_zone0: critical temperature
>>> reached (95 C), shutting down
>>>
>>> Is there any update to fix this?  Maybe I got a bad chip?
>>>
>> --
> 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/2002ea0b-985c-4161-934b-567284c6b8a8n%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/CA%2BT6QPk%2BaTMbSvCqgw04KSGEAtWrCjaWy2ZXEPue3HiN9u6vDA%40mail.gmail.com.

Re: [beagleboard] Beagleboard-xM hooked up to BBT-ULCD_LITE-001 REV

[Jason Kridner]

If you load the software for BeagleBoard-xM from
https://beagleboard.org/latest-images onto a microSD card, it should boot
and give you a Linux desktop with a touchscreen.

Someone did a write-up at https://www.ietfng.org/nwf/ee/embcomp/bbxm.html,
but I tried it about a month ago and the EEPROM detection seemed to "just
work".

On Thu, Feb 11, 2021 at 9:08 PM Talleymarkstudios 
wrote:

> I am completely new to Beagleboard. And I have a Beagleboard-xM hooked up
> to BBT-ULCD_LITE-001 REV, with no clue how to use it. I have no clue where
> it came from, as it was a gift from my dad, and I have no clue if it is
> even intended to be built like this. Any help that can be offered will be
> appreciated.
>
> --
> 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/ad41a77c-c0af-4fe5-819e-cdacb40ecb6fn%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/CA%2BT6QPmTrN%3DVVfCn%3DbXeE2MuiPSNM3Y-_QB1PvvMvYgU-FH1WQ%40mail.gmail.com.

Re: [beagleboard] Google Summer of Code

[Jason Kridner]

On Wed, Feb 10, 2021 at 12:03 PM din...@gmail.com  wrote:

> I would love to see a simple "echo" rpmsg example for C66 cores using GCC
> toolchain.That would allow interesting experiments without any proprietary
> bits.


+1 on GCC!



> I tried and failed to get a simple C66 ELF from c6x-gcc to be loaded by
> remoteproc. I then saw mentions of setting up IOMMU in the linux remoteproc
> driver and gave up :)
>

oh no. I hope there’s not too much magic in the OpenCL stuff.


>
> Regards,
> Dimitar
>
> On Wednesday, February 10, 2021 at 4:49:49 PM UTC+2 Daniel Block wrote:
>
>> 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...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/beagleboard/CAK8RMs3X_7pLpMC%2BHkhM0V91jwNRQuMs8aZCQHHN3b0vvB2Q0w%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/beagleboard/CAK8RMs3X_7pLpMC%2BHkhM0V91jwNRQuMs8aZCQHHN3b0vvB2Q0w%40mail.gmail.com?utm_medium=email_source=footer>
>>> .
>>>
>> --
> 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/1e98dc57-3904-4887-883f-c3b6a6b870c6n%40googlegroups.com
> <https://groups.google.com/d/msgid/beagleboard/1e98dc57-3904-4887-883f-c3b6a6b870c6n%40googlegroups.com?utm_medium=email_source=footer>
> .
>
-- 
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/CA%2BT6QPkrmq6QA4Uo8ZxWuVNkmNBG%3D8eCBuOv5ExoE_7Gvp91YQ%40mail.gmail.com.

Re: [beagleboard] Google Summer of Code

[Jason Kridner]

On Wed, Feb 10, 2021 at 9:49 AM Daniel Block  wrote:

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

Well, looking at how the PRU stuff works could be a great way to getting
into the C66x stuff. I think we ship with the TI toolchain. A couple of the
remoteproc endpoints are for the C66x DSPs. Look at the cloud9-examples PRU
code and Makefile.


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

That’d be a great project starting point.

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

Getting started should probably include both the OpenCL stuff and a more
raw remoteproc/shared-mem/rpmsg approach.

Look at the TIDL examples in cloud9-examples for the OpenCL make I setup.



>  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
>> <https://groups.google.com/d/msgid/beagleboard/CAK8RMs3X_7pLpMC%2BHkhM0V91jwNRQuMs8aZCQHHN3b0vvB2Q0w%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
> --
> 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
> <https://groups.google.com/d/msgid/beagleboard/CAMTPGNaAps%2BP4Ef%3D-uKe7cpA9_OY%2B_C8ZgTBa0CV0-ntRn5UKQ%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
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/CA%2BT6QPnQLjGb4EucQKgx6-TN_MF5ZGtFeih-abSyOQ1JiexYGw%40mail.gmail.com.

[beagleboard] Google Summer of Code

[Jason Kridner]

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.

[beagleboard] New BeagleV GoogleGroup

[Jason Kridner]

Based on (albeit somewhat limited, but pointed) feedback, I have taken up 
the suggestion of moving BeagleV discussion to another Google Group.

https://groups.google.com/g/beaglev

While I have some concerns it will hurt building critical mass of that 
discussion, it will certainly reduce noise for those only interested in the 
TI/ARM-based boards. Hope this works for you!

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

[beagleboard] BeagleV google group

[Jason Kridner]

groups.google.com/g/beaglev

I think BeagleV is different enough that having a separate group will make 
things less confusing.

-- 
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/4bb2dd27-a42e-4f97-8716-43a6d5b23ef8n%40googlegroups.com.

[beagleboard] Re: SRe: BeagleBoard.org(R) and Seeed Introduce the First Affordable RISC-V Board Designed to Run Linux

[Jason Kridner]

On Friday, January 15, 2021 at 9:40:40 AM UTC-5 KenUnix wrote:

> Is there going to be a case for t his? Thanks.


Perhaps not this version, but certainly for the production version in 
September.
 

>
>
> On Thursday, January 14, 2021 at 10:43:58 AM UTC-5 Jason Kridner wrote:
>
>> In case you haven't seen this already, 
>> https://beagleboard.org/blog/2021-01-13-beagleboard-org-and-seeed-introduce-the-first-affordable-risc-v-board-designed-to-run-linux
>>  
>> (short link: https://bbb.io/@2698). 
>>
>> There is a form link on BeagleV.org to register your interest. A shortcut 
>> to that link is here: https://forms.gle/Ri94XnCEZUnju4it9
>>
>> Note, this is not a replacement for the BeagleBoard or BeagleBone line of 
>> products and we still have a roadmap for TI Industrial ARM processors and 
>> other fun stuff. This is meant to satisfy a frequent community request to 
>> provide more cost-effective access to RISC-V computers designed for running 
>> Linux for people seeking to advance the state of open source for RISC-V.
>>
>> -- 
>> 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/437dd6a1-a2ef-4561-a5ff-c3e27aa21f4en%40googlegroups.com.

Re: [beagleboard] BeagleV?

[Jason Kridner]

On Thu, Jan 14, 2021 at 5:45 PM Raul Rathmann 
wrote:

> I totally get it on the Beaglebone form-factor and continuing support for
> it. I have Beaglebone AI format-type solutions I have to support on the
> software side and the Mech. and Elec. engineers in my group would probably
> devise some kind of torture system and install it in my cubicle if I pushed
> a radically different form factor "just because". I was really only
> parroting what I've observed with the other groups like RPi and the Jetson
> stuff - they seem to be partly going for an industrial direction in a "mass
> quantities" kind of way, doesn't mean that's what the Beagleboard group
> should do at all.
>
> The possibility of expanded I/O would be great to see and PCIe would be
> fantastic even over a "non-standard" connection.
>

Really pushing Type-C for that, though it isn’t daughterboard friendly.

I'd also add a vote for a populated JTAG connection, or at least one that
> one that isn't too involved to install.
>

Choosing TagConnect for future boards. A bit more expensive to add an
adapter, but at least no soldering.


>
> On Thursday, January 14, 2021 at 4:31:32 AM UTC-8 Jason Kridner wrote:
>
>> Yeah, the PRUs are there, but hidden I guess for "support" reasons. I
>> think TI isn't offering the firmware loads to support industrial protocols
>> on this chip to the public. TI already makes a carrier board SOM.  I want
>> to make sure those people who have invested in the BeagleBone form-factor
>> get pay-off with upgraded processing. I'm sure there is lots more that
>> could be done with the TDA4VM. I'm going to try to see if I can at least
>> get a fairly high-speed ribbon cable brought off, but things like PCIe will
>> need to be muxed across type-C in this form-factor as best I can tell.
>>
>> On Wed, Jan 13, 2021 at 9:19 PM Daniel Kulp  wrote:
>>
> 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 <
>>>> vinicius...@gmail.com> 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

[beagleboard] BeagleBoard.org(R) and Seeed Introduce the First Affordable RISC-V Board Designed to Run Linux

[Jason Kridner]

In case you haven't seen this already,
https://beagleboard.org/blog/2021-01-13-beagleboard-org-and-seeed-introduce-the-first-affordable-risc-v-board-designed-to-run-linux
(short link: https://bbb.io/@2698).

There is a form link on BeagleV.org to register your interest. A shortcut
to that link is here: https://forms.gle/Ri94XnCEZUnju4it9

Note, this is not a replacement for the BeagleBoard or BeagleBone line of
products and we still have a roadmap for TI Industrial ARM processors and
other fun stuff. This is meant to satisfy a frequent community request to
provide more cost-effective access to RISC-V computers designed for running
Linux for people seeking to advance the state of open source for RISC-V.

-- 
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/CA%2BT6QPnUB-yGyxsOVv%3DiDWANULpFkepgfkjtsAvB4fdratuk5g%40mail.gmail.com.

Re: [beagleboard] BeagleV?

[Jason Kridner]

Yeah, the PRUs are there, but hidden I guess for "support" reasons. I think
TI isn't offering the firmware loads to support industrial protocols on
this chip to the public. TI already makes a carrier board SOM.  I want to
make sure those people who have invested in the BeagleBone form-factor get
pay-off with upgraded processing. I'm sure there is lots more that could be
done with the TDA4VM. I'm going to try to see if I can at least get a
fairly high-speed ribbon cable brought off, but things like PCIe will need
to be muxed across type-C in this form-factor as best I can tell.

On Wed, Jan 13, 2021 at 9:19 PM Daniel Kulp  wrote:

> 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 <
>> vinicius...@gmail.com> 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 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 sh

Re: [beagleboard] BeagleV?

[Jason Kridner]

On Wed, Jan 13, 2021 at 4:23 PM 'Mark Lazarewicz' via BeagleBoard <
beagleboard@googlegroups.com> wrote:

> 15.4 support that's huge. Is the TI SUB GHz radio on  a cape?
> Our neighborhood gas meters were recently updated with a product I worked
> on that product had  an older TI radio and was based on a Renesas
> controller.
> This alternative positions TI to possibly offer a turn key replacement for
> that product  beyond porting the app to Linux.
>

Are you talking about BeagleConnect Freedom? I am working on a cape that
would include the CC1352 as well, but, for now, you'd connect the
BeagleConnect Freedom to any Linux board over USB and run the wpanusb
driver (still needs to be mainlined). So, the BeagleConnect Freedom can act
as either a device or a gateway. Right now, they are 2 different firmware
loads.


>
> TI support is way way better than Renesas and that product had reset
> issues I strongly suspect were the Microcontroller
>
> Sent from Yahoo Mail on Android
> <https://overview.mail.yahoo.com/mobile/?.src=Android>
>
> On Wed, Jan 13, 2021 at 12:42 PM, 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.henselm...@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+unsubscr...@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://groups.google.com/d/msgid/beagleboard/3cc933a3-b647-4fe4-b24b-9ba03c478f1fn%40googlegroups.com?utm_medium=email_source=footer>
> .
>
>
>
> --
> 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 receiv

Re: [beagleboard] BeagleV?

[Jason Kridner]

On Wednesday, January 13, 2021 at 4:08:35 PM UTC-5 vinicius...@gmail.com 
wrote:

> Hi Jason
>
> The idea on the BBAI is change from am5729 to TDA4VM ?
>

Yes.

I think the things to figure out are if we can:
* Increase RAM
* Add CSI signals/connectors
* Bring PCIe over Type-C as an alt mode (some devices are just better 
interfaced over PCIe than USB) 
* Add USB-SS to the Type-A connector
* Add an alternate power connector (capes and USB shouldn't be the only way 
to power, but barrels are too big for this design)
 

>
> Best regards
>
> Sent from my iPhone
>
>
> Em 13 de jan. de 2021, à(s) 15:42, Jason Kridner  
> escreveu:
>
> 
>
> 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://groups.google.com/d/msgid/beagleboard/3cc933a3-b647-4fe4-b24b-9ba03c478f1fn%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>
>
> -- 
> 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...@googlegroups.com.
>
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/CA%2BT6QP%3D5vSi9%3DTn%2B2n6wT%3Dkp09sLCGmMT3dv-Q6kdzmWOD8FBQ%40mail.gmail.com
>  
> <https://groups.google.com/d/m

Re: [beagleboard] BeagleV?

[Jason Kridner]

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.henselm...@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+unsubscr...@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/CA%2BT6QP%3D5vSi9%3DTn%2B2n6wT%3Dkp09sLCGmMT3dv-Q6kdzmWOD8FBQ%40mail.gmail.com.

Re: [beagleboard] Beaglebone bootloader

[Jason Kridner]

On Mon, Jan 4, 2021 at 8:13 AM Abdallah Rashed 
wrote:

> I was thinking in developing bootloader for beaglebone as kind of self
> study and getting better in the field , do you think it worth the effort
>

It is a very useful lesson.


> and is it feasible?
>

For sure. The Staterware bare metal library has been useful, though it
hasn't been maintained.


> I understand in this case it would replace the ubot right?
>

Or, you could just run a bare metal app. Up to you. U-boot start-up is
simpler to understand than the Linux kernel start-up, but neither is super,
super simple.

I'd probably start by creating an app I could load from u-boot itself and
run it to have the hardware do something like blink an LED or otherwise
tell me it is running. Then, I'd start to look at how I format that same
application to be loaded by the ROM bootloader.

Doing something in ARM assembly could be especially empowering, because
then you can decipher the actual opcodes in the binary image you create.
You can also have the compiler generate assembly listings from C files,
which will give you a starting point for creating your own assembly or at
least help you map instructions to the binary image. If you are trying to
understand how things work at the lowest levels, this can really give you
confidence the processor is running exactly what you are providing it, with
some caveats.


> Did anyone try it before or has any guide or materials for that and how to
> start?
>

Doubt anyone has done a really nice write-up, but I could be wrong.

Check out https://diydrones.com/profiles/blogs/booting-up-a-beaglebone-black

Of course, most people looking at bare metal will encourage a JTAG
connection.

Such as
https://www.twosixlabs.com/running-a-baremetal-beaglebone-black-part-1/.

That's why I suggest trying to run a very simple application that gives
some indication, like toggling a GPIO, in u-boot. Even there you have to
deal with the fact a lot of things get setup ahead of time.

Getting a write-up that doesn't require JTAG would be great.


Another super example to look at is https://github.com/ravikp7/BeagleBoot.
It uses the ROM bootloader to load an application over USB. Unfortunately,
the application loaded as part of the example is rather complicated
(u-boot, kernel, etc.), but the fact you are booting over USB rather than
uSD/eMMC gives you some live interaction such that you have confidence the
processor is looking at the code you are providing. Breaking this down a
bit, you can see the original project it was based on,
https://github.com/ungureanuvladvictor/BBBlfs.


The advantage of USB is that it doesn't require any additional hardware
with a BeagleBone Black. However, the absolutely most direct way of
bootloading in a way where you can observe the initial interactions is over
the UART. Check out
http://labs.isee.biz/index.php/Firsts_steps_with_AM335x#UART_recovery_boot
for an example. Again, the example uses a complicated application (u-boot).


Perhaps the very best write-up I've seen is
https://octavosystems.com/app_notes/bare-metal-on-osd335x-using-u-boot/.
Even though it talks about the OSD3358, that is based on the same circuit
used on the BeagleBone Black.

Good luck and keep us informed. Be sure to reach out on #beagle on
irc.freenode.net if you get stuck. I'm 'jkridner' there.

-- 
> 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/CADA%3DDiLhpgCSJ0Ogj8tEqq%2BmqPgAdyH%3DteoY0sje%3D7JGKs%3DZbw%40mail.gmail.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/CA%2BT6QP%3DrKKAixi95uzEGmmqc2ngdcop8hemj4ZRwoXe8DRcELg%40mail.gmail.com.

Re: [beagleboard] 64 -bit beaglebone

[Jason Kridner]

There are multiple 64-bit BeagleBone projects in the works. Nothing
available at the moment.

On Fri, Nov 20, 2020 at 3:54 AM Pankaj Joshi  wrote:

> Hi,
> Do you know any of the BBC 64-bit with quad-core.Please let me know if
> anyone knows
>
> 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/79a5762b-ac90-422c-b100-626442aa32acn%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/CA%2BT6QPkjU3ZwyoBg8t82iNQ_0J7i5mjgxjex3zqPvmRTqs0E2g%40mail.gmail.com.

Re: [beagleboard] Re: Latest Image - Summer 2020 Release - RC2 (GSOC stuff)

[Jason Kridner]

Blocking items I know about:
* BeagleBone AI rev A2 SuperSpeed USB verification - haven't debugged why
it may be slower
* PocketBeagle cape overlay support

I think we need to address items at
https://github.com/beagleboard/Latest-Images/milestone/2 and then a release
can finally be made.

Fortunately or unfortunately, there has been a lot of development and it is
taking some time for things to settle.


On Fri, Nov 20, 2020 at 9:32 AM jose...@gmail.com 
wrote:

> Hi Robert,
>
> Is there an updated schedule for the next stable image release?
> I assume there are some blocking issues that prevented the Summer release
> to took place, inittialy postponed to Fall, acording to the
> Latest-image-testing wiki.
> May we know what issues are preventing a new stable release?
>
> Best regards,
> José Gonçalves
>
> A quarta-feira, 2 de setembro de 2020 à(s) 18:21:04 UTC+1,
> jose...@gmail.com escreveu:
>
>> Hi Robert,
>>
>> The wiki page at https://elinux.org/Beagleboard:Latest-images-testing
>> has some outdated info on the Sumer 2020 Release.
>> While the RC2 is marked (properly) has released in August 26, it says the
>> final version was released in August 3rd!
>>
>> Best regards,
>> José Gonçalves
>>
>> A quarta-feira, 26 de agosto de 2020 à(s) 15:45:24 UTC+1, RobertCNelson
>> escreveu:
>>
>>> Hi Everyone,
>>>
>>> So RC2 is now out, all the "wl18xx" based devices now have working
>>> Bluetooth again, config: CONFIG_SERIAL_SC16IS7XX completely broke it..
>>>
>>> I'm planning to do the "full" burn in testing this Saturday, my targets
>>> are:
>>>
>>> Windows 10 (2004)
>>> Debian
>>> Mac OS (Mojave, Catalina)
>>>
>>> Here is what i did last 'time' which took about a full day of none stop
>>> testing:
>>>
>>> https://github.com/beagleboard/Latest-Images/issues/26
>>>
>>> Please reply with more things to verify..
>>>
>>> Now GSOC students, please reply with still un-merged patches and what
>>> kernel they are targeting. I'd like to get all these projects built
>>> and merged by this Thursday, then we can do a final "RC" next week,
>>> that may turn into "FInal"..
>>>
>>> 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/f65a9152-7368-43d0-9f9d-e410e9a66c73n%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/CA%2BT6QPnY1Hv-FuXG8dwB%2B3tZyLqx6jmz8h1v7KryNb-srXvGyQ%40mail.gmail.com.

Re: [beagleboard] Saving content from TI Wiki

[Jason Kridner]

I think TI would be supportive in giving us copies of relevant content. I
barely got started copying content over to eLinux.org--that seems like the
best host to me.

If you look at my latest contribution history (
https://elinux.org/Special:Contributions/Jkridner), you can see a few pages
I started to copy over to the Beagleboard space on elinux.org.

You can also see the assets didn't get moved over by me copying and pasting
the text, obviously. I tried for a few minutes to think of a way to
automate and didn't arrive at anything.

Remind me the next few days to provide the list I got on potential content.
Then, others can add to that list if we missed anything. Mine is based on a
spreadsheet I got from TI.

If anyone has good suggestions on automating the move, please let me know.


On Sat, Oct 10, 2020 at 2:13 PM din...@gmail.com  wrote:

> On Saturday, October 10, 2020 at 12:35:36 AM UTC+3 RobertCNelson wrote:
>
>> On Fri, Oct 9, 2020 at 4:01 PM din...@gmail.com 
>> wrote:
>> >
>> > Dear Beagleboard.org overseers,
>> >
>> > The TI Processors Wiki is being shutdown. I think valuable information
>> would be lost that cannot be found in TRMs or Datasheets. For example, the
>> following opcodes information was crucial while porting the GNU assembler
>> for PRU:
>> > https://processors.wiki.ti.com/index.php/Programmable_Realtime_Unit
>> >
>> > Are you willing to transfer that and similar content to beagleboard.org
>> ? Wikimedia page sources can be mostly automatically translated to MarkDown
>> or HTML. So content could be served as a static page, with no need to host
>> dynamic Wiki.
>>
>>
>> I don't think we could get access to that..
>>
>
> Wikimedia page source is still available:
> https://processors.wiki.ti.com/index.php?title=Programmable_Realtime_Unit=edit
> . EOL is scheduled for December.
>
>
>>
>> http://web.archive.org/web/20190916141936/http://processors.wiki.ti.com:80/index.php/Programmable_Realtime_Unit
>>
>> 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/0cf3f8f1-bcec-459d-ac02-a8b81773f118n%40googlegroups.com
> 
> .
>


-- 
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/CAK8RMs1zFgWoeouFEJuXa59F3WM%2BND1srYhABMbRcN%3DyrdftRw%40mail.gmail.com.

Re: [beagleboard] BBAI cape EEPROM pin usage section

[Jason Kridner]

On Wed, Sep 9, 2020 at 8:11 AM Diane Miller 
wrote:

> Are there any plans to implement this in the future?
>

No.


> If not, is the device tree the only way to set up the pin muxing?
>

U-boot sets up the device tree and initial pin mux. Using the device tree
configured by u-boot is the simplest way to set the pinmux, but you can
also change the default pin muxing in u-boot outside of the device
tree--just make sure the kernel doesn't change it by having a device tree
that doesn't match.


>
> On Tue, Sep 8, 2020, 5:23 PM Robert Nelson 
> wrote:
>
>>
>>
>> On Tue, Sep 8, 2020, 5:19 PM Diane Miller 
>> wrote:
>>
>>> Where can I find the format of the cape EEPROM pin usage section for the
>>> BeagleBone AI? I need to know the ordering of the pins as well as the
>>> format of each pin's 16-bit field.
>>>
>>> From what I could figure out on my own the BBB pins are in GPIO order,
>>> with the non-muxed AINx pins at the end of the table. Can anyone confirm
>>> that this same ordering applies to the BBAI? How are the a/b pins handled
>>> (such as 9.19a/b)?
>>>
>>> It seems that the BBAI pin bitfield's format must differ from the BBB
>>> since the AM572x has a 4-bit muxmode field, whereas the AM335x has only 3
>>> bits. Has the BBAI's EEPROM format been posted anywhere?
>>>
>>
>>
>> This feature of the spec was never utilized.
>>
>>
>>
>> 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/9Y37l-T19As/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/CAOCHtYjhJstTWhvVVpbA8Kw%3DfGzC8T5%2B%2B-6sU-Q%3DnO8bdqUA5w%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/CAGmogxd8T5DwSCHwWs8HrG0j%2Bojmg6cHgtJAkUMjivmOA8jF-A%40mail.gmail.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/CA%2BT6QPkbQSm16hRzN_YB%3DnR8s0098ZHOZ12xzpJ2FwUW%3DyKYQw%40mail.gmail.com.

[beagleboard] Cool mikroBUS presentation at Linux Plumbers Conference!

[Jason Kridner]

See https://youtu.be/A3NyEjB5O38 for an early glimpse at the demo.

This will be presented at Linux Plumbers Conference on tomorrow, August
27th, by Vaishnav and is very much worth checking out.

Track information "You, Me, and IoT Two" microconference track:
https://linuxplumbersconf.org/event/7...

Latest RFC Patch: https://lore.kernel.org/patchwork/pat...

Instructions for Reproducing the Work:
https://github.com/vaishnav98/manifes...

For more information and discussions: https://elinux.org/Mikrobus


This was somewhat tipped on
https://www.phoronix.com/scan.php?page=news_item=MikroBUS-Linux-Driver-Patches
based on the LKML RFC, but it seems regular readers of Phoronix don't
really get what life is like for embedded Linux developers. This really is
a *big deal* and just part of what BeagleBoard is working on to greatly
simplify the life of "IoT" developers.

Stay tuned and check out the free live stream on YouTube!
https://www.youtube.com/c/LinuxPlumbersConference/videos

Also, be sure to check out the rest of the track (
https://linuxplumbersconf.org/event/7/sessions/89/#20200827), especially
Chris Friedt's talk on Greybus!
https://linuxplumbersconf.org/event/7/contributions/814/

-- 
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/CA%2BT6QPkaQfYQE9-uetZUBJDFUwwGok6zR0XEVgzR2t3iHWJ-Fg%40mail.gmail.com.

[beagleboard] Re: [beagle-alpha] Latest Image - Summer 2020 Release - RC2 (GSOC stuff)

[Jason Kridner]

Would anyone else like a u-boot patch for PocketBeagle such that EEPROMs at
address 0x57 on either I2C1 or I2C2 would have cape identifiers such that
GamePup, TechLab, and Grove PocketBeagle Capes would automatically load
overlays?

On Wed, Aug 26, 2020 at 10:45 AM Robert Nelson 
wrote:

> Hi Everyone,
>
> So RC2 is now out, all the "wl18xx" based devices now have working
> Bluetooth again, config: CONFIG_SERIAL_SC16IS7XX completely broke it..
>
> I'm planning to do the "full" burn in testing this Saturday, my targets
> are:
>
> Windows 10 (2004)
> Debian
> Mac OS (Mojave, Catalina)
>
> Here is what i did last 'time' which took about a full day of none stop
> testing:
>
> https://github.com/beagleboard/Latest-Images/issues/26
>
> Please reply with more things to verify..
>
> Now GSOC students, please reply with still un-merged patches and what
> kernel they are targeting. I'd like to get all these projects built
> and merged by this Thursday, then we can do a final "RC" next week,
> that may turn into "FInal"..
>
> Regards,
>
> --
> Robert Nelson
> https://rcn-ee.com/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Beagle Alpha" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagle-alpha+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagle-alpha/CAOCHtYhCWi_pdmVABn4H8tK%2BxWg599ncCiim4CV0EPYCtRjyyA%40mail.gmail.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/CA%2BT6QPkQ7syS2Cp2OVAgnFBF%2BidWaf%3DiT6%3D5X7%3DqR_XCm%3D7SiQ%40mail.gmail.com.

Re: [beagleboard] HS tariff code for BeagleBoard products

[Jason Kridner]

I need to research a "best" answer. The export classification there is
mostly regarding encryption regulation and not taxation. I'm a bit overdue
to do a good scrub of both.

On Fri, Jul 31, 2020 at 9:33 AM Robert Nelson 
wrote:

> On Fri, Jul 31, 2020 at 6:10 AM Giulio Moro  wrote:
> >
> > Hi there,
> > I was wondering what ls the HS tariff code for the BeagleBoard products?
> > Thanks,
> > Giulio
>
> This is always a fun subject, most should be here:
>
> https://github.com/beagleboard/beaglebone-black/tree/master/regulatory
>
> Regards,
>
> --
> Robert Nelson
> https://rcn-ee.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/CA%2BT6QPkRAoUdnQ9CZBnmV5Ek0QJavm6peWbfzN_9-OggizCoFg%40mail.gmail.com.

Re: [beagleboard] How to create /dev/spidev2.0 for beaglebone AI?

[Jason Kridner]

On Wed, Jul 22, 2020 at 7:48 AM  wrote:

>
> How to create /dev/spidev2.0 for beaglebone AI?
>

This is in-work as a Google Summer of Code project.

Deepak's overlay is here:
https://github.com/lorforlinux/bb.org-overlays/blob/bone_spi/src/arm/BONE-SPI1_0-00A0.dts

The critical section is:

 {
  P9_28_pinmux { pinctrl-0 = <_28_spi_cs_pin>; }; /* CS */
   P9_30_pinmux { pinctrl-0 = <_30_spi_pin>; }; /* MOSI */
   P9_29_pinmux { pinctrl-0 = <_29_spi_pin>; }; /* MISO */
   P9_31_pinmux { pinctrl-0 = <_31_spi_sclk_pin>; }; /* CLK */
};

_spi_1_0 {
   status = "okay";
   spi-max-frequency = <1600>;
   spi-cpha;
};

It depends on his changes to the base board device tree or it'll fail to
boot:
https://github.com/lorforlinux/BeagleBoard-DeviceTrees/blob/compatibility/src/arm/bbai-bone-buses.dtsi

The critical section is:

 {
   #address-cells = <1>;
   #size-cells = <0>;

   bone_spi_1_0: channel@0 {
 #address-cells = <1>;
 #size-cells = <0>;
 compatible = "spidev";
 symlink = "bone/spi/1.0";
 reg = <0>;
   };

   bone_spi_1_1: channel@1 {
 #address-cells = <1>;
 #size-cells = <0>;
 compatible = "spidev";
 symlink = "bone/spi/1.1";
 reg = <1>;
   };
};

That is, if I understand which port your are trying to expose. Some
background and pins are show at
https://elinux.org/Beagleboard:BeagleBone_cape_interface_spec#SPI.

This doesn't have all the background and instructions I'd like, but I
believe Deepak will be updating it.

Best to have a serial cable and know how to deal with a hung-up boot, but
might be a good place to start to use spidev on BeagleBone AI.

Otherwise, this is scheduled for the August tri-annual software image
release, which isn't that far away 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/de6d58b0-2f0c-420d-88ee-c90c9e3c4f7eo%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/CA%2BT6QPmZ%3D71rh5hHqd-U7x93g7TaKNHFnnFwK7EJSzpqh3zc%2BA%40mail.gmail.com.

[beagleboard] Re: BeagleBone Black Industrial?

[Jason Kridner]

Very much in production, but we changed manufacturers from Embest to Seeed.
Distributors are transitioning stock.

btw, I put the support/community list in copy on my response and removed
your name.


https://www.digikey.com/product-detail/en/beagleboard-by-seeed-studio/102110423/1597-102110423-ND/12342853

https://www.mouser.com/ProductDetail/BeagleBoard-by-Seeed-Studio/102110423?qs=%2Fha2pyFaduhdfTYrXET7yAX9nICxVolfDXzHZgZ5%252BZBlGTrwuflCKNvMgxfxnagBnu435K2FoyA%3D

https://www.newark.com/element14/bbone-black-ind-4g/silicon-manufacturer-texas-instruments/dp/76Y2810?ost=beaglebone+black+industrial


Stock should arrive soon.

On Mon, Jul 20, 2020 at 9:57 AM someone wrote:

> Hi Jason,
>
> I’m trying to source the BeagleBone Black Industrial board (with increased
> temperature ratings) and I’m having trouble finding it.  Is this board
> still in production?  Any insights would be much appreciated.
>
> Thanks!
>
>
> --
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/CA%2BT6QPkMpx%2BF%2BkLagrhDwoeMHGEMmQ4cAw2_u3veZ_Kz%2B3SZHw%40mail.gmail.com.

Re: [beagleboard] Re: BB Ai dead after first upgrade

[Jason Kridner]

If you can describe a bit more about what happened, I can work to analyze
the failure and provide a replacement.

On Thu, Jun 25, 2020 at 10:51 AM jonnymo  wrote:

> Can you describe what you did to upgrade the BB AI?
>
> How are you powering the board?
>
> Cheers,
>
>
> On Thu, Jun 25, 2020 at 7:40 AM Robert Forsyth <
> robert.styles.fors...@gmail.com> wrote:
>
>> I assume you tried another SD-Card with another image (
>> https://beagleboard.org/latest-images) for AM5729
>>
>> On Thursday, 25 June 2020 12:55:50 UTC+1, Raf wrote:
>>>
>>> Hello,
>>> I purchased a BB Ai from DigiKey. It arrived today. I updated, connected
>>> to wireless and reboot. The unit does nothing but get hot, only the LED
>>> that turns on is the one next to the USB C connector. any idea? can I get
>>> it returned, exchanged or something?
>>>
>>> thx
>>>
>> --
>> 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/942f24e8-ea21-4a55-92f1-00b72868e189o%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/CAG99bkpgmoB7Kayc-VfQhd%3D8Pf%3DUo7OWOCuWZPBhF3hLs_hogA%40mail.gmail.com
> 
> .
>


-- 
https://beagleboard.org/about - 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/CA%2BT6QPmpA1d4txfnVks3QzjoE6NDYt0ej0_8JVrGSnK6rFJ8zQ%40mail.gmail.com.

Re: [beagleboard] Re: requesting information on pcb files for beaglebone black and beaglebone ai

[Jason Kridner]

The only part that shouldn't match is the logo (which we have stripped from
the source). We have, at times, taken the source design and handed it off
for manufacturing to be certain it matches. However, in this case, we
relied on Embest to provide us with matching design files to the production
hand-off. We can probably ask them to confirm the files are correct. I'm
open to any further suggestions you have to validate it. Otherwise, we will
validate when the A2 design is released from Seeed. I'm happy to provide
the pre-release sources, but realize they aren't yet validated in hardware,
so you'd be no better off.

On Mon, Jun 15, 2020 at 8:41 PM jimvr  wrote:

> Jason,
>
> Well, I was wrong, the dsn and brd files that are here, are not matching
> up.
> https://github.com/beagleboard/beaglebone-ai/tree/master/HW
>
> I do see the A2 proposed changes, and I understand that the board files
> for that is not  yet available.
>
> Can you confirm that the design set that is up in the github, match?  It
> could be just our conversion went wrong, and we need to figure that out.
> The schematic seems correct to the PDF that we have from the same github.
>
> On Saturday, June 13, 2020 at 1:29:30 PM UTC-7 jimvr wrote:
>
>> Jason,
>>
>> One of our friends has Allegro and we were able to convert, so good
>> there. However, I noted that the files on GitHub are for A1, is there a
>> board set package for A2, or errata from A1 to A2 that can be shared so
>> that we can be sure to understand what was left off?
>>
>> I am having some IO pin issues right now, and it just seems like my A1
>> board is missing a signal or two to the cape header.  Plus I can see that
>> the JTAG port is not right, two wires perhaps needed?
>>
>> And if you are happy with this, I can send you the Altium project when
>> done, and you can post that up?
>>
>> Share?
>>
>> On Saturday, June 13, 2020 at 9:01:41 AM UTC-7 jimvr wrote:
>>
>>> Jason,
>>>
>>> We also are interested in the Altium file export for the BBAI Rev A2, if
>>> you can do that export.  According to what I read, there are two methods
>>> from this Altium post:
>>> https://www.altium.com/documentation/altium-designer/allegro-import-ad
>>>
>>> *Allegro Binary PCB Design Files*
>>>
>>> The Import Wizard can directly import and translate Allegro PCB files
>>> (*.brd) to Altium Designer PCB files (*.PcbDoc) when the Wizard has local
>>> access to an Allegro PCB editor installation – that is, when a licensed
>>> copy of Allegro PCB is installed on the same machine as Altium Designer.
>>>
>>> The Wizard uses Allegro’s included file conversion capabilities to
>>> configure the design data for processing by the importer.
>>>
>>> *Allegro ASCII Extracted Design Files*
>>>
>>> Altium Designer’s Import Wizard can import and translate ASCII-based
>>> Allegro PCB files (*.alg) that have been created from a licensed Allegro
>>> PCB installation. The ASCII PCB design files are extracted from native
>>> Allegro PCB files (*.brd) by Allegro’s included file converter
>>> (extracta.exe), which is called by a special batch file supplied with
>>> Altium Designer.
>>>
>>> Since Allegro binary-to-ASCII conversion is a self-contained file
>>> process, the Allegro installation does not need to be accessed by Altium
>>> Designer. The Allegro installation can be on any machine, and is only used
>>> to generate suitable ASCII PCB design files.
>>> We have many Altium seats here, if you wanted to "use" a license to try
>>> the first method, I can create a temporary login to our license for Altium,
>>> however you will need to download and install Altium on the same machine.
>>> If you can create the .alg file set, that may help us that want to view
>>> the board in Altium.  Altium has no problem with the schematic, that was a
>>> native import within Altium.
>>>
>>> Please let us know!  You guys did a great job with that board design,
>>> and the support from your team, stellar all around.  Thanks.
>>>
>>> On Thursday, April 23, 2020 at 9:32:41 AM UTC-7 Jason Kridner wrote:
>>>
>>>> On Wed, Apr 22, 2020 at 10:35 AM Ramakrishna Bachimanchi <
>>>> bach...@jlab.org> wrote:
>>>>
>>>>> Hello,
>>>>> my name is Rama Bachimanchi and I am an electrical engineer working at
>>>>> Jefferson Lab (non-profit research organization). I have come across the
>>>>> amazing work you guys are doin

Re: [beagleboard] Re: remoteproc write to PRU over rpmsg device blocks even when set non-blocking

[Jason Kridner]

Which repo has the code that is causing problems?

I took a quick look at
https://git.ti.com/cgit/pru-software-support-package/pru-software-support-package/tree/lib/src/rpmsg_lib/pru_rpmsg.c
and it seems to be structured a fair bit differently. If the same issue had
been there, I'd recommend posting to e2e.ti.com.

Switching over to the kernel, I see the function you mention:
https://github.com/beagleboard/linux/blob/4.14/drivers/rpmsg/rpmsg_pru.c#L106-L129

The driver isn't upstream yet:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/rpmsg

The post to a public list seems to be here:
* https://patchwork.kernel.org/patch/10795751/

The development tree seems to be here:
* https://git.ti.com/cgit/rpmsg/rpmsg/

The code seems the same in the latest development branch:
* https://git.ti.com/cgit/rpmsg/rpmsg/tree/drivers/rpmsg/rpmsg_pru.c#n108

Er, I guess that is an example of doing it right and the issue is here?
* https://git.ti.com/cgit/rpmsg/rpmsg/tree/drivers/rpmsg/rpmsg_pru.c#n142

Since it isn't upstream, I'd think an e2e post might be OK, but it might be
more productive to reply to the latest post on linux-omap:
*
https://lore.kernel.org/linux-omap/e97f7bfc-a3c2-92a9-953e-572d9438d...@ti.com/

Copy Jason Reeder, Anthony F. Davis and Suman Anna. Not sure why it has
been so long between revision posts.

Personally, I don't see any harm in modifying the _write code with a fifo
check on O_NONBLOCK.

On Mon, Jun 22, 2020 at 2:01 AM Andrew P. Lentvorski 
wrote:

> Nobody knows where I should file this bug?
>
> On Saturday, June 6, 2020 at 6:34:26 PM UTC-7, Andrew P. Lentvorski wrote:
>>
>> It appears that the problem is in rpmsg_pru.c.
>>
>> rpmsg_pru_read has the following code:
>>
>> if (kfifo_is_empty(>msg_fifo) &&
>> (filp->f_flags & O_NONBLOCK))
>> return -EAGAIN;
>>
>>
>>
>> rpmsg_pru_write presumably needs a similar piece of code with
>> kfifo_is_full() or it needs to look for O_NONBLOCK and then use
>> rpmsg_trysend instead of rpmsg_send.
>>
>> Unfortunately, I've got nowhere near the Linux kernel programming chops
>> to debate the implications of that.
>>
>> Presumably, I need to file a bug somewhere?
>>
>> 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/2c824e98-015d-4471-b787-a8c27ceaae5fo%40googlegroups.com
> 
> .
>


-- 
https://beagleboard.org/about - 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/CA%2BT6QPkt6RSbEKb5Jx7Tb9DmSW1%3DNDipFZkA2LkcyL%3DNi%3DtVQQ%40mail.gmail.com.

Re: [beagleboard] GPIO poll for interrupts fails

[Jason Kridner]

On Fri, Jun 19, 2020 at 5:18 PM  wrote:

> Folks,
> Any help would be appreciated. I've Googled, studied, and stared for many
> hours.
> Problem: Using poll to watch a GPIO pin for change, poll returns
> "immediately" and persistently, with no value change, with POLLPRI set.
>

Please consider using libgpiod.

Background: This is a prep stage for implementing a software encoder
> counter where 2 GPIOs are connected to an external rotary encoder with
> leads A and B. I am working on a user space quadrature encoder routine
> based on the Linux driver rotary_encoder.c logic. It didn't work and I
> traced it to failing to respond to the GPIO edge events using poll. I made
> a single GPIO interrupt response demonstrator (shown excerpted below) and
> it doesn't work either. Further, it doesn't work on either Beaglebone Blue
> or Raspberry Pi 3.
> Hardware: The Blue shows ' uname -a
> Linux blue1 4.19.94-ti-r42 #1buster SMP PREEMPT Tue Mar 31 19:38:29 UTC
> 2020 armv7l GNU/Linux'
> The RPi shows ' uname -a
> Linux raspberrypi 4.19.93-v7+ #1290 SMP Fri Jan 10 16:39:50 GMT 2020
> armv7l GNU/Linux'
> Both have the same wheel encoders (Pololu Romi encoders  item #3542 or its
> 2.7v version). Both bots will correctly read the encoders. The Blue using
> the hardware encoder and the RPi via the software driver rotary-encoder.
> For this demonstrator, the Blue uses other GPIOs, specifically GP0.3 and
> GP0.4. Signal changes on these GPIOs are read correctly in the gpioN/value
> register via manual testing. The RPi uses the same GPIOs (2 or 3) as the
> encoder driver, but with the driver disabled to eliminate the competition.
> Furthermore: This has been a long standing software challenge. Googling
> shows many things one needs to know. GPIOs in sysFS are deprecated, but
> they still work. Setting an edge is what enables polling on the value to
> pick up the transition. Initial reads are required to clear initial
> spurious values. sysFS requires POLLPRI events, since POLLIN always returns
> for sysFS. sysFS always returns POLLERR which can be ignored. One must
> LSEEK on the value fd before reading the value. One must read the value,
> wanted or not.
> Notes on the demonstrator code: I have been working on a common hardware
> interface module to support bots built on Blue and RPi. I have long been
> following StrawsonDesign's librobotcontrol. This code uses a few routines
> from Strawson. One is a function to tell whether the hardware is Beaglebone
> or RPI and another to launch a thread. I don't show them here. I have
> elided all the error handling snippets, replacing them with "gripe"
> comments.
> The program follows the StrawsonDesign librobotcontrol rc_test examples.
> In this case, the main checks inputs, sets up hardware, launches a worker
> thread, then waits for the user to quit via Ctrl-C. Here the worker thread
> sets up a repeated poll loop. In the eventual quadrature application, the
> GPIO events feed the quadrature state machine of rotary-encoder.c. A short
> timeout is set for my use so the thread can be readily killed by the main
> application, independent of GPIO arrivals. The version here leaves the
> GPIOs set up upon completion so we can inspect the state of things. The
> Blue has pinmux helpers for the user GPIOs on GP0 and GP1 which are used to
> set them to GPIO mode. The RPi doesn't do that. Apparently user GPIOS are
> pre-set up.
> The code produces the same result on both machines. The read after poll
> always fails with return -1. The event is 0x0a which is POLLPRI | POLLERR.
> While it  does stream fast, I can never see a response to manually fiddling
> with the physical inputs. It never reports time out.
> OBTW, if you can see into what is going on here, think about how this
> works when I switch to SCHED_FIFO. All my bot threads run in this
> 'realtime' mode. For a software encoder that responds to GPIO interrupts, I
> think this doesn't present any problem that isn't already presented by all
> the other threads. On RPi, tho, the kernel catches the GPIO interrupts and
> runs the quadrature logic, only letting the user's poll get control after a
> complete turn of +1 or -1 occurs. I presume the rotary-encoder driver runs
> at kernel priority level, which is below the worker thread. At least, if my
> app consumes too much CPU, the kernel can't keep with its many functions,
> one of which is this driver. I have done that in the past. Let's get this
> code to work, then I'd like help thinking through this and its impact on
> CPUs like Blue and RPi. Because I'm getting lots of input about the CPU
> load of a software rotary encoder.
> So, needless to say, I don't get it. I hope someone can see what I'm
> missing. I need to get past this and get back to making bots go.
> /**
>  * @excerpts from my_test_gpio_interrupts.c
>  * as of 19 June 2020
>  *
>  * Demonstrates use sysFS to respond to
>  * gpio interrupts. Instructions are printed to the screen when called.
>  */
>
>
> #include 
> #include 

Re: [beagleboard] CAN not working with Debian 10.3

[Jason Kridner]

What steps are you trying to enable it?

On Thu, Jun 4, 2020 at 10:17 AM barney  wrote:

> We have a c program that uses CAN and it works with Debian 9.5.  When I
> updated the BBB to Debian 10.3, the CAN no longer works.  Can anyone
> provide info on what changes were made to Debian 10.3 with respect to CAN?
> The UART still works but not CAN.
> Thanks,
> John
>
> --
> 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/f56114c5-b521-4570-8771-d40618af6b75%40googlegroups.com
> 
> .
>
-- 
https://beagleboard.org/about - 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/CA%2BT6QPkb3y8JCxtz--raiGpejRCwfmcAYNM80B1GUTNp%2BAn4Pg%40mail.gmail.com.

Re: [beagleboard] Re: How to flash the eMMC on BBB

[Jason Kridner]

type ${devtype} ${devnum}:${distro_bootpart} 
>> bootfstype; then run scan_dev_for_boot; fi; done; setenv devplist
>> scan_dev_for_efi=setenv efi_fdtfile ${fdtfile}; if test -z "${fdtfile}" -a 
>> -n "${soc}"; then setenv efi_fdtfile ${soc}-${board}${boardver}.dtb; fi; for 
>> prefix in ${efi_dtb_prefixes}; do if test -e ${devtype} 
>> ${devnum}:${distro_bootpart} ${prefix}${efi_fdtfile}; then run load_efi_dtb; 
>> fi;done;if test -e ${devtype} ${devnum}:${distro_bootpart} 
>> efi/boot/bootarm.efi; then echo Found EFI removable media binary 
>> efi/boot/bootarm.efi; run boot_efi_binary; echo EFI LOAD FAILED: 
>> continuing...; fi; setenv efi_fdtfile
>> scan_dev_for_extlinux=if test -e ${devtype} ${devnum}:${distro_bootpart} 
>> ${prefix}${boot_syslinux_conf}; then echo Found 
>> ${prefix}${boot_syslinux_conf}; run boot_extlinux; echo SCRIPT FAILED: 
>> continuing...; fi
>> scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} 
>> ${devnum}:${distro_bootpart} ${prefix}${script}; then echo Found U-Boot 
>> script ${prefix}${script}; run boot_a_script; echo SCRIPT FAILED: 
>> continuing...; fi; done
>> scriptaddr=0x8000
>> serial#=4819BBBK12B5
>> soc=am33xx
>> spiargs=setenv bootargs console=${console} ${optargs} root=${spiroot} 
>> rootfstype=${spirootfstype}
>> spiboot=echo Booting from spi ...; run spiargs; sf probe ${spibusno}:0; sf 
>> read ${loadaddr} ${spisrcaddr} ${spiimgsize}; bootz ${loadaddr}
>> spibusno=0
>> spiimgsize=0x362000
>> spiroot=/dev/mtdblock4 rw
>> spirootfstype=jffs2
>> spisrcaddr=0xe
>> static_ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}::off
>> stderr=serial@44e09000
>> stdin=serial@44e09000
>> stdout=serial@44e09000
>> update_to_fit=setenv loadaddr ${fit_loadaddr}; setenv bootfile 
>> ${fit_bootfile}
>> usb_boot=usb start; if usb dev ${devnum}; then devtype=usb; run 
>> scan_dev_for_boot_part; fi
>> usbnet_devaddr=de:ad:be:ef:00:01
>> vendor=ti
>> ver=U-Boot 2019.07 (Jun 02 2020 - 16:55:38 +0200)
>> Environment size: 9845/131068 bytes
> 
> 
> W dniu wtorek, 2 czerwca 2020 17:56:38 UTC+2 użytkownik Jason Kridner napisał:
>> 
>> Can you stop the boot in u-boot and print the environment? There's probably 
>> an easy fix to the bootcmd.
>> 
>>> On Tue, Jun 2, 2020 at 11:50 AM Szymon Kempny  wrote:
>>> It looks like the eMMC is properly recognized by uBoot:
>>> 
>>>> => mmcinfo
>>>> Device: OMAP SD/MMC
>>>> Manufacturer ID: 70
>>>> OEM: 100
>>>> Name: M6270
>>>> Bus Speed: 4800
>>>> Mode: MMC High Speed (52MHz)
>>>> Rd Block Len: 512
>>>> MMC version 5.1
>>>> High Capacity: Yes
>>>> Capacity: 3.6 GiB
>>>> Bus Width: 8-bit
>>>> Erase Group Size: 512 KiB
>>>> User Capacity: 3.6 GiB
>>>> Boot Capacity: 2 MiB ENH
>>>> RPMB Capacity: 512 KiB ENH
>>> 
>>> 
>>> -- 
>>> 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/03673c3f-8769-4c0b-bce0-d231eb1555db%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/a396d415-4b59-4a41-a681-81438cc78615%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/C6C8B136-795D-4ADD-B63D-066050843FA5%40gmail.com.

Re: [beagleboard] How to flash the eMMC on BBB

[Jason Kridner]

> On Jun 2, 2020, at 11:15 AM, Szymon Kempny  wrote:
> 
> 
> Hello,
> 
> how to flash system image created by buildroot to internal eMMC memory in BBB?
> 
> Here is what I'm doing:
> 
> 1. Build image with buildroot
> 2. Write sdcard.img to SD card
> 3. Boot BBB from SD card
> 4. Increase root partition on SD card: resize2fs /dev/mmcblk0p2
> 5. scp sdcard.img from PC to BBB: scp output/images/sdcard.img 
> root@192.168.1.213:/root/
> 6. Boot BBB from SD card
> 7. Write sdcard.img to internal eMMC od BBB: dd if=sdcard.img of=/dev/mmcblk1
> 8. Poweroff BBB
> 9. Remove SD card from BBB
> 10. Power on BBB.
> 
> Here is the output from console:
> 
>> U-Boot SPL 2019.07 (Jun 02 2020 - 16:55:38 +0200)
>> Trying to boot from MMC2
>> 
>> U-Boot 2019.07 (Jun 02 2020 - 16:55:38 +0200)
>> CPU  : AM335X-GP rev 2.1
>> Model: TI AM335x BeagleBone Black
>> DRAM:  512 MiB
>> NAND:  0 MiB
>> MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
>> Loading Environment from FAT...  not set. Validating first E-fuse 
>> MAC
>> Net:   eth0: ethernet@4a10
>> Warning: usb_ether MAC addresses don't match:
>> Address in ROM is  de:ad:be:ef:00:01
>> Address in environment is  0c:b2:b7:cd:44:35
>> , eth1: usb_ether
>> Hit any key to stop autoboot:  0
>> switch to partitions #0, OK
>> mmc1(part 0) is current device
>> SD/MMC found on device 1

It would be nice if the environment and boot failure where on the same email.

It seems like this is where it fails. Reading your environment, I’d guess that 
this is because the kernel isn’t found?

Do you have 1 or 2 partitions on your buildroot image?

Where is the kernel? Where are the dtbs?

Do you know if you are running the right uboot built by buildroot? I’d guess 
you are by the build stamp. 

Is this upstream buildroot?


>> ## Error: "bootcmd_nand0" not defined
>> starting USB...
>> Bus usb@47401800: Port not available.
>> ethernet@4a10 Waiting for PHY auto negotiation to complete... done
>> link up on port 0, speed 100, full duplex
>> BOOTP broadcast 1
>> DHCP client bound to address 192.168.1.213 (6 ms)
>> Using ethernet@4a10 device
>> TFTP from server 192.168.1.1; our IP address is 192.168.1.213
>> Filename 'zImage'.
>> Load address: 0x8200
>> Loading: T
> 
> 
> 
> What should I fix to properly run my BBB from eMMC?
> 
> 
> -- 
> For more options, visit http://beagleboard.org/discuss
> --- 
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/7cf87e6c-8df7-40e2-beb4-6381329c3275%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/C2E87EB6-D7A7-427B-AFCB-2DBFF4096D4E%40gmail.com.

Re: [beagleboard] Re: How to flash the eMMC on BBB

[Jason Kridner]

Can you stop the boot in u-boot and print the environment? There's probably
an easy fix to the bootcmd.

On Tue, Jun 2, 2020 at 11:50 AM Szymon Kempny  wrote:

> It looks like the eMMC is properly recognized by uBoot:
>
> => mmcinfo
>> Device: OMAP SD/MMC
>> Manufacturer ID: 70
>> OEM: 100
>> Name: M6270
>> Bus Speed: 4800
>> Mode: MMC High Speed (52MHz)
>> Rd Block Len: 512
>> MMC version 5.1
>> High Capacity: Yes
>> Capacity: 3.6 GiB
>> Bus Width: 8-bit
>> Erase Group Size: 512 KiB
>> User Capacity: 3.6 GiB
>> Boot Capacity: 2 MiB ENH
>> RPMB Capacity: 512 KiB ENH
>
>
> --
> 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/03673c3f-8769-4c0b-bce0-d231eb1555db%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/CA%2BT6QPnf%3DorS9Kw%3DD%2B9ebB2sDCdQ8%2BhzkR%2BDivEGwkM8QGMYTA%40mail.gmail.com.

Re: [beagleboard] Re: accessing P9.13 on Beaglebone AI

[Jason Kridner]

On Tue, May 12, 2020 at 10:40 AM jonnymo  wrote:

> There is an open issue for the BBAI in reference to adding AB10 GPIO
> support but states being added with rev. A2 which I thought was the current
> rev board:
> This is also mentioned in the System Reference Manual:
> https://github.com/beagleboard/beaglebone-ai/wiki/System-Reference-Manual
>
> HW: P9.13 does not have a GPIO:
> https://github.com/beagleboard/beaglebone-ai/issues/22
>
> Perhaps it was not implemented yet?
>

Correct. The current revision is A1a. Sorry to jump the gun on adding AB10
to the code--it isn't on the board.

At one point, I thought A2 would come out a lot faster. I just got updated
schematics yesterday for review and it is going into layout.


>
> Cheers,
>
> Jon
>
>
>
> On Tue, May 12, 2020 at 6:11 AM John Allwine  wrote:
>
>> Thanks for the suggestions. Here's what I get when I run show_pins.pl
>> when I use the device tree overlay linked above
>> 
>> :
>> $ sudo /opt/scripts/device/bone/show-pins.pl | grep "P9.13"
>> P9.13b   160 AB10 e fast rx  up  gpio6_12
>> P9.13a   204  C17 f fast rx  Driver off
>>
>> That seems right, but unfortunately I can't seem to properly read from
>> it. When I take out the line that configures P9.13b from my device tree, it
>> also does what would be expected so it seems like I'm configuring my device
>> tree correctly.
>> $ sudo /opt/scripts/device/bone/show-pins.pl  | grep P9.13
>> P9.13b   160 AB10 f fastdown Driver off
>> P9.13a   204  C17 f fast rx  Driver off
>>
>> Maybe Jason can chime in here. Why is P9.13b not blue in your
>> spreadsheet? Does that mean it's not a usable pin?
>>
>> On Mon, May 11, 2020 at 11:27 PM Jon Morss  wrote:
>>
>>> According to the spreadsheet that Jason sent some time back, P9.13 does
>>> not have the gpio value highlighted in blue but I am not sure what that
>>> really means.  However, it seems the pins with a gpio value in blue seem to
>>> work fine, such as P9.12 (gpio5_0).
>>>
>>> https://docs.google.com/spreadsheets/d/1fE-AsDZvJ-bBwzNBj1_sPDrutvEvsmARqFwvbw_HkrE/edit?usp=sharing
>>>
>>> You could check the output of showpins to see what P9.13x is set to:
>>> sudo /opt/scripts/device/bone/show-pins.pl |grep "P9.13"
>>> P9.13b   160 AB10 e fast rx  gpio6_12
>>> P9.13a   204  C17 e fastdown
>>>
>>> With P9.12 set, it looks as such:
>>> sudo /opt/scripts/device/bone/show-pins.pl |grep "P9.12"
>>> P9.12171  B14 e fast rx  gpio5_0
>>>
>>> Also,  I do add this in the .dts file:
>>>
>>> cape_pins: cape_pins {
>>> compatible = "gpio-leds";
>>> pinctrl-names = "default";
>>> gpios = < 12 GPIO_ACTIVE_HIGH>,
>>> < 0 GPIO_ACTIVE_HIGH>;
>>> pinctrl-0 = <_pins_default>;
>>> };
>>>
>>>
>>> Perhaps there is another trick to get P9.13b to work as a GPIO pin.
>>>
>>> Cheers,
>>>
>>> Jon
>>>
>>>
>>> On Monday, May 11, 2020 at 3:25:59 PM UTC-7, John Allwine wrote:

 When I manually wire a pull up resistor, I still am not able to detect
 a high signal using the methods I listed, though I can verify with a
 multimeter that P9.13 is high.

 On Monday, May 11, 2020 at 3:17:36 PM UTC-6, John Allwine wrote:
>
> I'm trying to configure P9.13 on the Beaglebone AI as an input pull
> up, but am not having any success. In the System Manual
> 
> it lists P9.13a as not being bound to a GPIO port, but P9.13b is bound to
> GPIO6_12. This is the device tree overlay I'm using
> 
>  with
> line 56 showing how I'm attempting to configure P9.13b (and P9.13a the 
> line
> above it). Am I doing something wrong in my device tree overlay? I've had
> success configuring many other pins, but P9.13 is giving me trouble for
> some reason.
>
> I'm testing it a couple ways:
> 1) with sysfs
> echo 172 > /sys/class/gpio/export
> cat /sys/class/gpio/gpio172/value
>
> 2) with libgpio
> gpioget gpiochip5 12
>
> Both return a value of 0, when I'd expect it to be 1 (I don't have
> anything wired to it). Any idea what I'm doing wrong?
>
 --
>>> 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
>>> 

Re: [beagleboard] PRU Beginner Questions (2)

[Jason Kridner]

> On May 10, 2020, at 4:09 AM, V37E00E  wrote:
> 
> 
> Hello,
> 
> 
> 
> I’m a beginner learning about PRU with a couple of questions.  I’ve been 
> using as reference:
> 
> PRU Cookbook (thank you Mark)
> Exploring BeagleBone by Derek Molloy
> TI Examples & Labs 
> https://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs
> Questions:
> 
> 1.   1.  Default firmware for PRU0/1:
> 
> root@beaglebone:~# cat /sys/class/remoteproc/remoteproc*/firmware
> 
> am335x-pm-firmware.elf
> 
> am335x-pru0-fw
> 
> am335x-pru1-fw
> 
>  
> 
> root@beaglebone:~# find / -name am335x-pru?-fw
> 
> /lib/firmware/am335x-pru0-fw
> 
> /lib/firmware/am335x-pru1-fw
> 
>  
> 
> What do these programs do?  I haven’t found any source code to explain what 
> is inside.  I think the files come from TI (compiled form), but what happens 
> if I
> 
> echo start > state for the default firmware?  Seems strange to have this as 
> the default with no clues about what is inside.
> 

There’s no defacto pru firmware. Robert and I discussed loading a firmware 
image that puts the processor in a hold loop just to have something in there by 
default. I imagine that is what this is. 

>  
> 
> 2.   What is the source for the __R30 pin configurations (default?.  
> Fresh boot =>
> 

Check https://github.com/beagleboard/customizations. This is where Robert and I 
discussed putting it. 

> root@beaglebone:~# cat /sys/kernel/debug/remoteproc/remoteproc1/regs | grep 
> "GPREG30 "
> 
> GPREG30 := 0xd233c9c3CT_REG30 := 0x4000
> 
>  
> 
> I’ve looked in:
> 
> U-Boot, am335x-boneblack-uboot, cape_universal, AM335X-PRU-RPROC-4-14-TI-00A0 
> and googled around but can’t find anything that looks like it sets __R30 at 
> boot.  
> 
> 
> 
> With a LED connected to P9-27, P9-28, P9-29:
> 
> config-pin P9-27 pruout => LED is low
> 
> config-pin P9-28 pruout => LED is high
> 
> config-pin P9-28 pruout => LED is high
> 
> For me, it seems strange that some pins would be high by "default".  What is 
> setting these values as high??? 
> 
>  
> 
> Many thanks in advance for any clues.
> 

There was nothing done to my knowledge to make these known or specific. I 
suggest you provide a firmware load if you want them to be specific. 

Patches welcome. 

There are some thoughts to load the PRUs with a small REPL through rpmsg for 
quick hacking. 

> -- 
> 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/3f51b584-e0bc-4474-9710-5a96f53d5177%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/150EE7B5-2D68-4623-82E2-3180F12F0201%40gmail.com.

Re: [beagleboard] Re: I killed my BBAI...

[Jason Kridner]

Will they boot off of microSD cards? I'm wondering if there is any chance
something is being done to corrupt the eMMC causing it to fail to boot and
shutdown very quickly.

On Sat, May 9, 2020 at 11:25 AM Gattu Savanth 
wrote:

> Hi hunter long,
> Actually same issue has been happened to my beaglebone ai today. the
> beaglebone is not powering on.previously i was working with one pin and
> suddenly board has powered off and its not powering on what to do.does the
> board   is damaged.please anyone help.
> Thanking you
> -savanth
>
> --
> 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/bdad1668-3ed9-443e-83e1-614a7dc16c0b%40googlegroups.com
> .
>


-- 
https://beagleboard.org/about - 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/CA%2BT6QPnHG44z3we91pmTNfw%2BBysM3nrFdU3Bcy5OpL6kQjJVrg%40mail.gmail.com.

[beagleboard] BeagleBone Black SRM released from asciidoc version on wiki

[Jason Kridner]

I've updated
https://github.com/beagleboard/beaglebone-black/blob/master/BBB_SRM.pdf
such that we can use it as a template for future SRMs as well as to accept
community edits.

Source is at
https://github.com/beagleboard/beaglebone-black/wiki/System-Reference-Manual
in asciidoc format. PDF conversion done with asciidoctor-pdf. Looking to
move to asciidoctor.js in the future.

-- 
https://beagleboard.org/about

-- 
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/CA%2BT6QP%3DWQDHZf8ztEYBtZK8UGbf9SNpKDtKy4TEomPK2p9RVwA%40mail.gmail.com.

Re: [beagleboard] PRU locking up Beaglebone AI

[Jason Kridner]

Got a more complete answer from the TI support team:

This is seems classic. The Remote Core, PRU in this case, is trying to
access GPIO bank shared with Linux.

Linux, by default owns all GPIO banks and if there are no GPIO lines
requested by Linux - the GPIO bank will be powered down.

Correct solution:
- GPIOs used by the Remote core has to be grouped in some GPIO bank X and
that bank has to be removed from Linux
   (DT - disabled or even completely removed).
   Remote core can use this GPIO bank X (including GPIO IRQ), but need
ensure it's enabled.

Possible option:
  - some line from GPIO bank X are used by Linux and some by Remote core
!! but not as IRQ sources !!
  IF:
  (a) GPIOX_Y is used by some Linux driver and requested before Remote core
loaded
  (b) unused GPIOX_Z line can be requested through sysfs/gpio_ioctl
interface before Remote core loaded
  Remote core can access GPIOX_A, but only through GPIO_SETDATAOUT,
GPIO_CLEARDATAOUT, GPIO_DATAIN

*not supported*
- Linux and remote Core FW can't share GPIO bank if both want to use GPIO
IRQs.

On Wed, Apr 29, 2020 at 5:01 PM John Allwine  wrote:

> This makes a whole lot more sense now, because I swear I had it working on
> those GPIO ports at one point. I think I had exported pins manually while
> testing things. Thanks for the help!
>
> On Wed, Apr 29, 2020 at 2:59 PM John Allwine  wrote:
>
>> That did it! I exported pin 8.43:
>>
>> echo 226 > /sys/class/gpio/export
>>
>> And now the PRUs can write to the set and clear addresses for GPIO8.
>>
>> I also exported 8.26:
>>
>> echo 124 > /sys/class/gpio/export
>>
>> And now the PRUs can write to the set and clear addresses for GPIO4.
>>
>> On Wed, Apr 29, 2020 at 11:42 AM Jason Kridner 
>> wrote:
>>
>>>
>>>
>>> On Wed, Apr 29, 2020 at 12:38 PM Charles Steinkuehler <
>>> char...@steinkuehler.net> wrote:
>>>
>>>> Regarding your bus errors, I don't see anything in the TRM that
>>>> indicates the PRU shouldn't be able to talk to all of the GPIO banks.
>>>>
>>>> I have, however, seen bus errors on uninitialized GPIO banks which come
>>>> up disabled by default.  Check to make sure at least one GPIO pin is
>>>> exported by the Linux Kernel (either manually or via device tree) and
>>>> see if the bus errors go away.
>>>>
>>>
>>> I'll double-down on that feedback. I forwarded this to the team at TI
>>> and they said it is likely that the GPIO bank doesn't have its clock
>>> enabled. I inquired what the minimal action to enable the clock would be,
>>> but haven't heard back yet. Enabling one of the GPIOs in the bank in Linux
>>> seems like a sure way to do it.
>>>
>>> I'll get back when I can find anything more minimal than that.
>>>
>>>
>>>>
>>>>
>>>> On 4/28/2020 4:45 PM, John Allwine wrote:
>>>> > Using that test, I was able to quickly check to see which GPIO ports
>>>> I was
>>>> > able to write to from the PRU. GPIO 1, 4 and 8 errored. GPIO 2
>>>> doesn't have
>>>> > any pins mapped to P8 or P9 headers, so that leaves GPIO 3, 5, 6 and
>>>> 7 that
>>>> > I can use for hal_pru_generic. The P8 and P9 pins that are mapped to
>>>> GPIO 4
>>>> > and 8 can all be mapped to direct outputs on certain PRUs. I'll need
>>>> to
>>>> > document how each pin can be used, but it seems like just about all
>>>> the P8
>>>> > and P9 pins can be used as long as you know which PRU to run it on for
>>>> > direct outputs and which are suitable to be used as GPIO outputs.
>>>> >
>>>> > On Tue, Apr 28, 2020 at 1:59 PM John Allwine >>> >
>>>> > wrote:
>>>> >
>>>> >> Ok, I have a more localized test that triggers the exception:
>>>> >>
>>>> >>
>>>> https://github.com/PocketNC/cloud9-examples/blob/test-pru-gpio-access/BeagleBone/AI/pru/doNothingToGPIO8.pru1_1.c
>>>> >>
>>>> >> Two stack traces can be seen in dmesg after running that on the PRU.
>>>> If it
>>>> >> has something to do with the device tree, this is the overlay I'm
>>>> using:
>>>> >>
>>>> >>
>>>> https://github.com/PocketNC/BeagleBoard-DeviceTrees/blob/pocketnc-ai-test/src/arm/am5729-beagleboneai-pocketnc-pro.dts
>>>> >>
>>>> >> On Tue, Apr 28, 2020 at 1:20 PM John Allwine 
>>>> wrote:
&

Re: [beagleboard] PRU locking up Beaglebone AI

[Jason Kridner]

On Wed, Apr 29, 2020 at 12:38 PM Charles Steinkuehler <
char...@steinkuehler.net> wrote:

> Regarding your bus errors, I don't see anything in the TRM that
> indicates the PRU shouldn't be able to talk to all of the GPIO banks.
>
> I have, however, seen bus errors on uninitialized GPIO banks which come
> up disabled by default.  Check to make sure at least one GPIO pin is
> exported by the Linux Kernel (either manually or via device tree) and
> see if the bus errors go away.
>

I'll double-down on that feedback. I forwarded this to the team at TI and
they said it is likely that the GPIO bank doesn't have its clock enabled. I
inquired what the minimal action to enable the clock would be, but haven't
heard back yet. Enabling one of the GPIOs in the bank in Linux seems like a
sure way to do it.

I'll get back when I can find anything more minimal than that.


>
>
> On 4/28/2020 4:45 PM, John Allwine wrote:
> > Using that test, I was able to quickly check to see which GPIO ports I
> was
> > able to write to from the PRU. GPIO 1, 4 and 8 errored. GPIO 2 doesn't
> have
> > any pins mapped to P8 or P9 headers, so that leaves GPIO 3, 5, 6 and 7
> that
> > I can use for hal_pru_generic. The P8 and P9 pins that are mapped to
> GPIO 4
> > and 8 can all be mapped to direct outputs on certain PRUs. I'll need to
> > document how each pin can be used, but it seems like just about all the
> P8
> > and P9 pins can be used as long as you know which PRU to run it on for
> > direct outputs and which are suitable to be used as GPIO outputs.
> >
> > On Tue, Apr 28, 2020 at 1:59 PM John Allwine 
> > wrote:
> >
> >> Ok, I have a more localized test that triggers the exception:
> >>
> >>
> https://github.com/PocketNC/cloud9-examples/blob/test-pru-gpio-access/BeagleBone/AI/pru/doNothingToGPIO8.pru1_1.c
> >>
> >> Two stack traces can be seen in dmesg after running that on the PRU. If
> it
> >> has something to do with the device tree, this is the overlay I'm using:
> >>
> >>
> https://github.com/PocketNC/BeagleBoard-DeviceTrees/blob/pocketnc-ai-test/src/arm/am5729-beagleboneai-pocketnc-pro.dts
> >>
> >> On Tue, Apr 28, 2020 at 1:20 PM John Allwine  wrote:
> >>
> >>> Are there any ramifications of the PRU writing 0 to both the set and
> >>> clear addresses of GPIO8 (0x48053190 and 0x48053194), when the device
> tree
> >>> has several overlapping pins allocated to being direct outputs on the
> PRU?
> >>> The issue seems to arise when I write to those two addresses on the
> PRU, as
> >>> well as the set and clear addresses of GPIO4 (0x48059190 and
> 0x48059194).
> >>> What could cause that to trigger an exception in the kernel?
> >>>
> >>> On Tue, Apr 28, 2020 at 12:19 PM John Allwine 
> wrote:
> >>>
> >>>> It seems that even if I hardcode the addresses in there (to eliminate
> >>>> the possibility that my registers were getting overwritten
> somewhere), that
> >>>> I get the bus error.  Does enabling the OCP Master port work the same
> way
> >>>> as on the BBB? It's supposedly being set here:
> >>>>
> https://github.com/PocketNC/machinekit-hal/blob/c8b38386d87abc45baa33593681cbae46d996980/src/hal/drivers/hal_pru_generic/pru_generic.p#L174-L176
> >>>>
> >>>> On Tue, Apr 28, 2020 at 11:47 AM John Allwine 
> wrote:
> >>>>
> >>>>> It's the hal_pru_generic code. It definitely smells like a bus error.
> >>>>> In fact, if I comment out the lines that write to the GPIO, it stops
> >>>>> happening, so it seems like I have the wrong addresses in there, but
> I'm
> >>>>> struggling figuring out how that could be.
> >>>>>
> >>>>> These lines are where the GPIO ports are written to in memory:
> >>>>>
> >>>>>
> https://github.com/PocketNC/machinekit-hal/blob/c8b38386d87abc45baa33593681cbae46d996980/src/hal/drivers/hal_pru_generic/pru_wait.p#L214-L217
> >>>>>
> >>>>> Theoretically, the addresses should be set to the clear addresses of
> >>>>> GPIO3, GPIO5, GPIO6 and GPIO7:
> >>>>>
> >>>>> Addresses defined here:
> >>>>>
> >>>>>
> https://github.com/PocketNC/machinekit-hal/blob/c8b38386d87abc45baa33593681cbae46d996980/src/hal/support/pru/pru.h#L303-L307
> >>>>>
> >>>>> Loaded into registers here:
> >>>>>
> >>>>>
> htt

Re: [beagleboard] PRU locking up Beaglebone AI

[Jason Kridner]

What is the code running on PRUSS2 PRU1?

This line kinda spells out an illegal access by that PRU or of that PRU:
MASTER PRUSS2 PRU1 TARGET L4_PER1_P3 (Idle): Data Access in Supervisor mode
during Functional access

Looks like the error is from here:
https://github.com/beagleboard/linux/blob/7a920684860a790099061b67961d0b5ffa033fdf/drivers/bus/omap_l3_noc.c#L135

Looks like a bus exception to me.

On Tue, Apr 28, 2020 at 11:46 AM  wrote:

> I'm getting this stack trace in dmesg, but I'm unsure what it means or how
> to figure out what it means. As far as I can tell, the code running on the
> PRU is working. I'm generating a 100Khz signal on a direct output, and am
> able to successfully measure this signal. The Beaglebone is locking up,
> though, and I believe this stack trace is being spammed so heavily that the
> logging is taking over the CPU and my ssh shell gets locked out.
>
> I'm using this device tree overlay:
> https://github.com/PocketNC/BeagleBoard-DeviceTrees/blob/pocketnc-ai-test/src/arm/am5729-beagleboneai-pocketnc-pro.dts
>
> The code I'm running is implemented in PRU Assembly that is assembled with
> pasm. pasm outputs a .bin file and I need a .elf file for running it with
> remoteproc, so I'm jumping through some hoops to do that conversion. The
> elf file does seem to work, but I'm not sure if I need to do more to ensure
> I'm specifying what resources I need access to or something like that. I
> can go into more detail if need be.
>
> The stack trace is below. Any ideas about what is going on are appreciated!
>
> [  168.153783] [ cut here ]
> [  168.153829] WARNING: CPU: 0 PID: 0 at drivers/bus/omap_l3_noc.c:147
> l3_interrupt_handler+0x27c/0x39c
> [  168.153851] 4400.ocp:L3 Custom Error: MASTER PRUSS2 PRU1 TARGET
> L4_PER1_P3 (Idle): Data Access in Supervisor mode during Functional access
> [  168.153865] Modules linked in: xt_conntrack ipt_MASQUERADE
> nf_nat_masquerade_ipv4 rpmsg_rpc rpmsg_proto bnep btsdio bluetooth
> ecdh_generic brcmfmac pvrsrvkm(O) brcmutil cfg80211 uio_pruss_shmem evdev
> joydev stmpe_adc omap_remoteproc virtio_rpmsg_bus rpmsg_core 8021q garp mrp
> stp llc iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat
> usb_f_acm nf_conntrack u_serial usb_f_ecm usb_f_mass_storage iptable_mangle
> iptable_filter usb_f_rndis u_ether libcomposite cmemk(O) uio_pdrv_genirq
> uio spidev pruss_soc_bus pru_rproc pruss pruss_intc ip_tables x_tables
> [  168.154474] CPU: 0 PID: 0 Comm: swapper/0 Tainted: GW  O
> 4.14.108-ti-r119 #1
> [  168.154490] Hardware name: Generic DRA74X (Flattened Device Tree)
> [  168.154538] [] (unwind_backtrace) from []
> (show_stack+0x20/0x24)
> [  168.154575] [] (show_stack) from []
> (dump_stack+0x80/0x94)
> [  168.154609] [] (dump_stack) from []
> (__warn+0xf8/0x110)
> [  168.154636] [] (__warn) from []
> (warn_slowpath_fmt+0x58/0x74)
> [  168.154667] [] (warn_slowpath_fmt) from []
> (l3_interrupt_handler+0x27c/0x39c)
> [  168.154703] [] (l3_interrupt_handler) from []
> (__handle_irq_event_percpu+0xbc/0x280)
> [  168.154734] [] (__handle_irq_event_percpu) from []
> (handle_irq_event_percpu+0x3c/0x8c)
> [  168.154761] [] (handle_irq_event_percpu) from []
> (handle_irq_event+0x48/0x6c)
> [  168.154792] [] (handle_irq_event) from []
> (handle_fasteoi_irq+0xc8/0x17c)
> [  168.154822] [] (handle_fasteoi_irq) from []
> (generic_handle_irq+0x34/0x44)
> [  168.154850] [] (generic_handle_irq) from []
> (__handle_domain_irq+0x8c/0xfc)
> [  168.154879] [] (__handle_domain_irq) from []
> (gic_handle_irq+0x4c/0x88)
> [  168.154908] [] (gic_handle_irq) from []
> (__irq_svc+0x6c/0xa8)
> [  168.154925] Exception stack(0xc1501ed8 to 0xc1501f20)
> [  168.154946] 1ec0:
>  0001 
> [  168.154973] 1ee0: fe60  c150 c1504e60 c1504dfc c14cbb78
> c1501f48 
> [  168.154997] 1f00:  c1501f34 c1501f14 c1501f28 c012fcb8 c0109768
> 600f0013 
> [  168.155031] [] (__irq_svc) from []
> (arch_cpu_idle+0x30/0x4c)
> [  168.155061] [] (arch_cpu_idle) from []
> (default_idle_call+0x30/0x3c)
> [  168.155092] [] (default_idle_call) from []
> (do_idle+0x180/0x214)
> [  168.155124] [] (do_idle) from []
> (cpu_startup_entry+0x28/0x2c)
> [  168.155156] [] (cpu_startup_entry) from []
> (rest_init+0xdc/0xe0)
> [  168.155194] [] (rest_init) from []
> (start_kernel+0x434/0x45c)
> [  168.155217] ---[ end trace d9047b952a20ba7f ]---
>
>
>
> --
> 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/fde6b3e0-1a1d-43d5-8f78-14d604a7b1fa%40googlegroups.com
> 

[beagleboard] Re: requesting information on pcb files for beaglebone black and beaglebone ai

[Jason Kridner]

On Wed, Apr 22, 2020 at 10:35 AM Ramakrishna Bachimanchi 
wrote:

> Hello,
> my name is Rama Bachimanchi and I am an electrical engineer working at
> Jefferson Lab (non-profit research organization). I have come across the
> amazing work you guys are doing and was looking into possibly modifying one
> of your designs to replace an obsolete ioc we are using (it's a kontron
> pc/104 no longer in production). I was able to import the schematic into
> Altium, but not the pcb design files. I am getting an error when tried to
> view the files using the free allegro pcb viewer. Would it be possible to
> update the files and also upload the ascii file, so that we can import this
> into altium. We are planning to replace the expansion connectors with
> pc/104 connector. If we get to work and finish the design, we will most
> likely share it with you(not sure, if this is useful for the community).
> Please let me know
>


I'm not sure what ASCII file is needed. If I knew, I'd be happy to export
it.

For conversion to KiCAD, I created a cds2f text file:
https://github.com/beagleboard/beaglebone-ai/blob/master/HW/cds2f_BeagleBone-AI.txt

When the KiCAD version is available, you might find it easier to import
that into Altium:
https://www.altium.com/solution/kicad-pcb-design-software-free-download



>
> Thanks,
> Rama Bachimanchi
>
>

-- 
https://beagleboard.org/about - 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/CA%2BT6QP%3DCryDTk7QT1keBQ6-3HuJ5%3DW35nSacRYepa3MR6Ac9sg%40mail.gmail.com.

Re: [beagleboard] Re: Beaglebone AI UART access

[Jason Kridner]

Thanks for all your shared work.

The plan for the Fall release (based on GSoC work on-going this summer, if
approved, or this might be delayed) is to modify the base device trees and
set of overlays to provide at common set of overlays to load for Black/AI.
Then, symlinks would be provided that map to UARTs on specific header pins.

See https://elinux.org/Beagleboard:BeagleBone_cape_interface_spec for
work-in-progress.

On Wed, Apr 22, 2020 at 10:22 PM  wrote:

>
> I hope it is helpful for uart3  /dev/ttyS2 device tree implementation.
>
> Uart3 RX starts working after the mode update to
>
> PIN_INPUT_PULLUP | MUX_MODE1 // P9.22b uart3_rxd
>
> Mode is confirmed as the following:
>
>
> P9.22b   240 fast rx  up   1 uart 2 rxd   serial@4802 (uart3)
>
> pin 240 (PIN240) 4a0037c0 00060001 pinctrl-single ( instead of 0001)
>
>
>
> UART3 TX was working without any pull up or pull down.
>
> P9_21, MUX_MODE1 ) // P9.21 uart3_txd
>
> pin 241 (PIN241) 4a0037c4 0001 pinctrl-single
>
>
>
> To activate uart3, please add the following code into *.dts file and
> compile to *.dtb.
>
> Also please modify the am572*ai.dts file by deactivating the shared pins.
>
>
>  {
>
>  status = "okay";
>
>  pinctrl-names = "default";
>
>  pinctrl-0 = <_pins>;
>
> };
>
> _pmx_core {
>
>  uart3_pins: uart3 {
>
>   pinctrl-single,pins = <
>
>DRA7XX_CORE_IOPAD( P9_21, MUX_MODE1 ) // P9.21 uart3_txd
>
>DRA7XX_CORE_IOPAD( P9_22b, PIN_INPUT_PULLUP | MUX_MODE1) // P9.22b
> uart3_rxd
>
>DRA7XX_CORE_IOPAD( P9_22a, MUX_MODE15) // P9.22a driver_off //shared-pin
>
>   >;
>
>  };
>
>
>
> };
>
>
> --
> 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/c77fd7a6-4177-4a4c-9f20-cca67e254fb5%40googlegroups.com
> 
> .
>


-- 
https://beagleboard.org/about - 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/CA%2BT6QPm5OdC%3Dth0ByQ3DJ-Rq9ynfarN9MkhiDdd3eOh0_RrW0g%40mail.gmail.com.

Re: [beagleboard] BBAI Flasher Image with Desktop

[Jason Kridner]

On Wed, Apr 22, 2020 at 9:51 PM Robert Nelson 
wrote:

> On Wed, Apr 22, 2020 at 8:49 PM  wrote:
> >
> > Does anyone know if there is an image for the bealgebone ai that will
> flash to the eMMC and includes the graphical desktop?
> > None of the images at http://beagleboard.org/latest-images have a
> graphical desktop and will flash to eMMC that I can see.
> > An older Debian version is okay.
> >
> > I had to re-flash the eMMC on my board due to a network connectivity
> problem but have lost the desktop that I was using to display using opencv.
> > I also don't want to boot off of an sd card because it has been a pain
> getting opencv and tensorflow installed locally.
>
> Grab this version, it's updated once a month:
>
>
> https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Debian_Stretch_LXQt_TIDL_Snapshot


Robert, Is there a simple process for installing the extra LXQt bits via
apt?



>
>
> 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/CAOCHtYhGfXK6PMPc20mm2oDMKXWk5O%3Dz%2BGUf7wZBHb35TBKVnA%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/CA%2BT6QPk94NcewYOKceOfdN04xSCQO70gmEpCxvJg%2BZoLxjHQVg%40mail.gmail.com.

Re: [beagleboard] Jumps right to cloud9 ide, connecting with board right?

[Jason Kridner]

On Wed, Apr 22, 2020 at 10:05 AM Robert Nelson 
wrote:

> On Wed, Apr 22, 2020 at 9:01 AM  wrote:
> >
> > Hello everyone,
> >
> > I have a BBB, Rev C and I was just trying to follow the Start menu and
> update the software, now, after I have tried to set it up, when I 'connect'
> to it it goes right to cloud9 IDE without the prior start up page, what
> happened?  I was wanting to play with the scripts on that start page. How
> do I get back to it, I try going to connect board by putting in address,
> and it does not connect.  How can I get my board back to original factory
> settings on the eMMC?  It is an Element 14 board.
>
> It was decided to drop the whole "bone" webpage on startup and just
> move users to Cloud9, and provide all the examples/doc's in the left
> hand plane of the ide.
>
> https://github.com/beagleboard/cloud9-examples


That said, we haven't *fully* killed it (at least not last I checked).

Look at http://:8000/Support/bone101

But, it is likely to be not installed in future images. I do see this stuff
gets some usage, but not enough interest to really continue driving updates
to the tutorials, which is why we've shifted to this model of tutorials
that people seem to understand what is going on quicker. The whole RPC
server confuses a lot of people, despite being a powerful tutorial feature.


If you want to run an older image, scroll down on
https://beagleboard.org/latest-images and find the date you want to move
back to. The flashing process is covered at
https://beagleboard.org/getting-started#update.


>
>
> 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/CAOCHtYge1M-caKj%3DKGmLmYiyc_y6ndqg41aSWw9_-_1NtZpCDw%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/CA%2BT6QPkrQ_6jLYPyCpvhQc%2B4QyYXL7uLx6mg2%3DJO%3D6ESzzOHdw%40mail.gmail.com.

[beagleboard] Re: BeagleBone and multi boot usb

[Jason Kridner]

This really should have beagleboard@googlegroups.com in cc. I don't feel
like waiting for you to do the right thing, so I'm just replying with you
in bcc.

On Wed, Apr 22, 2020 at 5:31 PM someone wrote:

> Hey Jason,
>
> Hope you are safe and doing well.
>
> Wondering if the BeagleBone Green or other variants can act as a usb host
> and client at the same time.
>

On 2 separate ports, yes. The USB specification itself does not support
multi-master. Man, makes me miss IEEE-1394 every time.


>
> I.e. connect USB flash drive to beagle bone, and have the beagle bone act
> as a larger flash drive when plugged into a client?
>

Sure. You can have the BeagleBone act as a USB storage device and you can
add intermediary layers that perform transactions on other devices,
including a USB host port.

https://hackaday.com/2013/07/02/usb-sniffing-with-the-beagleboard-xm/ shows
one proof-of-concept (done as a Google Summer of Code project under
BeagleBoard.org mentorship).

I'd suggest you also look at https://github.com/microsoft/uf2-linux to see
the way they used network-backed block device (NBD) to create a daemon that
listens for the block accesses. This can be pretty tricky, but you can fake
all sorts of storage handling in-between.


>
> The use case is a multi boot USB tool - throw a bunch of ISOs on the BB
> and select which one you need, plug it in and boot the machine!
>
>
When structuring such a support e-mail, I always suggest with starting with
what you are wanting to accomplish FIRST:
 1) what you want to do
 2) what you tried
 3) what you expected
 4) what you actually got (and why it isn't what you expected, if you know)

Nice guide on smart questions:
http://www.catb.org/~esr/faqs/smart-questions.html. I don't think you
researched this one much. Anyway, it is still something useful to get out
to searchable land.

If you have a right way to control the UI, the files on your target disk,
and the target disk is already mounted when you connect to your host, this
is actually pretty trivial. You'd simply set the backing store of your of
your gadget ahead of making the connection. USB ConfigFS makes this pretty
easy.

Here's an example that configures the default USB flash drive on Beagle
Debian images (
https://github.com/RobertCNelson/boot-scripts/blob/master/boot/am335x_evm.sh#L458-L465
):

echo "${log} enable USB mass_storage ${usb_image_file}"
mkdir -p functions/mass_storage.usb0
echo ${usb_ms_stall} > functions/mass_storage.usb0/stall
echo ${usb_ms_cdrom} > functions/mass_storage.usb0/lun.0/cdrom echo
${usb_ms_nofua} > functions/mass_storage.usb0/lun.0/nofua echo
${usb_ms_removable} > functions/mass_storage.usb0/lun.0/removable
echo ${usb_ms_ro} > functions/mass_storage.usb0/lun.0/ro
echo ${actual_image_file} > functions/mass_storage.usb0/lun.0/file

The ${actual_image_file} would need to point to the .iso on your target
storage file system.

See:
* https://www.kernel.org/doc/html/latest/usb/gadget_configfs.html
* https://www.kernel.org/doc/html/latest/usb/mass-storage.html


-- 
https://beagleboard.org/about

-- 
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/CA%2BT6QPnbJwO350pdG5i527_2zRfOGH6hObbZVpE2620A%3Dg9hbw%40mail.gmail.com.

Re: [beagleboard] BeagleBoneBlack-Ind-4g Bill of Material

[Jason Kridner]

On Fri, Apr 17, 2020 at 6:35 PM jbossert nssengr.com 
wrote:

> Hello,
>
>
>
> Our company is interested in using the BeagleBoneBlack-Ind-4g from
> element14 or the BeagleBoneBlack-ITEMP from Arrow in some of our products.
> But we need to be able the build the board ourselves in order to ensure
> sustainability in case our source stops manufacturing the BBBI that we are
> using, in the future.  To that end, I am trying to find the specific bill
> of material for the BeagleBoneBlack-Ind-4g Bill of Material or the
> BeagleBoneBlack-ITEMP Bill of Material with parts used for the extended
> temperature range included.  All that I can find is the BOM for the (BBB
> standard temperature range).
>
>
>
> Can you provide me with the specific BOM and related hardware documents
> for the BeagleBoneBlack-Ind-4g or the BeagleBoneBlack-ITEMP?
>

I uploaded the Embest BOM:
https://github.com/beagleboard/beaglebone-black/blob/proposed-bom-updates/BBBI_BOM.csv

Currently working on some updates with Seeed for their implementation.


>
>
> Thanks!
>
> Jeff Bossert
>
> North Star Systems, Inc.
>
>
>
> --
> 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/BN8PR12MB34124E11268C6C4C62B5414DC1D90%40BN8PR12MB3412.namprd12.prod.outlook.com
> 
> .
>


-- 
https://beagleboard.org/about - 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/CA%2BT6QPk%2B1kxzEzpofptrdXiFSeTDR0SxKUUWne9BY7bk9zQXWQ%40mail.gmail.com.

Re: [beagleboard] Barcode Scanner/Keyboard on BBB with Crontab

[Jason Kridner]

On Tue, Apr 21, 2020 at 9:02 AM Don Pancoe  wrote:

> Hello all,
>
> I have been successfully using a barcode scanner / keyboard emulator with
> python on a BBB thanks to the evdev library (
> https://python-evdev.readthedocs.io/en/latest/) recommended by Drew
> Fustini.
>
> However, when I run the main program with crontab instead of from a
> console (I want to eliminate the need to have a laptop at the workstation),
> the barcode scanner no longer works. I suspect it has something to do with
> with the /dev/input path to the device being different in that
> environment, but I'm not entirely sure.
>
> I've done some searching and reading into this but haven't found the magic
> answer yet. I've not yet even been able to connect a console to the
> instance that was spawned by crontab to see what's going on inside of it.
>
> Any guidance appreciated, including pointing me to resources to work
> through myself.
>

I've been using C, not Python, but I do launch my program from a udev rule,
which should be comparable to being launched from crontab. I do a bit more
in the udev rules (
https://github.com/jadonk/beagle-tester/blob/master/beagle-tester.rules) to
actually create a symlink for the barcode scanner that I then use in my C
program:

KERNEL=="event*", ATTRS{idVendor}=="05fe", ATTRS{idProduct}=="1010",\
SYMLINK+="input/beagle-barcode", TAG+="systemd",\
ENV{SYSTEMD_WANTS}="beagle-tester.service"
KERNEL=="event*", ATTRS{idVendor}=="05f9", ATTRS{idProduct}=="2204",\
SYMLINK+="input/beagle-barcode", TAG+="systemd",\
ENV{SYSTEMD_WANTS}="beagle-tester.service"
KERNEL=="event*", ATTRS{idVendor}=="067e", ATTRS{idProduct}=="0801",\
SYMLINK+="input/beagle-barcode", TAG+="systemd",\
ENV{SYSTEMD_WANTS}="beagle-tester.service"
KERNEL=="event*", ATTRS{idVendor}=="0c2e", ATTRS{idProduct}=="0901",\
SYMLINK+="input/beagle-barcode", TAG+="systemd",\
ENV{SYSTEMD_WANTS}="beagle-tester.service"
KERNEL=="event*", ATTRS{idVendor}=="05f9", ATTRS{idProduct}=="2206",\
SYMLINK+="input/beagle-barcode", TAG+="systemd",\
ENV{SYSTEMD_WANTS}="beagle-tester.service"
KERNEL=="event*", ATTRS{idVendor}=="24ea", ATTRS{idProduct}=="0197",\
SYMLINK+="input/beagle-barcode", TAG+="systemd",\
ENV{SYSTEMD_WANTS}="beagle-tester.service"


You can see I also use the insertion of the barcode scanner to startup the
beagle-tester.service (
https://github.com/jadonk/beagle-tester/blob/master/beagle-tester.service):

[Unit]
Description=Beagle Self-test
Requires=dev-input-beagle\x2dbarcode.device
BindsTo=dev-input-beagle\x2dbarcode.device
[Service]
ExecStart=/usr/sbin/beagle-tester

In my C program (
https://github.com/jadonk/beagle-tester/blob/master/beagle-tester.c#L3119),
I just open up the symlink:

int barcode = open("/dev/input/beagle-barcode", O_RDONLY);
The path shouldn't change based on if you invoke the program from the
console or by a crontab, but it could change due to adding/removing input
devices. I suggest you look at my udev-rule + systemd method of invocation
and see if that makes it more stable. The VID/PID entries in the udev rules
are based on which barcode scanners I've used/tested. You can make a more
generic rule to try to catch more input devices.

Note, these rules come pre-installed on the Debian images, so they might
actually be getting in your way already! We use these in production tests
of the boards.



> --
> Don Pancoe, P.E.
> Industrial Designer, Electrical Engineer
> DonPancoe.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/CAP3tSUPTTQn7bZ_M53vRGzbdKgeSzefu_%2BDvTT4gDLE5rSp14A%40mail.gmail.com
> 
> .
>


-- 
https://beagleboard.org/about - 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/CA%2BT6QPkSbPjvEXY_HXHUC90%3Dek0EX2YO6JYG_2MszpfcP%3DY5fA%40mail.gmail.com.

Re: [beagleboard] UIO PRU driver on Beaglebone AI

[Jason Kridner]

> On Apr 9, 2020, at 12:54 PM, John Allwine  wrote:
> 
> 
> The PRU code for hal_pru_generic is here: 
> https://github.com/machinekit/machinekit-hal/tree/master/src/hal/drivers/hal_pru_generic
> 
> You'll see a number of .p files and they are assembled using pasm, the source 
> code for which is also in the machinekit repository: 
> https://github.com/machinekit/machinekit-hal/tree/master/src/hal/support/pasm
> 
> The copyrights at the top of the pasm source are by TI, so I imagine this was 
> copied from somewhere else. I don't see a way to compile the pru code down to 
> elf format using pasm, which is what it appears I need in order to use 
> remoteproc. Is there another tool I can use to compile/assemble the .p files? 
> Alternatively, is there another tool I can use to convert the compiled .bin 
> file to an elf file?

You’ll likely need to convert the syntax to get elf. You can use pru-gcc or 
clpru (TI).

 I’d recommend giving pru-gcc a shot. It is available to run on BeagleBone AI 
in the Debian package feed. 

I’d further recommend just switching to C with inline assembly. 


> 
>> On Wednesday, April 8, 2020 at 1:23:48 PM UTC-6, John Allwine wrote:
>> The hal_pru_generic PRU code is all written in assembly and is compiled down 
>> to a .bin file. Copying that bin file to the firmware doesn't work. On the 
>> Beaglebone Black the contents of the bin file are copied to the appropriate 
>> address in memory in order to load it onto the PRU. What do I have to do to 
>> this bin file in order to be able to copy it to 
>> /lib/firmare/am57xx-pru1_1-fw (or one of the other 3 pru options) and then 
>> start it with remoteproc?
>> 
>>> On Wednesday, April 8, 2020 at 12:45:33 AM UTC-6, Jason Kridner wrote:
>>> On Wed, Apr 8, 2020 at 12:28 AM John Allwine  
>>> wrote: 
>>> > 
>>> > Thanks Jason! I’ve found enough info on the pinmux to get me by for now. 
>>> > hal_pru_generic and the PRUs seem to be the big blocker at this point. I 
>>> > still need to get my head around the details of hal_pru_generic to know 
>>> > if using remoteproc would work. How do I use remoteproc to run code on 
>>> > the PRU? 
>>> 
>>> Check out 
>>> https://github.com/beagleboard/cloud9-examples/tree/v2020.01/BeagleBone/AI/pru
>>>  
>>> 
>>> PRU start script in the Makefile is at 
>>> https://github.com/beagleboard/cloud9-examples/blob/v2020.01/common/Makefile#L164-L167
>>>  
>>> 
>>> > 
>>> > > On Apr 7, 2020, at 9:57 PM, Jason Kridner  
>>> > > wrote: 
>>> > > 
>>> > > On Tue, Apr 7, 2020 at 11:27 PM John Allwine 
>>> > >  wrote: 
>>> > >> 
>>> > >> Is there a UIO PRU driver for the Beaglebone AI? How do I enable it? 
>>> > >> I'm trying to be able to talk to the PRUs using hal_pru_generic on the 
>>> > >> the Beaglebone AI, which does so on the BBB using the uio_pruss 
>>> > >> module. On the AI I see a uio_pruss_shmem module loaded when looking 
>>> > >> at /proc/modules, is that the same thing? 
>>> > > 
>>> > > This custom little uio_pruss_shmem driver will go away as a different 
>>> > > existing uio driver can be configured to provide uio shared memory 
>>> > > access without interfering with the remoteproc driver's ability to 
>>> > > load the PRU code. 
>>> > > 
>>> > > It is largely the same as the uio_pruss module, but the memory region 
>>> > > shared does not include the control registers needed to load code and 
>>> > > start/stop the processor. That can be done with the remoteproc 
>>> > > mechanisms. 
>>> > > 
>>> > > Will this work for you? 
>>> > > 
>>> > > BTW, sorry I never got back to you on the pinmux stuff. It keeps 
>>> > > dropping from my plate as I seem to always have something more urgent 
>>> > > to do at any given moment. Can you throw a meeting time on my calendar 
>>> > > if you still need this and we can make it a live working session? The 
>>> > > pinmux thing isn't complicated, but I have to look around in a bunch 
>>> > > of places to gather the right bits. 
>>> > > 
>>> > >> 
>>> > >> I can run the following commands on the AI: 
>>> > >> 
>>> > >> cat /sys/class/uio/uio0/maps/map0/addr 
>>> > >> 0x4b20 
>>> > >

Re: [beagleboard] Superuser

[Jason Kridner]

This answer seems appropriate:
https://askubuntu.com/questions/452860/usr-bin-sudo-must-be-owned-by-uid-0-and-have-the-setuid-bit-set

On Wed, Apr 8, 2020 at 11:49 AM  wrote:
>
>
> I would like to be Superuser on my BeagleBone Green W and Debian 9.9 LXQT - 
> currently I get the message "sudo: /usr/bin/sudo must be owned by uid 0 and 
> have the setuid bit set" when I try.
>
> How could I change these permissions and become superuser
>
> --
> 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/05c7784d-fda0-43fb-9640-a00310e06203%40googlegroups.com.



-- 
https://beagleboard.org/about - 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/CA%2BT6QPkyymCnCpaq2YEqCojw8UbMEpAL68d8KzkmfQp7OHQ82w%40mail.gmail.com.

Re: [beagleboard] UIO PRU driver on Beaglebone AI

[Jason Kridner]

On Wed, Apr 8, 2020 at 12:28 AM John Allwine  wrote:
>
> Thanks Jason! I’ve found enough info on the pinmux to get me by for now. 
> hal_pru_generic and the PRUs seem to be the big blocker at this point. I 
> still need to get my head around the details of hal_pru_generic to know if 
> using remoteproc would work. How do I use remoteproc to run code on the PRU?

Check out 
https://github.com/beagleboard/cloud9-examples/tree/v2020.01/BeagleBone/AI/pru

PRU start script in the Makefile is at
https://github.com/beagleboard/cloud9-examples/blob/v2020.01/common/Makefile#L164-L167

>
> > On Apr 7, 2020, at 9:57 PM, Jason Kridner  wrote:
> >
> > On Tue, Apr 7, 2020 at 11:27 PM John Allwine  
> > wrote:
> >>
> >> Is there a UIO PRU driver for the Beaglebone AI? How do I enable it? I'm 
> >> trying to be able to talk to the PRUs using hal_pru_generic on the the 
> >> Beaglebone AI, which does so on the BBB using the uio_pruss module. On the 
> >> AI I see a uio_pruss_shmem module loaded when looking at /proc/modules, is 
> >> that the same thing?
> >
> > This custom little uio_pruss_shmem driver will go away as a different
> > existing uio driver can be configured to provide uio shared memory
> > access without interfering with the remoteproc driver's ability to
> > load the PRU code.
> >
> > It is largely the same as the uio_pruss module, but the memory region
> > shared does not include the control registers needed to load code and
> > start/stop the processor. That can be done with the remoteproc
> > mechanisms.
> >
> > Will this work for you?
> >
> > BTW, sorry I never got back to you on the pinmux stuff. It keeps
> > dropping from my plate as I seem to always have something more urgent
> > to do at any given moment. Can you throw a meeting time on my calendar
> > if you still need this and we can make it a live working session? The
> > pinmux thing isn't complicated, but I have to look around in a bunch
> > of places to gather the right bits.
> >
> >>
> >> I can run the following commands on the AI:
> >>
> >> cat /sys/class/uio/uio0/maps/map0/addr
> >> 0x4b20
> >>
> >> cat /sys/class/uio/uio0/maps/map0/size
> >> 0x0002
> >>
> >> cat /sys/class/uio/uio1/maps/map0/addr
> >> 0x4b28
> >>
> >> cat /sys/class/uio/uio1/maps/map0/size
> >> 0x0002
> >>
> >> The size on both of those seem small as the PRUSS_INTC region starts at 
> >> 0x0002 according to the AM572x Technical Reference Manual on page 418 
> >> (and on the Beaglebone Black the PRU uio size is 0x0008).
> >>
> >> Anyway, I'm not very familiar with things at this level, so I may not be 
> >> phrasing my questions well, but any help is appreciated!
> >>
> >> --
> >> 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/02eb6681-dcac-4ad2-a45c-fa27a2e346f3%40googlegroups.com.
> >
> >
> >
> > --
> > https://beagleboard.org/about - 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/CA%2BT6QPnMrcQTc8jFkoGncpMZ18O7eSQf_Wm5Bw2KH4PMUFhsrA%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/396383D5-0B85-40C4-84D3-1AC9FAE2BF29%40allwinedesigns.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/CA%2BT6QPnhPNoK6JDsW3USgZmhtSDEOhqDnCi5AoJzhQKaS6Ajgw%40mail.gmail.com.

Re: [beagleboard] UIO PRU driver on Beaglebone AI

[Jason Kridner]

On Tue, Apr 7, 2020 at 11:27 PM John Allwine  wrote:
>
> Is there a UIO PRU driver for the Beaglebone AI? How do I enable it? I'm 
> trying to be able to talk to the PRUs using hal_pru_generic on the the 
> Beaglebone AI, which does so on the BBB using the uio_pruss module. On the AI 
> I see a uio_pruss_shmem module loaded when looking at /proc/modules, is that 
> the same thing?

This custom little uio_pruss_shmem driver will go away as a different
existing uio driver can be configured to provide uio shared memory
access without interfering with the remoteproc driver's ability to
load the PRU code.

It is largely the same as the uio_pruss module, but the memory region
shared does not include the control registers needed to load code and
start/stop the processor. That can be done with the remoteproc
mechanisms.

Will this work for you?

BTW, sorry I never got back to you on the pinmux stuff. It keeps
dropping from my plate as I seem to always have something more urgent
to do at any given moment. Can you throw a meeting time on my calendar
if you still need this and we can make it a live working session? The
pinmux thing isn't complicated, but I have to look around in a bunch
of places to gather the right bits.

>
> I can run the following commands on the AI:
>
> cat /sys/class/uio/uio0/maps/map0/addr
> 0x4b20
>
> cat /sys/class/uio/uio0/maps/map0/size
> 0x0002
>
> cat /sys/class/uio/uio1/maps/map0/addr
> 0x4b28
>
> cat /sys/class/uio/uio1/maps/map0/size
> 0x0002
>
> The size on both of those seem small as the PRUSS_INTC region starts at 
> 0x0002 according to the AM572x Technical Reference Manual on page 418 
> (and on the Beaglebone Black the PRU uio size is 0x0008).
>
> Anyway, I'm not very familiar with things at this level, so I may not be 
> phrasing my questions well, but any help is appreciated!
>
> --
> 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/02eb6681-dcac-4ad2-a45c-fa27a2e346f3%40googlegroups.com.



-- 
https://beagleboard.org/about - 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/CA%2BT6QPnMrcQTc8jFkoGncpMZ18O7eSQf_Wm5Bw2KH4PMUFhsrA%40mail.gmail.com.

Re: [beagleboard] CLoud9 TIDL example sees CMEM Error after recent upgrade

[Jason Kridner]

On Fri, Mar 27, 2020 at 7:07 AM Jason Kridner 
wrote:

> Any thoughts on making it more generic? Select the highest index?
>
> On Thu, Mar 26, 2020 at 10:22 PM jonnymo  wrote:
>
>> In the GitHub issue that was filed, I noted the following which seems to
>> get the camera active again:
>>
>>
>>
>> Setting '-d /dev/video1' in the common Makefile seemed to do the trick. I
>> now have video from the camera in the TIDL example.
>>
>> This is what I changed at line 170 in the Makefile at:
>> /var/lib/cloud9/common$
>>
>> else ifeq ($(PROC),tidl)
>> ti-mct-heap-check -c
>> sudo mjpg_streamer -i "input_opencv.so -d /dev/video1 -r 640x480 
>> --filter ./$(TARGET)$(EXE)" -o "output_http.so -p 8080 -w 
>> /usr/share/mjpg-streamer/www"
>> else
>>
>>
>>
Perhaps not the best, but here's my stab at making it continue to work with
older kernels:

commit 06c70c2b6a9573a6c72968bce725d30d09cbfe8a
Author: Jason Kridner 
Date:   Fri Mar 27 18:13:10 2020 +

Remove usage of VPE in running TIDL examples

diff --git a/common/Makefile b/common/Makefile
index 5a2b886..c1a0982 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -167,7 +167,8 @@ ifneq ($(PRU_DIR),)
@echo start > $(PRU_DIR)/state
 else ifeq ($(PROC),tidl)
ti-mct-heap-check -c
-   sudo mjpg_streamer -i "input_opencv.so -r 640x480 --filter
./$(TARGET)$(EXE)" -o "output_http.so -p 8090 -w
/usr/share/mjpg-streamer/www"
+   sudo mjpg_streamer -i "input_opencv.so -r 640x480 -d /dev/$(shell
fgrep -v vpe /sys/class/video4linux/video*/name | perl -ne
'/\/(video\d+)\/name/ && print $$1') \
+   --filter ./$(TARGET)$(EXE)" -o "output_http.so -p 8090 -w
/usr/share/mjpg-streamer/www"
 else
./$(TARGET)$(EXE)
 endif


As I look at this, I think it would fail if there were just 2 non-vpe
interfaces.

There has to be a relatively easy way to pick the first webcam.



>
>> On Thu, Mar 26, 2020 at 9:20 AM Robert Nelson 
>> wrote:
>>
>>> On Thu, Mar 26, 2020 at 10:27 AM  wrote:
>>> >
>>> > Hi,
>>> > I just came across this post that is relevant to the same problem. I
>>> just started working on this Beaglebone AI two days ago. I got the latest
>>> os image and updates and upgrades everything. I tried
>>> classification.tidl.cpp and I got the same last message that Jon Morss
>>> got.  And your latest message was about /dev/video0. On my board I got
>>> /dev/video0, /dev/video1 and it does recognize the camera. Do you mean that
>>> I can fix it with the change to the default dev for the camera ? And where
>>> can I change that? I worked with OpenCV and this VideoCapture::open()
>>> failed message seems to indicate a wrong /dev/video index?
>>>
>>> Please submit a bug to:
>>>
>>> https://github.com/beagleboard/cloud9-examples
>>>
>>> the classification demo should allow you to specify a video offset..
>>>
>>> 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/CAOCHtYjyA8yTBWKs-%3DFUoE4kh20XgiQNpheJLfnzHG7_ouqVNA%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/CAG99bko9Nkz-Jb%2BnBYd-RvhBzGhNHJMkv1%2B7bVcn6hLdaqDcTA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/beagleboard/CAG99bko9Nkz-Jb%2BnBYd-RvhBzGhNHJMkv1%2B7bVcn6hLdaqDcTA%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
> --
> https://beagleboard.org/about - a 501c3 non-profit educating around open
> hardware computing
>


-- 
https://beagleboard.org/about - 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/CA%2BT6QPkAeEiaNK-ULejZqiUR6pZuTt2J5egr20BM%2BC7%2BDLfdug%40mail.gmail.com.

Re: [beagleboard] how to access GPIO on Beaglebone AI via /dev/mem

[Jason Kridner]

Dynamic pinmux changes on AM5x have issues specific to AM5x.

For GPIO, accessing via register writes in userspace (/dev/mem) has no more
negative consequences than on AM3x or on any system running Linux for that
matter. Standard caveats apply.

Ideally, we’d create a kernel module to avoid latency and keep kernel
resource control. This doesn’t have to be that complicated. In short of
that, the same old hacks will work fine on AM5x—just don’t touch the pinmux
without doing a LOT more digging.

On Fri, Mar 27, 2020 at 5:52 AM Drew Fustini  wrote:

> You my want to consider using libgpiod with the /dev/gpiochipN character
> device.  You can get and set multiple lines in one syscall.
>
> The libgpiod tools are installed on the Debian image.
>
> More info:
>
> https://www.cnx-software.com/2017/11/03/learn-more-about-linuxs-new-gpio-user-space-subsystem-libgpiod/
>
> On Fri, Mar 27, 2020, 09:30 Stephan Böck  wrote:
>
>> Hello Robert,
>>
>> if I get this correctly, setting the direction of a gpio via the
>> corresponding register (e.g. let's say gpio4 base_addr + 0x134) should be
>> avoided?
>>
>> We use the BBB in combination with a carrier-board to have some
>> industrial in- and outputs. Therefore, some pins enable some flipflops
>> during initialization (the pins need to be outputs). These pins are later
>> on used as inputs. The current implementation manages all this with an
>> assembly program running on the pru and directly setting the right bits in
>> the different registers of the gpios.
>> Now, I want to port this to the BB AI. Since direct access causes
>> trouble, is there a better practise, than setting the direction/value of a
>> gpio via /sys/class/gpio?
>>
>> Regards,
>> Stephan
>>
>>
>> Am Donnerstag, 26. März 2020 15:26:56 UTC+1 schrieb RobertCNelson:
>>>
>>> On Thu, Mar 26, 2020 at 9:20 AM John Allwine 
>>> wrote:
>>> >
>>> > Is it possible to access the GPIO on the Beaglebone AI via /dev/mem
>>> similar to how it is done in this stackoverflow question on the Beaglebone
>>> Black? If so, how would I find what the offsets are?
>>>
>>> Hi John,
>>>
>>> dynamic changes to the am57xx's pinmux registers and gpio values is a
>>> bad idea..
>>>
>>> Figure out what you need and set them up in the device tree.
>>>
>>> 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/2ee15690-0da0-4cc0-889b-6f3c8326c5aa%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/CAEf4M_DgSg%3Dse0LCpsB%2BzV5sAq4-SphR6tNKiECd29jqOFwAOw%40mail.gmail.com
> 
> .
>
-- 
https://beagleboard.org/about - 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/CA%2BT6QPnUBffM0RE8CETw5PtcNPFaH2ntrptm7D1pJApazWOBYA%40mail.gmail.com.

Re: [beagleboard] CLoud9 TIDL example sees CMEM Error after recent upgrade

[Jason Kridner]

Any thoughts on making it more generic? Select the highest index?

On Thu, Mar 26, 2020 at 10:22 PM jonnymo  wrote:

> In the GitHub issue that was filed, I noted the following which seems to
> get the camera active again:
>
>
>
> Setting '-d /dev/video1' in the common Makefile seemed to do the trick. I
> now have video from the camera in the TIDL example.
>
> This is what I changed at line 170 in the Makefile at:
> /var/lib/cloud9/common$
>
> else ifeq ($(PROC),tidl)
> ti-mct-heap-check -c
> sudo mjpg_streamer -i "input_opencv.so -d /dev/video1 -r 640x480 
> --filter ./$(TARGET)$(EXE)" -o "output_http.so -p 8080 -w 
> /usr/share/mjpg-streamer/www"
> else
>
>
>
> On Thu, Mar 26, 2020 at 9:20 AM Robert Nelson 
> wrote:
>
>> On Thu, Mar 26, 2020 at 10:27 AM  wrote:
>> >
>> > Hi,
>> > I just came across this post that is relevant to the same problem. I
>> just started working on this Beaglebone AI two days ago. I got the latest
>> os image and updates and upgrades everything. I tried
>> classification.tidl.cpp and I got the same last message that Jon Morss
>> got.  And your latest message was about /dev/video0. On my board I got
>> /dev/video0, /dev/video1 and it does recognize the camera. Do you mean that
>> I can fix it with the change to the default dev for the camera ? And where
>> can I change that? I worked with OpenCV and this VideoCapture::open()
>> failed message seems to indicate a wrong /dev/video index?
>>
>> Please submit a bug to:
>>
>> https://github.com/beagleboard/cloud9-examples
>>
>> the classification demo should allow you to specify a video offset..
>>
>> 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/CAOCHtYjyA8yTBWKs-%3DFUoE4kh20XgiQNpheJLfnzHG7_ouqVNA%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/CAG99bko9Nkz-Jb%2BnBYd-RvhBzGhNHJMkv1%2B7bVcn6hLdaqDcTA%40mail.gmail.com
> 
> .
>
-- 
https://beagleboard.org/about - 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/CA%2BT6QPmDfKm3EufGri%3DYqkerefqhrfv_Be8rMVR4Rvm9Yi2_JA%40mail.gmail.com.

Re: [beagleboard] Re: BBAI and Updating to Stop the Heat Transfer at https://beagleboard.org/upgrade

[Jason Kridner]

I'm sure there's probably a better thread, but this one is the first one
that came up for me.

The Fan Cape is finally in stock at Newark:
https://www.newark.com/element14/6100310/beaglebone-ai-fan-cape/dp/50AH3704

Not sure when other distributors will have stock.


On Tue, Mar 3, 2020 at 7:42 PM Mala Dies  wrote:

> Hello,
>
> Here it is:
>
>
> 
> |Thermal zone   |temp   |mode   |cdev0_type |cdev1_type
>
> 
> |cpu_thermal|38600  |enabled|thermal-cpufreq-0  |
>  |passive:55000|critical:85000|
> |gpu_thermal|38600  |enabled|   |
>  |critical:85000|
> |core_thermal   |38600  |enabled|   |
>  |critical:85000|
> |dspeve_thermal |37800  |enabled|   |
>  |critical:85000|
> |iva_thermal|39000  |enabled|   |
>  |critical:85000|
>
> 
> |Cooling type   |state  |max_state  |
>
> 
> |thermal-cpufreq-0  |0  |3  |
>
> ----
>
> Enjoy,
>
> Seth
>
>
>
> On Monday, January 27, 2020 at 9:07:33 AM UTC-6, Jason Kridner wrote:
>>
>> Perhaps:
>>
>> watch /opt/scripts/device/x15/test_thermal.sh
>>
>> ?
>>
>>
>> The output of 'test_thermal.sh' would really be helpful for those
>> complaining about the heat. The update should stop it from overheating, at
>> least in a room temperature environment. That doesn't mean it won't be hot
>> to the touch... just not so hot that it will need to shutdown.
>>
>> Can I get some more feedback on this?
>>
>> Sorry for the VERY LONG delay on the Fan Cape. Chinese New Year recently
>> entered the reasons for delay, but it is coming. The other big missing
>> thing for BBAI is the Python Tensorflow library, which is also coming. I'll
>> be talking a lot more about BBAI once the two of those are out there.
>>
>> Anyway, just running the update should give you a nice solution for
>> running "regular" code. Please explain to me if that really isn't the case.
>>
>> On Mon, Jan 27, 2020 at 6:42 AM Mala Dies  wrote:
>>
>>> Hello,
>>>
>>> No...this fellow gave me a script to test for temp. continuously.
>>>
>>> Seth
>>>
>>> On Monday, January 20, 2020 at 8:19:00 AM UTC-6, IO wrote:
>>>>
>>>> You mean, by running cat
>>>> /sys/devices/virtual/thermal/thermal_zone0/temp ?
>>>>
>>>> On Sunday, January 19, 2020 at 7:54:46 PM UTC+2,
>>>> se...@lafayette-parish.com wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> Just an update, if you run the temp. sensors onboard the AI and run
>>>>> the fan, on my end, you will receive a 38c or below temp. for the board
>>>>> chips and surrounding area.
>>>>>
>>>>> Seth
>>>>>
>>>>> P.S. Nice! Fans!
>>>>>
>>>>> On Thursday, January 2, 2020 at 1:18:29 AM UTC-6, Mala Dies wrote:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> Thank you for this update. I did update the board already as the link
>>>>>> suggested. My fan was a 24v fan. I need to get another fan.
>>>>>>
>>>>>> Seth
>>>>>>
>>>>>> P.S. I might get the digikey.com fan you have listed. Anyway, if
>>>>>> anyone has any other ideas, shoot!
>>>>>>
>>>>>> On Sunday, December 29, 2019 at 5:30:02 PM UTC-6, jonnymo wrote:
>>>>>>>
>>>>>>> Jason recently posted an update regarding the Fan Cape he is working
>>>>>>> on.
>>>>>>> In the mean time, he recommended the Coolerguys USB fan that is
>>>>>>> listed in the BBAI FAQ:
>>>>>>>
>>>>>>> https://github.com/beagleboard/beaglebone-ai/wiki/Frequently-Asked-Questions#fans
>>>>>>>
>>>>>>> https://www.coolerguys.

[beagleboard] Online training update

[Jason Kridner]

https://beagleboard.org/blog/2020-03-18-online-training-update

As mentioned in my New Year’s resolution 
, I’m 
going to launch some online training for embedded Linux development.


Yes, this training will happen. Interest continues to build. At this point, 
I’m delaying until the first of our triannual image releases 

 comes 
out next month to align with the latest software release. I’m also fixing 
an issue with the TechLab boards being improperly classified for export, 
preventing shipments to some countries. I’m also working on getting a few 
more of these into distribution as I expect we’ll run out with everyone 
looking to do this training.


To make sure you don’t miss out, subscribe to the blog at 
beagleboard.org/blog.


Here’s a bit more on the format:
• It will be done as YouTube “premieres” 
 of 30 minute videos with live chat
• There will be an extra 30 minutes of live chat on beagleboard.org/chat
• On-going discussion on beagleboard.org/discuss under “Training”
• First session built on PocketBeagle TechLab 
 materials
from e-ALE workshops
[image: ➡] Kits will be available via a Digi-Key shopping cart 

PocketBeagle® and TechLab Workshop Setup

Feel free to get kits now, but I’ll try to include time to acquire kits 
after the first video. The first video will be more of an introduction to 
the concept and BeagleBoard.org. I’ll announce here on this blog when the 
first video is scheduled to premiere and will give at least a week’s notice.


As of now, some topics to be covered include:
[image: ➡] Use Linux command-line and explore file system
[image: ➡] Program basic Linux interfaces in JavaScript/Node-RED and Python
[image: ➡] Program PRUs using C
[image: ➡] Start writing kernel drivers in 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/70021e0c-e729-4ce3-a479-8a99868acace%40googlegroups.com.

Re: [beagleboard] loading firmware fails with error -22

[Jason Kridner]

On Thursday, March 19, 2020 at 2:46:41 PM UTC-4, Jason Kridner wrote:
>
>
>
> On Thursday, March 19, 2020 at 12:28:55 PM UTC-4, RobertCNelson wrote:
>>
>> On Thu, Mar 19, 2020 at 11:01 AM  wrote: 
>> > 
>> > Tried it with bone-debian-10.3-iot-armhf-2020-03-16-4gb.img. Same 
>> thing: copying over firmware fixed it. 
>>
>> Now that i think about it. The udev rule, to set the permissions is 
>> only triggered when the firmware exists. 
>>
>> Not sure how we actually fix your issue, beside shipping a default 
>> firmware..  We could do a blank, "nop" firmware, by default??? (or 
>> would this kill power?)  Then the remoteproc presmissions would be 
>> properly set. 
>>
>>
>>
> What would you think about a default firmware that provided some response 
> to pokes to /dev/rpmsg_pru30 and /dev/rpmsg_pru31?
>
> I started some hacks to try to make a "pruspeak" instance on the PRUs as 
> examples, but haven't finished: 
> https://github.com/beagleboard/cloud9-examples/blob/v2020.01/PocketBeagle/pru/.work-in-progress/pruspeak.pru0.c
>
> What if we just made some simple echo servers that would allow you to see 
> the PRU is alive? Maybe we could look at the power impact, but I'd expect 
> it to be very minor.
>
> I'm happy if there are other default candidates, like libpruio, but we 
> need to be careful they don't interfere with the Linux peripheral accesses.
>
> For my PRU workshops on PocketBeagle TechLab, I've been using 
> https://github.com/beagleboard/cloud9-examples/blob/v2020.01/PocketBeagle/TechLab/sleep.pru0.c
>  to 
> stop the PRU so that it isn't doing anything. 
>
> Install is 'make -f /var/lib/cloud9/common/Makefile TARGET=sleep.pru0' 
> from within that directory.
>
> Doh! It highlights an unmet dependency I made in the latest Makefile on 
> /usr/share/ti/starterware/pru/libdrivers.a.  That library isn't that 
> useful, so I need to remove it.
>

Double-ugh. PocketBeagle/TechLab/.challenges/analogIn.pru0.c depends on the 
staterware header files. I'll need to either use different header files or 
add Starterware. :-( 

-- 
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/c9913dca-0079-4759-b210-a76fc97fc2c2%40googlegroups.com.

Re: [beagleboard] loading firmware fails with error -22

[Jason Kridner]

On Thursday, March 19, 2020 at 12:28:55 PM UTC-4, RobertCNelson wrote:
>
> On Thu, Mar 19, 2020 at 11:01 AM  wrote: 
> > 
> > Tried it with bone-debian-10.3-iot-armhf-2020-03-16-4gb.img. Same thing: 
> copying over firmware fixed it. 
>
> Now that i think about it. The udev rule, to set the permissions is 
> only triggered when the firmware exists. 
>
> Not sure how we actually fix your issue, beside shipping a default 
> firmware..  We could do a blank, "nop" firmware, by default??? (or 
> would this kill power?)  Then the remoteproc presmissions would be 
> properly set. 
>
>
>
What would you think about a default firmware that provided some response 
to pokes to /dev/rpmsg_pru30 and /dev/rpmsg_pru31?

I started some hacks to try to make a "pruspeak" instance on the PRUs as 
examples, but haven't finished: 
https://github.com/beagleboard/cloud9-examples/blob/v2020.01/PocketBeagle/pru/.work-in-progress/pruspeak.pru0.c

What if we just made some simple echo servers that would allow you to see 
the PRU is alive? Maybe we could look at the power impact, but I'd expect 
it to be very minor.

I'm happy if there are other default candidates, like libpruio, but we need 
to be careful they don't interfere with the Linux peripheral accesses.

For my PRU workshops on PocketBeagle TechLab, I've been using 
https://github.com/beagleboard/cloud9-examples/blob/v2020.01/PocketBeagle/TechLab/sleep.pru0.c
 to 
stop the PRU so that it isn't doing anything. 

Install is 'make -f /var/lib/cloud9/common/Makefile TARGET=sleep.pru0' from 
within that directory.

Doh! It highlights an unmet dependency I made in the latest Makefile on 
/usr/share/ti/starterware/pru/libdrivers.a.  That library isn't that 
useful, so I need to remove it.

-- 
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/b01af03f-5459-4c37-9d24-c1a0518f5312%40googlegroups.com.

[beagleboard] Re: [Machinekit] Seeed to design and build Machinekit focused Cape for BeagleBone Black/AI

[Jason Kridner]

I think we have to reliably enable hobby-class machines first. Now, some
people take hobby pretty far and I'm not trying to cap this off too small,
I just don't want to boil the oceans. I'd say if we can do a bit more than
what CRAMPS can do today, we should.

Personally, I'd want to at least be able to handle the larger 3D printers,
smaller CNC mills and some pick-and-place machines. Looking around for some
open source ones where the controller could be swapped:
* Aleph Objects LulzBot Tax Pro
* SeeMeCNC Rostock Max v3
* PocketNC V2
* Charmhigh CHM-T36VA (not open source, but affordable and hackable)
* Lasersaur

The desire for the above is mostly to be a vehicle for demonstrating motion
control in a familiar way. Something CRAMPS-like could largely serve the
above, though would need to be done regarding the price to make it
sufficiently attractive, perhaps bundling as a kit.

Getting to the standard DB25 seems like a required thing to be widely
usable in the community, no?

This all said, I think handling BLDC motors or even small AC motors with
encoders and adding software motor control functions would be fantastic and
would give some important examples to the community. What I need to try to
understand the requirements are examples like the above. Then we can add up
all the I/Os, required currents/voltages, look at the encoder protocols,
etc. and arrive at a sane set of compromises.

If I go look around a place like
https://openbuildspartstore.com/openbuilds-c-beam-machine/, it seems all
their machines use steppers.

Looking around https://odriverobotics.com/, perhaps this stuff just hasn't
become popular with hobbyists yet? Can we get a sane set of requirements on
what motors we need to drive and encoders we need to support? Are hobby
motors like
https://hobbyking.com/en_us/9235-100kv-turnigy-multistar-brushless-multi-rotor-motor.html
really
available in a steady supply (I've had issues with this in my quadcopters)?

If there was a solution for 48V BLDC motors w/ encoders, would people start
building something or am I just missing where all these machines are
already? (Help me find them.) Would it use something like
http://www.machinekit.io/docs/man/man9/bldc_hall3v2/ or something else?

/me reads
https://www.reddit.com/r/AskEngineers/comments/4qx9b0/why_arent_brushless_dc_motors_more_commonly_used/

Man, I think I'm about to step in an ants nest wondering about BLDC vs. why
not just control AC servo motors, but why not?

Looking around for some decision factors on motor type support, I found an
add for the ClearPath motors that clarified some things for me:
https://www.youtube.com/watch?v=zUy89MT_Rkk. Looking around a bit more, I
found on this discussion form a message where Rick Mann got those ClearPath
motors working with his BeagleBone.

Anyway, I'd expect there to be a sweet spot for a motor power range and
amount of integration suitable to be covered, though perhaps we are talking
about needing 2-3 cape designs to be available based on how different some
requirements are? Is there real value in providing just the DB25?

Once I can gather a bit more feedback, I'll come up with a good mechanism
for a survey. I'm really looking for those open hardware examples sitting
at higher power than the examples I gave that are nicely handled by
steppers.


On Tue, Mar 17, 2020 at 11:31 PM Charles Steinkuehler <
char...@steinkuehler.net> wrote:

> This depends a lot on what sort of machine you're trying to drive.  A
> "standard" CNC machine with step/dir typically needs a DB25 (aka:
> parallel port) with buffered signals you can connect to external stepper
> drivers.  A 3D printer would more typically have low-powered "Pololu"
> style drivers either on-board or via sockets along with some high power
> outputs for the extruder and bed heaters.  A more advanced system might
> provide a control signal (+/- 10V, or perhaps PWM) to drive a motor
> driver and provide for encoder feedback to close the servo loop.
>
> ...so it really depends on what sort of system(s) you want to support,
> and how much you want to try to be a "one size fits all" solution.
>
> On 3/12/2020 8:38 AM, Jason Kridner wrote:
> > Seeed is looking to not only build a Machinekit-focused Cape for
> BeagleBone
> > Black and BeagleBone AI, but to:
> > * Take in features and feedback from the community
> > * Contribute the design to open source and certify it as such
> > * Manufacture the design under the BeagleBoard.org name to support the
> > BeagleBoard.org Foundation and community
> > * Help assemble and provide software images configured for an open source
> > 3D printer and CNC machine (with BeagleBoard.org and community guidance
> and
> > support)
> > * Offer a collection of additional accessories which might commonly be
> > needed
> >
> > I am very excited about this because 

[beagleboard] Re: [Machinekit] Seeed to design and build Machinekit focused Cape for BeagleBone Black/AI

[Jason Kridner]

f $300 is the expectation with 4.3" display and USB port for G-Code, then
let's work together to set the requirements appropriately.


>
>
> To have all the above I/O requires a lot of pins.  I'm not sure the BBB
> can do this all.  Unless it uses 10Mhz SPI to a serial shift register
> latch to create 6 axis STEP/DIR/PWM for X,Y,Z,A,B and Spindle along with
> coolant outputs to a maximum of 16 outputs.  Since SPI is in and out the
> system can just as easily hold a 16 bit latch that is shifted in at the
> same time holding the various inputs except for ESTOP and maybe a MACHINE
> ON switch.
>
>
>
> Some of the features on the PMDX-126 break out board could be part of this
> cape.  In fact the idea that perhaps a simple I/O bus structure be
> designed in is a really good idea.  A bi-directional 8 bit bus with a 4
> bit address bus along with RD/WR/ signals would allow LCD displays and
> other external add on devices.  The PIC32 for example supports that sort
> of bus.  I think the ARM on the Beagle does too but it may not be
> available.
>

Worth exploring what we can do to effectively generate such an expansion. I
think there are many options for it.


>
>
> So this cape would look a lot more like a PMDX-126 but be that large BoB
> cape for the Beagle.  It would have the I/O and maybe even high voltage
> relays along with optically isolated I/O.
>
> https://www.pmdx.com/PMDX-126
>
> The photos show how the PMDX has an expansion bus and a set of connectors
> that are compatible for a smooth stepper.
>
>
>
> Perhaps make the BBB the replacement for the Smooth Stepper and the cape
> the replacement for a much more extensive PMDX-126.  And use the BBB
> Ethernet connection to be the interface, if CNC is wanted, to MachineKit
> or LinuxCNC or even maybe MACH4 too.   Give the BBB cape a display output
> for rudimentary DRO and control information but for full CNC let a
> processor like Raspberry Pi4 or PC with much better decent HDMI control
> serve as the graphical and keyboard/mouse user input.
>
>
>
> The need for the BBB to do everything just doesn't exist anymore when that
> Pi4 only adds $50 to the price and the display/keyboard/mouse are fixed
> costs no matter what system is used.
>

I'd agree with that. The BeagleBone Black should really be valuable for its
ability to act as the real-time controller, not as the UI. BeagleBone AI
should be able to do both and also potentially introduce some kind of
preventive maintenance modes, tough greater stepper driver/motor feedback
would be needed.


>
>
> Make the system stand alone and scalable so a user can first add just a
> motor to their X axis for power feed.  Six monts later the Y axis for
> power feed.  Then a year later the Z axis for power feed.   When they
> swap in a 3 phase or AC servo motor onto the spindle they suddenly have
> on/off speed control and now the potential to add simple CNC operations.  Some
> of those could even be local like the wizards in MACH3/4.
>
>
>
> IMHO
>
> John Dammeyer
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *From:* machine...@googlegroups.com [mailto:machine...@googlegroups.com] *On
> Behalf Of *Jason Kridner
> *Sent:* March-12-20 6:39 AM
> *To:* machine...@googlegroups.com
> *Cc:* beagleboard@googlegroups.com
> *Subject:* [Machinekit] Seeed to design and build Machinekit focused Cape
> for BeagleBone Black/AI
>
>
>
> Seeed is looking to not only build a Machinekit-focused Cape for
> BeagleBone Black and BeagleBone AI, but to:
>
> * Take in features and feedback from the community
>
> * Contribute the design to open source and certify it as such
>
> * Manufacture the design under the BeagleBoard.org name to support the
> BeagleBoard.org Foundation and community
>
> * Help assemble and provide software images configured for an open source
> 3D printer and CNC machine (with BeagleBoard.org and community guidance and
> support)
>
> * Offer a collection of additional accessories which might commonly be
> needed
>
>
>
> I am very excited about this because I know Seeed cares about open
> hardware and also knows how to deliver solutions reliably and cost
> effectively.
>
>
>
> So, what are your ideas about where to start on such a cape?
>
> --
>
> https://beagleboard.org/about
>
> --
> website: http://www.machinekit.io blog: http://blog.machinekit.io github:
> https://github.com/machinekit
> ---
> You received this message because you are subscribed to the Google Groups
> "Machinekit" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to machinekit+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/machinekit/CA%2BT6QPktUtnx5fv0AG%2BEqENM2mBRw44FLiEe-hKBRXOTanHomg%40mail.gmail.com
> <https://groups.google.com/d/msgid/machinekit/CA%2BT6QPktUtnx5fv0AG%2BEqENM2mBRw44FLiEe-hKBRXOTanHomg%40mail.gmail.com?utm_medium=email_source=footer>
> .
>


-- 
https://beagleboard.org/about

-- 
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/CA%2BT6QPn7sFJEOibsoeAJaZphvpsEpaEmXXPNjUQyZfsr9F-NcA%40mail.gmail.com.

Re: [beagleboard] BeagleBoard Black with Cramps - X stepper vibrates and does not rotate

[Jason Kridner]

On Thu, Mar 12, 2020 at 8:14 AM John Hammond 
wrote:

> The Y and Z steppers rotate but the X one does not. I have switched the
> Polulu driver from the X to Z and it works fine. Where is the pulse rate
> determined in Linux? Does Machinekit have linuxcnc files that I haven’t
> seen? Should this be posted on Machinekit forum somewhere?


Folks on the Machinekit forum would be better at those details, but... if
you are seeing twitching, could it be as simple as that axis has too much
resistance? There certainly is a config file to specify the pins for
pulse/direction. You used a standard CRAMPS board, right? Who built it and
can you verify the connection? Any logs to share?


> 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/4a0a7edd-bb08-494f-84d4-9a9b278f3733%40googlegroups.com
> .
>
-- 
https://beagleboard.org/about - 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/CA%2BT6QP%3DLbh4aSLa31z5a9QhPpqwNWHZe869yYd9hbFKMxQJ8TQ%40mail.gmail.com.

[beagleboard] Seeed to design and build Machinekit focused Cape for BeagleBone Black/AI

[Jason Kridner]

Seeed is looking to not only build a Machinekit-focused Cape for BeagleBone
Black and BeagleBone AI, but to:
* Take in features and feedback from the community
* Contribute the design to open source and certify it as such
* Manufacture the design under the BeagleBoard.org name to support the
BeagleBoard.org Foundation and community
* Help assemble and provide software images configured for an open source
3D printer and CNC machine (with BeagleBoard.org and community guidance and
support)
* Offer a collection of additional accessories which might commonly be
needed

I am very excited about this because I know Seeed cares about open hardware
and also knows how to deliver solutions reliably and cost effectively.

So, what are your ideas about where to start on such a cape?
-- 
https://beagleboard.org/about

-- 
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/CA%2BT6QPktUtnx5fv0AG%2BEqENM2mBRw44FLiEe-hKBRXOTanHomg%40mail.gmail.com.

Re: [beagleboard] Re: BBBLues

[Jason Kridner]

On Sat, Mar 7, 2020 at 1:14 AM Barry Bolton  wrote:

> Hello Mala.
>
> How do you connect a Radio Receiver to the BBblue? I am interested in
> using it as a Quadcopter flight controller.
>

Start a new thread!!!

One way to connect a receiver:

https://github.com/mirkix/ardupilotblue/blob/master/README.md



>
> On Sunday, 13 October 2019 04:31:21 UTC+3, Mala Dies wrote:
>>
>> Hello Again,
>>
>> One last thing...
>>
>> ...
>>
>> You need to set up your kernel to rt. Real Time kernels are for real time
>> workings, right. So, those guys or guy/lady, whomever, set up the github
>> repo. in my last post, imfatant/test, and it should show a quick image to
>> grab for use.
>>
>> Seth
>>
>> P.S. Um, if I hear from you, nice. If not, that is okay too. I will
>> rummage around some more w/ ideas and quirks until I get this BBB land more
>> familiarized. Yea boy!
>>
>> On Wednesday, September 4, 2019 at 6:02:33 PM UTC-5, todd.c...@gmail.com
>> wrote:
>>>
>>> So I have had nothing but trouble with my two BBBls. I attempted every
>>> walk through I could find on both of them, every time I would get stuck at
>>> a different point before I could ever get to installing ardupilot software.
>>> I finally got fed up with them, bought a Pixhack, combined it with a I.MX6
>>> scavenged from a 3DR Solo, and went on about my business. Due to a recent 
>>> operator
>>> error induced gravitational field incident, the pixhack seems to have
>>> developed dementia as it no longer oriented as to place time or self.
>>> Therefore, I have recently found it necessary to bring the BBBls out of
>>> storage and give them a second chance.
>>>
>>>
>>> *Here is the problem*: both of these little beauties seem to have
>>> called it quits. When I connect them to a computer, any computer (I've
>>> tried Win7, Win10, and Ubuntu 18.something) with any usb cable sometimes
>>> the computer will acknowledge that a device was connected, sometimes it
>>> won't. On windows, when it realizes that a device is there, it tells me
>>> that I need to format the SD card, as if that was the only thing I
>>> connected, Linux machines will let me view the files but that's it. I no
>>> longer have the "Out the box" files that came on the BBBls that used to be
>>> there, the ones with the little picture of the dog and the "getting
>>> started" stuff. Where'd they go? *Can I re-download the factory
>>> software somewhere? or is there a Factory reset option?*
>>>
>>>
>>> The pictures below are included to show the lights that stay on on each
>>> one.
>>>
>>> #1 G,R,75, and the one by the 12v input light up immediately when power
>>> is applied, with or without an SD card, and 0-3 light up sequentially after
>>> about 5 seconds without a card, a little slower with one.
>>>
>>> #2 goes through the same process, but eventually all lights cut off
>>> except the one by the 12v plug and led zero goes into a double blink, pause
>>> pattern; with or without a card.
>>>
>>> [image: BBBLues1.jpg]
>>>
>>>
>>> [image: BBBLues2.jpg]
>>>
>>> When I say "card", I mean one flashed with
>>> "bone-debian-9.5-iot-armhf-2018-10-07-4gb.img.xz"
>>>
>>> I have installed BONE_64 on my PCs
>>>
>> --
> 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/4f2e69b5-0916-4139-aea4-ff5f2dd73752%40googlegroups.com
> 
> .
>
-- 
https://beagleboard.org/about - 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/CA%2BT6QPnd7BWd0KnRVgvQrigh4DfLS18OOASNc3HMKSuDs3_7ng%40mail.gmail.com.

[beagleboard] Re: Beaglebone black wireless documents

[Jason Kridner]

On Sun, Feb 23, 2020 at 1:39 AM you wrote:

> Hi Jason /  Gerald,
>
> I would like to download data sheets (with hardware details) and user
> manual for beagle bone black wireless board, can you please help me out on
> this.
>
> Also, can we get complete data sheet of TI WLAN / BT chipset with hardware
> details and wlan/ BT firmware documents.
>
>
I didn't quite understand the scope of the question, so thank you for
scheduling the call via https://bbb.io/about/jkridner. As mentioned, please
send a message to the support forum in the TO address on this email for
future support questions and again schedule a call with me if you aren't
getting suitable answers.

The WL1835MOD (WiFi/BT/BLE) datasheet is available from :
http://www.ti.com/product/WL1835MOD

The AM3358 (SoC processor and peripherals) datasheet and technical
reference manual are available from:
http://www.ti.com/product/AM3358/technicaldocuments

The OSD3358 SIP technical documentation is at:
https://octavosystems.com/octavo_products/osd335x/#Technical%20Documents

I believe you've found the general board design materials at:
https://github.com/beagleboard/beaglebone-black-wireless

I don't get a lot of system reference manual queries as the design is very
similar to BeagleBone Black with the exception of the WiFi/BT/BLE and it
has thus not been worked extensively. If I were to fix it, I'd probably
start by greatly reducing its scope. Let me know if this is a real
impediment in any way. The best BeagleBone Black Wireless
documentaion available is in Derek Molloy's book Exploring BeagleBone (2nd
edition):
http://exploringbeaglebone.com/

-- 
https://beagleboard.org/about - 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/CA%2BT6QPne_DoAHTA2PqicWzr-j4d4bHhBGMY6k8AtW_cyuL05dA%40mail.gmail.com.

Re: [beagleboard] Latest Image (new Process) - Spring 2020 Release

[Jason Kridner]

On Tue, Mar 3, 2020 at 8:41 AM Gwen Stouthuysen 
wrote:

> Can we drop features we would like to be implemented in the April release?
>

Please. There is a tracker.


> I would like to have kernel 5.4 (or newer) to be functional in the
> Pocket/BeagleBoneBlack (Wireless)
> Reason: I would like to use CAN J1939 directly from Kernel support.
>

Cool. I need dtbo ovetlays for some of my workshops and a number of out of
tree drivers. Really, I need to track them to mainline and create a
regression test suite.

Kernels are pretty big. Robert has scripts to load different kernels. Does
that work for you?


> I will keep an eye on the RCs and test them in my domain
>

Great!


> Gwen
>
>
> Op di 3 mrt. 2020 om 00:03 schreef Robert Nelson  >:
>
>> Hi Everyone,
>>
>> So it's been a long time since i posted one of these. So let's go more
>> crazy..
>>
>> In the past, Image releases have been kinda random. So let's try to
>> get things on a better schedule...
>>
>> Maybe 3 times a year?  We've been thinking, Early spring for GSOC,
>> Before School for universities who use our boards, and a mid December
>> which fits in between..
>>
>> So...  With a plan to have an NEW official image released on April
>> 6th, 2020, let's get started with RC1: (which are up right now..)  New
>> RC every Monday..
>>
>> Right now i just want to limit images to the Base Console, IoT and IoT
>> TIDL.  (For both Stretch 9.12 and Buster 10.3)
>>
>> Let's be honest, who really uses the lxqt image? Raise hand???
>>
>> Issue Tracker: https://github.com/beagleboard/Latest-Images/issues
>> elinux page with img links:
>> https://elinux.org/Beagleboard:Latest-images-testing
>>
>> Changes:
>>
>> usb0/usb1: default ip address (192.168.7.2/192.168.6.2)
>> For users that like to plug many Beagle's into one PC, you can now
>> stop fighting usb-gadget, under /etc/default/bb-boot, you can now
>> update the usb0/usb1 default ip address in one location...
>>
>> Node-RED : 1.0.4
>>
>> 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/CAOCHtYgP5GW-Wi4oCcY3OFfroEvEY7y1QtWnXco9EG41cmCJ4A%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/CAFfeaG-nZwBjBwATm%3DsLtK9P7d-F-SbPyEBGoeEih%2Ba0Mexchg%40mail.gmail.com
> 
> .
>
-- 
https://beagleboard.org/about - 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/CA%2BT6QPn5rFO8gTenT0yqTygcvz%2BZ7xwP1_X2LDc2moN6kR0wdg%40mail.gmail.com.

Re: [beagleboard] AM57XX_pru_package

[Jason Kridner]

On Wed, Feb 12, 2020 at 9:12 AM Stephan Böck  wrote:

> Hey,
>
> at the moment I try to port a program to the BB AI, which was developed
> for the BB Black.
>
> This program uses the PRUs and includes the headerfiles
> pruss_intc_mapping.h and prussdrv.h aswell as the libs (libprussdrv.a,
> libprussdrv.so, libprussdrvd.a and libprussdrvd.so) from the
> am335x_pru_package, which can be found in the beagleboard git repo
> https://github.com/beagleboard/am335x_pru_package
>
> Is there a chance that a pru package for the AM5729 is on the way?
>

What do you need out of the package first? I think we can tackle adding
some cross AM3/AM5 device support to this library incrementally.

Mark Yoder and I have been working on BeagleBone AI PRU examples at:

https://github.com/beagleboard/cloud9-examples/tree/v2020.01/BeagleBone/AI/pru



>
>
> Currently, I am facing segmentation faults. Which makes totally sense,
> since the base addresses changed.
>
> Stephan
>
> --
> 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/08c3aa1e-e013-4c3e-9214-1b238b5d3924%40googlegroups.com
> 
> .
>


-- 
https://beagleboard.org/about - 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/CA%2BT6QP%3DXwFKmVDS-t%3D82wMj7En1AUCDw%2BHRRnkaFjUVo2TNUeQ%40mail.gmail.com.

Re: [beagleboard] BeagleBone AI now AWS Greengrass certified

[Jason Kridner]

On Mon, Jan 27, 2020 at 11:07 AM jonnymo  wrote:

> Jason,
>
> That is awesome!
>
> Are there plans to have support for the BeagleBone AI with AWS RoboMaker?
>

Loosely, yes--I'm still trying to scope all the work and define the best
approach. I'd like to avoid having a bunch of images to support. I'm
largely unhappy with the state of ROS on Debian.

We are also working on SageMaker NEO support.


>
> Cheers,
>
> Jon
>
> On Mon, Jan 27, 2020 at 7:43 AM Jason Kridner  wrote:
>
>> Greengrass is a way to direct your board from the AWS Cloud. You can load
>> services (lambdas) on your board that have access to the board resources as
>> well as AWS Cloud resources.
>>
>> Details can be found at
>> https://devices.amazonaws.com/detail/a3G0h076ytWEAQ/BeagleBoard.org-BeagleBone-AI
>>
>> Interested? I have AWS credits I can send those who are interested in
>> trying this out ($10). Contact me if you'd like an AWS credit. Make sure to
>> reply privately and not on the forum. If you don't get a response, try the
>> resources on https://beagleboard.org/about/jkridner. If there's enough
>> response, I'll set up something more automated.
>>
>> --
>> https://beagleboard.org/about
>>
>> --
>> 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/CA%2BT6QPkXXpjMfwgoftqmcz0511KMRw9O%3DDRQ4WyJ-VKDvJU0cw%40mail.gmail.com
>> <https://groups.google.com/d/msgid/beagleboard/CA%2BT6QPkXXpjMfwgoftqmcz0511KMRw9O%3DDRQ4WyJ-VKDvJU0cw%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
> --
> 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/CAG99bkp21k0sO2FXFttuVFNSqsWVYb8vxmz0JEQXo7bDn0xA9w%40mail.gmail.com
> <https://groups.google.com/d/msgid/beagleboard/CAG99bkp21k0sO2FXFttuVFNSqsWVYb8vxmz0JEQXo7bDn0xA9w%40mail.gmail.com?utm_medium=email_source=footer>
> .
>


-- 
https://beagleboard.org/about - 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/CA%2BT6QP%3DcOQ8bSwZz6YrtfBPd9wanNjRfY5jNmgX1%2BP9moZ%2BN9w%40mail.gmail.com.

[beagleboard] BeagleBone AI now AWS Greengrass certified

[Jason Kridner]

Greengrass is a way to direct your board from the AWS Cloud. You can load
services (lambdas) on your board that have access to the board resources as
well as AWS Cloud resources.

Details can be found at
https://devices.amazonaws.com/detail/a3G0h076ytWEAQ/BeagleBoard.org-BeagleBone-AI

Interested? I have AWS credits I can send those who are interested in
trying this out ($10). Contact me if you'd like an AWS credit. Make sure to
reply privately and not on the forum. If you don't get a response, try the
resources on https://beagleboard.org/about/jkridner. If there's enough
response, I'll set up something more automated.

-- 
https://beagleboard.org/about

-- 
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/CA%2BT6QPkXXpjMfwgoftqmcz0511KMRw9O%3DDRQ4WyJ-VKDvJU0cw%40mail.gmail.com.

Re: [beagleboard] Can I utilize the Beaglebone debian distro on my custom card thats based on the AM3352 cpu?

[Jason Kridner]

If you could kindly remove the "beagleboard.org" branding on the desktop,
that'd be fine.

Alternatively, you can license the "beagleboard compatible" logo (see
https://beagleboard.org/logo) for on-going releases that will run on your
custom board. This should be only for open hardware.

On Fri, Jan 24, 2020 at 12:14 PM Linus  wrote:

> Hi,
>
> As asked in the title, Can I utilize the Beaglebone debian distro on my
> custom card thats based on the AM3352 cpu?
>
> I understand that I need to build a custom u-boot and dtb.
>
> Best regards,
> Linus
>
> --
> 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/2d66c510-03e3-48f7-8c22-c850c4ae451c%40googlegroups.com
> 
> .
>


-- 
https://beagleboard.org/about - 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/CA%2BT6QPnztbtCjT_XxoiBHd3kNQyF1%2Bh5g_AGvK7Ac80BOgLoFg%40mail.gmail.com.

Re: [beagleboard] Re: BBAI and Updating to Stop the Heat Transfer at https://beagleboard.org/upgrade

[Jason Kridner]

Perhaps:

watch /opt/scripts/device/x15/test_thermal.sh

?


The output of 'test_thermal.sh' would really be helpful for those
complaining about the heat. The update should stop it from overheating, at
least in a room temperature environment. That doesn't mean it won't be hot
to the touch... just not so hot that it will need to shutdown.

Can I get some more feedback on this?

Sorry for the VERY LONG delay on the Fan Cape. Chinese New Year recently
entered the reasons for delay, but it is coming. The other big missing
thing for BBAI is the Python Tensorflow library, which is also coming. I'll
be talking a lot more about BBAI once the two of those are out there.

Anyway, just running the update should give you a nice solution for running
"regular" code. Please explain to me if that really isn't the case.

On Mon, Jan 27, 2020 at 6:42 AM Mala Dies  wrote:

> Hello,
>
> No...this fellow gave me a script to test for temp. continuously.
>
> Seth
>
> On Monday, January 20, 2020 at 8:19:00 AM UTC-6, IO wrote:
>>
>> You mean, by running cat /sys/devices/virtual/thermal/thermal_zone0/temp ?
>>
>> On Sunday, January 19, 2020 at 7:54:46 PM UTC+2,
>> se...@lafayette-parish.com wrote:
>>>
>>> Hello,
>>>
>>> Just an update, if you run the temp. sensors onboard the AI and run the
>>> fan, on my end, you will receive a 38c or below temp. for the board chips
>>> and surrounding area.
>>>
>>> Seth
>>>
>>> P.S. Nice! Fans!
>>>
>>> On Thursday, January 2, 2020 at 1:18:29 AM UTC-6, Mala Dies wrote:

 Hello,

 Thank you for this update. I did update the board already as the link
 suggested. My fan was a 24v fan. I need to get another fan.

 Seth

 P.S. I might get the digikey.com fan you have listed. Anyway, if
 anyone has any other ideas, shoot!

 On Sunday, December 29, 2019 at 5:30:02 PM UTC-6, jonnymo wrote:
>
> Jason recently posted an update regarding the Fan Cape he is working
> on.
> In the mean time, he recommended the Coolerguys USB fan that is listed
> in the BBAI FAQ:
>
> https://github.com/beagleboard/beaglebone-ai/wiki/Frequently-Asked-Questions#fans
>
> https://www.coolerguys.com/collections/usb-fans/products/25mm-25x25x10-usb-fan
>
> Previously, the X15FANKIT was suggested but it requires wiring to 5v
> and grnd on the BBAI.  I am using this and it seems to work fine for my
> BBAI. This does fit perfectly on the BBAI heat-sink and the provided 
> screws
> work just fine.
>
> https://github.com/beagleboard/beaglebone-ai/wiki/System-Reference-Manual#3-1-2-fans
>
> https://www.digikey.com/product-detail/en/digi-key-electronics/X15FANKIT/X15FANKIT-ND/5822502
>
>
> Cheers,
>
> Jon
>
> On Sun, Dec 29, 2019 at 10:03 PM Mala Dies  wrote:
>
>> Hello,
>>
>> Thank you for the idea. USB powered fans. I guess they make
>> everything these days.
>>
>> Seth
>>
>> P.S. I was just going to power it from the sys_5v pin and GND on the
>> BBAI. I guess there are many more ways to go about making things work 
>> than
>> once thought.
>>
>> On Sunday, December 29, 2019 at 8:56:07 AM UTC-6, Stephen Johnson
>> wrote:
>>>
>>> I bought a USB powered fan which gives a very low airflow, but has
>>> kept everything cool to the touch.
>>> I just have the BBAI on my engineering workbench anyhow, so I just
>>> wanted something simple and quiet.
>>>
>>>
>>> [image: IMG_1873.jpeg]
>>>
>>>
>>>
>>> On Saturday, December 28, 2019 at 7:17:02 PM UTC-6, Mala Dies wrote:

 Hello,

 I was reluctant to purchase the BBAI at first b/c I have heard of
 issues w/ heat dissipation on the board and the chip. Anyway...

 Long story, short. I bought it against my better judgement b/c I
 know everyone, in the BBB world, is supportive w/ nice ideas.

 ...

 So:


- I went to: https://beagleboard.org/upgrade.
- I upgraded the board and adjusted things.
- I rebooted the board and found the board to be just as hot.


 Has anyone else come across an issue w/ heat or a fix to the heat
 issue?

 Seth

 P.S. I might get rid of some of the extras that comes with this
 board but I purchased it for its functionality. I want to use the M4, 
 TIDL,
 EVEs, and other
 more complicated chips for fun! I was thinking I would finally
 learn to program the PRUs too. I am going to try to get rid of 
 node-red,
 chromium, and
 some other sockets and ports on the board. I think that these may
 cause services that I will not use ever.

 ...

 If you are using the board, the BBAI, and you have had some similar
 

[beagleboard] Accessing USB3 superspeed host on BeagleBone AI

[Jason Kridner]

I'm surprised I've not noticed anyone ask yet, but the USB3 on
BeagleBone AI isn't just for acting as a client (gadget) device as it
works by default. You can also turn it around and use it in host mode!

echo "host" | sudo tee /sys/kernel/debug/4889.usb/mode

You'll want to use a multiport adapter or hub with power pass-through.
I've tested it with a number of multiport adapters and hubs, including
the Apple multiport adapters.

Most recently, I tried it with this one:

https://www.amazon.com/gp/product/B074DRW84M/ref=ppx_yo_dt_b_asin_title_o01_s00?ie=UTF8=1

Note that the one above is pretty simple, but does have a useless HDMI
connector on it as BeagleBone AI does not support the DisplayPort
alternate mode on USB Type-C.  Anyway, it is funny that I've found
cheaper ones that work, like:

https://www.amazon.com/LETSCOM-Adapter-Ethernet-Charging-Compatible/dp/B075QY215N

...but they all have so much extra stuff on them.

Anyone know of any affordable ones that are *just* USB Type-C hubs
with power pass-through?

-- 
https://beagleboard.org/about

-- 
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/CA%2BT6QPkiSc7LvqOyMDxwHiU2Y7Aua82CdhiMp_BAxO9Ao3RbVA%40mail.gmail.com.

Re: [beagleboard] Make PRU-controlled pin change direction or go tri-state?

[Jason Kridner]

On Thu, Jan 16, 2020 at 11:27 PM Andrew P. Lentvorski 
wrote:

>
>
> On Thursday, January 16, 2020 at 9:58:39 AM UTC-8, Jason Kridner wrote:
>>
>>
>>
>> On Thu, Jan 16, 2020 at 3:39 AM Andrew P. Lentvorski 
>> wrote:
>> >
>> > I've got to be missing something obvious, but I even after several
>> rounds of RTFM, I can't seem to figure out how to get the PRU to change the
>> direction of a pin or, at the very least, to let it go to a tri-state value.
>> >
>> > I would go out over the L3/L4 (although that kinda smashes the whole
>> "real-time" thing), but won't that bump into the fact that the processor
>> needs to be in supervisor mode?
>>
>> I see you got some other answers, but it might help you to qualify if you
>> are using a chip-level GPIO or PRU-level GPIO.
>>
>> As mentioned, you don't need a supervisor mode to get to the L3 bus
>> needed to configure the GPIO or pinmux. You do need to clear the
>> STANDBY_INIT bit in SYSCFG. Then, the PRU can poke all the SoC registers
>> that the ARM can. Below is an example that clears this bit, but doesn't
>> need to do so, because the PRU GPIO bits are INSIDE the PRUSS, so I'll
>> likely remove those lines from this example in the future.
>>
>>
>
> I guess I'm still missing something because the following program doesn't
> work.  When I try to write to *u32_control_P9_27, nothing changes.  I *CAN*
> however read from it and config-pin can change it externally just fine.
> So, I got the actual *pointer address* as well as various clocks and
> enables correct since I can read it properly.
>
> What did I get wrong?
>

Looks like *I* got it wrong that you can change PADCONF from the PRUs.
Apparently, from the PRUs those registers are read-only. :-(

https://e2e.ti.com/support/processors/f/791/t/445028


>
>
> #include 
> #include 
> #include "resource_table_empty.h"
>
> volatile register uint32_t __R30;   // 32 output gpios
> volatile register uint32_t __R31;   // 32 input gpios
>
> #define CONTROL_MODULE_START ((uint32_t)0x44E1)
> #define CONF_MCASP0_FSR_OFFSET 0x9A4
> uint32_t volatile * const u32_control_P9_27 = (uint32_t volatile * 
> const)(CONTROL_MODULE_START
> + CONF_MCASP0_FSR_OFFSET);
>
> #define PINMUX_PRU_OUT 0x5
> #define PINMUX_PRU_IN  0x6
>
> #define DELAY_CYCLES (5000/2)
> void main(void) {
> uint32_t const led = 0x0028; // Use pru0_pru_r30_5 and
> pru0_pru_r32_3 as an output
>
> // You can now monitor P9_28 frequency as reflecting state of P9_27
> pinmux
>
> CT_CFG.SYSCFG_bit.STANDBY_INIT = 0;
>
> unsigned int ui = 0;
> unsigned int ui_fast = 0;
>
> while (1) {
> *u32_control_P9_27 = PINMUX_PRU_IN;  // No effect on frequency
> while config-pin causes expected frequency shifts
>
> ++ui;
>
> if (((*u32_control_P9_27) & 0x07) == PINMUX_PRU_OUT) {  // This
> verifies that I actually got the correct address of the pinmux
> ui_fast = 1;
> } else {
> ui_fast = 0;
> }
>
> __R30 = led;
> __delay_cycles(DELAY_CYCLES);
> if (ui_fast != 1) {
> __delay_cycles(DELAY_CYCLES);
> }
>
> __R30 = 0;
> __delay_cycles(DELAY_CYCLES);
> if (ui_fast != 1) {
> __delay_cycles(DELAY_CYCLES);
> }
> }
>
> __halt();
> }
>
>
>
>
> --
> 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/437cd2db-6711-4dbe-ba19-0a781d0f31bd%40googlegroups.com
> <https://groups.google.com/d/msgid/beagleboard/437cd2db-6711-4dbe-ba19-0a781d0f31bd%40googlegroups.com?utm_medium=email_source=footer>
> .
>


-- 
https://beagleboard.org/about - 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/CA%2BT6QPmCL%2B91dY1KamkR6SGzBAyLUm9FEvS0uu5XEYd_y%2BOjEA%40mail.gmail.com.

Re: [beagleboard] Re: Make PRU-controlled pin change direction or go tri-state?

[Jason Kridner]

On Thu, Jan 16, 2020 at 11:39 AM TJF  wrote:

> There's no supervisor mode for the PRU.
>
> There's no tri-state-mode for AM335x GPIO.
>
> In order to change direction for a pin on a GPIO-SS, it needs a write
> access to its OE register. The PRU can do that.
>
> Find an example at
> https://github.com/DTJF/libpruw1/blob/master/src/bas/w1_prucode.p, which
> is a driver for a one-wire (w1) bus, reading and sending data on a single
> GPIO line for multiple divices. The library documentation is at
> http://users.freebasic-portal.de/tjf/Projekte/libpruw1/doc/html/
>

Thanks for the great example!

For those that don't quite follow, you are using the chip-level or
SoC-level GPIO subsystem for this example and not the PRU subsystem GPIOs
that can be accessed directly from R30/R31 on the PRU CPU itself. For those
pins, the PADCONF or pinmux settings must be adjusted at the chip/SoC-level
to disable the PRU GPIO output.


>
> --
> 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/81daa29b-4795-41b4-a4b6-a7f18229639c%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/CA%2BT6QP%3DV5k3p7LQOOHV5P5oHManD2UbKt0g9zRonUjELJCwgqg%40mail.gmail.com.

Re: [beagleboard] Make PRU-controlled pin change direction or go tri-state?

[Jason Kridner]

On Thu, Jan 16, 2020 at 3:39 AM Andrew P. Lentvorski 
wrote:
>
> I've got to be missing something obvious, but I even after several rounds
of RTFM, I can't seem to figure out how to get the PRU to change the
direction of a pin or, at the very least, to let it go to a tri-state value.
>
> I would go out over the L3/L4 (although that kinda smashes the whole
"real-time" thing), but won't that bump into the fact that the processor
needs to be in supervisor mode?

I see you got some other answers, but it might help you to qualify if you
are using a chip-level GPIO or PRU-level GPIO.

As mentioned, you don't need a supervisor mode to get to the L3 bus needed
to configure the GPIO or pinmux. You do need to clear the STANDBY_INIT bit
in SYSCFG. Then, the PRU can poke all the SoC registers that the ARM can.
Below is an example that clears this bit, but doesn't need to do so,
because the PRU GPIO bits are INSIDE the PRUSS, so I'll likely remove those
lines from this example in the future.

https://github.com/beagleboard/cloud9-examples/blob/master/BeagleBone/Black/pru/blinkR30.pru0.c
:


// blinkR30.pru0.c
// Blinks LEDs wired to P9_29 (and others) by writing register R30 on the
PRU
// Wiring: P9_29 connects to the plus lead of an LED. The negative lead of
the
// LED goes to a 220 Ohm resistor. The other lead of the resistor goes
// to ground.
// Setup: config_pin P9_29 pruout
// See: prugpio.h to see which pins attach to R30
// PRU: pru0

#include 
#include 
#include "resource_table_empty.h"
#include "prugpio.h"
volatile register unsigned int __R30;
volatile register unsigned int __R31;
void main(void) {
// Select which pins to toggle. These are all on pru1_1
uint32_t gpio = P9_29;
/* Clear SYSCFG[STANDBY_INIT] to enable OCP master port */
CT_CFG.SYSCFG_bit.STANDBY_INIT = 0;
while(1) {
__R30 |= gpio; // Set the GPIO pin to 1
__delay_cycles(5/5); // Wait 1/2 second
__R30 &= ~gpio; // Clear the GPIO pin
__delay_cycles(5/5);
}
__halt();
}
// Sets pinmux
#pragma DATA_SECTION(init_pins, ".init_pins")
#pragma RETAIN(init_pins)
const char init_pins[] =
"/sys/devices/platform/ocp/ocp:P9_29_pinmux/state\0pruout\0" \
"\0\0";
What I am thinking about adding to this repo is an example for reading an
ultrasonic sensor that kinda stupidly (IMHO) uses the same pin to trigger a
sample as to read it back. I think using the PRU for that would be good,
but it means changing the pin direction. The way to do that without
external hardware is to alter the PADCONF (ie., pinmux) settings on the pin
to go from pru_out mode to pru_in. Otherwise, the PRU itself doesn't have
any way to go into a high-Z or tristate mode.

I'd be happy if someone beat me to both updates to the repo and provided a
pull-request.

>
> Any help would be appreciated.
>
> 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/16640740-240b-4e94-950d-f4bbe369fb76%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/CA%2BT6QPkNJ5Z1QhhdG3hXvksPtjvG%2BHv4QZQcD%3DzOD%3Djo1o7ZUw%40mail.gmail.com.

Re: [beagleboard] TIDL import utility not supported on BBAI?

[Jason Kridner]

On Thu, Jan 2, 2020 at 5:16 PM Manderson  wrote:
>
> Hi all,
>
> I want to use the ML model import feature from the TI Processor SDK to be 
> able to use TensorFlow network models with the TIDL API available on the 
> BeagleBone AI, however, I can't find the tool in the Debian distro provided 
> by BB.
>
> I see several TIDL model examples in 
> /usr/share/ti/examples/tidl/test/testvecs/config/tidl_models but I should be 
> seeing the import tool in 
> /usr/share/ti/tidl/tidl_utils/test/testvecs/config/import
>
> Will this import utility be coming soon? Has anyone found a workaround?

The tool should be at https://git.ti.com/cgit/tidl/tidl-utils/. We've
had a bit of confusion building it. I'll escalate to the TI Sitara
Analytics team. Here's where I got just now...

(git tag 99ff282fbc440a68170736e7b5de2ff5a2984386)

$ git clone https://git.ti.com/cgit/tidl/tidl-utils/
$ cd tidl-utils/src/importTool/modules/ti_dl/utils/caffeImport
$ sudo apt install -y protobuf-compiler libprotobuf-dev
$ export LINUXENV=oearm
$ export LINUX_BUILD_TOOLS=/usr/bin/arm-linux-gnueabihf-
$ export PROTOBUF_LIB_DIR=/usr/lib
$ export PROTOBUF_INC_DIR=/usr/include
$ export FLATBUFFERS_INC_DIR=/usr/include
$ export TF_LITE_GENERATED_PATH=/usr/include
$ protoc --proto_path=. --cpp_out=. caffe.proto
$ cd ../tfImport
$ mkdir proto_cc
$ source genProtoC.sh
$ cd ../onnxImport
$ mkdir onnx_cc
$ source onnxGenProto.sh
$ cd ../tidlModelImport
$ make
compiling tidl_tfLiteImport.cpp
tidl_tfLiteImport.cpp:76:30: fatal error: schema_generated.h: No such
file or directory
 #include "schema_generated.h"

>
> 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/8906b7c2-bc0e-4d2c-a239-87b1fad3e78d%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/CA%2BT6QPmd5-4ts0_4-1Dt7NkOYzpL77-0QnNQaBiG8x4Vc%3D0S8A%40mail.gmail.com.

Re: [beagleboard] Striped down debian image for BB

[Jason Kridner]

Depends what you call necessary. There is a Debian console-only image.

On Mon, Jan 13, 2020 at 9:43 AM Stephan Böck  wrote:
>
> Hello,
>
> I found that my BB AI has a quite high idle load (around 15% on both cores, 
> 225MB of RAM used. Measured with htop). Has anyone else experienced the same?
>
> Maybe, there is a striped down debian image (dabian 9 or 10) that only 
> contains the necessary applications?
>
> Regards
> Stephan
>
> --
> 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/826e85f2-64dd-4733-9ef1-f2699d571957%40googlegroups.com.



-- 
https://beagleboard.org/about - 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/CA%2BT6QP%3DPU6b_6WLBKFA7ppmj6VRURUmRWEw%3DY-br2-r3dz1u-g%40mail.gmail.com.

Re: [beagleboard] AM5729 process now in ACTIVE status

[Jason Kridner]

The Seeed manufactured X15s and the previous boards made by PTI use the
same AM5729 variant. The BOM has been unfortunately deceptive since the
AM5729 wasn’t public, but all the rev C X15 boards did and do use it.

The exact part number is AM5729BABCXEAR

Seeed is the only current manufacturer. Actually just got the tour of where
they are being assembled on Thursday. I’ll post photos when I have a better
connection.


On Sat, Jan 11, 2020 at 1:20 AM Calvin Slater 
wrote:

> Yes. Pretty cool.
>
> Not sure what the new Seeed Studios boards come with (The X15 BOM calls
> for AM5728), But the previous boards from PTI had AM5729BABCXEA.
>
> BABCXEA is the nicest version of AM5729 that you can buy, i.e. industrial
> temp, industrial communication protocols enabled, etc
>
> Hopefully the new Seeed boards have the same.
>
> On Wed, 8 Jan 2020 at 12:13,  wrote:
>
>>
>> I noticed that the AM5729 has been changed to ACTIVE status and that
>> there appears to be a greater than zero quantity available for ordering.
>>
>> I also noticed that the Beagleboard X15, which like the Beagleboard AI is
>> made with the AM5729 and now sourced by Seeed Studio is available for order
>> on Mouser. Last I looked 300+ in stock.
>>
>> Raul
>>
>> --
>> 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/cf89e9ad-8884-4790-ae23-5a2fa635bbdd%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/CAN%2BNdyiHy8tT%3DsBjn56DWiMUOmNx6Uncww0QC9OnKOnHawp7ZA%40mail.gmail.com
> 
> .
>
-- 
https://beagleboard.org/about - 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/CA%2BT6QPm40d4B7i%3DVD3fCzUc7i_D7h5X3OeY%2B9f0kobb0gZi10A%40mail.gmail.com.

Re: [beagleboard] Re: Stopping an restarting cloud9

[Jason Kridner]

I believe there is also a cloud9.socket. After you stop it, does it restart
on its own if you open the port?

On Sat, Jan 4, 2020 at 3:22 PM Mark A. Yoder  wrote:

> Rebooting caused cloud9 to restart.
>
> Using iptables to block port 3000 might be the easiest thing to do.
>
> --Mark
>
>
> On Saturday, January 4, 2020 at 3:21:14 PM UTC-5, Mark A. Yoder wrote:
>>
>> I'd like to be able to stop and later restart cloud9.  The following
>> stopped cloud9
>>
>> bone$ *sudo systemctl stop cloud9*
>>
>> But the following didn't restart it.
>>
>> bone$ *sudo systemctl start cloud9*
>> bone$ *systemctl status cloud9*
>> ● cloud9.service - Cloud9 IDE
>>Loaded: loaded (/lib/systemd/system/cloud9.service; static; vendor
>> preset: enabled)
>>Active: failed (Result: exit-code) since Sat 2020-01-04 19:45:12 UTC;
>> 2s ago
>>   Process: 5485 ExecStartPre=/opt/cloud9/cloud9-symlink (code=exited,
>> status=0/SUCCESS)
>>   Process: 5491 ExecStart=/opt/cloud9_support/bin/node server.js --packed
>> -w /var/lib/cloud9 (code=exited, status=1/FAILURE)
>>  Main PID: 5491 (code=exited, status=1/FAILURE)
>>
>> Jan 04 19:45:12 ece312 cloud9ide[5491]:  port: '3000',
>> Jan 04 19:45:12 ece312 cloud9ide[5491]:  host: '127.0.0.1',
>> Jan 04 19:45:12 ece312 cloud9ide[5491]:  websocket: true,
>> Jan 04 19:45:12 ece312 cloud9ide[5491]:  showRealIP: true,
>> Jan 04 19:45:12 ece312 cloud9ide[5491]:  secure: undefined,
>> Jan 04 19:45:12 ece312 cloud9ide[5491]:  provides: [ 'connect',
>> 'http' ],
>> Jan 04 19:45:12 ece312 cloud9ide[5491]:  consumes: [],
>> Jan 04 19:45:12 ece312 cloud9ide[5491]:  setup: [Function: startup] }
>> } 'Error: No or too many file descriptors received.\nat Server.listen
>> (/opt/cloud9/node_modules
>> Jan 04 19:45:12 ece312 systemd[1]: cloud9.service: Main process exited,
>> code=exited, status=1/FAILURE
>> Jan 04 19:45:12 ece312 systemd[1]: cloud9.service: Failed with result
>> 'exit-code'.
>>
>> bone$ *cat /ID.txt*
>> BeagleBoard.org Debian Image 2019-12-16
>> bone $ *uname -a*
>> Linux ece312 4.19.79-ti-r30 #1buster SMP PREEMPT Mon Nov 4 20:38:01 UTC
>> 2019 armv7l GNU/Linux
>>
>> Or is there a better way to turn off cloud9 access and restore it later?
>>
>> --Mark
>>
> --
> 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/3b39975d-e122-4af4-905f-97cd11ffa8e4%40googlegroups.com
> 
> .
>
-- 
https://beagleboard.org/about - 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/CA%2BT6QPn1PiKqitK6GLi4rMoiF7hYcHJj_XsSbM6bdBvrHPALcQ%40mail.gmail.com.

[beagleboard] Re: Fan update for BeagleBone AI

[Jason Kridner]

Oh, and I added a 'fan' section to the FAQ: 
https://github.com/beagleboard/beaglebone-ai/wiki/Frequently-Asked-Questions#fans
 

On Saturday, December 28, 2019 at 1:55:11 PM UTC-5, Jason Kridner wrote:
>
> Some my my message was chopped
>
> In the meantime, I've found the Coolerguys 25mm USB fan works nicely, but the 
> pass-though USB doesn't pass through data. That means that you can't use a 
> USB camera with it unless you use a Type-C docking station on the other USB.
>
> Also, you have to acquire mounting screws separately.
>
>
>
> https://www.coolerguys.com/collections/usb-fans/products/25mm-25x25x10-usb-fan
>  
>
>
> On Saturday, December 28, 2019 at 1:38:18 PM UTC-5, Jason Kridner wrote:
>>
>> Getting closer on getting the BeagleBone Fan Cape boards out.  No real 
>> ETA. Maybe February. :-/ 
>>
>>

-- 
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/043bef03-8265-4194-bb82-8ee8827f88f4%40googlegroups.com.

[beagleboard] Re: Fan update for BeagleBone AI

[Jason Kridner]

Some my my message was chopped

In the meantime, I've found the Coolerguys 25mm USB fan works nicely, but the 
pass-though USB doesn't pass through data. That means that you can't use a USB 
camera with it unless you use a Type-C docking station on the other USB.

Also, you have to acquire mounting screws separately.


https://www.coolerguys.com/collections/usb-fans/products/25mm-25x25x10-usb-fan
 


On Saturday, December 28, 2019 at 1:38:18 PM UTC-5, Jason Kridner wrote:
>
> Getting closer on getting the BeagleBone Fan Cape boards out.  No real 
> ETA. Maybe February. :-/ 
>
>

-- 
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/608268be-be6e-4a09-9119-a707aafa9b3e%40googlegroups.com.

[beagleboard] Re: Notes about Black , Green and Pocketbeagle GamePup and TechLab cape learning

[Jason Kridner]

On Thursday, October 24, 2019 at 1:46:47 PM UTC-4, Dennis Bieber wrote:
>
> On Thu, 24 Oct 2019 07:19:34 -0700 (PDT), "Lee T. Davy" 
>  declaimed 
> the 
> following: 
>
> >Will Beaglebone ever replace Raspberry Pi for learning about computers ? 
> > 
>
> Probably not... 
>
> The Beaglebone series appears optimized for use as embedded Linux 
> controllers. They provide a large number of binary GPIO, SPI, I2C, 
> multiple 
> UARTs, along with ANALOG inputs and outputs. They have (at least the BBB) 
> only one USB port. But they tend toward slower single core processors 
> (ignoring the cryptic PRUs), small amount of RAM. The stand-alone Cloud-9 
> environment is the "friendly" interface for programming, favoring 
> Bonescript via node.js (though Cloud-9 does support Python too). 
>
>
> The R-Pi was billed as a cheap Linux computer using Python as the 
> primary programming language for teaching purposes. It really only has a 
> few binary GPIO, SPI, I2C -- but no analog I/O. Typically four USB ports. 
> The newer ones have 64-bit quad-core processors (though the normal OS is 
> just 32-bit for compatibility across the line) and more RAM -- but lack 
> any 
> coprocessors. Really meant to be used with an HDMI monitor and local 
> keyboard/mouse. 
>
> Compare: 
> BBAI: 1.5GHz dual Cortex-A15, 1GB ? RAM, 4 PRU, 4 EVE, 2 DSP, 16GB eMMC, 
> USB2, USB3?, WiFi 
>   
>   $117+ 
>
> BBB: 1GHz Cortex-A8, 512MB DDR3 RAM, 2 PRU, 4GB eMMC, USB2 
>   
>   $55+ 
>
>   
>
>
> R-Pi 4B: 1.5GHz quad Cortex-A72, 4GB DDR4 RAM, USB3, WiFi 
>   
>   $55 
>
> R-Pi 4B: 1.5GHz quad Cortex-A72, 1GB DDR4 RAM, USB3, WiFi 
>   
>   $35 
>
> R-Pi 3B+: 1.4GHz quad Cortex-A53, 1GB DDR2 RAM, USB2, WiFi 
>   
>   $35 
>
>
> The R-Pi foundation seems to release a new model every 12-18 
> months, 
> whereas Beagles appear to be targeted for long-term stability (what did I 
> read, 10 years production life?) 
>

Yes, 10 year production life. This has a big impact on both engineering 
education as well as use in products.

You mentioned lots of embedded I/O functionality, including on-board ADCs.

Don't forget about the open hardware aspect and variants optimized for 
various operating conditions.

Most designs including on-board eMMC for additional reliability and 
improved out-of-box experience/performance.

Having heterogeneous systems optimized for various embedded tasks is part 
of Beagle's identity as well.

The development experience is also very much targeted at embedded, where 
connecting a keyboard, monitor and mouse is not the anticipated development 
model.
 

>
> -- 
> Dennis L Bieber 
>
>

-- 
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/8d6ebe21-a275-4103-8035-4da8931b9146%40googlegroups.com.

[beagleboard] Re: BeagleBoard.org - Bad Gateway

[Jason Kridner]

On Thursday, October 3, 2019 at 10:19:31 AM UTC-4, Jon Morss wrote:
>
> When attempting to access anything at BeagleBoard.org I am getting a "502 
> Bad Gateway   nginx/1.12.2"  error.
>
> Is this site down?
>
>
The site got some unscheduled maintenance when I accidentally started a 
backup that required the host to be frozen. I ended up bringing the server 
up on an ARM host now so that I hope I can add some new continuous 
integration services. I've been able to run 
https://github.com/beagleboard/image-builder on the server itself, rather 
than off-loading to X15s.

Anyway, thanks for reporting the outage and stay tuned. 

-- 
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/4bd29384-b735-4d3d-917f-82c478abafed%40googlegroups.com.

Re: [beagleboard] Re: ArduCopter, BBBlue, and Flying/Linux

[Jason Kridner]

If you have any build instructions, it would be great to post them on
beagleboard.org/p.

On Sat, Nov 23, 2019 at 11:47 PM Mala Dies  wrote:
>
> Hello Again,
>
> Here is the link for the BBBlue and ArduCopter: https://youtu.be/cpqV8ubNuGU.
>
> Seth
>
> P.S. If you get bored, please pitch in your ideas, e.g. constructive or not!
>
> On Tuesday, September 3, 2019 at 1:22:58 PM UTC-5, Mala Dies wrote:
>>
>> Hello,
>>
>> I think I may have figured out my connection issues w/ GND and PRU on 
>> Encoder 4 on the BBBlue.
>>
>> Seth
>>
>> P.S. Time to fly!
>>
>> On Sunday, September 1, 2019 at 2:41:12 PM UTC-5, Mala Dies wrote:
>>>
>>> Hello,
>>>
>>> I have ArduCopter 3.6 on my BBBlue. Everything works and I can fly. Flying 
>>> is of no concern right now. I was wondering something.
>>>
>>> ...
>>>
>>> Does the SiP need to become so hot? I was thinking that it must be the RX 
>>> that I use w/ my transmitter. I power the RX by the  Servo Header Pins (5v).
>>>
>>> ...
>>>
>>> I know that w/ ArduCopter, the people have figured out a nice way of 
>>> communicating to the BBBlue via PRU (Encoder 4) from the hardware that I 
>>> use.
>>>
>>> Seth
>>>
>>> P.S. If you are using your BBBlue for ArduCopter/ArduPilot stuff in 
>>> general, please do not hesitate to post here. Again, my SiP is getting to 
>>> hot to handle. bzzt, bzzt!
>
> --
> 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/a0e24057-d227-4531-baac-6d2b674c6e43%40googlegroups.com.



-- 
https://beagleboard.org/about - 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/CA%2BT6QPnL7%3Dbmm3CbJ89O0SiHD8FaQTscwbZDY%3DotgYeNndXpqg%40mail.gmail.com.

Re: [beagleboard] infineon,slb9670 on beaglebone black

[Jason Kridner]

On Fri, Nov 22, 2019 at 9:55 AM  wrote:
>
> Hi Jason :)
>
> Thanks for your reply!
>
> Let me answer your questions:
> "Can you also provide the dmesg log output? Since the module is loaded, I'd 
> be inclined to think it would create whatever interfaces it would 
> provide...if the probe was successful."
>
> The dmesg log did not include any mentioning of "spi", "spidev" or "tpm". I 
> included some debug messages in the linux kernel. Specifically the modules in 
> question and rebuilt the kernel. Now when the modules are loaded they print 
> those messages in the dmesg log. I'm not sure if it will be appropriate to 
> dumo the entire dmesg log ... but here it is:
>
>  DMESG LOG *
> [0.00] Booting Linux on physical CPU 0x0
> [0.00] Linux version 4.19.73+ (ivan@tinkerboard) (gcc version 6.3.0 
> 20170516 (Debian 6.3.0-18+deb9u1)) #3 SMP PREEMPT Thu Nov 7 11:33:44 UTC 2019
> [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d
> [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
> instruction cache
> [0.00] OF: fdt: Machine model: TI AM335x BeagleBone Black
> [0.00] Memory policy: Data cache writeback
> [0.00] efi: Getting EFI parameters from FDT:
> [0.00] efi: UEFI not found.
> [0.00] cma: Reserved 48 MiB at 0x9c80
> [0.00] On node 0 totalpages: 130560
> [0.00]   Normal zone: 1148 pages used for memmap
> [0.00]   Normal zone: 0 pages reserved
> [0.00]   Normal zone: 130560 pages, LIFO batch:31
> [0.00] CPU: All CPU(s) started in SVC mode.
> [0.00] AM335X ES2.1 (sgx neon)
> [0.00] random: get_random_bytes called from start_kernel+0xa0/0x510 
> with crng_init=0
> [0.00] percpu: Embedded 18 pages/cpu s43724 r8192 d21812 u73728
> [0.00] pcpu-alloc: s43724 r8192 d21812 u73728 alloc=18*4096
> [0.00] pcpu-alloc: [0] 0
> [0.00] Built 1 zonelists, mobility grouping on.  Total pages: 129412
> [0.00] Kernel command line: console=ttyO0,115200n8 
> bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk0p1 ro rootfstype=ext4 
> rootwait coherent_pool=1M net.ifnames=0 rng_core.default_quality=100 quiet
> [0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
> [0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
> [0.00] Memory: 437628K/522240K available (13312K kernel code, 1152K 
> rwdata, 4420K rodata, 1024K init, 355K bss, 35460K reserved, 49152K 
> cma-reserved, 0K highmem)
> [0.00] Virtual kernel memory layout:
>vector  : 0x - 0x1000   (   4 kB)
>fixmap  : 0xffc0 - 0xfff0   (3072 kB)
>vmalloc : 0xe000 - 0xff80   ( 504 MB)
>lowmem  : 0xc000 - 0xdfe0   ( 510 MB)
>pkmap   : 0xbfe0 - 0xc000   (   2 MB)
>modules : 0xbf00 - 0xbfe0   (  14 MB)
>  .text : 0x(ptrval) - 0x(ptrval)   (14304 kB)
>  .init : 0x(ptrval) - 0x(ptrval)   (1024 kB)
>  .data : 0x(ptrval) - 0x(ptrval)   (1153 kB)
>   .bss : 0x(ptrval) - 0x(ptrval)   ( 356 kB)
> [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
> [0.00] ftrace: allocating 42332 entries in 125 pages
> [0.00] rcu: Preemptible hierarchical RCU implementation.
> [0.00] rcu: RCU restricting CPUs from NR_CPUS=2 to nr_cpu_ids=1.
> [0.00]  Tasks RCU enabled.
> [0.00] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1
> [0.00] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
> [0.00] IRQ: Found an INTC at 0x(ptrval) (revision 5.0) with 128 
> interrupts
> [0.00] OMAP clockevent source: timer2 at 2400 Hz
> [0.17] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 
> 89478484971ns
> [0.36] clocksource: timer1: mask: 0x max_cycles: 0x, 
> max_idle_ns: 79635851949 ns
> [0.46] OMAP clocksource: timer1 at 2400 Hz
> [0.000743] timer_probe: no matching timers found
> [0.000987] Console: colour dummy device 80x30
> [0.001015] WARNING: Your 'console=ttyO0' has been replaced by 'ttyS0'
> [0.001020] This ensures that you still see kernel messages. Please
> [0.001024] update your kernel commandline.
> [0.001083] Calibrating delay loop... 995.32 BogoMIPS (lpj=1990656)
> [0.046902] pid_max: default: 32768 minimum: 301
> [0.047197] Security Framework initialized
> [0.047211] Yama: becoming mindful.
> [0.047357] AppArmor: AppArmor initialized
> [0.047469] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
> [0.047482] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 
> bytes)
> [0.048580] CPU: Testing write buffer coherency: ok
> [0.048646] CPU0: Spectre v2: using 

Re: [beagleboard] infineon,slb9670 on beaglebone black

[Jason Kridner]

On Wed, Nov 6, 2019 at 2:09 AM  wrote:

> Hi All
>
> I have to following problem. I'm trying to setup a custom cape with and
> SPI TPM based on SLB9670VQ2.0 chip.
>
> What I've done so far is:
> 1 - building and deploying a custom kernel with SPI TPM 2.0 support
> enabled.
> 2 - Writing a dtbo to configure the right pins in their right modes for
> the TPM and to instruct the u-boot to load the specific kernel objects.
>
> After many problems and a lot of research, I managed to to build the DTBO
> activate it by including
> uboot_overlay_addr5=/lib/firmware/TPM-SLB9670-00A0.dtbo in the
> /boot/uEnv.txt and making sure the DTBO is loaded and does it's thing.
>
> Now, the DTBO IS loading and causes the respective modules to be loaded:
>
> ivan@beaglebone:~$ lsmod
> Module  Size  Used by
> 8021q  32768  0
> garp   16384  1 8021q
> stp16384  1 garp
> mrp20480  1 8021q
> llc16384  2 garp,stp
> usb_f_acm  16384  2
> u_serial   20480  3 usb_f_acm
> usb_f_ecm  20480  2
> usb_f_rndis32768  4
> u_ether20480  2 usb_f_ecm,usb_f_rndis
> libcomposite   61440  16 usb_f_ecm,usb_f_acm,usb_f_rndis
> iptable_nat16384  0
> nf_nat_ipv416384  1 iptable_nat
> nf_nat 36864  1 nf_nat_ipv4
> nf_conntrack  155648  2 nf_nat_ipv4,nf_nat
> nf_defrag_ipv6 20480  1 nf_conntrack
> nf_defrag_ipv4 16384  1 nf_conntrack
> iptable_mangle 16384  0
> iptable_filter 16384  0
>
>
>
> *tpm_tis_spi16384  0tpm_tis_core   24576  1
> tpm_tis_spitpm57344  2 
> tpm_tis_spi,tpm_tis_core*uio_pdrv_genirq
> 16384  0
> uio20480  1 uio_pdrv_genirq
> ip_tables  24576  3 iptable_mangle,iptable_filter,iptable_nat
> x_tables   32768  3 iptable_mangle,ip_tables,iptable_filter
>
> While researching, I was led to believe that the modules would create the
> "all-important" device file in the /dev directory, i.e. /dev/tpm0
> But that doesn't happen?!
>

Can you also provide the dmesg log output? Since the module is loaded, I'd
be inclined to think it would create whatever interfaces it would
provide...if the probe was successful.


> I tried modifying the dts file for my dtbo in every way I could imagine.
> It doesn't work.
>
> This is the complete dts file for my TPM dtbo:
>
> /*
> * Device Tree overlay for Infineon SLx 9670
> */
>
> #include 
> #include 
> #include 
> #include 
>
> /dts-v1/;
> /plugin/;
>
> / {
> compatible = "ti,beaglebone", "ti,beaglebone-black";
>
> /* Identification */
> part-number = "TPM-SLB9670";
> version = "00A0";
>
> exclusive-use = "P9.21", // Used as SPI0 MISO and is the Default +/
> "P9.18", // Used as SPI0 MOSI and is the Default +/
> "P9.22", // Used as SPI0 SCKL and is the Default +/
> "P9.17", // Used as SPI0 CS0 +/
>
> "P9.15", // GPIO1_16 aka GPIO_48 used as input to
> handle the IRQ from the TPM.
> "P9.13", // GPIO0_31 aka GPIO_31 used as output to
> drive the reset pin of the TPM
>
> "spi0",
> "i2c0",
> "i2c2";
>
> fragment@0 // Releasing the spi0 pins from their current
> assignments. (Tried without this fragment no difference)
> {
> target = <>;
>
> __overlay__
> {
> //  P9_21_pinmux { status = "disabled"; };
> //  P9_18_pinmux { status = "disabled"; };
> //  P9_22_pinmux { status = "disabled"; };
> //  P9_17_pinmux { status = "disabled"; };
>

Odd. I'd think you'd need to disable the pinmuxes if you want the default
to be SPI mode.

Check with 'sudo /opt/scripts/device/bone/show-pins.pl'.  I really need to
create a flag that removes the color printing on that utility and put it in
the standard path. Anyway, strip the color info and provide the output for
all the relevant pins.


>
> P9_15_pinmux { status = "disabled"; };
> P9_13_pinmux { status = "disabled"; };
> };
> };
>
> fragment@1 // Disabling both i2c interfaces since there are some
> pin conflicts, in the off chance they moght interfere (Tried without those
> two fragments - No difference)
> {
> target = <>;
>
> __overlay__
> {
> status = "disabled";
>

Isn't this the on-board i2c? Disabling that would be bad.


> };
> };
>
> fragment@2
> {
> target = <>;
>
> __overlay__
> {
> status = 

Re: [beagleboard] Re: macOS Catalina + Beaglebone Black

[Jason Kridner]

On Fri, Nov 15, 2019 at 5:42 PM  wrote:

> This did not work for me on Catalina. I updated /opt/scripts/ and saw your
> changes in boot/am335x_evm.sh. In /etc/default/bb-boot I tried
> USB_NETWORK_RNDIS_DISABLED=yes and no network interface was shown when I
> did an ifconfig except for my ethernet connection (I'm connecting over ssh
> through ethernet). I also tried USB_NETWORK_CDC_DISABLED=yes and the usb0
> network interface shows up when I ssh in over ethernet, but still doesn't
> connect from Catalina over usb (but does from High Sierra).
>

Can you try disabling CDC, leaving RNDIS enabled and install the HoRNDIS
driver?


>
> On Thursday, November 7, 2019 at 11:31:10 AM UTC-7, Jason Kridner wrote:
>>
>> I'm thinking we need something like the below, then we could edit
>> /etc/default/bb-boot to add USB_NETWORK_RNDIS_DISABLED=yes or
>> USB_NETWORK_CDC_DISABLED=yes. I'd need someone to try this on Catalina and
>> the latest Windows 10. Ugly, but something to get us over the hump.
>>
>> You may be able to log in over the virtual serial to make this change.
>> Thoughts?
>>
>> diff --git a/boot/am335x_evm.sh b/boot/am335x_evm.sh index
>> 16b1b38..7b72d0f 100755 --- a/boot/am335x_evm.sh +++ b/boot/am335x_evm.sh
>> @@ -43,7 +43,13 @@ fi if [ -f /etc/default/bb-boot ] ; then unset
>> USB_NETWORK_DISABLED + unset USB_NETWORK_RNDIS_DISABLED + unset
>> USB_NETWORK_CDC_DISABLED . /etc/default/bb-boot + if [
>> "x${USB_NETWORK_DISABLED}" = "xyes" ] ; then +
>> USB_NETWORK_RNDIS_DISABLED="yes" + USB_NETWORK_CDC_DISABLED="yes" + fi fi
>> log="am335x_evm:" @@ -507,7 +513,7 @@ run_libcomposite () { echo 500 >
>> configs/c.1/MaxPower - if [ ! "x${USB_NETWORK_DISABLED}" = "xyes" ]; then +
>> if [ ! "x${USB_NETWORK_RNDIS_DISABLED}" = "xyes" ]; then mkdir -p
>> functions/rndis.usb0 # first byte of address must be even echo
>> ${cpsw_2_mac} > functions/rndis.usb0/host_addr @@ -556,7 +562,7 @@
>> run_libcomposite () { ln -s functions/mass_storage.usb0 configs/c.1/ fi -
>> if [ ! "x${USB_NETWORK_DISABLED}" = "xyes" ]; then + if [ !
>> "x${USB_NETWORK_RNDIS_DISABLED}" = "xyes" ]; then ln -s configs/c.1 os_desc
>> mkdir functions/rndis.usb0/os_desc/interface.rndis/Icons echo 2 >
>> functions/rndis.usb0/os_desc/interface.rndis/Icons/type @@ -566,14 +572,16
>> @@ run_libcomposite () { echo "BeagleBone USB Ethernet" >
>> functions/rndis.usb0/os_desc/interface.rndis/Label/data ln -s
>> functions/rndis.usb0 configs/c.1/ + usb0="enable" fi - if [ !
>> "x${USB_NETWORK_DISABLED}" = "xyes" ]; then + if [ !
>> "x${USB_NETWORK_CDC_DISABLED}" = "xyes" ]; then mkdir -p functions/ecm.usb0
>> echo ${cpsw_4_mac} > functions/ecm.usb0/host_addr echo ${cpsw_5_mac} >
>> functions/ecm.usb0/dev_addr ln -s functions/ecm.usb0 configs/c.1/ +
>> usb1="enable" fi mkdir -p functions/acm.usb0 @@ -590,8 +598,6 @@
>> run_libcomposite () { fi fi - usb0="enable" - usb1="enable" echo "${log}
>> g_multi Created" else echo "${log} FIXME: need to bring down g_multi first,
>> before running a second time."
>>
>> On Thursday, November 7, 2019 at 10:15:08 AM UTC-5, John Allwine wrote:
>>>
>>> Thanks Jason, how do you disable the RNDIS interface used for Windows?
>>>
>>> On Nov 5, 2019, at 3:21 PM, Jason Kridner wrote:
>>>
>>>
>>> 
>>> Please cc the BeagleBoard Google Group on support issues if it isn't a
>>> private matter. I didn't figure you cared if this issue was private, so
>>> I've added it to the reply and moved you into BCC.
>>>
>>> I ran into the same problem last week at a training ELC-E (bbb.io/t).
>>> The work-around I found is to disable the RNDIS interface used for Windows.
>>> Seems Microsoft and Apple have both added the same bug in their operating
>>> systems. If either one sees the other's compatible network driver, they
>>> choose to not work. :-(
>>>
>>> One alternative might be to go back to using HoRNDIS, but it would mean
>>> asking the maintainer to support Catalina.
>>>
>>> On Tue, Nov 5, 2019 at 4:29 PM someone wrote:
>>>
>>>> Hi Jason,
>>>>
>>>> We've gotten reports from users using the latest version of macOS that
>>>> they aren't able to connect to the Pocket NC over USB. Are you aware of any
>>>> issues connecting over USB to the Beaglebone Black on macOS Cat

Re: [beagleboard] Python code got killed on BBAI

[Jason Kridner]

I took a look at the same code from
https://neo-ai-dlr.readthedocs.io/en/latest/install.html.

I took the liberty of replacing python2.7 with python3.5 as the default.
Also, I copied libdlr.* manually as the install script doesn't seem to do
it.

I was able to build it, but when I try to run the same script, I get:

debian@beaglebone:~/neo-ai-dlr/tests/python/integration$ python
load_and_run_tvm_model.py
Preparing model artifacts for resnet18_v1 ...
Preparing model artifacts for 4in2out ...
Preparing model artifacts for assign_op ...
Testing inference on resnet18...
Traceback (most recent call last):
  File "load_and_run_tvm_model.py", line 69, in 
test_multi_input_multi_output()
  File "load_and_run_tvm_model.py", line 30, in
test_multi_input_multi_output
assert model._impl._get_output_size_dim(0) == (2, 1)
AttributeError: 'DLRModel' object has no attribute '_impl'

On Thu, Nov 7, 2019 at 11:04 AM jonnymo  wrote:

> Sounds like your BB AI ran out of memory not disk space.   Is the Python
> script you are running part of the Cloud9 apps or your own creation?
> Python has a tendency to consume all the available memory on a system if
> you let it and not delete variables or objects when no longer being used.
>
> You can see the available memory in multiple ways:
> Ex:
>   - top
>   - free
>   - cat /proc/mem
>
> Or from Python as in this example:
>
> https://stackoverflow.com/questions/1204378/getting-total-free-ram-from-within-python
>
> Cheers,
>
> Jon
>
>
> On Thu, Nov 7, 2019 at 7:14 AM Jianzhong Xu 
> wrote:
>
>> I was trying to run a Python code. It failed and gave me error message
>> "Killed". Looks like this message means the Python program is out of
>> memory:
>> https://stackoverflow.com/questions/1811173/why-does-my-python-script-randomly-get-killed
>> .
>>
>> Then I opened /var/log/syslog and saw the following:
>>
>> Nov  6 14:26:56 beaglebone kernel: [ 3072.894508] Out of memory: Kill
>> process 28376 (python3) score 525 or sacrifice child
>> Nov  6 14:26:56 beaglebone kernel: [ 3072.919653] Killed process 28376
>> (python3) total-vm:491332kB, anon-rss:322104kB, file-rss:6724kB,
>> shmem-rss:0kB
>>
>> Below is what df reports:
>> debian@beaglebone:~/neo-ai-dlr/tests/python/integration$ df -h
>> Filesystem  Size  Used Avail Use% Mounted on
>> udev199M 0  199M   0% /dev
>> tmpfs62M  7.0M   55M  12% /run
>> /dev/mmcblk0p1   30G  4.2G   24G  15% /
>> tmpfs   306M  8.0K  306M   1% /dev/shm
>> tmpfs   5.0M  4.0K  5.0M   1% /run/lock
>> tmpfs   306M 0  306M   0% /sys/fs/cgroup
>> tmpfs62M  4.0K   62M   1% /run/user/1000
>>
>> Why did the Python code run out of memory and how can I solve it?
>>
>> Thanks and regards,
>> Jianzhong
>>
>> --
>> 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/be61ca7f-139c-4c6c-9414-b700f0ca031f%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/CAG99bkpD-tvv-rfN6Nt52zzfofNZGTuoQ1MA_-1BysoGiG5iwA%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/CA%2BT6QPk8AJB7PvnBsya2UcM-Xs_2Vu6gwMtxmiuHE5VeXT9kjw%40mail.gmail.com.

[beagleboard] Re: macOS Catalina + Beaglebone Black

[Jason Kridner]

I'm thinking we need something like the below, then we could edit 
/etc/default/bb-boot to add USB_NETWORK_RNDIS_DISABLED=yes or 
USB_NETWORK_CDC_DISABLED=yes. I'd need someone to try this on Catalina and 
the latest Windows 10. Ugly, but something to get us over the hump.

You may be able to log in over the virtual serial to make this change.  
Thoughts?

diff --git a/boot/am335x_evm.sh b/boot/am335x_evm.sh index 16b1b38..7b72d0f 
100755 --- a/boot/am335x_evm.sh +++ b/boot/am335x_evm.sh @@ -43,7 +43,13 @@ 
fi if [ -f /etc/default/bb-boot ] ; then unset USB_NETWORK_DISABLED + unset 
USB_NETWORK_RNDIS_DISABLED + unset USB_NETWORK_CDC_DISABLED . 
/etc/default/bb-boot + if [ "x${USB_NETWORK_DISABLED}" = "xyes" ] ; then + 
USB_NETWORK_RNDIS_DISABLED="yes" + USB_NETWORK_CDC_DISABLED="yes" + fi fi 
log="am335x_evm:" @@ -507,7 +513,7 @@ run_libcomposite () { echo 500 > 
configs/c.1/MaxPower - if [ ! "x${USB_NETWORK_DISABLED}" = "xyes" ]; then + 
if [ ! "x${USB_NETWORK_RNDIS_DISABLED}" = "xyes" ]; then mkdir -p 
functions/rndis.usb0 # first byte of address must be even echo 
${cpsw_2_mac} > functions/rndis.usb0/host_addr @@ -556,7 +562,7 @@ 
run_libcomposite () { ln -s functions/mass_storage.usb0 configs/c.1/ fi - 
if [ ! "x${USB_NETWORK_DISABLED}" = "xyes" ]; then + if [ ! 
"x${USB_NETWORK_RNDIS_DISABLED}" = "xyes" ]; then ln -s configs/c.1 os_desc 
mkdir functions/rndis.usb0/os_desc/interface.rndis/Icons echo 2 > 
functions/rndis.usb0/os_desc/interface.rndis/Icons/type @@ -566,14 +572,16 
@@ run_libcomposite () { echo "BeagleBone USB Ethernet" > 
functions/rndis.usb0/os_desc/interface.rndis/Label/data ln -s 
functions/rndis.usb0 configs/c.1/ + usb0="enable" fi - if [ ! 
"x${USB_NETWORK_DISABLED}" = "xyes" ]; then + if [ ! 
"x${USB_NETWORK_CDC_DISABLED}" = "xyes" ]; then mkdir -p functions/ecm.usb0 
echo ${cpsw_4_mac} > functions/ecm.usb0/host_addr echo ${cpsw_5_mac} > 
functions/ecm.usb0/dev_addr ln -s functions/ecm.usb0 configs/c.1/ + 
usb1="enable" fi mkdir -p functions/acm.usb0 @@ -590,8 +598,6 @@ 
run_libcomposite () { fi fi - usb0="enable" - usb1="enable" echo "${log} 
g_multi Created" else echo "${log} FIXME: need to bring down g_multi first, 
before running a second time."

On Thursday, November 7, 2019 at 10:15:08 AM UTC-5, John Allwine wrote:
>
> Thanks Jason, how do you disable the RNDIS interface used for Windows?
>
> On Nov 5, 2019, at 3:21 PM, Jason Kridner wrote:
>
>
> 
> Please cc the BeagleBoard Google Group on support issues if it isn't a 
> private matter. I didn't figure you cared if this issue was private, so 
> I've added it to the reply and moved you into BCC.
>
> I ran into the same problem last week at a training ELC-E (bbb.io/t). The 
> work-around I found is to disable the RNDIS interface used for Windows. 
> Seems Microsoft and Apple have both added the same bug in their operating 
> systems. If either one sees the other's compatible network driver, they 
> choose to not work. :-(
>
> One alternative might be to go back to using HoRNDIS, but it would mean 
> asking the maintainer to support Catalina.
>
> On Tue, Nov 5, 2019 at 4:29 PM someone wrote:
>
>> Hi Jason,
>>
>> We've gotten reports from users using the latest version of macOS that 
>> they aren't able to connect to the Pocket NC over USB. Are you aware of any 
>> issues connecting over USB to the Beaglebone Black on macOS Catalina?
>>
>>
>> -- 
> https://beagleboard.org/about
>
>

-- 
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/31b61f57-055c-468f-a38c-93e4ef386fdd%40googlegroups.com.

[beagleboard] Re: Beaglebone AI, only 610M RAM?

[Jason Kridner]

On Wednesday, November 6, 2019 at 7:26:05 AM UTC-5, Richard Krehbiel wrote:
>
> I built my image from these 
>  
> instructions, 
> and on my Beaglebone AI with 1GB of RAM, /proc/meminfo says *"624984 kB"*.
>
> So, what's consuming the other 413M?  Can I get some of that back?  Thanks.
>
>
By default, it is reserved for the C66/EVE processors. There has been much 
discussion about making it more dynamically allocatable, but, for now, it 
would require editing the device tree. 

In specific, these lines would need to be removed or marked "disabled" by 
an overlay: 
https://github.com/beagleboard/BeagleBoard-DeviceTrees/blob/2d1271702ce962160fe3a632ebee394207e2714b/src/arm/am5729-beagleboneai.dts#L38-L101

Due to a lack of foresight, the nodes don't have labels, which makes 
creating an overlay a bit more difficult.

In the default image, you can go to /opt/source/dtb-4.14-ti, edit 
src/arm/am5729-beagleboneai.dts to remove those lines, make, sudo make 
install and reboot and you should get all of the memory back.

-- 
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/a12120f9-9320-4ac4-bf27-deae6ca956c4%40googlegroups.com.

[beagleboard] Re: macOS Catalina + Beaglebone Black

[Jason Kridner]

Please cc the BeagleBoard Google Group on support issues if it isn't a
private matter. I didn't figure you cared if this issue was private, so
I've added it to the reply and moved you into BCC.

I ran into the same problem last week at a training ELC-E (bbb.io/t). The
work-around I found is to disable the RNDIS interface used for Windows.
Seems Microsoft and Apple have both added the same bug in their operating
systems. If either one sees the other's compatible network driver, they
choose to not work. :-(

One alternative might be to go back to using HoRNDIS, but it would mean
asking the maintainer to support Catalina.

On Tue, Nov 5, 2019 at 4:29 PM someone wrote:

> Hi Jason,
>
> We've gotten reports from users using the latest version of macOS that
> they aren't able to connect to the Pocket NC over USB. Are you aware of any
> issues connecting over USB to the Beaglebone Black on macOS Catalina?
>
>
> --
https://beagleboard.org/about

-- 
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/CA%2BT6QP%3Dgsj5H5EGod%2B2DgZHGs%3DVeferVoYnK%3Dr3_3NdsgNxi1w%40mail.gmail.com.

Re: [beagleboard] Re: TIDL Classification example not properly identify objects

[Jason Kridner]

Stick to 4.14.

Provide me the output of:
cd /var/lib/cloud9;git status;git show | head -1

On Mon, Oct 28, 2019 at 5:19 AM  wrote:

> I get the same error as well.  Updated everything and rebooted a couple of
> times.
>
> On Wednesday, October 23, 2019 at 11:37:39 PM UTC-5, jonnymo wrote:
>>
>> I've pulled in the changes but now I get the following error when
>> attempting to run the TIDL example from the Cloud9 IDE.
>> NOTE: I've updated to the 4.19 kernel, so I am not sure if that is
>> causing the issue:
>>
>> *Command: BeagleBone/AI/tidl/classification.tidl.cpp*
>> *Python: python3*
>> *Python path:
>> /usr/lib/python3.7/dist-packages:/usr/local/lib/python3.7/dist-packages*
>> */var/lib/cloud9/common/Makefile:27:
>> MODEL=BeagleBoard.org_BeagleBone_AI,TARGET=classification.tidl,COMMON=/var/lib/cloud9/common*
>> */var/lib/cloud9/common/Makefile:145:
>> GEN_DIR=/tmp/cloud9-examples,CHIP=am57xx,PROC=tidl,PRUN=,PRU_DIR=,EXE=.so*
>> *ti-mct-heap-check -c*
>> *sudo mjpg_streamer -i "input_opencv.so -r 640x480 --filter
>> ./classification.tidl.so <http://classification.tidl.so>" -o
>> "output_http.so -p 8080 -w /usr/share/mjpg-streamer/www"*
>> *[sudo] password for debian:*
>> *MJPG Streamer Version.: 2.0*
>> * i: device... : default*
>> * i: Desired Resolution: 640 x 480*
>> * i: filter... : ./classification.tidl.so
>> <http://classification.tidl.so>*
>> * i: filter args . :*
>> *Initializing filter*
>> *loading configuration*
>> *allocating execution object pipelines (EOP)*
>> *CMEM Error: init: major version mismatch between interface and driver.*
>> *CMEM Error: needs driver version 0x4150002, got 0x416*
>> *TIOCL FATAL: The cmemk kernel module is not installed. Consult the
>> OpenCL UserGuide at
>> http://software-dl.ti.com/mctools/esd/docs/opencl/index.html
>> <http://software-dl.ti.com/mctools/esd/docs/opencl/index.html>*
>> */var/lib/cloud9/common/Makefile:167: recipe for target 'start' failed*
>> *make: *** [start] Error 1*
>>
>>
>>
>> Cheers,
>>
>> Jon
>>
>>
>> On Wed, Oct 23, 2019 at 9:32 AM jonnymo  wrote:
>>
>>> Jason,
>>>
>>> I appreciate the update.  I'll update the code on me BB AI and run the
>>> exercise again.
>>>
>>> Now to get the blinkLED.py and JavaScript examples working.
>>>
>>> I'm looking forward for the Tensorflow Lite support, so I'll keep and
>>> eye on that.
>>>
>>> Thanks for the work you do on this.
>>>
>>> Cheers,
>>>
>>> Jon
>>>
>>> On Wed, Oct 23, 2019 at 8:20 AM Jason Kridner  wrote:
>>>
>>>> Sorry about that. I broke the example. I've updated it and it should
>>>> work now.
>>>>
>>>>
>>>> https://github.com/beagleboard/cloud9-examples/commit/210388017fcb233c2f422d54af293bb8d5c94bc2
>>>>
>>>> I was visiting the TI office and talking to the developers about the
>>>> performance of this example. According to profiles,
>>>> it should run up to 60fps. I attempted to make some changes to speed it
>>>> up, but I did it wrong.
>>>>
>>>> You can group different layers in the network to run on different
>>>> processors. For this classifier network, it is said to
>>>> be fastest to run the first 11 stages on EVEs as fixed-point processes
>>>> and then run the last 3 layers as floating-point
>>>> processes on the C66 DSPs. And, because we'd only be running 3 layers
>>>> on the DSPs, we only need a single DSP.
>>>>
>>>> Anyway, I didn't assign the layers properly and I still need to look at
>>>> the code a bit more to set them properly.
>>>>
>>>> For now, I've just switched back to running on all 14 layers on 4 EVEs.
>>>> The 30fps data from the camera seems to
>>>> be reasonably processed with this configuration.
>>>>
>>>> I picked up a Logitech C922 that is capable of doing 60fps and I'll be
>>>> looking to update the demo to run that way soon
>>>> and finishing up the segmentation demo.
>>>>
>>>> Checking the commit-log is a nice way to check-up on me, even if my
>>>> comments aren't the best.
>>>>
>>>> The errors are mostly due to the fact that I'm learning as well. I'm
>>>> trying to get the TI developers to use my methodology
>>>> of single-file mjpg-

[beagleboard] bonescript@0.7.4-beta1 published

[Jason Kridner]

Realized I hadn't published the work already done on putting BeagleBone AI 
GPIO pins into the node.js BoneScript library.

Any testing on this version would really be appreciated.


debian@beaglebone:/var/lib/cloud9/sensors$ *cd /usr/local/lib*
debian@beaglebone:/usr/local/lib$ *sudo npm install --unsafe-perm 
bonescript@0.7.4-beta1* 
npm WARN deprecated coffee-script@1.9.1: CoffeeScript on NPM has moved to 
"coffeescript" (no hyphen)
npm WARN deprecated json3@3.2.6: Please use the native JSON object instead 
of JSON 3
npm WARN deprecated json3@3.3.2: Please use the native JSON object instead 
of JSON 3
colors@1.0.3 node_modules/winston/node_modules/colors -> node_modules/colors
cycle@1.0.3 node_modules/winston/node_modules/cycle -> node_modules/cycle
eyes@0.1.8 node_modules/winston/node_modules/eyes -> node_modules/eyes
isstream@0.1.2 node_modules/winston/node_modules/isstream -> 
node_modules/isstream
pkginfo@0.3.1 node_modules/winston/node_modules/pkginfo -> 
node_modules/pkginfo
stack-trace@0.0.10 node_modules/winston/node_modules/stack-trace -> 
node_modules/stack-trace
/usr/local/lib
└─┬ bonescript@0.7.4-beta1
  └── winston@2.1.1

npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@^1.1.2 
(node_modules/chokidar/node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for 
fsevents@1.2.9: wanted {"os":"darwin","arch":"any"} (current: 
{"os":"linux","arch":"arm"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: xpc-connection@~0.1.4 
(node_modules/sensortag/node_modules/noble/node_modules/xpc-connection):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for 
xpc-connection@0.1.4: wanted {"os":"darwin","arch":"any"} (current: 
{"os":"linux","arch":"arm"})
npm WARN enoent ENOENT: no such file or directory, open 
'/usr/local/lib/package.json'
npm WARN lib No description
npm WARN lib No repository field.
npm WARN lib No README data
npm WARN lib No license field.
debian@beaglebone:/usr/local/lib$ *node -pe 
"require('bonescript').bone.getPinObject('p9.15').ai.gpio"*
76


-- 
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/28ae9679-ddb7-42e3-9437-aa56dacb147d%40googlegroups.com.

Re: [beagleboard] BBAI: Assistance requested with configuring P9_15 as an output gpio

[Jason Kridner]

On Thu, Oct 24, 2019 at 12:39 PM jonnymo  wrote:

> Oh, duh!  I should  have caught that missing lib.
> Okay, so the output of show-pins shows P.15 but it neither shows as up or
> down.  Is this correct?
>
> *debian@beaglebone:~$ sudo /opt/scripts/device/bone/show-pins.pl
>  | grep "P9.15"*
> *P9.15 69  AG4 e fast gpio3_12*
>
>
> Also, is the '69' value the gpio number that is used to enable this?
> Such as :
>
> *debian@beaglebone:~$ sudo echo 69 > /sys/class/gpio/export *
> *debian@beaglebone:~$ sudo echo out > /sys/class/gpio/gpio69/direction *
> *debian@beaglebone:~$ sudo echo 1 > /sys/class/gpio/gpio69/value*
>
>
> Since this is gpio3_12 I was thinking it was '108' considering the 32x3+12
> calculation as with the BB Black.
> Neither 69 or 108 seems to work though.
>

There’s no gpio0 on AM57x, so it is 2*32 +12 = 76.


> Also, are the failed messages from the version output something to be
> concerned about?
>
> *[1.582238] remoteproc remoteproc4: Direct firmware load for
> dra7-ipu1-fw.xem4 failed with error -2*
> *[1.582247] remoteproc remoteproc4: powering up 5882.ipu*
> *[1.582322] remoteproc remoteproc4: Direct firmware load for
> dra7-ipu1-fw.xem4 failed with error -2*
> *[1.582330] remoteproc remoteproc4: request_firmware failed: -2*
> *[1.588375] remoteproc remoteproc5: Direct firmware load for
> dra7-ipu2-fw.xem4 failed with error -2*
> *[1.588383] remoteproc remoteproc5: powering up 5502.ipu*
> *[1.588455] remoteproc remoteproc5: Direct firmware load for
> dra7-ipu2-fw.xem4 failed with error -2*
> *[1.588463] remoteproc remoteproc5: request_firmware failed: -2*
> *[1.594532] remoteproc remoteproc6: Direct firmware load for
> dra7-dsp1-fw.xe66 failed with error -2*
> *[1.594542] remoteproc remoteproc6: powering up 4080.dsp*
> *[1.594630] remoteproc remoteproc6: Direct firmware load for
> dra7-dsp1-fw.xe66 failed with error -2*
> *[1.594639] remoteproc remoteproc6: request_firmware failed: -2*
> *[1.600688] remoteproc remoteproc7: Direct firmware load for
> dra7-dsp2-fw.xe66 failed with error -2*
> *[1.600697] remoteproc remoteproc7: powering up 4100.dsp*
> *[1.600770] remoteproc remoteproc7: Direct firmware load for
> dra7-dsp2-fw.xe66 failed with error -2*
> *[1.600777] remoteproc remoteproc7: request_firmware failed: -2*
> *dmesg | grep pru*
>
>
>
> Thanks,
>
> Jon
>
> On Thu, Oct 24, 2019 at 8:24 AM Robert Nelson 
> wrote:
>
>> On Thu, Oct 24, 2019 at 10:12 AM Jon Morss  wrote:
>> >
>> > Hi,
>> >
>> > I've been trying to configure a header gpio pin such as P9_15 as an
>> output port on the BBAI but I am having no luck.  This pin is used with the
>> Cloud9 Python and JS examples but it is not working so I have tried to
>> enable it manually.
>> >
>> > I've added the following in the am5729-beagleboneai.dts file and run
>> make and make install and a reboot:
>> >
>> > cape_pins: cape_pins {
>> > compatible = "gpio-leds";
>> > pinctrl-names = "default";
>> > gpios = < 12 GPIO_ACTIVE_HIGH>;
>> > pinctrl-0 = <_pins_default>;
>> > };
>> >
>> >
>> >
>> >  DRA7XX_CORE_IOPAD(0x3514, PIN_OUTPUT | MUX_MODE14) /* AG4: P9.15:
>> vin1a_d8.gpio3_12 - MDIR2A */
>>
>> ^ looks correct..
>>
>>
>> > The config-pins tools shows
>> >
>> > debian@beaglebone:~$ sudo config-pin -q p9.15
>> > [sudo] password for debian:
>> > P9_15 pinmux file not found!
>> > Pin has no cape: P9_15
>>
>> Don't use config-pin the bbai..
>>
>> > The show-pins tools shows:
>> >
>> > debian@beaglebone:~$ sudo /opt/scripts/device/bone/show-pins.pl
>> > Can't locate Inline/Files.pm in @INC (you may need to install the
>> Inline::Files module) (@INC contains: /etc/perl
>> /usr/local/lib/arm-linux-gnueabihf/perl/5.24.1 /usr/local/share/perl/5.24.1
>> /usr/lib/arm-linux-gnueabihf/perl5/5.24 /usr/share/perl5
>> /usr/lib/arm-linux-gnueabihf/perl/5.24 /usr/share/perl/5.24
>> /usr/local/lib/site_perl /usr/lib/arm-linux-gnueabihf/perl-base) at
>> /opt/scripts/device/bone/show-pins.pl line 11.
>> > BEGIN failed--compilation aborted at /opt/scripts/device/bone/
>> show-pins.pl line 11.
>>
>> sudo apt install libinline-files-perl
>>
>>
>> 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/CAOCHtYiApGknihWCTdh5B0Fz75pOTkqoA4Ka%2BN0OUxCH8V5iWw%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 

[beagleboard] Re: BBONE-BLACK-4G - Lifecycle

[Jason Kridner]

On Thursday, October 17, 2019 at 2:33:02 AM UTC-4, M S, Siddeshappa wrote:
>
> Hi Team,
>
>  
>
> Please see the below issue one of our customer asking for the lifecycle 
> for BBONE-BLACK-4G Board.
>
>  
>
>
> Customer Issue – do you have any information regarding the lifecycle of 
> our code *BBONE-BLACK-4G* ?
>

Estimated life at launch is 10 years for BeagleBoard.org products. We will 
reach that in 2023 for this product. However, the demand currently is very 
strong.
 

> Do you think that this product will still be in our catalog for almost 5 
> years?
>

As long as sales continue as-is, absolutely. We may eventually need to 
replace the microSD card cage and eMMC flash again, but we will do so 
relatively seemlessly. 
 

>  
>
>  
>
>  
>
>  
>
>  
>
>
>  
>
>  
>

-- 
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/5b809e80-1106-4653-89af-8bb0fe657937%40googlegroups.com.