[beagleboard] Ethernet module in beagle bone black

[Megha Bhirade]

Hi,

I am using beagle bone black board in Linux ubuntu 16.04LTS, i need to work 
on Ethernet .

requirement is like enabling Ethernet  between the Board and PC and i need 
to send the data from PC and need to receive the data on beagle bone black 
using Ethernet communication and once data collected that data i need to 
pass to the other PC using Uart..

Uart enabling and transmitting the data i understood...

please tell me how to configure Ethernet and C program to receive the data 
from Ethernet

please suggest me any related link for this

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

Re: [beagleboard] CAN Not Working (P9_24, P9_26, P9_19, P9_20 - Beaglebone Black Enhaced)

[debounce]

Hi Robert,

Thanks for looking at this.  Below is the output of the version.sh script.  
I took this with can0 and can1 working.  Please let me know if there is 
anything else I can help with.

git:/opt/scripts/:[1d3eb3a15fafc1463e0a86dcef15857aa2a827be]
eeprom:[A335BNLTSE0A2019BBE81671]
model:[SanCloud_BeagleBone_Enhanced]:WiFi AP 
Enabled:[https://github.com/lwfinger/rtl8723bu]
dogtag:[rcn-ee.net console Ubuntu Image 2019-04-10]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
2019.04-2-gbb4af0f50f]:[location: dd MBR]
kernel:[4.19.31-ti-r19]
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[disable_uboot_overlay_video=1]
uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
pkg check: to individually upgrade run: [sudo apt install --only-upgrade 
]
pkg:[bb-cape-overlays]:[4.4.20190610.0-0rcnee0~bionic+20190610]
pkg:[bb-wl18xx-firmware]:[1.20190227.1-0rcnee0~bionic+20190227]
pkg:[kmod]:[24-1ubuntu3.2rcnee0~bionic+20190208]
WARNING:pkg:[librobotcontrol]:[NOT_INSTALLED]
cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
root=/dev/mmcblk1p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
net.ifnames=0 quiet cape_universal=enable]
dmesg | grep remote
dmesg | grep pru
dmesg | grep pinctrl-single
dmesg | grep gpio-of-helper
lsusb
Bus 001 Device 003: ID 0bda:b720 Realtek Semiconductor Corp. 
Bus 001 Device 002: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
END

On Tuesday, July 23, 2019 at 9:55:11 AM UTC-5, RobertCNelson wrote:
>
> On Tue, Jul 23, 2019 at 12:03 AM debounce  > wrote: 
> > 
> > Thanks for the feedback guys.  I went ahead and attacked this problem 
> again tonight. 
> > 
> > This one was really strange.  The reason I was using config-pin instead 
> of overlays was because config-pin seems to be the preferred method on 
> beaglebone to configure the pins now on the newer kernel and OS. 
>  "/sys/devices/bone_capemgr" no longer exists on my OS.  So the two options 
> I have is to use config-pin (beaglebone-universal-io) or /boot/uEnv.txt 
> > 
> > I tried enabling the overlay in /boot/uboot.txt by adding: 
> > uboot_overlay_addr0=/lib/firmware/BB-CAN1-00A0.dtbo 
> > uboot_overlay_addr0=/lib/firmware/BB-CAN0-00A0.dtbo 
> > 
> > This resulted in the same behavior. 
> > 
> > Then I tried to add the "DCAN" overlay: 
> > uboot_overlay_addr0=/lib/firmware/BB-DCAN1-00A0.dtbo 
> > 
> > This seems to have changed something and both CAN interfaces (can0 and 
> can1) began to work!  After I verified CAN was working with the manually 
> added overlays in uEnv.txt, I went ahead and removed all the manually added 
> CAN overlays (BB-CAN0-00A0.dtbo, BB-CAN1-00A0.dtbo, BB-DCAN1-00A0.dtbo) 
> from /boot/uEnv.txt and left "enable_uboot_cape_universal=1" and attempted 
> to configure the CAN pins via: 
> > 
> > config-pin P9_19 can 
> > config-pin P9_20 can 
> > config-pin P9_24 can 
> > config-pin P9_26 can 
> > sudo ip link set can0 up type can bitrate 50 
> > sudo ip link set can1 up type can bitrate 50 
> > sudo ifconfig can0 up 
> > sudo ifconfig can1 up 
> > 
> > The result was the CAN on can0 and can1 continued to work (RX and TX on 
> both interfaces).  How bizarre!  Anyone have a clue why adding the 
> "BB-DCAN1-00A0.dtbo" to /boot/uEnv.txt caused the CAN interfaces to work on 
> can0 and can1 all of a sudden? 
> > 
> > Anyway, thanks again for the tips.  I hope this helps someone in the 
> future! 
>
> Interesting, can you please run: 
>
> sudo /opt/scripts/tools/version.sh 
>
> When it's working, so i can validate and fix. 
>
> 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/e1cbd852-591c-40aa-80bb-5903f2a8ea5b%40googlegroups.com.

[beagleboard] Re: Mainline kernel driver for eQEP

[Dave]

I am using a Rotary Encoder with the eQEP as an input device. 
Initially I had a service that monitored sysfs changes to the count and 
injected right or left arrow keys based on the change. 
But the existing eqep driver did not notify changes correctly and once I 
found the need to change it, I added the key injection into the driver 
itself. 

I posted that here several months ago. I will look at your driver, the 
changes to use an RE as an input device are pretty simple. 
Maybe some others find them useful. 


On Monday, July 22, 2019 at 12:04:21 PM UTC-4, David Lechner wrote:
>
> FYI, I just submitted 
>  
> a driver for the eQEP using the new counter subsystem if anyone is 
> interested.
>
> I would be curious to hear which features of the eQEP people are using.
>

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

[beagleboard] Re: pwm audio driver on BBB wireless with snd-pwmsp module

[João Manoel]

I want to say that I managed to get the pwm sound working.

I was wrong when I said that the pwm sound was on the pin P9.28, in fact, 
this pin is related to the i2s sound from the board that is actually 
connected to the HDMI ic for sound. This explains why the "sound" was very 
noise; I'm surprised that I could listen to it, it is a digital sound data. 
I think that with good filtering it is even possible to remove the noise 
part of it if you have a mono sound for a cheap sound, just thinking Or 
maybe just connect an i2s ic driver and have a good sound :)

Anyway, in this case, the pwmsp module was not even working. To solve this, 
and to not confuse, I added the following line to uEnv.txt:

disable_uboot_overlay_audio=1

This will disable the i2s sound. (I think)
I used the dtbo created from the dts that I attached in the previous 
message on uEnv.txt, and loaded the module with: 

sudo modprobe snd_pwmsp

My system was freezing when I tried to play any sound. I recompiled the pwmsp 
module with the debug option enabled, and I found that the problem was on the 
statement (atomic_set(>timer_active, 1); of the file pwmsp_lib.c

This problem was fixed adding the line: pm_runtime_irq_safe(>dev); to the 
*drivers/pwm/pwm-tiehrpwm.c* (like here 
).
  I recompiled the kernel and the pwm sound worked. I don't know if the line 
added to the pwm driver of the board can 

impact in something else.








Em quarta-feira, 17 de julho de 2019 17:49:15 UTC+2, João Manoel escreveu:
>
> Hi,
>
> I'm trying to make the pwmsp driver work on my board. The driver is 
> compiled as a module on the kernel 4.14 by default
>
> https://github.com/beagleboard/linux/tree/4.14/sound/drivers/pwmsp
>
> I managed to make the driver work when I remove cape universal from 
> uEnv.txt (commenting the line #enable_uboot_cape_universal=1), the sound 
> is very noisy even with an RC low pass filter, but somehow it works. The 
> sound can be collected from pin P9.28, and it is recognized in ALSA as a 
> sound card.
>
> I have a LCD cape that I want to use, but when I connect my LCD to the 
> board the pwmsp driver doesn't load anymore. My LCD cape uses the same pin 
> P9.28 to control the brightness.
>
> I tried to recompile the dtbo used in my LCD removing the brightness 
> option leaving the pin completely free, but the pwmsp driver still not 
> loading, even when I force u-boot to not load the dtbo of the lcd (with 
> disable_uboot_overlay_addr0=1). I also tried to make my own dtbo file to 
> load the pwmsp driver but it also doesn't work, and the system crashes when 
> I try to play a sound.
>
> My question is how I change the PWM pin used by *pwmsp* to use as audio 
> output.
>
> My lcd module uses this dts:
>
>
> https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-CAPE-DISP-CT4-00A0.dts
>
> The dts that I tried to make to change the pwm port for pwmsp:
>
> /dts-v1/;
> /plugin/;
>
> / {
> compatible = "ti,beaglebone", "ti,beaglebone-black";
>
> /* identification */
> part-number = "BB-SND-PWM1";
> version = "00A0";
>
> /* state the resources this cape uses */
> exclusive-use =
> "P9.14",
> "P9.16";
>
> /*
>  * Free up the pins used by the cape from the pinmux helpers.
>  */
> fragment@0 {
> target = <>;
> __overlay__ {
> P9_14_pinmux { status = "disabled"; };  /* (U14) 
> gpmc_a2.ehrpwm1A */
> P9_16_pinmux { status = "disabled"; };  /* (T14) 
> gpmc_a3.ehrpwm1B */
> };
> };
>
> fragment@1 {
> target = <_pinmux>;
> __overlay__ {
> bb_pwm1_pin: pinmux-pwm1-pin {
> pinctrl-single,pins = <
> 0x48 0x06 /* (U14) 
> gpmc_a2.ehrpwm1A */
> 0x4c 0x06 /* (B17) 
> gpmc_a3.ehrpwm1B */
> >;
> };
> };
> };
>
> fragment@2 {
> target = <>;
> __overlay__ {
> bb_pwm1_test_helper: bb_snd-pwm1 {
> compatible = "bone-pinmux-helper";
> pinctrl-names = "default";
> pinctrl-0 = <_pwm1_pin>;
> status = "okay";
> };
> };
> };
>
> fragment@3 {
> target = <>;
> __overlay__ {
> status = "okay";
> };
> };
>
>
> fragment@4 {
> target = <>;
> __overlay__ {
> status = "okay";
> };
> };
>
> 

Re: [beagleboard] CAN Not Working (P9_24, P9_26, P9_19, P9_20 - Beaglebone Black Enhaced)

[Robert Nelson]

On Tue, Jul 23, 2019 at 12:03 AM debounce  wrote:
>
> Thanks for the feedback guys.  I went ahead and attacked this problem again 
> tonight.
>
> This one was really strange.  The reason I was using config-pin instead of 
> overlays was because config-pin seems to be the preferred method on 
> beaglebone to configure the pins now on the newer kernel and OS.  
> "/sys/devices/bone_capemgr" no longer exists on my OS.  So the two options I 
> have is to use config-pin (beaglebone-universal-io) or /boot/uEnv.txt
>
> I tried enabling the overlay in /boot/uboot.txt by adding:
> uboot_overlay_addr0=/lib/firmware/BB-CAN1-00A0.dtbo
> uboot_overlay_addr0=/lib/firmware/BB-CAN0-00A0.dtbo
>
> This resulted in the same behavior.
>
> Then I tried to add the "DCAN" overlay:
> uboot_overlay_addr0=/lib/firmware/BB-DCAN1-00A0.dtbo
>
> This seems to have changed something and both CAN interfaces (can0 and can1) 
> began to work!  After I verified CAN was working with the manually added 
> overlays in uEnv.txt, I went ahead and removed all the manually added CAN 
> overlays (BB-CAN0-00A0.dtbo, BB-CAN1-00A0.dtbo, BB-DCAN1-00A0.dtbo) from 
> /boot/uEnv.txt and left "enable_uboot_cape_universal=1" and attempted to 
> configure the CAN pins via:
>
> config-pin P9_19 can
> config-pin P9_20 can
> config-pin P9_24 can
> config-pin P9_26 can
> sudo ip link set can0 up type can bitrate 50
> sudo ip link set can1 up type can bitrate 50
> sudo ifconfig can0 up
> sudo ifconfig can1 up
>
> The result was the CAN on can0 and can1 continued to work (RX and TX on both 
> interfaces).  How bizarre!  Anyone have a clue why adding the 
> "BB-DCAN1-00A0.dtbo" to /boot/uEnv.txt caused the CAN interfaces to work on 
> can0 and can1 all of a sudden?
>
> Anyway, thanks again for the tips.  I hope this helps someone in the future!

Interesting, can you please run:

sudo /opt/scripts/tools/version.sh

When it's working, so i can validate and fix.

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/CAOCHtYjn3m8yMOsnA5%2BRbukj8jyzyDqOL-G%2BFOibWxdscHwFSw%40mail.gmail.com.