[beagleboard] Beaglebone AI Device Tree Overlay syntax

[John Allwine]

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

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

Re: [beagleboard] MachineKit

[John Allwine]

Hi John,

I'm not a maintainer of MachineKit or LinuxCNC, so I can't speak for them,
but I do actively use MachineKit on the BBB. Development on MachineKit
seems to be mostly focused on the HAL (Hardware Abstraction Layer) of the
technology stack and breaking apart LinuxCNC into more maintainable pieces.
MachineKit is now split into two projects, MachineKit-HAL (
https://github.com/machinekit/machinekit-hal) and MachineKit-CNC (
https://github.com/machinekit/machinekit-cnc). The CNC side of the project
is very stale. Instead of developing the CNC side, they performed a fork of
LinuxCNC and changed only what was necessary to use the CNC side of
LinuxCNC on top of MachineKit-HAL and actively rebase upstream changes to
be as insync with LinuxCNC as possible. This project is called
EMCApplication (https://github.com/machinekit/EMCApplication).

I'm not too familiar with the details of the real time differences, but I
believe MachineKit-HAL will take advantage of real time features if they
are present on the machine. We currently use the rt-preempt kernel to get
the best latencies we can, but one of the biggest benefits of the
BBB+MachineKit-HAL is it's hal_pru_generic implementation that allows
dedicated use of the PRU to generate step+direction signals, so it isn't
necessary for that processing to happen on the main CPU.

There isn't currently a BBB image available that uses MachineKit-HAL+CNC or
MachineKit-HAL+EMCApplication (the current images use the archived
MachineKit project prior to the split). I've made progress towards putting
an image together with the latest of MachineKit-HAL+EMCApplication on the
BBB and BBAI, but I'm not sure when it will be ready for general use.

-John

On Fri, Jun 4, 2021 at 5:06 PM John Dammeyer  wrote:

> >
> > For the BBB, they originally used the Xenomai kernel patchset, then
> > eventually started working on utilizing the RT Linux stuff.. Then they
> > discovered FGPA hardware, shortly after their forum really became
> > quiet..
> >
> > It's just an application that utilized Xenomai and RT kernel features..
>
>
> Thanks.  That's the information I was looking for.
> Have a good weekend.
> John
>
> >
> > 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/061a01d75996%243a495590%24aedc00b0%24%40autoartisans.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/CAPEK9qZ9VpaE%3DrwdfMK93m4n5YbVWvd59xByp08QgGf5mzY7cw%40mail.gmail.com.

Re: [beagleboard] versioning beaglebone images with OSTree

[John Allwine]

Thanks Robert!

What builds the initrd file? One strategy I'm seeing for using OSTree is do 
some of the filesystem mounting in initrd, but I'm not sure how to modify 
what is currently used.

-John

On Tuesday, May 4, 2021 at 5:05:15 PM UTC-6 RobertCNelson wrote:

> On Tue, May 4, 2021 at 5:28 PM John Allwine  wrote:
> >
> > Where is the source code for what u-boot runs by default on the 
> Beaglebone images? I see some references to patches that I assume are 
> applied to u-boot on the Beaglebone:
> > 
> https://github.com/beagleboard/image-builder/blob/master/target/chroot/beagleboard.org-buster.sh#L276-L291
> >
> > Is there somewhere I can see the applied versions of those or do I have 
> to manually apply them? I'm trying to understand what exactly the 
> environment variables in uEnv.txt do.
>
> You can find that tree here:
>
> https://github.com/beagleboard/u-boot/tree/v2019.04-bbb.io-am335x
>
> it's built/provided via the debian package: bb-u-boot-am335x-evm
>
> https://github.com/rcn-ee/repos/tree/master/bb-u-boot-am335x-evm
>
> 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/7862b0a1-3373-470e-965a-0b3d61504be0n%40googlegroups.com.

Re: [beagleboard] versioning beaglebone images with OSTree

[John Allwine]

Where is the source code for what u-boot runs by default on the Beaglebone 
images? I see some references to patches that I assume are applied to 
u-boot on the Beaglebone:
https://github.com/beagleboard/image-builder/blob/master/target/chroot/beagleboard.org-buster.sh#L276-L291

Is there somewhere I can see the applied versions of those or do I have to 
manually apply them? I'm trying to understand what exactly the environment 
variables in uEnv.txt do.
On Friday, April 30, 2021 at 10:20:21 AM UTC-6 John Allwine wrote:

> Thanks Robert! Do you have a sense of what the major hurdles of 
> implementing this are? From what I can tell:
>
> * Setting up U-Boot to look in the proper ostree deployment
> * Setting up bind mounts to the directories in /
> * Ensuring the system doesn't write to any directories other than /etc and 
> /var
> * Handling merges of /etc on update
> * Some kind of automatic rollback handling in case something goes wrong 
> with an update and system won't boot
>
> Does this sound right? Any thoughts on any of those? Am I missing anything 
> major (my guess is likely!)?
>
> On Thursday, April 22, 2021 at 9:35:57 AM UTC-6 RobertCNelson wrote:
>
>> On Fri, Apr 16, 2021 at 7:04 PM Robert Nelson  
>> wrote: 
>> > 
>> > On Fri, Apr 16, 2021 at 4:19 PM John Allwine  
>> wrote: 
>> > > 
>> > > I'd like to start a discussion about creating complete Beaglebone 
>> images that leverage OSTree to be able to atomically update the system as a 
>> whole. The scripts in https://github.com/beagleboard/image-builder 
>> generate complete images for the Beaglebone that include specific kernel, 
>> apt packages, boot settings, git repositories, etc. Updating a deployed 
>> Beaglebone without reflashing a new image involves piecemeal updating of 
>> those various components. Improperly updating can leave the system in a 
>> broken state and can be difficult to get back into a good state. It would 
>> be great to be able to leverage those image-builder scripts to construct 
>> the rootfs, add that tree as a commit to an OSTree repository and properly 
>> configured Beaglebones could download that commit and atomically switch to 
>> it to update the whole system while preserving portions of the system such 
>> as home directories and other key directories (/etc, /var?). If something 
>> did break, rolling back is easy as well. 
>> > > 
>> > > Configuring a Beaglebone this way would make most of the system 
>> read-only so using apt-get to install new packages wouldn't work without 
>> altering its implementation, but that seems like a worthy trade off. This 
>> would be for someone who has a Beaglebone with an out-of-the-box image and 
>> some scripts/servers set up in their home directory who doesn't want to 
>> worry too much about the system as a whole, but wants to be able to easily 
>> update it without reflashing or doing piecemeal updates. People who develop 
>> software for Beaglebones in their customers' devices could host their own 
>> OSTree repository and make their own modifications to the image-builder 
>> scripts if they have their own set of system dependencies (this is what I'd 
>> like to do). 
>> > > 
>> > > Does anyone else think this would be useful? Is there anyone with the 
>> expertise to know what details would need to be taken into account to make 
>> this work properly? 
>> > > 
>> > > OSTree documentation is here: https://ostreedev.github.io/ostree/ 
>> > > It lists a number of examples of it being used in various Linux 
>> distributions. 
>> > 
>> > I remember seeing one of Peter Robinson's demo of Fedora IoT a few 
>> > years back at ELC, that used OSTree+btrfs. It worked pretty well. At 
>> > that time, I made sure btrfs worked well for us, to possibly look down 
>> > that road. My biggest issue, the 4gb eMMC, was too limited for the 
>> > out of box images to do something like that. For an iot/console image 
>> > the idea would still work well.. While working on bullseye images 
>> > this week, i noticed we still have the "--no-merged-usr" flag for 
>> > debootstrap, we should try with that removed in 'bullseye', as ostree 
>> > needs that.. 
>> > 
>> > We did have ostree installed on the lxqt images: 
>> > 
>> > 
>> https://github.com/beagleboard/image-builder/blob/master/configs/bb.org-debian-buster-lxqt-v5.4.conf#L138
>>  
>> > 
>> > --no-merged-usr (due to bugs in stretch/buster..) 
>> > 
>> https://github.com/beagleboard/image-builder/blob/master/scripts

Re: [beagleboard] versioning beaglebone images with OSTree

[John Allwine]

Thanks Robert! Do you have a sense of what the major hurdles of 
implementing this are? From what I can tell:

* Setting up U-Boot to look in the proper ostree deployment
* Setting up bind mounts to the directories in /
* Ensuring the system doesn't write to any directories other than /etc and 
/var
* Handling merges of /etc on update
* Some kind of automatic rollback handling in case something goes wrong 
with an update and system won't boot

Does this sound right? Any thoughts on any of those? Am I missing anything 
major (my guess is likely!)?

On Thursday, April 22, 2021 at 9:35:57 AM UTC-6 RobertCNelson wrote:

> On Fri, Apr 16, 2021 at 7:04 PM Robert Nelson  wrote:
> >
> > On Fri, Apr 16, 2021 at 4:19 PM John Allwine  wrote:
> > >
> > > I'd like to start a discussion about creating complete Beaglebone 
> images that leverage OSTree to be able to atomically update the system as a 
> whole. The scripts in https://github.com/beagleboard/image-builder 
> generate complete images for the Beaglebone that include specific kernel, 
> apt packages, boot settings, git repositories, etc. Updating a deployed 
> Beaglebone without reflashing a new image involves piecemeal updating of 
> those various components. Improperly updating can leave the system in a 
> broken state and can be difficult to get back into a good state. It would 
> be great to be able to leverage those image-builder scripts to construct 
> the rootfs, add that tree as a commit to an OSTree repository and properly 
> configured Beaglebones could download that commit and atomically switch to 
> it to update the whole system while preserving portions of the system such 
> as home directories and other key directories (/etc, /var?). If something 
> did break, rolling back is easy as well.
> > >
> > > Configuring a Beaglebone this way would make most of the system 
> read-only so using apt-get to install new packages wouldn't work without 
> altering its implementation, but that seems like a worthy trade off. This 
> would be for someone who has a Beaglebone with an out-of-the-box image and 
> some scripts/servers set up in their home directory who doesn't want to 
> worry too much about the system as a whole, but wants to be able to easily 
> update it without reflashing or doing piecemeal updates. People who develop 
> software for Beaglebones in their customers' devices could host their own 
> OSTree repository and make their own modifications to the image-builder 
> scripts if they have their own set of system dependencies (this is what I'd 
> like to do).
> > >
> > > Does anyone else think this would be useful? Is there anyone with the 
> expertise to know what details would need to be taken into account to make 
> this work properly?
> > >
> > > OSTree documentation is here: https://ostreedev.github.io/ostree/
> > > It lists a number of examples of it being used in various Linux 
> distributions.
> >
> > I remember seeing one of Peter Robinson's demo of Fedora IoT a few
> > years back at ELC, that used OSTree+btrfs. It worked pretty well. At
> > that time, I made sure btrfs worked well for us, to possibly look down
> > that road. My biggest issue, the 4gb eMMC, was too limited for the
> > out of box images to do something like that. For an iot/console image
> > the idea would still work well.. While working on bullseye images
> > this week, i noticed we still have the "--no-merged-usr" flag for
> > debootstrap, we should try with that removed in 'bullseye', as ostree
> > needs that..
> >
> > We did have ostree installed on the lxqt images:
> >
> > 
> https://github.com/beagleboard/image-builder/blob/master/configs/bb.org-debian-buster-lxqt-v5.4.conf#L138
> >
> > --no-merged-usr (due to bugs in stretch/buster..)
> > 
> https://github.com/beagleboard/image-builder/blob/master/scripts/debootstrap.sh#L138
>
> bullseye and later now has --no-merged-usr disabled:
>
>
> https://github.com/RobertCNelson/omap-image-builder/commit/2d7bf137e3447038142a83751ed4fca76faca5fe
>
> 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/3934e734-8dda-4a0b-abf6-d70d9ad6151cn%40googlegroups.com.

Re: [beagleboard] building something from source in image-builder script

[John Allwine]

Perfect, thanks!

I completely missed this line where it blows the whole directory away:
https://github.com/beagleboard/image-builder/blob/24b8b155b41d4d0b4a3d7d3e2295441df81b94b0/RootStock-NG.sh#L160

I must be looking at a partial temp directory from a canceled run or
something.

Thanks for your help Robert!


On Tue, Apr 27, 2021 at 1:09 PM Robert Nelson 
wrote:

> On Tue, Apr 27, 2021 at 1:59 PM John Allwine  wrote:
> >
> > It seems like that tmp dir is missing a lot of data. Is there a clean up
> step I need to comment out?
>
> If you kill it right here:
>
>
> https://github.com/beagleboard/image-builder/blob/master/scripts/chroot.sh#L1363
>
> You can re-chroot in..
>
> 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/CAOCHtYiv_2LRS_xNUt88yfH2zWn05v2QcinGU%2BXwTfv%2ByELxMg%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/CAPEK9qZsJ%2BSNgKtLgbt3wTTJ1bWyCJx%2BtwtzD9H6dVNf7zZ2HA%40mail.gmail.com.

Re: [beagleboard] building something from source in image-builder script

[John Allwine]

It seems like that tmp dir is missing a lot of data. Is there a clean up
step I need to comment out?

On Tue, Apr 27, 2021 at 12:42 PM Robert Nelson 
wrote:

> On Tue, Apr 27, 2021 at 1:36 PM John Allwine  wrote:
> >
> > Is there a way to drop into a bash terminal within the qemu environment
> to debug? I ran the RootStock-NG.sh script and see the ignore/tmp.X
> directory. Does something like this work?
> >
> > After running RootStock-NG.sh;
> > sudo chroot /path/to/ignore/tmp.XXX /bin/bash
> >
> > (I get a /lib/ld-linux-armhf.so.3: No such file or directory when I do
> that)
>
> Before you chroot, make sure you mount sys, proc, dev/pts
>
>
> https://github.com/beagleboard/image-builder/blob/master/scripts/chroot.sh#L171-L187
>
> Then if host does not equal chroot architecture, copy qemu-arm-static
> under the chroot:
>
>
> https://github.com/beagleboard/image-builder/blob/master/scripts/chroot.sh#L246-L253
>
> At which case you can chroot in...
>
> 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/CAOCHtYiTe%2B8TFkNUTsmnctS_dDZLKd4_dYR3OH%3DTVSTzFZnYPA%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/CAPEK9qbhzBHrQ%3Dzkw5nraao%3DU1qv6FEJH%2BiQTF%2BVCWXaMZjr9g%40mail.gmail.com.

Re: [beagleboard] building something from source in image-builder script

[John Allwine]

Is there a way to drop into a bash terminal within the qemu environment to
debug? I ran the RootStock-NG.sh script and see the ignore/tmp.X
directory. Does something like this work?

After running RootStock-NG.sh;
sudo chroot /path/to/ignore/tmp.XXX /bin/bash

(I get a /lib/ld-linux-armhf.so.3: No such file or directory when I do that)

On Tue, Apr 27, 2021 at 12:05 PM Robert Nelson 
wrote:

> On Tue, Apr 27, 2021 at 12:47 PM John Allwine  wrote:
> >
> > The image-builder scripts (https://github.com/beagleboard/image-builder)
> are great for putting together a Beaglebone image. Is there a mechanism in
> there to build specific packages from source? I see some references to qemu
> in various places. Is it set up to cross compile?
> >
> > Any tips are appreciated!
>
> That what this final "target" bash script was for:
>
>
> https://github.com/beagleboard/image-builder/blob/master/target/chroot/beagleboard.org-buster.sh
>
> anything not packaged, etc..
>
> Just note, qemu can be a funky beast with a mind of it's own..
>
> 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/CAOCHtYhxydbZ2zpcOu%3D-LYiW-e5j15pdYk%3DaoTqHXE0ZD-9%2B6A%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/CAPEK9qZuKvfxqtNXf_UewdDSW3wdp_bWgbT7jDUJ5BrE5ROoBg%40mail.gmail.com.

[beagleboard] building something from source in image-builder script

[John Allwine]

The image-builder scripts (https://github.com/beagleboard/image-builder) 
are great for putting together a Beaglebone image. Is there a mechanism in 
there to build specific packages from source? I see some references to qemu 
in various places. Is it set up to cross compile? 

Any tips are 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/7a757a81-8ba0-47dc-9527-cb72151f952an%40googlegroups.com.

Re: [beagleboard] creating flasher image file from running Beaglebone

[John Allwine]

Thanks Robert! I issued a pull request with a couple minor changes to add a 
variable where you explained:
https://github.com/RobertCNelson/boot-scripts/pull/124

Here's the text of the pull request that describes how it could be used to 
make a smaller image size than the size of your microSD card:

Setting the conf_rootfs_partition_size variable allows for better control 
over the size of the microSD card necessary to house the resulting image 
when running the beaglebone-black-make-microSD-flasher-from-eMMC.sh script. 
For example, you might be working with a 32GB microSD card image, but want 
to generate an image that would also fit on a 4GB microSD card, so you 
could do the following:
sudo conf_rootfs_partition_size=7462912 
/opt/scripts/tools/eMMC/beaglebone-black-make-microSD-flasher-from-eMMC.sh

Which would specify the size as 7462912 sectors, which is the size of the 
eMMC rootfs partition (at least on the one I was testing on). After making 
the flasher you could then use dd to get the image off the microSD card for 
flashing onto other microSD cards:

sudo dd if= of= bs=512 
count=7471104

7471104 can be determined by the output from fdisk -l (one more than the 
End sector, or 8192 more than the size of the rootfs partition):
Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 * 8192 7471103 7462912 3.6G 83 Linux

You may be able to speed up the dd command by using a bigger blocksize and 
adjusting the count accordingly (using a 4MB block size):
sudo dd if= of= bs=419430 
count=912

On Thursday, April 22, 2021 at 7:58:42 AM UTC-6 RobertCNelson wrote:

> On Thu, Apr 22, 2021 at 8:26 AM John Allwine  wrote:
> >
> > How about changing the partition size in the make flasher script? Could 
> there be an option to make it the same size as the eMMC? Where is the 
> partition size determined?
>
>
> https://github.com/RobertCNelson/boot-scripts/blob/master/tools/eMMC/functions.sh#L1311-L1318
>
> LC_ALL=C sfdisk ${sfdisk_options} "${destination}" <<-__EOF__
> ${sfdisk_boot_startmb},,${sfdisk_fstype},*
>
> Change to:
> ${sfdisk_boot_startmb},${some new var for size},${sfdisk_fstype},*
>
> 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/50005372-feee-4683-b772-0cedc21c9be6n%40googlegroups.com.

Re: [beagleboard] creating flasher image file from running Beaglebone

[John Allwine]

How about changing the partition size in the make flasher script? Could there 
be an option to make it the same size as the eMMC? Where is the partition size 
determined?

> On Apr 21, 2021, at 3:05 PM, Robert Nelson  wrote:
> 
> On Wed, Apr 21, 2021 at 4:01 PM John Allwine  wrote:
>> 
>> What's the easiest way to create a Beaglebone flasher image file from a 
>> running system? I currently use the 
>> beaglebone-black-make-microSD-flasher-from-eMMC.sh script to directly write 
>> to a microSD card. I then use dd to copy the microSD card to a file. I 
>> currently only have a 32GB microSD card, though, so when I copy it the file 
>> is 32GB. With compression that mostly goes away, but and I'd also like it to 
>> work with smaller cards than that. Any ideas what the ideal solution is?
> 
> 
> You should be able to use gparted to shrink the partition size down,
> then just dd to the last sector used.. (untested in theory..)
> 
> 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/CAOCHtYge9qFsN1Tq_ZzrxRyhieT_Zz%3DjUbF9SzXO4sDPxeR8Xg%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/A2CE5D14-C905-4B0F-B308-C8B952348063%40pocketnc.com.

[beagleboard] creating flasher image file from running Beaglebone

[John Allwine]

What's the easiest way to create a Beaglebone flasher image file from a 
running system? I currently use 
the beaglebone-black-make-microSD-flasher-from-eMMC.sh script to directly 
write to a microSD card. I then use dd to copy the microSD card to a file. 
I currently only have a 32GB microSD card, though, so when I copy it the 
file is 32GB. With compression that mostly goes away, but and I'd also like 
it to work with smaller cards than that. Any ideas what the ideal solution 
is?

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/164823a8-5e4c-472f-8825-329c9f95c4b8n%40googlegroups.com.

Re: [beagleboard] versioning beaglebone images with OSTree

[John Allwine]

I noticed that adding ostree to deb_includes causes problems. What’s different 
about adding it to deb_additional_pkgs?

> On Apr 17, 2021, at 7:27 AM, John Allwine  wrote:
> 
> What is the biggest image currently?
> 
> OSTree is smart about space, so if updated incrementally and old images get 
> pruned, it could work. But I agree it’s a big limitation. Using a microSD 
> card in that case would be better.
> 
>>> On Apr 16, 2021, at 6:04 PM, Robert Nelson  wrote:
>>> 
>>> On Fri, Apr 16, 2021 at 4:19 PM John Allwine  wrote:
>>> 
>>> I'd like to start a discussion about creating complete Beaglebone images 
>>> that leverage OSTree to be able to atomically update the system as a whole. 
>>> The scripts in https://github.com/beagleboard/image-builder generate 
>>> complete images for the Beaglebone that include specific kernel, apt 
>>> packages, boot settings, git repositories, etc. Updating a deployed 
>>> Beaglebone without reflashing a new image involves piecemeal updating of 
>>> those various components. Improperly updating can leave the system in a 
>>> broken state and can be difficult to get back into a good state. It would 
>>> be great to be able to leverage those image-builder scripts to construct 
>>> the rootfs, add that tree as a commit to an OSTree repository and properly 
>>> configured Beaglebones could download that commit and atomically switch to 
>>> it to update the whole system while preserving portions of the system such 
>>> as home directories and other key directories (/etc, /var?). If something 
>>> did break, rolling back is easy as well.
>>> 
>>> Configuring a Beaglebone this way would make most of the system read-only 
>>> so using apt-get to install new packages wouldn't work without altering its 
>>> implementation, but that seems like a worthy trade off. This would be for 
>>> someone who has a Beaglebone with an out-of-the-box image and some 
>>> scripts/servers set up in their home directory who doesn't want to worry 
>>> too much about the system as a whole, but wants to be able to easily update 
>>> it without reflashing or doing piecemeal updates. People who develop 
>>> software for Beaglebones in their customers' devices could host their own 
>>> OSTree repository and make their own modifications to the image-builder 
>>> scripts if they have their own set of system dependencies (this is what I'd 
>>> like to do).
>>> 
>>> Does anyone else think this would be useful? Is there anyone with the 
>>> expertise to know what details would need to be taken into account to make 
>>> this work properly?
>>> 
>>> OSTree documentation is here: https://ostreedev.github.io/ostree/
>>> It lists a number of examples of it being used in various Linux 
>>> distributions.
>> 
>> I remember seeing one of Peter Robinson's demo of Fedora IoT a few
>> years back at ELC, that used OSTree+btrfs. It worked pretty well.  At
>> that time, I made sure btrfs worked well for us, to possibly look down
>> that road.  My biggest issue, the 4gb eMMC, was too limited for the
>> out of box images to do something like that.  For an iot/console image
>> the idea would still work well..   While working on bullseye images
>> this week, i noticed we still have the "--no-merged-usr" flag for
>> debootstrap, we should try with that removed in 'bullseye', as ostree
>> needs that..
>> 
>> We did have ostree installed on the lxqt images:
>> 
>> https://github.com/beagleboard/image-builder/blob/master/configs/bb.org-debian-buster-lxqt-v5.4.conf#L138
>> 
>> --no-merged-usr (due to bugs in stretch/buster..)
>> https://github.com/beagleboard/image-builder/blob/master/scripts/debootstrap.sh#L138
>> 
>> 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/CAOCHtYgHJiESN2df7jVbUErSwL5mcoPva-woQXR91t%3D0nCJJDQ%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/971CF81E-884F-43BD-8125-7A25803AA891%40pocketnc.com.

Re: [beagleboard] versioning beaglebone images with OSTree

[John Allwine]

What is the biggest image currently?

OSTree is smart about space, so if updated incrementally and old images get 
pruned, it could work. But I agree it’s a big limitation. Using a microSD card 
in that case would be better.

> On Apr 16, 2021, at 6:04 PM, Robert Nelson  wrote:
> 
> On Fri, Apr 16, 2021 at 4:19 PM John Allwine  wrote:
>> 
>> I'd like to start a discussion about creating complete Beaglebone images 
>> that leverage OSTree to be able to atomically update the system as a whole. 
>> The scripts in https://github.com/beagleboard/image-builder generate 
>> complete images for the Beaglebone that include specific kernel, apt 
>> packages, boot settings, git repositories, etc. Updating a deployed 
>> Beaglebone without reflashing a new image involves piecemeal updating of 
>> those various components. Improperly updating can leave the system in a 
>> broken state and can be difficult to get back into a good state. It would be 
>> great to be able to leverage those image-builder scripts to construct the 
>> rootfs, add that tree as a commit to an OSTree repository and properly 
>> configured Beaglebones could download that commit and atomically switch to 
>> it to update the whole system while preserving portions of the system such 
>> as home directories and other key directories (/etc, /var?). If something 
>> did break, rolling back is easy as well.
>> 
>> Configuring a Beaglebone this way would make most of the system read-only so 
>> using apt-get to install new packages wouldn't work without altering its 
>> implementation, but that seems like a worthy trade off. This would be for 
>> someone who has a Beaglebone with an out-of-the-box image and some 
>> scripts/servers set up in their home directory who doesn't want to worry too 
>> much about the system as a whole, but wants to be able to easily update it 
>> without reflashing or doing piecemeal updates. People who develop software 
>> for Beaglebones in their customers' devices could host their own OSTree 
>> repository and make their own modifications to the image-builder scripts if 
>> they have their own set of system dependencies (this is what I'd like to do).
>> 
>> Does anyone else think this would be useful? Is there anyone with the 
>> expertise to know what details would need to be taken into account to make 
>> this work properly?
>> 
>> OSTree documentation is here: https://ostreedev.github.io/ostree/
>> It lists a number of examples of it being used in various Linux 
>> distributions.
> 
> I remember seeing one of Peter Robinson's demo of Fedora IoT a few
> years back at ELC, that used OSTree+btrfs. It worked pretty well.  At
> that time, I made sure btrfs worked well for us, to possibly look down
> that road.  My biggest issue, the 4gb eMMC, was too limited for the
> out of box images to do something like that.  For an iot/console image
> the idea would still work well..   While working on bullseye images
> this week, i noticed we still have the "--no-merged-usr" flag for
> debootstrap, we should try with that removed in 'bullseye', as ostree
> needs that..
> 
> We did have ostree installed on the lxqt images:
> 
> https://github.com/beagleboard/image-builder/blob/master/configs/bb.org-debian-buster-lxqt-v5.4.conf#L138
> 
> --no-merged-usr (due to bugs in stretch/buster..)
> https://github.com/beagleboard/image-builder/blob/master/scripts/debootstrap.sh#L138
> 
> 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/CAOCHtYgHJiESN2df7jVbUErSwL5mcoPva-woQXR91t%3D0nCJJDQ%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/DE7D0E98-7405-4FC7-85B2-339E53CC4837%40pocketnc.com.

[beagleboard] versioning beaglebone images with OSTree

[John Allwine]

I'd like to start a discussion about creating complete Beaglebone images 
that leverage OSTree to be able to atomically update the system as a whole. 
The scripts in https://github.com/beagleboard/image-builder generate 
complete images for the Beaglebone that include specific kernel, apt 
packages, boot settings, git repositories, etc. Updating a deployed 
Beaglebone without reflashing a new image involves piecemeal updating of 
those various components. Improperly updating can leave the system in a 
broken state and can be difficult to get back into a good state. It would 
be great to be able to leverage those image-builder scripts to construct 
the rootfs, add that tree as a commit to an OSTree repository and properly 
configured Beaglebones could download that commit and atomically switch to 
it to update the whole system while preserving portions of the system such 
as home directories and other key directories (/etc, /var?). If something 
did break, rolling back is easy as well.
 
Configuring a Beaglebone this way would make most of the system read-only 
so using apt-get to install new packages wouldn't work without altering its 
implementation, but that seems like a worthy trade off. This would be for 
someone who has a Beaglebone with an out-of-the-box image and some 
scripts/servers set up in their home directory who doesn't want to worry 
too much about the system as a whole, but wants to be able to easily update 
it without reflashing or doing piecemeal updates. People who develop 
software for Beaglebones in their customers' devices could host their own 
OSTree repository and make their own modifications to the image-builder 
scripts if they have their own set of system dependencies (this is what I'd 
like to do).

Does anyone else think this would be useful? Is there anyone with the 
expertise to know what details would need to be taken into account to make 
this work properly?

OSTree documentation is here: https://ostreedev.github.io/ostree/
It lists a number of examples of it being used in various Linux 
distributions.

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

Re: [beagleboard] service that starts at boot can't use PRU - uio_pruss unavailable

[John Allwine]

I figured it out. The problem wasn't timing with the service, it was
problems with an old version of U-boot on a different board than I had been
testing with. I updated U-boot (like I had to do on my testing board) and
it all works now.

That said I still don't fully understand the problem. Where is U-boot
stored? I'm booting from a microSD card and using that card in one board
works, but didn't when I switched to this other board. Does it not pull
that data from the microSD card? Is it reading from the eMMC of the other
board?

On Fri, Apr 2, 2021 at 2:00 PM John Allwine  wrote:

> I have a systemd service that is supposed to run a program on the PRU
> using uio_pruss. The service has an After=generic-board-startup.service.
> It fails to run with the following error:
> ERROR: executing '/sbin/modprobe uio_pruss'  11 - Resource temporarily
> unavailable
>
> Is there something else I should set the service to start after? What is
> the recommended way to wait for uio_pruss to be available?
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/4e8c42d0-f959-48d3-9148-d6a03cc62bd2n%40googlegroups.com
> <https://groups.google.com/d/msgid/beagleboard/4e8c42d0-f959-48d3-9148-d6a03cc62bd2n%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/CAPEK9qaXm%3DenO6hKDeJEfBJSx6uZ3RCzAZ0UxRbVwperbavkew%40mail.gmail.com.

[beagleboard] service that starts at boot can't use PRU - uio_pruss unavailable

[John Allwine]

I have a systemd service that is supposed to run a program on the PRU using 
uio_pruss. The service has an After=generic-board-startup.service.  It 
fails to run with the following error:
ERROR: executing '/sbin/modprobe uio_pruss'  11 - Resource temporarily 
unavailable

Is there something else I should set the service to start after? What is 
the recommended way to wait for uio_pruss to be available?

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

Re: [beagleboard] difference between config-pin executables

[John Allwine]

What is the equivalent to the following:
in+
in-
out+
out-

On Thursday, March 18, 2021 at 1:14:36 PM UTC-6 RobertCNelson wrote:

> On Thu, Mar 18, 2021 at 1:45 PM John Allwine  wrote:
> >
> > On my Beaglebone Black, I have two config-pin executables. One is a 
> compiled executable from the bb-cape-overlays package, the other is a bash 
> script in /opt/source/bb.org-overlays:
> >
> > $ which config-pin
> > /usr/bin/config-pin
> >
> > $ dpkg -S /usr/bin/config-pin
> > bb-cape-overlays: /usr/bin/config-pin
> >
> > $ find / -name config-pin 2> /dev/null
> > /opt/source/bb.org-overlays/tools/beaglebone-universal-io/config-pin
> > /usr/bin/config-pin
> >
> > I have a script that configures specific pins using config-pin in the 
> format:
> > config-pin P8.8 in-
> > Which sets pin P8.8 to an input configured as a pull down.
> >
> > The bash script seems to be the one that accepts that format, the other 
> does not and errors with:
> > ERROR: open() for /sys/devices/platform/ocp/ocp:P8_8_pinmux/state 
> failed, No such file or directory
> >
> > The compiled version is the default on my Beaglebone and I'd like to 
> know more about it. For my script to work, I need to use the other one 
> right now. I can certainly update the script if the compiled config-pin is 
> a newer version and recommended practice is to use it, but I can't seem to 
> make it work right. Any information is appreciated!
>
> P8.8 -> P8.08, the original had a fixup for the missing zero.. I
> don't think 'in-' has been migrated yet..
>
> 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/835f5132-6b15-47da-8886-068278d98245n%40googlegroups.com.

[beagleboard] difference between config-pin executables

[John Allwine]

On my Beaglebone Black, I have two config-pin executables. One is a 
compiled executable from the bb-cape-overlays package, the other is a bash 
script in /opt/source/bb.org-overlays:

$ which config-pin
/usr/bin/config-pin

$ dpkg -S /usr/bin/config-pin
bb-cape-overlays: /usr/bin/config-pin

$ find / -name config-pin 2> /dev/null
/opt/source/bb.org-overlays/tools/beaglebone-universal-io/config-pin
/usr/bin/config-pin

I have a script that configures specific pins using config-pin in the 
format:
config-pin P8.8 in-
Which sets pin P8.8 to an input configured as a pull down.

The bash script seems to be the one that accepts that format, the other 
does not and errors with:
ERROR: open() for /sys/devices/platform/ocp/ocp:P8_8_pinmux/state failed, 
No such file or directory

The compiled version is the default on my Beaglebone and I'd like to know 
more about it. For my script to work, I need to use the other one right 
now. I can certainly update the script if the compiled config-pin is a 
newer version and recommended practice is to use it, but I can't seem to 
make it work right. Any information 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/535156de-dbaa-4088-b00b-b4dc141b0daan%40googlegroups.com.

Re: [beagleboard] setting up uio_pruss on BBB image using image-builder scripts

[John Allwine]

That did it! Thanks Robert!

On Wednesday, March 17, 2021 at 12:02:07 PM UTC-6 RobertCNelson wrote:

> On Wed, Mar 17, 2021 at 12:40 PM John Allwine  wrote:
> >
> > The kernel doesn't seem to be the problem. Even when I change to that 
> version my /dev/uio* devices aren't showing up. Am I missing a simple step 
> somewhere?
> >
> > $ sudo /opt/scripts/tools/version.sh
>
> > bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot SPL 
> 2019.04-2-gc9b3922522 (Aug 24 2020 - 16:42:18 -0500)]:[location: dd MBR]
> > bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
> 2019.04-2-gc9b3922522]:[location: dd MBR]
> > bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot SPL 
> 2019.04-2-gbb4af0f50f (Jul 08 2019 - 11:44:39 -0500)]:[location: dd MBR]
> > bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
> 2019.04-2-gbb4af0f50f]:[location: dd MBR]
> > UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]
> > UBOOT: Loaded Overlay:[BB-ADC-00A0]
> > UBOOT: Loaded Overlay:[BB-BONE-eMMC1-01-00A0]
> > UBOOT: Loaded Overlay:[BB-HDMI-TDA998x-00A0]
> > uboot_overlay_options:[uboot_overlay_pru=AM335X-PRU-UIO-00A0.dtbo]
>
> Eh, I see the problem..
>
> "uboot_overlay_pru=AM335X-PRU-UIO-00A0.dtbo" was a recent change..
> While you have U-boot: 2019.04, it's either: Jul 08 2019 or Aug 24
> 2020, so let's fix that..
>
> sudo apt update
> sudo apt install bb-u-boot-am335x-evm
>
> Then:
>
> cd /opt/u-boot/bb-u-boot-am335x-evm/
> sudo ./install.sh
>
> sudo reboot
>
> Then you should see the uio node here:
>
> UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]
> UBOOT: Loaded Overlay:[AM335X-PRU-UIO-00A0]
> UBOOT: Loaded Overlay:[BB-ADC-00A0]
> UBOOT: Loaded Overlay:[BB-BONE-eMMC1-01-00A0]
>
> 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/01f35c97-432e-4cfe-b746-d0d478da0d1an%40googlegroups.com.

Re: [beagleboard] setting up uio_pruss on BBB image using image-builder scripts

[John Allwine]

I switched to that kernel after the fact using:
sudo /opt/scripts/tools/update_kernel.sh --bone-rt-kernel --lts-4_19

Would it matter if I built the image originally with that kernel?

On Wednesday, March 17, 2021 at 11:40:24 AM UTC-6 John Allwine wrote:

> The kernel doesn't seem to be the problem. Even when I change to that 
> version my /dev/uio* devices aren't showing up. Am I missing a simple step 
> somewhere?
>
> $ sudo /opt/scripts/tools/version.sh 
> git:/opt/scripts/:[481db95174653ba485cca3797d4bbbe03c0cded0]
> eeprom:[A335BNLT000C1626BBBG0552]
> model:[TI_AM335x_BeagleBone_Black]
> dogtag:[Pocket NC Debian Buster Image 2021-02-01]
> bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot SPL 
> 2019.04-2-gc9b3922522 (Aug 24 2020 - 16:42:18 -0500)]:[location: dd MBR]
> bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
> 2019.04-2-gc9b3922522]:[location: dd MBR]
> bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot SPL 
> 2019.04-2-gbb4af0f50f (Jul 08 2019 - 11:44:39 -0500)]:[location: dd MBR]
> bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
> 2019.04-2-gbb4af0f50f]:[location: dd MBR]
> UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]
> UBOOT: Loaded Overlay:[BB-ADC-00A0]
> UBOOT: Loaded Overlay:[BB-BONE-eMMC1-01-00A0]
> UBOOT: Loaded Overlay:[BB-HDMI-TDA998x-00A0]
> kernel:[4.19.180-bone-rt-r61]
> /boot/uEnv.txt Settings:
> uboot_overlay_options:[enable_uboot_overlays=1]
> uboot_overlay_options:[uboot_overlay_pru=AM335X-PRU-UIO-00A0.dtbo]
> uboot_overlay_options:[enable_uboot_cape_universal=1]
> pkg check: to individually upgrade run: [sudo apt install --only-upgrade 
> ]
> pkg:[bb-cape-overlays]:[4.14.20210225.0-0~buster+20210225]
> pkg:[bb-customizations]:[1.20201105.0-0~buster+20201110]
> pkg:[bb-usb-gadgets]:[1.20200504.0-0~buster+20200504]
> pkg:[bb-wl18xx-firmware]:[1.20200813.1-0~buster+20200813]
> pkg:[kmod]:[26-1]
> WARNING:pkg:[librobotcontrol]:[NOT_INSTALLED]
> cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
> root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
> net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet]
> dmesg | grep remote
> [1.160381] remoteproc remoteproc0: wkup_m3 is available
> [1.423096] remoteproc remoteproc0: powering up wkup_m3
> [1.423115] remoteproc remoteproc0: Booting fw image 
> am335x-pm-firmware.elf, size 217168
> [1.425226] remoteproc remoteproc0: remote processor wkup_m3 is now up
> dmesg | grep pru
> dmesg | grep pinctrl-single
> [0.785028] pinctrl-single 44e10800.pinmux: 142 pins, size 568
> dmesg | grep gpio-of-helper
> [0.796784] gpio-of-helper ocp:cape-universal: ready
> END
>
> $ lsmod
> Module  Size  Used by
> uio_pruss  16384  0
> evdev  20480  1
> 8021q  24576  0
> garp   16384  1 8021q
> stp16384  1 garp
> mrp16384  1 8021q
> llc16384  2 garp,stp
> usb_f_acm  16384  2
> u_serial   20480  3 usb_f_acm
> usb_f_ncm  20480  2
> usb_f_rndis20480  4
> u_ether20480  2 usb_f_ncm,usb_f_rndis
> libcomposite   40960  16 usb_f_acm,usb_f_ncm,usb_f_rndis
> uio_pdrv_genirq16384  0
> uio16384  2 uio_pruss,uio_pdrv_genirq
> iptable_nat16384  0
> nf_nat_ipv416384  1 iptable_nat
> nf_nat 40960  1 nf_nat_ipv4
> nf_conntrack  118784  2 nf_nat_ipv4,nf_nat
> nf_defrag_ipv6 16384  1 nf_conntrack
> nf_defrag_ipv4 16384  1 nf_conntrack
> iptable_mangle 16384  0
> iptable_filter 16384  0
> ip_tables  20480  3 iptable_mangle,iptable_filter,iptable_nat
> x_tables   20480  3 iptable_mangle,ip_tables,iptable_filter
> spidev 16384  0
>
> $ ls /dev/uio* -la
> ls: cannot access '/dev/uio*': No such file or directory
>
> On Wednesday, March 17, 2021 at 11:24:53 AM UTC-6 RobertCNelson wrote:
>
>> On Wed, Mar 17, 2021 at 12:17 PM John Allwine  
>> wrote: 
>> > 
>> > I tried a different kernel, one that I know works with uio_pruss 
>> because I'm using it on a different image (4.19.59-bone-rt-r36). In my 
>> custom image, though, the /dev/uio* devices aren't showing up. Here's 
>> version.sh output on it: 
>> > 
>> > git:/opt/scripts/:[481db95174653ba485cca3797d4bbbe03c0cded0] 
>> > eeprom:[A335BNLT000C1626BBBG0552] 
>> > model:[TI_AM335x_BeagleBone_Black] 
>> > dogtag:[Pocket NC Debian Buster Image 2021-02-01] 
>> > bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[

Re: [beagleboard] setting up uio_pruss on BBB image using image-builder scripts

[John Allwine]

The kernel doesn't seem to be the problem. Even when I change to that 
version my /dev/uio* devices aren't showing up. Am I missing a simple step 
somewhere?

$ sudo /opt/scripts/tools/version.sh 
git:/opt/scripts/:[481db95174653ba485cca3797d4bbbe03c0cded0]
eeprom:[A335BNLT000C1626BBBG0552]
model:[TI_AM335x_BeagleBone_Black]
dogtag:[Pocket NC Debian Buster Image 2021-02-01]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot SPL 
2019.04-2-gc9b3922522 (Aug 24 2020 - 16:42:18 -0500)]:[location: dd MBR]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
2019.04-2-gc9b3922522]:[location: dd MBR]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot SPL 
2019.04-2-gbb4af0f50f (Jul 08 2019 - 11:44:39 -0500)]:[location: dd MBR]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
2019.04-2-gbb4af0f50f]:[location: dd MBR]
UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]
UBOOT: Loaded Overlay:[BB-ADC-00A0]
UBOOT: Loaded Overlay:[BB-BONE-eMMC1-01-00A0]
UBOOT: Loaded Overlay:[BB-HDMI-TDA998x-00A0]
kernel:[4.19.180-bone-rt-r61]
/boot/uEnv.txt Settings:
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[uboot_overlay_pru=AM335X-PRU-UIO-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
pkg check: to individually upgrade run: [sudo apt install --only-upgrade 
]
pkg:[bb-cape-overlays]:[4.14.20210225.0-0~buster+20210225]
pkg:[bb-customizations]:[1.20201105.0-0~buster+20201110]
pkg:[bb-usb-gadgets]:[1.20200504.0-0~buster+20200504]
pkg:[bb-wl18xx-firmware]:[1.20200813.1-0~buster+20200813]
pkg:[kmod]:[26-1]
WARNING:pkg:[librobotcontrol]:[NOT_INSTALLED]
cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet]
dmesg | grep remote
[1.160381] remoteproc remoteproc0: wkup_m3 is available
[1.423096] remoteproc remoteproc0: powering up wkup_m3
[1.423115] remoteproc remoteproc0: Booting fw image 
am335x-pm-firmware.elf, size 217168
[1.425226] remoteproc remoteproc0: remote processor wkup_m3 is now up
dmesg | grep pru
dmesg | grep pinctrl-single
[0.785028] pinctrl-single 44e10800.pinmux: 142 pins, size 568
dmesg | grep gpio-of-helper
[0.796784] gpio-of-helper ocp:cape-universal: ready
END

$ lsmod
Module  Size  Used by
uio_pruss  16384  0
evdev  20480  1
8021q  24576  0
garp   16384  1 8021q
stp16384  1 garp
mrp16384  1 8021q
llc16384  2 garp,stp
usb_f_acm  16384  2
u_serial   20480  3 usb_f_acm
usb_f_ncm  20480  2
usb_f_rndis20480  4
u_ether20480  2 usb_f_ncm,usb_f_rndis
libcomposite   40960  16 usb_f_acm,usb_f_ncm,usb_f_rndis
uio_pdrv_genirq16384  0
uio16384  2 uio_pruss,uio_pdrv_genirq
iptable_nat16384  0
nf_nat_ipv416384  1 iptable_nat
nf_nat 40960  1 nf_nat_ipv4
nf_conntrack  118784  2 nf_nat_ipv4,nf_nat
nf_defrag_ipv6 16384  1 nf_conntrack
nf_defrag_ipv4 16384  1 nf_conntrack
iptable_mangle 16384  0
iptable_filter 16384  0
ip_tables  20480  3 iptable_mangle,iptable_filter,iptable_nat
x_tables   20480  3 iptable_mangle,ip_tables,iptable_filter
spidev 16384  0

$ ls /dev/uio* -la
ls: cannot access '/dev/uio*': No such file or directory

On Wednesday, March 17, 2021 at 11:24:53 AM UTC-6 RobertCNelson wrote:

> On Wed, Mar 17, 2021 at 12:17 PM John Allwine  wrote:
> >
> > I tried a different kernel, one that I know works with uio_pruss because 
> I'm using it on a different image (4.19.59-bone-rt-r36). In my custom 
> image, though, the /dev/uio* devices aren't showing up. Here's version.sh 
> output on it:
> >
> > git:/opt/scripts/:[481db95174653ba485cca3797d4bbbe03c0cded0]
> > eeprom:[A335BNLT000C1626BBBG0552]
> > model:[TI_AM335x_BeagleBone_Black]
> > dogtag:[Pocket NC Debian Buster Image 2021-02-01]
> > bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot SPL 
> 2019.04-2-gc9b3922522 (Aug 24 2020 - 16:42:18 -0500)]:[location: dd MBR]
> > bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
> 2019.04-2-gc9b3922522]:[location: dd MBR]
> > bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot SPL 
> 2019.04-2-gbb4af0f50f (Jul 08 2019 - 11:44:39 -0500)]:[location: dd MBR]
> > bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
> 2019.04-2-gbb4af0f50f]:[location: dd MBR]
> > UBOOT: Loaded Overlay:[BB-ADC-00A0]
> > UBOOT: Loaded Overlay:[BB-BONE-eMMC1-01-00A0]
> > UBOOT: Loaded Overlay:[BB-HDMI-TDA998x-00A0]
> > kernel:[4.19.59-bone-rt-r36]
>
> probably fixed, between r36 and r61...
>
>
> http://gfn

Re: [beagleboard] setting up uio_pruss on BBB image using image-builder scripts

[John Allwine]

I tried a different kernel, one that I know works with uio_pruss because
I'm using it on a different image (4.19.59-bone-rt-r36). In my custom
image, though, the /dev/uio* devices aren't showing up. Here's version.sh
output on it:

git:/opt/scripts/:[481db95174653ba485cca3797d4bbbe03c0cded0]
eeprom:[A335BNLT000C1626BBBG0552]
model:[TI_AM335x_BeagleBone_Black]
dogtag:[Pocket NC Debian Buster Image 2021-02-01]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot SPL
2019.04-2-gc9b3922522 (Aug 24 2020 - 16:42:18 -0500)]:[location: dd MBR]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot
2019.04-2-gc9b3922522]:[location: dd MBR]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot SPL
2019.04-2-gbb4af0f50f (Jul 08 2019 - 11:44:39 -0500)]:[location: dd MBR]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot
2019.04-2-gbb4af0f50f]:[location: dd MBR]
UBOOT: Loaded Overlay:[BB-ADC-00A0]
UBOOT: Loaded Overlay:[BB-BONE-eMMC1-01-00A0]
UBOOT: Loaded Overlay:[BB-HDMI-TDA998x-00A0]
kernel:[4.19.59-bone-rt-r36]
/boot/uEnv.txt Settings:
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[uboot_overlay_pru=AM335X-PRU-UIO-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
pkg check: to individually upgrade run: [sudo apt install --only-upgrade
]
pkg:[bb-cape-overlays]:[4.14.20210225.0-0~buster+20210225]
pkg:[bb-customizations]:[1.20201105.0-0~buster+20201110]
pkg:[bb-usb-gadgets]:[1.20200504.0-0~buster+20200504]
pkg:[bb-wl18xx-firmware]:[1.20200813.1-0~buster+20200813]
pkg:[kmod]:[26-1]
WARNING:pkg:[librobotcontrol]:[NOT_INSTALLED]
cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1
root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M
net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet]
dmesg | grep remote
[1.242393] remoteproc remoteproc0: wkup_m3 is available
[1.515377] remoteproc remoteproc0: powering up wkup_m3
[1.515394] remoteproc remoteproc0: Booting fw image
am335x-pm-firmware.elf, size 217168
[1.517496] remoteproc remoteproc0: remote processor wkup_m3 is now up
dmesg | grep pru
dmesg | grep pinctrl-single
[0.868764] pinctrl-single 44e10800.pinmux: 142 pins, size 568
dmesg | grep gpio-of-helper
[0.879941] gpio-of-helper ocp:cape-universal: ready
END

On Wed, Mar 17, 2021 at 11:05 AM Robert Nelson 
wrote:

> On Wed, Mar 17, 2021 at 11:24 AM John Allwine  wrote:
> >
> > How about the rt kernel? I'm using 4.19.94-ti-rt-r57 and don't seem to
> have the /dev/uio* devices. Is there something else I need to activate
> those devices or does the rt kernel not support uio_pruss?
>
> sudo /opt/scripts/tools/version.sh
>
> Regards,
>
> --
> Robert Nelson
> https://rcn-ee.com/
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/CAOCHtYhP359QSK0P8ZJmupNqJ0Ap870jOgbQdYVPQHcncEqxxA%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/CAPEK9qYpZOuZmRCyxVa1QiRtk_j0GpvVroYGC4Fq9hKyUEjbYQ%40mail.gmail.com.

Re: [beagleboard] setting up uio_pruss on BBB image using image-builder scripts

[John Allwine]

How about the rt kernel? I'm using 4.19.94-ti-rt-r57 and don't seem to have
the /dev/uio* devices. Is there something else I need to activate those
devices or does the rt kernel not support uio_pruss?

On Wed, Mar 17, 2021 at 9:49 AM Robert Nelson 
wrote:

> On Wed, Mar 17, 2021 at 10:46 AM John Allwine  wrote:
> >
> > Great, and so if I had used one of those --enable-uboot-pru* options and
> I wanted to manually change an image to using uio_pruss, is it just a
> matter of changing /boot/uEnv.txt to use that overlay?
>
> Correct, 4.14.x-ti & 4.19.x-ti kernels support changing the pru driver
> from /boot/uEnv.txt.. Just un-comment the version you want..
>
> 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/CAOCHtYgrETMrZjb_QUBS5WSRRCz38KOkD64TR3sTcU%2BDCVnb7A%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/CAPEK9qb1zqFCJT_UHUo94zO7ukXFLGxKTayGdd8EhTn4X%3Db5kA%40mail.gmail.com.

Re: [beagleboard] setting up uio_pruss on BBB image using image-builder scripts

[John Allwine]

Great, and so if I had used one of those --enable-uboot-pru* options and I 
wanted to manually change an image to using uio_pruss, is it just a matter 
of changing /boot/uEnv.txt to use that overlay?

On Wednesday, March 17, 2021 at 9:39:21 AM UTC-6 RobertCNelson wrote:

> On Wed, Mar 17, 2021 at 10:33 AM John Allwine  wrote:
> >
> > What is necessary to set up a Beaglebone Black image with uio_pruss 
> enabled rather than remoteproc?
> >
> > If I wanted to build an image using this config file, for example: 
> https://github.com/beagleboard/image-builder/blob/master/configs/bb.org-debian-buster-console-v4.19.conf
> >
> > What steps would I have to take?
>
> When you run "setup_sdcard.sh" to generate your target *.img or
> microsd, just don't pass any "--enable-uboot-pru*" options..
>
>
> https://github.com/beagleboard/image-builder/blob/master/tools/setup_sdcard.sh#L2070-L2084
>
> as the default is:
>
> uboot_overlay_pru=AM335X-PRU-UIO-00A0.dtbo
>
>
> https://github.com/beagleboard/image-builder/blob/master/tools/setup_sdcard.sh#L1303-L1348
>
> 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/c7f63533-e612-410a-8414-056b167dee6fn%40googlegroups.com.

[beagleboard] setting up uio_pruss on BBB image using image-builder scripts

[John Allwine]

What is necessary to set up a Beaglebone Black image with uio_pruss enabled 
rather than remoteproc?

If I wanted to build an image using this config file, for 
example: 
https://github.com/beagleboard/image-builder/blob/master/configs/bb.org-debian-buster-console-v4.19.conf

What steps would I have to take?

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

Re: [beagleboard] static mac address on Beaglebone Black

[John Allwine]

Do you know the specific packages that should be upgraded to get the
bb_generate_mac.sh script?

On Tue, Jan 19, 2021 at 11:39 AM John Allwine  wrote:

> I'd match the file names that are used, which are host_addr and dev_addr.
> So USB1_MAC_HOST and USB1_MAC_DEV?
>
> On Tue, Jan 19, 2021 at 11:36 AM Robert Nelson 
> wrote:
>
>> On Tue, Jan 19, 2021 at 12:33 PM John Allwine  wrote:
>> >
>> > Is there a file that isn't version controlled that the overrides could
>> go in? That way updates to a file wouldn't cause conflicts down the road.
>> >
>> > As for a name, USB1_MAC seems reasonable to me.
>>
>> Just the host side right? ;) USB1_MAC_HOST, should we add
>> USB1_MAC_LOCAL? _CLIENT?
>>
>> 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/CAPEK9qbKKAJ6Bbisu59CdeWkidEc%3DB5Fs1bK_QxSX5V9PwZhgw%40mail.gmail.com.

Re: [beagleboard] static mac address on Beaglebone Black

[John Allwine]

I'd match the file names that are used, which are host_addr and dev_addr.
So USB1_MAC_HOST and USB1_MAC_DEV?

On Tue, Jan 19, 2021 at 11:36 AM Robert Nelson 
wrote:

> On Tue, Jan 19, 2021 at 12:33 PM John Allwine  wrote:
> >
> > Is there a file that isn't version controlled that the overrides could
> go in? That way updates to a file wouldn't cause conflicts down the road.
> >
> > As for a name, USB1_MAC seems reasonable to me.
>
> Just the host side right? ;) USB1_MAC_HOST, should we add
> USB1_MAC_LOCAL? _CLIENT?
>
> 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/CAPEK9qbE_mW59%2B-u79eQFFt48TJTP3TMJWRQHhfoCnbSFvfuyQ%40mail.gmail.com.

Re: [beagleboard] static mac address on Beaglebone Black

[John Allwine]

Is there a file that isn't version controlled that the overrides could go
in? That way updates to a file wouldn't cause conflicts down the road.

As for a name, USB1_MAC seems reasonable to me.


On Tue, Jan 19, 2021 at 10:52 AM Robert Nelson 
wrote:

> On Tue, Jan 19, 2021 at 11:49 AM John Allwine  wrote:
> >
> > What's the best way to set a static mac address for usb1 device on the
> Beaglebone Black?
> >
> > This line seems to be where it is set, but I don't see where cpsw_4_mac
> is set:
> >
> https://github.com/RobertCNelson/boot-scripts/blob/fe926a6a4cf5805041878d7df82b58c00b4f902e/boot/am335x_evm.sh#L500
> >
> > I don't seem to have a /usr/bin/bb_generate_mac.sh, so these lines don't
> seem like they would be called:
> https://github.com/RobertCNelson/boot-scripts/blob/fe926a6a4cf5805041878d7df82b58c00b4f902e/boot/am335x_evm.sh#L281-L286
> >
> > Anyone have any ideas?
>
> sudo apt update ; sudo apt upgrade
>
> would fix that..
>
> We should add the overrides here:
>
>
> https://github.com/RobertCNelson/boot-scripts/blob/master/boot/default/bb-boot#L21-L30
>
> Any thoughts on variable names?
>
> 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/CAPEK9qbFMHWRA2x2RBXE9D5RM6Ay5m35evkAuxkm5G3dsaWcRw%40mail.gmail.com.

[beagleboard] static mac address on Beaglebone Black

[John Allwine]

What's the best way to set a static mac address for usb1 device on the 
Beaglebone Black?

This line seems to be where it is set, but I don't see where cpsw_4_mac is 
set:
https://github.com/RobertCNelson/boot-scripts/blob/fe926a6a4cf5805041878d7df82b58c00b4f902e/boot/am335x_evm.sh#L500

I don't seem to have a /usr/bin/bb_generate_mac.sh, so these lines don't 
seem like they would be 
called: 
https://github.com/RobertCNelson/boot-scripts/blob/fe926a6a4cf5805041878d7df82b58c00b4f902e/boot/am335x_evm.sh#L281-L286

Anyone have any ideas?

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

Re: [beagleboard] multiple bootable partitions on a microSD card

[John Allwine]

I'm trying to use btrfs as the rootfs, but it doesn't seem to work.

I created two different eMMC flasher images, one that used the --rootfs
btrfs arguments and one that didn't. The one that defaults to ext4 booted
up and flashed the eMMC no problem. The btrfs one errors on boot with this:

mmc0 is current device

Partition Map for MMC device 0  --   Partition Type: DOS

PartStart SectorNum Sectors UUIDType
  1 81927364608 34e7716f-01 83 Boot
Scanning mmc device 0
Checking for: /uEnv.txt ...
** Unrecognized filesystem type **
Checking for: /boot/uEnv.txt ...
** Unrecognized filesystem type **
** Invalid partition 2 **
** Invalid partition 3 **
** Invalid partition 4 **
** Invalid partition 5 **
** Invalid partition 6 **
** Invalid partition 7 **
switch to partitions #0, OK
mmc1(part 0) is current device

After that it booted using the eMMC rather than the microSD card. Any ideas?

On Mon, Sep 21, 2020 at 1:56 PM Robert Nelson 
wrote:

> On Mon, Sep 21, 2020 at 2:50 PM John Allwine  wrote:
> >
> > Do I run this on a Beaglebone itself, or should it be done on something
> beefier? Maybe a docker container on my mac? Or would I need an ARM device?
>
> An x15, or something similar.. Or any Debian based os, it'll use qemu on
> x86..
>
> 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/CAOCHtYh%2BFaaNWbDBfYft1bLVfRZ6%3DjqK87rLa%3D4qW-5eWc30xw%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/CAPEK9qYWDn%2BZgeDYkAuif6Ty%3DcsbiC8TVfcn%3DSi9DPk_HWJHAQ%40mail.gmail.com.

Re: [beagleboard] multiple bootable partitions on a microSD card

[John Allwine]

Do I run this on a Beaglebone itself, or should it be done on something
beefier? Maybe a docker container on my mac? Or would I need an ARM device?

On Mon, Sep 21, 2020 at 11:25 AM Robert Nelson 
wrote:

> On Mon, Sep 21, 2020 at 12:00 PM John Allwine  wrote:
> >
> > Ah, I see. And how does that debian-10.5-iot-armhf-2020-09-21.tar.xz
> file get generated?
>
> git clone https://github.com/beagleboard/image-builder
> cd ./image-builder/
>
> ./RootStock-NG.sh -c bb.org-debian-buster-iot-v4.19
>
> 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/CAOCHtYhj5y79jZ0A-bjzEcJW-mScT7631PQdwV%3DR42nMDziFZw%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/CAPEK9qbRnS5H0C5k551V6e%2BApZBTMfr_cf19FSZ8KiVY7ALrxg%40mail.gmail.com.

Re: [beagleboard] multiple bootable partitions on a microSD card

[John Allwine]

Also, what about the process changes for the am57xx images?

On Mon, Sep 21, 2020 at 10:59 AM John Allwine  wrote:

> Ah, I see. And how does that debian-10.5-iot-armhf-2020-09-21.tar.xz file
> get generated?
>
> On Mon, Sep 21, 2020 at 10:04 AM Robert Nelson 
> wrote:
>
>> On Mon, Sep 21, 2020 at 10:58 AM John Allwine  wrote:
>> >
>> > Thanks Robert! It sounds like it's straight forward, but I'm not
>> familiar with the image creation process at all. When and where would I
>> call setup_sdcard.sh?
>>
>> For example, let's take this image:
>>
>> https://rcn-ee.net/rootfs/bb.org/testing/2020-09-21/buster-iot/
>>
>> if we ignore the am57xx files, there are only 2 for BBB's..
>>
>> bone-debian-*.img.xz and bone-eMMC-*.img.xz
>>
>> Those were both generated from inside this archive (once extracted),
>> setup_sdcard.sh is inside the archive:
>>
>> debian-10.5-iot-armhf-2020-09-21.tar.xz
>>
>> via:
>>
>> sudo ./setup_sdcard.sh --img-4gb bone-debian-10.5-iot-armhf-2020-09-21
>> --dtb beaglebone --rootfs_label rootfs --hostname beaglebone
>> --enable-cape-universal --enable-uboot-pru-rproc-419ti
>>
>> sudo ./setup_sdcard.sh --img-4gb
>> bone-eMMC-flasher-debian-10.5-iot-armhf-2020-09-21  --dtb beaglebone
>> --rootfs_label rootfs --hostname beaglebone --enable-cape-universal
>> --enable-uboot-pru-rproc-419ti --emmc-flasher
>>
>> Just add  "--rootfs btrfs"
>>
>> Regards,
>>
>> --
>> Robert Nelson
>> https://rcn-ee.com/
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to beagleboard+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/beagleboard/CAOCHtYi6S0rEyM%3DDsT-dvq7OF7CO8VeWy3PQOnTmp7JLCBzz-Q%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/CAPEK9qbj90cjS_zN%2BvVh9gUUbeS9BJJbjD6X3-OJ-AHLn1t8fw%40mail.gmail.com.

Re: [beagleboard] multiple bootable partitions on a microSD card

[John Allwine]

Ah, I see. And how does that debian-10.5-iot-armhf-2020-09-21.tar.xz file
get generated?

On Mon, Sep 21, 2020 at 10:04 AM Robert Nelson 
wrote:

> On Mon, Sep 21, 2020 at 10:58 AM John Allwine  wrote:
> >
> > Thanks Robert! It sounds like it's straight forward, but I'm not
> familiar with the image creation process at all. When and where would I
> call setup_sdcard.sh?
>
> For example, let's take this image:
>
> https://rcn-ee.net/rootfs/bb.org/testing/2020-09-21/buster-iot/
>
> if we ignore the am57xx files, there are only 2 for BBB's..
>
> bone-debian-*.img.xz and bone-eMMC-*.img.xz
>
> Those were both generated from inside this archive (once extracted),
> setup_sdcard.sh is inside the archive:
>
> debian-10.5-iot-armhf-2020-09-21.tar.xz
>
> via:
>
> sudo ./setup_sdcard.sh --img-4gb bone-debian-10.5-iot-armhf-2020-09-21
> --dtb beaglebone --rootfs_label rootfs --hostname beaglebone
> --enable-cape-universal --enable-uboot-pru-rproc-419ti
>
> sudo ./setup_sdcard.sh --img-4gb
> bone-eMMC-flasher-debian-10.5-iot-armhf-2020-09-21  --dtb beaglebone
> --rootfs_label rootfs --hostname beaglebone --enable-cape-universal
> --enable-uboot-pru-rproc-419ti --emmc-flasher
>
> Just add  "--rootfs btrfs"
>
> Regards,
>
> --
> Robert Nelson
> https://rcn-ee.com/
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/CAOCHtYi6S0rEyM%3DDsT-dvq7OF7CO8VeWy3PQOnTmp7JLCBzz-Q%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/CAPEK9qYdgLWWVegZwe1bS9oo74nCZ3JskzvH0k-Jt7kO1HYDew%40mail.gmail.com.

Re: [beagleboard] multiple bootable partitions on a microSD card

[John Allwine]

Thanks Robert! It sounds like it's straight forward, but I'm not familiar
with the image creation process at all. When and where would I call
setup_sdcard.sh?

On Mon, Sep 21, 2020 at 9:44 AM Robert Nelson 
wrote:

> On Mon, Sep 21, 2020 at 10:15 AM John Allwine  wrote:
> >
> > I like the idea of using btrfs. How difficult would it be to modify the
> script that generates the MachineKit images to use a btrfs filesystem
> rather than ext4? For starters I guess, how do you generate the MachineKit
> images and how might I do that myself?
>
> It's actually been fully supported for about a year or two.
>
> When you call "setup_sdcard.sh" just issue:
>
>  --rootfs btrfs
>
> (default is ext4)
>
> 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/CAOCHtYjz-pJwskvZ%3DWQwoVjVXRhdjwtL8WB7jpy6m7tY2AYZNg%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/CAPEK9qb%3DwQ%2BSZiTnOt2grukkn8Gvx7Hxz0byOHgQ_o1UPgDnRQ%40mail.gmail.com.

Re: [beagleboard] multiple bootable partitions on a microSD card

[John Allwine]

I like the idea of using btrfs. How difficult would it be to modify the 
script that generates the MachineKit images to use a btrfs filesystem 
rather than ext4? For starters I guess, how do you generate the MachineKit 
images and how might I do that myself?

On Friday, September 18, 2020 at 11:26:05 AM UTC-6 RobertCNelson wrote:

> Wait, that's btrfs snapshots, which also works today..
>
> On Fri, Sep 18, 2020, 12:01 PM John Allwine  wrote:
>
>> The ultimate goal here would be to be able to essentially flash a board, 
>> but always be able to revert to a previously installed firmware. So rather 
>> than always flash the eMMC, leverage a much larger microSD card that could 
>> have several different images and instead of ever overwriting them, 
>> allocate spare space to a new partition and change whatever setting is 
>> necessary to default to booting to that partition (and provide some 
>> interface for reverting to any previous one).
>>
>> On Fri, Sep 18, 2020 at 10:50 AM John Allwine  wrote:
>>
>>> Thanks Robert! I'll give it a try. It sounds like 4 different images 
>>> would be the limit using that strategy? Let's say I had a 256GB microSD 
>>> card with 10 different partitions. Any idea on what I would have to change 
>>> to be able to select one besides one of the first 4?
>>>
>>> On Friday, September 18, 2020 at 8:55:48 AM UTC-6 RobertCNelson wrote:
>>>
>>>> On Fri, Sep 18, 2020 at 9:47 AM John Allwine  
>>>> wrote: 
>>>> > 
>>>> > Has anyone partitioned a microSD card such that it can be booted into 
>>>> different partitions on a Beaglebone Black or AI? How would I go about 
>>>> doing something like that? I'd like to avoid needing to physically take 
>>>> out 
>>>> the microSD card and potentially add bootable partitions over time. Would 
>>>> that be doable from the Beaglebone itself? 
>>>>
>>>> We use "/boot/uEnv.txt" as a trigger file.. 
>>>>
>>>> Take an existing partition, shrink it to half, (dont' touch the 4mb 
>>>> hole), then clone that partition to the empy space (and update it's 
>>>> /etc/fstab).. 
>>>>
>>>> On startup, u-boot will search the first 4 partitions for 
>>>> "/boot/uEnv.txt" so either rename the one on the first partition to 
>>>> the boot the second/etc.. 
>>>>
>>>> There's probably a better way, but this will just work with the 
>>>> existing setup with the fewest mod's.. 
>>>>
>>>> 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...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/beagleboard/15487b80-ad54-40df-9079-e12f60368419n%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/beagleboard/15487b80-ad54-40df-9079-e12f60368419n%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...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/CAPEK9qafMH2HPHuxq%2BUETxaTR4bmD8TACDnn0zdrTTsGYekmNQ%40mail.gmail.com
>>  
>> <https://groups.google.com/d/msgid/beagleboard/CAPEK9qafMH2HPHuxq%2BUETxaTR4bmD8TACDnn0zdrTTsGYekmNQ%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/5bb42fda-9ee0-433e-b4a7-6eeaf9b98a20n%40googlegroups.com.

Re: [beagleboard] multiple bootable partitions on a microSD card

[John Allwine]

The ultimate goal here would be to be able to essentially flash a board,
but always be able to revert to a previously installed firmware. So rather
than always flash the eMMC, leverage a much larger microSD card that could
have several different images and instead of ever overwriting them,
allocate spare space to a new partition and change whatever setting is
necessary to default to booting to that partition (and provide some
interface for reverting to any previous one).

On Fri, Sep 18, 2020 at 10:50 AM John Allwine  wrote:

> Thanks Robert! I'll give it a try. It sounds like 4 different images would
> be the limit using that strategy? Let's say I had a 256GB microSD card with
> 10 different partitions. Any idea on what I would have to change to be able
> to select one besides one of the first 4?
>
> On Friday, September 18, 2020 at 8:55:48 AM UTC-6 RobertCNelson wrote:
>
>> On Fri, Sep 18, 2020 at 9:47 AM John Allwine  wrote:
>> >
>> > Has anyone partitioned a microSD card such that it can be booted into
>> different partitions on a Beaglebone Black or AI? How would I go about
>> doing something like that? I'd like to avoid needing to physically take out
>> the microSD card and potentially add bootable partitions over time. Would
>> that be doable from the Beaglebone itself?
>>
>> We use "/boot/uEnv.txt" as a trigger file..
>>
>> Take an existing partition, shrink it to half, (dont' touch the 4mb
>> hole), then clone that partition to the empy space (and update it's
>> /etc/fstab)..
>>
>> On startup, u-boot will search the first 4 partitions for
>> "/boot/uEnv.txt" so either rename the one on the first partition to
>> the boot the second/etc..
>>
>> There's probably a better way, but this will just work with the
>> existing setup with the fewest mod's..
>>
>> 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/15487b80-ad54-40df-9079-e12f60368419n%40googlegroups.com
> <https://groups.google.com/d/msgid/beagleboard/15487b80-ad54-40df-9079-e12f60368419n%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/CAPEK9qafMH2HPHuxq%2BUETxaTR4bmD8TACDnn0zdrTTsGYekmNQ%40mail.gmail.com.

Re: [beagleboard] multiple bootable partitions on a microSD card

[John Allwine]

Thanks Robert! I'll give it a try. It sounds like 4 different images would 
be the limit using that strategy? Let's say I had a 256GB microSD card with 
10 different partitions. Any idea on what I would have to change to be able 
to select one besides one of the first 4?

On Friday, September 18, 2020 at 8:55:48 AM UTC-6 RobertCNelson wrote:

> On Fri, Sep 18, 2020 at 9:47 AM John Allwine  wrote:
> >
> > Has anyone partitioned a microSD card such that it can be booted into 
> different partitions on a Beaglebone Black or AI? How would I go about 
> doing something like that? I'd like to avoid needing to physically take out 
> the microSD card and potentially add bootable partitions over time. Would 
> that be doable from the Beaglebone itself?
>
> We use "/boot/uEnv.txt" as a trigger file..
>
> Take an existing partition, shrink it to half, (dont' touch the 4mb
> hole), then clone that partition to the empy space (and update it's
> /etc/fstab)..
>
> On startup, u-boot will search the first 4 partitions for
> "/boot/uEnv.txt" so either rename the one on the first partition to
> the boot the second/etc..
>
> There's probably a better way, but this will just work with the
> existing setup with the fewest mod's..
>
> 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/15487b80-ad54-40df-9079-e12f60368419n%40googlegroups.com.

[beagleboard] multiple bootable partitions on a microSD card

[John Allwine]

Has anyone partitioned a microSD card such that it can be booted into 
different partitions on a Beaglebone Black or AI? How would I go about 
doing something like that? I'd like to avoid needing to physically take out 
the microSD card and potentially add bootable partitions over time. Would 
that be doable from the Beaglebone itself?

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

Re: [beagleboard] Re: libgpiod on Beaglebone AI

[John Allwine]

How is the toggling rate slower in C than in Python when using sysfs? That
seems strange to me.

On Mon, Aug 10, 2020 at 12:31 PM Mark A. Yoder 
wrote:

> Interesting...  Why go through all the trouble to set bits on a chip by
> chip basis, and then end up setting them in a loop?
>
> Here are the toggling standings.
> c via sysfs:   3kHz
> python via sysfs:  6KHz
> c via gpiod:  300KHz
>
> Now to get python via gpiod to work.
>
> --Mark
> On Monday, August 10, 2020 at 2:19:27 PM UTC-4 Dennis Bieber wrote:
>
>> On Mon, 10 Aug 2020 08:33:55 -0700 (PDT), in
>> gmane.comp.hardware.beagleboard.user "Mark A. Yoder"
>>  wrote:
>>
>> >Interesting I wrote a c version
>> ><
>> https://github.com/MarkAYoder/BeagleBoard-exercises/blob/master/gpiod/bulk.c>
>> and
>> >the pins are toggle *at the exact same time*. Now, how to get gpioset to
>> >work correctly.
>> >
>>
>> It doesn't seem to use the same/direct calls... I've tracked it down to
>> the function at line 661
>> https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/tree/lib/core.c
>> and macro definition at line 778
>>
>> https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/tree/include/gpiod.h
>> which seems to define a loop operation.
>>
>>
>> --
>> 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/29db35f1-9022-453e-8966-1a75da8512d4n%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/CAPEK9qbeaYEGp3S%2BM5L3iriqRw0NHxTodJmWRdOpt19gFyn%2B%2Bg%40mail.gmail.com.

Re: [beagleboard] Re: GPIO5.2 or BBAI (Rev A1) Cape Pin P9.18b, For Example Won't Read Pin Value Correctly

[John Allwine]

P8.17 is actually gpio8.18, so 242 is correct.

I just checked P8.3, P8.22 and P8.23 using the listed GPIO24, GPIO23 and
GPIO22 and they all worked with sysfs. I know I've been bitten by there
being so many steps that have to happen in order to change the behavior of
a pin (having to make changes to the device tree overlay, compile it, copy
it to the right place and then reboot for things to take effect, then also
export and set the proper direction on the pin). Leaving any step out can
lead to a lot of frustration especially when testing several different pins
and a minor step was left out for one or two of them. Can't speak to your
specific situation, but me leaving out one of those steps has always been
the culprit (except in the case of P9.13, which isn't actually wired up to
a GPIO pin yet).

On Sat, Jun 13, 2020 at 8:13 PM jimvr  wrote:

> John,
> Thanks for answering, thought I was the only one out there working today...
> According to the system manual for the AI (
> https://github.com/beagleboard/beaglebone-ai/wiki/System-Reference-Manual
> ),
> P8.17 is GPIO 242   *<=== shouldn't that be gpio241?*
>
> *Figured This Out*
> Here is why I was going crazy, my first GPIO assignment just happened to
> be one of these three wrongly mapped pins, all the rest of my pins that I
> am accessing through sysfs are working, plus I have direct access from the
> PRUs for the special pins, which is where I have been working for the past
> few weeks.  I was trying to finish this job and had to get some switches
> and indicator LEDs, resets, etc. to work from the main core, and hence
> where I was today.
>
> So, out of the 19 pins that I have assigned to sysfs, three of them are
> not mapped according to the documentation that I have been using, which is
> the Google Sheet at:  https://goo.gl/jiazTL
> #define PORTSIZE 32
> // Test point 10
> #define TP10_OUT (PORTSIZE * 1) + 24// gpio56 gpio1.24 cape P8.3 - why
> does this work? - VALIDATED
> //#define TP10_OUT (PORTSIZE * 0) + 24// gpio24 gpio1.24 cape P8.3 -
> and this does not?
> // Test Point 9
> #define TP9_OUT (PORTSIZE * 1) + 23 // gpio45 gpio1.23 cape
> P8.22 - why does this work? - VALIDATED
> //#define TP9_OUT (PORTSIZE * 0) + 23  // gpio23 gpio1.23 cape
> P8.22 - and this does not?
> // LED1
> #define LED1_OUT (PORTSIZE * 1) + 22// gpio54 gpio1.22 cape
> P8.23  -- why does this work?? - VALIDATED
> //#define LED1_OUT (PORTSIZE * 0) + 22// gpio22 gpio1.22 cape
> P8.23  -- and this does not work?
>
> These are all on GPIO1 (gpio0...) bank,  which just like when I had the
> issue with trying to access pins above 256, I got sysfs file errors.  I did
> not get file errors on the bad lines, those were mapped to the sysfs gpio
> structure, but they did not toggle the expected pins, so they are allowable
> gpioxxx assignments, just don't know what pin they were assigned to on the
> BGA.
>
> Right now, I am good to go, that was it for me, but I am still curious
> where the mapping issue is for GPIO1...   The -1 for me fixed the major
> issues, and these three, after testing each of the 19 pins by hand with an
> LED and switch, are perplexing but I am moving on.  If someone figures this
> our, post here, thanks!
> On Saturday, June 13, 2020 at 5:11:14 PM UTC-7 jo...@allwinedesigns.com
> wrote:
>
>> According to the system manual for the AI (
>> https://github.com/beagleboard/beaglebone-ai/wiki/System-Reference-Manual
>> ),
>> P8.17 is GPIO 242. It also doesn’t list GPIOs for the B mapping of the
>> other pins (so I don’t know if it’s doable or not), but you have access to
>> other GPIO that are connected to the same cape pin using sysfs. So P8.45 is
>> GPIO 224 (different gpio pin, though gpio8.0) and P8.30 is GPIO 116 (again,
>> different port/pin, gpio4.20). I’m not sure if you can access the b version
>> of those pins using sysfs or not, but you should be able to with libgpiod,
>> using gpioget and gpioset.
>>
>> On Jun 13, 2020, at 5:53 PM, jimvr  wrote:
>>
>> Trying to get through the GPIO instantiation into sysfs, and I still
>> cannot control some GPIO, but I have another issue that is perplexing... I
>> have three pins that do not want to come alive in sysfs...
>>
>>
>>
>> *gpio278 gpio8.22 cape P8.30b*
>>
>> *gpio272 gpio8.16 cape P8.45b *
>> *gpio274 gpio8.18 cape P8.17*
>> -- I have checked the TI PinMux too,l good., pins are available and are
>> mapped as I would assume to the GPIO crosspoint
>> -- Device Tree definitions, look good
>> *DRA7XX_CORE_IOPAD( 0x3624, PIN_INPUT_PULLUP | MUX_MODE14 ) // Ball A7
>> P8.17 gpio8-18*
>> *DRA7XX_CORE_IOPAD( 0x3634, PIN_INPUT_PULLUP | MUX_MODE14 ) // B9 P8.30b
>> gpio8_22*
>> *DRA7XX_CORE_IOPAD( 0x35CC, PIN_INPUT | MUX_MODE14 ) // B10 P8.30a
>> default*
>> *DRA7XX_CORE_IOPAD( 0x361C, 

Re: [beagleboard] Re: GPIO5.2 or BBAI (Rev A1) Cape Pin P9.18b, For Example Won't Read Pin Value Correctly

[John Allwine]

According to the system manual for the AI 
(https://github.com/beagleboard/beaglebone-ai/wiki/System-Reference-Manual), 
P8.17 is GPIO 242. It also doesn’t list GPIOs for the B mapping of the other 
pins (so I don’t know if it’s doable or not), but you have access to other GPIO 
that are connected to the same cape pin using sysfs. So P8.45 is GPIO 224 
(different gpio pin, though gpio8.0) and P8.30 is GPIO 116 (again, different 
port/pin, gpio4.20). I’m not sure if you can access the b version of those pins 
using sysfs or not, but you should be able to with libgpiod, using gpioget and 
gpioset.

> On Jun 13, 2020, at 5:53 PM, jimvr  wrote:
> 
> Trying to get through the GPIO instantiation into sysfs, and I still cannot 
> control some GPIO, but I have another issue that is perplexing... I have 
> three pins that do not want to come alive in sysfs...
> 
> gpio278 gpio8.22 cape P8.30b
> gpio272 gpio8.16 cape P8.45b 
> gpio274 gpio8.18 cape P8.17
> -- I have checked the TI PinMux too,l good., pins are available and are 
> mapped as I would assume to the GPIO crosspoint
> -- Device Tree definitions, look good
> DRA7XX_CORE_IOPAD( 0x3624, PIN_INPUT_PULLUP | MUX_MODE14 )// Ball 
> A7 P8.17 gpio8-18
> DRA7XX_CORE_IOPAD( 0x3634, PIN_INPUT_PULLUP | MUX_MODE14 )// B9 
> P8.30b  gpio8_22
> DRA7XX_CORE_IOPAD( 0x35CC, PIN_INPUT | MUX_MODE14 ) // B10 P8.30a default
> DRA7XX_CORE_IOPAD( 0x361C, PIN_OUTPUT_PULLDOWN | MUX_MODE14 ) // B7 
> P8.45b gpio8_16 Up square wave output
> DRA7XX_CORE_IOPAD( 0x35DC, PIN_INPUT | MUX_MODE14 ) // F11 P8.45a default
> -- "show-pins" confirms that the pins are defined, and I can make them change 
> via Device Tree .dtb changes, look good
> P8.30b   141 fast rx  up  14 gpio 7.22
> gpio@48053000 (gpio8)
> P8.45b   135 fastdown 14 gpio 7.16
> gpio@48053000 (gpio8)
> P8.17137 fast rx  up  14 gpio 7.18
> gpio@48053000 (gpio8)
> 
> However, when I try to "export" those as gpio pins, they show a write error:
> debian@beaglebone:~$ echo 274 > /sys/class/gpio/export
> -bash: echo: write error: Invalid argument
> 
> Kernel log shows the issue, the GPIO is invalid...
> journalctl -k -n10
> Jun 13 23:35:43 beaglebone kernel: export_store: invalid GPIO 278
> Jun 13 23:35:46 beaglebone kernel: export_store: invalid GPIO 272
> Jun 13 23:35:54 beaglebone kernel: export_store: invalid GPIO 274
> 
> I still have to go test these all now to see if they work, as I mentioned at 
> the first post, I have lots of pins working as expected, both IN and OUT, but 
> some just do not want to either report the right IN value, stuck at 0, or do 
> not put out electrically the correct state, even though "value" shows it 
> tracking my commands.
> 
> One commonality that I see is that these are all on Port8 -- 
> #define PORTSIZE 32
> #define GPIOXXX (PORTSIZE * 8) + 22   // gpio278 gpio8.22 cape P8.30b
> This is how I generate the gpio number...
> 
> ANY pointers here would be great!
> 
>> On Friday, June 12, 2020 at 6:28:33 PM UTC-7 jimvr wrote:
>> Having some trouble understanding what I am seeing, this is probably the 
>> simplest thing that I have to tackle right now, after getting just about 
>> every other piece of silicon working on the BBAI...a simple, read a GPIO.
>> 
>> I am using devicetrees, and I believe that I have my IO configured correctly 
>> from what I see, according to many feedback points:
>> shiow-pins:
>> P9.18b   173 slow rx  up  14 gpio 4.02
>> gpio@4805b000 (gpio5)
>> sysfs
>> /sys/class/gpio/gpio162
>>direction:  in
>>value:  0
>>active_low: 0
>>edge:none
>> 
>> I want to read this pin accurately.
>> My oscope shows the pin HIGH at 3V.
>> Everything else shows the pin LOW.
>> 
>> I am successful with many other pins, however I also have an output that is 
>> basically giving me the same grief.
>> 
>> P9.15 69 fastdown 14 gpio 2.12
>> gpio@48057000 (gpio3)
>> /sys/class/gpio/gpio108
>>direction:  out
>>value:  1
>>active_low: 0
>>edge:none
>> 
>> In this case, as an IO, I can change the value to 1 or 0, and sysfs keeps 
>> track of it just fine, but the oscope shows that pin stuck at 0.
>> 
>> Do I need to cut some of the 0-ohm resistors off the BBAI?
>> 
>> I do have the P9.18a pin floating, to not have a contention...
>> 
>>  DRA7XX_CORE_IOPAD( 0x36B4, PIN_INPUT_PULLUP | 
>> MUX_MODE14 | SLEWCONTROL )// G12 P9.18b GPIO5-2 Switch2
>>  DRA7XX_CORE_IOPAD( 0x37C8, PIN_INPUT | MUX_MODE14 ) 
>> // G17 P9.18a  not used, default
>> 
>> Like I said, I have just had amazing luck over the past few weeks with the 
>> PRU coding without a debugger, that was a lot of fun, but it is a pretty bad 
>> ass core, all 4 of them.
>> 
>> All I want to do now is monitor a 

Re: [beagleboard] RS485 serial communication on the Beaglebone AI

[John Allwine]

Thank you Oleg and Dnyaneshwar!

I've had some success since my last post. I'm trying to communicate with a
VFD, which up until now I've been communicating with over a USB serial
connection. I'd like USB on the AI to be dedicated to other things and the
device name to be guaranteed (to avoid having to figure out whether I need
to communicate with /dev/ttyUSB0 or /dev/ttyUSB1, etc.), so I wanted to
wire up communication over the VFD's RS485 port to a dedicated UART device
on the AI. I was hoping it would be a drop in replacement, but the half
duplex nature of RS485 has complicated the issue more than I had hoped.
There was a combination of device tree overlay issues, circuit issues,
software issues and examples that took different approaches that was
confusing the issue for me. I still have some issues to work out.

My hope for a drop in replacement led me to try and leverage kernel driver
level support for RS485 (rather than manually set a GPIO pin when I need to
write data). I was able to combine these examples to get some basic
communication working:
https://www.kernel.org/doc/html/latest/driver-api/serial/serial-rs485.html
https://groups.google.com/forum/m/#!msg/beagleboard/MIPuFXMPYqw/Imq_4_OJuuQJ

Various examples configured RTS as a GPIO pin, which affects how it's
configured in the device tree overlay. I ultimately went with using the
UART3 hardware RTS pin rather than an arbitrary GPIO pin. On the Beaglebone
AI, this is P9.17a and I have it configured as PIN_OUTPUT_PULLDOWN |
INPUT_EN | MUX_MODE1, the same as the TX and RX pins P9.21b and P9.22b. I'm
not sure if it needs to be that exactly (or if it does, why), but it has
worked for me.

Using the combination of examples linked above with the device tree overlay
properly configured, I was able to monitor the RTS, RX and TX pins on a
connected Arduino which showed that RTS was indeed getting pulled low prior
to sending data and then being set high again after the data was done
sending. To communicate with the VFD, though, I also wanted to leverage
libmodbus, which seems to have its own incantations to get RS485 working
that don't seem to work properly for me. This issue looks like it has
valuable information about it:
https://github.com/stephane/libmodbus/issues/331

In it, there is a table of drivers that libmodbus could work with with some
changes. How do I tell which driver I'm using?



On Tue, Jun 2, 2020 at 4:56 AM Dnyaneshwar Sahane 
wrote:

> Hello John,
> I am assuming that the UART signals are TTL level. For UART3 signals you
> have to interface with TTL to RS485 converter after that you can interface
> the RS485 to USB converter for any other windows or linux platform to
> send/receive data.
>
> *Regards,*
> *Dnyanesh*
> *+91-8655879300*
>
>
> On Fri, May 29, 2020 at 8:51 PM John Allwine  wrote:
>
>> Does anyone have any experience getting RS485 communication going over
>> one of the UARTs on the Beaglebone AI? I'm finding very little info on it
>> for the Beaglebone Black (none for the AI), and having a tough time
>> figuring out how to apply what there is to the AI. I'm specifically trying
>> to use UART3 on the Beaglebone AI and I'm not sure what to do.
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to beagleboard+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/beagleboard/493240ef-925a-4b69-9a90-e3a689987185%40googlegroups.com
>> <https://groups.google.com/d/msgid/beagleboard/493240ef-925a-4b69-9a90-e3a689987185%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/CA%2B2x4gtQw7ptRRvYBb062WdV8yxtC%2BcrKcacEf%2BXujYGiXzT6w%40mail.gmail.com
> <https://groups.google.com/d/msgid/beagleboard/CA%2B2x4gtQw7ptRRvYBb062WdV8yxtC%2BcrKcacEf%2BXujYGiXzT6w%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/CAPEK9qaFd%2BgPOKbWG%2B7ryzv%3D88-8R-o9Q5T4-Ss9uUuN5N-u9A%40mail.gmail.com.

[beagleboard] RS485 serial communication on the Beaglebone AI

[John Allwine]

Does anyone have any experience getting RS485 communication going over one 
of the UARTs on the Beaglebone AI? I'm finding very little info on it for 
the Beaglebone Black (none for the AI), and having a tough time figuring 
out how to apply what there is to the AI. I'm specifically trying to use 
UART3 on the Beaglebone AI and I'm not sure what to do.

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

Re: [beagleboard] Re: Questions about BeagleBone AI

[John Allwine]

> 
>Unless you disable the DSP processors (2x C66x DSP and maybe also the
> 4x EVE) and reconfigure the RAM, the RAM available to the main processor is
> only about 650MB -- DSP reserves the other 300+ MB.

How do you go about disabling the DSP and EVE cores?

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

Re: [beagleboard] Re: uart mapping to /dev/tty on Beaglebone AI

[John Allwine]

This works!

DRA7XX_CORE_IOPAD( 0x34F0, PIN_INPUT | MUX_MODE14 ) // P9.21a
DRA7XX_CORE_IOPAD( 0x37C4, PIN_OUTPUT_PULLUP | INPUT_EN | MUX_MODE1 ) //
P9.21b
DRA7XX_CORE_IOPAD( 0x369C, PIN_INPUT   | MUX_MODE14 ) // P9.22a
DRA7XX_CORE_IOPAD( 0x37C0, PIN_OUTPUT_PULLUP | INPUT_EN | MUX_MODE1 ) //
P9.22b


On Thu, May 14, 2020 at 4:39 PM John Allwine  wrote:

> Adding this to my device tree overlay seemed to make /dev/ttyO2 show up:
>  {
>   status = "okay";
> };
>
> I am not able to receive data, though, only send. Any ideas?
>
> On Thursday, May 14, 2020 at 9:22:07 AM UTC-6, John Allwine wrote:
>>
>> I'm trying to set up UART3 on the Beaglebone AI to work as a serial port,
>> but I'm not sure what is involved. I configured P9.21b and P9.22b to be in
>> mode 1, which is mapped to uart3_tx and uart3_rx. How do I get those pins
>> bound to a tty device under /dev? Maybe they already are and I don't know
>> which one?
>>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/4e851999-7922-41c1-9002-b7a357b37249%40googlegroups.com
> <https://groups.google.com/d/msgid/beagleboard/4e851999-7922-41c1-9002-b7a357b37249%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/CAPEK9qYLTNo7JXjHFgP%3DCzo%3DYL0kG8OVqeDtwSmE-xw0-G2JEw%40mail.gmail.com.

[beagleboard] Re: uart mapping to /dev/tty on Beaglebone AI

[John Allwine]

Adding this to my device tree overlay seemed to make /dev/ttyO2 show up:
 {
  status = "okay";
};

I am not able to receive data, though, only send. Any ideas?

On Thursday, May 14, 2020 at 9:22:07 AM UTC-6, John Allwine wrote:
>
> I'm trying to set up UART3 on the Beaglebone AI to work as a serial port, 
> but I'm not sure what is involved. I configured P9.21b and P9.22b to be in 
> mode 1, which is mapped to uart3_tx and uart3_rx. How do I get those pins 
> bound to a tty device under /dev? Maybe they already are and I don't know 
> which one?
>

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

[beagleboard] uart mapping to /dev/tty on Beaglebone AI

[John Allwine]

I'm trying to set up UART3 on the Beaglebone AI to work as a serial port, 
but I'm not sure what is involved. I configured P9.21b and P9.22b to be in 
mode 1, which is mapped to uart3_tx and uart3_rx. How do I get those pins 
bound to a tty device under /dev? Maybe they already are and I don't know 
which one?

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

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

[John Allwine]

Gotcha, thanks! I'll use a different pin.

On Tue, May 12, 2020 at 9:03 AM Jason Kridner 
wrote:

>
>
> 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
>>> <https://github.com/PocketNC/BeagleBoard-DeviceTrees/blob/pocketnc-ai-test/src/arm/am5729-beagleboneai-pocketnc-pro.dts#L56>
>>> :
>>> $ 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
>>>>>> <https://github.com/beagleboard/beaglebone-ai/wiki/System-Reference-Manual#p9.11-p9.13>
>>>>>> it lists P9.13a as not being bound to a

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

[John Allwine]

Thanks for the suggestions. Here's what I get when I run show_pins.pl when
I use the device tree overlay linked above
<https://github.com/PocketNC/BeagleBoard-DeviceTrees/blob/pocketnc-ai-test/src/arm/am5729-beagleboneai-pocketnc-pro.dts#L56>
:
$ 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
>>> <https://github.com/beagleboard/beaglebone-ai/wiki/System-Reference-Manual#p9.11-p9.13>
>>> 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
>>> <https://github.com/PocketNC/BeagleBoard-DeviceTrees/blob/pocketnc-ai-test/src/arm/am5729-beagleboneai-pocketnc-pro.dts#L56>
>>>  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
> https://groups.google.com/d/msgid/beagleboard/d808c9de-7abd-42bd-ab24-a697fb5f1913%40googlegroups.com
> <https://groups.google.com/d/msgid/beagleboard/d808c9de-7abd-42bd-ab24-a697fb5f1913%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/CAPEK9qZ4XLGMycRbbQEt9YnzRNGcEvy7oPz0p_CD04_dXe7poQ%40mail.gmail.com.

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

[John Allwine]

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 
> <https://github.com/beagleboard/beaglebone-ai/wiki/System-Reference-Manual#p9.11-p9.13>
>  
> 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 
> <https://github.com/PocketNC/BeagleBoard-DeviceTrees/blob/pocketnc-ai-test/src/arm/am5729-beagleboneai-pocketnc-pro.dts#L56>
>  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 
https://groups.google.com/d/msgid/beagleboard/90909b3d-3482-494b-98db-4f1e342360ea%40googlegroups.com.

[beagleboard] accessing P9.13 on Beaglebone AI

[John Allwine]

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 
https://groups.google.com/d/msgid/beagleboard/f9923508-a8ad-48b4-9ed7-f92f5533cf1e%40googlegroups.com.

Re: [beagleboard] Re: how to change uEnv.txt from U boot interface ?

[John Allwine]

This is how I did it using a microSD card: 
https://groups.google.com/forum/m/#!category-topic/beagleboard/b21LZKh8z2w

John Allwine
Principal Software Engineer
https://www.pocketnc.com

> On May 6, 2020, at 7:23 AM, zdenko.ba...@gmail.com wrote:
> 
> 
> Hi Ahmed,
> 
> I write a bit later but it can help someone else. 
> 
> If you have a backup of uEnv.txt - so than it is quick and simple. 
> 
> First copy file content to RAM memory:
> ext4load mmc 1 0x8000 /boot/uEnv.txt_bck
> 
> Write content of file to new file:
> ext4write mmc 1 0x8000 /boot/uEnv.txt 2042 0
> 
> mmc 1 - it is my rootfs partition. Use the command mmc list to see the 
> partition.
>   
> 
>> On Wednesday, September 14, 2016 at 3:02:59 AM UTC+2, Yahya ahmed wrote:
>> Hi all,
>> 
>> I made some changes on the uEnv.txt file from my computer , then I rebooted 
>> my beaglebone.
>> Now it starts the u-boot and writes "starting kernel" and it just hangs. 
>> My system(ubuntu) can't see the beaglebone anymore when I connect it using 
>> USB, so I can't re-edit my uEnv.txt 
>> 
>> So, is there anyway I can undo my edits on uEnv.txt ?? Can I do it from the 
>> U-Boot interface ?
>> 
>> 
> 
> -- 
> For more options, visit http://beagleboard.org/discuss
> --- 
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/ce8683ff-d37a-4b71-b422-6c57e7fe57eb%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/A6A875A7-63B6-459D-B0BF-8C4E597D5095%40pocketnc.com.

Re: [beagleboard] Re: BBAI Running TI SDK 6.03.00.106 DeviceTree File Creation

[John Allwine]

I found this post helpful to get going with an overlay based on the one you 
mentioned: 
https://www.element14.com/community/community/project14/visionthing/blog/2019/11/16/beagleboard-ai-brick-recovery-procedure

-John

> On May 4, 2020, at 5:13 PM, jimvr  wrote:
> 
> 
> I do see this base file...
> a) is there a user manual for it?
> b) after I am done, how to "compile" to a .dtb using the TI SDK build?
> 
> Thanks!
> 
>> On Monday, May 4, 2020 at 4:08:46 PM UTC-7, jimvr wrote:
>> I have utilized the TI PinMux tool to create all of the necessary functions 
>> that I need in my project.
>> 
>> I just cannot seem to get past how to create the .dtb file from the output 
>> of the PinMux tool.  I have a handful of files that are C defines and such, 
>> but no clear path to the dts or dtb file.
>> 
>> I have spend hours looking, and running scripts and pulling down git repos, 
>> to find that "my build" which is just the downloaded SDK SDcard image of the 
>> Matrix build from TI...
>> 
>> All of the links to the Cloud9 distro are not working, 
>> https://github.com/beagleboard/BeagleBoard-DeviceTrees.git for example is 
>> not something that works at all.  The four files that I have here are ones 
>> that are perhaps what I need to use, but I just don't know where to start.
>> 
>> Thanks in advance.
> 
> -- 
> For more options, visit http://beagleboard.org/discuss
> --- 
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/925ac5f5-00c1-47f2-8b6b-c294b09b5043%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/1C9868A5-F6E1-449A-832E-E31335872718%40pocketnc.com.

Re: [beagleboard] Re: BB AI task blocked

[John Allwine]

That did it. Thank you, Robert!

On Mon, May 4, 2020 at 7:55 AM Robert Nelson 
wrote:

> On Mon, May 4, 2020 at 8:50 AM John Allwine  wrote:
> >
> > That's the driver for Wifi chip? How can I disable that driver and
> anything trying to use it?
>
> blacklist it ..
>
> /etc/modprobe.d/brcmfmac-blacklist.conf
>
> blacklist brcmfmac
>
> 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/CAOCHtYjrXUp_BGr9sGD36EAJLmtUvgaJENaj7GPFWJdRodykxA%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/CAA9ERVrbg5vUUaFMonbVKLVjwkCG5xHkFAYPqaQ9PxSZ4yCSPA%40mail.gmail.com.

Re: [beagleboard] Re: BB AI task blocked

[John Allwine]

That's the driver for Wifi chip? How can I disable that driver and anything
trying to use it?

On Mon, May 4, 2020 at 7:48 AM Robert Nelson 
wrote:

> On Mon, May 4, 2020 at 8:45 AM John Allwine  wrote:
> >
> > Does anyone know anything about this? I'm seeing similar behavior on
> kernel 4.14.108-ti-rt-r134. I can't even ssh in anymore because something
> is hung at startup (I used to be able to, but I'm not sure why). After
> booting with a known good microSD card and checking kern.log, I see this:
>
> It's our "lovely" non-mainline "brcmfmac" driver..  It' fub-bar'd for RT..
>
> v4.14.x uses this 150+ patchset:
> https://community.cypress.com/docs/DOC-19000
>
> 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/CAPEK9qbyFsy4TDYPme%2Bs4KOvxwTUFrk48NQtmcGUmRpjbDs9uw%40mail.gmail.com.

[beagleboard] Re: BB AI task blocked

[John Allwine]

Does anyone know anything about this? I'm seeing similar behavior on kernel 
4.14.108-ti-rt-r134. I can't even ssh in anymore because something is hung 
at startup (I used to be able to, but I'm not sure why). After booting with 
a known good microSD card and checking kern.log, I see this:

[  242.872658] INFO: task systemd-udevd:351 blocked for more than 120 
seconds.
[  242.879698]   Tainted: GW  O4.14.108-ti-rt-r134 #1stretch
[  242.886558] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
this message.
[  242.894551] systemd-udevd   D0   351332 0x0101
[  242.894623] [] (__schedule) from [] 
(schedule+0x64/0x108)
[  242.894661] [] (schedule) from [] 
(__mmc_claim_host+0xb4/0x1d0)
[  242.894700] [] (__mmc_claim_host) from [] 
(sdio_claim_host+0x2c/0x44)
[  242.894737] [] (sdio_claim_host) from [] 
(sdio_bus_probe+0x80/0x12c)
[  242.894783] [] (sdio_bus_probe) from [] 
(driver_probe_device+0x2d4/0x480)
[  242.894826] [] (driver_probe_device) from [] 
(__driver_attach+0x10c/0x128)
[  242.894867] [] (__driver_attach) from [] 
(bus_for_each_dev+0x8c/0xd0)
[  242.894907] [] (bus_for_each_dev) from [] 
(driver_attach+0x2c/0x30)
[  242.894945] [] (driver_attach) from [] 
(bus_add_driver+0x1b8/0x278)
[  242.894986] [] (bus_add_driver) from [] 
(driver_register+0x88/0x104)
[  242.895024] [] (driver_register) from [] 
(sdio_register_driver+0x34/0x38)
[  242.895082] [] (sdio_register_driver) from [] 
(btsdio_init+0x2c/0x1000 [btsdio])
[  242.895152] [] (btsdio_init [btsdio]) from [] 
(do_one_initcall+0x64/0x19c)
[  242.895196] [] (do_one_initcall) from [] 
(do_init_module+0x74/0x210)
[  242.895238] [] (do_init_module) from [] 
(load_module+0x22a0/0x29f8)
[  242.895324] [] (load_module) from [] 
(SyS_init_module+0x1a4/0x1e0)
[  242.895369] [] (SyS_init_module) from [] 
(__sys_trace_return+0x0/0x10)
[  242.895424] INFO: task connmand:526 blocked for more than 120 seconds.
[  242.902076]   Tainted: GW  O4.14.108-ti-rt-r134 #1stretch
[  242.908948] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
this message.
[  242.916849] connmandD0   526  1 0x
[  242.916920] [] (__schedule) from [] 
(schedule+0x64/0x108)
[  242.916958] [] (schedule) from [] 
(__mmc_claim_host+0xb4/0x1d0)
[  242.916995] [] (__mmc_claim_host) from [] 
(sdio_claim_host+0x2c/0x44)
[  242.917206] [] (sdio_claim_host) from [] 
(brcmf_sdio_bus_txctl+0x134/0x1a0 [brcmfmac])
[  242.917551] [] (brcmf_sdio_bus_txctl [brcmfmac]) from 
[] (brcmf_proto_bcdc_msg+0xb4/0xb8 [brcmfmac])
[  242.917895] [] (brcmf_proto_bcdc_msg [brcmfmac]) from 
[] (brcmf_proto_bcdc_set_dcmd+0x38/0x100 [brcmfmac])
[  242.918234] [] (brcmf_proto_bcdc_set_dcmd [brcmfmac]) from 
[] (brcmf_fil_cmd_data+0x88/0xb4 [brcmfmac])
[  242.918572] [] (brcmf_fil_cmd_data [brcmfmac]) from 
[] (brcmf_fil_iovar_data_set+0x94/0xb8 [brcmfmac])
[  242.918909] [] (brcmf_fil_iovar_data_set [brcmfmac]) from 
[] (brcmf_fil_iovar_int_set+0x3c/0x58 [brcmfmac])
[  242.919241] [] (brcmf_fil_iovar_int_set [brcmfmac]) from 
[] (brcmf_configure_arp_nd_offload+0x50/0x70 [brcmfmac])
[  242.919754] [] (brcmf_configure_arp_nd_offload [brcmfmac]) 
from [] (brcmf_cfg80211_up+0x2ec/0x3a4 [brcmfmac])
[  242.920108] [] (brcmf_cfg80211_up [brcmfmac]) from 
[] (brcmf_netdev_open+0xac/0x128 [brcmfmac])
[  242.920319] [] (brcmf_netdev_open [brcmfmac]) from 
[] (__dev_open+0xe4/0x15c)
[  242.920368] [] (__dev_open) from [] 
(__dev_change_flags+0x1a4/0x1d0)
[  242.920412] [] (__dev_change_flags) from [] 
(dev_change_flags+0x28/0x58)
[  242.920451] [] (dev_change_flags) from [] 
(devinet_ioctl+0x704/0x7cc)
[  242.920489] [] (devinet_ioctl) from [] 
(inet_ioctl+0x1a4/0x1d0)
[  242.920532] [] (inet_ioctl) from [] 
(sock_ioctl+0x15c/0x300)
[  242.920571] [] (sock_ioctl) from [] 
(do_vfs_ioctl+0xc0/0x94c)
[  242.920604] [] (do_vfs_ioctl) from [] 
(SyS_ioctl+0x7c/0x8c)
[  242.920651] [] (SyS_ioctl) from [] 
(ret_fast_syscall+0x0/0x5c)

On Tuesday, October 29, 2019 at 2:28:07 PM UTC-6, Andrew Elder wrote:
>
>
> Similar observed with
>
> debian@ai:~$ uname -a
> Linux ai 4.19.73-ti-rt-r29 #1stretch SMP PREEMPT RT Wed Oct 9 21:13:08 UTC 
> 2019 armv7l GNU/Linux
>
> [  484.306447] INFO: task kworker/u4:0:7 blocked for more than 120 seconds.
> [  484.313237]   Tainted: GW  O  4.19.73-ti-rt-r29 
> #1stretch
> [  484.320145] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
> this message.
> [  484.329172] INFO: task kworker/1:1:66 blocked for more than 120 seconds.
> [  484.336062]   Tainted: GW  O  4.19.73-ti-rt-r29 
> #1stretch
> [  484.342924] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
> this message.
> [  484.355157] INFO: task kworker/u5:0:68 blocked for more than 120 
> seconds.
> [  484.362016]   Tainted: GW  O  4.19.73-ti-rt-r29 
> #1stretch
> [  484.368869] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
> this message.   
>
>
>
> On Friday, October 25, 

Re: [beagleboard] Re: problems with realtime kernel on Beaglebone AI

[John Allwine]

Per Cern's suggestion on the MachineKit forums 
<https://groups.google.com/d/msg/machinekit/1iYGU9VfvPM/ie9R7QfJBQAJ>, I 
simply removed the chunk of code that was throwing this error and all seems 
to be well.


On Friday, May 1, 2020 at 3:36:40 PM UTC-6, John Allwine wrote:
>
> This seems to be the source of the problem: 
> https://github.com/machinekit/machinekit-hal/blob/9fca994e08e3f8384498e78ea8e8baa1c899e4db/src/rtapi/rtapi_app.cc#L1457
>
> The system call iopl seems to be returning an error:
> http://man7.org/linux/man-pages/man2/iopl.2.html
>
> On Fri, May 1, 2020 at 2:39 PM John Allwine  wrote:
>
>> I'm not sure, what does that involve? It's probably worth a shot.
>>
>> On Fri, May 1, 2020 at 2:38 PM Robert Nelson  
>> wrote:
>>
>>> Let me know if we need to tweak the rt kernel config to support that..
>>>
>>> On Fri, May 1, 2020, 3:15 PM John Allwine  wrote:
>>>
>>>> I checked dmesg and saw this as well:
>>>>
>>>> [  811.654246] warning: process `rtapi:0' used the deprecated sysctl 
>>>> system call with 8.1.2.
>>>>
>>>> On Friday, May 1, 2020 at 2:13:15 PM UTC-6, John Allwine wrote:
>>>>>
>>>>> I'm trying to use a real time kernel on the Beaglebone AI to get 
>>>>> MachineKit running. I'm able to run MachineKit on a non-rt kernel 
>>>>> (4.14.108-ti-r113), but when I update to the latest ti-rt kernel 
>>>>> (4.14.108-ti-rt-r134), I get an error: 
>>>>>
>>>>> user cannot gain I/O privileges - forgot 'sudo make setuid'?
>>>>>
>>>>> Any idea what's going on? Is there a different kernel that is 
>>>>> recommended?
>>>>>
>>>> -- 
>>>> For more options, visit http://beagleboard.org/discuss
>>>> --- 
>>>> You received this message because you are subscribed to the Google 
>>>> Groups "BeagleBoard" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>> an email to beagleboard+unsubscr...@googlegroups.com.
>>>> To view this discussion on the web visit 
>>>> https://groups.google.com/d/msgid/beagleboard/0d99a63b-0522-4666-805c-d12c3d1628ae%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/beagleboard/0d99a63b-0522-4666-805c-d12c3d1628ae%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/CAOCHtYgNeScirH6faFDFg9vH14xxOMG0GiP6h%3DqMtsf6mpV43A%40mail.gmail.com
>>>  
>>> <https://groups.google.com/d/msgid/beagleboard/CAOCHtYgNeScirH6faFDFg9vH14xxOMG0GiP6h%3DqMtsf6mpV43A%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/2ba70c72-ad39-4a11-adeb-32feab3c93b5%40googlegroups.com.

Re: [beagleboard] Re: problems with realtime kernel on Beaglebone AI

[John Allwine]

This seems to be the source of the problem:
https://github.com/machinekit/machinekit-hal/blob/9fca994e08e3f8384498e78ea8e8baa1c899e4db/src/rtapi/rtapi_app.cc#L1457

The system call iopl seems to be returning an error:
http://man7.org/linux/man-pages/man2/iopl.2.html

On Fri, May 1, 2020 at 2:39 PM John Allwine  wrote:

> I'm not sure, what does that involve? It's probably worth a shot.
>
> On Fri, May 1, 2020 at 2:38 PM Robert Nelson 
> wrote:
>
>> Let me know if we need to tweak the rt kernel config to support that..
>>
>> On Fri, May 1, 2020, 3:15 PM John Allwine  wrote:
>>
>>> I checked dmesg and saw this as well:
>>>
>>> [  811.654246] warning: process `rtapi:0' used the deprecated sysctl
>>> system call with 8.1.2.
>>>
>>> On Friday, May 1, 2020 at 2:13:15 PM UTC-6, John Allwine wrote:
>>>>
>>>> I'm trying to use a real time kernel on the Beaglebone AI to get
>>>> MachineKit running. I'm able to run MachineKit on a non-rt kernel
>>>> (4.14.108-ti-r113), but when I update to the latest ti-rt kernel
>>>> (4.14.108-ti-rt-r134), I get an error:
>>>>
>>>> user cannot gain I/O privileges - forgot 'sudo make setuid'?
>>>>
>>>> Any idea what's going on? Is there a different kernel that is
>>>> recommended?
>>>>
>>> --
>>> For more options, visit http://beagleboard.org/discuss
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "BeagleBoard" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to beagleboard+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/beagleboard/0d99a63b-0522-4666-805c-d12c3d1628ae%40googlegroups.com
>>> <https://groups.google.com/d/msgid/beagleboard/0d99a63b-0522-4666-805c-d12c3d1628ae%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/CAOCHtYgNeScirH6faFDFg9vH14xxOMG0GiP6h%3DqMtsf6mpV43A%40mail.gmail.com
>> <https://groups.google.com/d/msgid/beagleboard/CAOCHtYgNeScirH6faFDFg9vH14xxOMG0GiP6h%3DqMtsf6mpV43A%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/CAPEK9qZzdD6-RTnqhczA9twawWA3aaPDv3a-vy_AZWp8m48RxQ%40mail.gmail.com.

Re: [beagleboard] Re: problems with realtime kernel on Beaglebone AI

[John Allwine]

I'm not sure, what does that involve? It's probably worth a shot.

On Fri, May 1, 2020 at 2:38 PM Robert Nelson 
wrote:

> Let me know if we need to tweak the rt kernel config to support that..
>
> On Fri, May 1, 2020, 3:15 PM John Allwine  wrote:
>
>> I checked dmesg and saw this as well:
>>
>> [  811.654246] warning: process `rtapi:0' used the deprecated sysctl
>> system call with 8.1.2.
>>
>> On Friday, May 1, 2020 at 2:13:15 PM UTC-6, John Allwine wrote:
>>>
>>> I'm trying to use a real time kernel on the Beaglebone AI to get
>>> MachineKit running. I'm able to run MachineKit on a non-rt kernel
>>> (4.14.108-ti-r113), but when I update to the latest ti-rt kernel
>>> (4.14.108-ti-rt-r134), I get an error:
>>>
>>> user cannot gain I/O privileges - forgot 'sudo make setuid'?
>>>
>>> Any idea what's going on? Is there a different kernel that is
>>> recommended?
>>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to beagleboard+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/beagleboard/0d99a63b-0522-4666-805c-d12c3d1628ae%40googlegroups.com
>> <https://groups.google.com/d/msgid/beagleboard/0d99a63b-0522-4666-805c-d12c3d1628ae%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/CAOCHtYgNeScirH6faFDFg9vH14xxOMG0GiP6h%3DqMtsf6mpV43A%40mail.gmail.com
> <https://groups.google.com/d/msgid/beagleboard/CAOCHtYgNeScirH6faFDFg9vH14xxOMG0GiP6h%3DqMtsf6mpV43A%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/CAPEK9qZX6mJLpCTN8OAhrCRZvbJNdapoTLMreu6vj8wD6qgjqg%40mail.gmail.com.

[beagleboard] Re: problems with realtime kernel on Beaglebone AI

[John Allwine]

I checked dmesg and saw this as well:

[  811.654246] warning: process `rtapi:0' used the deprecated sysctl system 
call with 8.1.2.

On Friday, May 1, 2020 at 2:13:15 PM UTC-6, John Allwine wrote:
>
> I'm trying to use a real time kernel on the Beaglebone AI to get 
> MachineKit running. I'm able to run MachineKit on a non-rt kernel 
> (4.14.108-ti-r113), but when I update to the latest ti-rt kernel 
> (4.14.108-ti-rt-r134), I get an error: 
>
> user cannot gain I/O privileges - forgot 'sudo make setuid'?
>
> Any idea what's going on? Is there a different kernel that is recommended?
>

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

[beagleboard] problems with realtime kernel on Beaglebone AI

[John Allwine]

I'm trying to use a real time kernel on the Beaglebone AI to get MachineKit 
running. I'm able to run MachineKit on a non-rt kernel (4.14.108-ti-r113), 
but when I update to the latest ti-rt kernel (4.14.108-ti-rt-r134), I get 
an error: 

user cannot gain I/O privileges - forgot 'sudo make setuid'?

Any idea what's going on? Is there a different kernel that is recommended?

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

Re: [beagleboard] PRU locking up Beaglebone AI

[John Allwine]

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

Re: [beagleboard] PRU locking up Beaglebone AI

[John Allwine]

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

Re: [beagleboard] PRU locking up Beaglebone AI

[John Allwine]

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:
>>>>
>>>> https://github.com/PocketNC/machinekit-hal/blob/c8b38386d87abc45baa33593681cbae46d996980/src/hal/drivers/hal_pru_generic/pru_generic.p#L261-L264
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Apr 28, 2020 at 10:50 AM Jason Kridner <
>>>> jkrid...@beagleboard.org> wrote:
>>>>
>>>>> 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,

Re: [beagleboard] PRU locking up Beaglebone AI

[John Allwine]

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:
>>>
>>> https://github.com/PocketNC/machinekit-hal/blob/c8b38386d87abc45baa33593681cbae46d996980/src/hal/drivers/hal_pru_generic/pru_generic.p#L261-L264
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Apr 28, 2020 at 10:50 AM Jason Kridner 
>>> wrote:
>>>
>>>> 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 

Re: [beagleboard] PRU locking up Beaglebone AI

[John Allwine]

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:
>>
>> https://github.com/PocketNC/machinekit-hal/blob/c8b38386d87abc45baa33593681cbae46d996980/src/hal/drivers/hal_pru_generic/pru_generic.p#L261-L264
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Apr 28, 2020 at 10:50 AM Jason Kridner 
>> wrote:
>>
>>> 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 n

Re: [beagleboard] PRU locking up Beaglebone AI

[John Allwine]

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:
>
> https://github.com/PocketNC/machinekit-hal/blob/c8b38386d87abc45baa33593681cbae46d996980/src/hal/drivers/hal_pru_generic/pru_generic.p#L261-L264
>
>
>
>
>
>
>
> On Tue, Apr 28, 2020 at 10:50 AM Jason Kridner 
> wrote:
>
>> 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] [] (__

Re: [beagleboard] PRU locking up Beaglebone AI

[John Allwine]

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:
https://github.com/PocketNC/machinekit-hal/blob/c8b38386d87abc45baa33593681cbae46d996980/src/hal/drivers/hal_pru_generic/pru_generic.p#L261-L264







On Tue, Apr 28, 2020 at 10:50 AM Jason Kridner 
wrote:

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

Re: [beagleboard] Re: can't ssh to BBAI after upgrading rt kernel

[John Allwine]

Thanks Dennis!

This is what I ended up doing:

1) I flashed an SD card with this image:
https://debian.beagleboard.org/images/am57xx-debian-9.9-lxqt-armhf-2019-08-03-4gb.img.xz
2) Booted up the BBAI with the SD card in.
3) sudo mkdir /mnt/emmc
4) sudo mount -t ext4 /dev/mmcblk1p1 /mnt/emmc
5) Edited /mnt/emmc/boot/uEnv.txt and switched the kernel back
6) sudo shutdown -h now
7) Removed the SD card
8) Booted back up successfully from the eMMC

This post was helpful:
https://unix.stackexchange.com/questions/449529/repair-uenv-txt-from-u-boot-terminal

On Mon, Apr 27, 2020 at 3:23 PM Dennis Lee Bieber 
wrote:

> On Mon, 27 Apr 2020 13:42:44 -0700 (PDT), in
> gmane.comp.hardware.beagleboard.user
> john-/83Ax2S01hhWk0Htik3J/w...@public.gmane.org wrote:
>
> >I also don't see anything when I hook up a monitor and keyboard. Is there
> a
> >way to boot with an SD card and switch the kernel back? Any other
> options?
> >I'd like to be able to save everything that was in my home directory if
> >possible.
>
> If you can successfully boot from SD card, you should be able to
> mount
> the eMMC and then copy that home directory off to the SD card.
>
>
> --
> Dennis L Bieber
>
> --
> 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/b21LZKh8z2w/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/h7jeafpp1rugrj6ia70m8ki94cc81s58sm%404ax.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/CAPEK9qbJrvsNW-1jo9Y7_wsSOrhx1PE4%3DbVnQg-WXt30ndjWeQ%40mail.gmail.com.

Re: [beagleboard] boot time on image that ships on the Beaglebone AI

[John Allwine]

I'm pretty much shooting in the dark here, but could this have anything to
do with it? I don't see a /dev/ttyGS0

debian@beaglebone:/etc$ systemctl status serial-getty@ttyGS0.service
● serial-getty@ttyGS0.service - Serial Getty on ttyGS0
   Loaded: loaded (/lib/systemd/system/serial-getty@.service; enabled;
vendor preset: enabled)
   Active: inactive (dead)
 Docs: man:agetty(8)
   man:systemd-getty-generator(8)
   http://0pointer.de/blog/projects/serial-console.html

Apr 27 18:16:17 beaglebone systemd[1]: Dependency failed for Serial Getty
on ttyGS0.
Apr 27 18:16:17 beaglebone systemd[1]: serial-getty@ttyGS0.service: Job
serial-getty@ttyGS0.service/start failed with result 'dependency'.

On Mon, Apr 27, 2020 at 11:51 AM John Allwine  wrote:

> Thanks for looking into it, Robert!
>
> On Mon, Apr 27, 2020 at 11:50 AM Robert Nelson 
> wrote:
>
>> On Mon, Apr 27, 2020 at 12:46 PM John Allwine  wrote:
>> >
>> > How can I disable that driver?
>>
>> The driver is: brcmfmac
>>
>> That was just an outlier, i moved it to be force loaded on startup
>> via: /etc/modules-load.d/modules.conf
>>
>> Which removed the 40second delay, but something else was still slowing
>> things down. So it didn't change anything.
>>
>> Anywho, i stopped for today, as day job was getting busy..
>>
>> 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/CAPEK9qZS0c_7kTNu_Eb2Xkf%3DwmnZF_7VV_5GUCtwghtUSmY3XQ%40mail.gmail.com.

Re: [beagleboard] boot time on image that ships on the Beaglebone AI

[John Allwine]

Thanks for looking into it, Robert!

On Mon, Apr 27, 2020 at 11:50 AM Robert Nelson 
wrote:

> On Mon, Apr 27, 2020 at 12:46 PM John Allwine  wrote:
> >
> > How can I disable that driver?
>
> The driver is: brcmfmac
>
> That was just an outlier, i moved it to be force loaded on startup
> via: /etc/modules-load.d/modules.conf
>
> Which removed the 40second delay, but something else was still slowing
> things down. So it didn't change anything.
>
> Anywho, i stopped for today, as day job was getting busy..
>
> 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/CAPEK9qZvqRFfhCnxa79JkEOW8chww%3D%3D13XSF-CXOeOc7LUDCVQ%40mail.gmail.com.

Re: [beagleboard] boot time on image that ships on the Beaglebone AI

[John Allwine]

How can I disable that driver?

On Mon, Apr 27, 2020 at 8:57 AM Robert Nelson 
wrote:

> On Mon, Apr 27, 2020 at 9:46 AM Robert Nelson 
> wrote:
> >
> > On Mon, Apr 27, 2020 at 8:48 AM John Allwine  wrote:
> > >
> > > Still taking about a minute and a half. Any ideas what happened since
> August last year?
> > >
> > > debian@beaglebone:~$ systemd-analyze
> > > Startup finished in 3.901s (kernel) + 1min 30.548s (userspace) = 1min
> 34.449s
> > > debian@beaglebone:~$ systemd-analyze blame
> > > 1min 28.412s generic-board-startup.service
> > >  46.345s bb-bbai-tether.service
> > >  42.818s dev-mmcblk1p1.device
> > >  14.048s systemd-rfkill.service
> > >927ms loadcpufreq.service
> > >861ms systemd-udev-trigger.service
> >
> > Quick comparison, between teh kernel from last august and today:
> >
> > debian@beaglebone:~$ uname -r ; systemd-analyze
> > 4.14.108-ti-r132
> > Startup finished in 6.013s (kernel) + 1min 30.734s (userspace) = 1min
> 36.747s
> >
> > debian@beaglebone:~$ uname -r ; systemd-analyze
> > 4.14.108-ti-r113
> > Startup finished in 4.517s (kernel) + 1min 30.544s (userspace) = 1min
> 35.062s
>
> It's taking 40+ seconds for the brcmfmac driver to load:
>
> Apr 27 14:50:27 beaglebone bb-bbai-tether[1610]: bbai:tether waiting
> for /sys/class/net/wlan0
> Apr 27 14:50:32 beaglebone bb-bbai-tether[1610]: bbai:tether waiting
> for /sys/class/net/wlan0
> Apr 27 14:50:37 beaglebone bb-bbai-tether[1610]: bbai:tether waiting
> for /sys/class/net/wlan0
> Apr 27 14:50:42 beaglebone bb-bbai-tether[1610]: bbai:tether waiting
> for /sys/class/net/wlan0
> Apr 27 14:50:48 beaglebone bb-bbai-tether[1610]: bbai:tether waiting
> for /sys/class/net/wlan0
> Apr 27 14:50:52 beaglebone bb-bbai-tether[1610]: bbai:tether waiting
> for /sys/class/net/wlan0
> Apr 27 14:50:57 beaglebone bb-bbai-tether[1610]: bbai:tether waiting
> for /sys/class/net/wlan0
> Apr 27 14:51:02 beaglebone bb-bbai-tether[1610]: bbai:tether waiting
> for /sys/class/net/wlan0
> Apr 27 14:51:07 beaglebone bb-bbai-tether[1610]: bbai:wlan0:Power
> Management:off
> Apr 27 14:51:07 beaglebone bb-bbai-tether[1610]: bbai:tether [iw phy
> phy0 interface add SoftAp0 type __ap]
> Apr 27 14:51:07 beaglebone bb-bbai-tether[1610]: bbai:tether [phy0 created]
> Apr 27 14:51:07 beaglebone bb-bbai-tether[1610]: bbai:tether [ip link
> set dev SoftAp0 down]
> Apr 27 14:51:07 beaglebone bb-bbai-tether[1610]: bbai:tether [ip link
> set dev SoftAp0 address 28:EC:9A:4C:63:D8]
> Apr 27 14:51:07 beaglebone bb-bbai-tether[1610]: bbai:tether [ip link
> set dev SoftAp0 up]
> Apr 27 14:51:08 beaglebone bb-bbai-tether[1610]: bbai:tether [ip addr
> add 192.168.8.1/24 broadcast 192.168.8.255 dev SoftAp0]
> Apr 27 14:51:08 beaglebone bb-bbai-tether[1610]: bbai:tether [iptables
> -w -t nat -A POSTROUTING -o wlan0 -j MASQUERADE]
> Apr 27 14:51:08 beaglebone bb-bbai-tether[1610]: bbai:tether [iptables
> -w -A FORWARD -i wlan0 -o SoftAp0 -m state --state RELATED,ESTABLISHE
> D -j ACCEPT]
> Apr 27 14:51:08 beaglebone bb-bbai-tether[1610]: bbai:tether [iptables
> -w -A FORWARD -i SoftAp0 -o wlan0 -j ACCEPT]
> Apr 27 14:51:10 beaglebone bb-bbai-tether[1610]: Configuration file:
> /tmp/hostapd-bbai.conf
> Apr 27 14:51:10 beaglebone bb-bbai-tether[1610]: SoftAp0: Could not
> connect to kernel driver
> Apr 27 14:51:10 beaglebone bb-bbai-tether[1610]: Using interface
> SoftAp0 with hwaddr 28:ec:9a:4c:63:d8 and ssid "BeagleBone-63D8"
> Apr 27 14:51:11 beaglebone bb-bbai-tether[1610]: SoftAp0: interface
> state UNINITIALIZED->ENABLED
> Apr 27 14:51:11 beaglebone bb-bbai-tether[1610]: SoftAp0: AP-ENABLED
>
> 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/CAPEK9qbfmFT%2BiWuc8iNZ7nLCDteOPrdvOj%3D8krW6JXL31kEGHA%40mail.gmail.com.

Re: [beagleboard] boot time on image that ships on the Beaglebone AI

[John Allwine]

Still taking about a minute and a half. Any ideas what happened since
August last year?

debian@beaglebone:~$ systemd-analyze
Startup finished in 3.901s (kernel) + 1min 30.548s (userspace) = 1min
34.449s
debian@beaglebone:~$ systemd-analyze blame
1min 28.412s generic-board-startup.service
 46.345s bb-bbai-tether.service
 42.818s dev-mmcblk1p1.device
 14.048s systemd-rfkill.service
   927ms loadcpufreq.service
   861ms systemd-udev-trigger.service

On Fri, Apr 24, 2020 at 6:58 PM John Allwine  wrote:

> That is on the second boot.
>
> > On Apr 24, 2020, at 6:06 PM, Robert Nelson 
> wrote:
> >
>

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

Re: [beagleboard] boot time on image that ships on the Beaglebone AI

[John Allwine]

That is on the second boot.

> On Apr 24, 2020, at 6:06 PM, Robert Nelson  wrote:
> 

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/80442C38-F5F6-4383-8A1A-24D116F7ED49%40pocketnc.com.

Re: [beagleboard] boot time on image that ships on the Beaglebone AI

[John Allwine]

Thanks Robert!

This is what I found:
debian@beaglebone:~$ cat /etc/dogtag
BeagleBoard.org Debian Image 2019-08-03
debian@beaglebone:~$ uname -a
Linux beaglebone 4.14.108-ti-r113 #1 SMP PREEMPT Wed Jul 31 00:01:10 UTC
2019 armv7l GNU/Linux
debian@beaglebone:~$ systemd-analyze
Startup finished in 2.585s (kernel) + 14.250s (userspace) = 16.836s
debian@beaglebone:~$ systemd-analyze blame
 12.577s bb-bbai-tether.service
  9.343s generic-board-startup.service
  7.241s dev-mmcblk1p1.device
  1.406s systemd-rfkill.service
  1.158s loadcpufreq.service
...

debian@beaglebone:~$ sudo /opt/scripts/tools/version.sh
[sudo] password for debian:
git:/opt/scripts/:[109f74fb87e6034ae1a8971a244064a8d5e090a5]
model:[BeagleBoard.org_BeagleBone_AI]
dogtag:[BeagleBoard.org Debian Image 2019-08-03]
kernel:[4.14.108-ti-r113]
nodejs:[v6.17.0]
pkg check: to individually upgrade run: [sudo apt install --only-upgrade
]
pkg:[bb-cape-overlays]:[4.4.20190801.0-0rcnee0~stretch+20190801]
pkg:[bb-wl18xx-firmware]:[1.20190227.1-0rcnee0~stretch+20190227]
pkg:[kmod]:[23-2rcnee1~stretch+20171005]
pkg:[librobotcontrol]:[1.0.4-git20190227.1-0rcnee0~stretch+20190327]
pkg:[firmware-ti-connectivity]:[20180825+dfsg-1rcnee1~stretch+20181217]
groups:[debian : debian adm kmem dialout cdrom floppy audio dip video
plugdev users systemd-journal i2c bluetooth netdev gpio pwm eqep remoteproc
admin spi tisdk weston-launch xenomai cloud9ide]
cmdline:[console=ttyS0,115200n8 root=/dev/mmcblk1p1 ro rootfstype=ext4
rootwait coherent_pool=1M net.ifnames=0 rng_core.default_quality=100 quiet]
dmesg | grep remote
[2.968159] remoteproc remoteproc0: 4b234000.pru is available
[2.969261] remoteproc remoteproc1: 4b238000.pru is available
[2.995373] remoteproc remoteproc2: 4b2b4000.pru is available
[3.000800] remoteproc remoteproc3: 4b2b8000.pru is available
[7.529481] remoteproc remoteproc4: 5882.ipu is available
[7.582192] remoteproc remoteproc5: 5502.ipu is available
[7.597129] remoteproc remoteproc4: powering up 5882.ipu
[7.597150] remoteproc remoteproc4: Booting fw image dra7-ipu1-fw.xem4,
size 6867360
[7.631779] remoteproc remoteproc6: 4080.dsp is available
[7.637271] remoteproc remoteproc5: powering up 5502.ipu
[7.637297] remoteproc remoteproc5: Booting fw image dra7-ipu2-fw.xem4,
size 3751356
[7.638584] remoteproc remoteproc4: registered virtio0 (type 7)
[7.638594] remoteproc remoteproc4: remote processor 5882.ipu is now
up
[7.654881] remoteproc remoteproc7: 4100.dsp is available
[7.799217] Modules linked in: omap_remoteproc virtio_rpmsg_bus
rpmsg_core usb_f_acm u_serial usb_f_ecm usb_f_mass_storage usb_f_rndis
u_ether iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat
libcomposite nf_conntrack iptable_mangle iptable_filter cmemk(O)
uio_pdrv_genirq uio spidev pruss_soc_bus pru_rproc pruss pruss_intc
ip_tables x_tables
[7.800200] Modules linked in: omap_remoteproc virtio_rpmsg_bus
rpmsg_core usb_f_acm u_serial usb_f_ecm usb_f_mass_storage usb_f_rndis
u_ether iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat
libcomposite nf_conntrack iptable_mangle iptable_filter cmemk(O)
uio_pdrv_genirq uio spidev pruss_soc_bus pru_rproc pruss pruss_intc
ip_tables x_tables
[7.951028] remoteproc remoteproc6: powering up 4080.dsp
[7.951054] remoteproc remoteproc6: Booting fw image dra7-dsp1-fw.xe66,
size 20998684
[7.958543] remoteproc remoteproc7: powering up 4100.dsp
[7.958562] remoteproc remoteproc7: Booting fw image dra7-dsp2-fw.xe66,
size 20998684
[8.018185] remoteproc remoteproc5: registered virtio1 (type 7)
[8.018199] remoteproc remoteproc5: remote processor 5502.ipu is now
up
[8.061603] remoteproc remoteproc6: registered virtio2 (type 7)
[8.061613] remoteproc remoteproc6: remote processor 4080.dsp is now
up
[8.072743] remoteproc remoteproc7: registered virtio3 (type 7)
[8.072754] remoteproc remoteproc7: remote processor 4100.dsp is now
up
dmesg | grep pru
[2.946787] pruss 4b20.pruss: creating PRU cores and other child
platform devices
[2.968159] remoteproc remoteproc0: 4b234000.pru is available
[2.968233] pru-rproc 4b234000.pru: PRU rproc node
/ocp/pruss_soc_bus@4b226004/pruss@0/pru@34000 probed successfully
[2.969261] remoteproc remoteproc1: 4b238000.pru is available
[2.969313] pru-rproc 4b238000.pru: PRU rproc node
/ocp/pruss_soc_bus@4b226004/pruss@0/pru@38000 probed successfully
[2.984426] pruss 4b28.pruss: creating PRU cores and other child
platform devices
[2.995373] remoteproc remoteproc2: 4b2b4000.pru is available
[2.995437] pru-rproc 4b2b4000.pru: PRU rproc node
/ocp/pruss_soc_bus@4b2a6004/pruss@0/pru@34000 probed successfully
[3.000800] remoteproc remoteproc3: 4b2b8000.pru is available
[3.000845] pru-rproc 4b2b8000.pru: PRU rproc node
/ocp/pruss_soc_bus@4b2a6004/pruss@0/pru@38000 probed successfully
[

Re: [beagleboard] how to make beaglebone ai flasher image

[John Allwine]

Ah, yes, it does seem to be working. I forgot to use sudo and received the
error:
We don't know how to reset the leds as we are not a BBB compatible device

Further up it told me to be root. Oops.

Thanks Robert!

On Fri, Apr 24, 2020 at 4:01 PM Robert Nelson 
wrote:

> On Fri, Apr 24, 2020 at 4:57 PM  wrote:
> >
> > How can I make a flasher image on a Beaglebone AI? On the BBB, I can run
> /opt/scripts/tools/eMMC/beaglebone-black-make-microSD-flasher-from-eMMC.sh
> >
> > Is there a comparable script for the AI?
>
> It 'should' work...  un-tested.. ;)
>
> It's the same set of scripts that the default flasher uses on teh ai..
>
> 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/CAPEK9qZ-7Yqcuo-0pOQLFw1kMHk22ULw53BXPxAdNp-UrKhB4Q%40mail.gmail.com.

[beagleboard] Best way to distinguish between BBB vs BBAI in C

[John Allwine]

What's the best way, at runtime, in C, to know whether we're executing on a 
Beaglebone Black vs Beaglebone AI?

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

Re: [beagleboard] IEP timer on PRUs on the Beaglebone AI and Beaglebone Black

[John Allwine]

I must have inadvertently set the CMP0_RST_CNT_EN bit on the COMPARE_CFG 
register on pr2. After setting that in the setup function, it works on both 
PRUs.

Does anyone know why the SR1.1 section is in the reference manual? Can the PRUs 
be configured to use SR1.1 over SR2.0?
 
> 
> I'm attempting to use the IEP timer on the PRUs on the Beaglebone AI (as 
> wells the BBB), but am a bit confused about the difference between SR1.1 and 
> SR2.0. The technical reference manual for the am572x has two separate 
> sections for the IEP, one for SR1.1 and one for SR2.0. I implemented two 
> different PRU programs that implement the basic programming sequence 
> described in section 30.1.11.2.2.3 (for SR2.0) and section 30.2.11.2.2.3 (for 
> SR1.1):
> 
> SR2.0 program: 
> https://github.com/PocketNC/cloud9-examples/blob/iep_tests/BeagleBone/AI/pru/blinkExternalLEDWithIEPTimer.pru2_0.c
> SR1.1 program: 
> https://github.com/PocketNC/cloud9-examples/blob/iep_tests/BeagleBone/AI/pru/blinkExternalLEDWithIEPTimer.pru1_1.c
> 
> I haven't tested the SR1.1 program on the Beaglebone Black, but I've been 
> debugging programs that seem to initialize the IEP using that method, so I 
> believe it should work on the BBB. The SR1.1 program does not work on any of 
> the prus on the Beaglebone AI. The SR2.0 program only seems to work on pr2_0 
> and pr2_1 on the Beaglebone AI. Why doesn't it work on pr1_0 and pr1_1?
> 
> I'd appreciate any information that could explain the difference between 
> SR1.1 and SR2.0 and the IEP Timers on the PRU with respect to the BBB vs the 
> BBAI. 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/9b02e8f2-b0a2-4799-89c6-62f3b319e7a1%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/99D6516E-3596-413F-B7C8-A26313D3029B%40allwinedesigns.com.

Re: [beagleboard] UIO PRU driver on Beaglebone AI

[John Allwine]

Err, I meant objcopy and ld

On Friday, April 10, 2020 at 7:49:09 AM UTC-6, John Allwine wrote:
>
> Converting the .p files seems like a bigger effort than I'd like to commit 
> right now. I was able to convert the .bin file to a .elf file using objcopy 
> and ln:
> Maybe this will come in handy for someone:
> https://github.com/PocketNC/bin2elf
>
> On Thursday, April 9, 2020 at 11:19:43 AM UTC-6, Jason Kridner wrote:
>>
>>
>>
>> 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 <
>>>> jo...@allwinedesigns.com> 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. 
>>&

Re: [beagleboard] UIO PRU driver on Beaglebone AI

[John Allwine]

Converting the .p files seems like a bigger effort than I'd like to commit 
right now. I was able to convert the .bin file to a .elf file using objcopy 
and ln:
Maybe this will come in handy for someone:
https://github.com/PocketNC/bin2elf

On Thursday, April 9, 2020 at 11:19:43 AM UTC-6, Jason Kridner wrote:
>
>
>
> 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 <
>>> jo...@allwinedesigns.com> 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 
>>> >

Re: [beagleboard] UIO PRU driver on Beaglebone AI

[John Allwine]

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?

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 <
>> jo...@allwinedesigns.com> 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 

Re: [beagleboard] UIO PRU driver on Beaglebone AI

[John Allwine]

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 <
> jo...@allwinedesigns.com > 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 beagl...@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 unsub

Re: [beagleboard] UIO PRU driver on Beaglebone AI

[John Allwine]

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?

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

[beagleboard] UIO PRU driver on Beaglebone AI

[John Allwine]

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? 

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.

Re: [beagleboard] libgpiod on Beaglebone AI

[John Allwine]

I don't intend to toggle a GPIO as fast as possible (except to test), but 
from a performance standpoint that demonstration seemed to indicate that 
there are issues with sysfs. Hopefully, libgpiod will prove to be better!

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

Re: [beagleboard] libgpiod on Beaglebone AI

[John Allwine]

That was it! gpioget gpiochip3 10 worked.

Thanks Robert!

On Friday, March 27, 2020 at 9:42:15 AM UTC-6, RobertCNelson wrote:
>
> On Fri, Mar 27, 2020 at 10:34 AM John Allwine  > wrote: 
> > 
> > I'm looking into using libgpiod to control the GPIO on the Beaglebone AI 
> in user space. I'm starting small and trying to use the included command 
> line tools gpioget and gpioset, but not having any success. 
> > 
> > The Beaglebone AI System Manual lists what looks like the gpio chip and 
> line under pinmux mode 14. P8.19 looks to be gpiochip4 line 10. Am I 
> reading that right? 
> > 
> > I have P8.19 configured in a device tree overlay to be an INPUT_PULLUP, 
> pinmuxed to mode 14. I have a button wired up to P8.19, which shorts it to 
> GND. I have verified that the button works using sysfs P8.19 GPIO number is 
> 106, also listed in the same table from the system manual): 
> > 
> > echo 106 > /sys/class/gpio/export 
> > cat /sys/class/gpio/gpio106/value 
> > 
> > The last command outputs 1 when the button is not depressed, 0 when it 
> is, as expected. I'm unable to use gpioget to see the same results: 
> > 
> > gpioget gpiochip4 10 
> > 
> > When I run that, I always get back 0. Any thoughts? 
>
> You can use gpioinfo to dump the whole pin list.. 
>
> sudo gpioinfo 
>
> But, 106 = 3*32 +10 - which should be gpiochip3 10, as long as the 
> gpio's are linear.. 
>
> You can also run: 
>
> sudo /opt/scripts/device/bone/show-pins.pl 
>
> Which is nicely documented, only using the legacy method.. 
>
> 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/27d5abc0-0292-40ae-8a2f-d4efd2437d35%40googlegroups.com.

[beagleboard] libgpiod on Beaglebone AI

[John Allwine]

I'm looking into using libgpiod to control the GPIO on the Beaglebone AI in 
user space. I'm starting small and trying to use the included command line 
tools gpioget and gpioset, but not having any success.

The Beaglebone AI System Manual 

 lists 
what looks like the gpio chip and line under pinmux mode 14. P8.19 looks to 
be gpiochip4 line 10. Am I reading that right?

I have P8.19 configured in a device tree overlay to be an INPUT_PULLUP, 
pinmuxed to mode 14. I have a button wired up to P8.19, which shorts it to 
GND. I have verified that the button works using sysfs P8.19 GPIO number is 
106, also listed in the same table from the system manual):

echo 106 > /sys/class/gpio/export
cat /sys/class/gpio/gpio106/value 

The last command outputs 1 when the button is not depressed, 0 when it is, 
as expected. I'm unable to use gpioget to see the same results:

gpioget gpiochip4 10

When I run that, I always get back 0. Any thoughts?





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

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

[John Allwine]

> 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. 
>
>
What is or how do I find the control register address for the AM5x? The system 
manual 

 seems 
to list the offsets from the control register, but I'm unsure what that is.
 

> 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/
>>
>
Thanks Drew! I'll give libgpiod a shot.  

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

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

[John Allwine]

How bad is bad? That other driver/device has stale data? The chip gets 
fried? Somewhere in between?

If I'm certain that my application is the only user space application 
accessing a particular pin, can I safely use /dev/mem for the speed 
increase?

On Thursday, March 26, 2020 at 11:19:48 AM UTC-6, William Hermans wrote:
>
>
>
> On Thu, Mar 26, 2020 at 10:59 AM John Allwine  > wrote:
>
>> I'm happy to leave the pinmux alone, but if all I'm doing is reading or 
>> writing to the GPIO can I do so from /dev/mem?
>>
>> According to this post, it's about 1000x faster: 
>> http://chiragnagpal.com/examples.html
>>
>> It's also how hal_bb_gpio is implemented: 
>> https://github.com/machinekit/machinekit-hal/blob/master/src/hal/drivers/hal_bb_gpio/hal_bb_gpio.c
>>
>> If necessary, it could be rewritten to use sysfs, but if it means being 
>> 1000x slower, that's not ideal.
>>
>
> I've used /dev/mem to access(read, and write), registers on the BBB and I 
> do agree. It is much faster.
>
> The reason why it's bad to use /dev/mem . . . is that there is no way for 
> the kernel to know what state a given "device" is in. That is, without a 
> physical read. Potentially, this could be bad. Especially if another driver 
> or application has access to the given hardware register.
>  
>

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

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

[John Allwine]

I'm happy to leave the pinmux alone, but if all I'm doing is reading or 
writing to the GPIO can I do so from /dev/mem?

According to this post, it's about 1000x faster: 
http://chiragnagpal.com/examples.html

It's also how hal_bb_gpio is implemented: 
https://github.com/machinekit/machinekit-hal/blob/master/src/hal/drivers/hal_bb_gpio/hal_bb_gpio.c

If necessary, it could be rewritten to use sysfs, but if it means being 
1000x slower, that's not ideal.

On Thursday, March 26, 2020 at 9:31:37 AM UTC-6, RobertCNelson wrote:
>
> On Thu, Mar 26, 2020 at 9:32 AM John Allwine  > wrote: 
> > 
> > Thanks Robert! 
> > 
> > Can you clarify why it's a bad idea on the am57xx when it seems to be 
> the fastest way to do it on the am335x? 
>
> I'm still waiting for an official Application Note from TI for the 
> am57xx, but the short answer, don't touch the pinmux registers from 
> linux. 
>
> > What is the fastest way to read/write to the GPIO on the am57xx? 
>
> Define them in the device tree, toggle them from userspace, just like 
> the am335x, just don't TOUCH the pinmux... 
>
> 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/230415f7-c639-4a4c-8838-ba6c6efcdcd1%40googlegroups.com.

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

[John Allwine]

Thanks Robert!

Can you clarify why it's a bad idea on the am57xx when it seems to be the 
fastest way to do it on the am335x?

What is the fastest way to read/write to the GPIO on the am57xx?

On Thursday, March 26, 2020 at 8:26:56 AM UTC-6, RobertCNelson wrote:
>
> 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/9d396eb4-f781-4bed-b94c-9513ca1f341c%40googlegroups.com.

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

[John Allwine]

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?

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

[beagleboard] Re: macOS Catalina + Beaglebone Black

[John Allwine]

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/3836BD14-8D8E-4310-9498-028AADC95C42%40pocketnc.com.