**** BEGIN LOGGING AT Tue Nov 17 02:59:56 2020 Nov 17 02:59:57 Dang it. Nov 17 02:59:58 ? Nov 17 03:01:29 GenTooMan: Are you around? Nov 17 03:02:56 I will brb. Dang, I need to make sure my power adapter is under _________ amperes. Nov 17 03:06:37 Well, I only have one. 12v @ 0.5A Nov 17 03:07:12 It is a little under what I think we described yesterday. Nov 17 03:07:34 Or...let me give you credit here. It is a little under what I think you described yesterday. Nov 17 03:09:16 I just went back knowing it was not going to be good for my educatoin. Nov 17 03:09:21 education. Nov 17 03:09:22 Sorry. Nov 17 03:09:41 So, 0.8 was the story? Now, I have 0.5. Nov 17 03:20:15 Oh. Nov 17 03:25:14 https://www.amazon.com/GENUINE-I-T-Power-Supply-Model/dp/B06XFKLQZL <<< This is the exact one I have currently. Nov 17 03:28:53 So...12/0.5 = 24 && 24/12 = 2. So, I am short. Crud. Nov 17 03:29:20 1.5A is what I am short. Boo. Nov 17 03:30:37 Or... Nov 17 03:30:56 Is it 80% of 2A? Nov 17 03:31:05 What the heck. Nov 17 03:31:17 Aw hell. Come on, man. Yes sir, what the heck. Nov 17 03:31:19 Help! Nov 17 03:31:53 so you have a 6W PSU and you are trying to use that to power your BBGG? Nov 17 03:32:12 I guess. Nov 17 03:32:28 Well, yea. That is the wattage. Nov 17 03:32:38 Is that too little of wattage? Nov 17 03:32:42 do you know how much current the BBGG needs to turn on? Nov 17 03:32:51 Nope. I sure do not. Nov 17 03:33:46 What does the manual say? Nov 17 03:34:00 Manual? Nov 17 03:34:09 What manual? Oh...for the am335x? Nov 17 03:34:26 Or for the chip for handling the 12v input? Nov 17 03:34:46 no for the BBGG it should have power requirements or something Nov 17 03:35:02 Let me go and check. I doubt it does now but I will look. Nov 17 03:39:34 They, the seeed studio people, have a wiki with no real relevant info. and a schematic. Nov 17 03:39:38 No such manual. Nov 17 03:40:46 Anyway, no big woof. I will just wonder about powering the board until someone knows. Nov 17 03:43:36 do you have a way of monitoring the 12V supply (IE multi meter) so when you plug it in you can see if it drops like a rock? Nov 17 03:46:19 Ha. Nov 17 03:46:25 yea. Nov 17 03:46:27 Well. Nov 17 03:46:34 Um, I thought about that idea. Nov 17 03:47:19 I just do not know how to test the BBGG while it is plugged in via barrel jack. Nov 17 03:47:49 I have some o-scope clips for my DMM. Nov 17 03:47:56 If that helps. Nov 17 03:49:18 So, center is GND and the Outside if V. Nov 17 03:49:20 Okay. Nov 17 03:49:35 Let me go and check. Nov 17 03:50:30 No issue. Nov 17 03:51:01 Scratch the last line. Sorry. Nov 17 03:53:12 I will test it in time. Right now, nature is calling me to yell in a dark room alone for a bit. Please hold. Nov 17 04:00:56 Okay. I will go and question seeed studio. I feel like I am harassing you and this channel right now. I should stop. Nov 17 04:03:49 heh well good night then Nov 17 04:06:54 Hey GenTooMan, no offense. Nov 17 04:07:14 I just feel like I am harassing answers out of you when there is not really any solution right now. Nov 17 04:08:03 The Seeed Studio people have this board available but w/out answers to specific questions, my tests may prove invaluable. Nov 17 04:09:11 sorry. Scratch invaluable. NOt valuable. Nov 17 04:09:50 The reasoning behind the "not valuable" answer is b/c the board may bite the dust. Nov 17 04:10:19 I have put a ton more amps into the BBB. Nov 17 04:10:29 No issue, there. Nov 17 04:11:14 But, this one handles 12v and not 5v. There is a difference and I am thinking right now that i am unaware of what transpired when Seeed Studio or whomever put it together for testing and action. Nov 17 04:17:56 sorry. I just say the time. Nov 17 04:18:10 over and dd. Nov 17 05:01:46 Hi,I am working on BBB AM335x for power management stuff as i am very new to linux power management i need a bit help i am trying to achieve following using sysfs but i didnt got sucessi want to put my whole system into sleep state /idle state except WiFi and backlight, when i am writting $echo mem > /sys/power/state my whole system is going Nov 17 05:01:46 into sleep state similarly i have checked with /sys/class/backlight but didnt worth.Can someone help me how i can do it ? How i can suspend and resume particular device only ??Thanks Nov 17 05:18:13 are you able to see my earlier message ?? Nov 17 07:41:24 Hi Nov 17 07:42:14 zumba_addict i am trying some power management can you help ? Nov 17 07:44:07 talnikar: please don't address your question to random people who come into the chat Nov 17 07:45:37 zmatt where i should ask ? Nov 17 07:45:48 if anyone has useful feedback to give I'm sure they will, but it's a rather obscure topic so you can expect to need to have a fair bit of patience and luck to get a useful answer Nov 17 07:46:44 though since your question isn't particularly BBB-specific you could also try asking on TI's E2E forum (e2e.ti.com) Nov 17 07:47:34 i am trying power management specifically on BBC Nov 17 07:49:21 I understand the BBB is your target, but there's nothing inherently BBB-specific about your question... whatever the answer is would equally well apply to other AM335x-based devices (and quite possibly to linux-based devices in general) Nov 17 07:49:59 hence you might have more luck just phrasing it as a question about the AM335x on TI's forum Nov 17 09:26:04 Hi all..i have lost connectivity in between posting my concern again Nov 17 09:26:10 Hi,I am working on BBB AM335x for power management stuff as i am very new to linux power management i need a bit help i am trying to achieve following using sysfs but i didnt got sucessi want to put my whole system into sleep state /idle state except WiFi and backlight, when i am writting $echo mem > /sys/power/state my whole system is going Nov 17 09:26:10 into sleep state similarly i have checked with /sys/class/backlight but didnt worth.Can someone help me how i can do it ? How i can suspend and resume particular device only ??Thanks Nov 17 10:17:18 Hi, I am trying to program serial communication using interrupt method. I am not able to get on with solution. Please suggest me the steps. Nov 17 10:23:37 Hi, I am trying to program uart1 communication with polling method using registers access in linux method with mmap. But no communication happening. Please guide me. Nov 17 15:25:30 nickand[m]: why would you want to do that? Nov 17 15:25:54 just for educational purposes? Nov 17 15:31:01 _generally speaking_ you shouldn't directly mess with peripheral registers from linux userspace and instead leave that to the device drivers in the kernel Nov 17 15:31:32 where's the fun in that? :) Nov 17 15:32:41 there are some legitimate use-cases for using a peripheral directly from linux userspace, but I have a hard time imagining one for the UART, unless it's just to learn how it works (e.g. because you want to eventually use it from PRU) Nov 17 15:36:59 there is fixing up poor handling of the PM register on the UART... ;) Nov 17 15:37:41 hmm? what's there to poorly handle about sysconfig? Nov 17 15:38:17 there is another register (beyond the 165550 stock ones) that controls details of PM...not the generic sysconfig stuff Nov 17 15:39:32 sysconfig is a TI-specific register for PM, and the only PM-related register I can think of Nov 17 15:40:03 let dig up the TRM... have a video call running...low BW Nov 17 15:41:27 I just checked my header, the only PRCM-related registers are these: https://pastebin.com/LhLKgg2y Nov 17 15:43:12 so there's not much to misconfigure... linux will set sysconfig based on hwmod data which is usually right (and a one-line fix if it's not) Nov 17 15:45:23 nevermind... it is unsupported on the AM33x Nov 17 15:45:48 which chip were you thinking of? Nov 17 15:46:18 the AM335x does have some undocumented (but afaik working) UART registers but those still don't involve PM Nov 17 15:46:30 the wake control registers but it is unsupported on teh 33x Nov 17 15:46:53 uart0 supports wakeup Nov 17 15:46:54 other TI SOCs has that wired up and caused interrupt loops (stock interrupt handler doesn't know what to do with it) Nov 17 15:46:55 iirc Nov 17 15:47:09 'k that Nov 17 15:47:24 but the wakeup irq goes to the Cortex-M3, not the Cortex-A8 iirc Nov 17 15:47:37 think I have seen that on the classic Beagle Nov 17 15:47:50 that just sounds like a kernel driver bug though Nov 17 15:47:52 I have seen it loop on the A8 side Nov 17 15:48:34 yes, yes it is a bug... classic 16550 doesn't have it...this was in the era of ttyUSBx vs ttySx + misc special detections Nov 17 15:49:03 I mean ttyOx not ttyUSBx Nov 17 15:51:44 honestly I still think a separate driver is saner than using the generic 8520 driver with custom hooks... Nov 17 15:52:34 i can argue it both ways Nov 17 15:52:44 I can argue it _three_ ways Nov 17 15:52:50 that thing is becomes a monster no sane person would want to touch given how it covers a horde of vaguely similar yet actually different devices, 99% of which you won't be able to test after making any changes Nov 17 15:53:16 all of drivers/tty is a monster that nobody wants to touch Nov 17 15:53:43 there is a lot of code like that Nov 17 15:54:17 mru: yes and no... a driver for a platform-specific device is much easier to overhaul than one for a gazillion devices across all architectures Nov 17 15:54:25 then you get tossed into a project to do XYZ... get it working for $X...get it working and upstream - $X^Y ;) Nov 17 15:55:01 zmatt: I'm not disagreeing Nov 17 15:55:49 and in this case, the saner way to initialize and operate the OMAP UART makes explicit use of its specific features rather than its backwards compat Nov 17 15:56:04 having been through the x86 days where there were 242349314832723427389 different flavors of 16550/16450/etc.... a monolith driver was really nice Nov 17 15:56:06 I wish the backwards compat were let go entirely, it's a disgusting register interface Nov 17 15:56:19 hmm, I can see that point too Nov 17 15:56:33 like, if it gets out of hand Nov 17 15:57:04 in those days, there were so many variants on the classic 8250 Nov 17 15:57:11 blame Intel ;) Nov 17 15:57:29 probably all of them gross Nov 17 16:00:58 I just hate the UART register interface... especially initialization is way more complex than it ought to be for its functionality Nov 17 16:01:05 https://e2e.ti.com/support/processors/f/791/p/379360/1342615#1342615 Nov 17 16:01:46 it makes a decent read the datasheet teaching problem :D Nov 17 16:02:21 it's confusing enough that the TRM actually gets the initialization procedure wrong Nov 17 16:02:55 you are suppose to know the UART because you learned on the 8250 and then moved to the 16450 then the 16550 ;) Nov 17 16:03:28 I'm not an archeologist Nov 17 16:03:42 :P Nov 17 16:23:44 sadly it seems easier to "reverse engineer" existing projects to understand how to work with perhiperals than to use the TRM Nov 17 16:26:40 I mean, if you can find a project that does something similar to what you want.. Nov 17 16:26:56 and there's probably also a fair amount of code out there that's just Bad and Wrong Nov 17 16:27:04 and works by luck more than anything else :P Nov 17 16:27:29 and I think the TRM is decent enough most of the time... it varies a bit per peripheral Nov 17 16:28:06 like, I curse the TRM often enough, but from what I've seen of other chip documentation, the grass ain't greener elsewhere Nov 17 16:30:06 ideally the TRM should be accompanied by code examples for each perhiperal Nov 17 16:30:54 as there is 0 code in it, it's often unclear how to setup certain things in practice Nov 17 16:32:10 I'm now having a look at this old project https://github.com/ML-Cai/BBBIOlib that shows some way to use SPI and other perhiperals Nov 17 16:32:14 I don't think I agree, the purpose of the TRM is to describe the hardware in details, it's not a cookbook or a how-to guide Nov 17 16:33:11 also, iirc the code of that library was horrible Nov 17 16:34:11 the hardware details are not really explained many times, but left to the imagination by providing a name supposed to be self descriptive, but not always sufficient Nov 17 16:34:33 example? Nov 17 16:35:06 code is just one way of setting things up Nov 17 16:36:39 besides, TI does have code examples for the AM335x... it's called StarterWare. the code is a steaming pile of pig manure, but hey :P Nov 17 16:37:36 the McSPI, McASP sections has all the info you need to set things up Nov 17 16:37:36 I give you a simple example, I don't see any mention of how to configure the pins before using a perhiperal in the TRM, but looking at BBBiolib_McSPI.c I can see some pinmux checks that makes me think, ha this is what I need to do Nov 17 16:38:03 pinmux setting is global to most blocks Nov 17 16:38:23 pinmux configuration is documented in the Control Module chapter Nov 17 16:38:24 the few McSPI specific settings are documented in the McSPI section (the D0D1 monstrosity for example) Nov 17 16:38:41 right, because those are internal to the peripheral Nov 17 16:38:51 it is a 2nd mux Nov 17 16:39:09 while the peripheral is completely unaware of the pinmux configuration stuff in the control module Nov 17 16:39:25 my only complaint is there is no solid explanation of why input has to be enabled on the McSPI clk even though it is the master Nov 17 16:39:53 I feel like that's explicitly documented, but maybe I misremember Nov 17 16:39:55 I do understand why Nov 17 16:40:33 do explain why it has to be looped outside of the block Nov 17 16:41:18 yep I remember correctly, it's mentioned in a footnote in 24.2.3 McSPI Pin List Nov 17 16:42:03 in general someone not already knowleadgeable on how to use SPI would likely not succeed just using TRM Nov 17 16:43:08 whta rev of the TRM? Nov 17 16:43:43 I don't see a footnote on rev G Nov 17 16:43:50 mm302: I don't know if that's true, though in general it's not the TRM's job to explain how SPI works in general (though it does so anyway) Nov 17 16:44:04 ds2: rev Q (2019-12) Nov 17 16:44:16 must have been added after the complaints ;) Nov 17 16:44:31 perhaps Nov 17 16:44:50 ds2: anyway, it has to do with signal timing Nov 17 16:45:28 zmatt: as in it runs fast enough that the delay from block to pinmux is significant? Nov 17 16:45:37 yes Nov 17 16:46:08 and using the looped back clock from the pad ensures better timings characteristics Nov 17 16:46:43 even with a 48MHz clock? I haven't worked out the timings Nov 17 16:50:10 ok for example on how to set the pins to use spi0 (thanks zmatt for pointing to the "Control Module chapter" I didn't know about that), although it's different from the standard config-pin way of configuring the pins and just redirects to a generic "9.3.1.50 conf__ Register " Nov 17 16:50:10 so, it's interesting to look at the McASP timing specs since when as a master it supports both using the clock internally and using the clock from the pad. when using internal clock the data input has 11.5 ns setup time and -1 ns hold time, when using loopback clock it has 4 ns setup time and 0.4 ns hold time Nov 17 16:51:18 mm302: config-pin is a BBB-specific software invention, if you want to compare it to the actual pin configuration you need to look at the DT sources to see how the actual pinmux nodes are defined that are used by the pinmux-helper devices Nov 17 16:52:39 11.5 ns is more than half a clock cycle at 48 MHz Nov 17 16:52:52 thanks zmatt, I think I'll have a closer look at the BBBio code Nov 17 16:53:05 mm302: the BBBio code does no pinmux setup Nov 17 16:53:16 you're required to deal with that externally Nov 17 16:53:27 it does some checks on the expected modes for all 4 pins Nov 17 16:53:32 however the same will be true for your PRU code Nov 17 16:53:44 so they are trying to avoid having to model internal delays Nov 17 16:53:58 in BBBIO_McSPI_EP_check Nov 17 16:54:00 in all cases you should just either use config-pin or use your overlay to setup pins Nov 17 16:54:08 it's not something your software has to know or care about Nov 17 16:54:58 mm302: I guess it's its way of trying to be user-friendly? Nov 17 16:55:32 like, normally this isn't something a driver would check, and linux drivers definitely don't Nov 17 16:55:49 I wrote a little C++ wrapper that sets the pins when the app starts accordingly, I just need to figure out the expected settings, I'll figure that out, but was just an example of why TRM sometimes does not clearly show how to Nov 17 16:57:20 it does, but not in the peripheral chapter since it's not part of the peripheral Nov 17 16:58:11 in other terms... the AM335x is a giant building with a limited number doors Nov 17 16:58:24 the McSPI, McASP, etc chapters document the departments Nov 17 16:58:30 part of it kind of is, for example like knowing what mode should I set for the CLK Nov 17 16:58:36 you still need to tell the door receptionist where to send things to Nov 17 16:58:41 PRCM and pinmux are part of the overall integration of the peripheral in the SoC... the chapter of each peripheral does give a summary of its integration details, but if you want to write baremetal code you still need to have read the PRCM and Control Module chapters Nov 17 16:59:58 mm302: modes for all pins are listed in the Control Module chapter and probably also the datasheet, or you can consule my spreadsheet: https://goo.gl/Jkcg0w#gid=698174264#gid=1775283126 Nov 17 17:00:04 whoops Nov 17 17:00:11 https://goo.gl/Jkcg0w#gid=1775283126 Nov 17 17:00:53 the BBB tab gives a flat list with excessive details, but the P9 and P8 tabs are probably more useful, they should all the info you might need for the expansion header pins Nov 17 17:01:15 *should contain Nov 17 17:01:59 e.g. the spi 0 functions on P9.17/18/21/22 are all mux mode 0 Nov 17 17:02:18 (listed in the F0 (function 0) column) Nov 17 17:02:36 thanks, I'll have a closer look at chapter 8 PRCM and 9 CM, just out of curiosity Nov 17 17:02:46 of course that only matters if you're writing pinmux nodes in DT yourself Nov 17 17:02:49 not if you use config-pin Nov 17 17:03:31 do note that Control Module registers cannot be written directly by PRU nor from linux userspace (without a really obscure hack that's probably technically a security hole) Nov 17 17:04:01 just out of curiousity... can you write to it from DMA? Nov 17 17:04:03 oh Nov 17 17:05:16 and you also shouldn't mess with PRCM registers behind the kernel's back, just let it handle those. if you want to use a peripheral directly, use an overlay to 1. disable the kernel driver or replace it by uio_pdrv_genirq 2. tell the kernel to keep the peripheral enabled using the ti,no-idle; property Nov 17 17:05:46 ds2: only if the DMA descriptor has been setup using privileged writes. (EDMA proxies privilege) Nov 17 17:06:59 so it should be possible to allow PRU to write to a specific control module register by having privileged code setup an EDMA transfer from PRU memory to the Control Module and then have PRU manually trigger it Nov 17 17:07:00 I just think would be handy for the perhiperal chapter to mentino the expected pin setup Nov 17 17:07:19 "expected"? Nov 17 17:07:26 it is very application specific Nov 17 17:08:36 I agree it would be nice if it were mentioned in the pins list Nov 17 17:08:44 3 pins are driven by the perhiperal I believe so should depend on it, except for the receive pin Nov 17 17:08:59 ?? Nov 17 17:09:12 both receive and transmit pins need to be correctly setup Nov 17 17:09:12 the same pin signal can be sent to multiple possible physical pins! Nov 17 17:09:19 that too Nov 17 17:09:25 so what is typical in that case? Nov 17 17:09:43 (though not for the spi 0 on the am335x) Nov 17 17:10:39 at least the standard 4 pins used for spi0 are typical Nov 17 17:10:44 also, which pads they correspond to depends on the chip package (ZCZ vs ZCE) Nov 17 17:11:01 4 pins typical??? Nov 17 17:11:08 which 4 pins? Nov 17 17:11:14 clk, miso, mosi, cs Nov 17 17:11:21 (with two options for cs) Nov 17 17:11:26 CS is not used in a lot of devices Nov 17 17:11:35 I've never seen a device that doesn't require CS Nov 17 17:11:56 a lot of devices can run with /CS tied low on the device side Nov 17 17:11:58 I know they exist, but I have personally not encountered them in any design I've worked on or examined Nov 17 17:12:18 i run into them a lot Nov 17 17:12:27 interesting Nov 17 17:12:58 for 1 device on the bus, CLK going active should be enough of a hint Nov 17 17:13:48 most devices if not all devices I've ever used use CS to demarcate the start of a command / transaction Nov 17 17:15:15 without CS I'd also be slightly nervous about the fact that if the device somehow picks up a noise pulse on the clk it would remain permanently desynced :P Nov 17 17:17:51 some chips have a /RST input Nov 17 17:17:58 unless ds2 has a perhiperal that just returns a constant value, so sync woun't be much of an issue Nov 17 17:19:13 ds2: I mean yes, but that means you have to have software control over it *and* software logic that realizes shit got fucked up and the device needs to be reset Nov 17 17:19:34 *shrug* never had things desynced Nov 17 17:19:42 I agree it's not likely Nov 17 17:19:54 which means it won't happen except at the most incomvenient moment ;-) Nov 17 17:20:16 if you have noise on a TOTEM pole driven line, you have bigger issues Nov 17 17:20:30 I mean, I don't disagree with that :) Nov 17 17:20:37 maybe some ESD event Nov 17 17:20:56 it's probably just an irrational worry Nov 17 17:21:06 arrg..can't find a public datasheet to point out Nov 17 17:21:12 but I'd still be inclined to hook up CS if available Nov 17 17:21:36 it is useful for PM... a lot of chips goto sleep if /CS is high Nov 17 17:23:48 looking more closely at bbbio it provides BBBIO_sys_Enable_GPIO to set a pin to a specific mode, setting a binary mode that I guess is the one from `9.2.2.1 Mode Selection` Nov 17 17:24:29 that's not doing anything with pins Nov 17 17:24:39 it's rudely messing with PRCM behind the kernel's back Nov 17 17:25:35 (which _will_ get upset about this if it finds it, which it might or might not) Nov 17 17:25:42 *finds out Nov 17 17:27:02 BBBIO_sys_Disable_GPIO is even worse, that's just a recipe for a kernel panic Nov 17 17:27:15 oh it's also completely broken Nov 17 17:27:57 well, it's broken for gpio0, so that's 1/4 broken I guess rather than completely broken :P Nov 17 17:28:20 mm302: basically, most of BBBio_Lib seems to be a bad example of how _not_ to do things :P Nov 17 17:28:51 unfortunately BBBio is my only source of truth on how to use the SPI at the moment Nov 17 17:30:09 I mean, for your device having PRU bit-bang is both easier and more efficient than using McSPI :P Nov 17 17:30:50 true, I'll just play with it a bit more before giving up Nov 17 17:31:11 even if I mess up the pin config hopefully nothing should burn Nov 17 17:31:25 again, pin config should just be done with config-pin Nov 17 17:31:28 or your overlay Nov 17 17:31:45 so this lib offers nothing useful for that aspect Nov 17 21:13:44 ds2: "so they are trying to avoid having to model internal delays" .. I just realized I never replied to this thread. but yes, it's a super simple and effective way to compensate for internal delays even though they will vary depending on process, voltage, and temperature Nov 17 21:15:53 I mean, what's the alternative? AM572x-style delay lines programmed based on chips modeling and compensated by (factory or runtime) calibration measurement Nov 17 21:16:50 or some fixed value and hope the timing is acceptable for the entire PVT range Nov 17 21:17:18 I'd think half way there should be enough... something that puts out around 4-8nS of delay to get it near the ballpark then call out setup/hold specs Nov 17 21:17:55 in any case, the old docs didn't have that footnote you mentioned... this goes back to the O3 days at the very least Nov 17 21:18:02 I mean, it's possible but that still requires intentional delay elements that need to be tuned to the design and will differ depending on which pin you muxed them to Nov 17 21:18:18 while clock loopback gets you the compensation "for free" Nov 17 21:19:24 and fixed compensation will add uncertainty, which is easy to see for the McASP example I mentioned: setup time + hold time for inputs is 10.5 ns without clock loopback vs 4.4 ns with clock loopback Nov 17 21:19:49 the McASPs run a lttle slower Nov 17 21:20:06 these times are in ns so they don't depend on clock frequency Nov 17 21:20:30 no..slower so the delays are less percentagewise of the actual clock Nov 17 21:20:46 a 1MHz clock could careless about 10.5nS delays Nov 17 21:20:51 also McASP has a min cycle time of 20 ns, i.e. max 50 MHz Nov 17 21:21:01 a 1GHz clock would be in trouble Nov 17 21:21:15 whick clock are you talking about? MCLK? Nov 17 21:21:20 bit clock Nov 17 21:22:04 yes but how common is a 50MHz clock for audio? Nov 17 21:22:27 rare. I'm kinda lost about what point you're trying to make Nov 17 21:22:44 32 bit * 2 chan * 48000 sample/sec is about 3MHz Nov 17 21:23:25 the point is the McASPs don't really care about the delays given that it is a smaller percentage Nov 17 21:23:42 I was using McASP as example simply because it's a synchronous serial interface with timing requirements documented both with and without looping the clock via the pad Nov 17 21:23:58 since it is critical on the McSPI, using this ride seems... Nov 17 21:23:58 allowing the impact of the I/O cells to be seen Nov 17 21:24:39 makes me wonder about the PRU now Nov 17 21:24:41 (while McSPI only supports looping the clock via the pad) Nov 17 21:29:11 TRM revision G is like ancient... why are you still consulting that? :P Nov 17 21:29:25 because I was on a video call and that's all I had locally handy Nov 17 21:29:46 sometimes older versions have more information Nov 17 21:30:17 and because I traced down that very issue way back on the O3 Nov 17 21:30:54 the best policy with TRMs is to archive every single one...never knowwhat they will remove/obfuscate/add :( Nov 17 21:30:55 mru: true, which is why I download and keep every version :P Nov 17 21:31:02 hehe, yep Nov 17 21:31:04 not TI, but I've seen datasheets go from a fairly complete register description to "call this function in the sdk" Nov 17 21:31:30 mru: oh that sucks... I don't think I've seen anything that obnoxious with TI Nov 17 21:31:40 I generally just save all files, so I wind up with piles of versions over time. It's only hard drive space. Nov 17 21:31:41 they do sometimes hide details that they don't want to support Nov 17 21:32:28 I have, currently, 3.6 GB of pdf docs Nov 17 21:32:47 are there any people from TI in this chat? Nov 17 21:33:05 sometimes Nov 17 21:33:16 there are also those special editions where they accidentially added sections Nov 17 21:33:31 I have 7.7G of PDFs in ~/docs/ti Nov 17 21:34:20 probably they will pretend they don't see the converstation to avoid blushing :-) Nov 17 21:35:20 I'm not clever enough to tally all the scattered PDF sizes. Nov 17 21:35:40 find -name '*.pdf' -exec du -hsc {} \+ | tail -n1 Nov 17 21:36:17 or if you keep them on a separate volume, df -h /path/to/docs Nov 17 21:36:33 Noob didn't use {}. WTF. Nov 17 21:39:53 So tiny. Only 68M. Hardly bears mention. Nov 17 21:40:36 don't mention the bears Nov 17 21:41:24 Or the otters? Nov 17 21:41:30 but yeah, some PDFs have some really good stuff... like the best documentation for the am335x debug subsystem is in the dm816x TRM, together with the omap36xx/dm37xx TRM for details about ICEPick (although I think that's ICEPick-C not -D) Nov 17 21:42:26 the dm814x TRM is the closest relative to the am335x that has a decent Interconnects chapter Nov 17 21:43:34 it's like when someone submits multiple FOI requests and receives differently redacted documents Nov 17 21:43:53 lol Just hold them to the light... Nov 17 21:44:07 it's been done Nov 17 21:44:39 and if you're lucky, the redaction is just black rectangles in a separate pdf layer Nov 17 21:46:09 personally the only TRM info I use is the register tables, but that could be replaced by a spreadsheet Nov 17 21:46:10 omap4 is a good place to learn about PRCM. (dm81xx use simplified omap4 prcm, the am335x uses simplified-and-messed-up omap4 prcm) Nov 17 21:46:35 mm302: well that explains why you're having trouble understanding how it works ;) Nov 17 21:47:04 having things like register tables and module information / integration data in machine-readable format would however indeed be extremely useful Nov 17 21:47:26 no, because only the register tables give some details in my opinion Nov 17 21:48:12 I'm not saying they're not important, but I wouldn't want the rest of each chapter to be missing Nov 17 21:48:21 one time, the only information I had on a peripheral was which addresses weren't documented as belonging to something else Nov 17 21:48:34 plus a few register names Nov 17 21:49:03 that was enough to find a manual for a completely different chip (different vendor) that happened to use the same block Nov 17 21:49:31 so you see, TI is pretty good, even if we complain at times Nov 17 21:49:37 yep Nov 17 21:50:16 I mentioned that earlier too... I may curse the TRM sometimes but I've seen the grass ain't greener elsewhere Nov 17 21:50:22 TI docs are pretty great overall Nov 17 21:50:49 for ICs in general, nothing beats Linear datasheets Nov 17 21:51:32 mm302: I don't know if I've linked it before, but I also have a personal mcspi header with some notes based on testing/observation: https://liktaanjeneus.nl/mcspi.h.html Nov 17 21:51:33 (the rest of) ADI is also very good, often better than TI Nov 17 21:52:17 zmatt, yes I saw it thanks, now I'm just trying to write a very simple assebly code to start mcspi Nov 17 21:53:02 mru: hmm, we use the analog adau145x and it's documentation is not that great Nov 17 21:53:46 speaking of, didn't ADI buy Maxim recently? Nov 17 21:54:00 there are always exceptions Nov 17 21:55:43 I've never used that device or similar Nov 17 21:59:29 would you recommend using .assign to just load a 32bit perhiperal register into a local register? I know it's meant for .struct, but seems tidier than using #define for the use of local registers Nov 17 22:00:51 I seem to recall it only works for structs Nov 17 22:01:21 yes, I was going to have many single .u32 structs Nov 17 22:01:43 I wouldn't consider that cleaner than using #define Nov 17 22:02:02 well, I guess it would help detect conflicts Nov 17 22:02:18 because of scopes, will tell you if you override by mistake a register I think Nov 17 22:02:19 you could also stick your random global vars into a single struct Nov 17 22:02:46 true Nov 17 22:02:52 dunno... I do indeed wish you could use .assign for single .u8/.u16/.u32 vars Nov 17 22:11:33 I cannot have nested .struct ? Nov 17 22:11:58 good question, no idea Nov 17 22:15:48 looks like it's not allowed, that's very limiting, I guess I'd have to accept it's dirty assembly after all Nov 17 22:22:52 Hi I'm new to open source. Looking forward to contribute to this world, pls guide me how to contribute to ur projects. Nov 17 22:24:01 translation: "hi, I'm here in the context of GSoC" Nov 17 22:24:23 there's a separate channel for gsoc, #beagle-gsoc Nov 17 22:26:40 cool, I didn't know it was possible to contribute to the beagles Nov 18 01:25:50 GenTooMan: So, I contacted seeed studio about their BBGG. I will receive some type of reply hopefully. They replied so far but the person did not understand my ramblings. Nov 18 01:26:18 So, I tried to make it super clear. Nov 18 01:50:58 clear as mud! Nov 18 01:51:52 does the BBB and Debian OS look for executables in /usr/local/? Nov 18 01:52:20 When I typed "look," i mean w/out changing $PATH. Nov 18 01:52:39 normally /usr/local/bin is part of PATH by default Nov 18 01:52:45 Oh. Nov 18 01:52:46 Okay. Nov 18 01:52:48 Nice. Nov 18 01:52:51 Thank you. Nov 18 01:53:09 which is the place to put custom executables if you want them to be available globally (i.e. for all users) Nov 18 01:53:36 Right. It is basically just me but who knows? One day, another person may be able to use it. Nov 18 01:54:10 I am still messing w/ pocketsphinx. I think the makers of pocketsphinx moved on. Nov 18 01:54:18 I think they are working on a new idea. Nov 18 02:04:02 I got that sucker to work it and it works! Nov 18 02:04:10 Ewww weeee! Nov 18 02:44:20 Hello. On the BBB, how would I install libgfortran3 and have specific libs. only use it? Nov 18 02:44:30 I have Buster now w/ kernel 4.19.x. Nov 18 02:44:42 Buster uses libgfortran5. Nov 18 02:45:06 Is there a specific idea I need to view? PATH or is it another idea? Nov 18 02:46:25 backports? **** ENDING LOGGING AT Wed Nov 18 03:02:03 2020