Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    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
    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.
    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.
    emard
    @emard
    yes oberon 251020. I compiled but no boot, Only D7 lit. Generates 1024x768 60Hz black screen, correct sync
    Oh sorry my mistake, yes you are right, I extracted wrong file
    Paul Ruiz
    @pnru_gitlab
    emard
    @emard
    I am compiling this with corrected memsel and video enabled
    emard
    @emard
    I compiled now latest 251020 but still the same effect only D7 lit and black screen
    Paul Ruiz
    @pnru_gitlab
    Uhm, i think i forgot to change pll.v back to 125 (0 deg) mhz.
    emard
    @emard
    You can use my ecp5pll.sv that's easy any setting
    Paul Ruiz
    @pnru_gitlab
    Yes.
    emard
    @emard
    My ecp5pll calculator reports that it can't fit parameters for 125,65,325 MHz to the same PLL and requires 2 different instances.
    your has generated 130MHz instead of 125 MHz which can't work
    BUT on 85F now there are not enough BRAM to support OSD HEX display :)
    Paul Ruiz
    @pnru_gitlab
    In general it should be able to work, but in this case I'm pushing it really close on timing. The SDRAM has data ready at "half a clock" as seen from the controller clock and I delay that by ~2ns. This means registered data is available 6ns after the controller clock positive edge. The cache block RAM clocks that in on the next positive edge. At 125MHz the cycle is 8ns, so the block RAM gets 8 - 6 = 2ns setup time. At 130ns it is even less.

    How about a test without video at 125MHz? It would be good to know if that boots to the expected leds.

    My simulation now ran for 400ms, but it is still doing stuff with the file system at that time.

    emard
    @emard
    I will compile it somehow with 125MHz to see what LEDs do
    emard
    @emard
    I compiled 125MHz but same as before D7 and no boot
    Paul Ruiz
    @pnru_gitlab
    Bummer - that can only mean that the sdram is not working. However, with the 12F yesterday getting a lot further in the sequence, I must be close. Back to the drawing board. Maybe that SDRAM test bench model that @edbordin located will help in pinning down the issue.
    emard
    @emard
    In video declaration there is 1 word too much reg [31:0] mem[0:24575]; while you used 24576
    Paul Ruiz
    @pnru_gitlab

    Another strange thing is that the screen is black - I think I am pre-filling the video ram with some content.

    Yes, you are right: 24575.

    emard
    @emard
    OK last word doesn't make it fit with OSD ...