Re: [beagleboard] Re: wl18xx warning - any resolution?

[jose...@gmail.com]

I would go a setp further from Robert's sugestion and manually upgrade the 
firmware file, using the one at:

https://git.ti.com/cgit/wilink8-wlan/wl18xx_fw/tree/

That FW should be retro-compatible with older drivers...

A segunda-feira, 14 de dezembro de 2020 à(s) 15:10:36 UTC, RobertCNelson 
escreveu:

> On Mon, Dec 14, 2020 at 9:03 AM ags  wrote:
> >
> > Does that mean that everyone running 4.14.x had these problems? I didn't 
> find an outpouring of posts about this problem (although possibly simply a 
> benign log entry) so thought it was a rarer problem that few others had.
> >
> > Is it reasonable to update just the radio firmware(s), or would that 
> pose a risk (greater than the upgrade)?
>
> 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]
>
> sudo apt update
> sudo apt install --only-upgrade firmware-ti-connectivity
>
> 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/c463b99b-a4bc-42cb-8bcd-432a640f56a7n%40googlegroups.com.

Re: [beagleboard] Re: wl18xx warning - any resolution?

[jose...@gmail.com]

I would suggest upgrading to the v4.19.x-ti kernel and then upgrade the 
firmware to TI's latest (8.9.0.0.85):

https://git.ti.com/cgit/wilink8-wlan/wl18xx_fw/

Upgrading the firmware to 8.9.0.0.85 solved some issues in my specific use 
case.

If that does'nt solve your issue, you can try also to upgrade the wl18xx 
driver.

For that, pick Robert's scripts and patches to build a BB kernel:

https://github.com/RobertCNelson/ti-linux-kernel-dev/tree/ti-linux-4.19.y

add to them TI's wl18xx R8.8 driver patches:

https://git.ti.com/cgit/wilink8-wlan/build-utilites/tree/patches/kernel_patches/4.19.38?h=r8.8

and build a custom kernel with:

./build_deb.sh

A terça-feira, 8 de dezembro de 2020 à(s) 06:42:24 UTC, ags escreveu:

>
> git:/opt/scripts/:[109f74fb87e6034ae1a8971a244064a8d5e090a5]
>
> eeprom:[A335BNLTBWA51650BBWG0378]
>
> model:[TI_AM335x_BeagleBone_Black_Wireless]
>
> dogtag:[BeagleBoard.org Debian Image 2019-08-03]
>
> bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
> 2019.04-2-gbb4af0f50f]:[location: dd MBR]
>
> kernel:[4.14.108-ti-r113]
>
> nodejs:[v6.17.0]
>
> uboot_overlay_options:[enable_uboot_overlays=1]
>
> uboot_overlay_options:[disable_uboot_overlay_audio=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.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=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
> root=/dev/mmcblk1p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
> net.ifnames=0 rng_core.default_quality=100 quiet]
>
> dmesg | grep remote
>
> [1.313264] remoteproc remoteproc0: wkup_m3 is available
>
> [1.528468] remoteproc remoteproc0: powering up wkup_m3
>
> [1.528581] remoteproc remoteproc0: Booting fw image 
> am335x-pm-firmware.elf, size 217168
>
> [1.532865] remoteproc remoteproc0: remote processor wkup_m3 is now up
>
> dmesg | grep pru
>
> [ 5566.578557] Modules linked in: xt_conntrack ipt_MASQUERADE 
> nf_nat_masquerade_ipv4 aes_arm_bs crypto_simd cryptd wl18xx wlcore mac80211 
> rfcomm bnep hci_uart btqca bluetooth cfg80211 ecdh_generic uio_pruss 
> usb_f_mass_storage usb_f_acm u_serial usb_f_ecm usb_f_rndis u_ether 
> libcomposite bc_example(O) pvrsrvkm(O) iptable_nat nf_conntrack_ipv4 
> nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle 
> iptable_filter snd_usb_audio snd_hwdep snd_usbmidi_lib snd_rawmidi 
> snd_seq_device wlcore_sdio evdev uio_pdrv_genirq uio spidev pruss_soc_bus 
> pru_rproc pruss pruss_intc ip_tables x_tables
>
> [39794.273196] Modules linked in: xt_conntrack ipt_MASQUERADE 
> nf_nat_masquerade_ipv4 aes_arm_bs crypto_simd cryptd wl18xx wlcore mac80211 
> rfcomm bnep hci_uart btqca bluetooth cfg80211 ecdh_generic uio_pruss 
> usb_f_mass_storage usb_f_acm u_serial usb_f_ecm usb_f_rndis u_ether 
> libcomposite bc_example(O) pvrsrvkm(O) iptable_nat nf_conntrack_ipv4 
> nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle 
> iptable_filter snd_usb_audio snd_hwdep snd_usbmidi_lib snd_rawmidi 
> snd_seq_device wlcore_sdio evdev uio_pdrv_genirq uio spidev pruss_soc_bus 
> pru_rproc pruss pruss_intc ip_tables x_tables
>
> dmesg | grep pinctrl-single
>
> [0.949178] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 
> size 568
>
> dmesg | grep gpio-of-helper
>
> [0.961436] gpio-of-helper ocp:cape-universal: ready
>
> lsusb
>
> Bus 001 Device 002: ID 0d8c:0014 C-Media Electronics, Inc.
>
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>
> END
>
> ~
>
>
> ~
>
>
>   
> 26,592All
>
> On Monday, December 7, 2020 at 1:53:24 PM UTC-7, RobertCNelson wrote:
>
>> On Mon, Dec 7, 2020 at 2:43 PM ags  wrote: 
>> > 
>> > @RobertCNelson are there any plans to provide this update as part of a 
>> BBBW package? (any reason to believe it addresses the issue cited above?) 
>> > 
>>
>> ps you have a different issue: 
>>
>> Please run and report this output: 
>>
>> sudo /opt/scripts/tools/version.sh 
>>
>> Regards, 
>>
>> -- 
>> Robert Nelson 
>> https://rcn-e

[beagleboard] Re: wl18xx warning - any resolution?

[jose...@gmail.com]

TI has released recently an updated driver and firmware:

https://github.com/beagleboard/Latest-Images/issues/73

A segunda-feira, 7 de dezembro de 2020 à(s) 11:12:52 UTC, ags escreveu:

> Has there been any progress in understanding the cause, and cure, for the 
> warning message being written to the system log every second (BBBW)?
>
> kernel: *wlcore: WARNING no fw rx ba on tid *
>>
>
> Is there a firmware/driver update available? I just re-flashed my eMMC on a
>
> uname -a
>
> Linux beaglebone 4.14.108-ti-r113 #1 SMP PREEMPT Wed Jul 31 00:01:10 UTC 
> 2019 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/b9a27168-6fa0-442d-a699-9063e18fee2bn%40googlegroups.com.

[beagleboard] Upgrading to Debian 10.7

[jose...@gmail.com]

Hi,

Debian has just released the 10.7 upgrade.
Doing an "apt update" followed by "apt list --upgradable"  in one of my 
BeagleBones, I found that there are a couple of systemd/udev upgrades 
sugested:

libnss-systemd/stable 241-7~deb10u5 armhf [upgradable from: 
241-7~deb10u4rcnee0~buster+20200509]
libpam-systemd/stable 241-7~deb10u5 armhf [upgradable from: 
241-7~deb10u4rcnee0~buster+20200509]
libsystemd0/stable 241-7~deb10u5 armhf [upgradable from: 
241-7~deb10u4rcnee0~buster+20200509]
libudev1/stable 241-7~deb10u5 armhf [upgradable from: 
241-7~deb10u4rcnee0~buster+20200509]
systemd-sysv/stable 241-7~deb10u5 armhf [upgradable from: 
241-7~deb10u4rcnee0~buster+20200509]
systemd/stable 241-7~deb10u5 armhf [upgradable from: 
241-7~deb10u4rcnee0~buster+20200509]
udev/stable 241-7~deb10u5 armhf [upgradable from: 
241-7~deb10u4rcnee0~buster+20200509]

Are these upgrades safe to perform?
My question arises because the BB's systemd packages are originally 
from repos.rcn-ee.com, so I supect they may have some BB specific tweeks.

Best regards,
José Gonçalves

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

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

[jose...@gmail.com]

Hi Robert,

Is there an updated schedule for the next stable image release?
I assume there are some blocking issues that prevented the Summer release 
to took place, inittialy postponed to Fall, acording to the 
Latest-image-testing wiki.
May we know what issues are preventing a new stable release? 

Best regards,
José Gonçalves

A quarta-feira, 2 de setembro de 2020 à(s) 18:21:04 UTC+1, 
jose...@gmail.com escreveu:

> Hi Robert,
>
> The wiki page at https://elinux.org/Beagleboard:Latest-images-testing has 
> some outdated info on the Sumer 2020 Release.
> While the RC2 is marked (properly) has released in August 26, it says the 
> final version was released in August 3rd!
>
> Best regards,
> José Gonçalves
>
> A quarta-feira, 26 de agosto de 2020 à(s) 15:45:24 UTC+1, RobertCNelson 
> escreveu:
>
>> Hi Everyone, 
>>
>> So RC2 is now out, all the "wl18xx" based devices now have working 
>> Bluetooth again, config: CONFIG_SERIAL_SC16IS7XX completely broke it.. 
>>
>> I'm planning to do the "full" burn in testing this Saturday, my targets 
>> are: 
>>
>> Windows 10 (2004) 
>> Debian 
>> Mac OS (Mojave, Catalina) 
>>
>> Here is what i did last 'time' which took about a full day of none stop 
>> testing: 
>>
>> https://github.com/beagleboard/Latest-Images/issues/26 
>>
>> Please reply with more things to verify.. 
>>
>> Now GSOC students, please reply with still un-merged patches and what 
>> kernel they are targeting. I'd like to get all these projects built 
>> and merged by this Thursday, then we can do a final "RC" next week, 
>> that may turn into "FInal".. 
>>
>> Regards, 
>>
>> -- 
>> Robert Nelson 
>> https://rcn-ee.com/ 
>>
>

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

[beagleboard] Re: Configure CAN BeagleBone AI, Kernel v4.19

[jose...@gmail.com]

CAN interfaces are down by default. If you type "*ifconfig -a*" you should 
see them...

A quarta-feira, 14 de outubro de 2020 à(s) 11:45:01 UTC+1, Douglas Conover 
escreveu:

>
> Hi all, I have been working on updating some of my device tree files to 
> the newer image found at:
>
>
> https://rcn-ee.net/rootfs/bb.org/testing/2020-09-07/buster-iot/am57xx-debian-10.5-iot-armhf-2020-09-07-4gb.img.xz
>  
>
> using the device tree files at:
>
>
> https://github.com/beagleboard/BeagleBoard-DeviceTrees/tree/v4.19.x-ti-overlays/src/arm/overlays
>
> I would like to use pins P9.26 and P9.24 for can bus communication. In the 
> previous version of the image (the latest IOT image found at 
> https://beagleboard.org/latest-images), I was able to configure them 
> using a modified version of a sample dts. Looking at the 4.19.x-ti-overlays 
> branch of the device tree overlay repo, I found the BONE-CAN1.dts file, 
> which seemed to do almost exactly the same thing. I built the dtbo and 
> copied it to /boot/dtbs. This is my uEnv.txt:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *uname_r=4.19.94-ti-r50#uuid=#dtb=###U-Boot Overlays##Documentation: 
> http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays 
> ###Master
>  
> Enableenable_uboot_overlays=1##Overide capes with 
> eepromuboot_overlay_addr0=/boot/dtbs/BONE-CAN1.dtbo#uboot_overlay_addr2=.dtbo#uboot_overlay_addr3=.dtbo##Additional
>  
> custom 
> capes#uboot_overlay_addr4=.dtbo#uboot_overlay_addr5=.dtbo#uboot_overlay_addr6=.dtbo#uboot_overlay_addr7=.dtbo##Custom
>  
> Cape#dtb_overlay=.dtbo##Debug: disable uboot autoload of 
> Cape#disable_uboot_overlay_addr0=1#disable_uboot_overlay_addr1=1#disable_uboot_overlay_addr2=1#disable_uboot_overlay_addr3=1##U-Boot
>  
> fdt tweaks... (6 = 384KB)#uboot_fdt_buffer=0x6###U-Boot 
> Overlays###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##enable x15: 
> eMMC Flasher:##make sure, these tools are installed: dosfstools rsync*
>
> On reboot, the show-pins utility (https://github.com/mvduin/bbb-pin-utils) 
> shows that the pins are in the correct mux modes:
>
>
>
>
>
> *debian@beaglebone:/var/lib/cloud9$ show-pins | grep canCaution: Uses 
> peripheral names from >. See 
> README there for details.P9.26b81 
> fast 15 unused   ocp@4400/P9_26_pinmux 
> (pinmux_P9_26_can_pin)P9.26a   162 fast 
> up   2 can 1 tx ocp@4400/P9_26_pinmux 
> (pinmux_P9_26_can_pin)P9.24163 fast rx  
> up   2 can 1 rx ocp@4400/P9_24_pinmux (pinmux_P9_24_can_pin)*
>  
> but ifconfig does not reveal a can interface:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *SoftAp0: flags=4163  mtu 1500inet 
> 192.168.8.1  netmask 255.255.255.0  broadcast 192.168.8.255inet6 
> fe80::200:ff:fe00:0  prefixlen 64  scopeid 0x20ether 
> 00:00:00:00:00:00  txqueuelen 1000  (Ethernet)RX packets 0  bytes 0 
> (0.0 B)RX errors 0  dropped 0  overruns 0  frame 0TX 
> packets 35  bytes 6868 (6.7 KiB)TX errors 0  dropped 0 overruns 0  
> carrier 0  collisions 0eth0: 
> flags=-28605  mtu 1500inet 
> 169.254.25.128  netmask 255.255.0.0  broadcast 169.254.255.255inet6 
> fe80::2aec:9aff:feeb:54d6  prefixlen 64  scopeid 0x20ether 
> 28:ec:9a:eb:54:d6  txqueuelen 1000  (Ethernet)RX packets 72  bytes 
> 16296 (15.9 KiB)RX errors 0  dropped 0  overruns 0  frame 0
> TX packets 114  bytes 31416 (30.6 KiB)TX errors 0  dropped 0 
> overruns 0  carrier 0  collisions 0device interrupt 128lo: 
> flags=73  mtu 65536inet 127.0.0.1  netmask 
> 255.0.0.0inet6 ::1  prefixlen 128  scopeid 0x10loop  
> txqueuelen 1000  (Local Loopback)RX packets 1040  bytes 70800 (69.1 
> KiB)RX errors 0  dropped 0  overruns 0  frame 0TX packets 
> 1040  bytes 70800 (69.1 KiB)TX errors 0  dropped 0 overruns 0  
> carrier 0  collisions 0usb0: flags=4163  
> mtu 1500inet 192.168.7.2  netmask 255.255.255.0  broadcast 
> 192.168.7.255inet6 fe80::1eba:8cff:fea2:ed6b  prefixlen 64  scopeid 
> 0x20ether 1c:ba:8c:a2:ed:6b  txqueuelen 1000  
> (Ethernet)RX packets 418  bytes 63986 (62.4 KiB)RX errors 
> 0  dropped 0  overruns 0  frame 0TX packets 355  bytes 84899 (82.9 
> KiB)TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0usb1: 
> flags=4163  mtu 1500inet 

[beagleboard] Re: Using an external RTC in BBGG

[jose...@gmail.com]

Found it! Just needed to add another alias in the DTS file:

rtc2 = "/ocp/i2c@44e0b000/rtc@68";

and afterwards, my Cape's RTC is used:

debian@bbgg:~$ dmesg | grep rtc
[1.067904] omap_rtc 44e3e000.rtc: already running
[1.068392] omap_rtc 44e3e000.rtc: registered as rtc1
[1.132459] rtc-ds1307 0-0068: registered as rtc2
[1.172017] rtc-pcf2127-i2c 1-0051: rtc core: registered rtc-pcf2127-i2c 
as rtc0
[1.178840] rtc-pcf2127-i2c 1-0051: setting system clock to 2020-09-27 
07:40:07 UTC (1601192407)


A sexta-feira, 25 de setembro de 2020 à(s) 18:42:26 UTC+1, 
jose...@gmail.com escreveu:

> Hi,
>
> I have a custom Cape that has a PCF2129 RTC chip.
> I've set a device tree overlay like this:
>
> &{/} {
> aliases {
> rtc0 = &extrtc;
> rtc1 = "/ocp/rtc@44e3e000";
> };
> };
>
> &i2c1 {
> extrtc: pcf2129@51 {
> compatible = "nxp,pcf2129";
> reg = <0x51>;
> };
> }
>
> and this setup works fine in a BB Green Wireless:
>
> debian@bbgw:~$ dmesg | grep rtc
> [1.032100] omap_rtc 44e3e000.rtc: already running
> [1.032598] omap_rtc 44e3e000.rtc: registered as rtc1
> [1.133896] rtc-pcf2127-i2c 1-0051: rtc core: registered 
> rtc-pcf2127-i2c as rtc0
> [1.140557] rtc-pcf2127-i2c 1-0051: setting system clock to 2020-09-25 
> 15:27:03 UTC (1601047623)
>
> Nevertheless, trying to use that Cape in a BB Green Gateway (that has 
> another RTC builtin), I'm unable to set the Cape's RTC as default, because 
> it's set as rtc2, instead of rtc0 (using the same overlay file):
>
>  debian@bbgg:~$ dmesg | grep rtc
> [1.084958] omap_rtc 44e3e000.rtc: already running
> [1.085461] omap_rtc 44e3e000.rtc: registered as rtc1
> [1.152108] rtc-ds1307 0-0068: registered as rtc0
> [1.187459] rtc-pcf2127-i2c 1-0051: oscillator stop detected, date/time 
> is not reliable
> [1.187691] rtc-pcf2127-i2c 1-0051: rtc core: registered 
> rtc-pcf2127-i2c as rtc2
> [1.194605] rtc-ds1307 0-0068: setting system clock to 2020-09-25 
> 17:23:30 UTC (1601054610)
>
> Is there any way that I could setup my Cape's DTS file in order the Cape's 
> RTC is used  on a BB Green Gateway?
>
> Best regards,
> José Gonçalves
>

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

[beagleboard] Using an external RTC in BBGG

[jose...@gmail.com]

Hi,

I have a custom Cape that has a PCF2129 RTC chip.
I've set a device tree overlay like this:

&{/} {
aliases {
rtc0 = &extrtc;
rtc1 = "/ocp/rtc@44e3e000";
};
};

&i2c1 {
extrtc: pcf2129@51 {
compatible = "nxp,pcf2129";
reg = <0x51>;
};
}

and this setup works fine in a BB Green Wireless:

debian@bbgw:~$ dmesg | grep rtc
[1.032100] omap_rtc 44e3e000.rtc: already running
[1.032598] omap_rtc 44e3e000.rtc: registered as rtc1
[1.133896] rtc-pcf2127-i2c 1-0051: rtc core: registered rtc-pcf2127-i2c 
as rtc0
[1.140557] rtc-pcf2127-i2c 1-0051: setting system clock to 2020-09-25 
15:27:03 UTC (1601047623)

Nevertheless, trying to use that Cape in a BB Green Gateway (that has 
another RTC builtin), I'm unable to set the Cape's RTC as default, because 
it's set as rtc2, instead of rtc0 (using the same overlay file):

 debian@bbgg:~$ dmesg | grep rtc
[1.084958] omap_rtc 44e3e000.rtc: already running
[1.085461] omap_rtc 44e3e000.rtc: registered as rtc1
[1.152108] rtc-ds1307 0-0068: registered as rtc0
[1.187459] rtc-pcf2127-i2c 1-0051: oscillator stop detected, date/time 
is not reliable
[1.187691] rtc-pcf2127-i2c 1-0051: rtc core: registered rtc-pcf2127-i2c 
as rtc2
[1.194605] rtc-ds1307 0-0068: setting system clock to 2020-09-25 
17:23:30 UTC (1601054610)

Is there any way that I could setup my Cape's DTS file in order the Cape's 
RTC is used  on a BB Green Gateway?

Best regards,
José Gonçalves

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

[beagleboard] Re: Syntax highlight in nano

[jose...@gmail.com]

Have you installed the full *vim* version ?

$ sudo apt install vim

By default, some Debian images only have installed the *vim-tiny* package, 
that does not have support to syntax highlight.

Other thing that may affect the presentation of color is the usage of a 
serial terminal.
If you can, login via SSH to test if, in this way, you get colors on your 
terminal.

A terça-feira, 8 de setembro de 2020 à(s) 08:38:06 UTC+1, 
py.o...@sunrise.ch escreveu:

> Thanks.
> I edited */etc/vim/vimrc*.
> Here is what I get.
> Where are colors in this so-called highlighting.
> Regards,
> Pavel.
>
> [image: Screenshot from 2020-09-08 09-34-18.png]
>
>
> On Monday, September 7, 2020 at 4:19:58 PM UTC+2, jose...@gmail.com wrote:
>>
>> If you provide appropriate config, *vim* will give you syntax highlight.
>> I always add in my boards the following config in */etc/vim/vimrc.local*:
>>
>> let g:skip_defaults_vim = 1
>> syntax on
>> set background=dark
>> set modeline
>> set modelines=3
>> set mouse=
>>
>> BR,
>> José Gonçalves
>>
>> A segunda-feira, 7 de setembro de 2020 à(s) 14:02:32 UTC+1, 
>> py.o...@sunrise.ch escreveu:
>>
>>> BTW, the *vim* editor does not provide syntax highlighting either.
>>>
>>>
>>> On Monday, September 7, 2020 at 1:41:44 PM UTC+2, Pavel Yermolenko wrote:
>>>>
>>>> In the file */etc/nanorc *there is following line:
>>>>
>>>> ## To include all existing syntax definitions, you can do:
>>>> include "/usr/share/nano/*.nanorc"
>>>>
>>>> Here is the content of */usr/share/nano/*:
>>>>
>>>> debian@beaglebone:~$ ls /usr/share/nano/ -l
>>>> total 180
>>>> -rw-r--r-- 1 root root  882 Jun 12  2019 asm.nanorc
>>>> -rw-r--r-- 1 root root  555 Jun 12  2019 autoconf.nanorc
>>>> -rw-r--r-- 1 root root 1342 Jun 12  2019 awk.nanorc
>>>> -rw-r--r-- 1 root root  712 Jun 12  2019 changelog.nanorc
>>>> -rw-r--r-- 1 root root  788 Jun 12  2019 cmake.nanorc
>>>> -rw-r--r-- 1 root root 1748 Jun 12  2019 c.nanorc
>>>> -rw-r--r-- 1 root root  344 Jun 12  2019 css.nanorc
>>>> -rw-r--r-- 1 root root  757 Jun 12  2019 debian.nanorc
>>>> -rw-r--r-- 1 root root  414 Jun 12  2019 default.nanorc
>>>> -rw-r--r-- 1 root root 1108 Jun 12  2019 elisp.nanorc
>>>> -rw-r--r-- 1 root root 1967 Jun 12  2019 fortran.nanorc
>>>> -rw-r--r-- 1 root root 4226 Jun 12  2019 gentoo.nanorc
>>>> -rw-r--r-- 1 root root 1317 Jun 12  2019 go.nanorc
>>>> -rw-r--r-- 1 root root  710 Jun 12  2019 groff.nanorc
>>>> -rw-r--r-- 1 root root  587 Jun 12  2019 guile.nanorc
>>>> -rw-r--r-- 1 root root 1211 Jun 12  2019 html.nanorc
>>>> -rw-r--r-- 1 root root  653 Jun 12  2019 java.nanorc
>>>> -rw-r--r-- 1 root root  763 Jun 12  2019 javascript.nanorc
>>>> -rw-r--r-- 1 root root  878 Jun 12  2019 json.nanorc
>>>> -rw-r--r-- 1 root root 2459 Jun 12  2019 lua.nanorc
>>>> -rw-r--r-- 1 root root  535 Jun 12  2019 makefile.nanorc
>>>> -rw-r--r-- 1 root root  453 Jun 12  2019 man.nanorc
>>>> -rw-r--r-- 1 root root  198 Jun 12  2019 mgp.nanorc
>>>> -rw-r--r-- 1 root root  185 Jun 12  2019 mutt.nanorc
>>>> -rw-r--r-- 1 root root  388 Jun 12  2019 nanohelp.nanorc
>>>> -rw-r--r-- 1 root root 2675 Jun 12  2019 nanorc.nanorc
>>>> -rw-r--r-- 1 root root  791 Jun 12  2019 nftables.nanorc
>>>> -rw-r--r-- 1 root root 1696 Jun 12  2019 objc.nanorc
>>>> -rw-r--r-- 1 root root  859 Jun 12  2019 ocaml.nanorc
>>>> -rw-r--r-- 1 root root  590 Jun 12  2019 patch.nanorc
>>>> -rw-r--r-- 1 root root 1457 Jun 12  2019 perl.nanorc
>>>> -rw-r--r-- 1 root root 1070 Jun 12  2019 php.nanorc
>>>> -rw-r--r-- 1 root root  919 Jun 12  2019 po.nanorc
>>>> -rw-r--r-- 1 root root 3046 Jun 12  2019 postgresql.nanorc
>>>> -rw-r--r-- 1 root root  632 Jun 12  2019 pov.nanorc
>>>> -rw-r--r-- 1 root root 1199 Jun 12  2019 python.nanorc
>>>> -rw-r--r-- 1 root root 1506 Jun 12  2019 ruby.nanorc
>>>> -rw-r--r-- 1 root root 1116 Jun 12  2019 rust.nanorc
>>>> -rw-r--r-- 1 root root 1489 Jun 12  2019 sh.nanorc
>>>> -rw-r--r-- 1 root root 1924 Jun 12  2019 spec.nanorc
>>>> -rw-r--r-- 1 root root 2181 Jun 12  2019 tcl.nanorc
>>>> -rw-r--r-- 1 root root  463 Jun 12  2019 texinfo.nanorc
>>>> -rw-r--r-- 1 root root  200 Jun 12  2019 tex.nanorc
>>>> -rw-r--r-- 1 root root  527 Jun 12  2019 xml.nanor

[beagleboard] Re: Syntax highlight in nano

[jose...@gmail.com]

If you provide appropriate config, *vim* will give you syntax highlight.
I always add in my boards the following config in */etc/vim/vimrc.local*:

let g:skip_defaults_vim = 1
syntax on
set background=dark
set modeline
set modelines=3
set mouse=

BR,
José Gonçalves

A segunda-feira, 7 de setembro de 2020 à(s) 14:02:32 UTC+1, 
py.o...@sunrise.ch escreveu:

> BTW, the *vim* editor does not provide syntax highlighting either.
>
>
> On Monday, September 7, 2020 at 1:41:44 PM UTC+2, Pavel Yermolenko wrote:
>>
>> In the file */etc/nanorc *there is following line:
>>
>> ## To include all existing syntax definitions, you can do:
>> include "/usr/share/nano/*.nanorc"
>>
>> Here is the content of */usr/share/nano/*:
>>
>> debian@beaglebone:~$ ls /usr/share/nano/ -l
>> total 180
>> -rw-r--r-- 1 root root  882 Jun 12  2019 asm.nanorc
>> -rw-r--r-- 1 root root  555 Jun 12  2019 autoconf.nanorc
>> -rw-r--r-- 1 root root 1342 Jun 12  2019 awk.nanorc
>> -rw-r--r-- 1 root root  712 Jun 12  2019 changelog.nanorc
>> -rw-r--r-- 1 root root  788 Jun 12  2019 cmake.nanorc
>> -rw-r--r-- 1 root root 1748 Jun 12  2019 c.nanorc
>> -rw-r--r-- 1 root root  344 Jun 12  2019 css.nanorc
>> -rw-r--r-- 1 root root  757 Jun 12  2019 debian.nanorc
>> -rw-r--r-- 1 root root  414 Jun 12  2019 default.nanorc
>> -rw-r--r-- 1 root root 1108 Jun 12  2019 elisp.nanorc
>> -rw-r--r-- 1 root root 1967 Jun 12  2019 fortran.nanorc
>> -rw-r--r-- 1 root root 4226 Jun 12  2019 gentoo.nanorc
>> -rw-r--r-- 1 root root 1317 Jun 12  2019 go.nanorc
>> -rw-r--r-- 1 root root  710 Jun 12  2019 groff.nanorc
>> -rw-r--r-- 1 root root  587 Jun 12  2019 guile.nanorc
>> -rw-r--r-- 1 root root 1211 Jun 12  2019 html.nanorc
>> -rw-r--r-- 1 root root  653 Jun 12  2019 java.nanorc
>> -rw-r--r-- 1 root root  763 Jun 12  2019 javascript.nanorc
>> -rw-r--r-- 1 root root  878 Jun 12  2019 json.nanorc
>> -rw-r--r-- 1 root root 2459 Jun 12  2019 lua.nanorc
>> -rw-r--r-- 1 root root  535 Jun 12  2019 makefile.nanorc
>> -rw-r--r-- 1 root root  453 Jun 12  2019 man.nanorc
>> -rw-r--r-- 1 root root  198 Jun 12  2019 mgp.nanorc
>> -rw-r--r-- 1 root root  185 Jun 12  2019 mutt.nanorc
>> -rw-r--r-- 1 root root  388 Jun 12  2019 nanohelp.nanorc
>> -rw-r--r-- 1 root root 2675 Jun 12  2019 nanorc.nanorc
>> -rw-r--r-- 1 root root  791 Jun 12  2019 nftables.nanorc
>> -rw-r--r-- 1 root root 1696 Jun 12  2019 objc.nanorc
>> -rw-r--r-- 1 root root  859 Jun 12  2019 ocaml.nanorc
>> -rw-r--r-- 1 root root  590 Jun 12  2019 patch.nanorc
>> -rw-r--r-- 1 root root 1457 Jun 12  2019 perl.nanorc
>> -rw-r--r-- 1 root root 1070 Jun 12  2019 php.nanorc
>> -rw-r--r-- 1 root root  919 Jun 12  2019 po.nanorc
>> -rw-r--r-- 1 root root 3046 Jun 12  2019 postgresql.nanorc
>> -rw-r--r-- 1 root root  632 Jun 12  2019 pov.nanorc
>> -rw-r--r-- 1 root root 1199 Jun 12  2019 python.nanorc
>> -rw-r--r-- 1 root root 1506 Jun 12  2019 ruby.nanorc
>> -rw-r--r-- 1 root root 1116 Jun 12  2019 rust.nanorc
>> -rw-r--r-- 1 root root 1489 Jun 12  2019 sh.nanorc
>> -rw-r--r-- 1 root root 1924 Jun 12  2019 spec.nanorc
>> -rw-r--r-- 1 root root 2181 Jun 12  2019 tcl.nanorc
>> -rw-r--r-- 1 root root  463 Jun 12  2019 texinfo.nanorc
>> -rw-r--r-- 1 root root  200 Jun 12  2019 tex.nanorc
>> -rw-r--r-- 1 root root  527 Jun 12  2019 xml.nanorc
>> debian@beaglebone:~$ 
>>
>> But there is no syntax coloring for any of languages.
>> Where is the problem ?
>> Thanks
>>
>> On Friday, September 4, 2020 at 4:35:23 PM UTC+2, Pavel Yermolenko wrote:
>>
>>> Hello,
>>>
>>> How to add syntax highlighting in nano ?
>>> I created file *.nanorc* and added there
>>>
>>> include /usr/share/nano/java.nanorc
>>>
>>> But it didn't work.
>>> 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/c59dc0ac-99d2-46de-828f-96e300f63653n%40googlegroups.com.

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

[jose...@gmail.com]

Hi Robert,

The wiki page at https://elinux.org/Beagleboard:Latest-images-testing has 
some outdated info on the Sumer 2020 Release.
While the RC2 is marked (properly) has released in August 26, it says the 
final version was released in August 3rd!

Best regards,
José Gonçalves

A quarta-feira, 26 de agosto de 2020 à(s) 15:45:24 UTC+1, RobertCNelson 
escreveu:

> Hi Everyone,
>
> So RC2 is now out, all the "wl18xx" based devices now have working
> Bluetooth again, config: CONFIG_SERIAL_SC16IS7XX completely broke it..
>
> I'm planning to do the "full" burn in testing this Saturday, my targets 
> are:
>
> Windows 10 (2004)
> Debian
> Mac OS (Mojave, Catalina)
>
> Here is what i did last 'time' which took about a full day of none stop 
> testing:
>
> https://github.com/beagleboard/Latest-Images/issues/26
>
> Please reply with more things to verify..
>
> Now GSOC students, please reply with still un-merged patches and what
> kernel they are targeting. I'd like to get all these projects built
> and merged by this Thursday, then we can do a final "RC" next week,
> that may turn into "FInal"..
>
> Regards,
>
> -- 
> Robert Nelson
> https://rcn-ee.com/
>

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