Bongobongdid a df -h / on a 64gb sd card and got 3.3G, 1.7G used, 1.4G available
gakhello, I am new here and to beagleboard
gakI am trying to download the angstrom distribution but having problems
zmattBongobong: yeah, so the partition and filesystem need to be expanded
zmattyou can either do that from another linux system or even while booted from the card itself
Bongobongyeah i have done that it seems to be more stable now
Bongobongstill haven't tried enabling spi, i noticed it said something about capes being deprecated and to use u-boot overlays
zmattyou 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
Bongobongeven if i am not showing anything in /dev about spi?
zmattI would guess that's because you already made changes in configuration that caused this
zmattthey are there by default
zmatt(unless you're using a really old image)
zmattbut you're not since you mentioned u-boot overlays
Bongobongi am on 4.9 kernel and the latest debian image, however when i first boot on a clean image it is not there
zmattwhat's the name of the image you're using?
zmattalso, you've booted from sd card right?
Bongobongyes and one second
zmattdo you care about the content of eMMC? if not, consider erasing it with sudo blkdiscard /dev/mmcblk1
Bongobongdebian 9.3 iot
zmattby default ROM prefers to load u-boot from eMMC over loading it from SD
zmattif the system on eMMC is much older than the system on SD card, that can cause trouble
zmatte.g. the system is expecting u-boot overlays to be used, but the old u-boot on eMMC doesn't know anything about that
Guest8276I'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.
Guest8276H: is the beaglebone via USB.
zmattif you're using a recent image on the beaglebone, no driver is needed for windows 10
zmattif 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
Guest8276ok. At the moment I've just unplacked the board and plugged it in and ran Start.htm following the instructions there
Guest8276Is there a way to interogate it to see what version is on there?
zmattthere is, but that requires you're able to log into it
Guest8276haha ok. I'll keep reading and see if it explains how to try and log into it :)
zmattcheck the "status" column of the table here to check for connectivity:
ds2sigh.... dump that crap
ds2no point in having a massive spyware at home
zmattGuest8276: anyway, fresh out of the box... who knows how old the stuff on there might be
zmattds2: ?
ds2win10 == massive spyware
zmattI don't like using windows either, but this doesn't seem like the appropriate place to try to convert people to linux
ds2I am specifically complaining about win10 but you have a fair point
ds2specially - why are we supporting use of spyware
zmattbecause trying to be elitist about which OS people should used is not exactly a good way to welcome new users?
ds2anyways... let's just follow your suggestion =)
zmattGuest3950: I recommend reflashing the beaglebone anyways... whatever is on there is most likely not very recent
zmattother guest
zmattwho already left it seems
Bongobongzmatt erasing emmc worked
Bongobongi now have spidev stuff
kenrestivois this the current best source for pinctrl-single,pins addreses? is there a better one?
kenrestivothat's quite old.
zmattwell it's not like the hardware functions have changed
zmattbut you can also consult my spreadsheet
zmatt the BBB tab for a list, or P9/P8 tabs for overviews
zmattI don't list the register offset, but it's 4 * pin number
zmattusually people don't need that info anymore since cape-universal has been enabled by default
zmatt(which lets you just configure pins by name)
kenrestivohow can i do that in an overlay?
kenrestivolooks like overlays still require the addresses
zmattI use a header with constants for the pins
kenrestivo(application: trying to get gpio-keys going)
kenrestivooh, nice! thanks!
zmattthis is just my custom stuff though
kenrestivoit's a good idea tho
zmattI think the official stuff now uses constants too, but with different syntax
kenrestivoi didn't know #includes worked in dts
zmattthey do if you run it through a preprocessor
zmattsee Makefile
zmattalso I use a perl script that turns normal .dtsi syntax into the horrid mess required for overlays
zmattthat stuff
kenrestivotarget, yep.
kenrestivogood stuff, thanks
zmatt(or, well, I just made this stuff actually... I don't actually *use* overlays myself)
kenrestivowhere's the official stuff? i don't remember seeing any official PIN_IO_PULLUP() style macros anywhere
kenrestivoor at least the docs i find on beaglebone all seem to be from 2012-2014 :(
kenrestivobefore the raspocalypse
zmattbrowsing the dt sources I see various stuff in use
kenrestivorcn, gotcha
kenrestivoby the way, is there any way to load overlays nowadays? capemgr seems deprecated?
zmattbut elsewhere
zmattat runtime or at boot?
zmattthe configfs mechanism should still work
kenrestivoare there docs on that?
zmattmy overlay-utils repository has scripts for that too, see bin dir
kenrestivoperfect, looking thru it now
kenrestivothat's one hairy perl script for dtsi
zmatthaven't tested them in quite a while, but should still work I think
zmattI still don't understand why dtc doesn't just accept normal syntax for overlays
zmattI really see no technical reason for this
kenrestivohistory, i bet
zmattoverlays don't have that much history
kenrestivowould the dtc maintainers accept a patch to clean up the syntax?
kenrestivoi haven't looked at their code; not sure how easy it is to mod
zmattI have no idea... have overlays even made it upstream yet?
kenrestivodunno. beagle and raspberry use them heavily
zmattbeagle no longer really
zmattoverlaying is now done in u-boot
kenrestivoright, but i remember seeing dtbo's in u-boot
zmattfair enough, for dtc it's still relevant
kenrestivooh cool: /sys/kernel/config/device-tree/overlays. is that documented anywhere?
zmattI think so yes
kenrestivohmm, i think this is it then
zmatt if you want the one for the relevant kernel tree
kenrestivoalso found this
zmattthat's about configfs in general yeah
ds2zmatt: does your perl script do the reverse (overlay -> dts)?
zmattuh, no? that would be a totally different procedure
moto-timoACTION scratches head and wonders why
moto-timosomeone would ask for the reverse
Bongobonghm i have spidev in /dev but i am not able to interface with this device
Bongobongtried using an o scope to see if there was a signal but nothing, even on clock
zmattdid you configure the pins with config-pin ?
Bongobongi did not i thought that was for gpio
Bongobongaren't the pins for spi0 dedicated?
zmattgpio is the default mode, so you actually don't need to use config-pin for that
zmattalmost no pins are dedicated
Bongobongi see
Bongobongare all the pins identified by p9.#?
ds2yes but getting rid of overlays is more interesting
Bongobongwhat do you mean
zmattBongobong: or p8.#
Bongobongdoes the p8 and p9 denote anything?
zmattthey're the two big expansion headers
Bongobongah i see now, it makes sense thanks
Bongobongokay 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
Bongobongdoes it matter that the device tree overlay only has mode 0?
zmattoverlay? you're still trying to do something with an overlay?
Bongobongit's a devie tree source
zmattyes but why are you referencing it?
zmattalso, to double-check the current pin config you can use my show-pins script:
Bongobongi'm showing the pins configured appropriately
Bongobongwait shouldn't some of those be tx?
zmattrx indicates receiver is enabled
Bongobongah yeah
zmattbut yeah this looks fine
zmattspidev0.0 should work with this
Bongobongi don't have 0.0 i have 1.0
zmattoh right, stupid device numbering
zmattI patched that but maybe rcn didn't merge that, or at least not in the particular kernel you have
Bongobongso it's likely my code rather than the device
zmattmay be useful to do a simple loopback test by connecting mosi -> miso and doing an inout transfer
Bongobonginout transfer?
zmattsimultaneous in and out
zmatt(i.e. not an in-only or out-only transfer)
Bongobongi'll do that and see what i get
Bongobongit does look like spi is working
smitthhyyAre 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.
ArunKumarHello everyone
ArunKumarI 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
ArunKumaris there any tutorials on this avalable?
mattvenn_have you seen the exploring beaglebone tutorials?
peroyvibzmatt: 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_pythonhello all, im sorry for asking this again, how can i access normal gpio via the PRU?
pru_pythonfor 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_pythoncan i only access pr1_pru1_pru_r3x_xx type pins??
pru_pythonwell the pypruss library doesn't seem to be working still,,
pru_pythonif i ignore the modprobe command
pru_pythonit just throws a "return without exception set error"
zmattperoyvib: ?
zmattperoyvib: not sure what you're talking about
peroyvibzmatt: not important, problem solved.
zmattwell 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_pythonhello 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_pythonaccording 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_pythondo i need to add the robotics cape debt manually to uEnv.txt?
zmattno 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_pythonso after uncommenting the boot_overlay_pru line i should be able to use pypruss like you said right?
pru_pythonwith out the silly modprobe think
pru_pythoncuz when i tried it yesterday after that, it still wasn't opening the pru
zmattcheck 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
zmattthen something is wrong
zmattI'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?
zmattdid 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)
zmattdtbs 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
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_pythonso, i got the uio to show in asmod | grep uio
pru_pythonhowever pypruss not working still :(
pru_python"prussdrv_open open failed"
pru_pythonzmatt: 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_pythonalso im trying to run the examples from the am335x package
pru_pythonthe uio_pruss shows up in asmod, but it isn't exectuing
pru_pythonit throws "prussdrv_open open failed" error
pru_python_mesh it still only shows pru_rproc in lsmod
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
zmattwait, have you disabled remoteproc in /boot/uEnv.txt yet?
zmattalso, are you running from eMMC or SD ?
zmattalso, 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
zmattok, that's good, then the question becomes why this is being ignored
zmattare you running from eMMC or SD ?
pru_python_i am running from eMMC
zmattwhich 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
zmattwhy 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"
zmattit shouldn't have either of those to be honest, that's part of the overlay loaded by uboot_overlay_pru
zmattmaybe 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?
zmattif I had a blue and wanted to use pru, I'd use uio-pruss
zmattI 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
zmattbut you said you also saw remoteproc
zmattor not?
pru_python_i did see
zmatthaving both loaded would definitely be disaster
pru_python_should i do rmmod -f for remoteproc
zmattit shouldn't load in the first place
zmattwell not remoteproc in general, rproc_pru or whatever it's called
zmattoh what the hell, I just found this in u-boot boot script:
zmattif 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
zmattjkridner[m]: the config you told pru_python_ is never going to work when u-boot overlays aren't even supported currently for the blue
zmattpru_python_: is there any /dev/uio* device?
pru_python_zmatt: no uio device in /dev
zmattthen you or something probably just pointlessly modprobed the uio_pruss kernel module
zmatt(instead of it being automatically loaded for pruss)
zmattand 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)
zmattmodprobe uio_pruss will load the kernel module
zmattregardless of whether it has anything useful to do
zmattif the appropriate DT declarations aren't there, the module does nothing
zmattif the appropriate DT declarations are there, the module will get loaded automatically
zmattthat'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?
zmattyeah it requires a DT tweak... like you did earlier actually
zmattnot sure why that didn't work then
zmattyeah now that I know u-boot overlays are *not* being used, that's actually the best option
zmattbut, 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_pythonso i blacklisted pruss, pruss_intc and pru-rproc
pru_pythonstill no uio device in /dev
jason_94quick question to anyone with a BBB wireless
pru_python_sorry i timed out cuz i shutdown my blue
jason_94I see it comes with the chip WiLink1835 used for wlan/ble
jason_94does anyone know how many simutaneous connections the WiLink1835 chip inside the BBB wireless can handle?
jason_94simeteanous BLE connections*
pru_python_jason_94: as mentioned here: on pg 30
pru_python_blue can have 10 low energy connections at max
jason_94awesome, 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_pythonzmatt: 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_pythonzmatt: check this out: