Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Goran Mahovlic
    @goran-mahovlic
    @TheAnimatrix just avoid top right corner on ULX3S as it has 5V OUT
    emard
    @emard
    @pnru_gitlab thnx, I'll try to test something of new oberon. You correctly noticed, oberon is designed without interrupt. It would be good to have some for I/O. CPU core and source is smaller without IRQ :)
    TheAnimatrix
    @TheAnimatrix
    is there any way i can get hold of a ulx3s (85f) model right now ?
    i see the ship date is november
    we're trying to port a couple of our designs from xilinx to lattice
    also can we unlock the 12k lut edition to 25k luts, i heard that they're essentially the same silicon
    just soft locked
    Paul Ruiz
    @pnru_gitlab
    @emard thnx, I'll try to test something of new oberon.
    Thanks, I will have little time this weekend to push it further (although I hope to find some time to get that other sd card for oberon).
    Paul Ruiz
    @pnru_gitlab

    @charlesap If there are no interrupts, then the "l1: jmp l1" loop is probably an error condition. I did notice that it switches all leds off just before entering the loop (it gets to 0x84 before). Where, after the boot load, does it continue (I mean at the source level) ?

    In simulation I am running a plain sram in parallel with the cache/sdram to verify all data reads, so I am reasonably certain that it is not a memory bug. Maybe I did something wrong on the I/O side.

    Goran Mahovlic
    @goran-mahovlic
    @TheAnimatrix Production of 85F is done, but I still need to get papers from CrowdSupply and ship boards, so I do not think it will be sooner then November. I do have few boards with not working ESP32 that I will not send there - but still "normal" shipping of those board could take some time - so maybe fastest way is to wait for Mouser/CS -
    @TheAnimatrix If you use opensource tools you will have more luts by default
    Paul Ruiz
    @pnru_gitlab
    @emard by the way, in that tar ball prom.mem is the version that @charlesap did, with a shortened delay loop in the boot. prom_old.mem is the original version for use with real h/w.
    emard
    @emard
    @pnru_gitlab I compiled your source but I'm not sure did it boot properly. My oberon boot LEDs D7+D1, D7+D2, and D5 (leaves only D5 lit). Your stops at D7+D2
    I compiled prom_old.mem
    Paul Ruiz
    @pnru_gitlab

    @emard Well, that seems to be a lot of good news: If it gets to D7+D2 (0x84 in the simulation run) it has loaded the Oberon kernel from the SD card. From simulation I know that there are a dozen or so reads/writes between the cache and sdram, so if it gets there in all likelihood the new burst sdram controller is working with real h/w. How about the video, did that generate a stable signal?

    My simulation run switches off all LEDs (after D7+D2) before entering the endless loop, so there is a difference there to be explored.

    I know very little about Oberon - the closest I got to Niklaus Wirth's work was reading the Pascal User Manual and Report over and over in the seventies. We need the input from the Oberoners to understand what the various LED codes mean. @charlesap and others, feel free to comment!

    emard
    @emard
    Ha it has some video out? :) No GPDI but I can add some if theres VGA signal
    Paul Ruiz
    @pnru_gitlab
    There ate two tar balls. The later one has a first stab at gpdi video
    Are
    emard
    @emard
    aaaa I will pull. I can post on oberon list a question what boot leds mean
    emard
    @emard
    Hmmm it can't fit on 12F, (will try 85F next)
    ERROR: Unable to place cell 'video.vram.mem.0.8.0', no Bels remaining of type 'DP16KD'
    Paul Ruiz
    @pnru_gitlab

    Yes, this a simple start with 96KB of shadow block ram and 85F only.

    Once that works (and the rest of Oberon, of course), we can refine. I'm thinking to roughly follow the design of the Fleaohm one, but with a few simplifications: (i) use a dual ported buffer bram, but merely 512 bytes (will be rounded up to one 18Kb block); (ii) switch the sdram controller between servicing the cache and the video circuit; (iii) fetch 256 bytes (2 lines of b/w pixels) - same as a cache line; (iv) at every time, 256 bytes in the bram are being read by the display circuit and the other 256 are being refilled - these switch roles every two lines; (v) add a "flush" feature to the cache.

    Paul Ruiz
    @pnru_gitlab

    @emard I have just discovered that I have the switches wrong. I have them at zero, the Fleaohm version has them at one:
    https://gitlab.com/pnru/ulx3s-misc/-/blob/master/oberonstation/Ulx3s_Top.v#L109
    https://github.com/emard/oberon/blob/master/hdl/RISC5Top.OStation.v#L76

    Maybe we should hook this to the ulx3s switches - at least the bottom 6 ones.

    emard
    @emard
    ok currently video 1024x768 black screen and no SD boot at 85F with MICRON 32MB SDRAM and ISSI 16MB flash. Only D7 lit constantly. My oberon bitstream boots and works
    emard
    @emard
    Non-video version on 85F boots to D7+D2
    I will try swi = 0xFF
    Paul Ruiz
    @pnru_gitlab

    Maybe this is related to the SDRAM frequency being slightly off (PLL at 130MHz instead of 125MHz). Also, my build fails Fmax for the CPU (22MHz max). What did you get?

    Will try a simulation run with switches set to one.

    emard
    @emard
    Fmax failed at 12F, I didn't read how much just set nextpnr to ignore timing
    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
    ov7670