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

Tim Ansell 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
> 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
>>
>>
>>
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.librecores.org/pipermail/opensocdebug/attachments/20170721/80571b7b/attachment-0001.html>


More information about the OpenSoCDebug mailing list