[Oberon] FPGA Oberon - Modules.rsc

Wed Mar 22 17:19:24 CET 2017

Thomas,

see the answers inline below.

  > thomas.kral at email.cz thomas.kral at email.cz Wed Mar 22 15:40:42 CET 2017

  > In the chapter 14.2 it hints that linker is almost identical to `Modules.
  > Mod' loader, except it links statically into a file, rather than into memory.

The linker referred to in the book "Project Oberon" is called ORL.Mod. It corresponds to module Linker.Mod in the repository https://github.com/andreaspirklbauer/Oberon-building-tools <https://github.com/andreaspirklbauer/Oberon-building-tools>. I don’t have access to the source code of ORL.Mod, but from the description in the book, it looks like ORL.Link is doing pretty much what Linker.Link does.

If you have a quick glance at the source code of Linker.Mod, you will see that it *is* in fact the Oberon 2013 module loader (i.e. Modules.Load renamed to Linker.Link), line for line - with the *one* important difference that it writes the “loaded” modules into a separate memory area first (instead of modifying the “official” module area itself) and then, at the very end of the linking process, simply writes that area byte for byte to the specified output file. That’s all there is too it — the regular Oberon 2013 module loader, where however the output is written to a file.

   >Addresses are relocated with origin 0H, from a fixed start of Oberon partition?

During the regular Oberon boot process, the regular Oberon boot file (containing the pre-linked binary of the 4 modules of the Oberon inner core, i.e. modules Kernel, FileDir, Files and Kernel) is loaded from the so-called “boot area” of the local disk. In Oberon 2013, the boot area is located in sectors 2-63 of the disk. Looking at the source code of Builder.Load, you can indeed see that it literally overwrites exactly those sectors with the inner core, byte for byte. Then, during the system boot process, the boot loader (BootLoad.Mod) merely reads those sectors from disk and transfers their content byte for byte into main memory, starting at location 0. The number of bytes to be read is extracted from location 16 of the boot file itself (see source code of BootLoad.LoadFromDisk which is less than half a dozen lines of code).

Note that the *format* of the Oberon boot file, as transferred into main memory by the boot loader from the boot area of the disk, is *defined* to *exactly* mirror the standard Oberon storage layout, starting at location 0 (See chapter 8.1, page 103, of the book Project Oberon, 2013 Edition, for a detailed description of Oberon’s storage layout). The boot file is *created* this way by Linker.Mod (see Linker.Link, towards the end). In particular, location 0 in the boot file (and later in main memory once it has been loaded) contains a branch instruction to the initialization sequence of the top module of the boot file (i.e. module Modules). 

Thus, the boot loader (BootLoad.Mod) can simply transfer the boot file byte for byte from the boot area (sectors 2-63) to main memory location 0 during the regular Oberon boot process, and then branch to location 0 – which is *precisely* what it does. And this is why BootLoad.Mod is so simple: just a few lines of code.

   > I also found found some  boot linking modules in native oberon souce files.

   > ./src/x86/Unix/BootLinker.Mod

   > ./src/NO/BootLinker.Mod

  > Was I close?

Those are quite similar indeed. These files come from older implementations. I am not using those.

The file Linker.Mod that you will find in the repository https://github.com/andreaspirklbauer/Oberon-building-tools <https://github.com/andreaspirklbauer/Oberon-building-tools> has the nice property that it behaves *exactly* like the regular Oberon *2013* module loader (Modules.Load) - because, well, it *is* in fact the module loader, with the one small modification outlined above. So, by keeping the above repository in sync with the official version of the Oberon 2013 module loader, it is *guaranteed* to work with the latest version(s) of Oberon 2013. 

  > What would be also  interesting to decompose `prom.mem' to understand how this file could be produced.

  > It seems to have 361 lines each ascii encoded long word. Ends with C7000000, lines 362-490 are zeros. 
  > Are these RISC machine instructions?

The file prom.mem file looks like it is, in essence, the boot loader (think: "BootLoad.rsc re-packaged"). If that is the case, it is supposed to be produced by the command:

  Builder.WriteFile BootLoad.rsc 512 prom.mem

However, I just haven’t gotten around to implement it - first, because I don’t have the specific hardware to test it . . . and second, because I don’t need it. I already *have* a working prom.mem which I don’t intend, nor have any reason, to change. As outlined in the README file of the above repository, there usually is no need to change the boot loader itself.

But - in case you intend to implement it - all this command does needs to do is take the binary file for the boot loader (BootLoad.rsc - as generated by the regular Oberon compiler, see the README file for the details), copy it byte for byte to the file “prom.mem", and add a few additional bits of information around it, so that it is compatible with the specific hardware used (e.g. Xilinx FPGA board). For that, one probably needs to read some Xilinx documentation I suppose.

PS: Note that Builder.WriteFile corresponds to ORX.WriteFile, but I don’t have the source code of module ORX.Mod either. But the creator of the file prom.mem certainly does. That would be the file you’d need to get. 

   > Many thanks

   > Tomas 

---------- Původní zpráva ----------
Od: Andreas Pirklbauer <andreas_pirklbauer at yahoo.com <https://lists.inf.ethz.ch/mailman/listinfo/oberon>>
Komu: ETH Oberon and related systems <oberon at lists.inf.ethz.ch <https://lists.inf.ethz.ch/mailman/listinfo/oberon>>
Datum: 22. 3. 2017 11:36:35
Předmět: [Oberon] FPGA Oberon - Modules.rsc

"

The book Project Oberon does not describe the way the inner core itself is built (it only mentions that a “boot linker”is needed for that) or loaded onto the boot area of the local disk, nor are the tools to accomplish this published.

<br>

A minimal set of the Oberon building tools can be found at:

<br>

<span style='white-space:pre-wrap'><a href='https://github.com/andreaspirklbauer/Oberon-building-tools <https://github.com/andreaspirklbauer/Oberon-building-tools>'>https://github.com/andreaspirklbauer/Oberon-building-tools</a <https://github.com/andreaspirklbauer/Oberon-building-tools%3C/a>></span>

<span style='white-space:pre-wrap'><br></span>

<span style='white-space:pre-wrap'>Usage:</span>

<span style='white-space:pre-wrap'><br></span>

<span style='white-space:pre-wrap'>   ORP.Compile Kernel.Mod FileDir.Mod Files.Mod Modules.Mod ~</span>

<span style='white-space:pre-wrap'><br></span>

<span style='white-space:pre-wrap'>   Linker.Link Modules    # prepare inner core (pre-linked binary)</span>

<span style='white-space:pre-wrap'><br></span>

<span style='white-space:pre-wrap'>   Builder.Build Modules  # load inner core into boot area of disk</span>

<br>

<br>

---------------------------------------------------------
thomas.kral at email.cz thomas.kral at email.cz 
Tue Mar 21 09:13:34 CET 2017

Hi Joerg,
I was rereading the chapter 14 again, I realise the boot over RS232 is 
triggered by a switch, but I still do miss the point, how do I build the 
inner core, and Oberon0. In the text there is a reference to boot linker. 

Many thanks

Tomas 

---------- Původní zpráva ----------
Od: Jörg <<a href='https://lists.inf.ethz.ch/mailman/listinfo/oberon <https://lists.inf.ethz.ch/mailman/listinfo/oberon>'>joerg.straube at iaeth.ch</a>>
Komu: ETH Oberon and related systems <<a href='https://lists.inf.ethz.ch/mailman/listinfo/oberon <https://lists.inf.ethz.ch/mailman/listinfo/oberon>'>oberon at lists.inf.ethz.ch</a>>
Datum: 21. 3. 2017 8:06:54
Předmět: Re: [Oberon] FPGA Oberon - Modules.rsc

"

The inner core is at a fixed location on the disk.

The boot process is described in chapter 14.1:

<a href='https://www.inf.ethz.ch/personal/wirth/ProjectOberon/PO.Applications.pdf <https://www.inf.ethz.ch/personal/wirth/ProjectOberon/PO.Applications.pdf>'>https://www.inf.ethz.ch/personal/wirth/ProjectOberon/PO.Applications.pdf</a <https://www.inf.ethz.ch/personal/wirth/ProjectOberon/PO.Applications.pdf%3C/a>>
(<a href='https://www.inf.ethz.ch/personal/wirth/ProjectOberon/PO.Applications.pdf <https://www.inf.ethz.ch/personal/wirth/ProjectOberon/PO.Applications.pdf>'>https://www.inf.ethz.ch/personal/wirth/ProjectOberon/PO.Applications.pdf</a <https://www.inf.ethz.ch/personal/wirth/ProjectOberon/PO.Applications.pdf%3C/a>>)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20170322/d3570936/attachment.html>