**** BEGIN LOGGING AT Mon Mar 13 03:00:01 2017 Mar 13 05:35:53 hey guys Mar 13 05:35:56 allah is doing Mar 13 05:36:02 sun is not doing allah is doing Mar 13 05:36:04 to accept Islam say that i bear witness that there is no deity worthy of worship except Allah and Muhammad peace be upon him is his slave and messenger Mar 13 09:08:23 gm Mar 13 09:09:54 zmatt: I guess I'll have to compile the starterware demo and inspect all the PRM and CM registers to find out... Mar 13 09:20:58 maybe I'll have to put the MPU DPLL in bypass. the starterware demo seems to do that will all DPLLs before entering DS0 Mar 13 10:19:16 hollow Mar 13 10:21:51 I have a question using BeagleBird. Mar 13 10:22:10 Which question do you have to ask? Mar 13 10:34:39 o.O Mar 13 10:36:29 thinkfat: note: you still haven't actually explained yet what the problem is you're experiencing, which makes it hard to give any sort of useful feedback :) Mar 13 10:36:53 thinkfat: on the other hand, yes I'm pretty sure all PLLs need to be in bypass before entering ds0 Mar 13 10:37:08 in fact iirc they get powered down via a special procedure Mar 13 10:42:51 thinkfat: like so: http://git.ti.com/processor-firmware/ti-amx3-cm3-pm-firmware/blobs/master/src/pm_services/dpll.c#line33 Mar 13 10:50:06 thinkfat: that however only applies to the dpll_ddr, dpll_disp, and dpll_per Mar 13 10:51:30 (I have the power up/down procedure also a bit more legibly documented here: https://github.com/dutchanddutch/jbang/blob/master/include/ti/subarctic/ctrl.h#L707-L727 ) Mar 13 10:54:26 zmatt: well, the problem is, the sleep transition to DS1 state doesn't complete, because the second half triggered by the PRCM interrupt to the M3 is not executed. Mar 13 10:55:54 zmatt: note I'm not trying DS0 yet, in DS1 the PER domain is still on and I think the PLLs (maybe except MPU) can stay locked Mar 13 10:56:29 for that it should suffice that the m3 has the irq enabled, mpu modulemode=off, and the a8 performs wfi with no pending irqs Mar 13 10:57:33 they can stay locked if you want, pll management only comes after the m3 is notified anyway (currently) Mar 13 11:02:51 zmatt: https://ghostbin.com/paste/zqdhn Mar 13 11:03:26 zmatt: to me that looks ok, I retrieve the registers through the M3 AHB-AP via jtag while the A8 is in WFI Mar 13 11:04:00 I'm not seeing a dump of MPU_PWRCTRL Mar 13 11:04:09 ok, wait a sec Mar 13 11:04:34 also, 0 for CLKSTCTRL is wrong iirc Mar 13 11:05:26 indeed -> https://github.com/dutchanddutch/jbang/blob/master/include/ti/subarctic/prcm.h#L19 Mar 13 11:06:27 zmatt: that should be the effect of the M3 not kicking in, MPU power domain transition is part of the M3 handling, no? Mar 13 11:07:06 currently it probably is yes Mar 13 11:07:40 but I wasn't sure why else you were showing me these regs Mar 13 11:08:01 what you want to know is: was the m3 irq enabled at the time the a8 performed the wfi ? Mar 13 11:09:13 mhm, right Mar 13 11:09:29 I really do remember quite strongly that I got an irq on the m3 side on every successful wfi of the a8, regardless of modulemode, i.e. even if no idle transition was involved Mar 13 11:09:50 but of course I did have the irq enabled on the m3 at all times Mar 13 11:10:32 this directly contradicts the TRM, but that's exactly why I remember it vividly :) Mar 13 11:11:14 actually I should say: I had the irq enabled for the m3 in prcm Mar 13 11:11:35 through PM_IRQENABL_M3 ? Mar 13 11:11:56 I didn't have it enabled in the m3 itself since I had no code there, I just used jtag to observe and clear the irq pending bits in NVIC Mar 13 11:11:59 yes Mar 13 11:12:02 or whatever it's called Mar 13 11:12:42 oh never mind Mar 13 11:12:46 irq1 is always enabled Mar 13 11:13:09 hm, but I think I need irq2 Mar 13 11:13:30 we're talking about the same thing, in my opinion there's irq0 and irq1 Mar 13 11:13:30 :P Mar 13 11:13:38 ah Mar 13 11:13:45 TRM-speak is INT2 :) Mar 13 11:14:08 yes well the TRM can stick the "let's randomly use 1-based numbering in a few places" where the sun don't shine Mar 13 11:14:46 hm, no documented register for an IRQ enable status on the M3? I only see SET and CLR registers Mar 13 11:15:06 ? Mar 13 11:15:17 of course the NVIC has irq enable registers Mar 13 11:16:34 0xE000E100 Mar 13 11:19:01 but note that even if not enabled, irqs still become pending and will fire as soon as you enable them, if I remember correctly Mar 13 11:19:07 (unless explicitly cleared of course) Mar 13 11:20:39 zmatt: hm, in the source these registers are marked as "SET_EN1" to "SET_EN3", and they only set a bit if you write a 1 to that bit Mar 13 11:20:52 zmatt: doesn't seem that I can read it back and get a status Mar 13 11:21:10 you can read them to see if they're set Mar 13 11:22:40 100: read enabled, write 1 to set enabled Mar 13 11:22:45 180: read enabled, write 1 to clear enabled Mar 13 11:22:54 100: read pending, write 1 to set pending Mar 13 11:22:56 eh Mar 13 11:22:57 200: read pending, write 1 to set pending Mar 13 11:23:05 280: read pending, write 1 to clear pending Mar 13 11:23:18 300: read active Mar 13 11:26:21 well there is a pending irq, but not extint34 ;) Mar 13 11:26:42 but extint34 is enabled Mar 13 11:27:27 prcm irq1 is irq 18 Mar 13 11:27:44 irq 34 is watchdog 1 wakeup Mar 13 11:27:58 uh? eh? Mar 13 11:28:18 zmatt: what's 48? Mar 13 11:28:21 see Wakeup-M3 tab of https://goo.gl/Jkcg0w Mar 13 11:28:27 it only has 35 irqs Mar 13 11:29:43 ENOSUCHTAB Mar 13 11:30:15 huh Mar 13 11:30:55 I have it right in front of me Mar 13 11:31:09 let me open it in an incognito window to check if there's some permissions issue Mar 13 11:31:20 oh Mar 13 11:31:25 wrong link, huh Mar 13 11:31:37 https://goo.gl/7YooOO Mar 13 11:31:38 that Mar 13 11:31:52 sorry, pebkac on my side Mar 13 11:34:07 hm, compared to the cm3 firmware sources, these numbers have a -16 offset Mar 13 11:34:57 these numbers are the index into every irq-indexed array Mar 13 11:36:44 16 + irq is the corresponding handler number Mar 13 11:37:05 which has quite limited usefulness Mar 13 11:37:36 the firmware also seems to use that number to compute the enable register and bit position Mar 13 11:38:55 well it can use that number to compute the enable register and bit position, but only if that computation looks like handler_nr >= 16 ? compute for irq_nr=(handler_nr-16) : special case handling for other handlers Mar 13 11:42:13 zmatt: no, doesn't at all look like that Mar 13 11:42:21 attempting to treat irqs uniformly with non-irq-handlers is misguided however Mar 13 11:42:41 since they simply don't behave uniformly Mar 13 11:43:20 handlers 4-6 (mmu fault, bus fault, usage fault) have enable bits in some register, but disabling them just means they get unconditionally escalated to hardfault Mar 13 11:44:05 systick (handler 15) is basically the only handler that behaves like an irq and has an enable bit somewhere Mar 13 11:45:20 remaining handlers have no enable bit Mar 13 11:47:33 zmatt: I think your interpretation of the assignment of interrupt number to the enable register bits is not correct. If you were correct, this M3 firmware wouldn't stand a chance of ever working Mar 13 11:47:53 lol, I was trying to figure out what icon google used to represent you... apparently you are Anonymous Capybara Mar 13 11:48:03 :-D Mar 13 11:48:20 is that a pokemon? Mar 13 11:49:21 no, a capybara is basically a really big guinea pig Mar 13 11:49:29 mhm, probably tasty Mar 13 11:49:44 which reminds me, I need to grab lunch Mar 13 11:49:47 afk for a bit Mar 13 11:50:26 "a favourite food of jaguar, puma, ocelot, eagle, and caiman", "also the preferred prey of the anaconda" Mar 13 11:52:34 and indeed I'm now also confused... hmm Mar 13 11:52:59 zmatt: just one little bit of info before I really leave: if I force the PRCM int by writing to the PEND2 register, the correct handler gets called, executes, and afterwards the A8 is truly off Mar 13 11:53:04 zmatt: just like it should be Mar 13 11:53:35 yeah, so maybe check if the m3 firmware clears it in some inappropriate place Mar 13 11:53:45 will do Mar 13 11:53:49 afk for reals now Mar 13 11:57:57 ok this is really weird, it seems that those are indeed irq numbers, and TI simply doesn't use irqs 0-15 at all Mar 13 11:58:00 wtf Mar 13 11:59:30 that's weird as hell Mar 13 12:00:23 I've updated my spreadsheet Mar 13 12:02:35 maybe the software guys communicated handler numbers to the hardware guys, who interpreted them as irq numbers, and by the time it was noticed it was too late :P Mar 13 12:03:38 oh well, maybe some use will show up for those 16 soft-irqs ;) Mar 13 13:01:52 zmatt: http://processors.wiki.ti.com/index.php/AM335x_StarterWare_Power_management Mar 13 13:02:17 zmatt: "Note: When A8 is connected to debugger and executes wfi, CM3 will not receive interupt." Mar 13 13:02:20 zmatt: eh? Mar 13 13:03:55 zmatt: what does "connected to the debugger" mean? Mar 13 13:04:53 zmatt: tap enabled in icepick? Mar 13 13:06:43 ahh, so it does check whether clock gets gated :) Mar 13 13:07:09 probably the force clock enabled bit in the icepick tap control register and/or core control register Mar 13 13:08:09 check if bit 4 is set in either of those Mar 13 13:08:19 4 [r-] clock is being kept active solely due to debugger Mar 13 13:08:38 zmatt: one second. Mar 13 13:08:53 zmatt: is that an icepick register or in the address space of the a8? Mar 13 13:08:58 icepick Mar 13 13:09:08 ok, now it'll get tricky Mar 13 13:09:16 successfully debugging power transitions requires a lot more intimate interaction between debugger and icepick Mar 13 13:09:28 are you using openocd or ccs ? Mar 13 13:09:32 openocd Mar 13 13:09:57 I'm pretty sure it has helpers to read icepick registers? Mar 13 13:10:07 or does it set them blindly? Mar 13 13:12:40 I found this in my openocd stuff, is it useful? -> https://gist.github.com/mvduin/92361f46efe0f27002f141f80e2024b2 Mar 13 13:14:17 lol I really have no idea anymore how this worked Mar 13 13:15:03 well the current icepick helpers are a bit different but they're usable Mar 13 13:15:19 so, relevant registers are 0x2c and 0x60 Mar 13 13:15:41 2c is tap control and 60 is core control? Mar 13 13:15:45 yes Mar 13 13:16:21 I don't know which of those is relevant here... it *should* be core control in my opinion Mar 13 13:16:36 but quite obviuosly they didn't consult my opinion :P Mar 13 13:19:38 in theory when the a8 tries to idle, the debugger can notice bit 4 being set and detach itself to avoid stalling the clock domain transition Mar 13 13:20:17 given that icepick<->prcm integration seems overall messed up on subarctic, I don't know whether this works there in practice Mar 13 13:21:26 zmatt: I think I'll try something else, I'll connect only to the M3 and check from there Mar 13 13:21:38 that's the lazy way out yes Mar 13 13:22:15 if I understood you correctly, I anyway cannot force a clock release from icepick side other than through disconnecting Mar 13 13:22:33 you *ought* to also be able to attach to DAP since it lives in pd_core, not pd_mpu Mar 13 13:22:50 depends on what you mean by "disconnecting" Mar 13 13:22:56 disabling the tap Mar 13 13:23:11 I don't know any other way to "disconnect" Mar 13 13:23:39 I mean, physically disconnecting the jtag makes no sense ;) Mar 13 13:24:16 well you need to release the clock-forcing through icepick. I don't see any reason to deselect the DAP TAP since it lives in pd_core Mar 13 13:26:48 there's also a 'force power on' bit in a coresight debug register that might be relevant Mar 13 13:27:25 in fact that one seems more likely, since they don't seem to have done much if anything with icepick-prcm integration Mar 13 13:28:56 bit 0 of reg 0x80001310 via APB-AP Mar 13 13:29:54 does that register have a name? Mar 13 13:30:12 I'm quite positive that it does Mar 13 13:30:59 lemme check the TRM to see how ARM named it Mar 13 13:31:47 given that those names tend to look like someone just bashed his fists on a keyboard, I give them sensible names in my own notes/headers :P Mar 13 13:32:50 PRCR Mar 13 13:33:42 the relevant bit being called DBGNOPWRDWN Mar 13 13:33:43 oh yeah Mar 13 13:35:06 I'm just guessing which control(s) are actually relevant here of course Mar 13 13:37:32 nothing on oocd touches this register, so likely it's at the default setting Mar 13 13:38:11 the default is 0, easy enough to verify that that's what its at Mar 13 13:38:48 I'm probably leaning more towards the icepick route Mar 13 13:39:05 yeah my next candidate would be icepick core control register Mar 13 13:39:53 core control is specific to icepick-d or also in icepick-c? I think I have a manual for icepick-c around Mar 13 13:40:07 new in icepick-d Mar 13 13:40:42 but afaik the bit allocation is the same as for debug tap control registers, just a subset thereof Mar 13 13:42:32 bit 3 would be the relevant bit Mar 13 13:42:46 hummmm Mar 13 13:42:47 ok Mar 13 13:43:01 3 [aw] force clock (and therefore power) on Mar 13 13:43:17 the icepick-d helper seems to write 0x2008 to that register Mar 13 13:43:39 bit 17 releases from wait-in-reset Mar 13 13:43:45 that would force the clock, right? Mar 13 13:43:49 yes Mar 13 13:44:01 hohumm.. Mar 13 13:45:05 note that if you clear it, and the clock indeed is gated, I don't know what happens if you attempt any access to the mpuss-embedded part of the debug interconnect Mar 13 13:45:24 my guess is either it would fault or it would hang Mar 13 13:47:58 zmatt: it fails :-) Mar 13 13:48:23 zmatt: but properly sending WAIT Mar 13 13:48:32 i.e. it hangs Mar 13 13:48:35 yup Mar 13 13:48:53 that's not proper, you now have an unusable DAP Mar 13 13:48:53 but the M3 now gets the interrupt, all fine :-) Mar 13 13:49:57 so, ideally there'd be some way to declare access to certain addresses temporarily prohibited Mar 13 13:50:00 well I'd expect that to happen when I try to access something in the core power domain Mar 13 13:50:09 mpu power domain Mar 13 13:50:13 yes Mar 13 13:50:18 "core" in adi speak Mar 13 13:50:20 I'd expect a fault Mar 13 13:50:46 since a hanging transaction is in general unrecoverable Mar 13 13:55:45 hmm, does that mean that if you set and clear bit 3 now that the m3 gets another irq? :) Mar 13 13:56:45 hm? Mar 13 13:57:06 since it would force-wake up the a8 clock and then allow it to be gated again Mar 13 13:57:14 ah, indeed Mar 13 13:57:20 maybe Mar 13 13:57:30 is the m3 prepared for that? :) Mar 13 13:57:51 something makes me doubt that Mar 13 13:57:55 hehe Mar 13 13:58:14 but it's difficult to tell from the lack of documentation :-) Mar 13 13:58:43 who needs documentation when there's source code? ;) Mar 13 13:59:33 of course, this whole logic is bogus... the knowledge that the a8 is "now" clock-gated is worthless since it might not even be true anymore by the time the m3 receives the irq Mar 13 14:04:43 Can anyone tell me, does beaglebone have audio output or not? Mar 13 14:05:33 it does not have an integrated analog audio output. it does support multiple I2S outputs, and one is wired into the hdmi framer to allow audio over hdmi Mar 13 14:06:21 Thank you for response, it's clear now. Mar 13 14:07:13 it can also produce S/PDIF if you connect a driver (for coaxial S/PDIF) or optical transmitter Mar 13 14:08:04 Mm.. No, I need a board with line out support without additional hardware. Mar 13 14:08:22 But thank you Mar 13 14:08:55 there are probably plenty of boards that have it, but the beaglebone is not one :) Mar 13 14:29:47 zmatt: now back to solving the hardfault exception that the M3 gets when it wakes up Mar 13 14:51:50 fun fun fun! Mar 13 14:59:02 could it be that some interconnect is powered down? Mar 13 15:01:48 zmatt: the failing register access is in the control module, but the module itself is enabled according to CM_WKUP_CONTROL_CLKCTRL Mar 13 15:03:39 cool! have you already figured out why it's causing hardfault in the first place? Mar 13 15:03:47 instead of busfault Mar 13 15:17:22 zmatt: no idea. M3 tries to read dpll_pwr_sw_ctrl register, next I see in the stack trace if hadfault exception Mar 13 15:19:17 check the hardfault status register Mar 13 15:23:11 zmatt: FORCED bit is set Mar 13 15:23:41 zmatt: so an escalated faule Mar 13 15:24:14 I'm guessing that although they defined a (trivial) busfault handler they didn't bother enabling it? Mar 13 15:24:35 or was the fault taken with faults masked? Mar 13 15:24:50 BusFault status is 0x82 Mar 13 15:25:24 and the bus fault address is 44e11318 Mar 13 15:25:32 that's the register that faulted Mar 13 15:25:42 so it's actually a unhandled or masked busfaul Mar 13 15:25:44 note: I only have marginal attention right now, typing an email Mar 13 15:49:10 hi all ,a newbie question? Is there any libery like bonescrippt that support C++ Mar 13 15:54:11 qt: bonescript's just like GPIO/etc js interface? Mar 13 15:54:19 if you're using c++ you might want to use the drivers directly Mar 13 15:56:09 you mean by configure the driver directly on your code? using path ? Mar 13 15:57:13 qt: you know how the typical lunix driver file interfaces work? Mar 13 15:58:43 not sure ..., I'm also new to linux Mar 13 16:02:04 where should I start ? Mar 13 16:03:22 let's just say drivers can export files on filesystem that you can open/read/write/ioctl/close from userspace to ask the driver to do things Mar 13 16:03:43 you might want to take a look how bbio is implemented Mar 13 16:03:44 learning without any destination kinda frustrating .. Mar 13 16:03:51 https://github.com/adafruit/adafruit-beaglebone-io-python Mar 13 16:04:34 while that is python library the functionality is written in c so you should be able to check how to do things with c++ Mar 13 16:07:11 also, you might want to take a look for example under /sys/devices/platform/ocp/ Mar 13 16:12:33 thank you :) Mar 13 16:21:56 i have a beagle board XM and noticed at time the USB and Ethernet Port stopped working Mar 13 16:22:28 anyone know how to fix that problem? powercycling the unit does not work Mar 13 16:29:52 qt: though beware that those adafruit libraries are often horrible code and not a good example at all :P Mar 13 16:30:30 I can see it =)) kindof meshy Mar 13 16:34:25 qt: https://gist.github.com/mvduin/8f7ff56e60109e3d9dcaa04bc915daf0 Mar 13 16:34:39 this isn't beautiful C++ either, but it's nicer at least Mar 13 16:35:09 though one thing that needs explaining is the /dev/gpio/%s you see, which is non-standard Mar 13 16:36:17 on our beaglebones we customize the device tree for the product they're integrated in, which includes declarations for all GPIOs relevant to userspace, which makes those automatically exported Mar 13 16:37:04 a udev rule then makes symlinks /dev/gpio/$NAME -> /sys/class/gpio/$NUMBER thus applications also don't need to worry about gpio numbering Mar 13 16:41:38 your info is precios Mar 13 16:41:47 thanks alot Mar 13 16:43:11 so the dev directory gave you access change the hardware and the class dir show you what you have set ? Mar 13 16:43:15 simply speaking ? Mar 13 16:43:45 no Mar 13 16:45:19 so, /sys/ is a pseudo-filesystem where the "files" and "folder" actually represent kernel objects Mar 13 16:45:38 ah i see Mar 13 16:46:10 the main hierarchy is /sys/devices but more convenient symlinks ("shortcuts" in Windows terminology) can be found in /sys/bus/ and /sys/class/ Mar 13 16:47:55 e.g. on one beaglebone here, /sys/class/gpio/gpio15 is a link to /sys/devices/platform/ocp/44c00000.l4/44e07000.gpio/gpiochip0/gpio/gpio15 Mar 13 16:49:00 ah now I get it :) Mar 13 16:49:05 while that's certainly an improvement, we've arranged things on our beaglebones such that symlinks based on function (in a particular application) are made Mar 13 16:49:20 e.g. /dev/gpio/reset-dsp -> /sys/class/gpio/gpio15 Mar 13 16:50:48 now our program doesn't need to know which gpio is being used to reset that external DSP, that's just part of the device tree (in which all declarations are located w.r.t. external hardware) Mar 13 16:51:40 except for some very special circumstances, you can't make stuff in /sys/ since everything there represents kernel objects Mar 13 16:52:47 hence we place them in /dev/gpio/ (a directory we made), which is perhaps very slight abuse of /dev but I'm perfectly fine with it Mar 13 16:54:57 thats a lot Mar 13 17:35:33 (to anyone interested in declaring gpios in DT for userspace, see gpio-demo.dtsi in https://github.com/mvduin/overlay-utils ) Mar 13 17:39:39 what is the specs of the beagle board green ◦2x Grove connectors Mar 13 17:39:56 i need to find a part number from digikey Mar 13 17:41:59 you have checked the schematics? there's usually a part number there Mar 13 18:28:42 hey guys! Any cool sites to buy parts for a new projects? #beagleboneblack or others Mar 13 19:33:13 tindie Mar 13 19:33:27 seeedstudio Mar 13 20:06:14 Hi Mar 13 20:06:43 Hi Mar 13 20:53:23 this got weird Mar 14 00:36:38 ayjay_t: hm? **** ENDING LOGGING AT Tue Mar 14 03:00:02 2017