**** BEGIN LOGGING AT Fri Mar 24 03:00:00 2017
Mar 24 04:37:41 <zmatt> thinkfat: it looks like you have enough evidence now though for a very specific E2E question.  After entering and exiting deepsleep, EDBGRQ is continuously asserted.  How do we resolve this?
Mar 24 04:37:56 <zmatt> thinkfat: one last thing you can verify is the cortex-a8 debug integration status register
Mar 24 04:51:16 <zmatt> thinkfat: i.e. write 1 to 80001f00, read 80001efc, write 0 to 80001f00 ... and possibly reset depending on how confused the a8 now is
Mar 24 04:51:49 <zmatt> thinkfat: that register actually differentiates between the EDBGRQ from CTI and the "real" one
Mar 24 04:52:24 <zmatt> (although the CTI one makes no sense to be asserted, and this could be double-checked also via CTI itself)
Mar 24 04:56:45 <zmatt> thinkfat: w.r.t. the icecrusher difference, maybe check what "halted before deepsleep" looks like, that's probably a better comparison point since right now we don't know whether that bit 17 means "I'm forcing the a8 to halt" or "I noticed the a8 is halted"
Mar 24 05:33:08 <ayjay_t> okay so i've been working on the nxp kinetis programmer cape thingy for like, 4 days, i've been sleeping in my office
Mar 24 05:33:29 <ayjay_t> because it's basically like, done, right? but, at the very end, i had one bug
Mar 24 05:33:33 <ayjay_t> and i couldn't figure it out
Mar 24 05:33:59 <ayjay_t> and every hour i'm just like "no this is stupid it's just one bug i'm sure i'll just figure it out in < 2hrs and be totally done
Mar 24 05:34:06 <ayjay_t> and i've managed to convince myself this way to stay in my office for 3 days
Mar 24 05:34:20 <ayjay_t> or however long its been
Mar 24 05:38:50 <zmatt> hehe
Mar 24 05:56:26 <zmatt> so, fixed it yet?
Mar 24 05:57:03 <ayjay_t> just now
Mar 24 05:57:07 <ayjay_t> there is a god!
Mar 24 05:57:15 <ayjay_t> so i had bought the lower memory version of the same chip
Mar 24 05:57:22 <ayjay_t> and didn't adjust the memory bounds in my linker script
Mar 24 05:57:44 <ayjay_t> so it was setting the stack pointer out of bounds and initializing variables to ram addresses that didn't exist
Mar 24 05:58:40 <ayjay_t> it was a good learning experience, i guess
Mar 24 05:58:41 <zmatt> hehe
Mar 24 05:59:07 <ayjay_t> i've gotten pretty good at soldering and desoldering flat leads at this point
Mar 24 05:59:13 <zmatt> one of those d'oh moments
Mar 24 05:59:39 <ayjay_t> since i thought i was burning chips i kept on replacing it and resoldering it at a lower temperature and in shorter time
Mar 24 05:59:58 <ayjay_t> yeah i mean, yeah
Mar 24 06:00:18 <ayjay_t> i'm a one man show in this office so i don't have that second set of eyes to just say "hey aj, you forgot to plug it in"
Mar 24 06:00:37 <ayjay_t> one time i spent four hours taking apart my work station to figure out why the printer wasn't working and it literally wasn't plugged in
Mar 24 06:01:22 <ayjay_t> but i need to read up on solder masks, flux, stencils etc and how to get a good solder. i need a book or something, i keep on getting tons of bridges which are a pain in the butt
Mar 24 09:10:28 <thinkfat_> gm
Mar 24 09:59:44 <zmatt> thinkfat: mornin'... see scrollback ;)
Mar 24 10:00:21 <thinkfat_> zmatt: uh ;)
Mar 24 10:00:29 <thinkfat_> zmatt: where's a logbot when you need one ...
Mar 24 10:00:45 <zmatt> ohey, two thinkfats
Mar 24 10:00:53 <thinkfat_> zmatt: sorry, my always-online comp is at home, I cannot access it right now
Mar 24 10:01:13 <zmatt> now see, that's what ssh was invented for ;)
Mar 24 10:01:20 <zmatt> I'll grab it from scrollback
Mar 24 10:01:22 <thinkfat_> zmatt: and VPNs I know
Mar 24 10:02:43 <zmatt> thinkfat_: http://pastebin.com/raw/metv3xPs
Mar 24 10:04:55 <zmatt> of course some attempts to meddle a bit with that ICECrusher register (after claiming any and all ownership in a sufficient radius) might also be worth a try... e.g. writing the same value in case it's write-1-to-clear, or attempting to clear it
Mar 24 10:05:41 <thinkfat_> zmatt: I already tried claiming any icecrusher facility that looked like it was claimable
Mar 24 10:06:02 <thinkfat_> zmatt: debug_csr unfortunately doesn't seem to be one, or it's related to another facility
Mar 24 10:06:28 <thinkfat_> zmatt: I could successfully claim and write to config, trigger and dcon
Mar 24 10:07:38 <zmatt> config? interrupt you mean?
Mar 24 10:07:49 <zmatt> config? is that an ownership thing?
Mar 24 10:08:00 <thinkfat_> zmatt: config is claimable and writable
Mar 24 10:08:24 <thinkfat_> zmatt: interrupt I was not able to claim and write to
Mar 24 10:08:34 <thinkfat_> zmatt: same for reset
Mar 24 10:11:09 <zmatt> I can claim interrupt :D  probably because I'm *not* doing it from debugger
Mar 24 10:11:29 <zmatt> maybe that's what 0b0011 (instead of 0b0010) means
Mar 24 10:12:29 <zmatt> makes sense that interrupts are for application rather than for debug
Mar 24 10:13:04 <ver|laptop> zmatt: quicky q .. is the gpio 'interface' a kernel driver?
Mar 24 10:13:32 <ver|laptop> and/or does it have references in the DT?
Mar 24 10:13:42 <zmatt> depends on the meaning of "the gpio interface" and "kernel driver"
Mar 24 10:13:52 <zmatt> of course all gpio controllers are declared in DT
Mar 24 10:13:55 <ver|laptop> zmatt: lol I know .. sorry, just woke up :p
Mar 24 10:14:18 <zmatt> and individual gpios themselves are also frequently used in DT
Mar 24 10:14:46 <zmatt> and in rcn's kernels at least you can also setup gpios in DT to be exported to userspace
Mar 24 10:15:12 <ver|laptop> ok, so what populates the sysfs interface?
Mar 24 10:15:16 <ver|laptop> (asking for another)
Mar 24 10:15:48 <zmatt> the gpiochips are the gpio controllers declared in DT
Mar 24 10:16:28 <zmatt> individual gpios can be exported if requested by a driver, requested by DT (via the gpio-of-helper driver), or requested by userspace (through 'export')
Mar 24 10:16:49 <zmatt> that part isn't really a driver, more part of the gpio subsystem in general
Mar 24 10:17:02 <ver|laptop> righto thanks
Mar 24 10:17:37 <zmatt> thinkfat_: config definitely isn't claimable by application, so probably debugger-only
Mar 24 10:18:21 <thinkfat_> zmatt: maybe I can "claim" those registers if I access them not through the APB but through the AHB AP, but I guess the access would still be tagged as coming from a debugger...
Mar 24 10:18:38 <thinkfat_> ah, but they might not be on L3?
Mar 24 10:18:41 <zmatt> try APB but with bit 23 cleared
Mar 24 10:18:44 <zmatt> they're on the L3
Mar 24 10:18:49 <zmatt> bit 31 cleared I mean
Mar 24 10:18:53 <thinkfat_> ah, yes
Mar 24 10:18:59 <thinkfat_> neat little trick...
Mar 24 10:19:44 <thinkfat_> zmatt: those debug registers you mentioned, they're from the Cortex-A8 TRM, I guess, because I don't see them in the ARM
Mar 24 10:20:13 <zmatt> integration test?  yes that's chip-specific of course
Mar 24 10:20:47 <zmatt> hm, interesting btw, my debug_csr on dm814x is reading 0x1000 currently
Mar 24 10:33:12 <thinkfat_> zmatt: I should have looked at the TRM earlier, I think
Mar 24 10:33:19 <zmatt> hmm?
Mar 24 10:34:07 <NP95> Ok can anyone help me here how to cross compile bonnie++ for AM335 processors?
Mar 24 10:34:24 <NP95> I have tried following the instructions on the internet
Mar 24 10:36:26 <NP95> I run the .configure
Mar 24 10:36:35 <NP95> and it shows that we are not cross compiling
Mar 24 10:37:10 <thinkfat_> zmatt: os save/restore procedure
Mar 24 10:37:31 <thinkfat_> zmatt: implementing that would maybe help.
Mar 24 10:37:41 <thinkfat_> zmatt: but first I'll check the integration mode
Mar 24 10:37:50 <zmatt> thinkfat_: didn't you have the same problem if you only attached the debugger *after* deepsleep had happened?
Mar 24 10:38:00 <thinkfat_> zmatt: I never tried that
Mar 24 10:38:19 <zmatt> OS save/restore btw is, as the name suggests, normally performed by the OS
Mar 24 10:38:34 <zmatt> it can't do that if it's stuck in halt on resume
Mar 24 10:39:11 <thinkfat_> zmatt: hm yes. egg, meet chicken.
Mar 24 10:40:07 <thinkfat_> zmatt: the reason why I never tried a debugger after a resume was, the only sample I had was a Linux and there it just worked, so no incentive to attach a debugger
Mar 24 10:40:19 <zmatt> no this feels more like a weird integration bug, or some mechanism originally meant for debugging resume
Mar 24 10:41:21 <thinkfat_> zmatt: In the back of my head there's a constant murmuring about a TI web page I think I saw, that offered an extension to CCS to debug over resume.
Mar 24 10:41:41 <thinkfat_> zmatt: but I cannot find it on TI or through google.
Mar 24 10:41:52 <zmatt> CCS has a checkbox for debugging through low power states
Mar 24 10:46:49 <zmatt> ah, if I claim and enable the interrupt-csr, I can indeed trigger the icecrusher interrupt on the a8
Mar 24 10:47:15 <thinkfat_> zmatt: from your forth?
Mar 24 10:47:19 <zmatt> yes
Mar 24 10:47:38 <thinkfat_> what is that, by the way, a bare-metal forth shell?
Mar 24 10:48:26 <zmatt> it's a forth :)  running baremetal yes, as most forths do
Mar 24 10:49:04 <thinkfat_> forth as in https://en.wikipedia.org/wiki/Forth_(programming_language) ?
Mar 24 10:49:05 <gcl-bot> [WIKIPEDIA] Forth (programming language) | "Forth is an imperative stack-based computer programming language and environment originally designed by Charles "Chuck" Moore. Language features include structured programming, reflection (the ability to modify the program structure during program execution), concatenative programming (functions are..."
Mar 24 10:49:10 <zmatt> yes
Mar 24 10:51:19 <thinkfat_> zmatt: my only experience with forth ever was on a C64. There was an interpreter for it I briefly played with
Mar 24 10:51:34 <thinkfat_> zmatt: though "interpreter" is the wrong word
Mar 24 10:52:09 <zmatt> indeed
Mar 24 10:52:12 <zmatt> well
Mar 24 10:52:21 <zmatt> it is one too
Mar 24 10:52:33 <zmatt> depending a little on precise definitions
Mar 24 10:58:25 <thinkfat_> zmatt: icecrusher debug_csr in debug-halted state: 0x00019000
Mar 24 10:58:50 <thinkfat_> zmatt: resumed: 0x00011100
Mar 24 10:59:04 <zmatt> it's getting more and more colorful
Mar 24 11:00:22 <zmatt> so it started with 18000  halt: 19000  resume: 11100
Mar 24 11:01:26 <zmatt> actually my notes say it starts with 0, but apparently becomes 18000 due to debugger attachment
Mar 24 11:01:29 <thinkfat_> zmatt: wedged: 0x00038000
Mar 24 11:02:59 <zmatt> and apparently I have seen 20000 under unknown circumstances... there's that mystery bit 17 again, if it's a bit rather than a mode/state combined with bit 16
Mar 24 11:06:46 <zmatt> did you try yet whether it hangs if you attach after deepsleep suspend/resume?
Mar 24 11:07:27 <zmatt> since that would make it an unambiguous hardware bug
Mar 24 11:08:45 <thinkfat_> zmatt: heh
Mar 24 11:09:00 <thinkfat_> zmatt: 0x80001efc = 0xc02 :-)
Mar 24 11:09:06 <thinkfat_> zmatt: so, it's not EDBGRQ
Mar 24 11:09:14 <thinkfat_> zmatt: but there's a halt request from CTI
Mar 24 11:09:23 <zmatt> aha, but that's fixable
Mar 24 11:09:34 <zmatt> iirc from a8 it requires explicit clearing
Mar 24 11:09:57 <thinkfat_> yeah, TROUT_STATUS requires an ack sequence to clear it
Mar 24 11:10:40 <thinkfat_> just the CTI config is real weird
Mar 24 11:10:53 <thinkfat_> INEN0-7: 0xf OUTEN0-7: 0xf
Mar 24 11:10:55 <ver|laptop> <3 "trout_status"
Mar 24 11:11:38 <thinkfat_> zmatt: TRIN_STATUS = 0x71
Mar 24 11:11:47 <zmatt> thinkfat_: neither CTI itself nor how TI wired it up is very fresh in my mind I have to admit
Mar 24 11:12:21 <thinkfat_> zmatt: I played with in on armv8, where it's mandatory, since the DRCR register doesn't have a halt request bit any more
Mar 24 11:12:37 <zmatt> lol
Mar 24 11:13:28 <thinkfat_> zmatt: interestingly, the CHIN/CHOUT status is all 0, so the debug request doesn't seem to come from the trigger matrix
Mar 24 11:13:49 <zmatt> does it clear properly though?
Mar 24 11:16:25 <zmatt> oh wow, I just looked up what those numbers you quoted mean
Mar 24 11:16:27 <zmatt> that's messed up
Mar 24 11:16:51 <zmatt> did they forget to connect a reset line there or something?
Mar 24 11:18:47 <thinkfat_> zmatt: for clearing the chout I should normally need to write a 1 to 0x80002010, but that doesn't clear trout
Mar 24 11:18:58 <thinkfat_> ah, clearing the trout, I mean
Mar 24 11:19:43 <zmatt> first write -1 to 0x80002018 ?
Mar 24 11:20:25 <thinkfat_> no effect
Mar 24 11:20:35 <zmatt> and then ack?
Mar 24 11:20:41 <thinkfat_> no effect
Mar 24 11:21:33 <zmatt> you have cleared those crazy inen/outen values ?
Mar 24 11:21:38 <zmatt> just in case
Mar 24 11:22:13 <zmatt> or how about we just turn CTI *off* ? :P  I see it has a global enable (reg 0 bit 0)
Mar 24 11:22:20 <zmatt> "0 = disable CTI (reset)"
Mar 24 11:22:22 <zmatt> reset sounds good
Mar 24 11:25:53 <zmatt> all INEN/OUTEN being enabled rather strongly suggests they hooked the relevant reset (ATRESETn it seems) up to the wrong reset signal.. one that doesn't get asserted when mpu is powered down during deepsleep... who knows what state that thing is in
Mar 24 11:26:11 <zmatt> I don't see any other explanation really
Mar 24 11:26:38 <thinkfat_> zmatt: one interesting thing
Mar 24 11:27:07 <thinkfat_> zmatt: I just wrote 0 to 0x80001ef4, that changed debug_csr to 0x30000
Mar 24 11:28:25 <zmatt> oh the a8 is in integration test mode?
Mar 24 11:28:30 <thinkfat_> yes
Mar 24 11:29:52 <zmatt> try writing 1
Mar 24 11:30:18 <zmatt> that should ack EDBGRQ and allow it to clear in CTI
Mar 24 11:30:28 <thinkfat_> let me start afresh
Mar 24 11:30:35 <zmatt> or that
Mar 24 11:31:12 <zmatt> curious actually that icecrusher reacts to anything in ef4
Mar 24 11:31:28 <thinkfat_> zmatt: might be a fluke
Mar 24 11:31:40 <zmatt> but to be honest I have no idea what's going on if you put the a8 into integration test
Mar 24 11:32:16 <thinkfat_> zmatt: eh, debug_csr actually changes if you enter integration mode
Mar 24 11:32:28 <zmatt> that I perfectly understand
Mar 24 11:32:30 <thinkfat_> zmatt: so it wasn't the write to efc but to f00 that affected it
Mar 24 11:33:55 <zmatt> assuming the output registers are initially 0, the moment you enable itest suddenly you're asserting 4 irqs, exiting debug mode, and probably indicate something about the debug comms
Mar 24 11:34:31 <zmatt> so I'm not really surprised icecrusher finds something in there to react to ;)
Mar 24 11:36:39 <thinkfat_> well if I knew what this bit 17 in debug_csr was, that would be a good hint
Mar 24 11:37:12 <zmatt> did you try clearing CTI without a8 being in itest ?
Mar 24 11:37:21 <thinkfat_> one moment, next thing to try
Mar 24 11:37:44 <thinkfat_> for now I dumped the cti registers in normal running state
Mar 24 11:38:25 <thinkfat_> and it's completely sane: cti is off/reset, trin is 0x2, gate is 0xf, all others are 0
Mar 24 11:38:54 <thinkfat_> only in that weird wedged state the CTI looks so broken
Mar 24 11:40:44 <zmatt> do the a8 debug registers look okay?  no crazy stuff like breakpoints?
Mar 24 11:41:25 <thinkfat_> good question, I never checked that
Mar 24 11:42:59 <thinkfat_> maybe it's just a bug...
Mar 24 11:43:26 <thinkfat_> and maybe I need to implement the debug save/restore
Mar 24 11:43:28 <zmatt> see above, my guess is that CTI doesn't get reset
Mar 24 11:43:43 <zmatt> see earlier reasoning that that idea doesn't make sense
Mar 24 11:43:48 <thinkfat_> at least no on a warm reset when MPU PD was off
Mar 24 11:44:06 <zmatt> yes that's what I meant sorry
Mar 24 11:46:03 <zmatt> technically that's not a warm reset, but a local cold reset, I think
Mar 24 11:53:42 <thinkfat_> oh, ok
Mar 24 11:54:14 <thinkfat_> writing 0 to PRCR clears the weird icecrusher state
Mar 24 11:54:53 <thinkfat_> looks like I forgot that the HCF bit in PRCR was still set ;)
Mar 24 11:55:10 <zmatt> right... i.e. prcr also initializes bogusly?
Mar 24 11:55:26 <thinkfat_> yes
Mar 24 11:55:37 <thinkfat_> now icecrusher looks healthy
Mar 24 11:55:42 <thinkfat_> but cpu still doesn't resume
Mar 24 11:55:57 <zmatt> how's CTI ?
Mar 24 11:56:08 <thinkfat_> still weird
Mar 24 11:56:14 <zmatt> well fix it :)
Mar 24 11:56:16 <thinkfat_> maybe now it will clear
Mar 24 11:57:08 <zmatt> although if the whole debug logic has not been reset.... brr
Mar 24 12:05:38 <thinkfat_> oooh, I got the system back :-)
Mar 24 12:07:30 <thinkfat_> humm, now I need to retrace my steps, I'm afraid
Mar 24 12:07:40 <zmatt> hehe
Mar 24 12:07:42 <thinkfat_> but it's back, and reacts normally to the debugger
Mar 24 12:07:58 <zmatt> I'd still suggest dumping some registers for signs of oddness
Mar 24 12:08:11 <zmatt> but yay \o/
Mar 24 12:08:27 <thinkfat_> it was a combination of disabling DBGEN, clearing PRCR and probably also the CTI
Mar 24 12:09:19 <zmatt> yeah, put everything you find in as normal state as possible, and then temporarily disable DBGEN... that sounds like a plausible strategy
Mar 24 12:09:46 <thinkfat_> alright, time for a quick lunch
Mar 24 13:27:19 <new> Yoo
Mar 24 13:27:57 <new> Does anyone know why I wouldnt be able to see my beaglebone black under my computer on windows
Mar 24 13:28:19 <new> after installing the drivers
Mar 24 13:31:45 <ver|laptop> new: this is gonna sound aweful .. but .. the answer is mostly "Windows" :/
Mar 24 13:34:13 <naor> hi
Mar 24 13:34:43 <naor> can someone help me load spi on bbx15
Mar 24 13:35:00 <new> I feared that may be the case
Mar 24 13:35:09 <new> Unfortunately I only have access to a windows machine at the moment
Mar 24 13:35:45 <naor> need help with spi
Mar 24 13:37:48 <naor> !@
Mar 24 13:37:55 <naor> help with bbx?
Mar 24 13:37:58 <naor> 15
Mar 24 13:40:37 <ver|laptop> http://www.catb.org/~esr/faqs/smart-questions.html
Mar 24 13:40:50 <ver|laptop> naor: what help? what do you know, what do you need to know
Mar 24 13:41:42 <naor> soory first time here
Mar 24 13:42:16 <naor> i just want to connect 2 bbx15 over spi
Mar 24 13:42:37 <naor> i use for both of them ubunto 16.04
Mar 24 13:42:39 <naor> ubuntu
Mar 24 13:42:58 <naor> please help me
Mar 24 13:46:33 <NP95> Hello can anyone help me cross compile the Bonnie++ benchmarks for Beaglebone
Mar 24 13:46:49 <NP95> I have tried the instructions on the TI wiki
Mar 24 13:46:49 <jtrip> naor: you have an x15??? those are still pretty rare afaik
Mar 24 13:47:00 <NP95> But I keep on failing
Mar 24 13:47:13 <naor> i have 2 bbx 15
Mar 24 13:48:26 <jtrip> wow, I'm jealous. How did you get them?
Mar 24 13:51:38 <naor> you can buy them online
Mar 24 13:51:51 <naor> digi-key
Mar 24 13:54:11 <jtrip> do you have a link? I don't see them and I was under the impression they are not in production yet
Mar 24 13:54:59 <ver|laptop> jtrip: some suppliers were takng pre-orders a while back
Mar 24 13:55:51 <ver|laptop> if jkdridner is lurking anywhere maybe he can update us to where/whether production has started ... or whether there were still some emc snags lingering...
Mar 24 13:57:13 <jtrip> yeah I was talking to him last night, and it sounded like production has not started yet
Mar 24 13:57:56 <ver|laptop> gotcha, cool
Mar 24 13:58:20 <ver|laptop> I know one/two batches got made, but not much beyon that. And that they were pre-prod basically
Mar 24 13:58:32 <jtrip> naor, I'm guessing we are thinking of different boards, or somehow you have one of the pre-production boards but that seems pretty unlikely
Mar 24 13:58:37 <ver|laptop> I was gonna do some testing of gstreamer on them :D
Mar 24 13:58:54 <ver|laptop> me - not yet
Mar 24 13:59:24 <jtrip> also that x15 is $$$$ so having two seems even more unlikely! :) at least in my world
Mar 24 13:59:39 <ver|laptop> having one is bad enough .. if you gotta pay for it
Mar 24 13:59:41 <ver|laptop> :D
Mar 24 13:59:53 <ver|laptop> and I have .. the BB-blue on my wishlist currently .. a *lot* cheaper
Mar 24 14:00:20 <jtrip> I just got a blue :D I'm super stoked, looking for parts for my first build now
Mar 24 14:01:15 <naor> ver what do you want ?
Mar 24 14:01:34 <naor> you want to help or not
Mar 24 14:02:22 <naor> https://beagleboard.org/x15
Mar 24 14:02:59 <naor> i have 2 of thuse so insted of trying to look smart
Mar 24 14:03:22 <naor> maybe stop beeing adush and start really to help
Mar 24 14:03:24 <jtrip> naor, it would help us understand the trouble you are having if you could describe what you have done and what did not work exactly
Mar 24 14:12:00 <thinkfat_> zmatt: slowly getting there, but the procedure is a bit finicky...
Mar 24 14:30:55 <thinkfat_> zmatt: https://ghostbin.com/paste/7bces
Mar 24 14:31:00 <thinkfat_> zmatt: this works most of the time
Mar 24 14:31:20 <zmatt> most of the time... sounds good :)
Mar 24 14:31:33 <thinkfat_> just sometimes not, and I wonder why
Mar 24 14:31:50 <thinkfat_> for example, "a8.cti dump" basically reads all the CTI registers and prints them out
Mar 24 14:32:01 <zmatt> have you checked other registers of the debug logic yet?
Mar 24 14:32:09 <thinkfat_> no, not yet.
Mar 24 14:32:33 <thinkfat_> but it might of course explain why it sometimes doesn't work
Mar 24 14:32:34 <zmatt> unfortunately I don't think there's a way to explicitly reset the whole emu domain (without resetting the whole chip)
Mar 24 14:59:37 <thinkfat_> zmatt: the key really seems to be to remove DBGEN signal after clearing the status of the CTI and PRCR
Mar 24 15:00:35 <thinkfat_> zmatt: then you can re-assert DBGEN, but not too quickly
Mar 24 16:11:31 <thinkfat_> zmatt: small nit to pick, the method doesn't allow setting breakpoints into the resume path, because the cpu will of couse run a significant amount of time with DBGEN clered
Mar 24 16:11:56 <thinkfat_> zmatt: but that can be fixed with a small "1: b 1b" :-)
Mar 24 16:12:06 * thinkfat_ heads home
Mar 24 19:59:45 <carlostib> hi there
Mar 24 21:15:25 <thinkfat_> gm
Mar 24 21:46:29 <thinkfat_> zmatt: thanks for all the good advice and information
Mar 24 21:46:52 <thinkfat_> zmatt: if we ever meet, drinks are on me.
Mar 24 21:55:02 <zmatt> you're welcome
Mar 24 21:56:59 <zmatt> btw, about the debugging in the face of this mess: you can still try to have icepick extend the a8 core reset while you clean up the debug state
Mar 24 22:16:50 <thinkfat_> zmatt: I still haven't figured out what exactly makes it work again. It is for sure both cleaning the CTI registers and the PRCR
Mar 24 22:18:19 <thinkfat_> zmatt: but that alone definitely isn't enough. You also need to, at least for some yet to determine time, release DBGEN
Mar 24 22:19:00 <thinkfat_> zmatt: and it migh also be required to read some of the CTI registers, for whatever reason
Mar 24 22:46:22 <zmatt> thinkfat: I'd still suggest an E2E post, both to report this erratum (I think we can safely call it that), and whether there's any way to ensure the mpuss-embedded debug/trace logic gets properly reset when leaving standby
Mar 24 23:05:34 <newblue> hey
Mar 24 23:06:09 <newblue> just fyi to update everyone, it turns out there was some unknown hardware issue with the bb blue I was asking about earlier this week
Mar 24 23:06:37 <newblue> i ordered a new one from mouser and it works just fine.
Mar 24 23:06:57 <newblue> and arrow was easy to work with for the return
Mar 25 01:10:14 <Jorslu> Hello?
Mar 25 01:11:10 <ver|laptop> Goodbye!
**** ENDING LOGGING AT Sat Mar 25 03:00:02 2017