| Bongobong | did a df -h / on a 64gb sd card and got 3.3G, 1.7G used, 1.4G available |
| Bongobong | top |
| gak | hello, I am new here and to beagleboard |
| gak | I am trying to download the angstrom distribution but having problems |
| zmatt | Bongobong: yeah, so the partition and filesystem need to be expanded |
| zmatt | you can either do that from another linux system or even while booted from the card itself |
| Bongobong | yeah i have done that it seems to be more stable now |
| Bongobong | still haven't tried enabling spi, i noticed it said something about capes being deprecated and to use u-boot overlays |
| zmatt | you normally don't need to enable spi, it should be enabled by default, all you have to do is configure the pins with config-pin |
| Bongobong | even if i am not showing anything in /dev about spi? |
| zmatt | I would guess that's because you already made changes in configuration that caused this |
| zmatt | they are there by default |
| zmatt | (unless you're using a really old image) |
| zmatt | but you're not since you mentioned u-boot overlays |
| Bongobong | i am on 4.9 kernel and the latest debian image, however when i first boot on a clean image it is not there |
| zmatt | what's the name of the image you're using? |
| zmatt | also, you've booted from sd card right? |
| Bongobong | yes and one second |
| zmatt | do you care about the content of eMMC? if not, consider erasing it with sudo blkdiscard /dev/mmcblk1 |
| Bongobong | debian 9.3 iot |
| zmatt | by default ROM prefers to load u-boot from eMMC over loading it from SD |
| zmatt | if the system on eMMC is much older than the system on SD card, that can cause trouble |
| zmatt | e.g. the system is expecting u-boot overlays to be used, but the old u-boot on eMMC doesn't know anything about that |
| Guest8276 | I'm having trouble installing the BeagleBone Driver Installation on Windows 10. I'm downloading the 64bit driver file:///H:/Drivers/Windows/BONE_D64.exe. All are reporting Install Failed. Even when I run as administrator. |
| Guest8276 | H: is the beaglebone via USB. |
| zmatt | if you're using a recent image on the beaglebone, no driver is needed for windows 10 |
| zmatt | if whatever image is flashed onto the beaglebone is old enough to still need a driver, I'd suggest reflashing the beaglebone with the latest image |
| Guest8276 | ok. At the moment I've just unplacked the board and plugged it in and ran Start.htm following the instructions there |
| Guest8276 | Is there a way to interogate it to see what version is on there? |
| zmatt | there is, but that requires you're able to log into it |
| Guest8276 | haha ok. I'll keep reading and see if it explains how to try and log into it :) |
| zmatt | check the "status" column of the table here to check for connectivity: http://beagleboard.org/getting-started#step2 |
| ds2 | sigh.... dump that crap |
| ds2 | no point in having a massive spyware at home |
| zmatt | Guest8276: anyway, fresh out of the box... who knows how old the stuff on there might be |
| zmatt | ds2: ? |
| ds2 | win10 == massive spyware |
| zmatt | I don't like using windows either, but this doesn't seem like the appropriate place to try to convert people to linux |
| ds2 | I am specifically complaining about win10 but you have a fair point |
| ds2 | specially - why are we supporting use of spyware |
| trev | trev |
| zmatt | because trying to be elitist about which OS people should used is not exactly a good way to welcome new users? |
| ds2 | anyways... let's just follow your suggestion =) |
| zmatt | Guest3950: I recommend reflashing the beaglebone anyways... whatever is on there is most likely not very recent |
| zmatt | eh |
| zmatt | other guest |
| zmatt | who already left it seems |
| Bongobong | zmatt erasing emmc worked |
| Bongobong | i now have spidev stuff |
| zmatt | :) |
| kenrestivo | is this the current best source for pinctrl-single,pins addreses? http://www.embedded-things.com/wp-content/uploads/2013/08/P8.png is there a better one? |
| kenrestivo | that's quite old. |
| kenrestivo | (2013) |
| zmatt | well it's not like the hardware functions have changed |
| zmatt | but you can also consult my spreadsheet |
| zmatt | https://goo.gl/Jkcg0w the BBB tab for a list, or P9/P8 tabs for overviews |
| zmatt | I don't list the register offset, but it's 4 * pin number |
| kenrestivo | thanks |
| zmatt | usually people don't need that info anymore since cape-universal has been enabled by default |
| zmatt | (which lets you just configure pins by name) |
| kenrestivo | how can i do that in an overlay? |
| kenrestivo | looks like overlays still require the addresses |
| zmatt | I use a header with constants for the pins |
| kenrestivo | (application: trying to get gpio-keys going) |
| zmatt | e.g. https://github.com/mvduin/overlay-utils/blob/master/i2c1.dtsi#L15-L26 |
| kenrestivo | oh, nice! thanks! |
| zmatt | this is just my custom stuff though |
| kenrestivo | it's a good idea tho |
| zmatt | I think the official stuff now uses constants too, but with different syntax |
| kenrestivo | i didn't know #includes worked in dts |
| zmatt | they do if you run it through a preprocessor |
| zmatt | see Makefile |
| zmatt | also I use a perl script that turns normal .dtsi syntax into the horrid mess required for overlays |
| kenrestivo | __overlay__ |
| zmatt | that stuff |
| kenrestivo | target, yep. |
| kenrestivo | good stuff, thanks |
| zmatt | (or, well, I just made this stuff actually... I don't actually *use* overlays myself) |
| kenrestivo | where's the official stuff? i don't remember seeing any official PIN_IO_PULLUP() style macros anywhere |
| kenrestivo | or at least the docs i find on beaglebone all seem to be from 2012-2014 :( |
| kenrestivo | before the raspocalypse |
| zmatt | browsing the dt sources I see various stuff in use |
| zmatt | like https://github.com/RobertCNelson/dtb-rebuilder/blob/4.9-ti/src/arm/am335x-bone-pinmux-i2c2.dtsi#L32-L41 |
| kenrestivo | rcn, gotcha |
| kenrestivo | by the way, is there any way to load overlays nowadays? capemgr seems deprecated? |
| zmatt | but elsewhere https://github.com/RobertCNelson/dtb-rebuilder/blob/4.9-ti/src/arm/am335x-bone-common.dtsi#L87-L92 |
| zmatt | at runtime or at boot? |
| kenrestivo | runtime |
| zmatt | the configfs mechanism should still work |
| kenrestivo | are there docs on that? |
| zmatt | my overlay-utils repository has scripts for that too, see bin dir |
| kenrestivo | perfect, looking thru it now |
| kenrestivo | that's one hairy perl script for dtsi |
| zmatt | haven't tested them in quite a while, but should still work I think |
| zmatt | I still don't understand why dtc doesn't just accept normal syntax for overlays |
| zmatt | I really see no technical reason for this |
| kenrestivo | history, i bet |
| zmatt | overlays don't have that much history |
| kenrestivo | would the dtc maintainers accept a patch to clean up the syntax? |
| kenrestivo | i haven't looked at their code; not sure how easy it is to mod |
| zmatt | I have no idea... have overlays even made it upstream yet? |
| kenrestivo | dunno. beagle and raspberry use them heavily |
| zmatt | beagle no longer really |
| zmatt | overlaying is now done in u-boot |
| kenrestivo | right, but i remember seeing dtbo's in u-boot |
| zmatt | fair enough, for dtc it's still relevant |
| kenrestivo | oh cool: /sys/kernel/config/device-tree/overlays. is that documented anywhere? |
| zmatt | I think so yes |
| kenrestivo | hmm, i think this is it then https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git/tree/Documentation/devicetree/configfs-overlays.txt?h=topic/overlays |
| zmatt | yep |
| zmatt | https://github.com/RobertCNelson/linux-stable-rcn-ee/blob/4.9.80-ti-r98/Documentation/devicetree/configfs-overlays.txt if you want the one for the relevant kernel tree |
| kenrestivo | also found this https://www.kernel.org/doc/Documentation/filesystems/configfs/configfs.txt |
| zmatt | that's about configfs in general yeah |
| ds2 | zmatt: does your perl script do the reverse (overlay -> dts)? |
| zmatt | uh, no? that would be a totally different procedure |
| moto-timo | ACTION scratches head and wonders why |
| moto-timo | someone would ask for the reverse |
| Bongobong | hm i have spidev in /dev but i am not able to interface with this device |
| Bongobong | tried using an o scope to see if there was a signal but nothing, even on clock |
| zmatt | did you configure the pins with config-pin ? |
| Bongobong | i did not i thought that was for gpio |
| Bongobong | aren't the pins for spi0 dedicated? |
| zmatt | gpio is the default mode, so you actually don't need to use config-pin for that |
| zmatt | no |
| zmatt | almost no pins are dedicated |
| Bongobong | i see |
| Bongobong | are all the pins identified by p9.#? |
| ds2 | yes but getting rid of overlays is more interesting |
| Bongobong | what do you mean |
| zmatt | Bongobong: or p8.# |
| Bongobong | does the p8 and p9 denote anything? |
| zmatt | they're the two big expansion headers |
| Bongobong | ah i see now, it makes sense thanks |
| Bongobong | okay i have configured the pins p9.17 - spi_cs, p9.18 spi, p9.21 spi, p9.22 spi_sclk and still am not able to interface |
| Bongobong | does it matter that the device tree overlay only has mode 0? https://github.com/nolanholden/beaglebone-c/blob/c066d9b54aecb21e58bc7d524818f8ee092dda28/overlays/BBCLIB-SPI0.dts |
| zmatt | overlay? you're still trying to do something with an overlay? |
| Bongobong | it's a devie tree source |
| Bongobong | device |
| zmatt | yes but why are you referencing it? |
| zmatt | also, to double-check the current pin config you can use my show-pins script: https://github.com/mvduin/bbb-pin-utils/tree/master#show-pins |
| Bongobong | okay |
| Bongobong | https://i.imgur.com/r14wbJt.png |
| Bongobong | i'm showing the pins configured appropriately |
| Bongobong | wait shouldn't some of those be tx? |
| zmatt | rx indicates receiver is enabled |
| Bongobong | ah yeah |
| zmatt | but yeah this looks fine |
| zmatt | spidev0.0 should work with this |
| Bongobong | i don't have 0.0 i have 1.0 |
| zmatt | oh right, stupid device numbering |
| zmatt | I patched that but maybe rcn didn't merge that, or at least not in the particular kernel you have |
| Bongobong | so it's likely my code rather than the device |
| zmatt | may be useful to do a simple loopback test by connecting mosi -> miso and doing an inout transfer |
| Bongobong | inout transfer? |
| zmatt | simultaneous in and out |
| zmatt | (i.e. not an in-only or out-only transfer) |
| Bongobong | i'll do that and see what i get |
| Bongobong | it does look like spi is working |
| smitthhyy | Are serial ports enabled by default eg ttyS4? I'm trying to send/receive between to BB's using Node-Red, just not getting data in. |
| ArunKumar | Hello everyone |
| sulphurik[m] | Howdy |
| tbr | moo! |
| ArunKumar | I just got my first BB black today and was wondering how do i setup an SPI communication to it.I plan to read two separate ADC simultaniously |
| ArunKumar | is there any tutorials on this avalable? |
| mattvenn_ | hi |
| mattvenn_ | have you seen the exploring beaglebone tutorials? |
| mattvenn_ | http://exploringbeaglebone.com/chapter8/ |
| peroyvib | zmatt: I tried out your script, it gave me different indexes, I did run the rc_gpio_export(); function with "BLUE_GPI0_PIN_x" or x = 3, 4, 5 and 6 in my program. That solved the problem. But the output of your script still get me different numbers, my program did not work with those. |
| pru_python | hello all, im sorry for asking this again, how can i access normal gpio via the PRU? |
| pru_python | for example, the RED and GREEN leds on the blue are not connected to the pru, so how can i toggle them via the pru? |
| pru_python | can i only access pr1_pru1_pru_r3x_xx type pins?? |
| pru_python | well the pypruss library doesn't seem to be working still,, |
| pru_python | if i ignore the modprobe command |
| pru_python | it just throws a "return without exception set error" |
| zmatt | peroyvib: ? |
| zmatt | peroyvib: not sure what you're talking about |
| peroyvib | zmatt: not important, problem solved. |
| zmatt | well if there's some major mistake in the blue version of my show-pins script then that is important to me... I don't think it does though |
| pru_python | hello all, so i flashed debian 9.3 to my blue, and i wanted to know how to check the current device tree being used |
| pru_python | according to what zmatt and jkridner said, i needed to activate the uio_pruss to be able to use pypruss so i have uncommented the following line from /boot/uEnv.txt : |
| pru_python | uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo |
| pru_python | do i need to add the robotics cape debt manually to uEnv.txt? |
| zmatt | no since you don't have a robotics cape, you have a beaglebone blue |
| zmatt | (even for capes, no manual configuration in /boot/uEnv.txt should be necessary actually) |
| pru_python | so after uncommenting the boot_overlay_pru line i should be able to use pypruss like you said right? |
| pru_python | with out the silly modprobe think |
| pru_python | cuz when i tried it yesterday after that, it still wasn't opening the pru |
| zmatt | check that uio_pruss (or something like that) is listed in lsmod after boot |
| pru_python_ | zmatt: hey its not enabling uio_pruss |
| pru_python_ | i just rebooted |
| zmatt | then something is wrong |
| zmatt | I'm not really awake enough yet for much tech support though |
| pru_python_ | alright cool |
| pru_python_ | can you tell me where i can find the dt blob? |
| pru_python_ | for the blue? |
| zmatt | did you flash onto eMMC or are you running from sd card? |
| pru_python_ | i flashed onto eMMC, will it be in opt/source |
| pru_python_ | in 4.9 |
| pru_python_ | (as im running 4/9 kernel) |
| pru_python_ | 4.9* |
| zmatt | dtbs are in /boot/dtbs ... if you meant dt sources however, you can find them in the applicable kernel source tree (in arch/arm/boot/dts ) or in https://github.com/RobertCNelson/dtb-rebuilder |
| pru_python_ | you're right i needed the dts (man i need to get my jargons right), so im gonna try adding this: #include "am33xx-pruss-uio.dtsi" to it and see |
| pru_python_ | thanks for your time |
| pru_python_ | i guess the am335x-pruss-uio.dtsi is not included in 4.9 rt |
| pru_python | so, i got the uio to show in asmod | grep uio |
| pru_python | lsmod* |
| pru_python | however pypruss not working still :( |
| pru_python | "prussdrv_open open failed" |
| pru_python | zmatt: I ran echo "uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo" >> /boot/uEnv.txt and echo "enable_uboot_overlays=1" >> /boot/uEnv.txt as was mentioned by jkridner (since the manual modifications i did lat time didn't work :( ) |
| pru_python | last* |
| pru_python | also im trying to run the examples from the am335x package |
| pru_python | the uio_pruss shows up in asmod, but it isn't exectuing |
| pru_python | executing* |
| pru_python | it throws "prussdrv_open open failed" error |
| pru_python_ | mesh it still only shows pru_rproc in lsmod |
| pru_python_ | eesh* |
| pru_python_ | can anyone tell me a proper way to use am335x_pru_package with the blue |
| pru_python_ | i want to integrate it into my project |
| pru_python_ | remote_proc seems way too cnvoluted |
| pru_python_ | how to enable the PRU on th eblue |
| zmatt | wait, have you disabled remoteproc in /boot/uEnv.txt yet? |
| zmatt | also, are you running from eMMC or SD ? |
| zmatt | also, please undo whatever you did by messing with the dtbs, you should not have to do anything like that |
| pru_python_ | the line uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-4-TI-00A0.dtbo is commented out |
| pru_python_ | and the UIO one is uncommented |
| pru_python_ | i have undone all the dtbs changes thanks for letting me know |
| zmatt | ok, that's good, then the question becomes why this is being ignored |
| zmatt | are you running from eMMC or SD ? |
| pru_python_ | i am running from eMMC |
| zmatt | which image are you using? (cat /etc/dogtag ) |
| pru_python_ | 2018-01-28 |
| pru_python_ | Debian Image |
| pru_python_ | also if it helps, im using 4.4.148 rt kernel i think |
| pru_python_ | i just updated to the latest one |
| pru_python_ | but its 4.4 |
| zmatt | why did you switch? still shouldn't matter though, remoteproc shouldn't be loading |
| pru_python_ | i switched because the "am33xx-pruss-uio.dtsi" was not available on 4.9 |
| pru_python_ | so what should be done now, any ideas? |
| pru_python_ | Note: I have undone the dts as you mentioned so it now has #include "am33xx-pruss-rproc.dtsi" |
| zmatt | it shouldn't have either of those to be honest, that's part of the overlay loaded by uboot_overlay_pru |
| zmatt | maybe there are now issues because you've switched to an older kernel? or maybe the u-boot logic for the blue is just not the same as for every other beaglebone, I don't know |
| pru_python_ | okay so remote proc is the way to go right now fo blue? |
| pru_python_ | in /usr/lib/ti/pru-software-support-package/examples/am335x how do i run the examples? |
| zmatt | if I had a blue and wanted to use pru, I'd use uio-pruss |
| zmatt | I don't care for remoteproc personally |
| pru_python_ | but currently theres no option right? |
| pru_python_ | what i don't understand is if in lsmod it shows that the uio_pruss is active, why is it not working |
| zmatt | but you said you also saw remoteproc |
| zmatt | or not? |
| pru_python_ | i did see |
| zmatt | having both loaded would definitely be disaster |
| pru_python_ | should i do rmmod -f for remoteproc |
| zmatt | it shouldn't load in the first place |
| zmatt | well not remoteproc in general, rproc_pru or whatever it's called |
| zmatt | oh what the hell, I just found this in u-boot boot script: |
| zmatt | if test $board_name = BBBL; then env delete -f enable_uboot_overlays; fi; |
| pru_python_ | im sorry i was wrong, here is the output of lsmod | grep pru: uio_pruss 4629 0 |
| pru_python_ | and a bunch of other stuff |
| pru_python_ | with uio |
| pru_python_ | oh shit haha! |
| pru_python_ | so ill comment that out |
| pru_python_ | ? |
| zmatt | jkridner[m]: the config you told pru_python_ is never going to work when u-boot overlays aren't even supported currently for the blue |
| zmatt | pru_python_: is there any /dev/uio* device? |
| pru_python_ | no |
| pru_python_ | zmatt: no uio device in /dev |
| zmatt | then you or something probably just pointlessly modprobed the uio_pruss kernel module |
| zmatt | (instead of it being automatically loaded for pruss) |
| zmatt | and I don't think forcibly enabling u-boot overlays would be a good idea, probably the base dtb isn't designed for it yet then |
| pru_python_ | would running modprobe uio_pruss have caused that? (sorry i don't understand) |
| zmatt | modprobe uio_pruss will load the kernel module |
| zmatt | regardless of whether it has anything useful to do |
| zmatt | if the appropriate DT declarations aren't there, the module does nothing |
| zmatt | if the appropriate DT declarations are there, the module will get loaded automatically |
| zmatt | that's why manually modprobing is pointless |
| pru_python_ | alright, so in the current state the Blue cannot use uio_pruss |
| pru_python_ | can't we modify the blue's dts? |
| zmatt | yeah it requires a DT tweak... like you did earlier actually |
| zmatt | not sure why that didn't work then |
| zmatt | yeah now that I know u-boot overlays are *not* being used, that's actually the best option |
| zmatt | but, I'm afk for a bit |
| pru_python_ | okay cool |
| pru_python_ | ill try including the uio.dtsi file again and see |
| pru_python_ | im modifying am335x-boneblue.dts |
| pru_python_ | I have added #include "am33xx-pruss-uio.dtsi" and commented out #include "am33xx-pruss-rproc.dtsi" |
| pru_python | so i blacklisted pruss, pruss_intc and pru-rproc |
| pru_python | still no uio device in /dev |
| jason_94 | quick question to anyone with a BBB wireless |
| pru_python_ | sorry i timed out cuz i shutdown my blue |
| jason_94 | I see it comes with the chip WiLink1835 used for wlan/ble |
| jason_94 | does anyone know how many simutaneous connections the WiLink1835 chip inside the BBB wireless can handle? |
| jason_94 | simeteanous BLE connections* |
| pru_python_ | jason_94: as mentioned here: http://www.ti.com/lit/ds/symlink/wl1837mod.pdf on pg 30 |
| pru_python_ | blue can have 10 low energy connections at max |
| pru_python_ | ble* |
| jason_94 | awesome, thanks for the quick response! |
| pru_python_ | no worries haha |
| pru_python_ | zmatt: My blue was not booting up after those changes, I am refreshing it right now |
| pru_python_ | zmatt: uio cannot run on 4.9 kernel right? |
| pru_python_ | reflashing* |
| pru_python | zmatt: its quite late here, so im nodding off! would you mind messaging me in case you figure out what can be done, or if nothing can? its really urgent for me. Regardless, thanks as always :) |
| pru_python | zmatt: check this out: https://github.com/shubhi1407/PRU-framework |