ulx3s/Lobby

emard

@emard

With swi=0xFF at non-video oberon, it has D7+D0 and stays (I'd say less boot progress than before)

Paul Ruiz

@pnru_gitlab

For the meaning of the switches there is this line:
https://github.com/Spirit-of-Oberon/ProjectOberon2013/blob/master/Sources/BootLoad.Mod#L6
but I don't recognise that from the code.

It seems with the switches the other way around it sits waiting for a boot from the serial line:
https://github.com/Spirit-of-Oberon/ProjectOberon2013/blob/master/Sources/BootLoad.Mod#L110

Have to check why my switches appear to be in reverse from Fleaohm.

Paul Ruiz

@pnru_gitlab

Ah, this is why:
https://github.com/emard/oberon/blob/master/hdl/RISC5Top.OStation.v#L160
I had missed the negation. I guess on the pepino switches are inverted.

Charles Perkins

@charlesap

@pnru_gitlab @emard I will see if I can generate an Oberon sd card with some more interesting LED activity. I have downloaded the source files again from http://www.projectoberon.com and will work from that so it is as close to the original as possible, just a recompilation with more blinky bits!

Paul Ruiz

@pnru_gitlab

Thank you @charlesap ! I've managed to pop out to the stores today and get an extra sd card for oberon experiments. From our first experiments it seems a lot is already working - at least the CPU is executing PROM code and the little use that the the boot code makes of main memory seems to work correctly enough to load the kernel (although I am not sure it will have loaded into core correctly - maybe the cache access is okay, but the main ram access is not, etc.)

What would be ideal is to have a mini-monitor to access the system over serial and inspect some stuff "from the inside". Maybe this already exists in some form for embedded use.

Paul Ruiz

@pnru_gitlab

@charlesap My simulated boot seems to end up on this patched instruction:
https://github.com/Spirit-of-Oberon/ProjectOberon2013/blob/master/Sources/Kernel.Mod#L251
At the moment I am totally confused on RISC5. The code in the OberonStation does not seem to use it, but the RISCx materials discuss interrupts implemented at the RISC3+ levels. The above code line appears to handle traps, but the online book is silent on traps.

Charles Perkins

@charlesap

@pnru_gitlab traps are briefly mentioned at the end of chapter 12 in the online PDFs http://www.inf.ethz.ch/personal/wirth/ProjectOberon/PO.Applications.pdf where the compiler inserts checks for things like null pointer dereferences and array-out-of-bounds, etc. Traps 1 through 7 are error conditions. Trap 0 however is not an error, it is a memory allocation request that is satisfied by the Kernel. Traps are different from Interrupts, which as you noticed were introduced later. Traps are a software construct, the details involve the way modules work in Oberon.

emard

@emard

leds in boot loader
80H cold boot
81H load Oberon from serial
82H load Oberon from CF
84H transfer from boot loader to Oberon

leds in Oberon
21H garbage collector mark phase
23H garbage collector restore files
27H garbage collector scan phase
20H garbage collector ends
C0H+w  Trap w

br
Jörg

@pnru_gitlab I think you may need OLED/LCD hex decoder for the bus state...

emard

@emard

@pnru_gitlab do you have one of supported mini displays like SSD1331, SSD1306, SSD1351, ST7789. If none I can display on DVI or maybe even try to OSD mix HEX with normal 1024x768

Paul Ruiz

@pnru_gitlab

@emard No, sorry I don't have one of those - but I can order one. I'll see if I can find a local supplier with short lead times.

emard

@emard

Let me first try DVI version of the HEX. For ordering best buy is ST7789 1.3"

Paul Ruiz

@pnru_gitlab

I'm thinking that I should first find out why the simulation run ends up in the start-up trap. If it does not work in simulation, for sure it does not work on real h/w -- an in simulation it is easy to inspect every wire at every clock. Probably an ASSERT fails, it is a matter of finding out which one.

Also, as it is almost certain that the CPU and the cache RAM work, it may be easier to write some small test routines in RISC5 assembler, to figure out if the SDRAM is working.

emard

@emard

here is another answer from oberon mailing list to the boot issue

Hello Jörg,

D7+D2 is 84H, not 82H.
(D0=1H, D1=2H, D2=4H, D3=8H, D4=10H, D5=20H, D6=40H, D7=80H)

If reading from RAM or writing to RAM were totally broken, it would not
get that far.

One possible reason (just a guess) would be if RAM reading as data
works, but reading as code would not. Since at that point a RAM
instruction is executed for the first time (before it was all in ROM).

But as for most memory problems, it could be many other things as well.
Regards 
Michael

Paul Ruiz

@pnru_gitlab

ST7789 1.3" That is a good suggestion, that model is available locally and in stock.

emard

@emard

I recommend it, 240x240 color and good contrast, low price.

Lawrie Griffiths

@lawrie

@goran-mahovlic I now have a version of the OV7670 camera application working in nmigen with the st7789 display - https://github.com/lawrie/ulx3s-nmigen-examples/tree/master/ov7670

Ulx3s selfie. There is a bug at the moment with some wrapround on the left.

Goran Mahovlic

@goran-mahovlic

woohoo!

Charles Perkins

@charlesap

@pnru_gitlab @emard I have created a new disk image based on the www.projectoberon.com sources, only adding some more LED output in the inner core boot process.

Here's a zip file of a disk image that you should be able to directly write to an SD card: https://github.com/io-core/io/blob/main/images/ledboot.img.zip ... this image has the Oberon partition at the correct offset but I did not bother to format the first part with a FAT partition. It boots on my ulx3s with the earlier Oberon .bit file.

Here's the meaning of the LEDs on booting:
LEDs: 7------- In BootLoad Firmware
LEDs: 7-----1- In BootLoad Firmware
LEDs: 7----2-- In BootLoad Firmware
LEDs: -------0 Control transferred to Modules
LEDs: ------1- Control transferred to Files
LEDs: -----2-- Control transferred to Kernel
LEDs: ----3--- In Kernel - Temporary Trap installed
LEDs: ---4---- In Kernel - Stack and heap origins and limits configured
LEDs: --5----- Kernel SecMap initialized, control transferred to FileDir
LEDs: -6------ Directory traversal complete
LEDs: 7------- Sectors marked, control transferred to Modules which has loaded Oberon.
LEDs: -------- Icons are defined, display subsystem initialized, ready to load System.
LEDs: --5----0 GC in the Oberon Loop
LEDs: --5---10 GC in the Oberon Loop
LEDs: --5--210 GC in the Oberon Loop
LEDs: --5-----

If there is an early trap before the system introduces a nicer printing trap the leds will fast-blink now with the trap value (0-7).
If the system gets an error trying to load modules after the boot loader successfully loads the kernel (which Oberon needs to actually display graphics and text to the screen) then this code fast-blinks bit zero.

The Oberon source code modified with the LED output is here:

https://github.com/io-orig/projectoberon/blob/main/Kernel.Mod.NL
https://github.com/io-orig/projectoberon/blob/main/FileDir.Mod.NL
https://github.com/io-orig/projectoberon/blob/main/Files.Mod.NL
https://github.com/io-orig/projectoberon/blob/main/Modules.Mod.NL
https://github.com/io-orig/projectoberon/blob/main/Oberon.Mod.NL

Paul Ruiz

@pnru_gitlab

Great! That will help a lot. The list post above by "michael" is helpful as well. It would seem that a RISC5 cpu does not assert its RD line for instruction fetches. As long as the instructions happen to be in the cache things happen to work right, but when there is a cache miss, the cache controller does not realise there was a valid mem fetch happening....

emard

@emard

http://lists.inf.ethz.ch/pipermail/oberon/2020/015065.html here is this message, we can check this thread if something more appears

Paul Ruiz

@pnru_gitlab

Well, fixing all clock cycles other than I/O or PROM being memory cycles improved things. With the new disk image I now get:

SD CMD = 510008004cff
i =          90
SD CMD = 7a00000000ff
SD CMD = 510008004dff
i =          91
leds=00000084
leds=00000001
leds=00000002
leds=00000004
leds=00000020
memory bug!

in simulation. The leds= values are hex. So we get to "control transferred to the Kernel" before we go wrong. And we go wrong before there is a memory bug (i.e. cache output != shadow sram output).

emard

@emard

I practically got semi-transparend OSD HEX overlay working for flea-based oberon, a few tuning parameters and it will be ready to release

Ed Bordin

@edbordin

reposting from discord: Has anyone found a good simulation model for the IS45S16160G sdram? (ideally verilog)

Paul Ruiz

@pnru_gitlab

This last mem bug seems to be because the RISC5 CPU does not keep its address bus stable during a memory stall in all cases. I'm beginning to see why Fleaohm chose gating the clock as a brute force way out.

reposting from discord: Has anyone found a good simulation model for the IS45S16160G sdram? (ideally verilog)

Very simplistic, but these worked for me:
https://gitlab.com/pnru/ulx3s-misc/-/blob/master/oberonstation/ob_tb.v#L150-261
https://gitlab.com/pnru/cortex/-/blob/master/sys_tb.v#L292-385

The Cortex one does single word reads/writes with CL=3, the Oberonstation one does burst reads/writes with CL=3.

Ed Bordin

@edbordin

thanks! I also just found this which was the sdram chip used on a different production run (I will have to take care to select the equivalent 256M size for it though) https://github.com/lgeek/orpsoc/blob/master/bench/verilog/mt48lc16m16a2.v

Paul Ruiz

@pnru_gitlab

thanks! I've looked for something like that for a while, but never found one.

Ed Bordin

@edbordin

I might give it a go, so long as I edit the timing parameters it looks like it should be good. Although given I'm using someone else's working sdram controller maybe this is overdoing it

emard

@emard

@pnru_gitlab in my port of oberon here is OSD HEX overlay example where it can in real-time display any 64-bit wire as HEX overlaid on oberon screen. I must go2sleep() now, if you want me to add it to your code I can do it, just it needs VGA signal out and it will video mix HEX to it. https://github.com/emard/oberon/blob/master/hdl/top/ulx3s_v20_top.v#L175

emard

@emard

OSD stuff is updated, holding BTN1 shows HEX LED, sdram_a, sdram_d over oberon video. HEX is updated during vsync to avoid "breaking" of digits. There is not much traffic on the bus, moving mouse pointer will change it for example.

Paul Ruiz

@pnru_gitlab

@emard @charlesap OK, thinking about the address bus stability with a fresh mind this morning lead to a minimal, 2 line fix to the RISC5 core and now it seems to work (in simulation) as it should. It continues to led=0x40, "Directory traversal complete" when te simulation time (200ms) ran out.

Will do a longer run, but it seems we are there on the simulation side.

emard

@emard

Great news! I have HEX decoder and DVI video OSD ready to be used if you will need help in hardware debugging that shows any bus state in HEX in real time. mini display is not required.

Paul Ruiz

@pnru_gitlab

@emard I've uploaded a new tarball. I've not tried synthesis at all yet. Video code is there, but commented out in the top file. I've renamed the prom images prom.mem (original) and prom_sim (charles version) with an ifdef in the PROM.v file for automatic selection of the right one.

Paul Ruiz

@pnru_gitlab

https://gitlab.com/pnru/ulx3s-misc/-/blob/master/oberonstation/oberon_251020.tgz

emard

@emard

I pulled and compiling

Paul Ruiz

@pnru_gitlab

Thanks. Hopefully I will be able to do some h/w tests of my own late this evening.

emard

@emard

Video is also enabled at toplevel what I see in the source, no commented out?

Quiickly looking, OSD HEX could be inserted in the video stream at toplevel

Paul Ruiz

@pnru_gitlab

I think in line 343-372 in Ulx3s_Top.v I have commented it out?

emard

@emard

No, there's just comment text commented and code active

It can be left as is especially if it generates any picture

Paul Ruiz

@pnru_gitlab

In oberon_251020.tgz ?
There may be a timing synthesis issue with video included, but maybe it works.

It is not good if you don't see the commented out lines, because there were changes to the toplevel as well since yesterday.

Where communities thrive

People

Repo info

Activity