**** BEGIN LOGGING AT Sun Nov 08 03:00:00 2020 Nov 08 03:04:50 set_ no the DSPs are TI based devices. They also can access main memory. However chapter 20 discusses how to handle mapping the devices access to memory under IPU MMU area. That said you would need to spend some time to figure out how to access that MMU's and then set them up. Also you need to confiure 1 or more of the M4 cores as in control them. Not sure how the linux distribution is setup. TI sometimes makes things usable Nov 08 03:04:50 for mere mortals but probably as zmatt was indicating getting access to the M4's to use is probably going to be a bit more than just a headache. Nov 08 03:08:14 I have bugs and shrugs. No headache here. Nov 08 03:08:38 I found the M4 and ARM v7 ref. man. Nov 08 03:08:46 I can start here. Nov 08 03:09:06 I see the programmers' model so far. I am reading it now to review it later. Nov 08 03:09:33 I can play catch up soon w/ how TI or you guys implemented it on the AI. Nov 08 03:10:01 I will have time. Winter is around the corner. Grass "no grow" in the cold days of the year. Nov 08 03:38:31 No headache yet but hunger kicked in! Nov 08 03:48:43 10:00 is around the corner! Nov 08 05:21:07 this elevator sounds like it needs therapy... https://www.youtube.com/watch?v=bQtmm_lpUKI Nov 08 16:14:50 does the m4 on the bbb have a memory map or trm published? Nov 08 16:14:53 o mean bbai Nov 08 16:19:10 it is a really interesting problem Nov 08 16:19:20 even though i def dont have time and i'm struggling already as the winter blues kick in Nov 08 16:23:27 i think they call the m4's ipus, and there is a lot of information in the TRM even if its not complete Nov 08 16:23:30 i dont know if it is Nov 08 16:26:56 yep the IPUs are the cortex-m4 subsystems Nov 08 16:27:08 and yeah there is a fair bit of documentation in the TRM, including memory map Nov 08 16:27:54 yeah i mean lol the memory map itself is a pretty intimidating section Nov 08 16:28:39 i actually dont know if i have enough background on chip design to understand this section even if i read it Nov 08 16:28:54 i don't really know much about chaches or how they work, and i think i need to fix that Nov 08 16:29:52 /chaches/caches Nov 08 16:32:29 i guess what i need is a stronger more technical course on these architectures in general Nov 08 16:33:48 yeah the memory map as seen by the cores depends almost entirely on the L1 MMU setup since the Code and System buses of both cores of the subsystem connect to the "Unicache" L1 cache/MMU Nov 08 16:36:49 on the older dual-m3 subsystem the default L1 mmu setup mapped 16KB at 0x00000000 (on the Code buses) to 0x55020000 (subsystem-local RAM) and 4KB at 0x40000000 ("Near Peripheral" device memory on the System bus) to 0x55080000 (unicache registers including SCTM), with caching disabled Nov 08 16:37:07 I think it's still the same on the newer dual-m4 subsystem, haven't checked Nov 08 16:38:11 mapping maps to maps Nov 08 16:39:22 im anticipating a ton of detail in order to develop a programmers model and it would be nice if its documented but i still dont know why i'm doing this i have like 100 things to do today lol Nov 08 16:39:28 yeah, access to the rest of the system goes through another MMU (the L2 MMU) although its use is optional I think Nov 08 16:39:53 actually I'm certain it's optional Nov 08 16:40:41 i mean i'm reading about L3 and L4 right now in chapter two Nov 08 16:41:00 ok yeah those are the names of the main interconnects Nov 08 16:41:06 the L3 being the big chip-level interconnect Nov 08 16:41:36 the basic idea being that "initiators" (cores, DMA, other things) are interconnected through it and also to peripherals Nov 08 16:41:49 thats what i'm reading anyway Nov 08 16:41:54 it's basically like a network, except rather special-purpose Nov 08 16:42:07 well L3 seems to be the main connection and then it connects to L4s which have specific groups of peripherals Nov 08 16:42:17 yeahhhh i mean if you're saying its kind of like a router? Nov 08 16:42:22 the L3 also connects to some big subsystems/peripherals directly Nov 08 16:42:32 the L3 is actually a packet-switched network Nov 08 16:42:50 i see that, yeah L4 is only for _peripheral_ peripherals it seems like- gpio, i2c, spi coutners etc Nov 08 16:43:12 MPU connects to EMIF + GPMC (memory controllers) both through l3 and directly Nov 08 16:43:25 yeah the L4 interconnects aggregrate lots of "minor" peripherals Nov 08 16:43:32 on a bus Nov 08 16:43:57 okay im not totally confused then i'm just going to keep reading Nov 08 16:44:05 interesting about the packet switched network Nov 08 16:44:21 yeah, so this is a fragment of the L3 on an older TI SoC: https://liktaanjeneus.nl/centaurus-partial-L3F.png Nov 08 16:44:42 it's literally a network Nov 08 16:45:12 (red lines are firewalls) Nov 08 16:46:19 the thick red lines I mean... I think the red arrows merely indicate which initiators on Switch_2 use which path to Switch_1 Nov 08 16:46:58 also I have no idea why the arrows are drawn from target to initiator instead of the more logical direction from initiator to target :P Nov 08 16:47:00 O_o Nov 08 16:47:14 there's a reason they leave that detail out of the TRM lol Nov 08 16:47:41 I wish they didn't Nov 08 16:48:34 ah I knew I had one for the AM572x L3 too: https://liktaanjeneus.nl/vayu-l3.png Nov 08 16:49:11 unfortunately the resolution is not great Nov 08 16:49:26 is that detail actually useful to a programmer? Nov 08 16:49:58 for performance reasoning, also for knowing what sort of ordering constraints are actually guaranteed by the topology Nov 08 16:50:37 baby steps for me now Nov 08 16:50:44 like, if I write to memory and then write a command to the DMA conrtoller which fires a read from memory, is that read guaranteed to be ordered behind my write to memory yes or no? Nov 08 16:50:55 oh yeah i mean i get that Nov 08 16:51:01 (answer: no.) Nov 08 16:52:15 it's also easier to analyze performance bottlenecks if you have a mental model of where performance bottlenecks could be Nov 08 16:53:51 so in case you're curious: afaik every switch in the L3 is a crossbar, meaning all initiators can be services simultaneously as long as they don't try to access the same target at the same time (in which case someone will have to wait) Nov 08 16:53:58 *can be serviced Nov 08 16:54:37 i wish there was a better visual for these memory maps Nov 08 16:55:05 im stupid i need picture books lol Nov 08 16:55:22 hehe Nov 08 16:58:06 so basically an initiator will issue some request like "read 16 bytes at 0x12345678" and then a lookup is performed for that address (by the initiator Network Interface Unit I believe) to figure out what target that is and what address it maps to inside that target (typ address - base address of the target), and then the L3 itself will just route based on target ID without caring about address Nov 08 17:01:56 yeah i'm struggling with this memory map section because its like a) is there some global memory starting at 0x00 and then b) obviously not because the TRM mentions overlap in address spaces Nov 08 17:02:39 and that's like okay so i need to do more research on L1/L2 because those aren't described as well in the memory map section Nov 08 17:02:53 and I need to read more about how the MMU works because I've never worked with an MMU directly before but its okay Nov 08 17:03:02 technically every initiator has its own memory map, even though often a lot of stuff eventually ends up on the L3 which is where everyone agrees on what's where (though there's no technical requirement for that I think) Nov 08 17:03:56 so an address only means something within an address space, such as the virtual address space of a process under linux, or the physical address space of the cortex-a8, or the address space of a PRU, etc Nov 08 17:04:28 yeah Nov 08 17:05:17 and L1-4 doesn't necessarily go in order from lowest address to highest address i've just realized Nov 08 17:05:20 i dont know why i assumed that Nov 08 17:05:38 i mean not at all Nov 08 17:06:36 because certain addresses in L3 access L1 Nov 08 17:06:36 and then certain things seem to be able to access L1 directly Nov 08 17:06:36 or maybe not Nov 08 17:06:36 thats a detail tho not important Nov 08 17:06:39 so e.g. on the AM335x, a memory access will first go through the Cortex-A8's own MMU to go from the virtual address space of the process to the physical address space of the cortex-a8, which is the address space of the Cortex-A8 subsystem, which is: https://goo.gl/UHF2Fy#gid=1219477862 which mostly delegates to the global L3 memory map albeit with some exceptions Nov 08 17:06:44 L1/L2/L3 are layers Nov 08 17:08:16 so the L1 memory system of the cortex-a8 is its MMU and L1 caches, the L2 memory system is the L2 cache, which is why TI named the L3 interconnect the L3 interconnect Nov 08 17:08:34 do they not describe ranges of addresses? Nov 08 17:09:16 though this is really an oversimplification, since what layers there are (e.g. MMUs and caches) between a piece of software and a concrete target varies depending on what core that software runs on and the intended target, and sometimes even the route to the target Nov 08 17:09:20 no Nov 08 17:10:46 i think of the MMU as a peripheral that reroutes things Nov 08 17:10:46 and all i really care about is the memory map of each initiator Nov 08 17:10:53 (ignoring the issue of race conditions as you described earlier) Nov 08 17:11:33 think of each layer as getting a request with some address, performing some address-based lookup and either servicing it directly (e.g. in case it hits a cache) or passing it on to the next hop (which may vary depending on address), probably with an altered address Nov 08 17:11:49 and so on Nov 08 17:12:16 yeah thats annoying Nov 08 17:12:21 see thats really complicated Nov 08 17:12:30 i feel like all i should worry about is what the memory map looks like wherever i write code Nov 08 17:13:25 well you can just write out the complete memory map for each initiator, which I think the TRM does, but in many ways that's more complicated that writing out the network since there's a ton of redundancy if you write it out like that Nov 08 17:13:46 and if there's any hop that's reconfigurable then you end up with a problem Nov 08 17:13:49 yeah i think theres redundanc ANNNND overlap Nov 08 17:14:10 because it seems like, especially in the case of the IPU certain memory addresses mean two things depending on how the MMU is configured (that's more or less their words) Nov 08 17:14:30 and even the memory map will write two descriptions for one range of addresses Nov 08 17:14:30 an MMU is an example of a layer where the address mapping is configurable Nov 08 17:14:37 which is in fact the main purpose of an MMU Nov 08 17:14:53 along with being able to specify attributes per region (e.g. cacheability) Nov 08 17:14:55 yeah i mean i always understood is properly separating userspace from physical memory Nov 08 17:15:01 it as* Nov 08 17:15:06 but it clearly has more functions Nov 08 17:15:23 an MMU isn't always about privilege or isolation, it can also be about convenience Nov 08 17:15:36 e.g. making non-contiguous memory appear contiguous Nov 08 17:16:28 so ultimately tho every range of addresses has some L* that it connects to directly Nov 08 17:16:31 the final hop Nov 08 17:16:33 the lan Nov 08 17:17:12 maybe multiple L*s connect to some peripheral and can be access by multiple routes or even multiple addresses, who knows Nov 08 17:22:36 so, for example, if you've got some PRU memory mapped into a linux userspace process and perform a read/write in that, the steps are (ignoring caching since the MMU mapping will specify this to be non-cacheable): Nov 08 17:22:40 1. MMU translation of virtual address to physical address (via translation tables, cached in TLB) Nov 08 17:22:45 2. cortex-a8 issues request on AXI bus Nov 08 17:22:51 3. cortex-a8 subsystem routes request (via async fifo) to L3 interconnect Nov 08 17:23:12 4. L3 interconnect routes request (probably via multiple packet switches) to L4HS interconnect Nov 08 17:23:24 5. L4HS interconnect routes request (via async fifo) to PRU subsystem Nov 08 17:23:34 6. PRU subsystem interconnect routes request to local memory Nov 08 17:24:29 like i dont really get how its hierarchal Nov 08 17:24:31 like why is L1 L1 Nov 08 17:24:45 L1 just refers to closest to the initiator Nov 08 17:25:06 and L1 is actually a whole bunch of complicated things? Nov 08 17:25:14 i mean obvious based on that picture you showed me Nov 08 17:25:33 im upset by this nomenclature Nov 08 17:25:36 don't attach too much meaning for this attempt at neatly layering things into numbered layers Nov 08 17:25:44 since reality isn't that neat Nov 08 17:26:22 but the cortex-a8 L1 memory system is the L1 cache and MMU lookup mechanism (whose lookups happen in parallel) Nov 08 17:27:41 yeah i kinda get that now Nov 08 17:28:32 so the memory map section is literally a list of initiators and their respective memory maps, like you said Nov 08 17:28:57 yep, possibly flattened to some degree Nov 08 17:29:04 and the different initiators have their respective mmus which can be used to configure it Nov 08 17:29:14 there's definitely a specific MMU for the IPUs Nov 08 17:29:31 we've been at this for an hour now. Nov 08 17:29:45 well the memory maps apply to the addresses that are after the MMU typically Nov 08 17:30:51 like, in my 6 steps above only the first step (the cortex-A8 L1 memory system) uses virtual addresses of your userspace process Nov 08 17:32:01 which are programmably mapped to physical addresses used for L2 cache lookup (if applicable) and requests on the cortex-a8 bus interface (AXI) Nov 08 17:32:46 L1 L2 and the MMU are considered part of the MPU subsystem? Nov 08 17:32:48 and then there are 4 fixed (non-programmable) memory maps consulted in sequence at various hops to actually route the request to its final destination Nov 08 17:33:05 CoffeeBreakfast: not even the subsystem, they are part of the Cortex-A8 core itself Nov 08 17:34:30 of course that situation will vary per initiator, e.g. PRU doesn't really have an MMU unless you count the option to subtract 0x80000 from all addresses going to the L3 Nov 08 17:36:21 i guess im reading all about AM572x memory architectures today Nov 08 17:36:33 which is useless if i dont also make it to looking at how the kernel handles it at some point Nov 08 17:36:47 note that the specific example I gave was for the AM335x, though things are similar (but overall more complex) on the AM572x Nov 08 17:37:02 yeah i mean i'm just reading your examples for illustrative purposes Nov 08 17:42:05 https://i.imgur.com/igXHQeI.png is pretty interesting, from the TRM Nov 08 17:42:11 where EMIF is the DDR controller Nov 08 17:43:01 yeah, this shows specifically the bits for plain memory address Nov 08 17:43:05 *access Nov 08 17:43:27 note that on the AM572x each core has its own L1 memory system but the L2 memory system is shared between the two cores Nov 08 17:44:01 is there any onchip nonvolatile writeable memory? Nov 08 17:44:05 no Nov 08 17:44:25 thats totally out in most cortex-a's i bet Nov 08 17:44:38 well, efuses but those are only factory-programmed (unless you're a very fancy customer), but those are just for bits of configuration Nov 08 17:45:20 that sentence was not the most well-phrased thing I've ever written Nov 08 17:46:53 i think its weird that sometimes memory mappings will be listed for specific "hops" w/in the chains Nov 08 17:47:18 ayjay_t: so here's what my notes say about the OMAP5/AM57xx subsystem routing specifically: https://pastebin.com/raw/qnfrhQtq Nov 08 17:48:03 zmatt i feel like you'd like roam research Nov 08 17:48:18 some kind of wiki on steroids for note taking Nov 08 17:49:38 so based on the diagram you showed, all this routing/mapping happens inside the Memory Adapter component of the MPU subsystem Nov 08 17:50:44 actually no, also the local interconnect labeled "MPU_AXI2OCP" Nov 08 17:51:08 well this is only for DRAM i think Nov 08 17:51:10 which will sort out the various local destinations Nov 08 17:51:31 like 99% sure this is just a way for L2 (MPUs only?) to skip L3 when accessing DRAM Nov 08 17:51:41 yeah the Memory Adapter just separates RAM and non-RAM destinations and deals with the RAM accesses Nov 08 17:51:59 correct, it's a fast path from cortex-A15 to ram Nov 08 17:52:07 bypassing the L3 Nov 08 17:53:03 (on the AM335x ram access does go through the L3, although it does have a dedicated interface for it from MPU subsystem to L3 and the path is shorter anyway since the AM335x has no DMM) Nov 08 17:55:35 I think part of it is also to avoid the latency of an async bridge, since you need only one to go from the MPU clock domain to the DDR clock domain instead of going via the L3 clock domain as intermediate step Nov 08 17:56:45 okay yeah, l3 and l4 are both 3rd party IP Nov 08 17:57:36 they are yeah, the L3 is an instance of Arteris FlexNOC while the L4 interconnects are Sonics S3220 Nov 08 17:58:26 if you see mentions of "VBUS" or "CBA", those refer to TI's own interconnect technology Nov 08 17:58:55 im gonna take a look at the MMU chapter and _maybe_ call it day. actually i think this kernel is still available right probably from rcn-ee Nov 08 17:59:09 (while AXI is ARM's high performance interconnect) Nov 08 17:59:10 i dont think i'll be able to but i'd like to at least find where some of this relevant code is Nov 08 18:02:22 oh god and the RT kernel Nov 08 18:02:28 another thing for me to dig into Nov 08 18:04:16 RT kernel = most interrupts are turned into kernel threads, most spinlocks are turned into priority-inheritence mutexes Nov 08 18:06:20 okay but just looking at the kernel directory structure is overwhelming Nov 08 18:06:35 i would assume all MMU configuration is not handled by device tree/drivers? Nov 08 18:09:23 MMU configuration is an affair private to the linux kernel Nov 08 18:09:54 here's some super simple Cortex-A8 MMU setup code from a baremetal experiment: https://pastebin.com/pwyGeZPe Nov 08 18:10:22 i am probably better off looking at uboot Nov 08 18:10:30 then kernel to start Nov 08 18:10:34 simpliar approach, i imagine Nov 08 18:10:43 what I linked is probably easier to understand than either of those Nov 08 18:11:22 it's pretty much the bare minimum MMU initialization Nov 08 18:11:27 written for readability Nov 08 18:11:56 your notes are pretty good Nov 08 18:14:39 ill have to start with an easier less complicated chip tho, which is fine because that actually does align with my projects lol Nov 08 18:15:50 the AM335x is quite reasonable Nov 08 18:15:59 (the AM572x isn't) Nov 08 18:18:36 ugh the chips im working on are too simple, single core mmu-less cortex-ms Nov 08 18:18:44 and then i have this new bb ai which is too complicated Nov 08 18:19:09 its fine to use am335 but im not actually usng it right now Nov 08 18:20:05 much of understanding the AM335x translates to the AM572x, except it has more of everything and everything is more complicated Nov 08 18:20:49 the AM335x requires surprisingly little code to get in a sane operational state, even with no help from u-boot (i.e. directly launched by bootrom) Nov 08 18:21:21 the AM572x requires voodoo, some of which involving undocumented registers Nov 08 18:22:50 I wish I ever got around to porting my Forth from the dm814x to the am335x ... a Forth system is such a delight for interactively playing with hardware Nov 08 18:25:54 big oof Nov 08 18:28:15 im assuming that type of voodoo is why you're reluctant about taking on the m4s Nov 08 18:36:02 not remotely, the m4s are not relevant for bootloading Nov 08 18:36:44 I'm also not reluctant about them, I've targeted the nearly equivalent cortex-m3 subsystem on the older dm814x SoC Nov 08 18:37:12 though that was in a baremetal environment, I haven't looked at the linux remoteproc stuff for them Nov 08 18:38:05 if I had any need/use for loading code onto them I could do so pretty easily using uio or /dev/mem if I cared to :P Nov 08 18:38:11 well i mean the am572 voodoo in general Nov 08 18:38:34 I was talking about chip initialization there Nov 08 18:38:39 i was afraid there would be configurations that needed to be set prior to booting into userspace Nov 08 18:38:51 i figured there was more voodoo than just taht Nov 08 18:38:55 for the cortex-m4s ? nah Nov 08 18:40:13 strange how much better i feel after reading some datasheets, even if i'm totally overwhelmed Nov 08 18:40:24 maybe ill try to wrangle the m4s with pyuio then Nov 08 18:40:27 someday Nov 08 18:40:30 I don't know what the kernel driver does, but you can load code onto that subsystem by writing a code image into its subsystem-local ram and then releasing the reset bit Nov 08 18:41:01 no need even to mess with the MMUs Nov 08 18:41:07 i figured thered be some memory configuration like w/ the MMUs Nov 08 18:41:12 (this assumes your code image fits in 64K) Nov 08 18:41:14 and didn't know how freaky pinmuxing might get Nov 08 18:41:26 pinmuxing is irreleevant, the cortex-m4 subsystem has no pins Nov 08 18:42:03 omg really Nov 08 18:42:11 i can't even control a GPIO directly from the m4 Nov 08 18:42:17 sure you can Nov 08 18:42:21 you can access the whole SoC Nov 08 18:42:24 including the GPIO controllers Nov 08 18:42:34 but that means you mux those pins simply to GPIO mode Nov 08 18:42:53 can processors compete for control over l4 registers then?? Nov 08 18:43:18 there's no "complete over control", peripherals generally do not know or care who's accessing them Nov 08 18:43:29 that makes sense i just somehow assumed there would be register level control assignments Nov 08 18:43:46 cool tho Nov 08 18:43:51 alright bike ride time Nov 08 18:43:55 thanks for the notes and help zmatt Nov 08 18:43:57 no, avoiding software-level fights is something you need to deal with at software level Nov 08 18:44:10 e.g. if you want exclusive access to a peripheral, make sure there's no kernel driver loaded for it Nov 08 18:44:31 shared access to a peripheral is safely possible only in very specific circumstances (e.g. gpio set/clear) Nov 08 18:44:54 ok, cya :) Nov 08 18:45:11 I kinda need to do shopping, just haven't succeeded getting off my lazy ass yet Nov 08 19:38:36 M4 stuff, nice! Nov 08 19:41:28 All that stuff is nice info, right. But... Nov 08 19:41:52 What chip labeling is the M4 onboard the AI? Nov 08 19:44:49 For instance, my ARM KEIL software is calling them LM4xxx... and so on. I have like 50 or so many different to pick from on the software. I need to get this section correct. It is the start of it all! Nov 08 19:45:36 AM572x, already answered several times Nov 08 19:45:51 Okay. Nov 08 19:45:54 Thank you. Nov 08 19:45:55 the "IPU" Cortex-M4 subsystems of the AM572x Nov 08 19:46:09 there is no better designation available than that Nov 08 19:46:15 it is unlikely to be listed in your software Nov 08 19:46:16 Oh. Nov 08 19:46:21 Okay. Nov 08 19:46:39 Hmm. Bummer but I guess you are right. Nov 08 19:47:08 Oh well. I see the AM5729 is now for selling online. Nov 08 19:47:50 Okay. Thank you. Nov 08 20:27:21 I've applied a postive voltage to several pins, I can capture some of them from PRU1 but others not. I've used a mapping zmatt shared a while ago, but what I see seems different Nov 08 20:35:00 actually the voltage wasn't right, I'll try again Nov 08 20:36:32 looks like certain pins are high by default, how can I change that? Nov 08 20:38:20 I guess pruin- is the mode, I'll try that Nov 08 20:47:26 doesn't work, looks like pull down cannot be set on pru inputs? Nov 08 20:51:26 Hey! Nov 08 20:51:38 I found the cmsis ideas for the m4! Nov 08 20:51:59 mm302: What board are you using? Nov 08 20:52:12 Ai or any of the am335x boards? Nov 08 20:52:23 I can test now if necessary. Nov 08 20:56:33 hi set_, I found a user with nickname "get" you may want message him and become friends Nov 08 20:56:43 Ha. Nov 08 20:56:55 mm302: Friendly-schmiendly. Nov 08 20:57:07 mm302: What are you doing? Nov 08 20:57:24 Making negative positive and vice versa? Nov 08 20:58:10 pruin pruout. Hmm. So, it all depends on + or -. I can check. Nov 08 20:58:25 I saw the source somewhere online a while back. Nov 08 20:58:38 I'm trying to capture the pin state with the PRU, but the pins config looks like a mess, certain pins seem high by default, certain pins are set high by connecting to ground, others by applying a positive voltage Nov 08 20:58:56 Hmm. Not nice at all. Nov 08 20:59:32 so, something like pruin1 or pruin- would be nice. got it. Nov 08 20:59:50 Let me check. am335x or am5729? Nov 08 21:00:54 rproc or uio? Nov 08 21:02:10 sh script to the rescue? Nov 08 21:04:19 I'm trying out some secret pin modes looking at config-pin Nov 08 21:04:26 Hey, I came across this idea in bb.org-overlays: https://github.com/beagleboard/bb.org-overlays/blob/master/tools/beaglebone-universal-io/config-pin Nov 08 21:04:27 Oh. Nov 08 21:04:29 Okay. Nov 08 21:11:28 I forgot. config-pin only works on am335x boards. Oops. Nov 08 21:12:40 All I can find is out and in for the PRUs. Nov 08 21:13:02 Nothing like negative or positive for config-pin arguments. Nov 08 21:13:58 there is an optional + or - after the mode, but doesn't seem to work with pruin/out Nov 08 21:15:07 Right. If you go to the /bealgebone-universal-io/config-pin source, you will see that is a fact. Nov 08 21:15:22 I am not sure why exactly. Maybe some are only meant for out or in. Nov 08 21:17:26 for example I see P8_43 default to high, unless I ground it Nov 08 21:18:05 Heh? Maybe a gpio_pu first and then overwrite w/ a pruout/in config-pin command? I will test it. Nov 08 21:19:21 I just booted. So, I need to upgrade real quickly. Nov 08 21:20:54 Okay. I got a LED in place on p8.21 now. Nov 08 21:21:05 I set it to gpio_pu first. Nov 08 21:22:33 What would you expect to happen on this circumstance. LED on or off when I use pruout commands? Nov 08 21:24:06 ha I think you're right, I can use config-pin in- first and then update it to pruin Nov 08 21:24:54 also: /var/lib/cloud9/common/prugpio.h <<< check here Nov 08 21:25:49 I found that info. from the prucookbook. Nov 08 21:26:06 that .h file should have some nice info. in it. Nov 08 21:29:29 thanks, looks a bit unpredictable to me at the moment Nov 08 21:30:25 Okay. Yea. That PRUCookbook/docs/common/ dir. has a lot of nice files for setting up the PRU. Nov 08 21:31:36 mm302: Did changing the gpio functionality w/ config-pin work for when setting up the pruout/in? Nov 08 21:34:45 it did work once, setting quickly in- on a pin and then running my app that sets pruin mode on it Nov 08 21:34:52 but then didn't work Nov 08 21:34:55 Right. Nov 08 21:35:25 You will need to use a sh script to set up your pins correctly from what I understand. At least, that is one way. Nov 08 21:36:37 I'll wait for Matt to confirm, I'm suspecting a scary answer like oh you can just update the device tree Nov 08 21:36:47 Okay. No issue. Nov 08 21:37:02 No hurt feelings here. I will cry later. Nov 08 21:38:43 men don't cry Nov 08 21:38:58 yes, they do. Look at me. I am a wet mess. Nov 08 21:39:25 That is part of my issue. I tear up over mundane garbage. Nov 08 21:39:47 Outside of that ordeal, I am sure @zmatt will be back later. Nov 08 21:42:25 Anyway. I think you need to stop it and then start it again before things work. Nov 08 21:42:36 So, stop, start, stop. Nov 08 21:43:02 bbl Nov 08 21:43:56 Okay. Have fun. Nov 08 22:49:31 real men cry but not about stupid things like loosing a race. Nov 08 22:57:53 lots of peopleputting two os in that word ltely Nov 08 22:57:56 lately Nov 08 23:23:23 that's because english is confusing :-p Nov 08 23:35:19 I got milktoast for tears. Nov 08 23:35:49 GenTooMan: While "helping" mm302, I ruined my pru testing interface. Nov 08 23:35:51 Boo. Nov 08 23:47:53 stuff happens at least you didn't explode. Nov 08 23:48:34 Right-O. No explosions equals fun times at Ridgemont High. Nov 08 23:52:05 night Nov 08 23:52:56 ayjay_t spelling in English is if you pardon the pun "exceptional" or exception filled. **** ENDING LOGGING AT Mon Nov 09 03:02:03 2020