Re: [beagleboard] Re: remoteproc write to PRU over rpmsg device blocks even when set non-blocking
Sure. Right now, I just keep track of how many messages are in flight and I don't allow it to queue too many. That's useful once you know what the bug is. Fortunately, I hit this bug before I had two threads (one receiving USB and one receiving ethernet) which would have made hunting it down quite painful. So, at least now I know that I *must* have a single thread acting as a gatekeeper on top of the rpmsg system. If, however, you try to use a library on top of this bug that actually expects the O_NONBLOCK behavior to work, you will have a long debugging chain. What *originally* tripped all of this was that I tried to use Rust and Tokio, which failed mysteriously. After far too much fruitless debugging, I switched down to Rust and mio, which also failed weirdly. So, I switched down to C, poll, and O_NONBLOCK, which then gave the incorrect blocking behavior and the ERESTARTSYS. After *that*, I could actually pinpoint the incorrect behavior as belonging to pru_rpmsg and as being due to a full queue with incorrect blocking semantics. Getting to that point, however, was neither pleasant nor straightforward. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/4f17a6a6-0c12-49de-81ec-25b072b6d9efo%40googlegroups.com.
[beagleboard] Re: soft UART implementation on the AM335x PRU
I've just posted v2 of the PRU Cookbook[1]. It should help with some of your questions. I suggest doing all the development in cloud9 on the Beagle. the PRU compiler is already installed on the current images. --Mark [1] https://github.com/MarkAYoder/PRUCookbook On Friday, June 19, 2020 at 9:37:17 AM UTC-4, awainia...@gmail.com wrote: > > Hello, > > I am still a newbie to PRU development, and I am trying to use the 9 bits > UART capability of the UART PRU firmware and I have a couple of questions > > 1- in the code composer studio,do I use the PRU compiler or the ARM > compiler ? > 2- do i have to use sys/bios when using the soft implementatio of the UART > ? if so how to upload the generated file to the card without an emulator, ( > I used FTP to deploy .out files to the beaglebone black and then coppying > the firmware to the remoteproc when getting introduced to the PRU > development) > > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/1edca93b-87b1-413f-a688-e4821149b17eo%40googlegroups.com.
[beagleboard] Re: 2GB linux image
wm.b.barnett wrote: > > Are there 2GB Linux images available? I have an older B-version and would > like to use it in a small application. > > Yes, 2 GB Linux Images are available but there is the limitations for the speed and performance. You cannot use it for complex applications. However, if you are wishing for the small application, it would be enough for the older BBB version. Regards, Sagar Patel -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/e182ea0b-44dc-4488-9902-5b6d39fe4d90o%40googlegroups.com.
[beagleboard] Ethernet phy ID u-boot fix
Hi there,
My BeagleBone Green has had major problems with the Ethernet phy since I
got it many years ago. There is a patch for Linux here:
https://github.com/RobertCNelson/bb-kernel/blob/am33x-v5.3/patches/drivers/ti/cpsw/0001-cpsw-search-for-phy.patch
I asked in #beagle on FreeNode IRC about this some months ago, after
finally getting around to building my device. Here is an abridged log,
which will save me rewriting it:
<+rcn-ee[m]> rah: that's fixed in u-boot... it'll be going away..
<+rcn-ee[m]> rah: here is the u-boot fix: (which is better then the
kernel fix)
https://github.com/u-boot/u-boot/blob/master/board/ti/am335x/board.c#L629-L700
<+rcn-ee[m]> rah: thus the only reason i still carry the patch, is for
user still running old u-boot..
<+rcn-ee[m]> Here's the commit:
https://github.com/u-boot/u-boot/commit/20c37fb1bfb9f20804645b2199699cd815a4d55c
< rah> U-Boot 2019.04-2-gbb4af0f50f (Jul 08 2019 - 11:44:39 -0500),
Build: jenkins-github_Bootloader-Builder-128
< rah> github seems to think that patch went into 2019.10
< rah> is there a beaglebone image with a later u-boot image that I can
flash?
<+rcn-ee[m]> rah: special build for you: sudo
/opt/scripts/tools/developers/update_bootloader.sh --beta
<+rcn-ee[m]> rah: , there should be a new print: printf("fixing up
phy_id for %s, old: %d, new: %d\n",
< rah> rcn-ee[m]: it looks like I was wrong about the release version
though, it looks like this patch went in from v2018.11-rc1 onwards
< rah> rcn-ee[m]: I'm not seeing this printf:
https://paste.debian.net/765/
<+rcn-ee[m]> rah: ugh CONFIG_OF_BOARD_SETUP, that's the fdt path, we are
still using the classic board path..
<+rcn-ee[m]> i'll need to do some testing, the last time i tried
switching over the fdt path, it was a shit show...
<+rcn-ee[m]> atleast now, we spec a larger hole at the start of the
partition.
< rah> ok, that's all going over my head but I get that you can't sort
it out now :-)
< rah> thanks anyway
I've been waiting patiently for months to hear more but nothing has
materialised. I've been waiting in #beagle to pounce on rcn-ee but he
has not appeared.
I just downloaded the latest Debian image, wrote it to the eMMC, booted
it, ran
$ sudo /opt/scripts/tools/developers/update_bootloader.sh --beta
and this is the resulting version:
U-Boot 2019.04-2-g31a8ae0206 (May 13 2020 - 09:26:17 -0500), Build:
jenkins-github_Bootloader-Builder-139
Which apparently still does not contain the fix:
[ 23.440684] cpsw 4a10.ethernet: phy
"/ocp/interconnect@4a00/segment@0/target-module@10/ethernet@0/mdio@1000/ethernet-phy@0"
not found on slave 0
Can anyone tell me whether the fix is going to appear in u-boot?
Thanks,
Bob Ham
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/27e213e2-535f-2981-cab6-3284a03acedf%40settrans.net.
signature.asc
Description: OpenPGP digital signature
Re: [beagleboard] Re: requesting information on pcb files for beaglebone black and beaglebone ai
The only part that shouldn't match is the logo (which we have stripped from the source). We have, at times, taken the source design and handed it off for manufacturing to be certain it matches. However, in this case, we relied on Embest to provide us with matching design files to the production hand-off. We can probably ask them to confirm the files are correct. I'm open to any further suggestions you have to validate it. Otherwise, we will validate when the A2 design is released from Seeed. I'm happy to provide the pre-release sources, but realize they aren't yet validated in hardware, so you'd be no better off. On Mon, Jun 15, 2020 at 8:41 PM jimvr wrote: > Jason, > > Well, I was wrong, the dsn and brd files that are here, are not matching > up. > https://github.com/beagleboard/beaglebone-ai/tree/master/HW > > I do see the A2 proposed changes, and I understand that the board files > for that is not yet available. > > Can you confirm that the design set that is up in the github, match? It > could be just our conversion went wrong, and we need to figure that out. > The schematic seems correct to the PDF that we have from the same github. > > On Saturday, June 13, 2020 at 1:29:30 PM UTC-7 jimvr wrote: > >> Jason, >> >> One of our friends has Allegro and we were able to convert, so good >> there. However, I noted that the files on GitHub are for A1, is there a >> board set package for A2, or errata from A1 to A2 that can be shared so >> that we can be sure to understand what was left off? >> >> I am having some IO pin issues right now, and it just seems like my A1 >> board is missing a signal or two to the cape header. Plus I can see that >> the JTAG port is not right, two wires perhaps needed? >> >> And if you are happy with this, I can send you the Altium project when >> done, and you can post that up? >> >> Share? >> >> On Saturday, June 13, 2020 at 9:01:41 AM UTC-7 jimvr wrote: >> >>> Jason, >>> >>> We also are interested in the Altium file export for the BBAI Rev A2, if >>> you can do that export. According to what I read, there are two methods >>> from this Altium post: >>> https://www.altium.com/documentation/altium-designer/allegro-import-ad >>> >>> *Allegro Binary PCB Design Files* >>> >>> The Import Wizard can directly import and translate Allegro PCB files >>> (*.brd) to Altium Designer PCB files (*.PcbDoc) when the Wizard has local >>> access to an Allegro PCB editor installation – that is, when a licensed >>> copy of Allegro PCB is installed on the same machine as Altium Designer. >>> >>> The Wizard uses Allegro’s included file conversion capabilities to >>> configure the design data for processing by the importer. >>> >>> *Allegro ASCII Extracted Design Files* >>> >>> Altium Designer’s Import Wizard can import and translate ASCII-based >>> Allegro PCB files (*.alg) that have been created from a licensed Allegro >>> PCB installation. The ASCII PCB design files are extracted from native >>> Allegro PCB files (*.brd) by Allegro’s included file converter >>> (extracta.exe), which is called by a special batch file supplied with >>> Altium Designer. >>> >>> Since Allegro binary-to-ASCII conversion is a self-contained file >>> process, the Allegro installation does not need to be accessed by Altium >>> Designer. The Allegro installation can be on any machine, and is only used >>> to generate suitable ASCII PCB design files. >>> We have many Altium seats here, if you wanted to "use" a license to try >>> the first method, I can create a temporary login to our license for Altium, >>> however you will need to download and install Altium on the same machine. >>> If you can create the .alg file set, that may help us that want to view >>> the board in Altium. Altium has no problem with the schematic, that was a >>> native import within Altium. >>> >>> Please let us know! You guys did a great job with that board design, >>> and the support from your team, stellar all around. Thanks. >>> >>> On Thursday, April 23, 2020 at 9:32:41 AM UTC-7 Jason Kridner wrote: >>> On Wed, Apr 22, 2020 at 10:35 AM Ramakrishna Bachimanchi < bach...@jlab.org> wrote: > Hello, > my name is Rama Bachimanchi and I am an electrical engineer working at > Jefferson Lab (non-profit research organization). I have come across the > amazing work you guys are doing and was looking into possibly modifying > one > of your designs to replace an obsolete ioc we are using (it's a kontron > pc/104 no longer in production). I was able to import the schematic into > Altium, but not the pcb design files. I am getting an error when tried to > view the files using the free allegro pcb viewer. Would it be possible to > update the files and also upload the ascii file, so that we can import > this > into altium. We are planning to replace the expansion connectors with > pc/104 connector. If we get to work and finish the design, we will most > likely share it with you(not sur
[beagleboard] Re: 2GB linux image
Bill Barnett wrote: > [-- text/plain, encoding 7bit, charset: UTF-8, 14 lines --] > > Are there 2GB Linux images available? I have an older B-version and would > like to use it in a small application. > The 'console' versions are smallest, the image file is only about 1Gb. You'll only have ssh (or local serial console) access to your BBB though. I *thought* an IOT (internet of things) version would fit in 2Gb but it looks as if the latest ones don't. -- Chris Green · -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/ift8sg-41l.ln1%40esprimo.zbmc.eu.
Re: [beagleboard] Re: remoteproc write to PRU over rpmsg device blocks even when set non-blocking
You could increase the vring buffers or check for full and retry depending on how critical the timing is. Sent from Yahoo Mail on Android On Tue, Jun 23, 2020 at 2:04 AM, Andrew P. Lentvorski wrote: Urk, sorry I didn't quite get the implications of this statement: The kfifo is used only on the receive path because of the asynchronous callbacks. The Tx-path is synchronous, the copy is attempted directly on the vring buffers That means that kfifo doesn't exist on send so the only available solution appears to be calling rpmsg_trysend when in O_NONBLOCK mode. That will hit the full vring buffers and should bounce back immediately with ENOMEM. 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/dcbb9c5a-229a-481f-8ea0-11a8735ac095o%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/961636032.1615460.1592898453563%40mail.yahoo.com.
Re: [beagleboard] Re: remoteproc write to PRU over rpmsg device blocks even when set non-blocking
Urk, sorry I didn't quite get the implications of this statement: The kfifo is used only on the receive path because of the asynchronous > callbacks. The > Tx-path is synchronous, the copy is attempted directly on the vring buffers > That means that kfifo doesn't exist on send so the only available solution appears to be calling rpmsg_trysend when in O_NONBLOCK mode. That will hit the full vring buffers and should bounce back immediately with ENOMEM. 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/dcbb9c5a-229a-481f-8ea0-11a8735ac095o%40googlegroups.com.
