[Libre-soc-dev] daily kan-ban update 22sep2020
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Wed Sep 23 10:26:35 BST 2020
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:
> 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
> 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
here is some example python socket code:
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, ,
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
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.
More information about the Libre-soc-dev