[Oberon] Re: Active Oberon on ARM CPUs

[Bernhard Egger]

>>   http://aces.snu.ac.kr/~bernhard/bluebottle/armaos/01.ETH.Egger.ARMAos.pdf
>>   http://aces.snu.ac.kr/~bernhard/bluebottle/armaos/ARMRelease.zip
>>
> Presently under linux, ARMRelease.zip tells:  Archive:  a.zip
>   End-of-central-directory signature not found.  Either this file is not
>   a zipfile, or it constitutes one disk of a multi-part archive.  In the
>   latter case the central directory and zipfile comment will be found on
>   the last disk(s) of this archive.
I've just downloaded the file from the link provided above and unzipped it
without any problems. I suggest you download the file again.
Here's the MD5 sum:
  egger at r2d2 ~/scratch/test $ md5sum ARMRelease.zip
  872b0fd2f2bc61577c1b5b9645d34ab0  ARMRelease.zip


> I don't know what hardware to get.
> I'd want to take a successive refinement approach, eg.:
> - hex code a minimal loop which confirms eg. that input to port1 is echoed out to port2
> - perhaps confirm that the ample linux/gcc tools can produce something
> - and only then start building minimal AOS 'confirmatory utilities' and documenting
>   them for use of later collaborators.
you'll need a standard ARM (developer) board. More advanced boards come with a
boot loader (e.g. redboot) that loads a minimal runtime environment with which
you can download your binaries with TFTP over TCP/IP, for example. If you want
to run AOS natively on that board, your boot up code will have to kill the
runtime environment and take control of the MMU, etc itself.
Simpler boards do not contain a boot loader. They simply boot from the internal
flash. In this case, you can burn your image to the flash using the JTAG interface.
Both have advantages and disadvantages. The advanced boards with a boot loader
initialize the memory timing registers, serial port, etc. and you can easily
download and execute code. However, booting into AOS will be harder because you
first have to kill the boot loader, turn off the MMU, and only then you can
start executing the AOS kernel.
The simpler boards are easier to boot from because the CPU will start executing
at address 0x00000000 in a well-defined state, but downloading the images is not
that easy and rather slow. Furthermore, if your code crashes before you have
initialized the serial port, it is quite hard to find the problem.
The best approach is probably to start with a board with a boot loader, develop
a working AOS system and then replace the boot loader with an AOS boot loader.

>> I suggest you have a look at the bootup code in wear.AosSysSrc.zip, specifically
>> wearARM.Relocator.Mod and ARM.AosBoot.Mod. Those are the two modules that bring
>> the board into a specific state. The kernel above is +/- the same for all boards
>> (except device drivers, of course)
> 
> Are these files in the ARMRelease.zip ?
yes. ARM.Relocator.Mod and ARM.AosBoot.Mod can be found in ARM.AosSrc1.zip:
  egger at r2d2 ~/scratch/test/ARMRelease $ unzip -l ARM.AosSrc1.zip | \
                                            grep -iE "(relocator|aosboot)\.mod"
    31564  08-15-01 14:29   ARM.Relocator.Mod
    17522  08-02-01 18:53   ARM.AosBoot.Mod

This is the boot up code for the DNARD computer with its OpenFirmware. If you
have a standard ARM board without such an advanced boot loader, the files in
wear.AosSysSrc.zip might be more useful to you (wearARM.Relocator.Mod and
ARM.AosBoot.Mod)

Here's the MD5 sum for wear.AosSysSrc.zip:
  egger at r2d2 ~/scratch/test $ md5sum wear.AosSysSrc.zip
  3369c7e229c48f8be7771f3fb1527c17  wear.AosSysSrc.zip

cheers,
Bernhard