[Oberon] RiskFive; was Oberon on ULX3S explanation
skulski at pas.rochester.edu
Wed Nov 13 20:32:21 CET 2019
thank you for asking. RiskFive is low priority because it is at the sidelines of our funded work. Vedant is using one of these boards and I have four more piled on my desk. As of now Vedant has implemented Wiznet W5500 and he is now working on W5300. All this work was MicroBlaze and C because he is following Pong P. Chu firmware. My tentative plan is to let him complete this work, after which one of us will wrap RISC5 the same way as the MicroBlaze Controller System (MCS) from Xilinx. If RISC5 becomes a drop-in replacement for the MCS, then all the other firmware can stay in place.
Implementing the W5300 reqired changing the address map from Pong P. Chu to wider address chunks per module, because PP.Chu provides for only 32 memory locations, while W5300 needs 32 kB. This is a minor change, which is greatly facilitated by the modular structure of P.P.Chu bus. Interestingly enough, NW/PR bus is basically the same as the P.P.Chu bus, but it is documented in a different way. It turns out that the "bus" does not really exist inside the FPGA. All that exists is its documentation. You can read the WishBone document where they clearly say that WishBone is a specification rather than a firmware component. Much the same is true about NW/PR, P.P.Chu, and other such buses. I tentatively decided to adopt FPro by P.P.Chu because it is both simple and extensively documented. After changing the memory map we will rename it to SPro to avoid confusion with his FPro specs.
All this is firmware. My aim is development of a firmware framework with larger memory address range per chunk than FPro is providing, and then adopting P.P.Chu components to build a system on chip for our needs. Part of this work which of general interest can be open sourced, after writing and releasing sufficient documentation.
I reviewed the current Oberon System software from the point of view of porting it to a future SoC. I found that the low level modules such as Kernel, Display, Files,
or a boot loader, will all need to be factored into a low level driver layer with the HW addresses, and the upper layer without. This is perhaps stated in the NW book, but this book does not accurately describe the Oberon System reality. In reality there are numbers literally hardcoded inside the modules in more than one place. For example, at the end of the BootLoader, the locations 12 and 24 are loaded with values. Now imagine porting this software to another SoC. How do you make sure that these values are properly interfaced with hardware if it is not clear what is going on. It happens in many places in the low level drivers.
My favorite lines of code in Modules.Mod are:
mno := inst DIV 100000H MOD 10H;
pno := inst DIV 1000H MOD 100H;
disp := inst MOD 1000H;
SYSTEM.PUT(adr, (offset MOD 1000000H) + 0F7000000H);
Now imagine porting such undocumented code to range of different SoCs with different memory arrangements. It looks like a recipe for a disaster to me. It will be necessary to rewrite portions of low-level Oberon System code to factor out such pieces, before porting the system to other boards which are substantially different from the present boards. Documentation will be crucial. None of such literal values should be allowed in the portable code without extensive comments describing the mechanics. Such structural fixes would be needed before this software is portable to a different SoC.
It would be helpful if this community formed a task force to start modernizing the FPGA Oberon System. The first modest task of the task force could be commenting and documenting the low level code, as well as moving all the hardcoded locations into the definition module SysDef.Mod corresponding to the firmware memory locations. (Consult the P.P.Chu book where he is doing exactly that.)
Forming a task force could be contrary to the culture of this group. We seem to be very individualistic. And we do not seem to have a clear common goal.
I can circulate a draft review of the low level Oberon System if there is interest.
Thank you again for asking. And I want to profusely apologize to anyone who could read this e-mail as being unduly critical.
From: Oberon [oberon-bounces at lists.inf.ethz.ch] on behalf of peter at easthope.ca [peter at easthope.ca]
Sent: Wednesday, November 13, 2019 12:55 PM
To: oberon at lists.inf.ethz.ch
Subject: [Oberon] RiskFive; was Oberon on ULX3S explanation
is RiskFive still viable? The last news on your site is 2018,
November. Not criticizing; just wondering.
Thanks ... L.
More information about the Oberon