**** BEGIN LOGGING AT Sat Jun 15 02:59:57 2019 Jun 15 06:56:09 zmatt I have been investigating this some more; the DBGDIDR is reporting the debug hardware is reporting for Version, bits[19:16] is 0b0100, so I am now reading DBGDRAR and DBGDSAR which I can do however both are returning 0 (RAZ). Jun 15 06:57:31 zmatt if I could find the ROM and read it I could figure out the memory map for the registers. Jun 15 06:58:01 bits 16-19 of DBGDIDR indicate ARM debug architecture v7, that doesn't indicate whether it's cp14-based or memory-mapped Jun 15 06:58:42 and I've mentioned a few times that TI neglected to configure those other two registers correctly... the debug ROM contents is likewise wrong iirc Jun 15 06:58:54 hold on, lemme find the notes I have on where's what Jun 15 06:59:44 The TRM for A8 says it is "v7 Debug architecture, with only the baseline CP14 registers implemented" which means I can read the ID and DBGDRAR and DBGDSAR. I am reading with 'mrc' as there is not extended address space. Jun 15 07:00:09 zmatt thanks Jun 15 07:01:02 actually the debug ROM isn't even accessible by the cortex-a8, only by JTAG. doesn't matter anyhow, since its contents is blank Jun 15 07:01:28 see the Debug tab of https://goo.gl/UHF2Fy Jun 15 07:05:18 zmatt hmm I am at a loss how a generic debug monitor can figure out the address map. I would prefer not to encode specific board or device support if I can help it. Jun 15 07:06:31 via DBGDSAR and DBGDRAR + the usual coresight discovery process, none of which will work since TI neglected to program these Jun 15 07:06:37 hardcoding it is the only possibility Jun 15 07:08:31 the jtag debugger has the same problem (in addition to requiring support for some TI-specific components, mainly ICEPick) Jun 15 07:09:05 zmatt thank you for the information, it has saved me a lot of time; I will add specific board and device address support, weak symbols will be my friend doing this. Jun 15 07:09:38 presumably you have board-specific stuff anyway Jun 15 07:10:03 actually that's not "presumably", that's "obviously" Jun 15 07:10:24 it's not like you can discover the rest of the SoC's memory map Jun 15 07:11:46 In RTEMS you build a board support package, ie beagleboneblack which selects an architecture, ie ARM. I will add a generic call to get the address map and will make it weak so a BSP can override that symbol with a localised version and the addresses. Jun 15 07:12:16 sounds reasonable Jun 15 07:12:22 Yeah this is true ... I wonder if the FDT has this defined? Jun 15 07:12:36 no since linux doesn't support the memory-mapped debug model anyway Jun 15 07:13:09 Sure and with Linux and processes that makes sense. Jun 15 07:13:25 uhh no it's just because noone has cared enough to implement it Jun 15 14:57:08 you're working on the BBB BSP for RTEMS kiwichri_ ? Jun 15 14:57:51 I added SPI to it with some friends, but not pushed yet Jun 15 22:38:43 mawk I am doing some work on it. Did the patches get posted to RTEMS's devel list? Jun 15 22:47:28 on SPI specifically kiwichri_ ? Jun 15 22:47:33 no, I'm ashamed of the code Jun 15 22:47:35 it's dirty Jun 15 23:12:54 mawk Yes. I have not looked at the SPI code in the BBB. Was this FreeBSD code? The FreeBSD port we use on RTEMS has SPI support for SD cards. Jun 15 23:20:37 we wrote it from scratch kiwichri_ Jun 15 23:20:44 SPI is very simple you don't need much Jun 15 23:21:26 we just read the BBB reference manual about the SPI peripheral and voilà Jun 15 23:21:47 did the spi peripheral as a subset of the i2c peripheral as that's what they do in other BSPs for SPI as we saw Jun 15 23:24:32 Ah ok, that is the in the kernel I2C/SPI implementation. I am not sure which is used when FreeBSD is being used. Jun 15 23:34:32 what do you mean by freebsd kiwichri_ ? Jun 15 23:34:37 we're talking about RTEMS Jun 15 23:40:41 mawk long story, the networking stack in rtems.git is a pre 2001 collection of freebsd sources which is still being used but is only ipv4 and not SMP; we learnt from that port we need to maintain source as close to upstream freebsd as we can so the libbsd project was started, see rtems-libbsd.git. This is now 1800 freebsd source files + rtems support ones and most of the code ported is not touched, we call this transparency. This means we have ipv4, Jun 15 23:40:41 ipv6, packet filtering, vlan, usb, mass storage and current drivers on RTEMS with fine grain SMP support. We have USB and wifi can be made to run on the bbb which is neat. Jun 15 23:41:02 yes the networking stack is freebsd indeed Jun 15 23:41:08 we worked on it too Jun 15 23:41:18 we added 6LoWPAN/802.15.4 Jun 15 23:41:47 Oh nice, I have been looking into 6LoWPAN and what is needed to support it Jun 16 00:01:51 but it's not pushed either Jun 16 00:01:55 code is too ugly Jun 16 00:02:03 we used the MRF24J40MA module, you can use that one if you want kiwichri_ Jun 16 00:02:15 here the code is pretty nice I believe (since I wrote it, I didn't write the other codes) Jun 16 00:02:59 I didn't implement every 802.15.4 feature, just beaconless mode, but it's enough to start Jun 16 00:17:18 Nice and thanks Jun 16 00:17:57 "codes" ? are you a fortran programmer? ;P Jun 16 00:40:12 :( Jun 16 00:40:19 hehe Jun 16 01:07:30 zmatt probing the debug registers at 0x4b141000 I can read the ID which looks good but I cannot read DBGDSCRext @ 0x4b141088. Are any enables or locks I need to look at? Jun 16 01:08:25 did you assert DBGEN like I mentioned a few times? Jun 16 01:08:42 also there are some steps required iirc Jun 16 01:10:12 I guess DBGEN is probably not required just to read the register, but iirc there was a step that is Jun 16 01:12:57 yeah, I think you need to fiddle with DBGPRSR/DBGPRCR Jun 16 01:14:59 and probably unlock the interface via DBGLSR/DBRLAR Jun 16 01:15:08 zmatt when you DBGEN do you mean a physical signal? Jun 16 01:16:26 03:41 <@zmatt> kiwichris: the DBGEN signal is controlled by a bit in an ICEPick register, which is only accessible via JTAG (although I've made a hideous hack that is enable to set the bit via software control by manipulating pin config registers to make ICEPick think the jtag signals are toggling. this however does require nTRST to be high, whereas it has a pull-down on the BBB) Jun 16 01:16:34 04:18 <@zmatt> kiwichris: btw, the hack I mentioned to enable DBGEN by self-jtagging using the pin config registers: https://github.com/dutchanddutch/jbang Jun 16 01:17:56 if DBGEN is not asserted, non-secure invasive debug is not allowed Jun 16 01:19:09 zmatt oh really, I am looking for a software only solution to debugging Jun 16 01:21:11 if zero soldering on the BBB is a hard condition, then you cannot use the processor's integrated debug support on the BBB Jun 16 01:21:20 just trace Jun 16 01:21:28 and pure software solutions Jun 16 01:28:24 kiwichri_: I kind of assumed it would be a problem, that's why it was the very first thing I answered to your question :P Jun 16 01:28:56 zmatt I am starting to understand this some more Jun 16 01:30:11 I have no clue why DBGEN can only be asserted by jtag, it would have made much more sense to make it software-controlled than jtag-controlled imho Jun 16 01:30:24 (and enabled by default) Jun 16 01:38:31 Agreed. Jun 16 01:39:00 Is DBGSWENABLE related to DBGEN? Jun 16 01:39:36 no Jun 16 01:40:44 DBGEN is an out-of-band debug authentication signal from the SoC to the debug logic. CoreSight does not specify how it is to be controlled Jun 16 01:41:03 The software lock bit is set in DBGLSR and I can unlock it with a write to DBRLAR but it does not help Jun 16 01:43:07 iirc clearing the power-loss bit in the debug power control/status is what resolves being unable to access the registers at all Jun 16 01:44:15 various unlocking is required to be able to write to it. the degree of access available when DBGEN is not asserted should be documented, but it's probably basically nothing in case of the debug registers Jun 16 01:44:53 (DBGEN however isn't required for using processor trace via ETM + ETB, for that NIDEN suffices, which is asserted by default) Jun 16 01:45:07 OK Jun 16 01:52:42 if you do want DBGEN asserted, then the easiest solution may be to find someone who can remove the external pull-down resistor that's on the nTRST signal on the BBB, and change the pinconfig register for that pin from internal pull-down to internal pull-up Jun 16 01:53:14 and then enable DBGEN via self-jtag as demonstrated by jbang **** ENDING LOGGING AT Sun Jun 16 02:59:58 2019