[Oberon] Re. Active Oberon on ARM CPUs

[Bernhard Egger]

> Sven Stauber wrote To: <oberon at lists.inf.ethz.ch>:
>> In about two weeks, I'm going to work again on a project which uses the 
>> ARM version of AOS. At that time, I will provide an image that runs on 
>> XScale PXA25x/PXA26x CPUs (maybe also others, I'm not sure) and the 
>> corresponding sources for those who are interested. I'm going to 
>> announce the availability of these files on this list.
> 
> Yes very interested, but this would be a much bigger task than porting
> ETH-oberon or AOS to a standard PC.

AOS/Bluebottle on ARM has existed for almost 6 years now as I have originally
ported the (x86) AOS to a DNARD computer with a StrongARM processor. If you're
interested, here's a link to my thesis and the sources:
  http://aces.snu.ac.kr/~bernhard/bluebottle/armaos/01.ETH.Egger.ARMAos.pdf
  http://aces.snu.ac.kr/~bernhard/bluebottle/armaos/ARMRelease.zip

The release also includes the ARM backend for Paco.

The DNARD has a OpenFirmware that Aos relies on to detect devices, switch video
modes, etc, so that release will not work 1:1 on a standard ARM board.
I've ported the initial ARM Aos for the DNARD to a simple ARM-based board with
flash memory, video output and Bluetooth. You can download the modified bootup
code/kernel for this version here
  http://aces.snu.ac.kr/~bernhard/bluebottle/armaos/wear.AosSysSrc.zip

The code generated by the Paco's ARM backed will run on any ARM architecture >=v4.

> Since I've resisted examining the [family of] ARM CPU[s] architecture,
> I don't even know how/where a boot/reset code would run.
It's stored in flash memory that is mapped into the memory address space at
0x00000000. ARM CPUs start executing from there when powered up.

> Apart from any AOS considerations, where would one get 
> documentation for the boot/load method.  Which I'd want
> to test, in a minimum way first.
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)

Since I have left, ETH has been working on new ARM-based projects, so you might
want to wait for Sven's release. However, since documenting stuff is not one of
the strong sides of us, you might wanna have a look at my diploma thesis to get
an idea what's going on.

If you have any questions, I'll be happy to answer them.

Hope that helps,
Bernhard