[beagleboard] Re: bbgw wlan0 users
I brought a Beaglebone Green Wireless. At the first day, its wifi worked, so I did some apt-get update/upgrade/dis-upgrade. My main purpose is to use it to do some python work. UART/I2C/GPIO etc. So I didn't discover that the wifi no longer working after the apt-get upgrade. I spent two working days trying to make its wifi working again, but no success. I didn't record the version info of the original working Debian. And I can't find the pre-load image from https://debian.beagleboard.org/images/ What I can find are: bone-debian-8.5-seeed-gcp-iot-armhf-2016-08-26-4gb.img.xz - failed to boot bone-debian-8.6-iot-armhf-2016-12-09-4gb.img.xz - failed to boot bone-debian-8.6-seeed-iot-armhf-2016-11-06-4gb.img.xz - wifi doesn't work I also tried to use the kernel in *-iot-armhf-2016-12-09-* with * seeed-iot-armhf-2016-11-06*, but no success. (By changing uname_r of uEnv.txt, and even by renaming the files.) After all these I found a thread in TI E2E: https://e2e.ti.com/support/wireless_connectivity/wilink_wifi_bluetooth/f/307/p/541235/1978301 So I guess it's a hardware problem, but without wifi, there is no internet connection on BBGW, then I am not able to install python packages, my BBGW becomes useless. And I guess the below images are not for BBGW. https://rcn-ee.net/rootfs/2016-11-10/microsd/ Is there any work-around available for a general user? Thank you for your patience. Juliusz Chroboczek於 2016年11月19日星期六 UTC+8下午2時15分25秒寫道: > > > Okay, 4.4.22-ti-r49 has hit the repo: > > I can no longer reproduce the issue with 4.4.32-ti-r68. Thanks a lot, > Nelson. > > -- Juliusz > > -- 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/af37e7ea-67d3-4ced-8195-e61bcc4c6e8e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: bbgw wlan0 users
On Fri, Dec 30, 2016 at 2:37 AM, Linq John wrote: > > I brought a Beaglebone Green Wireless. > At the first day, its wifi worked, so I did some apt-get > update/upgrade/dis-upgrade. > My main purpose is to use it to do some python work. UART/I2C/GPIO etc. > So I didn't discover that the wifi no longer working after the apt-get > upgrade. > I spent two working days trying to make its wifi working again, but no > success. > I didn't record the version info of the original working Debian. > And I can't find the pre-load image from > https://debian.beagleboard.org/images/ > What I can find are: > bone-debian-8.5-seeed-gcp-iot-armhf-2016-08-26-4gb.img.xz - failed to boot > bone-debian-8.6-iot-armhf-2016-12-09-4gb.img.xz - failed to boot > bone-debian-8.6-seeed-iot-armhf-2016-11-06-4gb.img.xz - wifi doesn't work > I also tried to use the kernel in *-iot-armhf-2016-12-09-* with > *seeed-iot-armhf-2016-11-06*, but no success. > (By changing uname_r of uEnv.txt, and even by renaming the files.) > After all these I found a thread in TI E2E: > https://e2e.ti.com/support/wireless_connectivity/wilink_wifi_bluetooth/f/307/p/541235/1978301 > So I guess it's a hardware problem, but without wifi, there is no internet > connection on BBGW, > then I am not able to install python packages, my BBGW becomes useless. > > And I guess the below images are not for BBGW. > https://rcn-ee.net/rootfs/2016-11-10/microsd/ > > Is there any work-around available for a general user? Use this build: https://rcn-ee.net/rootfs/bb.org/testing/2016-12-27/ 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/CAOCHtYhzVm-wEkPD4vFZi51RQwnKfd6Mbx5WCae6q39EjRhtMg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] v4.4.x-ti changes
r78: normal/rt/xenomai: added: module flag, so u-boot can tell bone_capemgr overlay has already been loaded (by u-boot) bone_capemgr.uboot_capemgr_enabled=0 (default condition) kernel auto loads overlays bone_capemgr.uboot_capemgr_enabled=1 = U-Boot already loaded overlay xenomai: disabled cpu_idle uio_pruss by default (for machinekit uio_pruss stack) 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/CAOCHtYhXggrAxik8RcDp-6RqzJ0qiqFpTPoC%3DTJqHTY47y2KtQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: Cape Manager for U-Boot
Okay, time to push it out as default... First stable build is: U-Boot SPL 2017.01-rc2-3-ga4c7d45040 (Dec 30 2016 - 11:30:57) Trying to boot from MMC1 U-Boot 2017.01-rc2-3-ga4c7d45040 (Dec 30 2016 - 11:30:57 -0600), Build: jenkins-github_Bootloader-Builder-497 This includes a U-Boot overlays disabled by default, end user has to enable in /boot/uEnv.txt overide.. Doc's: to enable this new feature, set enable_boot_overlays in /boot/uEnv.txt enable_uboot_overlays=1 First 4 slots are then auto-loaded 5th slot, can be set by user dtb_overlay=/lib/firmware/*.dtbo Works best with a r78 based v4.4.x kernel.. 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/CAOCHtYjTfx9faU0Wacn3gAk78r4AL%3DYkW%2Bd1uoy4%3DQO%2Bzdi7cQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] SPI on new BBBW with current image
I'm posting this here hoping to save others some frustration/pain that I've gone through trying to get SPI working on the beagle bone black wireless. The documentation for this is a shambles currently, with conflicting and out of date information all over the internet. So, for those who find this post via google, let me explain what's going on and how we got to here. SPI on the BBB is actually really easy, it just may not seem like it. Ok, for starters when you google this, you've probably found a bunch of information on dts, overlays, capemgr, slots, etc... I'll take a sec to explain the history of this first. So, linux traditionally used kernel modules (drivers) for every piece of hardware that you might want to use. This strategy didn't work very well when all these ARM devices like the beagle bone started showing up because there were so many devices with different configurations, and it really didn't make sense to add all that to the kernel. As a solution to this, Linus came up with this idea for a level of abstraction called a device tree. The device tree is basically a way to describe the mapping and purpose of physical hardware to the kernel. This is done via a 'dts' file, which is a source code file that lists the specific properties of the hardware. This source code file is compiled into a binary that the kernel can understand, a 'dtb' or 'dtbo' file. So, early on in beagle bone history, this was how things were done. There were lots of dts and dtbo files that were made for all sorts of different purposes, and you, as the user could swap these out depending on how you want pins configured. You can also create your own. This is where some of the older articles you see that have instructions about creating a dts file and compiling it to enable SPI come from. Well, that whole thing was pretty spiffy, but there were some drawbacks. One, it wasn't very approachable for new folks. You basically had to learn a new language and toolchain just to configure pins. While better than writing a kernel module, that still wasn't great. Also, all of this configuration happened at boot time, so every time you wanted to make a change you had to reboot. This really doesn't work well for a device where you want to be able to hot swap extension boards and reconfigure things at runtime. Third, this all happened in kernel space, which as an industry we try not to do. It's better to keep as much as possible in user space. To address those issues: enter the Cape Manager. The cape manager is a pretty fancy piece of kernel module software that has the ability to dynamically load and swap out device tree overlays, and the tools live in userspace. When you see instructions on the web about adding lines to uEnv.txt like: optargs=quiet drm.debug=7 capemgr.enable_partno=BB-SPIDEV0 this is telling the cape manager to load the SPI device tree overlay at boot time. Everywhere you look on the internet, this is the recommended solution for enabling SPI on 'current' devices. But, it doesn't work. Why? Well, to explain that requires one more step. Even though the cape manager is neat software from an engineering perspective, and really accomplished its goals well, it still leaves something to be desired from a new user perspective. Folks who are just getting into the whole maker scene are reasonably confused by all this. To address that, some new software was created which is enormously fancy, called universal io. Basically what this is, is a device tree overlay that's loaded by the cape manager at boot time that has the ability to dynamically configure all of the pins at runtime using a tool called config-pin. You can see it and read more about it here: https://github.com/cdsteinkuehler/beaglebone-universal-io So, with this utility all of the pins that aren't reserved for HDMI can be hot configured by using the simple config-pin command, and this includes SPI! So, finally after that long bit of history, here's how you actually set up and use SPI on a new beagle bone black wireless with a current image: #data out config-pin P.18 spi #clock out config-pin P.22 spi Rinse, repeat if you need other pins like CS, or MISO. After days of learning all of the above, and figuring all this out, I'm finally able to see a beautiful output wave form on my oscope. I hope this helps someone else new to all 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/6f2f0867-2045-4e19-afee-365fa30badc3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: Cape Manager for U-Boot
On Fri, Dec 30, 2016 at 11:03 AM, Robert Nelson wrote: > Okay, time to push it out as default... > > First stable build is: > > U-Boot SPL 2017.01-rc2-3-ga4c7d45040 (Dec 30 2016 - 11:30:57) > Trying to boot from MMC1 > > U-Boot 2017.01-rc2-3-ga4c7d45040 (Dec 30 2016 - 11:30:57 -0600), > Build: jenkins-github_Bootloader-Builder-497 > > This includes a U-Boot overlays disabled by default, end user has to > enable in /boot/uEnv.txt overide.. > > Doc's: > > to enable this new feature, set enable_boot_overlays in /boot/uEnv.txt > > enable_uboot_overlays=1 > > First 4 slots are then auto-loaded > 5th slot, can be set by user > > dtb_overlay=/lib/firmware/*.dtbo > > Works best with a r78 based v4.4.x kernel.. > Hey Robert, So, a question some of us who already have existing, and working images may have. Is how do we update our uboot ? When updating to a new kernel, I suspect this will happen automatically via dpkg. But what if "we" do not wish to update our kernel? Things may be working perfectly etc, and maybe we're a bit skittish about updating to a newer kernel. Or maybe we have kernel reliant software ( custom kernel modules, etc ). I just did a git pull update of the scripts repo's but the only two files updated seem like they're unrelated. Or maybe it just seems that way to me . . . -- 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/CALHSORomZxvhdVDB0TOsKakH0pbOYt9OP6dAGFYXOOQdGERgeQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Compiling a kernel module for jessie on the Beaglebone itself
Trying to compile a module of mine which compiles and works fine on my Ubuntu PC. It is basically just usb-skeleton.c but with the usb VendorID and ProductID changed. Now I want to compile it on my BeagleBone. I'm running Linux beaglebone 4.1.30-ti-r69 #1 SMP Sun Aug 14 11:23:09 UTC 2016 armv7l GNU/Linux I've downloaded the kernel source via git clone https://github.com/RobertCNelson/linux-stable-rcn-ee I've linked the source folder to /lib/modules/4.1.30-ti-r69/build The build of my module fails because there is no config. I tried to use the .config from my /boot directory... I copied /boot/config-4.1.30-ti-r69 to linux-stable-rcn-ee/.config Not sure what to do now. So I did make oldconfig && make prepare It asked me a thousand questions which I just hit enter to. Then when it was generating .h files, it failed on timeconst.h: /bin/sh: 1: bc: not found Kbuild:67: recipe for target 'include/generated/timeconst.h' failed recipe for target 'prepare0' failed I'm not trying to rebuild the kernel. I would just the module build system to know how to build my module so that I can use it on my BeagleBone. Thanks for your time. -- 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/294a9527-9781-48bf-b0e0-cd2ef6840df6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: Cape Manager for U-Boot
So I thought about it for a few minutes when not otherwise busy, and figured it out on my own. $ cd /opt/scripts/tools/developers/ $ git pull $ sudo ./update_bootloader.sh $ sudo reboot serial debug: ... [84389.038894] reboot: Restarting system U-Boot SPL 2017.01-rc2-3-ga4c7d45040 (Dec 30 2016 - 11:30:57) Trying to boot from MMC2 *U-Boot 2017.01-rc2-3-ga4c7d45040 (Dec 30 2016 - 11:30:57 -0600), Build: jenkins-github_Bootloader-Builder-497* ... *But I forgot to change /boot/uEnv.txt to allow uboot cape manager . . .* $ sudo nano /boot/uEnv.txt . . . ##BeagleBone Black: HDMI (Audio/Video) disabled: *enable_uboot_overlays=1* dtb=am335x-boneblack-emmc-overlay.dtb dtb_overlay=/lib/firmware/BB-W1-P8.26-00A0.dtbo . . . Serial debug now: loading /boot/vmlinuz-4.4.12-ti-r31 ... 640 bytes read in 514 ms (14.4 MiB/s) loading /boot/dtbs/4.4.12-ti-r31/am335x-boneblack-emmc-overlay.dtb ... 60139 bytes read in 39 ms (1.5 MiB/s) *debug: [dtb_overlay=/lib/firmware/BB-W1-P8.26-00A0.dtbo] ...loading /lib/firmware/BB-W1-P8.26-00A0.dtbo ...974 bytes read in 72 ms (12.7 KiB/s)* Testing 1-wire temp sensor: debian@beaglebone:~$ cat /sys/bus/w1/devices/28-0647ddf6/w1_slave 1c 01 4b 46 7f ff 04 10 e8 : crc=e8 YES 1c 01 4b 46 7f ff 04 10 e8 t=17750 Everything working fine. On Fri, Dec 30, 2016 at 2:07 PM, William Hermans wrote: > On Fri, Dec 30, 2016 at 11:03 AM, Robert Nelson > wrote: > >> Okay, time to push it out as default... >> >> First stable build is: >> >> U-Boot SPL 2017.01-rc2-3-ga4c7d45040 (Dec 30 2016 - 11:30:57) >> Trying to boot from MMC1 >> >> U-Boot 2017.01-rc2-3-ga4c7d45040 (Dec 30 2016 - 11:30:57 -0600), >> Build: jenkins-github_Bootloader-Builder-497 >> >> This includes a U-Boot overlays disabled by default, end user has to >> enable in /boot/uEnv.txt overide.. >> >> Doc's: >> >> to enable this new feature, set enable_boot_overlays in /boot/uEnv.txt >> >> enable_uboot_overlays=1 >> >> First 4 slots are then auto-loaded >> 5th slot, can be set by user >> >> dtb_overlay=/lib/firmware/*.dtbo >> >> Works best with a r78 based v4.4.x kernel.. >> > > Hey Robert, > > So, a question some of us who already have existing, and working images > may have. Is how do we update our uboot ? When updating to a new kernel, I > suspect this will happen automatically via dpkg. But what if "we" do not > wish to update our kernel? Things may be working perfectly etc, and maybe > we're a bit skittish about updating to a newer kernel. Or maybe we have > kernel reliant software ( custom kernel modules, etc ). > > I just did a git pull update of the scripts repo's but the only two files > updated seem like they're unrelated. Or maybe it just seems that way to me > . . . > -- 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/CALHSORpWuvSfU_6OKy4dt1cRsPd-av_4T1F1xZ58URSoJA6Yzg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: Cannot enable UART's
On Friday, 30 December 2016 10:45:35 UTC, truni wrote: > Hi all > > > I cannot enable UARTS no matter what I try. > > > See attached for the commands I am sending, has anybody come across this > problem before? > > > My distro information : > > > Linux beaglebone 4.4.30-ti-r64 #1 SMP Fri Nov 4 21:23:33 UTC 2016 armv7l > GNU/Linux > > > I just cannot get this to work, no does editing uEnv.txt... > > > Please help :) > > > Thanks! So I got the bone to boot up by editing the /etc/rc.local file, which is the last script to run upon boot. However, for some reason although I add both UART-3 and UART-5, the bone only boots with UART-5 enabled. It will boot with only UART-3 enabled if I echo that line out after the UART-5 is echoed. So I am a step closer but not there yet Has anybody got a solution as I cannot enable two UART's at the same time.. it's either one or the other... Is there some pinmux issue going on? -- 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/4429f6e2-ceb0-4440-a7e6-556fbd204075%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: Cannot enable UART's
On Saturday, 31 December 2016 00:41:03 UTC, millsey_386 wrote: > On Friday, 30 December 2016 10:45:35 UTC, truni wrote: > > Hi all > > > > > > I cannot enable UARTS no matter what I try. > > > > > > See attached for the commands I am sending, has anybody come across this > > problem before? > > > > > > My distro information : > > > > > > Linux beaglebone 4.4.30-ti-r64 #1 SMP Fri Nov 4 21:23:33 UTC 2016 armv7l > > GNU/Linux > > > > > > I just cannot get this to work, no does editing uEnv.txt... > > > > > > Please help :) > > > > > > Thanks! > > So I got the bone to boot up by editing the /etc/rc.local file, which is the > last script to run upon boot. > > However, for some reason although I add both UART-3 and UART-5, the bone only > boots with UART-5 enabled. It will boot with only UART-3 enabled if I echo > that line out after the UART-5 is echoed. > > So I am a step closer but not there yet > > Has anybody got a solution as I cannot enable two UART's at the same time.. > it's either one or the other... > > Is there some pinmux issue going on? The issue was that I was being stupid I had a small typo in my rc.local file causing the second line initialising UART2 to be dropped I now get this output after boot Last login: Sat Dec 31 03:12:40 2016 from scotts-iphone debian@beaglebone:~$ su Password: root@beaglebone:/home/debian# cat /sys/devices/platform/bone_capemgr/slots 0: PF -1 1: PF -1 2: PF -1 3: PF -1 4: P-O-L- 0 Override Board Name,00A0,Override Manuf,BB-UART4 5: P-O-L- 1 Override Board Name,00A0,Override Manuf,BB-UART2 root@beaglebone:/home/debian# ls -l /dev/ttyO* lrwxrwxrwx 1 root root 5 Dec 31 03:10 /dev/ttyO0 -> ttyS0 lrwxrwxrwx 1 root root 5 Dec 31 03:10 /dev/ttyO2 -> ttyS2 lrwxrwxrwx 1 root root 5 Dec 31 03:10 /dev/ttyO4 -> ttyS4 root@beaglebone:/home/debian# Next up is using minicom, physically connecting them together and seeing how much of a mess I can make out of that :-) -- 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/12441b9d-de99-4266-9f13-a4454de8467a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.