**** BEGIN LOGGING AT Fri Aug 07 02:59:57 2020 Aug 07 03:21:05 Aw! Aug 07 03:21:17 What about the S2 makes no sense? Aug 07 03:22:37 Oh. B/c. One would have to use it on every boot? Aug 07 03:24:09 that first remark I guess makes _some_ sense, IF MattB0ne was indicating he was having problems booting from sd, but it sounded to me more like he was asking for precautions Aug 07 03:24:37 except if you intend to continue booting from SD you don't want to reflash eMMC, you want to wipe it Aug 07 03:25:14 which is just a simple "sudo blkdiscard /dev/mmcblk1" and poof, eMMC contents is gone Aug 07 03:26:17 Right. Aug 07 03:26:24 He said neither/nor, though. Aug 07 03:26:41 It seemed the fellow wanted general info. Aug 07 03:27:11 But, yes, wiping that eMMC can be done too. I am aware of it, too. You told me many times over. Aug 07 03:27:51 Speaking of...where did he go? Aug 07 03:37:39 sorry Aug 07 03:37:41 back Aug 07 03:38:05 so I am gonna try and boot from SD Aug 07 03:38:07 now Aug 07 03:38:20 MattB00ne: so, why exactly? Aug 07 03:38:57 i want extra PRU pins and so I need to disable my eMMC Aug 07 03:39:00 to get them Aug 07 03:39:17 I need the pins to use that H Bridge and have directional control Aug 07 03:39:55 I need two lines for the PWM and 1 line for the enable switch Aug 07 03:40:19 with my LCD cape, encoder and UART there wasnt much left to work with Aug 07 03:41:22 what pins are you using for the pru uart? Aug 07 03:41:38 P9_24 and P9_26 Aug 07 03:42:13 using P9.17/18 instead would free up pru pins Aug 07 03:43:58 also the H-bridge you showed doesn't have a direction-input, it instead uses two separate pwm signals Aug 07 03:44:38 right I need to put a switch in there Aug 07 03:44:54 so it switches the PWM from one pin to the other Aug 07 03:44:58 ugly I know Aug 07 03:45:14 I do have a 2nd hbridge that is not as clunky Aug 07 03:45:25 or use an ehrpwm controller (which has two pwm outputs) instead of ecap Aug 07 03:46:56 anyway, you do you I guess. do keep in mind that the eMMC will still be probed (hence the lines associated with it will toggle) during boot, and since the eMMC can't be held in reset you should avoid using both the "cmd" and "clk" lines (reusing one of them is okay, just not both) Aug 07 03:47:35 ok I will hold off on the SD Aug 07 03:48:01 what you mention woth the ehrpwm will that impact my plan to have that controled by PRU1 Aug 07 03:48:14 no Aug 07 03:49:19 both pru cores can access all peripherals on the system Aug 07 03:49:19 is that in py-uio? **** BEGIN LOGGING AT Fri Aug 07 03:51:12 2020 Aug 07 03:52:26 ok, so I am in your google file to set pins to use ehrpwm does that pwm sync in and pwm sync trip are the modes I need Aug 07 03:52:30 py-uio does actually have some pwmss support though I'd need to check what would be the steps to use that. you could also initialize it from pru or (ugliest but potentially simplest) let linux initialize it and then just sneakily change the duty-cycle behind its back Aug 07 03:52:40 no Aug 07 03:53:06 the "a" and "b" outputs of a pwm controller Aug 07 03:53:21 I mean, you could also use different pwm controllers I guess Aug 07 03:53:25 it doesn't matter much Aug 07 03:53:36 you can ignore sync in/out and trip Aug 07 03:53:42 they're irrelevant to you Aug 07 04:00:02 hmm so ehrpwm is actually better than ecap Aug 07 04:00:08 HW PWM vs SW PWM Aug 07 04:00:42 ??? they're both hw pwm, and ecap has more resolution Aug 07 04:01:17 was looking at this thread Aug 07 04:01:18 https://groups.google.com/forum/#!topic/machinekit/yys5OA1JeYo Aug 07 04:01:21 do not understand much Aug 07 04:02:41 with "pru pwm" they're not talking about pru ecap, they seem to be talking about some kind of software-pwm Aug 07 04:03:21 ok Aug 07 04:04:07 do I need to use an overlay to enable? Aug 07 04:04:33 https://github.com/mhaberler/BBBIOlib/blob/master/Demo/Demo_PWM/PWM.c Aug 07 04:04:33 not specifically no Aug 07 04:04:39 I was going to follow this example Aug 07 04:06:00 just configure the pins using config-pin Aug 07 04:07:03 and bbbio does all initialization from scratch, which you probably don't need to, and it directly messes with prcm, which you definitely shouldn't do Aug 07 04:07:25 ok Aug 07 04:07:33 so not a good starting point Aug 07 04:16:10 can the ehrpwm be on any pin Aug 07 04:17:03 i guess I am confused on actually wiring up to the ehrpwm Aug 07 11:12:15 argh why is gcc's code output for 64-bit arithmetic on ARM so moronic... https://pastebin.com/CUd8W0WH Aug 07 11:12:59 (this is at -O3) Aug 07 11:13:00 what the hell syntax is that? Aug 07 11:13:13 oh sorry, C++ Aug 07 11:13:29 ah Aug 07 11:13:32 just read it as (uint64_t)b ;-) (though it's not a synonym) Aug 07 11:13:40 yeah, I figured Aug 07 11:13:47 ought to generate the same code Aug 07 11:14:20 yeah it will, the difference is that uint64_t{ x } would complain if you try to use it for a narrowing cast Aug 07 11:14:41 I think I've discussed this nonsense with the gcc devs years ago Aug 07 11:15:14 the problem, iirc, is that gcc _really_ wants to allocate a register pair for 64-bit variables Aug 07 11:15:30 like, you'd think any sort of rudimentary instruction-level optimization would catch this Aug 07 11:16:49 in case you hadn't noticed, gcc kinda sucks Aug 07 11:17:07 it's full of deep-seated weirdness that's almost impossible to get rid of Aug 07 11:18:07 true... though I'm sure clang has its own obnoxiousness. I remember that for a while I went back and forth between gcc and clang because I kept hitting obnoxious behaviours in each of them :P Aug 07 11:18:24 oh, I've had arguments with all of them Aug 07 11:18:58 I was in the ARM toolchain team for a while **** BEGIN LOGGING AT Fri Aug 07 11:21:14 2020 Aug 07 11:23:07 I remember last time I manged to I basically just setup all the paths manually Aug 07 11:23:14 sometimes it's enough to make an arm-linux-gnueabihf-clang symlink Aug 07 11:44:38 mru: nope, same error Aug 07 11:52:41 mru: include paths used by g++ vs clang: https://pastebin.com/raw/J0948jPH Aug 07 11:52:41 I once had a very convoluted wrapper script to set things up right Aug 07 11:53:00 (with all paths fixed to not have any ../ in them) Aug 07 11:53:51 so yeah, this is pretty fail Aug 07 11:55:13 here's my old script: https://termbin.com/encv Aug 07 11:55:23 last changed in 2012 Aug 07 11:56:11 I don't remember what it does or why Aug 07 11:56:22 and it probably doesn't work any more Aug 07 11:57:41 interesting that you used gcc as linker Aug 07 11:57:51 at least that's what it looks like? Aug 07 11:57:54 I guess clang didn't work Aug 07 11:59:11 I just dug up an old makefile include that I made for compiling with clang, the first thing I see is a comment "# this... is... fucking... gross" Aug 07 11:59:54 https://pastebin.com/pEixcgRe Aug 07 12:22:09 it seems to do the right thing here when invoked with a symlink and --sysroot= flag Aug 07 12:22:15 for compiling, at least Aug 07 12:22:18 linking fails Aug 07 12:23:01 might also need some -march and/or -mfloat-abi flags Aug 07 13:12:03 mru: with what as sysroot? I don't see how sysroot could be used to get the correct include paths (as listed at the top in https://pastebin.com/raw/J0948jPH ) Aug 07 13:15:49 https://termbin.com/2w6v Aug 07 13:19:03 what a weird triple... arm-hardfloat-linux-gnueabi is not the right way to indicate hardfault, that would be arm-linux-gnueabihf Aug 07 13:19:34 it's what whatever tool I used to build it uses Aug 07 13:20:00 gnueabihflflbtq is the debian scheme Aug 07 13:21:07 that would be the same debian that refused to even acknowledge hardfloat for about two decades Aug 07 13:21:39 but yeah ok... I just noticed I was blind and that /usr/arm-linux-gnueabihf is sort of a sysroot (though if it were a real sysroot then it would have been /usr/arm-linux-gnueabihf/usr/include ) ... for some reason I thought that arm-linux-gnueabihf was a subdir of /usr/include and /usr/lib Aug 07 13:22:20 there are many ways of configuring and installing cross compilers Aug 07 13:22:29 zmatt: Did you see my panic paste yesterday? If so and no comment, that's fine ofc. (grin) Just wanted to be sure. I'm thinking I'm not using USB correctly, so I'm reading docs and twiddling code. Aug 07 13:22:37 actually that's exactly what https://wiki.debian.org/Multiarch/Implementation#What_does_the_end_result_look_like.3F says it is Aug 07 13:22:55 yet that's not how it is currently, so that must have changed Aug 07 13:23:14 Ragnorok: I did not, lemme see Aug 07 13:24:07 babble normally indicates a hardware issue Aug 07 13:24:23 of course it should not result in a WARN Aug 07 13:24:44 but the musbhdrc driver sucks Aug 07 13:25:00 Any particular manner of hardware issue, or just generically? Aug 07 13:26:33 so, "babble" means the device kept transmitting past its permitted window. however, if a hub is in the chain then it is responsible for detecting this and disabling the port of the babbling device, so more likely the usb phy on the am335x is mistakenly thinking it's receiving a signal, which can be due to signal integrity issues of some sort I think Aug 07 13:27:14 Roit. Thanks for the info. Aug 07 13:27:34 or maybe the device is actually babbling but the hub fails to deal with it Aug 07 13:27:51 I'm thinking that, actually. I'm working w/o the hub in the mix and it still happend. Aug 07 13:28:48 without a hub there's no way to tell whether the device is truly babbling or the BBB is just picking up interference and misinterpreting it as babble Aug 07 13:29:03 some E2E post: "Wireless dongles, especially those transmitting in the 2.4G spectrum, are notorious for causing interference on unshielded USB interfaces. This interference could certainly result in babble." Aug 07 13:30:57 I also found a post by someone who had it due to a fan switching Aug 07 13:30:59 I had a nubbin' in the hub, but right now it's not there. I'll move things around physically and see if it appears to affect anything. Aug 07 13:32:04 this is with kernel 4.19 right? Aug 07 13:32:08 Is it something I should worry about? Yes. Aug 07 13:34:22 Ragnorok? Aug 07 13:34:28 Yes. Aug 07 13:34:39 Did my last message not come through? Aug 07 13:37:58 oh I didn't understand that line as being a reply to my question Aug 07 13:38:16 kernel version does matter since the driver has improved over time Aug 07 13:38:41 Roit. Aug 07 13:39:04 Prolly why it works at all w/ 4.19 and doesn't work at all w/ 4.1. (grin) Aug 07 13:39:07 it may be worthwhile to use dynamic debug to enable debug messages in drivers/usb/musb/musb_dsps.c Aug 07 13:39:31 Okey doke. I'll look into that. Aug 07 13:40:55 e.g. echo 'file musb_dsps.c +p' >/sys/kernel/debug/dynamic_debug/control Aug 07 13:41:20 (use -p instead of +p to disable those messages again, dunno how spammy it'll get in your kernel log) Aug 07 13:41:30 Thanks! Aug 07 13:42:02 you can cat that file to get a list of all messages that can be enabled through this mechanism Aug 07 13:42:20 see also https://www.kernel.org/doc/html/v4.19/admin-guide/dynamic-debug-howto.html Aug 07 13:42:35 There we got. When I got to searching I expected to find that. Aug 07 13:43:57 dynamic debug is pretty neat Aug 07 13:44:23 I'm looking forward to finding out. lol Aug 07 13:46:31 basically, assuming you're not a sillybean who disabled it in kernel config, it means that pr_debug() and dev_dbg() calls in kernel code can be individually enabled and disabled at runtime Aug 07 13:47:25 and this is nearly zero-overhead, it's done by hot-patching a branch in the code Aug 07 13:48:12 so the only runtime cost when such a message is disabled is a single nop instruction or something like that Aug 07 13:48:35 That's spiff. Even better than fail-fast. Aug 07 13:52:10 I think it's pretty great, you can have debug messages whenever you want and with negligible runtime cost when those messages are disabled Aug 07 14:40:54 any good ways out there to debug pru assembly code? Aug 07 14:45:14 I'm not aware of a debugger. I wrote logs to a set block of shared ram as a ring buffer and read that from user space, but I'm using C. I could see that not working for asm. Aug 07 14:47:14 stare at the code until you spot the error Aug 07 15:26:06 hahaha staring hard atm. nother question, while pru1 is running, in mmaping the dram of it, any writes/reads form that dram space returns 0, but when stopped read/write is as expected.... Aug 07 15:26:22 can you only access the dram while the pru is stopped? Aug 07 15:29:14 I could hit shared while it ran. I believe the separate PRU RAM areas are also readble while it's running. Aug 07 15:30:15 hmmmm..mmmm....mmmmm Aug 07 15:30:26 more poking! Aug 07 15:31:53 sbbo to 0x00000000 is the local dram right? Aug 07 15:32:03 There's a thing out there called dumpmem iirc. It didn't do what I wanted, but I modded it to do what I wanted. Might rely on UIO ... didn't pay attention b/c I'm using UIO already. Aug 07 15:32:38 I don't know PASM. Aug 07 15:44:02 alright, i think i found some pointers to whats wrong, datasheet point to PRU_ICSS data space on the L4_fast as 0x4A30_0000. but it also says that this is for instruction/data/and contol space... Aug 07 15:44:29 i can't seem to find how to map the location of pru1 dmem to this offset. Aug 07 15:45:05 i think the 0x2000 offset i was using is actually pointing to the imem of pru1 rather than the dmem. Aug 07 15:45:13 Iirc 0x4A300000 is the base address for the PRUSS module. Aug 07 15:46:34 I believe that's correct. 0x4A300000 is PRU0's RAM and 0x4A32000 is PRU1's RAM. Aug 07 15:46:52 yup but it points to the whole pru subsystem, and i cant find how the individual sections are mapped within that. Aug 07 15:47:14 what about the imem? Aug 07 15:47:51 I don't recall where that is, as I didn't attempt to read it. There's docs out there somewhere. Let me see if I can at least find the name of what I have. Aug 07 15:48:34 Iram i think they refer to it as. in the ref manual, in the local sections both iram(for the instructions) and dram(for data) are at offset 0x0000 Aug 07 15:49:32 werrd, more poking time. it seems that when turning on pru1, writes/reads to the 0x4A302000 location return 0, but when it is off, they work Aug 07 15:51:46 Dunno. You're at a lower level than I was, but I wouldn't expect compiled C to behave radically differently than pasm. Aug 07 15:52:11 what about jtag Aug 07 15:52:38 Apparently if using CCS it is possible have a debugger for PRU. Aug 07 15:52:45 yeah Aug 07 15:53:28 I even have the emulator they suggest, but it was far simpler to use shared as a rolling log than try to get debugging working. Aug 07 15:53:55 i saw the same Aug 07 15:53:55 CCS and jtag adaptor Aug 07 15:53:55 i was going to get one when I get a little better at this stuff Aug 07 15:53:57 hmm, i have a xds200, but no good way to hook up to the pocketbeagles jtag Aug 07 15:54:08 01-AM335x_PRU_ICSS_Overview.pdf has a PRUSS memory map if you don't have that. Aug 07 15:55:44 son of a diddly, it is at that 2000 offset. Aug 07 15:56:05 hugh, why no comm then.... Aug 07 15:57:23 There's also a PRU Reference Guide which is much more comprehensive. Aug 07 17:08:52 Konsgnx: dram0 = 0x4A300000, dram1 = 0x4A302000, iram0 = 0x4A334000, iram1 = 0x4A338000 Aug 07 17:09:31 yup saw that in the icss overview, still hunting the cause of null's Aug 07 17:10:09 Konsgnx: I've never seen any change in behaviour w.r.t. dram between cores running or cores stopped Aug 07 17:11:25 going to try a benign fw from the cloud9 examples and see how it goes. Aug 07 17:12:28 Konsgnx: if you want to be able to inspect what's going on in pruss in detail as well as single-step cores (and access their registers in between steps), my py-uio library has functionality for that: https://github.com/mvduin/py-uio Aug 07 17:18:18 good to know! Aug 07 17:19:14 overview of addresses of the memories: https://pastebin.com/raw/ze6K4wWz Aug 07 17:20:12 (the pru cores can also use the global addresses to access via the L3, with substantial performance penalty obviously) Aug 07 17:22:04 anyway, what you're saying makes no sense, the accessibility of the drams does _not_ depend on whether cores are running or not, so you must be misinterpreting something somehow Aug 07 17:23:02 a core's iram and debug registers are inaccessible while it's running, but the drams are not part of or tied to the cores at all really, they're just three RAMs hooked up to the local interconnect Aug 07 17:41:49 sbbo doesnt autoincrement does it? Aug 07 17:41:55 nope Aug 07 17:43:16 sbbo &a, b, c, d is basically just memcpy( b+c, &a, d ); if we pretend you could get an actual pointer into the register file Aug 07 18:11:01 memory-mapped registers were once upon a time a thing Aug 07 18:11:31 well, pru's registers are memory-mapped, but only when the core is halted :) Aug 07 18:26:50 can you sbbo with a size \= unit of 4? Aug 07 18:31:44 bah, the backwards qbgt naming got me. Aug 07 18:32:14 Konsgnx: sure, and no alignment requirements either Aug 07 19:18:57 zmatt: how do I hook up to the ehrpwm controller Aug 07 19:19:08 what pins Aug 07 19:19:11 or can it be any Aug 07 19:32:28 MattB00ne: ehm, no of course it can't be any, like any peripheral function they are available on specific pins Aug 07 19:33:18 I thought so but figured I would ask, on your spread sheet what mode would be for that peripheral