[Oberon] FPGA - Boot over serial line

[Andreas Pirklbauer]

> On Fri Oct 13 16:09:17 CEST 2017 Tomas Kral wrote:
>
> I have coded simplified `ORX.WriteFile’ in
> shell for the host computer. It does not do
> all it should, but I hope carries the idea?
>
> #!/bin/sh
> # ORX.WriteFile
>
> i=0; echo -n > prom.mem
> while read hex; do
>   echo $hex >> prom.mem
>   i=$((i+1))
> done < prom0.mem
> j=$i; while [ $j -lt 512 ]; do
>   echo 00000000 >> prom.mem
>   j=$((j+1))
> done
>

I added a command Builder.WriteFile to the building tools:

  www.github.com/andreaspirklbauer/Oberon-building-tools

It *should* do what the above script does. However I have
no way of testing as I don’t have an FPGA board with me.
I wrote it “blind” so to speak..
 
Could you please check (and adjust the code if needed)? Any
changes needed in order to comply with the Xilinx file format
requirements for the PROM file should be rather easy to make.

-AP


Comments:
~~~~~~~~~

1. The command Builder.WriteFile can be invoked as follows

     ORP.Compile BootLoad.Mod ~
     Builder.WriteFile BootLoad.rsc 512 prom.mem ~

2. The command Builder.WriteFile extracts the code block
   from the specified object file (BootLoad.rsc) and
   transfers it into a text file (prom.mem), where for
   each 4-byte opcode encountered in the code block,
   an 8-digit hex code is written to the output file,
   with one per line, with a CR + LF added at the end
   of each line, and zero-filled to the specified size:

     E7000151  (line 0)
     00000000
     ...
     4EE90014
     AFE00000
     40000004
     ...
     00000000
     00000000  (line 511)

3. Currently ONLY the *code* section (mod.code) is
   extracted from the object file (BootLoad.rsc) and
   written out as a sequence of 8-digit hex codes to
   to the output file.

   This means that if the source code is compiled with
   the RISC0 option (i.e. with an asterisk immediately
   after the key word MODULE), the very first opcode
   in the generated PROM file is the branch instruction
   to the module initialization sequence generated
   with the compiler is invoked with the RISC0 option.

4. The *data* section (mod.data) containing the space
   for holding the type descriptors, variables and
   strings (see ch. 6.2 on p.80ff of the book Project
   Oberon 2013) is currently NOT written as hex codes
   to the PROM file. This is in order to keep the
   branch instruction (see 4.) at the beginning of the
   generated PROM file.

   But it also means that type descriptors for declared
   named record types (one type descriptor per record
   type is generated by the compiler) are not available,
   so for example type tests cannot be performed)

   It also means that there should be enough space
   in memory right before the location where the PROM
   file is loaded by fpgaprog.

   Note: If one wanted to make the *data* section part
   of the PROM file, this COULD of course be done. One
   would only need to prefix it with the same branch
   instruction as the one at the beginning of the
   code section. But is it needed?

5. The *meta* data section (mod.imp, mod.cmd, mod.ent,
   mod.ptr) are currently also NOT written to the PROM
   file, as these are not needed (standalone procedures
   cannot import modules, and there is also no module
   loader and no command interpreter present when a
   program runs on the bare metal)

6. The module descriptor (mod) itself containing
   pointers to the various sections in the module
   block is also not transferred to the PROM file.


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