Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Lawrie Griffiths
    @lawrie
    The two Linux-capable versions of RISC-V that run on the Ulx3s are litex-vexriscv and SaxonSoc. They both use the VexRiscv version of RISC-V. VexRiscv is fast and very flexible, and it written in SpinalHDL, but there is a repository with generated Verilog versions of it (which is what linux-on-litex-vexriscv uses.
    VexRiscv supports JTAG, but I never got it to work with the built-in USB JTAG, so have always used it with a separate USB to JTAG programmer connected to GPIO pins. For that you need headers soldered to your Ulx3s.
    If you learn SpinalHDL you can build bare-metal VexRiscv SoCs using SaxonSoc or the older Murax or Briey SoC generators.
    Lawrie Griffiths
    @lawrie
    SpinaLHDL (like Chisel that is used for the SiFive RISC-V processors freedom and rocket) is based on the Scala language.
    emard
    @emard
    @pnru_gitlab for USB protocol to keep "alive" also SIE is required to be done in core and presented as bus interface. SIE handles USB packets and you can consider this as some circuit-bent UDP protocol having few IN and OUT "ports" or "sockets" called endpoints that handle 8-byte or 64-byte packets. Once you get at packet level you are mostly time non-critical
    Lawrie Griffiths
    @lawrie
    LiteX is written in the python-based Migen language. You can use it to build SoCs based on several different RISC-V processor (e.g. VexRiscv, picorv32, minerva) if you learn migen.
    nmigen is a newer version of migen (still python-based). The minerva RISC-V processor is written in that. I am pretty sure that would run on the Ulx3s board.
    There are lots of other open source RISC-V processors that will probably run on the Ulx3s board - see https://riscv.org/exchange/cores-socs/.
    Lawrie Griffiths
    @lawrie
    There is also f32c written in VHDL, which runs on the Ulx3s board. @emard will know more about the current state of that.
    Personally, I use VexRiscv and picorv32, and I use VexRiscv via SaxonSoc. This is a minimal bare-metal SoC using SaxonSoc - https://github.com/SpinalHDL/SaxonSoc/blob/dev/hardware/scala/saxon/board/ulx3s/Ulx3sMinimal.scala
    But SaxonSoc is under active development and is changing.
    emard
    @emard
    Yes f32c has very efficient and stable MIPS core and some attempt to repurpose MIPS to also decode RISCV ISA. Proof of concept works but not much development happened recently so f32c-RISCV only supports BRAM, while f32c-MIPS supports SDRAM and BRAM
    Saxonsoc is light and efficient so I'd really recommend it for bigger RISCV after some learning with picosoc
    e2kgh
    @e2kgh
    RISC-V: for VHDL friends, there is https://opencores.org/projects/neorv32, which looks pretty complete as a SOC ...
    Lawrie Griffiths
    @lawrie
    @pnru_gitlab It can't be Unix. It hasn't got vi.
    I think I need Blit.
    emard
    @emard
    Maybe it didnt have "vi" (I edited with echo >> hi.c ctrl-d) but then it has cc, so I can native compile stuff it's even reasonably fast :). Can we have some native C compiler for saxonsoc?
    Lawrie Griffiths
    @lawrie
    I will get back to looking at SaxonSoc again soon.
    Yes, I created a c program with cat.
    Lawrie Griffiths
    @lawrie
    It has the "ed" line editor.
    Lawrie Griffiths
    @lawrie
    Not sure what server.c is doing.
    Paul Ruiz
    @pnru_gitlab
    @lawrie Yes it has ed, the original editor written by Ken Thompson himself. It is still mandated by the Unix standard, so OS X and Linux still have it. vi was initially written by Bill Joy and is too large to run on the Mini Cortex. It needs separate I/D spaces which the 9995 does not support. It is supported on the 99000 though, so it is high on my list of to-do's. I do have the s editor (I think I have it at /s) which is a vi-like editor: https://github.com/udo-munk/s
    The S editor assumes an ansi terminal, so make sure you use that. No support for arrow keys, use H, J, K and L for that (as you would in the original vi).
    Lawrie Griffiths
    @lawrie
    I have hacked your pnr password. Interesting choice.
    Paul Ruiz
    @pnru_gitlab
    @lawrie the disk image is a copy of my working disk. I was experimenting with adding the file system switch from V8 unix and add a /proc file system and Unix domain sockets. That worked, but was in a state of flux, printing kernel debug messages and maybe not stable. I reverted the kernel to my stable version from a few months ago, but some of the user land test files are still there. server.c was one of them.
    Lawrie Griffiths
    @lawrie
    # passwd ka
    Usage: passwd user password
    # passwd ka aline
    # grep ka /etc/passwd
    ka:ugiTjezp:11:1::/usr/ka:
    # passwd ka ladne
    # grep ka /etc/passwd
    ka:ugiTjezp:11:1::/usr/ka:
    emard
    @emard
    "/s" editor works! But how I regularly exit? esc :w saves but esc :wq, :q, :q! I tried to exit but none works
    Lawrie Griffiths
    @lawrie
    q exited for me.
    emard
    @emard
    Yes sometimes works sometimes not, strange but ok, generaly source changes and hello.c compiles in 13s here :)
    Lawrie Griffiths
    @lawrie
    Keyboard seems to stop working with /s.
    emard
    @emard
    I like how fast it boots and gets prompt, even exe's are short, responds fast to prompt and only 6 MHz 16-bit CPU. Wonder are elf, ld, systemd all only to counterbalance for GB of RAM and GHz of CPU... Instead of 9600 I'd like to have 115200 ... :)
    Paul Ruiz
    @pnru_gitlab

    @lawrie Yes, that delightful anecdote is how I got to use that on the Mini Cortex. The M209 cypher used on V5/V6 Unix was an assembler routine that I had to port I figured that if my implementation hashed both aline and ladne to ugiTjezp, I would have the algorithm correct.

    The cypher was already weak at the time: with a few bits of hardware it would be susceptible to a brute force attack. In V7 (1979) it was replaced by triple DES as the crypt algorithm.

    Lawrie Griffiths
    @lawrie
    BTW, I have it running on a Blue 85f.
    Paul Ruiz
    @pnru_gitlab

    The s port is something that I have not used much. It may have bugs. For sure I know it crashes if it has to load a file that is too big to fit in memory. Strange as it may sound, ed is not all bad once you get (back) into it.

    The s commands are here: https://github.com/udo-munk/s/blob/master/commands.c#L17,L40 and the address specifiers are here: https://github.com/udo-munk/s/blob/master/address.c#L17,L53 All based on ancient vi.

    To save and exit the command is Z Z.

    To understand some of the key combinations, remember that vi was written for the ADM-3A terminal keyboard:

    If you find repeatable bugs, please let me know - maybe I can fix them easily.

    Paul Ruiz
    @pnru_gitlab
    @emard hello.c compiles in 13s here :) Yes, same here (obviously). I think the main time eater is the way that my current disk code interacts with the IDE interface: it byte-bangs the sector. What I wanted on the new SBC that I was planning, was to add a TMS9911 DMA chip that can move a sector in 512 machine cycles. My guess is that implementing that will take the compile time down to 3-4 seconds. Another improvement would be to add a "ranlib" index to libraries - that was a V7 invention that I have not implemented as yet. That may slice another second of the total compile time.
    emard
    @emard
    Some speedup can also be done with increasing block size or caching more blocks to get 8KB SPI transaction, then using 4-bit mode makes some improvement
    Paul Ruiz
    @pnru_gitlab

    @emard I like how fast it boots and gets prompt, even exe's are short, responds fast to prompt and only 6 MHz 16-bit CPU. Wonder are elf, ld, systemd all only to counterbalance for GB of RAM and GHz of CPU...

    Well, the PDP-11 was a 6MHz 16-bit machine and the VAX 750 ran at 8MHz. That is the hardware both Unix and the Internet were invented with. Unix has had ld since the earliest days. I don't care much for systemd which is trying to do entirely too much - but at the same time init is too simple a solution for a world with pluggable hardware. elf (or at least dynamic libraries) are a good idea in a bigger memory space. Without it, V7 Unix has about 5KB of stdio code duplicated in dozens of binaries - surely that is not quite right either.

    emard
    @emard
    Yes how about FPGA tools, most desireable stuff is statically linked see this cutie:
    ls -alh /usr/bin/nextpnr-ecp5 
    -rwxr-xr-x 1 root root 111M kol   2 05:32 /usr/bin/nextpnr-ecp5
    Anyway I got some i2c master stuff from net and will try make rtc reader example
    Paul Ruiz
    @pnru_gitlab

    @emard Instead of 9600 I'd like to have 115200 ... :)

    That is 12 times the speed. If we hook up h/w handshaking it is possible as a minimal fix, but that of course will not get your throughput up much. The problem is that the 9902 interrupts once for each character sent and received: at 12 times the speed the CPU would have a hard time to keep up. However, other manufacturers (read DEC) had I/O boards with buffers. It will not be too difficult to make a special UART chip in Verilog with buffers so that the CPU could R/W multiple bytes on each interrupt. What do you need it for?

    emard
    @emard
    Just 115200 to have default speed with connecting to python prompt and unix, nothing else. It can be char-by-char slow
    Paul Ruiz
    @pnru_gitlab
    I'll see what I can do. Maybe with H/W flow control and the 9902 set to its fastest mode, it can do 115200.
    emard
    @emard
    If it matters something, also experminenting with PLL clock around 6MHz to get a closest multiple of 115200 may help serial dividers get correct ratio
    It's already great, 115200*54=6.22 MHz (actual 6.25 right thing)
    Paul Ruiz
    @pnru_gitlab
    The 9902 operates on an internal frequency of 1MHz. We can try to set the half-bit timer to 4: this gives a bit time of 8us, which is 8.5% off from correct. This may be within the FTDI tolerance. Look at /rom/evmfast.mem, lines 12 to 14. Change all the 0001 bytes to 0004. Recompile with the ROM filled with evmfast.
    Paul Ruiz
    @pnru_gitlab
    Come to think of it - the 9902 was designed for a DTE role and assumes that it will always be faster than the modem. Hence it has RTS/CTS, but not DTR. For your convenience, maybe a hardwired DTR signal that reduces flow to ~9600 baud equivalent is the solution.
    emard
    @emard
    You mean a serial baud converter core, that would accept 115200 and with DTR signaling reduce it to 9600?
    And also retransmit at speed 9600 when communicating to TMS9902 side (FTDI side will be 115200)?
    Paul Ruiz
    @pnru_gitlab
    Yes. Thinking a bit more adding DTR to the 9902 is not very hard either: is should de-assert as soon as a character starts being received and re-assert after the CPU has read the byte. I cannot replicate that in vintage hardware, but it would be just a few lines of Verilog in the 9902 code. Just to be sure: which FTDI flow control lines are hooked up to the FPGA?