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

[Andrew P. Lentvorski]

It appears that the problem is in rpmsg_pru.c.

rpmsg_pru_read has the following code:

if (kfifo_is_empty(>msg_fifo) &&
(filp->f_flags & O_NONBLOCK))
return -EAGAIN;



rpmsg_pru_write presumably needs a similar piece of code with 
kfifo_is_full() or it needs to look for O_NONBLOCK and then use 
rpmsg_trysend instead of rpmsg_send.

Unfortunately, I've got nowhere near the Linux kernel programming chops to 
debate the implications of that.

Presumably, I need to file a bug somewhere?

Thanks.

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

[beagleboard] Re: eqep2 problemss

[TJF]

Am Samstag, 6. Juni 2020 09:49:59 UTC+2 schrieb cesare@gmail.com:
>
> Is there something else I can check?
>

Sure, check out libpruio. 
 Easy 
controlling of QEP modules in one, two or three line configurations 
(without any device tree trouble).

Regards

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

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

[Dennis Lee Bieber]

On Fri, 5 Jun 2020 20:00:42 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user
tomburtell-re5jqeeqqe8avxtiumw...@public.gmane.org wrote:

>I had the same problem.  I had messed around with uEnb.txt and made it 
>unreadable to the OS, stopping the OS from loading.  I tried the link to that 
>version of Linux you listed, but it didn't work at all.  Then, I tried a 
>different 
>version,(https://debian.beagleboard.org/images/bone-debian-9.9-lxqt-armhf-2019-08-03-4gb.img.xz)
> and it booted up like it should have when I held down S2. Also, on the matter 
>of using a USB to UART cable, the manufacturer of the cable had the labels 
>reversed.  (Tx and Rx).  Be aware that this might be a problem for you too.  
>That took a while to trouble-shoot because the gobbledygook that is output to 
>the screen is usually thought of as being just a bad baud setting. 


Please keep track of which board you are discussing.

am57xx-debian-9.9-lxqt-armhf-2019-08-03-4gb.img.xz 
is for the Beaglebone AI whereas
bone-debian-9.9-lxqt-armhf-2019-08-03-4gb.img.xz 
is for the Beaglebone Black (and similar boards). 

The BBAI and BBB use different SoCs (with much different on-board
hardware [unlike the R-Pis which have different SoCs but same on-board
hardware, so can function with a single OS image with just a bunch of board
specific DTBs), so an image built for one is not expected to run on the
other. As I recall, the BBAI also does not have a boot-select button (a
button that hasn't, in normal use, been required on the BBB since Debian
Jessie -- if the eMMC had been flashed with a modern uBoot smart enough to
search for the SD card and transfer control)




-- 
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/31ondft1r5aagkujsr7m328ue69vbkk6us%404ax.com.

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

[Andrew P. Lentvorski]

I was getting some strange bugs from some remoteproc stuff I was doing on a 
BBB, and eventually I tracked it down to the overunning the rpmsg system 
which can block for several seconds on a write.

Okay, fine.  No big deal.  This is what poll() was made for--flip 
"/dev/rpmsg_pru30" to O_NONBLOCK, set up POLLOUT, wait for a write event, 
write the data, and check the error.

Except that my overrun writes to "/dev/rpmsg_pru30" *still* block for 
several seconds (very bad) and then terminate with an Error 512 (huh?).

I can handle the error, but the big problem is the blocking.  That 
absolutely should not be allowed to happen.

What's going on?  And where do I file a bug about this?

Thanks.

# uname -a
Linux beaglebone 4.19.94-ti-r42 #1buster SMP PREEMPT Tue Mar 31 19:38:29 
UTC 2020 armv7l GNU/Linux


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

[beagleboard] How to modify BBAI not to be powered USB-C connector?

[Geza Kuhmann]

Hi All,

I'd like to make my BBAI so it could only be powered from the J9.5/6 pins, 
but *not* from the USB-C connector.
On the other hand, the USB-C connector should stay functional as pure USB 
connection (using the BBAI as a USB gadget).

Reading the schematic it seems to me that removing diode D81 would exactly 
do this, but not being a hardware expert, I would be glad if somebody could 
confirm this.

Thanks,

Geza

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

[beagleboard] Re: eqep2 problemss

[cesare . giavardi]

Thanks Robert for your quick reply.
I tried changing from uboot_overlay_eqep2 to uboot_overlay_addr0 but 
nothing happened.
Eqep2 is still not counting.

I checked the messages from 'version.h' and there is something strange (to 
me...):

...

uboot_overlay_options:[uboot_overlay_addr0=/lib/firmware/bone_eqep2-new-00A0.dtbo]
pkg check: to individually upgrade run: [sudo apt install --only-upgrade 
]

... 


Same message when I was using 
uboot_overlay_eqep2=/lib/firmware/bone_eqep2-new-00A0.dtbo

I tried changing uEnv.txt to 

uboot_overlay_addr0=/lib/firmware/bone_eqep2*1*-new-00A0.dtbo 


File ...eqep21... doesn't exist. After reboot I had the same message from 
'version.h':

uboot_overlay_options:[uboot_overlay_addr0=/lib/firmware/bone_eqep21-new-00A0.dtbo]

pkg check: to individually upgrade run: [sudo apt install --only-upgrade 
]


Could it be a problem?

Is there something else I can check?
Regards.
 
 

Il giorno sabato 6 giugno 2020 05:29:33 UTC+2, Cesare Giavardi ha scritto:
>
> Dear,
> I'm struggling with eqep2 on BBB, After one week of attempts nothing 
> works...
> Here my situation:
>
> - I compiled this dts file (generating *bone_eqep2-new-00A0.dtbo*):
>
> /dts-v1/;
> /plugin/;
>
> #include 
> #include 
> #include 
>
> / {
> compatible = "ti,beaglebone", "ti,beaglebone-black";
>
> // identification
> part-number = "bone_eqep2b";
> version = "00A0";
>
> // resources this cape uses
> exclusive-use =
> "P8.12", // EQEP2A_in
> "P8.11", // EQEP2B_in
> "P8.16", // EQEP2_index
> "P8.15", // EQEP2_strobe
>
> "eqep2"; // hardware ip used
>
> /*
> * Helper to show loaded overlays under: /proc/device-tree/chosen/overlays/
> */
> fragment@0 {
> target-path="/";
> __overlay__ {
>
> chosen {
> overlays {
> bone_eqep2b-00A0 = __TIMESTAMP__;
> };
> };
> };
> };
>
> /*
> * Free up the pins used by the cape from the pinmux helpers.
> */
> fragment@1 {
> target = <>;
> __overlay__ {
> P8_12_pinmux { status = "disabled"; }; /* P8_12: GPIO1_12 = EQEP2A_in */
> P8_11_pinmux { status = "disabled"; }; /* P8_11: GPIO1_13 = EQEP2B_in */
> P8_16_pinmux { status = "disabled"; }; /* P8_16: GPIO1_14 = EQEP2_index */
> P8_15_pinmux { status = "disabled"; }; /* P8_15: GPIO1_15 = EQEP2_strobe 
> */
> };
> };
>
> fragment@2 {
> target = <_pinmux>;
> __overlay__ {
> pinctrl_eqep2: pinctrl_eqep2_pins {
> pinctrl-single,pins = <
> BONE_P8_12 (*PIN_INPUT_PULLUP* | MUX_MODE4) /* P8_12: GPIO1_12 = 
> EQEP2A_in */
> BONE_P8_11 (*PIN_INPUT_PULLUP* | MUX_MODE4) /* P8_11: GPIO1_13 = 
> EQEP2B_in */
> BONE_P8_16 (PIN_INPUT | MUX_MODE4) /* P8_16: GPIO1_14 = EQEP2_index */
> BONE_P8_15 (PIN_INPUT | MUX_MODE4) /* P8_15: GPIO1_15 = EQEP2_strobe */
> // From: 
> https://groups.google.com/forum/#!searchin/beagleboard/eQep/beagleboard/Orp3tFcNgCc/mYacP_GkCQQJ
> >;
> };
> };
> };
>
> fragment@3 {
> target = <>;
> __overlay__ {
> status = "okay";
> };
> };
>
> fragment@4 {
> target = <>;
> __overlay__ {
> pinctrl-names = "default";
> pinctrl-0 = <_eqep2>;
>
> count_mode = <0>; // count_mode is not userspace op_mode
> // 0 -> Quadrature mode, normal 90 phase offset cha & chb.
> // 1 -> Direction mode.  cha input = clock, chb input = direction
> // 2 -> UP count mode for frequency measurement QDIR=1, ignore direction 
> input
> // 3 -> DOWN count mode for frequency measurement QDIR=0, ignore direction 
> input
>
> swap_inputs = <0>; // swap channel A and B? (0 - no, 1 - yes)
> invert_qa = <0>; // invert channel A input?
> invert_qb = <0>; // invert channel B input?
> invert_qi = <0>; // invert index input?
> invert_qs = <0>; // invert strobe input?
> omit_interrupt = <0>; // 1 -> do not install interrupt handler, 0 -> do 
> install
>
> status = "okay";
> };
> };
> };
>
>
>
> - Moved file to /lib/firmware
>
> - Modified /boot/uEnv.txt:
>  
>
> #Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0
>
> enable_uboot_overlays=1
> enable_uboot_cape_universal=1
> disable_uboot_overlay_video=1
>
> uname_r=4.14.108-ti-r127
> #uuid=
> #dtb=
> cmdline=coherent_pool=1M net.ifnames=0 rng_core.default_quality=100 quiet
>
> #In the event of edid real failures, uncomment this next line:
> #cmdline=coherent_pool=1M net.ifnames=0 rng_core.default_quality=100 quiet 
> video=HDMI-A-1:1024x768@60e
>
> #Use an overlayfs on top of a read-only root filesystem:
> #cmdline=coherent_pool=1M net.ifnames=0 rng_core.default_quality=100 quiet 
> overlayroot=tmpfs
>
> ##enable x15: eMMC Flasher:
> ##make sure, these tools are installed: dosfstools rsync
> #cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3-no-eeprom.sh
>
> #uboot_overlay_addr0=/lib/firmware/PRU_BlinkLed-00A0.dtbo
> uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo
>
>
> *uboot_overlay_eqep2=/lib/firmware/bone_eqep2-new-00A0.dtbo*
>
>
>
> - Reboot BBB
>
> - cd /sys/devices/platform/ocp/48304000.epwmss/48304180.eqeps
> - cat enabled --> 1
> - cat mode --> 0
> - cat position --> 0
>
> - Connnect the encoder.
>
> - cat position --> 0 *ALWAYS*
>
> - /opt/scripts/tool/version.sh:
>
>