<ds2>
it is so disappointing that so many pins are wasted on the analog in on the pocket beagle
<zmatt>
I mean, many pins in general are wasted on the pocketbeagle... that's just the trade-off for its tiny size
<Angel_Sosa>
What I struggle with is judt finding what is availalble and solid documentation on how to alter the pins on the X15
<Angel_Sosa>
There is so much out dated documentation on X15 and so much has to be cobbled together to come close to an answer. I really get the feeling these boards are past due
vd has quit [Quit: Client closed]
vd has joined #beagle
<zmatt>
it just hasn't received quite as much attention
<ds2>
the ADC on 335x just blows chunks
<ds2>
bringing out more of the PRU would at least enable more soft peripherals
Angel_Sosa has quit [Quit: Client closed]
Angel_Sosa has joined #beagle
Angel_Sosa has quit [Client Quit]
buzzmarshall has quit [Quit: Konversation terminated!]
otisolsen70 has joined #beagle
xet7 has joined #beagle
xet7 has quit [Remote host closed the connection]
xet7 has joined #beagle
vd has quit [Quit: Client closed]
vd has joined #beagle
vd has quit [Ping timeout: 256 seconds]
Shadyman has quit [Remote host closed the connection]
<markand>
our old application export pins using the deprecated /sys/class/gpio/export API
<markand>
basically fopen + fprintf, sometimes the pin does not appear in /sys/class/gpio for some reasons...
<markand>
while a simple echo 44 > /sys/class/gpio/export works fine...
<markand>
is there a limit of exports? we open in order: 44, 22, 45, 65, 61
<markand>
sometimes the program exports the 44 fines, sometimes the 22 is visible but not always both at the same time
<Angel_Sosa>
Hi Everyone, On the BB-X15 I know how to communicate with the GPIO labeled pins via sysfs. How do I via software and sysfs activate and communicate with pins ex: P16.24, P18.17, P18.43, P.18.42. And please point me to the best information you know of so that I can enable myself
nmingotti has joined #beagle
<nmingotti>
is it possible to load the universal cape in BB-AI ? If so, how do i do it ?
<zmatt>
markand: there's a bug in rcn's kernels that attempting to export an already-exported pin causes it to vanish... are you maybe running into that?
<zmatt>
markand: also, I recommend using open()+write() rather than fopen()+fwrite() since sysfs attributes do not behave like normal files
<zmatt>
writing a value to a sysfs attribute should be done using a single write() syscall... it's likely fwrite() will do that but I don't think there's any semantic guarantee that it in fact will
<Angel_Sosa>
Its more newbie information in my case
<zmatt>
nmingotti: I *think* that should work in the testing images
<Angel_Sosa>
Just so you know Using C++ or C is to open and close sysfs files is not my issue
<zmatt>
Angel_Sosa: yeah it's possible cape-universal just has never been ported to the x15, in which case pinmux requires an overlay
<zmatt>
Angel_Sosa: I was talking to markand, not you
<Angel_Sosa>
Ok
<Angel_Sosa>
I'll standby
<zmatt>
no need to do that, just pay attention to whom I'm replying to... if there's any possibility of ambiguity I always prefix lines with the person I'm addressing
<Angel_Sosa>
To complete my question to the group I need to know how to access the pins mentioned above I can get to them mechanically but how from a software point of view
<nmingotti>
@zmatt, ok thanks, i will put it in my notes and check it out
<zmatt>
which is the only mechanism supported by mainline linux and mainline u-boot
<zmatt>
if you're using a recent enough image, overlays should work as well, which allows keeping customizations separate from the base dtb
<zmatt>
(hence also avoiding the need to rebuild the custom dtb after every kernel update)
<zmatt>
runtime configuration of pins via sysfs requires cape-universal, which like I said might never have been ported to the bbx15
<Angel_Sosa>
zmatt I use sysfs to reconfigure for example P16.3 and P16. 4
<zmatt>
??
<zmatt>
what do you mean?
<zmatt>
if cape-universal were implemented, it'll be for all pins, it makes no sense for it to be implemented for only a few pins
<Angel_Sosa>
It just like on the BB Black it works P16.3 is GPIO4_17 = ( BB Math to access pins on headers ) = GPIO113
<Angel_Sosa>
export 113 and its available to raise and lower the pin
<zmatt>
btw be warned that at least older u-boot versions for bbx15 did all sorts of weird pin configuration in u-boot (designed for the expansion board of the am572x-evm)... I don't know if that's been fixed already in current images, back then I actually built a custom u-boot that disables this pin config (https://liktaanjeneus.nl/bbx15/u-boot-2017.01-00468-g506adcc7f880.tar.xz) but do note this u-boot ...
<zmatt>
...doesn't support overlays and requires the use of a custom dtb
<zmatt>
okay but controlling a gpio has nothing to do with pinmux configuration
<zmatt>
gpio is just one particular pin function selectable via pinmux
<Angel_Sosa>
This is the education I am getting thats why I mentioned earlier the following pins P16.24, P18.17, P18.43, P.18.42 because I am walking into new territory
<zmatt>
my guess would be you're talking about the pins that just happen to be muxed to gpio mode by the weird default pin config done by u-boot (hopefully only old u-boot versions but I haven't verified it has been fixed)
<zmatt>
(I don't know if that's those pins, can't easily check since I fixed u-boot on my bbx15 to not do that)
<Angel_Sosa>
Thats why I am asking how via programming how do I access the following non GPIO pins P16.24, P18.17, P18.43, P.18.42? Which I am led to believe this is the only way to do it https://pastebin.com/MagZyG75. Would that be correct. And if it is I am looking for clear walk throughs
<zmatt>
I can probably make an example when I'm a bit more awake
<markand>
zmatt, ahh... yes it looks like...
<markand>
zmatt, yes I've changed to open and dprintf, but also what I do is to force unexport pins before trying to export
<zmatt>
markand: just don't try to export them if already exported
<zmatt>
better yet, use DT to export them instead of /sys/class/gpio/export
<zmatt>
(if you're using a beagleboard.org kernel)
<Angel_Sosa>
Its a good start . I see the pins mentioned below in the link are the BBB pins. I imagine i would substitute with one of these P16.24, P18.17, P18.43, P.18.42
<Angel_Sosa>
for the X15
<zmatt>
Angel_Sosa: for the bbx15 the same gpio-of-helper can be used to setup gpios, but pin configuration syntax is wildly different
<zmatt>
overlay-utils also uses different macros than mainline linux for the bbb, but I haven't added am572x pinmux support to overlay-utils
<zmatt>
like I said, I can make an example in a bit
buckket has quit [Quit: buckket]
<Angel_Sosa>
Thank you ZMatt. I used GPIO labeled pins as an example and I can see its a poor example. Forget about them for now. If I wanted to expose a pin including send and receive information to those pins as an example P16.24, P18.17, P18.43, P.18.42 ( these are labeled as three different types of pins ), how is it done, what is the process? A good
<Angel_Sosa>
example if possible would basic one that exposes the pin and then another that changes its function. Again thank you zmatt
<zmatt>
I have no idea what you're saying or asking... if you want to use pins for a different function than gpio you'll need to be more specific about which function (supported by those pins)
<zmatt>
but, brb
buckket has joined #beagle
<Angel_Sosa>
Can I just ask If I could get a good working example from start to finish exposing pins P16.24, P18.17, P18.43, P.18.42 so that I can right C code to communicate with these pins? I also need to know the C library used to communicate with these pins? I am also using the following spreadsheet as my reference
rcn-ee has quit [Remote host closed the connection]
xet7 has joined #beagle
rcn-ee has joined #beagle
<zmatt>
Angel_Sosa: I already said I was going to make an example
<zmatt>
Angel_Sosa: and again, if you want to use a particular function, you need to specify _which_ function. absent that information, I'm making an example for gpio
<Angel_Sosa>
Zmatt I appreciate your help. Of course I'll take the GPIO example and If you could create an example that repurposes the pin that would be great so for example repurpose P16.3 to provide spi functionality?
<zmatt>
Angel_Sosa: btw, if you currently have an u-boot that configures all sorts of weird pins by default, I strongly recommend you replace it by one that doesn't... the u-boot archive here contains the u-boot build I currently use myself + install script: https://liktaanjeneus.nl/bbx15/
<zmatt>
(alternatively, rcn probably has a script to update u-boot preinstalled somewhere in opt, and hopefully that will fix it too and will also get you overlay support... but I haven't tested that hypothesis, for the linked u-boot I can at least confirm it works for me)
xet7 has joined #beagle
<zmatt>
as with everything on the bbx15, be cautious with off-by-one errors, e.g. gpio0 is &gpio1 and uart0 (ttyS0) is &uart1
<zmatt>
on the am572x I should say
<zmatt>
the am335x dts only has an off-by-one for mmc devices (mmc0 = &mmc1) but people fortunately rarely need to reference those
<zmatt>
you can use an udev rule (https://pastebin.com/MMC6u7pR) to create symlinks for the gpios so that software also doesn't have to know anything about gpio numbers
<zmatt>
unless that's already installed, I don't remember if rcn made that part of his images
<zmatt>
Angel_Sosa: https://pastebin.com/MagZyG75 updated to include SPI. I've enabled two chip selects for spi 2 but if you only want one you can of course remove one of the slave device declarations and the pinmux of the corresponding chip select pin
<Angel_Sosa>
I had to step for a bit. Zmatt going back to your 11:39 post I keep my X15 pretty much stock. So no weird going on there. I will look and follow the link you posted
<zmatt>
I don't know what "stock" means
<zmatt>
stock = random firmware version
<zmatt>
also, stock probably means you have an old u-boot which does in fact have the problem I was tlaking about
<Angel_Sosa>
Stock meaning I have not re-configured UBoot in any way. I just use it pretty much how it ships in the image
<zmatt>
Angel_Sosa: yes, that probably means it's an old u-boot which does a ton of bogus pinmuxing
<zmatt>
what you want do see when you run show-pins is that expansion headers that you didn't explicitly configure yourself are listed as "unused" or perhaps as gpio
<rcn-ee>
Angel_Sosa, u-boot debian package is: bb-u-boot-am57xx-evm , run sudo /opt/u-boot/bb-u-boot-am57xx-evm/install.sh to update eMMC and microSD..
<zmatt>
rcn-ee: it has sane default pinmuxing now on the bbx15 ?
<zmatt>
yeah those are not sane defaults, those are defaults for the am572x-evm
<zmatt>
they're a hazard to anyone _not_ using the actual evm (specifically the lcd expansion board it puts onto the base board)
<rcn-ee>
zmatt, i'd like to move both am335x/am57xx on v2022.01 (next month) on the next update.. what do we need for a better default pinmux..
<Angel_Sosa>
I just downloaded and ran show-pins it executes directly
<Angel_Sosa>
it executes correctly
<zmatt>
rcn-ee: detect when a board is actually a bbx15 rather than an am572x and either don't mux the expansion header pins at all or at most mux them to gpio (for pins which have gpio function available)
<zmatt>
Angel_Sosa: ... why would it not "execute correctly" ?
<Angel_Sosa>
Just providing positive feedback for the information and the you are providing. What you are doing is wonderful. And your depth is humbling
<zmatt>
Angel_Sosa: but what's the conclusion from the output?
<zmatt>
(I already know the conclusion since I don't think there's been any u-boot build with sane defaults for the bbx15)
<zmatt>
but hopefully if you compare the output you get with what I get ( https://pastebin.com/raw/RNPEV9EJ ) you understand the point I was trying to make
<zmatt>
rcn-ee: yeah like I said, it's setting up pinmux for the am572x-evm (baseboard + expansion boards), a bad option for bbx15 users which will probably want to do their own configuration (via dt given that cape-universal hasn't been ported to x15)
<rcn-ee>
on the bright side, the only way to get that baseboard, is buy it as the kit from ti.. so moving to gpio only for mainline and u-boot and kernel should not break any real user.. the ti customers would probally bug e2e forums..
<rcn-ee>
(i don't have one to even test..)
<zmatt>
rcn-ee: if you can tell the evm baseboard from bbx15 then the current pinmux is suitable for the evm and bbx15 should be gpio-only
<rcn-ee>
SB_A never shipped, that was a indegoogo/project..
<zmatt>
ideal would be the actually detect the presence of the lcd board / camera board and make the muxing conditional on that, instead of assuming a particular baseboard will or won't have those expansions plugged in
<zmatt>
but dunno if TI was nice enough to make their presence easily identifiable
<rcn-ee>
seeing how ti has an eeprom for TDA5's expansion, i think they firgured out they messed up in a previous generation.. i didn't see any i2c expeansion eeprom during am57xx's TI kit..
<zmatt>
nmingotti: in /etc/udev/rules.d/81-pwm-noroot.rules check that the two rules below "# automatically export pwm channels" are not commented out
<zmatt>
(if they are, uncomment then, do "sudo update-initramfs -u" and reboot)
<nmingotti>
ok, let me check it out
<nmingotti>
yes, it worked ! but the pwm devices were placed into /dev/ instead of /dev/bone (minor issue)
<zmatt>
that'll depend on the version of overlays you have
<zmatt>
or sorry, udev rule
<nmingotti>
ok, i see if i can change it from there, thank you zmatt ! you are really the BB allmighty ! :)
<nmingotti>
another quick question, i have the fan cape, when i run the BB-AI with it it automatically loads BBORG_FAN-A000.dtbo. Is there a way to forbit it ? I prefer to control the fan speed with PWM myself
<zmatt>
yeah you can inhibit overlay autoloading of individual capes via /boot/uEnv.txt
<nmingotti>
ah, ok, i suupose it is : disable_uboot_overlay_addr0=PATH_OF_THE_OVERLAY
<zmatt>
just =1
<zmatt>
the cape to disable is selected based on slot (0..3), not overlay name
<nmingotti>
i see, how can i determine the correct number ?
<zmatt>
good question
<zmatt>
it's based on the eeprom address of the cape, which is selectable on some capes
<nmingotti>
i imagine the smaller cape number goes to *addr0=1. Then can i see the eeprom cape address somehow via shell ?
<zmatt>
I'm pretty sure there's a script to check which capes there are, but you should also be able to determine manually which of the four i2c devices is present
<nmingotti>
ooooh, they comunicate via i2c, and it is the i2c address who rules ?
<zmatt>
on the BBB it looks like all four (address 0x54..0x57, on i2c bus 2 on the BBB but that'll probably be a different bus on the bbai) show up in /sys/bus/i2c/devices, but since I don't have any capes they don't seem to probe hence don't have an eeprom attribute nor an nvmem device in /sys/bus/nvmem/devices/
<nmingotti>
i need to leave now, i will check it carefully later ! thanks again !
lucascastro has quit [Ping timeout: 250 seconds]
zjason` has joined #beagle
zjason has quit [Ping timeout: 268 seconds]
otisolsen70 has quit [Quit: Leaving]
<nmingotti>
hi zmatt, i'm back, i have the FAN cape loaded, if you want i can try stuff
<rcn-ee>
nmingotti, the fan cape only disables 400Mhz option, what would you like it to do?
<nmingotti>
hi rcn-ee, i am not able with my current knowledge of controlling the fan speed of the cape. I don't know if it is at all possible.
<nmingotti>
so, i have 2 objectives
<rcn-ee>
nmingotti, digging for a schmeatic.. let's just say beyond disabling 400mhz i never looked much further, honestly thought the fan was on a 5vcc rail..
<rcn-ee>
they say: [This Fan Cape uses a PIC16F15313 to emulate the Cape EEPROM, provide PWM to the fan, read temperature sensors, and read the jumper input.]...
<nmingotti>
1. Disable the cape (in the meanwhile learn how to do it in general) and hook it up in a PWM controlled by the BBAI
<rcn-ee>
nmingotti, no reason to disable it..
<rcn-ee>
do an i2c probe, see if you read anything on that address...
<nmingotti>
yes, i am familiar with those statements ... but i don't know memory locations to make the tweaks
<nmingotti>
address should be 57
<rcn-ee>
me neither...
<nmingotti>
yes, that is the problem, it is a pity ... but maybe you can understand something from the cape DTS , for me it is obscure
<nmingotti>
yes zmatt, it was just to complete my knowledge ;) well, to get it started
<rcn-ee>
this overlay just removes it...
<rcn-ee>
the 'other' node is just a userspace hint... hey this overlay is loaded..
<zmatt>
rcn-ee: can't you set opp-supported-hw to something indicating the mode isn't supported? instead of redefining its clock frequency and voltages
<rcn-ee>
it's actually a clone of 1Ghz... the opp latey automaticly nukes it as a copoy..
<zmatt>
ah
<zmatt>
it would be nice if overlays supported /delete-node/
<rcn-ee>
exactly! someday!!
<zmatt>
(and /delete-property/)
<rcn-ee>
and the PI firmware as a nice extension... on device A -> option 1 on device B -> option 2
<rcn-ee>
that's against dtc mainline kernel rules...
<zmatt>
oh noes
<zmatt>
it does sound unnecessary?
<zmatt>
like, what's the point of that instead of just loading the appropriate dtb?
<rcn-ee>
that helps them migrate to newer devices without breaking old overlays, with completely different perhiperal numbers..
<zmatt>
uhh, I don't get that... overlays reference nodes by lable
<zmatt>
*label
<zmatt>
but I have no experience with the pi, so *shrug*
<rcn-ee>
it's a cheap 8GB arm64 builder after my apm-mustang finally gave up..
<rcn-ee>
nmingotti, i can't find any more info on the fan cape, it kinda got developed by a group, who's corporate owner got in feud with TI a few years back.. Thus head company no longer sells TI products to it's customers..
<rcn-ee>
we moved Everything to Seeed shortly after..
<nmingotti>
@rcn-ee it is a pity there is schematics but not the documentation of the few needed memory location to tweak. The master way should be to do that, but i can go the PWM way. Unfortunately the thing is very noisy at 5V, but at 3.XV it is acceptable.
<rcn-ee>
nmingotti, we all agree the fan is a noisy pos.. ;) it won't happen again, i've been pushing a solid chunk of aluminum for hte next version of any board we do..
<zmatt>
I don't suppose the firmware source code is around?
<nmingotti>
@zmatt, and maybe some red fish as well ;)
<nmingotti>
... the idea it not so creazy, the more i laugh, the more i like it: "forniture computing"
<nmingotti>
btw, how difficult is it to get root access to a BB ? Consider i may glue the SD-card slot and chop out the JTAG. Or cover with glue also other parts if necessary. I have some code in Python, some Node and eventually there will be Smalltalk. It would be annoying to rewrite in C++ just to hide the code.
Shadyman has joined #beagle
<nmingotti>
well, more than root, acccess, how difficult would be to read the data in eMMC (with the above measures taken)
<zmatt>
I mean, that might be a problem, or at least an annoyance, to a low-skill attacker or someone who only has access to the device for a very limited amount of time
<rcn-ee>
nmingotti, protect, J1 (serial), USB (otg) and all the sysboot pins... that would be the hardware access methods easy to get in..
<nmingotti>
consider, i don't need military secrecy, just not too make copy/paste of the code too easy
<zmatt>
usb only matters if an usb gadget is configured of course
<rcn-ee>
nmingotti, the bootrom on the am335x allows you to boot from many fun sources, that are pretty easy to get into...
<zmatt>
and you could rebuild u-boot to require a password to get access to the u-boot cli
<zmatt>
he's using a bbai right? not am335x
<zmatt>
but yeah, you do need to protect the sysboot pins
<zmatt>
on the BBB the eMMC is even easier to access since it's pinned out directly to the expansion headers
<rcn-ee>
ah, bbai, does have the usb-eth boot mode we had on the am335x... (that's the one i was thinking about on usb otg..)
<rcn-ee>
...does it have..
<zmatt>
dunno, but it shouldn't matter if you protect the sysboot pins, which you should anyway
<nmingotti>
umm, well i uses abundantly USB otg ethernet, i ssh there. Do i need to cut it ?
<zmatt>
I think it does have an usb boot mode iirc, although it works differently
<zmatt>
nmingotti: usb-networking should be safe, or at least as safe as networking in general, i.e. securable if you know what you're doing
<zmatt>
but the default usb gadget also has a usb serial port
<rcn-ee>
nmingotti, normal linux usb is fine... it's the built-in "rom" boot that am335x eanbled, you could boot into a usb target linux over the usb port..
<rcn-ee>
perfect for copying an eMMC. ;)
<nmingotti>
as i remember from RobertNelson wrote somewhere that the fancy boots methods are disabled by default, but i need to double check
<zmatt>
and yeah, boot methods... but if you can mess with sysboot you can also netboot via ethernet, at least on the am335x (can't remember for the am572x)
<zmatt>
all boot methods are selectable if you can influence the sysboot pins
<nmingotti>
i can use both the Black and the AI, the AI is faster so i would prefer it for the Smalltalk part
<rcn-ee>
if you hard lock the sysboots pins it gets rid of most of hte issues..
<zmatt>
of course that may be easier said than done
<zmatt>
on the BBB at least... the BBAI ones are easier to secure I think?
<zmatt>
since they're not connected to expansion header pins there
<zmatt>
anyway, zZ
<zmatt>
g'night all
<rcn-ee>
there are ecc608 chips.. but in the end, is security important?
<rcn-ee>
night!
<rcn-ee>
nmingotti, you could do something with the no-board i2c eeprom, custom build of u-boot and an encrypted filesystem..
<nmingotti>
i am collecting ideas, your suggestions are important ;) I will study all of them
<rcn-ee>
as i said that... the on-board i2c doesn't exist on the bbai.. that in the next version... so ah crap...
<nmingotti>
no, in this case i don't need to hide secret math formulas, but in a next machine i may need so i am getting warm ;)
<rcn-ee>
maybe the 'key' could be on your cape... u-boot on the am57xx reads the 'key' and un-encrypts the eMMC...
<nmingotti>
yes, kind of an old styled hardware key
<rcn-ee>
they'd have to buy your cape! ;)
<nmingotti>
muhahaahh, i sell it only in package with a large machine
<nmingotti>
they are welcome
<rcn-ee>
50cent door lock. ;)
<rcn-ee>
eh.. you have a lot of i/o on the cape, that wouldn't work...
<rcn-ee>
each am335x/am57xx has a fused mac address... you can use that as a 'registration...
<nmingotti>
uuuuu, this is cool info, i dreamed of that in web programming
<nmingotti>
umm, wait, oh, nop nope, the macaddress it easy to fake in linux
<zmatt>
if they already have access to your system you've already lost
<nmingotti>
is there any other serial number inside the BB i can read ?
<zmatt>
oh right, I was going to sleep
<nmingotti>
zmatt, good night, thank you for your help ! A pizza on me if you came to italy !
<rcn-ee>
nmingotti, while it's easy to fake, you could build a serial number based on that hash and the user's info?? basically lock the software image to one BBB/BBAI... they could try to copy everything, but it's locked to that internal efuse and their serial number...
<rcn-ee>
so your base os is locked to the cape, once user purchases devcie and enables it with a key, that user specific stuff is now also encrypted with the key..
<nmingotti>
i need to think well about it ... still i have some time
<nmingotti>
thank you for your help guys, here 01:00 am, time to leave the office, good night