**** BEGIN LOGGING AT Sun Oct 27 02:59:57 2019 Oct 27 11:39:27 hi Oct 27 11:40:07 please I have a circuitco beaglebone black revision B with am3358 chip on it, what is the debian distro to run on it? Oct 27 11:40:11 Thanks Oct 27 11:43:43 Posterdati: see https://beagleboard.org/latest-images Oct 27 11:44:37 I used debian 9.9 both images, but it won't boot Oct 27 11:45:06 how did you find out that it does not boot? Oct 27 11:45:27 I dd onto an sd card and placed in the board and it won't boot Oct 27 11:48:01 I think there's no uboot on those images Oct 27 11:48:35 doubt Oct 27 11:49:19 so it won't boot Oct 27 11:51:29 Posterdati: which leds do you see? Oct 27 11:52:10 also does it boot without the sd card? Oct 27 11:53:34 no leds Oct 27 11:53:40 only power led Oct 27 11:53:50 it does not boot without sd card Oct 27 11:55:09 I connected the USB cable and does nothing in the terminal (115200 8n1) Oct 27 11:59:04 Posterdati: what do you have attached to it and what power source are you using? Oct 27 12:03:20 usb Oct 27 12:04:37 and 5V 2.5A psu Oct 27 12:07:37 seems dead Oct 27 12:09:38 or the emmc is empty Oct 27 12:10:06 did you try to hold the power button on start? Oct 27 12:10:18 also I would start to measure the power rails.. Oct 27 12:10:19 there's only a reset button Oct 27 12:11:25 the black should have two Oct 27 12:11:35 uhm three Oct 27 12:12:10 reset, boot, power Oct 27 12:12:31 it is a circuitco beaglebone rev. B Oct 27 12:12:40 an3358 Oct 27 12:12:45 am3358 Oct 27 12:20:22 aah beaglebone, that one has no emmc Oct 27 12:21:36 uhm, just confused with the pocket one, sorry, beaglebone rev b is probably the black Oct 27 12:22:37 yes even if there's no indication on the box Oct 27 12:30:40 should be something in /boot/ Oct 27 12:30:44 to boot the board Oct 27 12:32:28 https://elinux.org/File:BeagleBone_256x249.jpg Oct 27 12:57:52 :( Oct 27 12:59:51 Posterdati: is that the original beaglebone? (the white) Oct 27 13:01:01 circuitco, bought from farnel Oct 27 13:17:16 Humpelst1lzchen: https://elinux.org/File:BeagleBone_256x249.jpg Oct 27 14:03:23 zmatt: for P8.15, I'm thinking of enabling gpio4_3 on ball D1 with a pull-down and pr1_pru1_gpi16 on ball A3, but I'm thinking I'd disable the pull-down on A3 to avoid a lower-than-expected impedance. Oct 27 14:12:46 zmatt: looking to do the same on p8.27,28,29,30 Oct 27 14:19:00 Posterdati: uhh that's an image of an ancient beaglebone white, those aren't sold anymore Oct 27 14:19:48 oh you didn't say you just bought them, nm, I just woke up Oct 27 14:20:02 Posterdati: the latest image should still work on it though (booting from sd card), odd Oct 27 14:23:16 jkridner: sounds fine, you obviously only need pull on one of the two pins Oct 27 14:23:54 k. I'm opting to use the pull-down on the gpio. Oct 27 14:24:05 hope to finish this round up soon. Oct 27 14:24:13 any chance you'll be at ELC-E this week? Oct 27 14:24:50 nope Oct 27 14:27:41 jkridner: as for the power management thing I found, I made a quick userspace utility to inspect and fiddle with the setting => https://liktaanjeneus.nl/bbx15/omap5-cpu-prcm.tar.gz Oct 27 14:27:59 jkridner: running it with --retention cools my bbx15 by about 10 degrees when idle Oct 27 14:28:23 is it not something that should just be put in the kernel? Oct 27 14:28:31 jkridner: though obviously this is just a hack for testing, it's not something that should be messed with by userspace Oct 27 14:28:34 absolutely Oct 27 14:28:39 and there already is kernel code to manage this setting Oct 27 14:28:58 so the question is why does it configure mpuss in a way that disallows it to enter any sort of lower power state Oct 27 14:29:19 could it be a performance thing? Oct 27 14:29:54 easiest way for me to follow-up is for there to be an e2e.ti.com entry, then I can escalate it for a good answer. Oct 27 14:32:58 I'm curious about SPI driving defaults. all signals are bi-directional, so they might start idle, but I'm not sure how the kernel leaves them configured when the driver is marked "okay". if the spidev driver is enabled, I'd assume the clk, mosi and cs lines will all be driven to a default state. :-/ Oct 27 14:33:12 hmm, I normally wouldn't be quick to ask a question like this there since it might just be specific to how rcn's kernel is configured. I'd feel like I'd need to first check whether TI's linux PSDK has the same issue Oct 27 14:34:17 yeah I'm not sure what the spi signals do by default Oct 27 14:34:37 true.... hadn't considered it might be something he added out-of-tree, but he hasn't added a whole lot of non-TI AM57x patches at this point. rcn-ee[m]? Oct 27 14:34:51 but I don't think spi is sensitive to glitches on individual IOs so there's no need to configure it early in u-boot Oct 27 14:35:17 k. I'll switch them back to gpio then. Oct 27 14:35:21 jkridner: I was more thinking along the lines of kernel config or configuration done by userspace Oct 27 14:35:46 I'm excited we might get to hacking in pinmux helper kinda soon. :-) Oct 27 14:36:10 but I also haven't looked in detail at the kernel code... it looks like it was originally written for the omap4 mpuss but it does have some patches specific to omap5/dra7 Oct 27 14:36:31 I think someone was talking to Linus W. or another developer about putting a debugfs entry in as a way to do something mainline rather than the out-of-tree pinmux helper. Oct 27 14:36:50 debugfs is root-only Oct 27 14:37:00 and meant for debugging, not for normal operation Oct 27 14:37:02 always? Oct 27 14:37:02 so wrong place Oct 27 14:37:40 well not necessarily, but there's stuff in debugfs that normal users definitely shouldn't be able to touch Oct 27 14:37:42 well, I don't see the mainline devs taking in pinmux helper. Oct 27 14:37:56 if it's cleaned up, why not? Oct 27 14:38:19 it's also a trivial driver to support out-of-tree Oct 27 14:38:47 it is said, and I'll need to verify by whom, that it is the "wrong way" and that the mux control should be controlled by the peripheral using the pinmux rather than separately. Oct 27 14:39:14 so, I'd think a "proper" solution would require hooks in each of the drivers for the associated peripherals. Oct 27 14:39:22 yep that's absolutely true, so how do they suggest changing which peripheral is using a pin at runtime, without runtime DT overlays? Oct 27 14:39:29 enabling them to request the pins. Oct 27 14:39:51 no that's a horrible solution, that puts the burden on every single platform driver that uses pins Oct 27 14:40:12 that's how I read the acceptable path. Oct 27 14:41:37 a possible solution would be a way to put peripherals in a "forced off" state, where they are put (by the power management layer) into suspend-state and a special "off" pinmux is selected Oct 27 14:41:45 along with a way to put peripherals into that state initially Oct 27 14:41:48 (in DT) Oct 27 14:42:05 then userspace could disable the active peripheral and enable another one that uses the same pins Oct 27 14:42:20 but that doesn't solve the fact that some people only want a subset of pins muxed for a peripheral Oct 27 14:42:44 for uart you might use it with or without flow control, and maybe rx-only or tx-only Oct 27 14:42:51 right... each peripheral driver would need to know all possible functional subsets. Oct 27 14:42:54 obnoxious. Oct 27 14:43:32 maybe the best solution is to just make it much easier to people to make custom DTs, but pinmux helper is still just great for experimentation Oct 27 14:43:51 the ti pinmux utility attempts to comprehend this, but, inevitably, individual pins must be selected. Oct 27 14:44:37 well, in the short term, I'm just looking forward to bringing back pinmux helper and config-pin, if only for a few pins and modes. Oct 27 14:44:48 people are just getting stuck all over the place. :-( Oct 27 14:45:12 just putting the pins to default to gpio is going to solve a lot of hate mail. Oct 27 14:45:45 * jkridner never fails to overestimate users' ability to edit dt files. Oct 27 14:46:02 sure you can definitely add pinmux helper devices... I see no reason to abandon pinmux helper right now Oct 27 14:46:42 the iodelay and glitch nonsense has TI developers saying "it isn't possible". Oct 27 14:46:58 which is *mostly* absurd. Oct 27 14:47:24 but right now, any pinmux done from anything other than u-boot SPL has the same problem. doing it in DT isn't any better than doing it at runtime with pinmux-helper Oct 27 14:48:10 right.... which is why rcn-ee[m] was actually working on getting the dt loaded in SPL! Oct 27 14:48:21 though for DT-controlled default configuration it should be fixable Oct 27 14:49:22 anyway, I think that is overly burdensome and care needs to be done to make sure the glitches don't break any peripheral function and no glitch can potentially cause any overlapping-drive-conflict that might generate latch-up. Oct 27 14:49:33 well that would mean not having SPL but just having bootrom directly load u-boot, i.e. making u-boot small enough to fit in internal SRAM (which is quite large on the am572x iirc) Oct 27 14:49:41 ....but that switching in userspace should be fine. Oct 27 14:50:04 which sounds like it ought to be doable but I try to never underestimate how bloated u-boot is Oct 27 14:50:13 lol Oct 27 14:50:23 it is a freakin' OS. Oct 27 14:50:31 and big one. Oct 27 14:51:08 just single-threaded and without any apps. Oct 27 14:51:40 but it would need to enter I/O isolation at least twice regardless: once to configure the pins necessary for finding and loading the DT (and any overlays enabled), once to apply the pinmux Oct 27 14:52:33 my idea was to instead reenter I/O isolation from u-boot even if it is already running from DDR memory, by briefly jumping back into code in internal SRAM and putting DDR in self-refresh Oct 27 14:54:06 that'd be cool. the SPL loading DT advantage is obviously that you don't need to figure out how to put the DDR in self-refresh. and, as you mentioned, the on-board RAM is pretty big so you can make a pretty big SPL. Oct 27 14:54:21 which is easier than trying to figure out how to make a fully-flexible u-boot small. Oct 27 14:54:59 well SPL is only used if the main u-boot doesn't fit in internal SRAM Oct 27 14:55:17 and for this you'd want all of u-boot in SRAM Oct 27 14:55:31 so it wouldn't be a big SPL, it would be a slim u-boot Oct 27 14:55:49 well, not "slim"... more like "slightly less excessively bloated than typical" Oct 27 14:56:48 if you can use ocmc_ram2 or ocmc_ram3 you have 1 MB Oct 27 14:56:51 don't need all of u-boot, just the part that loads from SD, edits DT and applies the pinmux settings. Oct 27 14:56:53 1 fucking MB Oct 27 14:57:08 you do need all of u-boot, since any later part would be useless Oct 27 14:57:28 thought there was 2.5MB on-board. Oct 27 14:57:31 since you want to apply pinmux based the DT you load together with the kernel (and initrd if applicable) from the boot system Oct 27 14:57:49 ocmc_ram1 is 0.5 MB, so 2.5 MB total, but iirc not contiguous (but lemme check that) Oct 27 14:58:15 or we'd just load the dt twice. Oct 27 14:58:35 couldn't we adjust the memory map? does it need to be contiguous? Oct 27 14:59:22 so if you want to configure pins glitch-free based on DT you need all code needed to load the OS in SPL, which leaves exactly nothing to do in the main u-boot since loading the OS is all u-boot is for Oct 27 14:59:49 if you manage to locate the boot device and load DT from it, you're basically there... no point in not also loading and executing the kernel Oct 27 15:01:16 well I suppose it could, but I imagine things like the kernel and initrd need to be contiguous in physical memory... I assume control is handed off to the kernel with the MMU disabled Oct 27 15:01:45 those would be in DDR. Oct 27 15:02:35 what does the kernel do with the L3 memory anyway? Oct 27 15:03:15 ah right... so the execution flow would be very different from how u-boot works normally Oct 27 15:04:56 you'd do basic platform initialization *excluding* DDR, locate the boot device, load the DT, configure pins, initialize DDR, move (or reload) the DT in DDR, load kernel/initrd in DDR, and transfer control Oct 27 15:05:44 and if MMU was used to make internal memories contiguous and MMU indeed needs to be disabled before handing off control then you'd also need to change execution to DDR somewhere between initializing DDR and transferring control Oct 27 15:05:56 zmatt: did you answer if you'd be at ELC-E? Oct 27 15:06:05 oh... Oct 27 15:06:08 you said "nope" Oct 27 15:06:09 sorry. Oct 27 15:06:12 15:24 <@jkridner> any chance you'll be at ELC-E this week? Oct 27 15:06:12 15:24 <@zmatt> nope Oct 27 15:06:19 yeah Oct 27 15:07:01 ocmc2 and 3 are physically contiguous Oct 27 15:07:08 so that's 2 MB of physically contiguous sram Oct 27 15:07:53 I really would hope u-boot can fit its fat ass in 2 MB Oct 27 15:08:23 :-D Oct 27 15:08:54 * jkridner runs to fetch beer and coffee (back in a bit) Oct 27 15:13:23 to be loaded by bootrom the max is 504 KB, which is still a lot (compared to 109 KB on the am335x) Oct 27 15:15:03 I guess using the 2 MB of ocmc2/3 for code would still require SPL, with SPL in ocmc_ram1 and u-boot in ocmc_ram2/3 Oct 27 15:16:09 using it as uninitialized ram (stack, malloc(), loaded files) shouldn't require a split though Oct 27 15:20:14 look at how many boot devices are supported by bootrom, and it is only 48 KB of code Oct 27 15:20:26 indeed. Oct 27 15:20:43 you could run a lot of system from 2.5MB w/o any DDR. Oct 27 15:20:58 so, does the kernel do anything with that memory? Oct 27 15:21:20 can I opt to put a really fast application into it? Oct 27 15:21:32 it's intended for video buffers passed between subsystems Oct 27 15:21:33 i mean, why not put the kernel there? Oct 27 15:21:45 I doubt the kernel fits in 2 MB Oct 27 15:22:08 inititially, maybe, but yeah, not once it is fleshed out with modules. Oct 27 15:22:16 I also doubt it would make much sense to use it for that Oct 27 15:22:28 performance-critical data seems more sensible Oct 27 15:22:38 sure. just don't know if it is being used and it would make some things a LOT faster. Oct 27 15:22:48 especially datasets too large to fit in cache, or that need to be used by other peripherals/subsystems Oct 27 15:23:06 obvious optimization for any app. Oct 27 15:23:08 dunno, I don't think fetching kernel code from ram into cache is really a performance-limiting factor Oct 27 15:23:43 I think its intended use (and similar ones) are probably the best use of ocmc Oct 27 15:23:59 it also has some fancypants support for ringbuffers iirc Oct 27 15:25:00 yeah, ocmc2 and 3 do Oct 27 15:25:04 ah all three do Oct 27 15:25:40 with 8MB virtual space for each of the three memories Oct 27 15:26:17 (to make ringbuffers appear linear) Oct 27 15:26:38 dma out the other side? Oct 27 15:27:06 no it's just addressing logic in ocmc Oct 27 15:27:51 process-to-process ring-buffer rather than process-to-hardware? Oct 27 15:29:26 yes, e.g. to pass video frames between subsystems (in ringbfufers, but with each video frame appearing physically contiguous even if it actually straddles the wrap-boundary) Oct 27 15:34:39 that's my understanding anyway Oct 27 15:39:55 ah it's actually fancier, it doesn't just make the buffers linear, it makes a sequence of frames accessible in a fixed location, so e.g. DSS may think it's reading from the same fixed framebuffer every time, but it's actually consuming a sequence of frames ones by one (produced by some other subsystem) Oct 27 16:35:44 Humpelst1lzchen: the sd card is broken, I tried another one and it is working Oct 27 16:36:43 Posterdati: this is why you should always verify the data written to sd card after writing it (or write the sd card using software that does so for you, e.g. etcher) Oct 27 16:37:18 sd cards are not the most reliable form of storage, and they have finite lifetime (dependent on how heavily it is used) Oct 27 16:38:12 even if it does seem to boot fine, there can be subtle corruption (a common failure mode is to start exhibiting a few dozen random bit flips in some storage pages) Oct 27 16:40:36 rcn-ee[m] zmatt: can you look at the update at https://github.com/beagleboard/beaglebone-ai/commit/d9c0685685091363a158af7aa4ccbb07196972bd ? Oct 27 16:41:46 * jkridner isn't sure why DCAN1_TX has SLEWCONTROL Oct 27 16:42:29 nor the SPI2_D0 nor SPI2_CS0: https://github.com/beagleboard/beaglebone-ai/commit/d9c0685685091363a158af7aa4ccbb07196972bd#diff-123f248551af3438081b2cbe62daa607R134-R136 Oct 27 16:43:41 anyway, looks like the diff on iopad.txt is easiest to read to understand what I changed in this rev. Oct 27 16:44:02 hope I'm closing in on it. I want to apply this and see if I can read the boardid from eMMC now. Oct 27 16:44:43 though, I suppose my bug there is just not understanding where u-boot expects to get the eMMC pinmux data. Oct 27 16:45:13 trini/Tartarus isn't lurking here. :-( Oct 27 16:45:35 man, where have all the u-boot devs gone? Oct 27 17:20:34 zmatt: I just noticed I'd left I2C4 w/o pull-ups, so I've just pushed that modification. Oct 27 17:24:05 are internal pull-ups sufficient for i2c .. or is it still worth putting resistors on-board too? Oct 27 17:25:39 veremitz: they are fine for stuff that really is on-board. If you load the net with capacitance, an additional pull-up might help. takes a small amount of analysis to know for certain, but either should be fine in most cases. Oct 27 17:25:56 are the am572x pulls stronger than those on the am335x ? Oct 27 17:26:03 don't think so. Oct 27 17:26:17 (making safest to add a bit external) Oct 27 17:26:41 I wouldn't use 100KΩ±50% pull-ups for i2c... basically internal pulls are just to keep pins from floating Oct 27 17:27:33 but yeah it'll depend on bus capacitance... there's a formula for calculating minimum and maximum pull-up values in the i2c spec Oct 27 17:28:11 ah lovely, ta for that wisdom :D Oct 27 17:28:15 50uA - 250uA Oct 27 17:28:36 #thingsIshouldknowifusingregularly ;D Oct 27 17:28:50 s/regularly/morefrequently/ Oct 27 17:29:19 jkridner: that's actually weaker than the am335x Oct 27 17:29:36 66kohm ? Oct 27 17:29:46 132-660 kΩ @ 3.3V Oct 27 17:30:08 did I miss a 0? Oct 27 17:30:15 my bad! Oct 27 17:30:24 okay so about the same as am335x Oct 27 17:30:24 3.3V / 0.00005 Oct 27 17:30:34 yeah I just made a typo Oct 27 17:30:52 k, so 13.2-66kohm Oct 27 17:31:13 jeez am I still asleep or something Oct 27 17:31:42 isn't it dinner time? Oct 27 17:31:45 lol Oct 27 17:31:53 * veremitz hands round the coffees Oct 27 17:32:01 you think I have a normal sleeping schedule? :D Oct 27 17:32:24 here's an app note on I2C pull-up calculation: http://www.ti.com/lit/an/slva689/slva689.pdf Oct 27 17:33:36 anyway so yeah, on average a fair bit stronger than am335x, and also even more imprecise than the am335x Oct 27 17:34:25 66kohm is pretty high for just about any capacitance, so more pull-up is welcome. Oct 27 17:35:04 but, in practice, I know it works well enough for light capacitive loads. Oct 27 17:39:18 yeah I think 4k7 is a typical goodish pull-up for buses .. I think I've got that on 1-wire for some dallas chips Oct 27 17:43:28 zmatt: did we ever work out why the pinmux tool sets MANUAL_MODE for eMMC? Oct 27 17:43:29 hmm I wonder what the pull strength was on the omap5... it actually had programmable drive strength (30/40/60/120Ω) and programmable slew rate (3 levels) for basically every I/O, with slew rate calibration for voltage and temperature. I guess dra7 traded that away for 3.3V compat Oct 27 17:43:33 (and if it is a good idea) Oct 27 17:44:15 jkridner: because the interface requires manual iodelay for certain high-speed modes (and for low speed modes it doesn't matter) Oct 27 17:44:34 k, I'll put it in. Oct 27 17:51:14 basically you should check the best bus mode supported, configure iodelay for that, and mark only that mode and compatible slower modes as supported in DT Oct 27 17:55:08 the "best mode" being either mmc-ddr or mmc-hs200 (for the correct voltage) depending on what the eMMC supports Oct 27 18:07:00 hs200 has the best performance Oct 27 18:24:48 performance is good :D Oct 27 21:22:45 I saw an update to the GitHub repository for BBAI: https://github.com/beagleboard/beaglebone-ai/tree/master/SW/u-boot/pinmux. Is this update related to BoneScript GPIO pin manipulation, I2C, and PWM? Oct 27 21:24:01 SeanMiller: it's to set up more sensible defaults in u-boot instead of doing so in DT (which currently makes customizing the DT very obnoxious and any sort of modularity impossible) Oct 27 21:24:18 it's still work in progress Oct 27 21:25:19 Thanks. How would an update like this come into play? Would it be part of a sudo apt update? Oct 27 21:26:57 nah the bootloader is only updated if you do so explicitly... there's probably a script for it in /opt Oct 27 21:30:47 He has this in his readme: Oct 27 21:30:49 Two commands to run the script: Oct 27 21:30:49 am57xx_generate_pin_config_data.pl -p genericFileFormatPadConf.txt -d genericFileFormatIOdelay.txt -o iopad > iopad.txt Oct 27 21:30:50 am57xx_generate_pin_config_data.pl -p genericFileFormatPadConf.txt -d genericFileFormatIOdelay.txt -o iodelay > iodelay.txt Oct 27 21:32:07 ? what readme? Oct 27 21:32:17 On the GitHub. I used to think I was good at this kind of stuff. But, when I read this, I get more questions than answers. Oct 27 21:32:27 https://github.com/beagleboard/beaglebone-ai/tree/master/SW/u-boot/pinmux Oct 27 21:32:31 that's not meant for end-users Oct 27 21:32:56 Ok. Oct 27 21:33:05 the generated files are in output/ anyway Oct 27 21:37:28 SeanMiller: the stuff going on there is still work-in-progress anyway Oct 27 21:38:59 Ok. Been trying to get PWM and I2C working with bonescript for the AI, but have been spinning my wheels. So far, just got an LED to blink, but no input. Can't find any tutorials out there, yet. Oct 27 21:39:41 I can probably help you with that, do you have a preference for which pins? Oct 27 21:39:51 (and which pwm peripheral) Oct 27 21:48:37 No preference for pins. Would love to have I2C, an analog input, and a PWM output to control. That would give me a pretty good board to play with. Oct 27 21:49:06 analog inputs don't require any pinmux setup Oct 27 21:49:17 I was going to control a servo with the PWM. Oct 27 21:49:35 just curious, why a BBAI rather than a BBB for that? Oct 27 21:49:54 I'm making a smart back up camera. Oct 27 21:51:03 It can turn like a turret and I'd like to respond to objects it "sees" while streaming to my phone. Oct 27 21:52:16 https://www.element14.com/community/community/project14/visionthing/blog/2019/10/20/seeing-around-corners-beagle-bone-back-up-car-camera-part-1-introduction Oct 27 21:56:40 anyway, just hold for a bit while I fiddle Oct 27 21:57:29 i2c-3 on P9.19-20 should be enabled by default Oct 27 21:57:44 Ok. Thanks so much. I'm curious...do you work with BeagleBoard or are you an avid enthusiast? Oct 27 21:57:48 although its pinmux isn't attached to the device, yuck Oct 27 21:58:07 I'm just an enthausiast and we use beaglebones at work Oct 27 21:58:25 Cool. Oct 27 22:28:58 SeanMiller: ok, so use git to check out https://github.com/beagleboard/BeagleBoard-DeviceTrees (select correct branch for the kernel series you're using) Oct 27 22:29:18 save https://pastebin.com/W1ae9fYH as src/arm/am5729-beagleboneai-custom.dts Oct 27 22:29:33 then: make src/arm/am5729-beagleboneai-custom.dtb Oct 27 22:29:56 sudo cp src/arm/am5729-beagleboneai-custom.dtb /boot/dtbs/$(uname -r)/ Oct 27 22:30:05 okay...looking now Oct 27 22:30:39 in /boot/uEnv.txt configure: dtb=am5729-beagleboneai-custom.dtb Oct 27 22:30:52 reboot, and hope I didn't fuck up Oct 27 22:31:03 actually, copy it to /boot/dtbs/ rather than /boot/dtbs/$(uname -r)/ Oct 27 22:31:30 otherwise you'd have a non-booting system if you update the kernel :P Oct 27 22:32:01 Here's where my inquisitive idiot questions come out... Oct 27 22:32:25 assuming all this seems to work and it still boots, use this to double-check the pinmux => https://github.com/mvduin/bbb-pin-utils/tree/bbai-experimental#show-pins Oct 27 22:34:46 To get the correct branch, I type sudo git pull https://github.com/beagleboard/BeagleBoard-DeviceTrees.git. Is there a parameter I pass to get the 4.14x branch? Oct 27 22:35:52 you can pass -b v4.14.x-ti as argument to git-clone, or later on switch to the branch with: git co v4.14.x-ti Oct 27 22:43:01 not finding src/arm/...what is the parent of that one? Oct 27 22:43:25 what do you mean? that's in the repository you just cloned Oct 27 22:44:20 Here's the output of the git. Oct 27 22:44:23 debian@beaglebone:~/trees$ sudo git clone https://github.com/beagleboard/BeagleBoard-DeviceTrees.git -b v4.14.x-ti Oct 27 22:44:24 Cloning into 'BeagleBoard-DeviceTrees'... Oct 27 22:44:24 remote: Enumerating objects: 125, done. Oct 27 22:44:24 remote: Counting objects: 100% (125/125), done. Oct 27 22:44:25 remote: Compressing objects: 100% (56/56), done. Oct 27 22:44:25 remote: Total 3362 (delta 62), reused 100 (delta 40), pack-reused 3237 Oct 27 22:44:26 Receiving objects: 100% (3362/3362), 1.01 MiB | 864.00 KiB/s, done. Oct 27 22:44:26 Resolving deltas: 100% (2281/2281), done. Oct 27 22:44:27 debian@beaglebone:~/trees$ ls Oct 27 22:44:27 please don't Oct 27 22:44:42 never paste multi-line output into chat Oct 27 22:45:00 My bad. Oct 27 22:45:10 like it says, it created a directory 'BeagleBoard-DeviceTrees' for you, in that you can find src/arm/ Oct 27 22:45:35 also don't use sudo Oct 27 22:45:46 why on earth are you using sudo here? Oct 27 22:46:00 sudo is for system administrative tasks Oct 27 22:47:12 seems every time I don't it throws a message I should, so I just started always doing it Oct 27 22:47:40 most likely many of those problems are caused by previous inappropriate use of sudo Oct 27 22:47:55 e.g. because you used sudo to check out the git repo, you now don't have access to it Oct 27 22:48:31 makes sense Oct 27 22:49:08 you'll want to fix ownership of the checked out repo with: sudo chown -R debian: BeagleBoard-DeviceTrees Oct 27 22:49:27 depending on how much you've been using sudo you might want to do that on your entire homedir :P Oct 27 22:52:23 things for which you need sudo is e.g. installing system packages with apt or meddling with files in /boot or /etc/ Oct 27 22:53:18 You are solving a many decade issue for me. Oct 27 22:53:36 The chown command cured it and make didn't through a message at me without sudo Oct 27 22:54:39 "git" and "make" are two excellent examples of commands that should never be prefixed with sudo... if you do then something is wrong Oct 27 22:55:11 for this: sudo cp src/arm/am5729-beagleboneai-custom.dtb /boot/dtbs/$(uname -r)/ do I do it exactly as shown or replace uname? Oct 27 22:55:58 like I said earlier I actually changed my mind and recommended installing into /boot/dtbs/ instead Oct 27 22:56:36 but otherwise you could have just executed it as shown, the shell would execute uname -r and substitute the result into the path Oct 27 22:57:46 Like I said earlier...inquisitive idiot. :-) Oct 27 22:58:22 almost done. Oct 27 22:58:31 nothing wrong with asking questions Oct 27 23:00:12 rebooting now Oct 27 23:03:04 Lights are blinking... Oct 27 23:03:39 Came back to life! Cloud9 came back. I've bricked it twice today trying something like this. Oct 27 23:04:20 :thumbsup: Oct 27 23:04:24 check pinmux? Oct 27 23:04:57 I just did this: /opt/scripts/device/bone/show-pins.pl Oct 27 23:05:56 Here is some stuff: (one line at a time) Oct 27 23:05:58 P9.19a 16 R6 7 fast rx up i2c4_scl i2c@4807a000 (i2c4) Oct 27 23:06:20 P9.14 107 D6 a fast down ehrpwm3A pwm@48442200 (ehrpwm2) Oct 27 23:06:36 There is a bunch more, but these two are worth asking questions on. Oct 27 23:06:46 What does "up" versus "down" mean? Oct 27 23:06:59 internal pull-up/down Oct 27 23:07:25 uhh, this looks odd Oct 27 23:07:50 oh you're using jkridner's show-pins version, no wonder Oct 27 23:07:55 that confused me for a bit Oct 27 23:08:31 Me, too. Oct 27 23:08:38 because I don't know what the hell I'm doing. Oct 27 23:09:26 So from here, I should be able to find some BeagleBone Black examples using these pins to get thinks going. That sound right? Oct 27 23:09:36 not following instruction :P I didn't ask for the output of /opt/scripts/device/bone/show-pins.pl, I asked for the output of my show-pins script :P Oct 27 23:09:54 Where is your show-pins script? Oct 27 23:10:00 I linked to it earlier, hold on Oct 27 23:10:08 https://github.com/mvduin/bbb-pin-utils/tree/bbai-experimental#show-pins Oct 27 23:10:30 anyway it looks good... I think Oct 27 23:10:54 so this should make /dev/i2c-3 operational using any i2c library for any language you like Oct 27 23:11:58 Getting your show pins. You're all right in my book. Oct 27 23:11:59 and with a bit of luck there should be symlinks in /dev/pwm/ for your pwm outputs (I configured both outputs of the ehrpwm peripheral so you have a spare pwm output :P ) Oct 27 23:12:29 as for whether libraries for beaglebone work, I doubt it Oct 27 23:12:43 they probably embed too much assumptions Oct 27 23:13:37 but setting up a pwm output is as simple as writing the desired values to the sysfs attributes of the pwm outputs, so it's easy to do in any programming language that can write to a file Oct 27 23:14:08 (ideally using a raw/unbuffered write) Oct 27 23:16:22 Is "writing the desired values to the sysfs attributes of the pwm outputs" the "fopen("/sys/class/gpio/gpio23/direction", "w");" examples I find a lot for BB. Oct 27 23:17:14 yes though it would be better to use open() and write() rather than fopen() and fwrite()/fprintf()/fputs() Oct 27 23:18:10 For those file writes, how is that working for the system? Is there a service that is always running waiting for the file to change and then handle things? Oct 27 23:18:20 (semantically speaking using buffered file I/O might break, but in practice it'll *probably* work although you'll need to fclose() or fflush() the file handle for the write to take effect) Oct 27 23:18:50 sysfs is not a real filesystem, and those attributes are not real files. it's a filesystem-like representation of kernel objects and their attributes Oct 27 23:19:09 so a write() to a "file" in /sys is actually a method call on a kernel object Oct 27 23:20:55 Okay-got it. I just had a flashback to my Amiga. Oct 27 23:21:10 Not sure why, but I remember something like that. Oct 27 23:23:24 Thanks for all your time on this. I'll get to cobbling some code now. Oct 27 23:44:02 jkridner: I've included your two changes in this, and also changed it a bit to make it easier to compare default settings with configured settings => https://docs.google.com/spreadsheets/d/e/2PACX-1vSB0SmXxNCxdazDYFF9x55__ks2zxsuh8-AZYl7kkCSIJptsBHP02ZPD2lu-XS6JTe8-uWtnhnWOSwz/pubhtml?gid=1887626825&single=true Oct 27 23:44:53 jkridner: note that quite a few expansion header pins are still floating, and there's a pull-up/down conflict on P9.18 Oct 27 23:47:10 and many pins have no gpio configured Oct 28 01:54:24 jkridner: just another data point, enabling retention by zmatt's brute force util reduces current @ 5V by about 10mA Oct 28 01:54:47 by 100mA I mean Oct 28 01:55:08 the overall usage is about 800mA (before) vs 700mA (after)... seems a bit high Oct 28 02:00:04 might be interesting to see what the impact is of disabling the various auxiliary cores (eve, dsp, ipu, pru) just in case Oct 28 02:00:21 since the kernel tries to load shit onto them at boot Oct 28 02:00:41 I'd kinda hope it leaves them properly disabled when not in use, but who knows Oct 28 02:04:35 they should be controlled by runtime PM Oct 28 02:05:30 they should :) Oct 28 02:06:10 are they stopped by default though? the tracebacks I saw in the kernel log pasted by hunter2018[m] seemed to suggest code was executed on EVEs **** ENDING LOGGING AT Mon Oct 28 02:59:58 2019