[Libre-soc-dev] daily kan-ban update 22sep2020

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Wed, Sep 23, 2020 at 3:28 AM Jacob Lifshay <programmerjake at gmail.com> wrote:
>
> Today:
> Resolved bug #497, turned out that Luke was using a repo that he
> thought was the official upstream for power-instruction-analyzer and
> it is different than the repo I was using and had pushed the latest
> changes to.
>
> Started working on #499: writing a gdb remote debugging protocol
> implementation in nmigen.
> Tried to get some examples of gdb's protocol in action, but was
> thwarted by qemu. I tried creating a powerpc64le debian chroot and
> managed to build a program and run gdbserver -- which promptly ignored
> all incoming TCP data, causing my attempts to connect to it to fail.
> After trying a few combinations of software versions and stuff, I
> decided to create a virtual machine instead. I was again thwarted by
> the virtual machine not getting to loading Linux from the debian
> install iso, it would just repeatedly hang.

it's fairly normal in the embedded world that the serial console is
the default console.  however (acknowledging what lauri said) i am
surprised to learn that it's the default for ppc ISOs, even debian
ones.

> After trying for several hours, I decided that maybe I should figure
> out how to tunnel the gdb connection over ssh to the power server that
> Raptor is kindly letting us use. I'll try that tomorrow, but it looks
> like I'll be out of time before I even wrote one line of code for
> #497. :(

i am being quite pathological and strict even with myself about this.
we need to leave *at least* a month preferably six weeks for Staf and
Jean-Paul to get things sorted.  i've not even added in I2C or 16550
UART because these are not supported by litex (err except i've just
found an I2C bit-banging core in litex sigh i'll drop that in because
it will take 5 minutes).

the absolute last thing we need is for them to run through the layout
process and then we say "oh but we just want to add in feature X".

can i suggest instead the following, jacob?  if you can write a
python-based version of this, both client and server, it can be used
to connect to jtagremote.   client and server because then stand-alone
unit tests can be written

https://github.com/enjoy-digital/litex/blob/master/litex/build/sim/core/modules/jtagremote/jtagremote.c#L228

here is some example python socket code:

    https://gist.github.com/hduffddybz/daa4c931f6ea0bd7ed93

the client version needs to be as a function that does a single
"snapshot" with a data structure that contains (TCK, TMS, TDI) or is
None to indicate "don't send", although now that i think about it
blocking-send is desirable behaviour.  so you want select(inputs, [],
[], 0)

however for receive this *must not* block, instead it should return
None if the select (outfds) is zero length, otherwise it should decode
and return the data.

the whole loop must *not* block (which is why the select last argument
is 0 seconds not 5) because it will be called from nmigen simulations.

likewise actually now that i think about it the same logic applies for
the server.

i can then combine that with Staf's SVF file-reading code and this
should be enough to implement a test that works on litex sim, nmigen
sim, *and* on the FPGA if i get a USB2JTAG converter.

i will get on with the ls180 IO pads today.

l.