[Oberon] FPGA - Boot over serial line
andreas_pirklbauer at yahoo.com
Sat Oct 14 14:49:27 CEST 2017
> 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?
> # ORX.WriteFile
> i=0; echo -n > prom.mem
> while read hex; do
> echo $hex >> prom.mem
> done < prom0.mem
> j=$i; while [ $j -lt 512 ]; do
> echo 00000000 >> prom.mem
I added a command Builder.WriteFile to the 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.
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 (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...
More information about the Oberon