**** BEGIN LOGGING AT Tue Jul 18 03:00:04 2017 Jul 18 08:41:22 Hi, there is any known issue with drm/tilcdc and weston that causes a freeze of all system? I'm seeing a weird issue after some seconds/minutes to launch weston, my BBB completely freezes, no kernel messages, nothing, I need to do a power cycle to recover the system. fwiw I'm not using the sgx. Jul 18 08:57:15 The issue is trivially triggered by running weston-simple-shm Jul 18 10:39:27 which kernel version are you using? Jul 18 10:51:54 zmatt: tried with some of them, 4.4, 4.9, 4.10, 4.11 and also the ti kernels, I think that the diference is that now I'm using weston 1.12 whereas before I was using 1.6 Jul 18 10:52:23 zmatt: I suspect that something introduced later triggered the issue, is really easy to reproduce Jul 18 10:54:03 hmm Jul 18 13:40:34 hi, im learning to use the PRU's on the beaglebone black. I've written some asssembly code to manage the integrated UART based on the TI PRU manual, but I'm not getting what I expect. Is there support for this part of the PRU from TI on the BBB? Jul 18 13:41:46 wintermuted: your question is a bit vague Jul 18 13:42:09 I've never played with it yet, but I'd assume it just works Jul 18 13:42:28 ok, well I can explain what I'm doing more... Jul 18 13:44:15 I initialized the UART on the PRU according to my understanding of the TI manual. Then I write a few characters out and watch for the response with a logic analyzer. But I get nothing. Right now, I'm suspecting that my pinmux settings may be to blame, but I haven't been able to find any example overlays to check my work Jul 18 13:45:47 i did find this link though, for the amx437, that says there is no linux support for some of this... https://e2e.ti.com/support/arm/sitara_arm/f/791/p/503496/1903840 Jul 18 13:46:00 you can check your pinmux with my show-pins utility: https://github.com/mvduin/bbb-pin-utils/blob/master/show-pins Jul 18 13:46:25 it needs to say something like "uart pru rxd/txd" for the relevant pins Jul 18 13:46:49 cool. let me run that and confirm my configuration, then Jul 18 13:47:02 that guy seems to want to use the uart from linux rather than from the pru core Jul 18 13:47:42 not sure why they'd want that instead of using one of the other uarts... maybe he just needed an additional uart, or perhaps the higher speeds supported by the pruss uart Jul 18 13:47:54 it shouldn't be too hard to get that working if one were motivated Jul 18 13:49:29 ahh, ok. hmmm... Jul 18 13:50:21 it shouldn't be too hard to create an overlay to setup pinmux for it Jul 18 13:50:51 presumably it can also be configured using cape-universal instead Jul 18 13:51:32 hmm sure enough, the pru pins arent i use the capemgr to load my pins. So there must be a step I'm missing Jul 18 13:51:43 arent's loading* Jul 18 13:52:07 can you pastebin your /boot/uEnv.txt ? Jul 18 13:53:55 sure, but I'm doing the PRU configuration after boot. I can send you the overlay for that as well Jul 18 13:53:55 https://pastebin.com/VjG9Zibb Jul 18 13:55:44 you'll need to disable cape-universal since it conflicts with pretty much any overlay Jul 18 13:55:56 remove the "cape_universal=enable" from line 50 Jul 18 13:56:33 I just checked, my earlier presumption that you can use cape-universal to setup the pinmux for this was actually wrong, they neglected to include the pruss uart as option Jul 18 13:57:32 Ah, you mean the cape manager can't load the pinmux for the pruss uart? Jul 18 13:58:07 it can, but you need to disable cape-universal since it occupies all pins Jul 18 13:58:43 gotcha. So if I disable that on boot, it should deconflict Jul 18 13:58:59 if you checked kernel log there will have been errors about the pin conflict when you tried to load the overlay to setup pinmux Jul 18 14:00:48 i see a few errors, but none exactly like I'd expect. I probably dont know the right keyword to search for. Let's try a reboot Jul 18 14:13:08 your show-pins script is quite handy. It looks like when I load my overlay, my pruss uart pins arent getting loaded correctly. I'm trying P9.24 and P9.26 with pru0. there are two entiries for pru0 from your script, however Jul 18 14:15:06 ah, and there may be an hdmi conflict, even though I thought I disabled hdmi... Jul 18 14:19:42 the first column is just description, not pinmux Jul 18 14:20:37 and actually no, you didn't disable hdmi Jul 18 14:20:52 though hdmi doesn't conflict with the pru uart pins Jul 18 14:22:01 to disable hdmi you need to use the confusingly-named "am335x-boneblack-emmc-overlay.dtb" (line 10 of your /boot/uEnv.txt), whereas you're using the all-bells-and-whistles-enabled am335x-boneblack.dtb (line 20) Jul 18 14:22:52 I think they made this a bit less confusing in current images Jul 18 14:23:55 oh, I thought I was using a modern image. I started from the 8.7 debian image and then rebuilt to the 4.4 kernel since our legacy software needs uio_pruss Jul 18 14:24:27 in current images you can also easily choose between uio_pruss and remoteproc_pru in /boot/uEnv.txt Jul 18 14:24:48 (-ti kernels support both, -bone kernels only support uio_pruss) Jul 18 14:26:32 at some point I want to move to remoteproc. as I'm just starting with the prus, its nice to have working examples to reference and all my examples use uio_pruss Jul 18 14:27:37 I don't get remoteproc-pru... it just seems a more complicated way to get less functionality Jul 18 14:29:17 I've started working on better libs and examples for uio_pruss haven't been able to spend much time on it yet Jul 18 14:29:23 *but Jul 18 14:31:38 well, the good news is that hdmi is now gone. progress! Jul 18 14:35:23 in your show-pins script, what does the up/down column indicate? I cant parse the perl. Jul 18 14:36:00 hmm, did I put that in the readme yet... I know I still need to finish it Jul 18 14:36:04 ah, now i see Jul 18 14:36:10 its pullup/pulldown, no? Jul 18 14:36:15 yeah Jul 18 14:36:25 ok I definitely need to finish that part of the readme Jul 18 14:41:32 ok, i think I have the issue narrowed down. for whatever reason, my overlay is not being properly loaded. The pin mux settings are not being changed Jul 18 14:54:00 kernel log? Jul 18 14:59:07 and overlay source code Jul 18 15:02:43 Friends, I just loaded the latest Debian (2017-07-01) on my BBB C. When I run sudo node-red, node-red locks-up after loading palette node message. Any ideas? Jul 18 15:04:07 ah. it was my overlay. I had something crazy in there. Let me rewrite it and then send it to you if it still isnt working Jul 18 15:05:12 wintermuted are you referencing the node-red issue? Jul 18 15:06:39 no Jul 18 15:07:37 tnks Jul 18 15:36:26 has anyone seen their BeagleBone Black Wireless stop turning on after pushing and holding the power button to turn it off? Jul 18 15:37:22 wintermuted: I just added the descriptions that were still missing in my README Jul 18 15:38:02 arashed: it doesn't power on anymore at all? Jul 18 15:38:45 @zmatt thanks for the help. I think the overlay is working correctly now. no luck on the uart code working, but the next step is now to debug my assembly :) Jul 18 15:39:16 wintermuted: note that you can of course also play with the uart directly for linux userspace Jul 18 15:39:33 heh, but wheres the fun in that. we like realtime! Jul 18 15:39:53 it can be useful to confirm everything works the way you think it works :) Jul 18 15:40:00 also to inspect its state Jul 18 15:40:24 ill be sure to give it a look if I keep having issues. thanks again for the help! Jul 18 15:40:42 zmatt: sorry to just jump in and blurt out my question. but yes it's brand new out of the box and I did the push & hold to turn it off. Now when I plug it in or press the power button the power LED does one quick flash and nothing else. Jul 18 15:41:00 ouch Jul 18 15:41:47 that sounds like a production fault to me Jul 18 15:42:18 power led blip of doom is a common sight when the processor somehow got damaged Jul 18 15:43:12 (it means an overcurrent fault happened when the PMIC turned on the power supplies) Jul 18 15:44:16 sorry :/ Jul 18 15:44:50 and no need to say sorry for jumping in and blurting out your question, that is actually the right thing to do here Jul 18 15:45:05 Gotcha. I'm going to see what PMIC pins are routed out of this OSD3358. Maybe I can force it on. Jul 18 15:45:32 (along with waiting patiently since you're not always so lucky to find someone paying attention to IRC right away) Jul 18 15:45:52 ah sounds like you're already familiar with the hw Jul 18 15:46:23 Right - I haven't done any IRC in a while but rooms are usually always dead quiet Jul 18 15:46:41 it can take a few hours to get a reply yes Jul 18 15:47:17 people may be in a different timezone or just busy doing something else Jul 18 15:48:36 a well-phrased question that can be answered easily is also much more likely than a vague one which needs many follow-up questions to extract the relevant info from the person seeking help Jul 18 15:48:58 *much more likely to get a response Jul 18 15:49:01 anyway Jul 18 15:49:12 forcing-on sounds like a precarious thing to try Jul 18 15:51:12 there's a "powerhold" pin somewhere that I wanted to pull high Jul 18 15:51:50 if the pmic detects a fault there's nothing you can do to prevent it from powering off Jul 18 15:52:40 the real question is though, what the hell happened? Jul 18 15:54:26 I tried the shutdown command within linux which didn't seem to do anything and then I tried the halt command Jul 18 15:54:42 that also sounds strange Jul 18 15:54:46 that seems to stop the software running but the hardware was still on Jul 18 15:54:52 yeah the right command btw is "poweroff", not "halt" Jul 18 15:55:20 welp. so after that I pushed and held the power button to turn it off. Jul 18 15:55:44 nothing wrong with that right? Jul 18 15:58:53 so, fun fact: long-pressing the power button is actually supposed to cause the pmic to power-cycle, not power-off. the reason it often results in a power-off in practice is because the pmic inexplicably switches to battery power at the start of the poweroff sequence, even if no battery is connected at all. This causes some supplies to fail before they're disabled by the poweroff sequencer, causing the pmic Jul 18 15:58:59 to go via fault-state to off. Jul 18 16:00:25 http://elinux.org/File:Bbb-c-3v3u-shutdown-dc5v-hdmi.png (green is vsys, which is input to the 3.3v (pink) and 1.8v (blue) regulators) Jul 18 16:01:33 but while it's not very nice it shouldn't damage the hardware Jul 18 16:03:40 Sad. Wish there was a fault register in the pmic to read the fault reason. Jul 18 16:04:09 the pmic keeps no state in OFF-mode anyway Jul 18 16:04:56 it's not exactly the best pmic TI ever made :) Jul 18 16:09:29 the osd335x also sucks since they copied the power supply scheme from the BBB, complete with 3v3 regulator bug Jul 18 16:09:51 yeah I'm an apps engineer for TI - we spend months trying to enable a lower cost PMIC for the AM57xx and had to scrap the project because we had so many requirements that the PMIC couldn't meet. Jul 18 16:11:36 what pmic does the am57xx use normally? some palmas-derivative? Jul 18 16:12:27 yeah exactly that Jul 18 16:12:33 (I'm involved with a community-driven project that uses the omap5432, so I've gotten to know palmas fairly well) Jul 18 16:15:56 quick question.. does the WL18xx have a proper promiscious mode? been playing about with my BBGW and it says it's in promisc. but the traffic I'm seeing says probably not. I haven't set up a test network that I control using a spare router yet. Figured I'd ask here before jumping through those hoops. Jul 18 16:16:35 I find the tps65218 interesting though, especially the fact that apparently it is reprogrammable (although for some reason TI still doesn't make how to do so public info) Jul 18 16:17:00 * freemor is wondring if it might be like the chipset in the XO-1 and have a weird promisc. mode (XO-1's showed up as a separate rtap device) Jul 18 16:17:30 freemor: https://e2e.ti.com/support/wireless_connectivity/wilink_wifi_bluetooth/f/307/t/447185 Jul 18 16:18:21 I'm not familiar with the wl18xx at all honestly. Jul 18 16:20:35 Thanks I google'd about but could find nothing specifig to promisc. Hmmm thats monitor mode a bit different.. Stame story for Promisc. Jul 18 16:20:48 /stame/same Jul 18 16:22:37 Yeah wilink is a separate team from Sitara and we're not that helpful to each other :( Jul 18 16:23:45 not a biggie. I'm just poking at the edges seeing what the hardware can do. Did see that the WL18xx has a lot of config for things like MIMO, SISO, antenna usage, Etc. Learning all that'll keep me busy for a while :) Jul 18 16:24:13 arashed: maybe you can help me with something: we've been having trouble getting all the relevant docs for the palmas. when I first got involved with the project (Pyra) I noticed some of the docs they got were outdated. after some inquiry we got more docs from TI, but we're still missing the appnote that describes the actual part we're using (TWL6037B2A1), in particular its OTP settings Jul 18 16:24:57 we do have the appnote for the earlier PTWL6037BA1 (SWCA145) but I've noticed that there are differences Jul 18 16:25:24 The lack of monitor and promisc. is a sad but growing trend. Jul 18 16:26:43 zmatt: what is the title of the app note? I'll try a search on our sharepoint. Jul 18 16:27:28 thanks for the input zmatt, arashed Jul 18 16:27:54 arashed: I'd presume TWL6037B2A1 would be in the title. Jul 18 16:28:25 the appnote we have is just titled "TWL6037 Application Note Internal - PTWL6037BA1" Jul 18 16:28:43 which is the prototype version of the part we're using Jul 18 16:34:02 I found a June 2012 revision of SWCA145 Jul 18 16:34:37 that is the doc I have Jul 18 16:34:48 but that's for palmas es1.x, not es2.2 Jul 18 16:37:50 I found an es2.1 datasheet but it's NDA Jul 18 16:39:45 I have swcs104c and swcu133 Jul 18 16:40:21 yeah all these docs are nda for some inexplicable reason Jul 18 16:41:45 the problem with the data manual is that it just describes the various functionality options, but the actual behaviour depends on choices made in the OTP programming Jul 18 16:41:45 so it looks like any twl6037B is es2.x Jul 18 16:41:58 yes Jul 18 16:42:07 and I guess b2 is es2.2 Jul 18 16:42:10 ah right Jul 18 16:42:15 so it is 2.0 or something Jul 18 16:42:19 not 1.x Jul 18 16:42:20 ok Jul 18 16:42:32 yeah 1.x ends in A Jul 18 16:43:03 I've been finding docs for twl6037AAxx and whatnot Jul 18 16:43:51 still, changes were clearly made after 2.0. for example REGEN3 apparently wasn't used in 2.0 Jul 18 16:46:10 heh, I just checked the part on my omap5 uEVM... it's labeled "PALMASB2A1" "ES 2.2" .. weird they wrote palmas there rather than twl6037 Jul 18 16:46:44 I found a es2.1 app note (PTWL6037B1A2) Jul 18 16:47:32 then you already did a better job than whoever our contact at TI is (I haven't interacted with them myself) Jul 18 16:51:40 weird I found references to a pg2.3 that ended up being the TPS659037 Jul 18 16:52:47 I've seen that partnumber before Jul 18 16:52:50 somewhere Jul 18 16:53:02 it's the AM57xx pmic Jul 18 16:53:07 ah right Jul 18 16:53:23 but it was twl6035 pg2.3 not -37 Jul 18 16:53:50 same die, different package Jul 18 16:55:33 next time I run into my college in the pmic product line I'll ask him about the prospects of pulling up old app notes Jul 18 16:56:06 So what's Pyra? Jul 18 16:56:08 I still don't really understand why TI didn't just continue supporting omap5 as applications processor alongside the am57xx, for power-constrained applications... there's sooo much overlap Jul 18 16:56:31 successor to the OpenPandora Jul 18 16:56:44 pyra-handheld.com Jul 18 16:58:06 I'm not sure either. OMAP was cut down a lot and repurposed for automotive. All the catalog processors (am335x/437x/57xx) are auto processors repurposed for catalog Jul 18 16:58:38 actually no am335x was catalog's design Jul 18 16:58:46 am335x is dra60x isn't it? Jul 18 16:59:09 there's a whole "arctic" line and am335x is called sub-arctic Jul 18 16:59:33 I've seen arctic referenced but don't think I ever figured out which part it referred to Jul 18 16:59:57 there's definitely something odd about the am335x design Jul 18 17:00:54 it has quite a few "ghost" modules where there's a prcm register and an l3 interconnect target agent for it, but the actual module seems to be missing Jul 18 17:00:55 gotta go - nice chatting with you zmatt Jul 18 17:01:09 later! thanks for looking into the palmas docs! Jul 18 17:01:42 no problem, have a good day Jul 18 20:54:09 other than setting the mode to 0x07 in &am33xx_pinmux in the device tree, what do i need to do to enable gpio pins? Jul 18 20:58:36 what do you mean by "enable" exactly? **** ENDING LOGGING AT Wed Jul 19 03:00:03 2017