These are chat archives for ulx3s/Lobby

9th
Oct 2020
@blitz try uploading bit file to the flash. targetting flash with svf format is not supported. relevant code part:
        switch (input_type) {
            case TYPE_JED:
                res = exec_jedec_file(fname, target, debug);
                break;
            case TYPE_IMG:
            case TYPE_BIT:
                res = exec_bit_file(fname, target, debug);
                break;
            case TYPE_SVF:
                res = exec_svf_file(fname, debug);
                break;
(includes latest fujprog release)
BTW with latest release I'm hitting free Travis CI limit on building the tools as it can be seen here: https://travis-ci.org/github/alpin3/ulx3s
The job exceeded the maximum time limit for jobs, and has been terminated.
have to split the job and create new repo. i.e. ulx3s-core (fujprog, openfpgaloader, etc), ulx3s (+nextpnr, yosys, etc) and ulx3s-extra (vhd2vl, silice, etc). If somebody have better idea how to do it - I'm open to it.
I see that https://github.com/open-tool-forge/fpga-toolchain is using azure pipelines . maybe there is no such time limit in jobs?
v3.0.8 is latest produced. v3.1.3 exists only as design and is changing. Most important update is compatibility with ESP32-WROVER-E, also changing many pinout there. SERDES is currently only powered but not routed anywhere else. Plan is to connect RX of serdes to 8-pin LCD connector with capacitors inbetween for AC coupling.
Kid CUDA
@KidCUDA_gitlab
Oct 09 2020 06:54 UTC
did anyone ever get windows 1.0 / 3.0 running on Next186?
it seems that it is possible?
but i can't find any demos of it
emard
@emard
Oct 09 2020 07:18 UTC
@blitz easiest way of flashing is to generate *.bit file and flash it with fujprog -j flash file.bit
.bit is the same file that works as SRAM or FLASH content. A .svf is not like this. However a .svf can be generated to contain flashing commands so fujprog something_for_flash.svf could flash the chip too but that is not worth hassle
Goran Mahovlic
@goran-mahovlic
Oct 09 2020 09:11 UTC
@KidCUDA_gitlab hmm, we did not try - but should be possible http://flea.vieju.net/?p=37
Julian Stecklina
@blitz
Oct 09 2020 09:29 UTC

@blitz try uploading bit file to the flash. targetting flash with svf format is not supported. relevant code part:

@kost Ah, thank you. That explains why the target parameter makes no difference. I'll give this a shot in the evening.

emard
@emard
Oct 09 2020 09:54 UTC
@pnru_gitlab does cortex have some basic net functionality to upload a file with ftp or similar for convenient develop? Here's tetris source I attempted to convert to arhaic C https://github.com/emard/tetris4terminals/tree/master/arhaic If you can take a look could it work on cortex. struct timespec and termios are used.
Lawrie Griffiths
@lawrie
Oct 09 2020 10:22 UTC
I have an odd problem with my 45F device, that only affects the 45F, not other boards. I can program it with fujprog, but when I use ujprog, it says it cannot find the jtag cable. What is the difference between ujprog and fujprog that could cause this?
emard
@emard
Oct 09 2020 10:23 UTC
ujprog detects v3.0.3 and new 45F has v3.0.8 just a string change and recompile. But current linux env for compile for me has some other problems so I left ujprog old
Lawrie Griffiths
@lawrie
Oct 09 2020 10:32 UTC
I having been trying out icestudio and that uses ujprog, so that is why I was using it.
Goran Mahovlic
@goran-mahovlic
Oct 09 2020 10:33 UTC
@lawrie maybe we need to open this issue on icestudio - they should use fujprog
Lawrie Griffiths
@lawrie
Oct 09 2020 10:34 UTC
It was the nightly builds that I was trying, as I saw on twitter that they now support the ulx3s board.
emard
@emard
Oct 09 2020 10:38 UTC
ujprog is maybe left in "frozen" state. ujprog is used by studenst for v3.0.3 boards, university shop still sells only v3.0.3 and professors like no changes when "everything" works from their point of view :)
I have here some strange ujprog fork on my directory, should I rename 3.0.3->3.0.8 :)?
Lawrie Griffiths
@lawrie
Oct 09 2020 10:45 UTC
Yes, I had a look at that. Another language to learn. (Silice, not forth).
@emard I have built a version of ujprog that works for me.
Not sure what you should do to support other people.
I have also been playing with nmigen, and that uses OpenFPGALoader, so there are lots of programmers to keep working if you use lots of different tools.
Lawrie Griffiths
@lawrie
Oct 09 2020 10:53 UTC
icestudio installs apio (in .apio) and that has its own version of ujprog.
emard
@emard
Oct 09 2020 10:53 UTC
@lawrie I have added v3.0.8 in ujprog source fork at my repo. Too many copies spread around to update them all. Silice is really great, I have tried it, it's just a single executable and it generates verilog that can be compiled.
Paul Ruiz
@pnru_gitlab
Oct 09 2020 11:03 UTC

@emard

@pnru_gitlab does cortex have some basic net functionality to upload a file with ftp or similar for convenient develop?

No, as yet it does not - telnet & ftp is what I am working on; not having much time for that though.

Here's tetris source I attempted to convert to arhaic C. If you can take a look could it work on cortex. struct timespec and termios are used.

That is intriguing & thanks! It won't work in that form: termios and timespec are from a later era. In particular the VTIME functionality does not exist on the Cortex. Even more fundamentally, the system time granularity is currently 1 second. The original code was for 16ms, but I slowed that down to balance for the 8 bit bus used on the Mini-Cortex PCB. Moving back to a 16ms time base is a goal for the ULX3S version. Just last week I built a first version of select(), so that would come in handy for Tetris. All in all, given a bit of time the ULX3S Cortex should be able to handle tetris.

emard
@emard
Oct 09 2020 11:05 UTC
@pnru_gitlab yes great, the select() would provide functional minimum! We can left out sync with realtime and just have select(), it will be playable and speed a bit dependent on how fast terminal is
Goran Mahovlic
@goran-mahovlic
Oct 09 2020 11:07 UTC
I opened an issue on apio and icestudio so they can change all ujprog to fujprog
emard
@emard
Oct 09 2020 11:10 UTC
I compiled some dynamic linked ujprog for v3.0.8 in ulx3s-bin for linux. Still other platforms apple, win remain old
you can always symbolic link fujprog to ujprog (ln -sf fujprog ujprog)
or rename on windows
they have similar behaviour and command line switches, so everything should work
no need for recompilation of old ujprog
emard
@emard
Oct 09 2020 11:11 UTC
@kost yes the simplest solution is sometimes the best
Lawrie Griffiths
@lawrie
Oct 09 2020 11:56 UTC
I tried the standard icestudio example, converted for the ulx3s:
icestudio
It doesn't work correctly.
The buttons don't work as they generate their own lpf file and it has lost the PULLMODE=DOWN on the buttons, and has PULLMODE=NONE.
There doesn't seem to be a way to change that. There is a setup block that can add a pullup, but not a pulldown. I haven't tried that on the Ulx3s.
Also there is a PCF export from the File menu, and if you do that it exports a pseudo-pcf file for the Ulx3s. Very odd. There is no export lpf.
So support for the Ulx3s board does not look that good.
Lawrie Griffiths
@lawrie
Oct 09 2020 12:03 UTC
I tried the pullup setup block but that is ice40 specific and generates an SB_IO and an error for the Ulx3s.
The export menu also has things like blif and asc, which do not apply to Ecp5 boards.
Lawrie Griffiths
@lawrie
Oct 09 2020 12:13 UTC
btn[0] seems to work as that seems OK without the pullup.
To support Ecp5 boards correctly, icestudio needs to change the export menu when an Ecp5 board is selected, or use more generic terms for things like blif, asc, and pcf. blif is out of date, even for the ice40.
Lawrie Griffiths
@lawrie
Oct 09 2020 12:19 UTC
The icestudio documentation is also not very good. For example, a description of the logic blocks seems to be missing.
Goran Mahovlic
@goran-mahovlic
Oct 09 2020 12:38 UTC
I am missing one part in this studio and that is import of already written verilog file
It does not seams as mission impossible
export as .v would also be great to have
Lawrie Griffiths
@lawrie
Oct 09 2020 12:53 UTC
You can export the complete verilog (main.v) but it is incomprehensible and full of generated names.
mara
@vmedea
Oct 09 2020 12:56 UTC
after flashing Linux from https://github.com/lawrie/saxonsoc-ulx3s-bin/tree/master/Smp#using-pre-built-binaries , i can successfully use Linux through the USB serial, but the ESP32 becomes inaccessible through the network (though i've set it up to automatically connect to my AP), any idea why? i had expected to be able to use them at the same time
Lawrie Griffiths
@lawrie
Oct 09 2020 12:59 UTC
Currently, we have disabled the ESP32 (by setting wifi_en=0) due to some problems with interference with the sd card. But that can probably be removed, or attached to a switch.
Here is an icestudio, counting on the leds example:
iceleds
mara
@vmedea
Oct 09 2020 13:01 UTC
oh makes sense, i had read something about using PPP through the ESP32 for networking, which would have been nice, but yeah if it interferes with the SD card it's not very useful
Lawrie Griffiths
@lawrie
Oct 09 2020 13:03 UTC
There probably isn't any interference now, but we introduced it when we were having a problem with sd card access to eliminate that possibility.
mara
@vmedea
Oct 09 2020 13:04 UTC
thanks!
Dolu1990
@Dolu1990
Oct 09 2020 13:04 UTC
about the ESP/SDCARD conflict, basicaly, sometime, the ESP was driving MOSI, sometime not
I don't know if the reason is that the ESP get interrupted while he was booting, or something like this
MOSI or the SCK, i don't remember XD
Lawrie Griffiths
@lawrie
Oct 09 2020 13:08 UTC
@Dolu1990 I think is may not be necessary as long as micropython is running in the ESP32. When you flashed micropython, it didn't solve it for you, but we had a second sdcard problem at the time (the one that removing and re-inserting the card fixed).
Dolu1990
@Dolu1990
Oct 09 2020 13:08 UTC
right, there was quite some random issues saying hello at the same time XD
what might be not necessary ?
Lawrie Griffiths
@lawrie
Oct 09 2020 13:09 UTC
Disabling the ESP32 by wifi_en = 0, might not be necessary.
But the safest solution might be to connect it to sw[0].
Paul Ruiz
@pnru_gitlab
Oct 09 2020 13:11 UTC
I would assume that the ESP32 should not mount the sd card whilst saxonsoc is running? In an ideal world there would be arbitration who's driving the bus and each would access its own partition.
Lawrie Griffiths
@lawrie
Oct 09 2020 13:12 UTC
@Dolu1990 Or you suggested making wifi_en a gpio pin, but that seems to add complications to me.
Dolu1990
@Dolu1990
Oct 09 2020 13:14 UTC

Disabling the ESP32 by wifi_en = 0, might not be necessary.

Unless we find a way to be sure the ESP isn't driving the pin after boot, it is necessarry, i had mesurments of short cut between ESP and FPGA on the sdcard pins (The ESP was quite stronger than the FPGA XD)

All the other issues we fixed could not produce such behaviour (having non digital voltage level on the SPI SCK/MOSI (was about 2.6 V)
mara
@vmedea
Oct 09 2020 13:16 UTC
in my case it'd be ok to disable sdcard access from ESP32 completely and leave it for the FPGA, only need it for networking and to upload bitstreams
Dolu1990
@Dolu1990
Oct 09 2020 13:16 UTC
@pnru_gitlab Right, SDCARD shouldn't be used / mounted when the FPGA has usages of it.
Or we can have a small window at boot for the ESP to use it, and then release it
Paul Ruiz
@pnru_gitlab
Oct 09 2020 13:20 UTC
Then, if wifi_en is not hard disabled, we better add a heads-up in the readme to say that if both saxonsoc and the ESP32 are running the latter should not mount the sd card. I think many people will have the mount in their boot.py file and it is easy to forget.
Lawrie Griffiths
@lawrie
Oct 09 2020 13:28 UTC
@Dolu1990 I am suggesting changing:
val wifi_en = add task out(False)
to:
val esp32_disable = add task new Area {
  val wifi_en = out(Bool)
  val sw = in(Bits(4 bits))

  wifi_en := !sw(0)
 }
So that the ESP32 is enabled by default, but you can set sw[0] on to disable it.
Does that make sense?
Dolu1990
@Dolu1990
Oct 09 2020 13:31 UTC
it would work
but not allow to use the ESP wifi at the same time than SaxonSoc running
Lawrie Griffiths
@lawrie
Oct 09 2020 13:32 UTC
Why not?
Dolu1990
@Dolu1990
Oct 09 2020 13:32 UTC
because the ESP will actualy try to take controle of the sdcard
Lawrie Griffiths
@lawrie
Oct 09 2020 13:32 UTC
But if micropython is running, it doesn't.
Dolu1990
@Dolu1990
Oct 09 2020 13:33 UTC
I also had that issue when having micropython
Unless i mixed things up
We can try your proposal
to see if the issue pop again, or is realy gone
Lawrie Griffiths
@lawrie
Oct 09 2020 13:35 UTC
At least you will just have to set the switch if problems with the card occur.
Dolu1990
@Dolu1990
Oct 09 2020 13:57 UTC
Right
Michael Engel
@michaelengel
Oct 09 2020 14:05 UTC
Hi. Probably a bit of a stupid question... I´m trying to get SaxonSoc to run on the ulx3s and it seems the ESP32 interferes with FPGA access to the SD card. Somewhere here it was mentioned that J3 could be used to disable the ESP32, but I can´t seem to find J3 on the board...
Lawrie Griffiths
@lawrie
Oct 09 2020 14:06 UTC
@michaelengel Which size board are you using and where are you getting SaxonSoc from?
J3 is next to pin 9 and the sd card, but you shouldn't have to use that.
Michael Engel
@michaelengel
Oct 09 2020 14:12 UTC
@lawrie This is the board with the -85 FPGA and 32 MB SDRAM, received the board last week. I was trying to use the most recent bitfile from the docker build github repo at https://github.com/dok3r/ulx3s-saxonsoc/releases
@lawrie I also tried to use the binaries from https://github.com/lawrie/saxonsoc-ulx3s-bin - I suppose that`s your github account? The ulx3s_85f_green_2core_saxonsoc.bit bitfile gives this error message: "Image check .. OpenSBI missmatch 00B61633 FFF6C583"
Lawrie Griffiths
@lawrie
Oct 09 2020 14:14 UTC
That is the old version of SaxonSoc, not the current Smp version. I doubt if your problem is interference with the SD card.
The Smp/bitstreams/ulx3s_85f_green_2core_saxonsoc.bit bitstream from my repository should work. Several people are using it. It disables the ESP32.
Michael Engel
@michaelengel
Oct 09 2020 14:17 UTC
@lawrie Maybe it´s a problem with my way to program it. I´m currently only uploading the bitfile to FPGA RAM using ujprog, do I also need to program the onboard flash?
Lawrie Griffiths
@lawrie
Oct 09 2020 14:20 UTC
You don't need to put the bitstream in flash, but the bios and u-boot should be in flash. You are best using the Smp version from https://github.com/lawrie/saxonsoc-ulx3s-bin. There is a README in the SMP directory. Unfortunately there is currently no prebuild sdcard image.
Michael Engel
@michaelengel
Oct 09 2020 14:23 UTC
@lawrie Thanks, so I need to program the flash first... that probably explains it, will give it a try. I already built the SD card, that was no problem... thanks!
Ah yes, missed the bit on putting uboot and BIOS into flash, my bad... :/
mara
@vmedea
Oct 09 2020 14:27 UTC
can confirm that bitstream works fine on the crowdsupply ULX3S-85F board, just set up the same thing
also running it from SRAM directly, only bios and u-boot in flash
Lawrie Griffiths
@lawrie
Oct 09 2020 14:44 UTC
Playing with wifi_en connected to sw[0] corrupted by sd card. Changing it so that ESP32 boots while SaxonSoc is running doesn't seem like a good idea.
I am trying testdisk on it, as that fixed @emard's card from a similar problem.
emard
@emard
Oct 09 2020 14:48 UTC
I'm thinking how can we solve this, ESP32 if booted is useful for PPP but may easily ccorrupt SD card when saxonsoc is running...
Technically micropython will not try to mount SD by default but who knows what happens at pin transitions during ESP32 boot.
Lawrie Griffiths
@lawrie
Oct 09 2020 14:51 UTC
When you used testdisk did you wait for it to analyse cylinders. It seems to take a while.
emard
@emard
Oct 09 2020 14:52 UTC
No need to analyze cylinders but be careful you need to enable all partitions that you are sure they existed. In my case it offered also a wrong partition. It will still display some warnings abuout wrong partition so I'd suggesst first try it on a dummy backup card to get used to it
By default it will offer to restore only 1st partition, but you can move cursor down and select other offered partitions you know were really used. It can also list files on them
Second time you use it it will be restored in just a minute :)
Lawrie Griffiths
@lawrie
Oct 09 2020 14:56 UTC
The sd card seems to be rescued.
emard
@emard
Oct 09 2020 14:57 UTC
Yes great! After ESP32 fun, I rescued my SD 3-4 times already :)
If ESP32 efuse is untouched then holding GPIO12 high should prevent ESP32 from booting. Mostly we distribute efuse burnt already so that ESP32 always boots. Well once efuse is set there's no way back.
So I was thinking GPIO12 which is SD DAT(2) not used in 1-bit mode could be used held high to prevent ESP32 from booting. It will actually boot into some strange mode, internal flash not working
Lawrie Griffiths
@lawrie
Oct 09 2020 15:01 UTC
My change to use the switch seems to work, unless as yuou don't change the switch while SaxonSoc is running.
emard
@emard
Oct 09 2020 15:01 UTC
I think this SW[0] solution is good enough
Lawrie Griffiths
@lawrie
Oct 09 2020 15:02 UTC
As the switch defaults to ON, my change means that ESP32 is disabled by default. You hae to move it down to enable the ESP32. Is that OK, or is it better the other way round?
emard
@emard
Oct 09 2020 15:03 UTC
I think it's better way around. ESP32 normally ON with switch ON. Inverse will confuse users
Michael Engel
@michaelengel
Oct 09 2020 15:03 UTC
OK, after writing the flash and choosing another SD card (I used an ancient 256 MB microSD at first I had lying around which seems to be problematic), the saxonsoc boots :) - thanks again for your support! (and off to port xv6...)
Lawrie Griffiths
@lawrie
Oct 09 2020 15:04 UTC
Corrupting the partition tables is what seems to happen if ESP32 boots while Saxonsoc is running.
emard
@emard
Oct 09 2020 15:05 UTC
@michaelengel great, to be sure all is setup well, try https://github.com/emard/tetris4terminals
@lawrie Yes and I think only 1 SD block is corrupted only
Saxonsoc actually early discovers SD problem and it stops further accessing it. Sometimes I was able to almost "gracefully" steal SD card even without corruption
Michael Engel
@michaelengel
Oct 09 2020 15:08 UTC
@emard Oh, that sounds like it's fun, will give it a try :)
emard
@emard
Oct 09 2020 15:08 UTC
from Smp directory you need to extract lcc compiler into root of linux
Lawrie Griffiths
@lawrie
Oct 09 2020 15:09 UTC
@michaelengel @pnru_gitlab and I had a discussion about xv6. His cortex project is V6 Unix running on a Texas instruments TMS9900 CPU. What CPU is you planning to use for xv6?
Michael Engel
@michaelengel
Oct 09 2020 15:10 UTC
@lawrie I ported xv6 to RV32 - https://github.com/michaelengel/xv6-rv32
(runs in qemu currently) - this is just sample code for my students who are working on Oberon, Plan9 and Inferno ports to RISC V right now.
And I might continue working on a Smalltalk-80 port (did a bare metal Raspberry Pi port for fun recently...)
Lawrie Griffiths
@lawrie
Oct 09 2020 15:12 UTC
Fascinating.
Michael Engel
@michaelengel
Oct 09 2020 15:12 UTC
I should give the TMS9900 a try - I have actually worked with TI990 machines when I was a student (running DX10/DNOS)
and I have a TI99/4A somewhere :)
emard
@emard
Oct 09 2020 15:14 UTC
@michaelengel for ulx3s there is tms9900 unix by @pnru_gitlab and TI99/4A by @Speccery - many games work
Still XV6 would be very welcome as new stuff on our boards :)
Lawrie Griffiths
@lawrie
Oct 09 2020 15:15 UTC
Paul and I had some discussion with Richard Miller on the mystorm forum. He has been working on Risc-V versions of Plan9 and Inferno for ice40 boards, but I don't know how far he got. He maintains the Raspberry Pi Plan9 version, and just happens to be the first person to port Unix to a machine other than the PDP11.
Michael Engel
@michaelengel
Oct 09 2020 15:15 UTC
@emard The Unix port is the one linked from Dave Pitt's website (http://www.cozx.com/dpitts/ti990.html), right?
Yes, I know Richard was working on this and my students use his compiler (on 9p.io), which seems to work reasonably well.
emard
@emard
Oct 09 2020 15:17 UTC
https://gitlab.com/pnru/cortex/-/blob/master/doc/hacking.md here is @pnru_gitlab interesting site about powertran cortex tms9900 and quest to make unix and then port to ulx3s :)
Lawrie Griffiths
@lawrie
Oct 09 2020 15:18 UTC
@michaelengel What Risc-V implementation and SoC are you planning to use? VexRiscv and SaxonSoc?
Michael Engel
@michaelengel
Oct 09 2020 15:19 UTC
Whow, nice stuff - even though the TMS9900 is not really well suited to run C code (no HW stack and the strange in-memory registers...)
@lawrie Yes, was thinking about this, also wanted to try the ultraembedded RISC V SoC
emard
@emard
Oct 09 2020 15:20 UTC
He used some improved chip like TMS9995 but I guess additional +95 not making unix life much easier :)
Michael Engel
@michaelengel
Oct 09 2020 15:23 UTC
Yes, the 9995 was a bit nicer to interface due to the external 8 bit bus. There was also a high-end 99000 (TMS99105/110 IIRC), but that's pretty rare.
emard
@emard
Oct 09 2020 15:24 UTC
I think in ulx3s cortex unix some of instructions from those series are implemented but he would know better on details :)
Michael Engel
@michaelengel
Oct 09 2020 15:24 UTC
Tetris works nicely btw. (and ls -lR / > /dev/fb0 is also fun ;))
emard
@emard
Oct 09 2020 15:26 UTC
I'm especially happy for tetris, found some bare minimized code and added back only few necessary features, keeping it small as it ever should be :)
Michael Engel
@michaelengel
Oct 09 2020 15:27 UTC
@emard Yes, if it runs on an original Gameboy it shouldn't need too many resources ;)
emard
@emard
Oct 09 2020 15:28 UTC
It originaly run at russian PDP11 clone with 8K RAM so I gave it a try. BTW tetris > /dev/tty1 and ls -lR / > /dev/fb0 make interesting chaos together
Lawrie Griffiths
@lawrie
Oct 09 2020 15:29 UTC
The lcc RiscV compiler than Paul and i got going on SaxonSoc Linux seems to work quite well now, but it has not been tested on anything very big, and its C RTL is a bit deficient.
Michael Engel
@michaelengel
Oct 09 2020 15:30 UTC
@lawrie Running any more-or-less recent version of gcc fails due to a lack of RAM I suppose?
Maybe I can convince one of my students to work on a RISC V backend for pcc...
Lawrie Griffiths
@lawrie
Oct 09 2020 15:33 UTC
One reason to not use native gcc is that buildroot has stopped supporting it as a package. But it would probably be slow, eat ram, and be very complicated.
I share Paul and Emard's philosophy or trying to keep things small and understandable.
Michael Engel
@michaelengel
Oct 09 2020 15:35 UTC
Yeah. I have gcc 0.9 (vax and 68k backends) running here just for fun...
That's the whole idea behind the OS porting projects my students are working on - I want them to be able to understand the system they are working on (and in the end have a completely open source system, including compilers and the HW synthesis toolchain)
emard
@emard
Oct 09 2020 15:39 UTC
we are quite happy with lcc, few seconds run to a.out. well gcc 0.9 could be nice if you have proactive students, we can compare how it runs tetris too.
Michael Engel
@michaelengel
Oct 09 2020 15:41 UTC
I'm afraid gcc 0.9 was created way before the ANSI C standard existed, so the tetris code would need some changes. pcc would be the more useful compiler anyways, but I haven't looked at its backend code so far.
emard
@emard
Oct 09 2020 15:41 UTC
Oberon is also one of interesting OS+GUI things, 9000 of source, 1s to boot to windows with mouse and kbd working
@michaelengel I have "ancient" directory of tetris with K&R style :)
Michael Engel
@michaelengel
Oct 09 2020 15:42 UTC
Yes, Oberon is one of the porting targets for my students, got it running on an old Spartan 3 board here (with Wirth's RISC5 CPU)
@emard Ah, nice :)
emard
@emard
Oct 09 2020 15:44 UTC
Once cortex tms9900 gets select() call working, it will be tried for ancient tetris too. And oberon is great, ulx3s supports it. Maybe US2 port is not enough for both KBD and mouse so external PMOD USB set is recommended for convenience
Michael Engel
@michaelengel
Oct 09 2020 15:45 UTC
USB is such a horrible mess... I have some PS2 PMODs here and also a couple of old Apple ADB keyboards... these should be easier to interface.
emard
@emard
Oct 09 2020 15:46 UTC
Actually its PS/2 protocol just a connector as USB so devices combo USB+PS/2 can be plugged, some old KBD and mouses will work
As oberon not yet supports USB natively. Also we have core that acts as small host and enumerates usb-only mouse or kbd, not 100% compatible but some devices will work
Michael Engel
@michaelengel
Oct 09 2020 15:47 UTC
@emard Ah ok. Yeah, I'm using USB/PS2 keyboards with an adapter on the Spartan 3 board, too
Lawrie Griffiths
@lawrie
Oct 09 2020 15:47 UTC
Yes, I ran Oberon on the Ulx3s with Goran's Pmod and a keyboard and mouse. I think that is the version that is in my ulx3s_bit_streams repository.
Michael Engel
@michaelengel
Oct 09 2020 15:47 UTC
The USB stack probably will require more LoC than the rest of the Oberon system :)
@lawrie Ah nice, more things to play around with on this rainy weekend...
emard
@emard
Oct 09 2020 15:48 UTC
I think full USB device database and descriptor parsers would require as much as 10 oberons :)
Still here is rather small USB core which will enumerate USB1.0 or USB1.1 input devices and show their reports in HEX https://github.com/emard/ulx3s-misc/tree/master/examples/usb/proj/lattice/ulx3s/usbhid_host
Michael Engel
@michaelengel
Oct 09 2020 15:58 UTC
I need more time :)
It seems the UART console on the SaxonSoc is implemented using SBI callbacks, correct? There's also a UART at MMIO 0x10011000 (ttySL0), what is that connected to?
phdussud
@phdussud
Oct 09 2020 15:59 UTC
@emard Thank you very much for the pointer to the schematics.
Lawrie Griffiths
@lawrie
Oct 09 2020 16:02 UTC
@michaelengel The second uart is connected to the ESP32 and was used when we trying ESP32 networking (which worked, but really needs address translation in micropython). @Dolu1990 knows more about the uart implementation.
Michael Engel
@michaelengel
Oct 09 2020 16:04 UTC
@lawrie Ah, that makes sense.
emard
@emard
Oct 09 2020 16:05 UTC
I had some attempt before ttySL0 with PPP here https://github.com/emard/esp32ppp I think it needs specially compiled micropython by @pnru_gitlab for packet forwarding, but still it doesn't do NAT, NAT can be done by some external linux around the net
For networking, saxonsoc has more convenient soulution, ebay's module LAN8720 (100 Mbit RMII) or ENC28J60 (10 Mbit SPI)
Michael Engel
@michaelengel
Oct 09 2020 16:09 UTC
Hm, I should at least have a 28J60 somewhere...
emard
@emard
Oct 09 2020 16:10 UTC
LAN8720 is directly pluggable (pinout exactly fits), For 28J60 you need few wires but is also easy
Lawrie Griffiths
@lawrie
Oct 09 2020 16:27 UTC
I have put a new version of saxonsoc in Smp/bitstreams/ulx3s_85f_green_2core_saxonsoc.bit. With sw[0] is the default ON position the ESP32 is on. With it down, the ESP32 is disabled. Don't change the switch position while SaxonSoc is running, as it will likely corrupt your sd card. Also don't use an SD card from the ESP32 when SaxonSoc is running.
emard
@emard
Oct 09 2020 16:28 UTC
@lawrie getting upgrade :)
I will reboot after
root@buildroot:/home/root/tetris# uptime
 18:38:37 up 4 days,  4:03,  load average: 0.00, 0.15, 0.16
emard
@emard
Oct 09 2020 16:35 UTC
Rebooted and ESP32 is now enabled again
Paul Ruiz
@pnru_gitlab
Oct 09 2020 17:03 UTC

@michaelengel Well, that is a lot of conversation that is close my heart in the past few hours :^)

I'd be highly interested in xv6 running on Riscv / SaxonSoc and Plan9 has my keen interest as well.

Cool that you know the TI990. It's CPU can be expressed in surprisingly little verilog: less than a 1000 lines for a (nearly) cycle accurate model. The registers-in-memory approach is indeed odd, but when combined with fast memory is actually quite OK. I have not precisely measured but I think I'm getting about 0.5 VUP out of the 6MHz CPU (similar to the original 68K and the Z8000).

I did the Unix port for the 9900 from scratch, the short story is here. Dave Pitts ported this to a real 990/10 and 990/12 and much rounded out the userland software base.

Many of my experiments are essentially seeing about how much of later Unix/Plan9 ideas can be implemented on 16 bits, keeping the phenomenal bang/buck ratio V6. For instance, this spring I implemented the virtual file system (the 'file system switch') of V8 Unix in V6 and it turns out it needs only 500 bytes.

I'm not quite sure why you are interested in using pcc for SaxonSoc. What is your thinking here?

Michael Engel
@michaelengel
Oct 09 2020 17:40 UTC
@pnru_gitlab Thanks for the link to the background of the 9900 Unix port - this really is a fun project. It was amazing to see how much could be done on a 990/10 or /12, we had a customer using the machine until the mid-90s with 25 terminals and 10 printers attached. DX10/DNOS were actually quite nice.
pcc might be interesting as a compiler to support porting retrobsd/litebsd (2.11/4.3 BSD variants) to RISC V. This currently runs on some MIPS systems (PIC32 by Microchip). pcc is also historically interesting as I'm teaching a compilers course here :)
Paul Ruiz
@pnru_gitlab
Oct 09 2020 18:11 UTC
I get that. You are as interested in the history of things as I am :^) pcc is not a complex compiler (by today's standards): it may be within reach for a student project.
Michael Engel
@michaelengel
Oct 09 2020 18:16 UTC
Yeah, I'm also trying to restore some of the machines in our museum to working condition - TI Explorers, Xerox Stars and Tektronix 4404s (Lisp/Smalltalk machines). That's quite a bit of work...
Paul Ruiz
@pnru_gitlab
Oct 09 2020 18:30 UTC
This may be another (shorter) route to a compiler - and equally historically interesting. It may be a reasonable match with the 4.3BSD code base. Actually, the lcc compiler that now works on SaxonSoc Linux may also be suitable.
Michael Engel
@michaelengel
Oct 09 2020 18:34 UTC
@pnru_gitlab Yes, we're using Richard's compiler for our Plan9 and Inferno ports to RISC V. It seems to work quite well so far. Lcc is of course also nice... I read the Fraser/Hanson compiler book when I was a student.
Paul Ruiz
@pnru_gitlab
Oct 09 2020 18:39 UTC
Ah, you already have Plan9 running on RiscV? Then it is only a matter of porting that to the ULX3S
Michael Engel
@michaelengel
Oct 09 2020 18:44 UTC
@pnru_gitlab It's work in progress, two of my students are working on it and should have it running by the end of November (I hope :))
We're currently using qemu, but real hardware is, of course, always more fun
Paul Ruiz
@pnru_gitlab
Oct 09 2020 18:51 UTC
Well, depending on what hardware you have configured in qemu, it should not be an unsurmountable amount of work to get it running on Saxonsoc by Xmas :^)
Michael Engel
@michaelengel
Oct 09 2020 19:01 UTC
We're using the memory mapped virtio interface in qemu at the moment, but something more simple would be nice in the long run.
emard
@emard
Oct 09 2020 19:54 UTC
I have issue on saxonsoc and I don't know what it is. The terminal control graphics get sligthly garbled if I connect as terminal like fujprog -t or screen /dev/ttyUSB0 115200 and then start "screen" from saxonsoc prompt, and from this "screen" I run either nano editor or tetris. If I connect with ssh everything is ok. If I connect as fujprog -t without screen, again ok
Julian Stecklina
@blitz
Oct 09 2020 19:57 UTC
I'm currently using litex. Are there any advantages of saxonsoc?
btw, hello @michaelengel! :-D
Lawrie Griffiths
@lawrie
Oct 09 2020 20:00 UTC
@blitz What board are you running litex on? Are you talking about litex in general or Litex and SaxonSoc Linux?
Dolu1990
@Dolu1990
Oct 09 2020 20:01 UTC
@emard do you have the same with when running sl ?
Julian Stecklina
@blitz
Oct 09 2020 20:01 UTC
@lawrie I have the 85F ULX3s board. I'm interested in differences between the litex-vexriscv soc (https://github.com/litex-hub/linux-on-litex-vexriscv) vs saxonsoc
Lawrie Griffiths
@lawrie
Oct 09 2020 20:02 UTC
@emard I have seen the same issue with screen, The vi editor screen gets a bit mangled. sl runs fine for me.
Dolu1990
@Dolu1990
Oct 09 2020 20:02 UTC
i already had the case that using for example picocom will completly messup sl command, while with another one everything is fine
Lawrie Griffiths
@lawrie
Oct 09 2020 20:04 UTC
@blitz Are you currently running VexRiscv Litex Linux on the Ulx3s 85F board. I ask because my information on it might be a bit out of date.
Julian Stecklina
@blitz
Oct 09 2020 20:05 UTC
@lawrie Yes, I do.
Lawrie Griffiths
@lawrie
Oct 09 2020 20:06 UTC
When I last looked Litex Linux didn't support the SD card and the flash memory and had to boot over a serial link or the network. Do you know if that is still true. People who have used it, report it being very slow to boot. SaxonSoc boots in around 10 seconds.
Julian Stecklina
@blitz
Oct 09 2020 20:07 UTC
ah, interesting. litex claims support for the sd-card but I haven't tried it
Lawrie Griffiths
@lawrie
Oct 09 2020 20:07 UTC
SaxonSoc has the u-boot bootloader which I believe gives a lot more options than the bootloader Litex uses. It also uses the openSbi bios. So is using more industry-standard components.
I know Litex supports an SD card and flash on some boards, but the last time I looked it said not on the Ulx3s. I could well be out of date.
Michael Engel
@michaelengel
Oct 09 2020 20:09 UTC
@blitz Hey, small world :) - good to see you!
Lawrie Griffiths
@lawrie
Oct 09 2020 20:09 UTC
Also, I am not sure if the Litex versions fits on a 12F like SaxonSon does. They only seemed to have a prebuilt version for the 45F.
Julian Stecklina
@blitz
Oct 09 2020 20:09 UTC
@lawrie the readme says it supports the sd card on ulx3s, but I haven't tried. I'm also just using Linux to check whether everything is setup correctly. I'm more interested in playing around with some toy kernels.
I've managed to build a version that fits on the 85F, but I guess this was not a challenge. ;)
OpenSBI indeed sounds interesting
is there any documentation on saxonsoc? the readme on github looks pretty bare bones
Lawrie Griffiths
@lawrie
Oct 09 2020 20:11 UTC
In general we have put more work into supporting the Ulx3s hardware with SaxonSoc. So its supports i2c to the RTC clock. I don't think LiteX has that.
Julian Stecklina
@blitz
Oct 09 2020 20:11 UTC

@blitz Hey, small world :) - good to see you!

Likewise. I guess there are only so many cool places where OS people can hang out these days. ;)

Goran Mahovlic
@goran-mahovlic
Oct 09 2020 20:11 UTC
I think that someone at supercon did manage to run Litex on 12F but it may not be default setup
Lawrie Griffiths
@lawrie
Oct 09 2020 20:12 UTC
I don't think the litex cversion supports HDMI and the Linux framebuffer on the Ulx3s board, but I believe it does on other boards.
SaxonSoc also supports driving LCD and OLED displays on the Ulx3s.
Julian Stecklina
@blitz
Oct 09 2020 20:12 UTC
I'm sold. How do I get started? :)
Goran Mahovlic
@goran-mahovlic
Oct 09 2020 20:14 UTC
As I know no framebuffer only ASCII caracters on OrangeCrab
Lawrie Griffiths
@lawrie
Oct 09 2020 20:15 UTC
LiteX does support SMP VexRiscv SMP mode, as I know @Dolu1990 and @enjoy-digital worked together on that, but I don't know if is supported on the Ulx3s board.
Michael Engel
@michaelengel
Oct 09 2020 20:15 UTC
@blitz Lawrie's readme file on github works well to get started (if you carefully read it - which I didn't, that's why I showed up here...) - https://github.com/lawrie/saxonsoc-ulx3s-bin/tree/master/Smp
Lawrie Griffiths
@lawrie
Oct 09 2020 20:16 UTC
I am pretty sure that LiteX does not support Linux alsa sound like SaxonSoc.
Michael Engel
@michaelengel
Oct 09 2020 20:16 UTC
I flashed the FPGA and serial flash ROM using fujprog via USB/FTDI, not via the ESP32
Lawrie Griffiths
@lawrie
Oct 09 2020 20:17 UTC
I keep advertising this twitter thread on SaxonSoc - https://twitter.com/lawriegriffiths/status/1312360783028903937 (as is the only one I have ever written).
That lists the things that SaxonSoc supports and gives links to my prebuild binaries and to building from source.
Building from source requires installing Scala and SpinalHDL, but several people here are successfully doing that such as @e2kgh, @dpavlin and @kost.
But I personally would like someone to work on a good port of the Litex Linux to the Ulx3s board, so we can better compare its strengths and weaknesses to SaxonSoc.
Lawrie Griffiths
@lawrie
Oct 09 2020 20:23 UTC
If you are planning to do developments with it, there are quite a few people who prefer python to Scala, so that is a consideration. Personally, I think the SpinalHDL language is much better than migen or nmigen.
Julian Stecklina
@blitz
Oct 09 2020 20:23 UTC
living in saxony, saxonsoc's name definitely is a strength ;)
Michael Engel
@michaelengel
Oct 09 2020 20:24 UTC
:)
Lawrie Griffiths
@lawrie
Oct 09 2020 20:24 UTC
One issue with LiteX that puts me of working with it, is that it is written in migen, and that has been superseded by nmigen.
There are peripherals that Litex supports that SaxonSoc doesn't, but the list is getting smaller. PCI Express is one of them, but is not relevant to the Ulx3s board. I don't know if LiteX supports USB on any of its Linux versions. @Dolu1990 has started work on USB 1.1 host support for SaxonSoc, but that will take some time to complete as USB host is complex.
Lawrie Griffiths
@lawrie
Oct 09 2020 20:29 UTC
Booting over the network is one thing that Litex support that Saxonsoc currently doesn't, but I think u-boot supports that and it could probably be added if it was important to anyone.
Julian Stecklina
@blitz
Oct 09 2020 20:30 UTC
@lawrie I got uboot working on saxonsoc, so I guess I followed the instructions. :) now I just have to find an sd card...
Lawrie Griffiths
@lawrie
Oct 09 2020 20:30 UTC
Yes
Lawrie Griffiths
@lawrie
Oct 09 2020 20:38 UTC
The previous version of SaxonSoc Linux had a pre-built sdcard image. The Smp version just has instructions.
The lcc native C compiler is another plus for SaxonSoc, but it should run on LiteX as well as they use the same buildroot system.
Charles Perkins
@charlesap
Oct 09 2020 20:44 UTC
Hi everybody -- I have got my ulx3s to run Oberon on, and the prebuilt ulx3s_85f_oberon.bit runs and displays video! w00t! I am also able to build the .bit file using the kost/ulx3s-oberon dockerized packaging of the development environment, which uses Lattice Diamond 3.74.

Encouraged by that tried again with Lattice Diamond 3.11 on a different, beefier machine, without Docker. Now I get this lovely error message from diamondc:

ERROR - map: EHXPLLL 'clk_25_100_100p_25_inst/pll_i' output CLKOP with -180 degree phase shift should not be used as the feedback signal (FEEDBK_PATH = CLKOP).

Any idea where I should look first to try to resolve this?

Goran Mahovlic
@goran-mahovlic
Oct 09 2020 20:52 UTC
maybe removing phase shift from makefile or if it is there it may be clock module i top level
Charles Perkins
@charlesap
Oct 09 2020 20:53 UTC
ok, thanks!
Lawrie Griffiths
@lawrie
Oct 09 2020 20:54 UTC
I can't remember what I did about that problem. I think I probably built it with docker and the older version of Lattice. I believe you can generate the PLL with the Lattice GUI.
Charles Perkins
@charlesap
Oct 09 2020 20:55 UTC
helpful clues. Thanks.
Lawrie Griffiths
@lawrie
Oct 09 2020 20:56 UTC
I don't know if @emard has a better solution now.
It is a general problem with PLLs with phase shifts generated by trellis tools and used with Diamond 3.10 (I think) and beyond.
Goran Mahovlic
@goran-mahovlic
Oct 09 2020 20:57 UTC
You can also run 3.11 in docker
Lawrie Griffiths
@lawrie
Oct 09 2020 20:58 UTC
It is possible that Oberon may build with the open source tools and the GHDL plugin. I don't know if anyone has tried.
Julian Stecklina
@blitz
Oct 09 2020 20:59 UTC
does anyone know how to get a directory listing of the sd card from uboot?
I fail to write a device name for fatls
=> fatls mmc 0:0 / 
=>
mmh
I guess uboot thinks the sdcard is empty?
Charles Perkins
@charlesap
Oct 09 2020 21:00 UTC
oh hey look, in /oberon/hdl/lattice/clk_25_375_75_25.v it says
// diamond 3.7 accepts this PLL
// diamond 3.8-3.9 is untested
// diamond 3.10 or higher is likely to abort with error about unable to use feedback signal
// cause of this could be from wrong CPHASE/FPHASE parameters
Guess I'll look into phase parameters or fall back to 3.7
Lawrie Griffiths
@lawrie
Oct 09 2020 21:05 UTC
=> fatls mmc 0:1
     4005   dtb
  9719360   rootfs.cpio.uboot
  5489076   uImage
     3753   dtb.12f
     4005   dtb.green85f
     4509   dtb.blue85f

6 file(s), 0 dir(s)

=>
Julian Stecklina
@blitz
Oct 09 2020 21:06 UTC
I just get emptiness. are there limitations to the sd cards supported?
Michael Engel
@michaelengel
Oct 09 2020 21:06 UTC
@blitz I also had that problem when the ulx3s didn't like the first SD card I tried
Lawrie Griffiths
@lawrie
Oct 09 2020 21:06 UTC
Does mmc part give anything?
Julian Stecklina
@blitz
Oct 09 2020 21:07 UTC
no
Lawrie Griffiths
@lawrie
Oct 09 2020 21:07 UTC
=> mmc part

Partition Map for MMC device 0  --   Partition Type: DOS

Part    Start Sector    Num Sectors    UUID        Type
  1    2048          204800        519ca73f-01    06 Boot
  2    206848        409600        519ca73f-02    83
=>
If you are using the latest version of Smp/bitstreams/ulx3s_85f_green_2core_saxonsoc.bit, you could try using sw[0] to disable the ESP32. I suggest unplugging the device before doing that and pushing switch 0 down to the off position. But the symptoms you are getting look like a bad SD card rather than ESP32 interference.
Can you read the SD card from a Linux machine, orthe first partition from Windows?
I don't know of any restrictions on the type of SD card.
Julian Stecklina
@blitz
Oct 09 2020 21:12 UTC
I just wrote the card from my thinkpad. so I guess the card itself is fine (I also used it before in a raspberry pi)
I can grab a different brand of sd-card tomorrow
Lawrie Griffiths
@lawrie
Oct 09 2020 21:13 UTC
I believe @emard and I are both using Sandisk Ultra ones. But I have used others.
Julian Stecklina
@blitz
Oct 09 2020 21:14 UTC
i have a sandisk 32gb class 4 card
Lawrie Griffiths
@lawrie
Oct 09 2020 21:16 UTC
You could try removing the card and reinserting it while still in u-boot. That fixed a previous problem. Possibly do mmc rescan after reinserting it.
But it looks as if SPI is working OK for you, and that u-boot is just not reading the partitions.
I have used both 32GB and 64GB Sandisk cards.
Lawrie Griffiths
@lawrie
Oct 09 2020 21:23 UTC
Did you see messages like this:
DRAM:  32 MiB
MMC:   spi@10020000:mmc@1: 0
Loading Environment from FAT... *** Warning - bad CRC, using default environment
Julian Stecklina
@blitz
Oct 09 2020 21:23 UTC
I think I'm just too stupid to insert it into the cage thingy. I guess it's supposed to go in all the way
but it doesn't snap into place
Lawrie Griffiths
@lawrie
Oct 09 2020 21:25 UTC
The hinges are annoying. The boards without them are easier to use. You do have to pull the hinge back when the card is in place.
Julian Stecklina
@blitz
Oct 09 2020 21:30 UTC
image.png
my pride suffered a bit, because I had to check google images on how the hinge is supposed to work ;)
thanks for the patience @lawrie
Lawrie Griffiths
@lawrie
Oct 09 2020 21:32 UTC
Good to get another user of SaxonSoc Linux.
emard
@emard
Oct 09 2020 21:33 UTC
@lawrie @charlesap I think I got oberon compiled with opensource tools I must check my repository. Trick was to use vendor specific brams because inferring by yosys missed some points and made it too big to fit
Julian Stecklina
@blitz
Oct 09 2020 21:35 UTC
Is "* Warning - bad CRC, using default environment" something to worry about?
Lawrie Griffiths
@lawrie
Oct 09 2020 21:37 UTC
I think it just means it didn't find a saved environment file. Not sure why it gives an error message. I haven't tried saved environments with this version as I haven't needed to. We used to use them to switch between 32MB and 64MB of ram on different boards.
Julian Stecklina
@blitz
Oct 09 2020 21:37 UTC
ah, ok
Lawrie Griffiths
@lawrie
Oct 09 2020 21:39 UTC
It is possible to run a 4-cpu system on the green 85F boards, but I haven't built one. I think @e2kgh did.
Charles Perkins
@charlesap
Oct 09 2020 21:48 UTC
Thanks everybody, setting .CLKOP_CPHASE(1) in clk_25_375_75_25.v and .CLKOP_CPHASE(5), in clk_25_100_100p_25.v appears to have worked! I was able to compile an Oberon bit file and it booted. Now I can go do more dangerous things...
Michael Engel
@michaelengel
Oct 09 2020 21:49 UTC
@charlesap What are your plans for/with Oberon?
Charles Perkins
@charlesap
Oct 09 2020 21:50 UTC
I think I would like to do a build with opensource tools by preference though, so I look forward to seeing what you can dig up @emard
emard
@emard
Oct 09 2020 21:51 UTC
https://github.com/emard/oberon my repo is compiling with yosys now. I could upgrade the buggy ecppll.exe with my reworked ecp5pll.sv
I'm waiting for compile to finish so lets see will it boot
Yes it works. USB+PS/2 combo mouse to US2 port. My mouse needs to be unplugged and plugged after oberon boots because it will otherwise stay in USB mode
emard
@emard
Oct 09 2020 22:09 UTC
Actually first diamond compiled it currently. I will replace ecp5pll.sv now
Charles Perkins
@charlesap
Oct 09 2020 22:10 UTC
@michaelengel I wanted a clean-slate platform for exploring architectural concepts, integrated in one system, that have been explored elsewhere separately. I have a grab bag of ideas taken from lots of other systems that are probably mutually incompatible but we'll see. I'm delighted to see others also exploring Oberon, it's a gem of alternative thinking, not afraid to be different.
I ordered a couple of diligent ps2 PMODs, I guess my first modifications will be to introduce handling of those. After I solder the headers on the board, of course!
emard
@emard
Oct 09 2020 22:12 UTC
Hardcore oberons have "complaints" of uncleanness to ulx3s because sdram driver and cache is written in verilog while they would like it be written in LOLA2 https://people.inf.ethz.ch/wirth/Lola/index.html
Michael Engel
@michaelengel
Oct 09 2020 22:13 UTC
@charlesap Definitely, it's a great piece of work. My student who is working on the port of project Oberon to RISC V is highly motivated.
Charles Perkins
@charlesap
Oct 09 2020 22:14 UTC
Hardcore oberons were also not thrilled when I switched my sourcecode to also handle newlines in text... for starters. Made it so much easier to interoperate with linux, which is what I use most of the time.
But change comes, there's a branch that handles utf8 now, and I'm trying to add "interfaces" (a.k.a. "dynamic traits" in Rust) to oberon-2. I got the ulx3s mainly to keep me honest when I make changes. If I make a change that is not performant on the FPGA then it is not a good change.
Lawrie Griffiths
@lawrie
Oct 09 2020 22:16 UTC
@charlesap Why do you prefer the PS2 Pmods to using the us2 connector and the USB Pmod? They work directly with some USB keyboards or mice, or with an adapter with PS/2 keyboards and mice.
emard
@emard
Oct 09 2020 22:17 UTC
:) hehe I hope oberons will be more satisfied when they get our boards delivered, they boot and have practically all in place (except 2nd usb/ps2). OK -> so far so good, ecp5pll.sv provided still bootable oberon at my 12F
Charles Perkins
@charlesap
Oct 09 2020 22:18 UTC
I don't actually prefer the PS2 Pmod... It's just that I ordered them before I knew what I needed and now it is a challenge to me to see if I can make them work. If I can make them work then it will show that I understand how to program the ulx3s.
Now I have to go back to my day job activity and upgrade the gitlab instance so a programmer can update his continuous integration pipeline tools...
Lawrie Griffiths
@lawrie
Oct 09 2020 22:20 UTC
I have one or two of them and it should be no problem making them work. For some keyboards I need to use external 5v power with them.
emard
@emard
Oct 09 2020 22:47 UTC
Normally US2 should provide from USB 5V, strange that keyboard starts working if external 5V is connected. US2 5V is routed over 3A schottky diode thus reducing it to 4.7V but should for average KBD be still ok.
I got oberon nearly working using latest yosys/trellis nightly tools with -abc9 option. I see the font windows and mouse pointer which moves with mouse but whole picture "travels" horizontally, seems as hsync is somehow missing. Diamond works well using same source.
emard
@emard
Oct 09 2020 23:14 UTC
I inverted hsync and now oberon compiled with yosys/trellis provides correct picture. It's a kinda magic solution probably makes synthesis route a little bit differently
Charles Perkins
@charlesap
Oct 09 2020 23:23 UTC
cool!