October 2014 - Oberon - mailman3.inf.ethz.ch

Error in http://www.ethoberon.ethz.ch/bootstrap.html ?
by peter＠easthope.ca 01 Nov '14

01 Nov '14

Hello again, http://www.ethoberon.ethz.ch/betadocu.html#PM states, "It is important that the four bytes at offset 1CH in sector 0 designate the sector number of the boot sector." That is consistent with installed systems. http://www.ethoberon.ethz.ch/bootstrap.html has this line. 001C 00000000 ;hidden sectors Not correct is it? Regards, ... Peter E. -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 12 Tel +1 360 639 0202 http://carnot.yi.org/ Bcc: peter at easthope. ca

2 1

Re: [Oberon] Oberon-1 or Oberon-2?
by Treutwein Bernhard 31 Oct '14

31 Oct '14

> But I fear that ETH is not interested in doing it as > the current professors have other topics of interest. > absolutely. Jürg Gutknecht retired this spring, and the native group boils down to Felix Friedrich ... -- Bernhard

2 1

Oberon System on the FPGA (was Oberon-1 or Oberon-2?)
by skulski＠pas.rochester.edu 31 Oct '14

31 Oct '14

Chris: > I am a software guy too, and seeing for example > a Banana Pi for less than $40 I don't get it. > Whats wrong with these boards? Nothing is wrong. Very nice boards for their purpose. However, we are not using these. So what are we using? Please have a look at our web page www.skutek.com. Please look at the photos of the boards that we have developed. It will become obvious why all these very nice little boards are not on our radar. > Where is the advantage of the FPGA approach. In a nutshell, the FPGA allows to build your own System On Chip (SoC) that can serve your application. Please have a look at the wonderful books by Pong P. Chu "Embedded SoPC Design with Nios II Processor". (There are two versions, one with Verilog and one with VHDL). In these books you will find how you can build your own SoC. Do you need to build your own SoC? If you are doing what we are doing then the answer is yes. In fact, every FPGA configuration, with a processor or without, is a SoC. I am now interested in adding a soft core to our designs. > Why? I really don't understand. From the recent discussion > here I remember the FPGA board used is out of production. There are other boards. It is a piece of cake to roll out your own board, at least with our kind of experience. > Replacement is not available with the same features. Nexys-4 has all the features. One can also design one's own board. > Ethernet or USB is not available and most likely never will. Nexys-4 has the Ethernet. There are tons of ways to connect the Ethernet PHY to the FPGA. We have done this and we achieved full GbE Ethernet wire speed with our custom firmware running UDP packets via Gigabit PHY. In fact, our next data acquisition project will be doing just that. So, never say never while talking to the HW person. We can do anything. The question is "can you program the hardware that we developed". In particular, "can anybody port the OP2 compiler to RISC5, or to make the Wirth compiler understand Oberon-2"? Regards, Wojtek

3 3

Re: [Oberon] Hardware versus software development.
by skulski＠pas.rochester.edu 31 Oct '14

31 Oct '14

Joerg: > I only wanted to say that we have to look at the overall cost > not only at the HW cost. I live in a country where a man hour > is expensive. Spending man hours to write a non-trivial driver > just to be cheap on the HW side might end up with a higher total cost. This is going to be an open-source, open-hardware project. The idea is that the community contributes their work for free. The HW cannot be free because the PCB, the assembly, and the parts must be paid off, plus some reasonable profit to pay back for ordering the parts etc. The HW is meant to enable the community contributors. Those, who want their time to be compensated, must look somewhere else. If this is well executed then it may eventually generate cash flow to those involved, in this way or another. There may be a commercial potential in this kind of projects, but one has to realize where it is hiding. I guess ETH never realized this part... Wojtek

1 0

Re: [Oberon] Hardware versus software development.
by skulski＠pas.rochester.edu 31 Oct '14

31 Oct '14

Jorg: > I love this kind of interaction. It shows that the way more HW related > people (you) and the way more SW related people (me) are thinking differ. Actually, I do both. My most successful project to date consisted of hardware data acquisition and signal processing software written in BlackBox. This experience motivates my insistence on the Oberon-2 because I know how much good SW is available on the CPC website. Having the Oberon-2 would make this SW pool more accessible. > - I say: The SW does it like that and HW has to adapt, without considering > the HW impact of my decision > - You say: we take this HW and the SW has to adapt, without considering > the SW impact your decision might have. Well, HW comes first in the sense that it really defines the reception. The board has to be inexpensive in the first place, and this is where the HW comes first. Take the LX9 packaging as an example. The TQ-144 cuts down on the prototyping cost because we can assemble the proto boards by hand. The end user can do the same. We can thus sell bare PCBs to those who want to cut the cost to the minimum at the expense of their own time. We can sell the PCBs plus the part kits. Or we can sell the assembled boards. Now take the FT256 package. You cannot solder this by any means, unless you are operating professional pick-and-place, the reflow oven, and you have access to the post-reflow X-ray machine. This translates into a huge difference in cost of short-series production runs. We know because we do it all the time. So we will settle on TQ-144. It means that Memory Control Blocks are not available. This determines which memory chips you can use, and which you cannot. The memory chips determine both the video timing and the Verilog that you will need to develop. At the very end you end up with the SW driver to use this entire chain of HW and FW blocks. Now consider the other way. If you start with SW requirements, which you can of course do, then it will determine the amount of memory, the video speed, and so forth. OK, it implies which HW chips you can use and the pin count. This will define the FPGA package. This in turn will tell how many PCB layers, and which assembling technology you must use. It will determine the cost, which can become unacceptable for short series production. My obvious thought is that the entry level board cannot be too ambitious because it must be inexpensive. Having quite extensive experience with board design and part selection, I narrowed down the parts. The choices are very limited. Did I mention that the parts must not only be gull-wing, but they also must be in-stock? You must be able to buy the chips. This latter requirement is highly nontrivial. There are tons of catalog parts that you either cannot buy, or you must buy in full rolls of say 1,000 chips. These are again unacceptable in prototype environment. So the HW design of the entry-level board is in fact rigidly determined by the assembly cost and part availability. You need to be a practicing HW developer to appreciate how little space is left for HW maneuvers. > A word on SRAM: At first view, the kickstarter project > "Papilio Duo" looked promising to me as it was using SRAM > rather than SDRAM. But we would have to adopt the Verilog > memory driver quite a bit to emulate the 32bit access of RISC5. Papilio Duo is very nice. The problem with their design is that the video timing may be hard to meet, esp. if you want to add color which will triple the required memory bandwidth. I certainly want to use the 32-bit memory bus. It will eat a lot of pins, but I do not want to limit the video to just black-and-white. Wojtek

3 2

Re: [Oberon] Hardware versus software development.
by skulski＠pas.rochester.edu 31 Oct '14

31 Oct '14

Jorg: > I know. I had the following step-by-step approach in mind > 1) - try to find another board, possibly with more memory for future use Did I not say that I am working on designing the board? I do not want to set a firm deadline because I have a few urgent projects to complete before rolling out the new board. Basically, I have one of my previous designs that I want to adopt. It will be an entry-level board targeting the Oberon System development. In order to keep the cost down I will use Spartan-6 LX9. More powerful boards may follow later. I have plans how these should look like, but no firm commitment to develop these. > - port the Verilog code to the new board. > - whole Oberon system stays untouched > 2) introduce color > - SW decision (Oberon) > Assuming I have one bit per R-G-B: > How do I represent the color in the > framebuffer? RGB in 3 separate planes or RGB > as 3 consecutive bits. This is secondary because HW can route bits. I was thinking of PWM modulation, which is a cheap but not a very good solution. The image may get blurred. Nexys is using a R-2R resistor ladder. There are DACs on the market that are pretty easy to use. So there are different ways. Also, a more modern solution would be an HDMI chip. These decisions will be driven by hardware cost and complexity, while the SW will adopt. > - HW decision (Verlog) > There, I have to decide with RISC5 or with RISC6. > RISC5: I stay with 1 GB, I allocate more memory to video, > and have less for code, heap and stack. In the entry-level board I want to use the SRAM chips. This is due to the pin count that the LX9 has in the TQ-144. In future designs the video memory needs to get physically separated. Video has stringent timing requirements, while the program/data memory has a more relaxed timing. A good video solution is BRAM, but there is never enough of it. > RISC6: increase address bus by 1 and hence add another 1GB The advanced boards will use DDR3 chips which are cheap. Then the RISC processor can be adopted to the required address size. BTW, I have a better name for the CPU than RISC which is too generic, but I am afraid of N.Wirth reaction to changing his beloved names. Wojtek

2 1

Re: [Oberon] Oberon-1 or Oberon-2?
by "ɹǝzıuıʇnɹɔs ǝoɾ" 31 Oct '14

31 Oct '14

On 31/10/14 12:00, oberon-request(a)lists.inf.ethz.ch wrote: > Date: Thu, 30 Oct 2014 20:06:36 -0400 > From: skulski(a)pas.rochester.edu > Subject: Re: [Oberon] Oberon-1 or Oberon-2? > The progress must consist of single steps. I posed a question of getting > Oberon-2 to work on the new Oberon System 2013. The HW is a separate > question that needs a separate effort. Two steps, one at a time. the task is to compile an OP2 on risc5 with oberon-7 compiler and make it emit risc5 code: 1. select a suitable [Enhanced] OP2/backend (sparc, pa-risc, or powerPC?) OP2 is written in oberon[-1]. to change the source from oberon to oberon-07 is trivial according to NW's experience modifying his oberon-07 compiler from o-1 to o-7. 2. modify OP2 to emit risc5 code, taking code-gen samples from the o-7 compiler. 3. extend OP2 front (and back)-end with o-7 extensions (I forgot which — for low-level programming) rewards: complete code base of V4 would compile on riscv (given enough main memory) — if the V4 api is same as on risc5 oberon system. have I forgotten something?

1 0

Re: [Oberon] Oberon-1 or Oberon-2?
by skulski＠pas.rochester.edu 31 Oct '14

31 Oct '14

> Date: Wed, 29 Oct 2014 18:09:56 +0100 > From: Joerg <joerg.straube(a)iaeth.ch> > Subject: Re: [Oberon] Oberon-1 or Oberon-2? > The whole idea of the RISC5 project was to dismiss > this HW/SW discussion and demonstrate how a complete > computer system works from A to Z: It needs a > programming language, it needs a compiler, > it needs an operating system with > its HW drivers and it needs HW. The HW/SW discussion has not been dismissed, because you still need a board. The FPGA needs power, the configuration memory, and a few other things. As this discussion shows, these details are not quite familiar to the softies. So the discussion persits, though at a new level. To put it succintly, the Project Oberon 2013 demonstrated, how to build a System On Chip (SoC) under the assumption that the chip is properly powered up. It did not demonstrate, how to build a complete system that also comprises a working board. The latter is where the HW skills are still needed. > Adapting an existing compiler to generate RISC5 code > could be a nice semester work or so. Developing an FPGA board is about the same amount of work. So we are talking of two pieces of cake about the size of one semester each. > But I'm with Chris: Project Oberon is a great achievement > for education. I would wish there is an active community > taking care of this project and adding things to it >(like Chris mentioned eg. Ethernet). In its current > state it's too simplistic and I guess will not find > a lot of friends :-( The progress must consist of single steps. I posed a question of getting Oberon-2 to work on the new Oberon System 2013. The HW is a separate question that needs a separate effort. Two steps, one at a time. Wojtek

3 4

Re (2): NO qemu
by peter＠easthope.ca 30 Oct '14

30 Oct '14

From: peter at easthope.ca (peter at easthope.ca) Date: Tue, 28 Oct 2014 10:32:52 -0700 > Instructions for installing NO using qemu > and then booting it natively are now in the wiki. > http://www.ocp.inf.ethz.ch/wiki/Documentation/Installation#toc23 The procedure doesn't work properly yet and I've noted that. For testing, a qemu installed system is in /dev/sda5 and a diskette installed system is in /dev/sda6. sda6 boots as it should and sda5 comes to OBE and stops. According to http://www.ethoberon.ethz.ch/newfaq.html#hangOBE "... the second block of the OBL boot loader did not load correctly. " "dhex /dev/sda5 /dev/sda6" shows that the first 40 bytes from sda{5,6} match. Then, there are few matches until offset 800. From 800 onward, the two devices match again, except for three specific differences. Why do Oberon0 under QEMU and Oberon0 from a diskette install two different boot loaders? Have I overlooked an option for QEMU? Thanks for any ideas, ... Peter E. -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 12 Tel +1 360 639 0202 http://carnot.yi.org/ Bcc: peter at easthope. ca

2 1

Re: [Oberon] Oberon-1 or Oberon-2? (eas lab)
by skulski＠pas.rochester.edu 30 Oct '14

30 Oct '14

Chris: > I supose: > = all x86:win7 programs run on 64BitWinTel ? The rule is "all except the one that you need the most". For example, coLinux runs on 32-bit Win7, but not on 64-bit Win7. I know that coLinux is special, but then every nontrivial program can be special. One has to check whether "the program that one needs the most" runs or not. I was pleased to find that Oberon System behaves itself. > Hasn't it got the V4:compiler [with it's *.Mod] included? Yes, but that was not my question. I would like to see one of the mature Oberon Systems running on the RISC5. There are pieces of the mature Systems, like Kepler, which would not compile. Do we need Kepler? Perhaps we can live without it. Can we live without HTTP, web integration, and all the contributions that Linz has made? Sure we can. But this makes absolutely no sense, if one wants to take N.Wirth work as a basis for a serious project. We just need a solid starting base. Linz V4 is such a base. Hence, I am asking how far we are from being able to compile Linz V4 for RISC5? I emphasize Linz V4 because in my experience it has always been very solid and stable. System 3 is visionary and therefore a bit perplexing to use. But in fact both should be able to run on RISC5. Is it now more clear what I am trying to convey? Regards, Wojtek

1 0