| openpowerbot | [slack] <Paul Mackerras> I fixed it again recently in 7c240a66, having broken it in 0fb207be (December 2020) | 00:00 |
|---|---|---|
| openpowerbot | [mattermost] <lkcl> paul: ahh :) | 01:11 |
| openpowerbot | [slack] <Boris Shingarov> @Paul Mackerras Yes, and the issue is that it got broken again **after** 7c240a66. | 01:48 |
| openpowerbot | [slack] <Paul Mackerras> wow, ok | 02:14 |
| openpowerbot | [slack] <Paul Mackerras> hmmm... seems to work in sim, I'll try on the fpga | 02:18 |
| openpowerbot | [slack] <Paul Mackerras> works for me on the fpga as of 76a7b988, what failure are seeing exactly @Boris Shingarov? | 06:07 |
| openpowerbot | [slack] <Paul Mackerras> works for me on the fpga as of 76a7b988, what failure are you seeing exactly @Boris Shingarov? | 06:09 |
| openpowerbot | [slack] <joel> Perhaps the bug is with mw_debug itself? I have an old version that works: | 07:08 |
| openpowerbot | [slack] <joel> ```$ mw -d status | 07:08 |
| openpowerbot | [slack] <joel> Opening jtag backend cable 'DigilentHS1' | 07:08 |
| openpowerbot | [slack] <joel> Connected to libftdi driver. | 07:08 |
| openpowerbot | [slack] <joel> Found device ID: 0x27c72027 | 07:08 |
| openpowerbot | [slack] <joel> Core status = 0x0 | 07:08 |
| openpowerbot | [slack] <joel> Core: running | 07:08 |
| openpowerbot | [slack] <joel> NIA: c0000000000bf308 | 07:08 |
| openpowerbot | [slack] <joel> MSR: 2000000000012026``` | 07:08 |
| openpowerbot | [slack] <joel> But building a new one from the current sources doesn't: | 07:08 |
| openpowerbot | [slack] <joel> ```$ ./mw_debug -d -b jtag status | 07:08 |
| openpowerbot | [slack] <joel> Opening jtag backend cable 'probe' | 07:08 |
| openpowerbot | [slack] <joel> Found USB cable: Flyswatter | 07:08 |
| openpowerbot | [slack] <joel> Connected to libftdi driver. | 07:08 |
| openpowerbot | [slack] <joel> If I use -t it works: | 07:21 |
| openpowerbot | [slack] <joel> ```$ ./mw_debug -d -b jtag -t DigilentHS1 | 07:21 |
| openpowerbot | [slack] <joel> Opening jtag backend cable 'DigilentHS1' | 07:21 |
| openpowerbot | [slack] <joel> Connected to libftdi driver. | 07:21 |
| openpowerbot | [slack] <joel> Found device ID: 0x27c72027 | 07:21 |
| openpowerbot | [slack] <joel> Core status = 0x0 | 07:21 |
| openpowerbot | [slack] <joel> Core: running | 07:21 |
| openpowerbot | [slack] <joel> NIA: c0000000000bd930 | 07:21 |
| openpowerbot | [slack] <joel> MSR: 2000000000012026``` | 07:21 |
| openpowerbot | [slack] <joel> I guess this might be from this commit: | 07:21 |
| openpowerbot | [slack] <joel> ```commit 4bdfef9a207ea9f0f14f7af626af0a6b10d242dd | 07:21 |
| openpowerbot | [slack] <joel> Author: Benjamin Herrenschmidt <benh@kernel.crashing.org> | 07:21 |
| openpowerbot | [slack] <joel> Date: Fri Sep 24 13:53:06 2021 | 07:21 |
| openpowerbot | [slack] <joel> | 07:21 |
| openpowerbot | [slack] <joel> @Boris Shingarov It looks like mw_debug works fine here for me. I'm testing 76a7b98840c8 on the a100 | 08:38 |
| openpowerbot | [slack] <Boris Shingarov> > works for me on the fpga as of 76a7b988 | 09:02 |
| openpowerbot | [slack] <Boris Shingarov> Oh, my apologies @Paul Mackerras! I am an imbecile! The problem was my own, I have a buggy homegrown git script which was telling me I am building from f5e06c2 when in fact the local directory had a different checkout. I deeply apologize for wasting everyone's time. | 09:02 |
| openpowerbot | [slack] <Boris Shingarov> > Found USB cable: Flyswatter | 09:04 |
| openpowerbot | [slack] <Boris Shingarov> That one is fine, because it's fixed in Anton's branch of UrJTAG. | 09:04 |
| openpowerbot | [slack] <Boris Shingarov> So all in all, I am now well on my way towards GDB integration. | 09:04 |
| openpowerbot | [slack] <Matt Johnston> it was useful for me - I think I was seeing the same "stopping" problem a while back, will try Paul's fix | 09:54 |
| openpowerbot | [slack] <joel> I was going to message you Matt to say that liburjtag is packed in Debian now. But I looked at the changelog to discover that I'd packaged it locally, so still no dice there | 10:25 |
| openpowerbot | [slack] <Paul Mackerras> @Boris Shingarov no problem, I have done similar things myself in the past | 10:30 |
| openpowerbot | [mattermost] <lkcl> boris i remember i promised to write to you about openocd | 14:24 |
| openpowerbot | [mattermost] <lkcl> The Plan(tm) was - is - to add a ppc64 target to it, and use the DMI-over-JTAG format | 14:25 |
| openpowerbot | [mattermost] <lkcl> unlike all other cores mostly ARM there is literally not one single ppc64 target in openocd. | 14:25 |
| openpowerbot | [mattermost] <lkcl> raw jtag, sufficient to do an ID, yes | 14:26 |
| openpowerbot | [mattermost] <lkcl> raw jtag, so you can do SVF files, yes | 14:26 |
| openpowerbot | [mattermost] <lkcl> actual targets "--target=microwatt" or "--target=libresoc".... NONE. not one single one. | 14:26 |
| openpowerbot | [mattermost] <lkcl> why? | 14:26 |
| openpowerbot | [mattermost] <lkcl> because IBM POWER uses LPC. | 14:26 |
| openpowerbot | [mattermost] <lkcl> by adding a target into openocd you *automatically* get direct access to the *existing* gdb-remote features already present in openocd | 14:28 |
| openpowerbot | [mattermost] <lkcl> that basically means teaching openocd the DMI-JTAG format. | 14:29 |
| openpowerbot | [mattermost] <lkcl> the last time i looked, there was an extremely clean patch for adding openrisc1200 as a target, showing precisely and exactly what is involved there. | 14:30 |
| openpowerbot | [mattermost] <lkcl> it was pretty straightforward and obvious | 14:30 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!