[Open SoC Debug] GSoC project to improve soft-CPU debugging in LiteX + MiSoC
mithro at mithis.com
Fri Jul 21 15:10:11 CEST 2017
Are you on IRC? I think a 10-15 minute discussion will quickly figure out
what the best solution is.
Tim 'mithro' Ansell
On 21 July 2017 at 23:05, Philipp Wagner <philipp.wagner at tum.de> wrote:
> 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
> 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
> 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
> - 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.
>> Tim 'mithro' Ansell
>> On 12 Apr. 2017 7:44 pm, "Philipp Wagner" <philipp.wagner at tum.de <mailto:
>> philipp.wagner at tum.de>> wrote:
>> 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).
>> On 04/12/2017 09:48 AM, Tim Ansell wrote:
>> Sadly we didn't get any bites for the project as part of GSoC.
>> 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>>>
>> 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
>> 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
>> At the moment I just want some Verilog code that I can
>> wrap with
>> 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
>> also have run-control debug working out of the box).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenSoCDebug