**** BEGIN LOGGING AT Tue Dec 28 02:59:56 2021 Dec 28 03:22:53 it is so disappointing that so many pins are wasted on the analog in on the pocket beagle Dec 28 04:04:45 I mean, many pins in general are wasted on the pocketbeagle... that's just the trade-off for its tiny size Dec 28 04:35:40 What I struggle with is judt finding what is availalble and solid documentation on how to alter the pins on the X15 Dec 28 04:37:16 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 Dec 28 05:01:47 it just hasn't received quite as much attention Dec 28 05:11:27 the ADC on 335x just blows chunks Dec 28 05:11:41 bringing out more of the PRU would at least enable more soft peripherals Dec 28 11:12:37 our old application export pins using the deprecated /sys/class/gpio/export API Dec 28 11:13:16 basically fopen + fprintf, sometimes the pin does not appear in /sys/class/gpio for some reasons... Dec 28 11:13:32 while a simple echo 44 > /sys/class/gpio/export works fine... Dec 28 11:23:26 is there a limit of exports? we open in order: 44, 22, 45, 65, 61 Dec 28 11:23:40 sometimes the program exports the 44 fines, sometimes the 22 is visible but not always both at the same time Dec 28 12:03:57 https://bpa.st/TRSA Dec 28 12:04:05 I really don't get it D: Dec 28 13:30:35 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 Dec 28 13:34:06 is it possible to load the universal cape in BB-AI ? If so, how do i do it ? Dec 28 13:49:28 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? Dec 28 13:49:47 markand: also, I recommend using open()+write() rather than fopen()+fwrite() since sysfs attributes do not behave like normal files Dec 28 13:51:07 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 Dec 28 13:53:57 Its more newbie information in my case Dec 28 13:54:27 nmingotti: I *think* that should work in the testing images Dec 28 13:54:48 Just so you know Using C++ or C is to open and close sysfs files is not my issue Dec 28 13:54:50 Angel_Sosa: yeah it's possible cape-universal just has never been ported to the x15, in which case pinmux requires an overlay Dec 28 13:55:01 Angel_Sosa: I was talking to markand, not you Dec 28 13:55:26 Ok Dec 28 13:56:24 I'll standby Dec 28 13:57:16 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 Dec 28 13:59:07 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 Dec 28 13:59:29 @zmatt, ok thanks, i will put it in my notes and check it out Dec 28 14:00:32 Angel_Sosa: yeah originally it required a custom dtb, e.g. something like https://pastebin.com/MagZyG75 Dec 28 14:00:47 which is the only mechanism supported by mainline linux and mainline u-boot Dec 28 14:01:28 if you're using a recent enough image, overlays should work as well, which allows keeping customizations separate from the base dtb Dec 28 14:01:42 (hence also avoiding the need to rebuild the custom dtb after every kernel update) Dec 28 14:02:20 runtime configuration of pins via sysfs requires cape-universal, which like I said might never have been ported to the bbx15 Dec 28 14:04:36 zmatt I use sysfs to reconfigure for example P16.3 and P16. 4 Dec 28 14:04:52 ?? Dec 28 14:05:08 what do you mean? Dec 28 14:05:33 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 Dec 28 14:07:34 It just like on the BB Black it works P16.3 is GPIO4_17 = ( BB Math to access pins on headers ) = GPIO113 Dec 28 14:08:11 export 113 and its available to raise and lower the pin Dec 28 14:08:38 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 ... Dec 28 14:08:44 ...doesn't support overlays and requires the use of a custom dtb Dec 28 14:08:52 okay but controlling a gpio has nothing to do with pinmux configuration Dec 28 14:09:27 gpio is just one particular pin function selectable via pinmux Dec 28 14:10:24 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 Dec 28 14:11:24 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) Dec 28 14:12:09 (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) Dec 28 14:13:30 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 Dec 28 14:14:32 I can probably make an example when I'm a bit more awake Dec 28 14:15:13 zmatt, ahh... yes it looks like... Dec 28 14:15:36 zmatt, yes I've changed to open and dprintf, but also what I do is to force unexport pins before trying to export Dec 28 14:16:06 markand: just don't try to export them if already exported Dec 28 14:16:24 better yet, use DT to export them instead of /sys/class/gpio/export Dec 28 14:16:53 (if you're using a beagleboard.org kernel) Dec 28 14:18:00 (e.g. https://github.com/mvduin/overlay-utils/blob/master/gpio-demo.dtsi ) Dec 28 14:21:27 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 Dec 28 14:21:47 for the X15 Dec 28 14:22:09 Angel_Sosa: for the bbx15 the same gpio-of-helper can be used to setup gpios, but pin configuration syntax is wildly different Dec 28 14:23:18 overlay-utils also uses different macros than mainline linux for the bbb, but I haven't added am572x pinmux support to overlay-utils Dec 28 14:24:37 like I said, I can make an example in a bit Dec 28 14:31:24 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 Dec 28 14:31:25 example if possible would basic one that exposes the pin and then another that changes its function. Again thank you zmatt Dec 28 14:32:52 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) Dec 28 14:32:56 but, brb Dec 28 15:00:14 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 Dec 28 15:00:14 https://docs.google.com/spreadsheets/d/1mSqEpV_BAUHfeNApytxHcGhgTZwypy564GyOr66Nphs/edit#gid=108520837. Towards the right starting with column N of the spreadsheet is the function each pin supports. I also for as an example how to provision a pin from its original function to a new assigned function. Dec 28 15:24:20 Angel_Sosa: I already said I was going to make an example Dec 28 15:25:08 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 Dec 28 15:33:10 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? Dec 28 15:36:05 This is the spreadsheet I am using https://docs.google.com/spreadsheets/d/1mSqEpV_BAUHfeNApytxHcGhgTZwypy564GyOr66Nphs/edit#gid=108520837 row number 5, column Q on the spreadsheet Dec 28 15:36:20 Again Thanks Zmatt Dec 28 15:39:07 yeah you don't need to keep repeating that link, it's my own spreadsheet Dec 28 16:37:42 Angel_Sosa: https://pastebin.com/MagZyG75 no spi yet but does show gpio Dec 28 16:39:13 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/ Dec 28 16:40:16 (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) Dec 28 16:44:47 as with everything on the bbx15, be cautious with off-by-one errors, e.g. gpio0 is &gpio1 and uart0 (ttyS0) is &uart1 Dec 28 16:44:53 on the am572x I should say Dec 28 16:45:25 the am335x dts only has an off-by-one for mmc devices (mmc0 = &mmc1) but people fortunately rarely need to reference those Dec 28 16:46:09 using the provided macros for gpios (https://pastebin.com/rELLdW1k) avoids having to think about it Dec 28 16:47:23 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 Dec 28 16:47:52 unless that's already installed, I don't remember if rcn made that part of his images Dec 28 17:15:43 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 Dec 28 17:16:17 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 Dec 28 17:16:29 I don't know what "stock" means Dec 28 17:16:48 stock = random firmware version Dec 28 17:17:00 also, stock probably means you have an old u-boot which does in fact have the problem I was tlaking about Dec 28 17:17:26 *random image version Dec 28 17:18:36 Angel_Sosa: you can confirm pinmux using https://github.com/mvduin/bbb-pin-utils/tree/bbx15-experimental#show-pins Dec 28 17:19:00 Stock meaning I have not re-configured UBoot in any way. I just use it pretty much how it ships in the image Dec 28 17:19:24 Angel_Sosa: yes, that probably means it's an old u-boot which does a ton of bogus pinmuxing Dec 28 17:20:23 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 Dec 28 17:21:59 let me run show-pins Dec 28 17:22:12 Angel_Sosa: e.g., with the u-boot build I linked + my example custom dts, I have: https://pastebin.com/raw/RNPEV9EJ Dec 28 17:23:07 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.. Dec 28 17:23:30 rcn-ee: it has sane default pinmuxing now on the bbx15 ? Dec 28 17:24:26 it's this branch: https://github.com/beagleboard/u-boot/tree/v2021.04-bbb.io-am57xx Dec 28 17:25:00 zmatt, whatever u-boot v2021.04 defaulted to as pinmux.. https://github.com/beagleboard/u-boot/commits/v2021.04-bbb.io-am57xx Dec 28 17:25:40 yeah those are not sane defaults, those are defaults for the am572x-evm Dec 28 17:26:21 they're a hazard to anyone _not_ using the actual evm (specifically the lcd expansion board it puts onto the base board) Dec 28 17:27:02 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.. Dec 28 17:27:35 I just downloaded and ran show-pins it executes directly Dec 28 17:27:45 it executes correctly Dec 28 17:28:09 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) Dec 28 17:28:29 Angel_Sosa: ... why would it not "execute correctly" ? Dec 28 17:28:30 this is the mux when bbai or bbx25: https://github.com/u-boot/u-boot/blob/master/board/ti/am57xx/mux_data.h Dec 28 17:29:21 https://github.com/u-boot/u-boot/blob/master/board/ti/am57xx/board.c#L814 Dec 28 17:31:20 Just providing positive feedback for the information and the you  are providing. What you are doing is wonderful. And your depth is humbling Dec 28 17:31:58 Angel_Sosa: but what's the conclusion from the output? Dec 28 17:32:37 (I already know the conclusion since I don't think there's been any u-boot build with sane defaults for the bbx15) Dec 28 17:33:29 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 Dec 28 17:35:20 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) Dec 28 17:38:03 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.. Dec 28 17:38:29 (i don't have one to even test..) Dec 28 17:39:02 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 Dec 28 17:39:11 (and gpioless pins left unmuxed) Dec 28 17:40:11 rcn-ee: this was my fix: https://github.com/dutchanddutch/u-boot/commit/3e515ed6ef4e3b4c296c4b0b70da727f1e856017 Dec 28 17:40:37 https://github.com/u-boot/u-boot/blob/master/board/ti/am57xx/board.c#L866 board_is_am572x_evm_reva3 -> TI's "x15"... Dec 28 17:41:17 so we just need to spit that if to only rev1 and revc for us, and leave reva3 alone.. Dec 28 17:41:25 rev1 -> revb1 Dec 28 17:41:45 if those truly only match the bbx15 Dec 28 17:41:51 the evm never had any revision after a3 ? Dec 28 17:42:26 https://www.ti.com/tool/TMDSEVM572X#design-files ... "Rev. C" Dec 28 17:42:30 i have one TI x15, that's what it comes up as.. Dec 28 17:43:46 ugh, dsn files... Dec 28 17:43:59 oh the baseboard is still A3a Dec 28 17:44:13 the "Schematic" download is pdf Dec 28 17:45:23 so the "A3" didn't pass FCC...i see the current "measurement" connector, that got nuked in the FCC re-pcb-do, that became RevC.. Dec 28 17:46:53 anyone want to bug Gerald? revC didn't make github... Dec 28 17:46:59 https://github.com/beagleboard/beagleboard-x15 Dec 28 17:49:08 Angel_Sosa: anyway, until there's a newer u-boot with okay defaults, I'd suggest using https://liktaanjeneus.nl/bbx15/u-boot-2017.01-00468-g506adcc7f880.tar.xz Dec 28 17:49:18 (install script included) Dec 28 17:50:08 rcn-ee: I mean, what matters isn't really the schematic but what's in the eeprom Dec 28 17:50:46 of the various versions of bbx15 and am572x Dec 28 17:50:48 -evm Dec 28 17:51:34 looks at github, yay i saved the a3 eeprom: https://github.com/RobertCNelson/boot-scripts/tree/master/device/x15 Dec 28 17:51:49 SB_A never shipped, that was a indegoogo/project.. Dec 28 17:52:36 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 Dec 28 17:52:58 but dunno if TI was nice enough to make their presence easily identifiable Dec 28 17:53:53 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.. Dec 28 17:54:02 (tda4...) Dec 28 17:55:25 looks like am571xz idk as a lcd detect.. https://github.com/u-boot/u-boot/blob/master/board/ti/am57xx/board.c#L877 Dec 28 19:23:19 I am trying to load BONE-PWM1.dtbo via uEnv in BB-AI , which should work according to this page : https://elinux.org/Beagleboard:BeagleBone_cape_interface_spec . But I don't see the device /dev/bone/pwm after reboot. Dec 28 19:24:20 any suggestion ? Dec 28 19:25:40 maybe an udev rules issue? Dec 28 19:27:05 nmingotti: in /etc/udev/rules.d/81-pwm-noroot.rules check that the two rules below "# automatically export pwm channels" are not commented out Dec 28 19:27:29 (if they are, uncomment then, do "sudo update-initramfs -u" and reboot) Dec 28 19:27:58 ok, let me check it out Dec 28 19:32:29 yes, it worked ! but the pwm devices were placed into /dev/ instead of /dev/bone (minor issue) Dec 28 19:32:42 that'll depend on the version of overlays you have Dec 28 19:32:47 or sorry, udev rule Dec 28 19:34:02 ok, i see if i  can change it from there, thank you zmatt ! you are really the BB allmighty ! :) Dec 28 19:47:40  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 Dec 28 19:49:01 yeah you can inhibit overlay autoloading of individual capes via /boot/uEnv.txt Dec 28 19:50:27 ah, ok, i suupose it is : disable_uboot_overlay_addr0=PATH_OF_THE_OVERLAY Dec 28 19:50:54 just =1 Dec 28 19:51:16 the cape to disable is selected based on slot (0..3), not overlay name Dec 28 19:52:43 i see, how can i determine the correct number ? Dec 28 19:53:38 good question Dec 28 19:53:51 it's based on the eeprom address of the cape, which is selectable on some capes Dec 28 19:55:29 i imagine the smaller cape number goes to *addr0=1. Then can i see the eeprom cape address somehow via shell ? Dec 28 19:56:53 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 Dec 28 19:58:04 ooooh, they comunicate via i2c, and it is the i2c address who rules ? Dec 28 19:58:16 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/ Dec 28 19:58:57 i need to leave now, i will check it carefully later ! thanks again ! Dec 28 21:34:54 hi zmatt, i'm back, i have the FAN cape loaded, if you want i can try stuff Dec 28 22:12:53 nmingotti, the fan cape only disables 400Mhz option, what would you like it to do? Dec 28 22:14:03 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. Dec 28 22:14:37 so, i have 2 objectives Dec 28 22:14:51 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.. Dec 28 22:15:19 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.]... Dec 28 22:15:19 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 Dec 28 22:15:35 nmingotti, no reason to disable it.. Dec 28 22:15:49 do an i2c probe, see if you read anything on that address... Dec 28 22:16:00 yes, i am familiar with those statements ... but i don't know memory locations to make the tweaks Dec 28 22:16:21 address should be 57 Dec 28 22:16:23 me neither... Dec 28 22:17:38 yes, that is the problem, it is a pity ... but maybe you can understand something from the cape DTS , for me it is obscure Dec 28 22:17:51 it is very short Dec 28 22:18:10 &{/chosen} { Dec 28 22:18:10         overlays { Dec 28 22:18:11                 BBORG_FAN-A000.kernel = __TIMESTAMP__; Dec 28 22:18:11         }; Dec 28 22:18:12 }; Dec 28 22:18:13 &cpu0_opp_table { Dec 28 22:18:13         opp_slow-400000000 { Dec 28 22:18:14                 opp-hz = /bits/ 64 <1000000000>; Dec 28 22:18:14                 opp-microvolt = <1060000 850000 1150000>, Dec 28 22:18:15                                 <1060000 850000 1150000>; Dec 28 22:18:15                 opp-supported-hw = <0xFF 0x01>; Dec 28 22:18:16                 opp-suspend; Dec 28 22:18:16         }; Dec 28 22:18:17 }; Dec 28 22:19:38 nmingotti, use pastebin... Dec 28 22:19:57 okis Dec 28 22:20:01 it's very short, as it only disables the 400mhz node.. Dec 28 22:20:10 it does nothing to anything else.. Dec 28 22:20:40 opp_slow-400000000 is a hack Jason did, this "overlay" un-doo's the hack, so when booted, you'll notice 400mhz node is gone.. Dec 28 22:20:45 i hoped into that "opp_hz" but i guess i was wrong Dec 28 22:21:18 yeah there's no reason to disable this overlay, it does nothing fan-related Dec 28 22:21:40 nmingotti, here is the "hack" jason did to help the bbai's NOT overheat with no cooling: https://github.com/beagleboard/BeagleBoard-DeviceTrees/blob/v4.19.x-ti-overlays/src/arm/am5729-beagleboneai.dts#L1053-L1062 Dec 28 22:21:43 yes zmatt, it was just to complete my knowledge ;) well, to get it started Dec 28 22:21:44 this overlay just removes it... Dec 28 22:22:09 the 'other' node is just a userspace hint... hey this overlay is loaded.. Dec 28 22:22:21 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 Dec 28 22:22:42 it's actually a clone of 1Ghz... the opp latey automaticly nukes it as a copoy.. Dec 28 22:22:48 ah Dec 28 22:22:53 it would be nice if overlays supported /delete-node/ Dec 28 22:23:34 exactly! someday!! Dec 28 22:23:46 (and /delete-property/) Dec 28 22:24:33 and the PI firmware as a nice extension... on device A -> option 1 on device B -> option 2 Dec 28 22:24:54 that's against dtc mainline kernel rules... Dec 28 22:25:17 oh noes Dec 28 22:25:40 it does sound unnecessary? Dec 28 22:25:58 like, what's the point of that instead of just loading the appropriate dtb? Dec 28 22:26:02 that helps them migrate to newer devices without breaking old overlays, with completely different perhiperal numbers.. Dec 28 22:26:26 uhh, I don't get that... overlays reference nodes by lable Dec 28 22:26:27 *label Dec 28 22:27:27 but I have no experience with the pi, so *shrug* Dec 28 22:28:34 it's a cheap 8GB arm64 builder after my apm-mustang finally gave up.. Dec 28 22:30:59 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.. Dec 28 22:31:16 we moved Everything to Seeed shortly after.. Dec 28 22:34:09  @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. Dec 28 22:35:37 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.. Dec 28 22:36:49 I don't suppose the firmware source code is around? Dec 28 22:36:58 nmingotti, if you can cut some metal, something like: https://www.seeedstudio.com/Black-Warrior-ICE-Tower-CPU-Cooling-Fan-for-Raspberry-Pi-Support-Pi-4-p-4319.html (don't really need the fan) would work awesome... but the mount needs to be done.. Dec 28 22:37:00 from what i see it was developed by Jason Kridner, i may try to send him a mail Dec 28 22:37:06 zmatt, i can't even find the schmatic! Dec 28 22:37:27 nmingotti, he's on vacation, -> @jkridner Dec 28 22:38:00 rcn-ee, ok, so i will not disturb Dec 28 22:38:29 schematic ... saw it several times around, let me see Dec 28 22:41:44 rcn-ee: nonono, i can't put such big stuff, i have a very nice thing on the top of my BB(B|AI) which i love, let me show you:  https://czh-labs.com/products/czh-labs-screw-terminal-block-breakout-board-module-for-beaglebone Dec 28 22:42:10 yeah that would break your design.. Dec 28 22:43:12 but also, this thing czh-labs thingy covers the BB-AI and makes a fan a strict requirement Dec 28 22:44:42 just immerse it in cooling liquid ;) Dec 28 22:45:38 foun the skema for FAN cape, and a very nice description, there miss only the info i need ;) https://www.elektormagazine.com/labs/fan-cape-for-beaglebone-ai Dec 28 22:47:57 @zmatt, and maybe some red fish as well ;) Dec 28 22:49:01 ... the idea it not so creazy, the more i laugh, the more i like it: "forniture computing" Dec 28 22:52:48 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. Dec 28 22:53:42 well, more than root, acccess, how difficult would be to read the data in eMMC (with the above measures taken) Dec 28 22:55:49 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 Dec 28 22:58:37 nmingotti, protect, J1 (serial), USB (otg) and all the sysboot pins... that would be the hardware access methods easy to get in.. Dec 28 23:00:10 consider, i don't need military secrecy, just not too make copy/paste of the code too easy Dec 28 23:00:34 usb only matters if an usb gadget is configured of course Dec 28 23:01:03 nmingotti, the bootrom on the am335x allows you to boot from many fun sources, that are pretty easy to get into... Dec 28 23:01:12 and you could rebuild u-boot to require a password to get access to the u-boot cli Dec 28 23:01:18 he's using a bbai right? not am335x Dec 28 23:01:32 but yeah, you do need to protect the sysboot pins Dec 28 23:01:54 on the BBB the eMMC is even easier to access since it's pinned out directly to the expansion headers Dec 28 23:02:00 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..) Dec 28 23:02:06 ...does it have.. Dec 28 23:02:24 dunno, but it shouldn't matter if you protect the sysboot pins, which you should anyway Dec 28 23:02:35 umm, well i uses abundantly USB otg ethernet, i ssh there. Do i need to cut it  ? Dec 28 23:02:37 I think it does have an usb boot mode iirc, although it works differently Dec 28 23:03:16 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 Dec 28 23:03:39 but the default usb gadget also has a usb serial port Dec 28 23:03:47 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.. Dec 28 23:04:01 perfect for copying an eMMC. ;) Dec 28 23:04:15 as i remember from RobertNelson wrote somewhere that the fancy boots methods are disabled by default, but i need to double check Dec 28 23:04:15 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) Dec 28 23:04:38 all boot methods are selectable if you can influence the sysboot pins Dec 28 23:04:43 i can use both the Black and the AI, the AI is faster so i would prefer it for the Smalltalk part Dec 28 23:04:43 if you hard lock the sysboots pins it gets rid of most of hte issues.. Dec 28 23:05:10 of course that may be easier said than done Dec 28 23:06:02 on the BBB at least... the BBAI ones are easier to secure I think? Dec 28 23:06:12 since they're not connected to expansion header pins there Dec 28 23:07:20 anyway, zZ Dec 28 23:07:26 g'night all Dec 28 23:07:31 there are ecc608 chips.. but in the end, is security important? Dec 28 23:07:32 night! Dec 28 23:08:16 nmingotti, you could do something with the no-board i2c eeprom, custom build of u-boot and an encrypted filesystem.. Dec 28 23:08:50 i am collecting ideas, your suggestions are important ;) I will study all of them Dec 28 23:09:26 as i said that... the on-board i2c doesn't exist on the bbai.. that in the next version... so ah crap... Dec 28 23:09:42 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 ;) Dec 28 23:09:51 maybe the 'key' could be on your cape... u-boot on the am57xx reads the 'key' and un-encrypts the eMMC... Dec 28 23:10:28 yes, kind of an old styled hardware key Dec 28 23:10:42 they'd have to buy your cape! ;) Dec 28 23:11:09 muhahaahh, i sell it only in package with a large machine Dec 28 23:11:29 they are welcome Dec 28 23:11:30 50cent door lock. ;) Dec 28 23:11:56 eh.. you have a lot of i/o on the cape, that wouldn't work... Dec 28 23:12:34 each am335x/am57xx has a fused mac address... you can use that as a 'registration... Dec 28 23:13:07 uuuuu, this is cool info, i dreamed of that in web programming Dec 28 23:13:48 umm, wait, oh, nop nope, the macaddress it easy to fake in linux Dec 28 23:14:19 if they already have access to your system you've already lost Dec 28 23:14:20 is there any other serial number inside the BB i can read ? Dec 28 23:14:37 oh right, I was going to sleep Dec 28 23:15:24 zmatt, good night, thank you for your help ! A pizza on me if you came to italy ! Dec 28 23:21:09 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... Dec 28 23:23:05 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.. Dec 28 23:26:00 i need to think well about it ... still i have some time Dec 28 23:27:30 thank you for your help guys, here 01:00 am, time to leave the office, good night **** ENDING LOGGING AT Wed Dec 29 02:59:56 2021