[Open SoC Debug] GSoC project to improve soft-CPU debugging in LiteX + MiSoC

Philipp Wagner philipp.wagner at tum.de
Fri Jul 21 15:05:54 CEST 2017


Hi Tim,

On 07/21/2017 01:07 PM, Tim Ansell wrote:
> We are currently trying to get Linux running on LiteX on real hardware 
> but running into problems with strange lockups. Everything works on our 
> QEMU simulation, which makes it harder to figure out what is going on.
> 
> Having a debugging interface working would make things vastly easier!
> 
> Hence I'm trying to figure out what my best plan of attack is. The two 
> options are;
>   (a) Resurrecting my previously working (but horribly Jacky) 
> adv_debug_sys stuff
>   (b) Do something with OSD.
> 
> It's my understanding that Wallento is extremely busy at the moment 
> (finishing a PhD?). Where has the OSD stuff gotten too?

I'm actively working on OSD, however (as it is so often), I was required 
to take a bit of a detour. Let me give a brief overview of what's going on.

- First of all, tracing in OSD works reasonably well today with the code 
we have in the master branches. What also works is the UART emulation 
module: let the Linux kernel print over UART and the messages are then 
sent over the debug network to the host. We use these two things 
currently Linux bringup on OpTiMSoC.

- In my current project, I'm heavily refactoring the way the software on 
the host side works. This is now the third iteration on the host 
software and will incorporate much we've learned over the last years. 
The main idea is to remove the strict separation between "host" and 
"target" and make the consumers and producers of trace or debug data 
into (more or less) equal players which are able to communicate 
directly. This gives (among others) the following benefits:

  -- Make it easier to support multiple consumers of debug and trace 
data. For example, two gdbserver instances for different cores, or a 
gdbserver for one core and a trace logger for another core.

  -- Allow debugging across devices.

  -- Enable the implementation of trace consumers on-chip or off-chip 
transparently.

Background for that: I'm working on implementing the ideas outlined in 
https://arxiv.org/abs/1607.04549 into OSD and extending the idea in the 
process.


The basic architecture is now up and running, however the code needs 
more cleanup (and a bit of thought) before I can push it for review (the 
current code is available in https://github.com/imphil/osd-software, but 
its not really in a usable state for anybody but myself).

So, what's the summary?
- OSD is usable in its current state, given you don't need run-control 
debug.

- Development is happening, more on that as soon as I've brought it into 
a reasonable state to be shared.

- I personally am holding off the implementation of run-control debug 
until after the refactoring is done; however, that doesn't mean nobody 
else can take on that today. Porting work is always easier than 
rewriting things.

- For your needs: would it work to integrate OSD with its tracing and 
UART-emulation capabilities for now and use the run-control debug stuff 
once that's available later? Otherwise, I'm available to help out a bit 
with the run-control implementation (the plan is pretty clear), but I'm 
not able to spend much time implementing it myself for now.


Philipp


> 
> Tim 'mithro' Ansell
> 
> On 12 Apr. 2017 7:44 pm, "Philipp Wagner" <philipp.wagner at tum.de 
> <mailto:philipp.wagner at tum.de>> wrote:
> 
>     Hi,
> 
>     It seems this approach works well with our all timelines, so let's
>     go for that and revisit later in the summer. Until then, OSD should
>     be more stabilized and ready to be adopted more widely (as I have a
>     personal need for that).
> 
>     Philipp
> 
> 
> 
>     On 04/12/2017 09:48 AM, Tim Ansell wrote:
> 
>         Sadly we didn't get any bites for the project as part of GSoC. After
>         chatting with Wallento, it sounds like we are going to wait
>         until you
>         guys have finished getting initial things going. After that he and I
>         will work on getting this into LiteX / MiSoC this together.
> 
>         As I have been reasonable successful at getting QEmu emulation
>         of our
>         SoC going, that has satiated our immediate need for now. Even if
>         it was
>         a GSoC project it would have been ~3 months before we /might/ have
>         gotten something useful.
> 
>         Tim 'mithro' Ansell
> 
>         On 21 March 2017 at 02:50, Philipp Wagner <philipp.wagner at tum.de
>         <mailto:philipp.wagner at tum.de>
>         <mailto:philipp.wagner at tum.de <mailto:philipp.wagner at tum.de>>>
>         wrote:
> 
>              On 03/19/2017 09:57 PM, Tim Ansell wrote:
> 
>                  Hi Philipp,
> 
>                  At the moment I'm looking at the lowest effort way to add
>                  debugging to
>                  LiteX as kind of a "proof of concept" to demonstrate how it
>                  might work.
>                  I had previously gotten adv_debug_sys working with the
>         or1k and was
>                  planning on getting that stuff working again before I
>         came across
>                  OpenSoCDebug.
> 
>                  At the moment I just want some Verilog code that I can
>         wrap with
>                  LiteX
>                  and hook up to the or1k core's debug interface. It
>         seems like
>                  OSD might
>                  not be ready for me to use that way yet?
> 
> 
>              In this case, I'd not go with OpenSoCDebug for now, but use
>         the or1k
>              debug infrastructure with adv_debug_sys & Co. directly. It
>         should be
>              easy to revisit this decisions once you have a need for more
>              sophisticated debug/trace infrastructure (and by then OSD
>         should
>              also have run-control debug working out of the box).
> 
>              Philipp
> 
> 
> 
> 
> 




More information about the OpenSoCDebug mailing list