[Oberon] RiskFive; was Oberon on ULX3S explanation

[Skulski, Wojciech]

Joerg wrote:

> Porting the system to a new board is mainly a task of understanding and adapting the .v files.

Or devising an entirely new set of files, not necessarily in Verilog. My favorite is P.P.Chu because of the quality of his book. There is no need to shy away from using an entirely new SoC if it is essentially almost ready to take.

Another need is adding new hardware to the board. New HW then needs to be interfaced, using an entirely new Verilog/VHDL files. 

> There are hardly any .Mod files you ever have to touch.

I strongly disagree. The goal of porting is to develop drivers for the new hardware. Current modules do not suffice, if the hardware has changed. Just a simple example: Imagine I want to use a QSPI interface to the SD card. The present interface is SPI. The code, which is currently in Kernel.Mod, is implementing SPI. It needs to be changed for the QSPI. Also look at the Kernel parameters, which limit the SD layout and limit its size. They are all hard coded in present modules. 

Another example: The FAT32 file system. Imagine I want to use the full card capacity, and make it readable under Windows. Then I need to switch to the FAT32. There are FAT32 implementations. You can get one from Cypress. Originally it was developed by Spansion. It is pretty substantial software. There are other, simpler implementations with some restrictions. Implementing FAT32 under Oberon System is a feasible task, though obviously it is lots of work. 

You may say "no, we should not be doing this". This is a different statement from saying "no need to touch the .Mod". If we do not touch these modules then we declare the Oberon System frozen and running on a frozen hardware. It becomes an interesting museum piece.

> The Oberon system can be compiled as is if the FPGA implements NW’s CPU and offers 1MB of memory, and the IOs and video framebuffer are mapped to the documented memory addresses.

Note that this discussion started around this new board with much more RAM. And it has the HDMI output for graphics. So there is a need for evolution right away.

If we want to freeze the system, then yes, we stay with 1 MB and declare it done. But we can also say that the present System was a step in the evolution. There is no strong argument it should be the last step.

We can define the Classic Oberon System as the one from NW website. One meg RAM, mono display, and SD card limited to 64 MB. Nice. Let it stay this way. It served its goal. But it needs not be the final goal forever. 

I am interested in a Portable Oberon System where all these limitations are lifted. The very definition of the Portable Oberon System is that it can be ported. Now, the more I look at the Classic details, the more obvious it becomes that a significant effort is needed on documentation, factoring out the literal numbers, and restructuring the System such that the portable and adjustable parts are separated from each other. 

> The first step in porting the system is: make the FPGA behave like the HW architecture as defined and documented by NW (His CPU, his 1MB memory layout with defined IO and framebuffer addresses.)

Yes, of course. Vedant is already running Astrobe on RiskFive. He is not far from running the Classic on RiskFive. I would love to see him running the Classic Oberon System there.

> AFTER you did that, you can take the second step and add new features to NW‘s machine like
> - adding more memory
> - adding color
> - adding Ethernet

Yes.

....
> In this second step you might need to adapt 1 to 2 modules. Mainly BootLoad.Mod to adapt the memory layout (In Kernel.Mod the „stackSize“ is hardcoded. 

This may be optimistic. As soon as we start adding truly new hardware like QSPI version of the SD card, there will be more changes. And how about having TWO SD cards rather than one? The whole Kernel will fall apart.

Note that two cards is a very reasonable feature. I want to have a separate System Disk which stays in place, and a possibly a much larger Data Disk where we will write the data files and take the disk for processing with a Windows PC. The Data Disk must use the full capacity. It will really help if the Data Disk is formatted with FAT32.

So if I look at fairly modest changes (a full size SD card with a universal FAT32, for example) then it is no longer a small set of changes. The System design needs to be reconsidered. 

> Unfortunately, Modules.Mod does not import stackSize from Kernel but hard codes it again😩)

We are in agreement. I noticed a few more such places. I am sure there are more. 

> In case of color graphics Display.Mod has to be adapted. I might be wrong but that’s it.

The current Display, even BW, can stay as is for quite a while. It is handy for software development. I think that the Display is one of the strongest assets of this System from the architecture standpoint. Changing its size or colors is not breaking the structure of the System. It means that Display is very well integrated.

The other changes which I indicated (FAT32, or two cards) are both causing the domino effect. It means that the file system is very deeply entrenched in the System design. Changing these parts will have a profound effect on the System structure.

Please feel free to question my assessment.

Thank you,
Wojtek

PS: I remoed the original post which was then massaged by the ProofPoint.