[beagleboard] Syntax error in update_kernel.sh ?
While trying to update one of my boards, I received the following error: root@test1:/opt/scripts/tools# uname -a Linux test1 4.4.13-bone-rt-r11 #1 PREEMPT RT Sat Jun 11 08:59:59 UTC 2016 armv7l GNU/Linux root@test1:/opt/scripts/tools# ./update_kernel.sh --bone-rt-kernel --lts-4_4 ./update_kernel.sh: 615: ./update_kernel.sh: Syntax error: "}" unexpected (expecting ";;") This occurred just after doing the "git pull", so it should be the current version. Thanks, Tim -- 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/f49127f8-b77b-46e9-b88b-4cb932da7e28%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] BBGW uEnv.txt: 2 lines that work on BBB fail to boot on BBGW
When I uncomment "#dtb=am335x-boneblack-emmc-overlay.dtb" and add a line for BB-SPIDEV1 as follows: #Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0 uname_r=4.4.38-bone-rt-r14 ###uuid= #dtb= ##BeagleBone Black/Green dtb's for v4.1.x (BeagleBone White just works..) ##BeagleBone Black: HDMI (Audio/Video) disabled: dtb=am335x-boneblack-emmc-overlay.dtb cape_enable=bone_capemgr.enable_partno=BB-SPIDEV1 ... (nothing is changed beyond this point) The system appears to fail during boot. This has worked for a long time on the BBB and I'm trying to move a running application to the BBGW. root@bbgw:/home/cd5# uname -a Linux bbgw 4.4.38-bone-rt-r14 #1 PREEMPT RT Mon Dec 12 10:10:25 UTC 2016 armv7l GNU/Linux I have also tried to use config-pin, but I haven't been able to find any documentation that will allow me to work through the problems. For example: cd5@bbgw:~$ sudo ./config-pin P8_18 low P8_18 pinmux file not found! cape-universala overlay not found run "config-pin overlay cape-universala" to load the cape root@bbgw:/home/cd5# ./config-pin overlay cape-universala Loading cape-universala overlay root@bbgw:/home/cd5# ./config-pin overlay BB-SPIDEV1 Loading BB-SPIDEV1 overlay bash: line 0: echo: write error: File exists Error loading device tree overlay file: BB-SPIDEV1 It appears that cape-universala loads both spidev0 and spidev1 - I need the spidev0 pins available for gpio Trying to push on: root@bbgw:/home/cd5# ./config-pin -l p8_18 default gpio gpio_pu gpio_pd root@bbgw:/home/cd5# ./config-pin -i p8_18 Pin name: P8_18 Function if no cape loaded: gpio Function if cape loaded: default gpio gpio_pu gpio_pd Function information: gpio2_1 default gpio2_1 gpio2_1 gpio2_1 Cape: cape-universala cape-universal cape-universaln Kernel GPIO id: 65 PRU GPIO id: 97 root@bbgw:/home/cd5# ./config-pin -q p8_18 Cannot read pinmux file: /sys/devices/platform/ocp/ocp*P8_18_pinmux/state I can't see where to go from here except to post this hoping that someone can help with either the uEnv.txt problem or the config-pin problems. When all is configured properly I should have spidev1 (the second spi bus) enabled along with a long list of gpios needed for the application. Thanks in advance, Tim -- 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/1546c704-46ee-41b3-8f01-ec0dbafcada6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] BBGW uEnv.txt: 2 lines that work on BBB fail to boot on BBGW
Hello William, thank you for the prompt response. First of all, I have to say that I have very little experience with the device tree, although I did use dtb-rebuilder to enable SPI back in the linux v3.8 days. So, my first request is: please point me to documentation that is current and helpful for dealing with the device tree. *I have now retested with only one change. If I include "dtb=am335x-boneblack-emmc-overlay.dtb" the boot fails.* This feels like a bug that would be a problem for any BBGW user who has a need for more than a few gpios. I started with "BBB-blank-debian-8.6-console-armhf-2016-11-27-2gb.img" and then: - - apt-get update - apt-get install git - update_kernel.sh --bone-rt-kernel --lts-4_4 - reboot - apt-get upgrade - reboot - apt-get install bb-wl18xx-firmware firmware-ti-connectivity connman - at this point I setup wifi and it was working correctly - apt-get install avahi-daemon avahi-autoipd avahi-utils hostapd curl build-essential I was rebooting after each significant step and all was working correctly. I copied this to a uSD card and hen I made the change to uEnv.txt and rebooted. The "hearbeat" was running, but nothing else was functioning. If I restore from the uSD (without the change to uEnv.txt) it all works. In /boot/dtbs I find: cd5@bbgw:/boot/dtbs/4.4.38-bone-rt-r14$ ls -l *bonegreen* -rw-r--r-- 1 root root 54771 Dec 12 02:22 am335x-bonegreen-overlay.dtb -rw-r--r-- 1 root root 57391 Dec 12 02:22 am335x-bonegreen-wireless.dtb -rw-r--r-- 1 root root 54742 Dec 12 02:22 am335x-bonegreen.dtb Thanks, Tim -- 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/b5d971d3-3abd-482e-8737-27d1e064510c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] BBGW uEnv.txt: 2 lines that work on BBB fail to boot on BBGW
Your intuition seems to be very good. After much testing, I now can see that as soon as I enable "dtb=am335x-boneblack-emmc-overlay.dtb" and reboot, the system does come up but wlan0 is no longer known. By that I mean that "ifconfig -a" and "connmanctl technologies" both fail to list it. The odd thing is that having setup wlan0 with connmanctl, it does come up and run and I can login (although it may quit after awhile). Yes, I can read the dts files fairly easily. The problem is knowing which overlays are included for a given device. Between the problems mentioned above and the failures that I'm seeing trying to use config-pin to setup the gpios, I guess I'm wondering if there is anyone who is actively working on getting the BBGW DT running. This is supposed to be a simple port of an existing application to the BBGW because we don't need hdmi and would like to add wifi. Of course, the desire is to reduce cost as well. If there is anyone working on the DT issues for the BBGW, I would appreciate a note. If I don't hear soon, I will simply recommend that we move to the BBBW instead. Thanks, Tim -- 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/18185346-24a7-4cf7-a64d-a7476dc621ab%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Did wifi configuration change between 3.8 and 4.08? Need help
I have had wireless working on a 3.8 BBB for quite some time and I wanted to move to a v4 kernel in the hope that the "lagginess" of the wifi connection would be reduced. I loaded another board with the LTS RT v4 kernel, did apt-get install wireless-tools wireless-regdb crda, and put my ssid and passphrase in /etc/network/interfaces. The results are: root@beaglebone:~# ifup -vv wlan0 Configuring interface wlan0=wlan0 (inet) run-parts --exit-on-error --verbose /etc/network/if-pre-up.d run-parts: executing /etc/network/if-pre-up.d/wireless-tools dhclient -v -pf /run/dhclient.wlan0.pid -lf /var/lib/dhcp/dhclient.wlan0.leases wlan0 Internet Systems Consortium DHCP Client 4.3.1 Copyright 2004-2014 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Listening on LPF/wlan0/c4:6e:1f:10:0e:70 Sending on LPF/wlan0/c4:6e:1f:10:0e:70 Sending on Socket/fallback DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 5 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 7 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 16 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 9 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 19 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 5 No DHCPOFFERS received. No working leases in persistent database - sleeping. I must have missed something. I even copied the interfaces file over from the 3.8 machine, but no joy. Of course, I also went from Wheezy to Jessie. The hardware is a TP-Link WN722N (Atheros) that I haven't had any problems with - in fact it does an "iwlist wlan0 scan" just fine in the new machine. This seems to a software problem. It is interesting that even after installing crda and wireless-regdb, dmesg shows: [ 10.512066] ath: EEPROM indicates we should expect a country code [ 10.512073] ath: doing EEPROM country->regdmn map search [ 10.512079] ath: country maps to regdmn code: 0x52 [ 10.512085] ath: Country alpha2 being used: CN [ 10.512090] ath: Regpair used: 0x52 [ 10.552110] ieee80211 phy0: Atheros AR9271 Rev:1 [ 10.638305] cfg80211: Regulatory domain changed to country: CN To be complete, ifconfig shows: wlan0 Link encap:Ethernet HWaddr c4:6e:1f:10:0e:70 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) and iwconfig wlan0 shows: wlan0 IEEE 802.11bgn ESSID:off/any Mode:Managed Access Point: Not-Associated Tx-Power=20 dBm Retry short limit:7 RTS thr:off Fragment thr:off Encryption key:off Power Management:off and this is the interfaces file: auto wlan0 iface wlan0 inet dhcp wpa-ssid "my_ssid" wpa-psk "my_passphrase" I would appreciate any help that you can provide, Tim -- 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. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Getting control of the lcd pins on P8
I'm working on a project that needs quite a few gpio's and we initially chose to use the lcd pins on P8 because we are running headless. Currently, we are running: Linux beaglebone 4.1.17-bone-rt-r18 #1 Mon Feb 1 07:40:21 UTC 2016 armv7l GNU/Linux (because we used "--bone-rt-kernel --lts-4_1"). When I try toggling the first few pins in the nxp_hdmi_bonelt_pins (on Derek Molloy's spreadsheet), they don't respond. In particular, P8_27 - P8_30 don't change. We originally built a custom dtb using dtb-rebuilder, but that seems to have been removed. So, we cloned https://github.com/beagleboard/bb.org-overlays and don't know where to go from there. -- 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. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: Getting control of the lcd pins on P8
Sorry, false alarm. Somebody :-( had the wrong base dtb enabled. Once we had "dtb=am335x-boneblack-emmc-overlay.dtb" enabled, it worked. I apologize for the noise. -- 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. For more options, visit https://groups.google.com/d/optout.
[beagleboard] BBB SPI: 6 cs signals needed
Hello, I need to address six devices on a single spi bus, and I'm hoping to avoid writing a device driver :-) We will be updating from 3.8.13-bone68 as soon as there is a stable release of a newer kernel. So far, my research hasn't turned up any indication that spidev can support the use of additional gpis's for this purpose. Will this be true with the new kernel? Has anyone addressed this? Thanks for your help, Tim -- 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. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: BBB SPI: 6 cs signals needed
Nic Cyn, thanks for the response. This summarizes what I had seen, but I wasn't sure that my interpretation was correct. It looks like we will go with wrapping the transfer with our own GPIO toggles. Unfortunately, we won't be using c# but I was looking at your code and noticed: /// Also NOTE that if you use the GPIO based slave select lines you cannot /// also connect anything to the SPI devices internal CS0 or CS1 slave select /// lines. These will always be activated on every write irregardless /// of the GPIO based slave select also asserted. This is just the way the /// SPIDev driver works. I see "SPI_NO_CS" defined in spidev.h, but I don't see any reference to it in spi-omap2-mcspi.c - is that the reason for your comment? Thanks again, Tim On Friday, January 23, 2015 at 6:14:14 AM UTC-8, Nic Cyn wrote: > > SPIDev will never be able to do this with any kernel. The BBB has two SPI > ports and each are theoretically capable of a maximum of 4 CS lines each. > However only two CS lines on each port are made available to the pinmux and > of those two I am pretty sure second CS line on SPI0 has not been brought > out to the P8 or P9 headers by the designers of the BBB. > > The upshot is that using the internal CS lines, which is what SPIDev does, > you can have a max of one device on SPI0 and two on SPI1. Also note that > SPI1 conflicts with the HDMI device and so to enable it you need to disable > the HDMI display. None of this is SPIDev's doing - it is just supporting > the hardware state it is given. > > So if you want more CS lines you need to ignore the internal CS lines and > simulate them with GPIO's. The BBBCSIO library has transparent support for > this but it is intended for mono/C# and needs the BBB to be running an > armhf kernel. You may find there are Python libraries which can do this too. > > BBBCSIO (in case you need the link): > http://ofitselfso.com/BBBCSIO/BBBCSIO.php > > > On Thursday, 22 January 2015 19:18:05 UTC, codemonkey wrote: >> >> Hello, I need to address six devices on a single spi bus, and I'm hoping >> to avoid writing a device driver :-) >> >> We will be updating from 3.8.13-bone68 as soon as there is a stable >> release of a newer kernel. So far, my research hasn't turned up any >> indication that spidev can support the use of additional gpis's for this >> purpose. >> >> Will this be true with the new kernel? Has anyone addressed this? >> >> Thanks for your help, >> Tim >> > -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Kernel 4.1.9 overlays not working
Robert, I have the same question about the source of DTC 1.4.1-gXYZXYZXYZ - I installed the device-tree-overlay package into a new build (Linux beaglebone 4.1.10-bone-rt-r16 #1 Sun Oct 4 09:05:14 UTC 2015 armv7l GNU/Linux) and checked the version of dtc. It was v1.4.0. I tried running ./dtc_overlay.sh, but the version didn't change. So, I cloned the git repository of the source at devicetree.org, did a make and make install. The version is still 1.4.0. The only reference Google has to the string in your readme (DTC 1.4.1-gXYZXYZXYZ) points to your readme. Thank you Tim On Tuesday, October 13, 2015 at 8:23:00 AM UTC-7, RobertCNelson wrote: > > On Tue, Oct 13, 2015 at 10:20 AM, Lee Armstrong > wrote: > > Thanks Robert, > > > > I’ve just reflashed it again with the latest Jessie image and will run > > through those steps. > > > > One thing not 100% clear in the steps is the best location to get the > latest > > (patched) DTC, there are many differing sources it seems! > > I moved the "./dtc-overlay.sh" script right after the "check dtc" in > step 2... I'm hoping it should be more obvious to run it.. > > 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. For more options, visit https://groups.google.com/d/optout.
