Dear Bernhard There is a misunderstanding: the build server provides only the test that all systems can be successfully built (compiled + linked), it is not a service that provides downloadable, bootable images. Sorry for the confusion. Kind regards Felix

Dear Felix,

thanks a lot for the update.

Just curious:

You write: "[...] and a link to a build server can be found via http://a2.inf.ethz.ch"

Visiting the build server and checking for the Bios32 build, I find that it succeeds at http://builds.cas.inf.ethz.ch/A2+Builds/Bios32/ but there is no downloadable image.

Is this intentionally or am I just too ignorant and I don't find the link? -- Bernhard

...

-----Original Message----- From: Felix Friedrich [mailto:felix.friedrich@inf.ethz.ch] Sent: Wednesday, June 05, 2019 10:10 AM To: ETH Oberon and related systems Subject: [Oberon] A2 repository

Dear all

for security reasons, a few weeks back ETH has abandoned the permanent ETH guest accounts that we had used in order to grant everyone access to the A2 repository.

Fortunately, we now have an alternative. We have set up the a2 repository including a tiny website and a new issue tracker.

The repository, the issue tracker and a link to a build server can be found via http://a2.inf.ethz.ch

Kind regards

Felix Friedrich

-- Dr. Felix Friedrich, Lecturer Department of Computer Science ETH Zurich, UNG F 14 Universitätsstr. 19 8092 Zurich, Switzerland tel.: +41 44 632 8312

Am 05.06.2019 um 22:56 schrieb Michael Schierl:

Yes, I tried that one, and I also tried adding --platform=Bios32 (and --extension=.Gof), but the resulting images (I used the Virtualbox ones) do not boot - last line is "OBERON loading" and then the screen remains unchanged.

Now I also tried again building 2353b6eb64256dfa1373126ba209bb417401ff81 (r8817) but the resulting images (after I increase the partition size since extracting the .ZIP files always trapped for me) act the same.

Same result when trying r8022. Also serial trace does not output anything. I then started bisecting from the "last known good build" r6498 and "first known bad build" r8022, and the latest build (of the ones chosen by git bisect) that I got to compile and boot was r7366. I used WinAOS 32-bit for building (as I could not get any other version to start on this old revision) and had to remove the second reference to Oberon.Display.Mod in Release.Tool. When trying the same on the next revision (r7367, <https://github.com/metacore/A2OS/commit/0dc3648ec67f89205519d3a06a4101920bfadb97>) the system reboots immediately, and assuming that I can trust the VirtualBox log, it is due to a triple fault. Behaviour is the same up to at least r7375. When taking r7367 and using Heaps.Mod from r7366 (plus adding an empty CheckAssignment* implementation), the system boots again. So, the triple fault is likely caused by a change in Heaps.Mod. Observations about some other revisions I tried during bisecting: r7387 compiles (after removing second Oberon.Display.Mod again) but immediately freezes when booting (no triple fault). When using Heaps.Mod from r7366 (plus adding NgcSweeps variable), the system boots again. For r7409/r7412/r7461 there were many compile time errors I was not quickly able to fix. For r7641/r7748 (yay, somebody removed the double Oberon.Display.Mod!), compilation failed due to Trace.Int not able to link against runtime intrinsics for doing DIV/MOD on HUGEINT, so I patched it to only output LONGINT values. Yet no way for me to get it to boot. So I guess, the next step would be to do another bisecting round to figure out where between r7387 and r7409 the compile time errors got introduced (and how to best fix/workaround them). Another route would be to have a closer look at the Heaps.Mod changes in r7367 and try to partially revert them to find out which change exactly caused the break. This might bring greater insights but be not the fastest way of getting to a recent build that works (as the error might have been fixed in a future version already, which I could not test due to the compile time errors). Of course, if anyone has a better idea, I'm all ears. Regards, Michael

Hello, Am 20.06.2019 um 23:25 schrieb Michael Schierl:

When taking r7367 and using Heaps.Mod from r7366 (plus adding an empty CheckAssignment* implementation), the system boots again. So, the triple fault is likely caused by a change in Heaps.Mod.

After some more investigation, it is only indirectly the case. The culprit is the variable "cardSet" introduced here: <https://github.com/metacore/A2OS/commit/0dc3648ec67f89205519d3a06a4101920bfadb97#diff-9b871273cc2a9acefd2d27c4ffe3bdf4R323> As a consequence, the size of the linked images increases by 128KB, and since the default OBL.Bin loader tries to load the linked image into conventional memory (640K ought to be enough for anybody), the image just got too large.

For r7409/r7412/r7461 there were many compile time errors I was not quickly able to fix.

Reason here was the change in <https://github.com/metacore/A2OS/commit/b4617815d2c3b7d5ff7550baafe43d46f7bede9b#diff-3252168e91a62b6afaa2443658b703a7R1187> that changed the namespaces to be separated by dashes instead of dots. I am unsure why this broke the Bios32 build but not the WinAOS build, but since this got fixed some revisions later, probably it is not important anyway. Anyway, when reverting this change (and also reverting the change how GetModuleSegmentedName is built), these versions compile and run again, too. Coming back to our main goal of recompiling a recent A2 version: The linked image of recent versions is a bit over 800KB, so I assume it is unrealistic to get this stripped (without breaking the system) to fit within 640KB. There seems to be a second Boot loader (OBLUnreal.Bin) available, which supposedly tries to avoid this limitation by switching to "Unreal mode" (also known as flat memory segment hack) and loading the image into extended memory instead. However, I was not able to make this bootloader boot (on VirtualBox, at least), neither when using a current version of A2 nor when using an old version that still boots fine with OBL.Bin. So I guess, to wrap this up, the issue with recent A2 native builds is that the linked image got too large for being loaded with OBL.Bin, and the alternative OBLUnreal.Bin does not work (on all hardware where OBL.Bin worked). Probably one could spend a lot of time finding the latest version that can get stripped down to fit into conventional memory, but I don't see a point in doing that myself. Other solutions could be to either implement a self-decompressing image (so it can be loaded with original OBL.bin; but even that might be "not enough" at some point) or add support for creating Multiboot or Multiboot2 images (and load them with a Multiboot-supporting bootloader, like SYSLINUX, ISOLINUX, PXELINUX or GRUB; disadvantage being that it is no longer possible to install A2 to an empty hard disk just from within A2). But both of them are a lot more work than I'd like to spend on this (side-)project. So I will stop my A2 endeavors here - since I also noticed that OberonGadgets apparently disappeared from later A2 versions, I'd probably stick with earlier versions anyway :D Regards, Michael

Dear Bernhard, all We are currently investing effort into cleaning up A2 (portability ...) and making it usable as a system with soft real-time guarantees. You probably know that Oberon and A2 featured a stop-the-world garbage collector that became more and more of an issue with larger projects. After having made various experiments with generational collectors (--> cardSet...) , we now have a reasonably simple concurrent GC. For processes that do not allocate memory, we have extremely short stopping times now. Such experiments can best be carried out with A2 being run on top of another OS (such as Linux or Windows). But we will make sure that native versions are properly supported again. It just takes time because our resources are very limited. We still teach Oberon in a course called "System Construction" at ETH and we always use the latest versions of A2 for development and implementation. This implies that we need to finish this work before October. Kind regards Felix PS: Oberon and Gadgets did not disappear from A2. Only the native build excludes the respective packages in order to keep the system minimal.

Dear Michael,

thanks for the invested time and work although the results are quite a bit disappointing.

@Felix: Any chances for recovery?

Regards -- Bernhard

...

-----Original Message----- From: Michael Schierl [mailto:schierlm@gmx.de] Sent: Saturday, June 29, 2019 10:10 PM To: oberon@lists.inf.ethz.ch Subject: Re: [Oberon] A2 Repository

Hello,

Am 20.06.2019 um 23:25 schrieb Michael Schierl:

...

When taking r7367 and using Heaps.Mod from r7366 (plus adding an empty CheckAssignment* implementation), the system boots again. So, the triple fault is likely caused by a change in Heaps.Mod. After some more investigation, it is only indirectly the case.

The culprit is the variable "cardSet" introduced here: <https://github.com/metacore/A2OS/commit/0dc3648ec67f89205519d3a06a41 01920bfadb97#diff-9b871273cc2a9acefd2d27c4ffe3bdf4R323>

As a consequence, the size of the linked images increases by 128KB, and since the default OBL.Bin loader tries to load the linked image into conventional memory (640K ought to be enough for anybody), the image just got too large.

...

For r7409/r7412/r7461 there were many compile time errors I was not quickly able to fix. Reason here was the change in <https://github.com/metacore/A2OS/commit/b4617815d2c3b7d5ff7550baafe43 d46f7bede9b#diff-3252168e91a62b6afaa2443658b703a7R1187> that changed the namespaces to be separated by dashes instead of dots. I am unsure why this broke the Bios32 build but not the WinAOS build, but since this got fixed some revisions later, probably it is not important anyway.

Anyway, when reverting this change (and also reverting the change how GetModuleSegmentedName is built), these versions compile and run again, too.

Coming back to our main goal of recompiling a recent A2 version: The linked image of recent versions is a bit over 800KB, so I assume it is unrealistic to get this stripped (without breaking the system) to fit within 640KB. There seems to be a second Boot loader (OBLUnreal.Bin) available, which supposedly tries to avoid this limitation by switching to "Unreal mode" (also known as flat memory segment hack) and loading the image into extended memory instead.

However, I was not able to make this bootloader boot (on VirtualBox, at least), neither when using a current version of A2 nor when using an old version that still boots fine with OBL.Bin.

So I guess, to wrap this up, the issue with recent A2 native builds is that the linked image got too large for being loaded with OBL.Bin, and the alternative OBLUnreal.Bin does not work (on all hardware where OBL.Bin worked). Probably one could spend a lot of time finding the latest version that can get stripped down to fit into conventional memory, but I don't see a point in doing that myself.

Other solutions could be to either implement a self-decompressing image (so it can be loaded with original OBL.bin; but even that might be "not enough" at some point) or add support for creating Multiboot or Multiboot2 images (and load them with a Multiboot-supporting bootloader, like SYSLINUX, ISOLINUX, PXELINUX or GRUB; disadvantage being that it is no longer possible to install A2 to an empty hard disk just from within A2). But both of them are a lot more work than I'd like to spend on this (side-)project.

So I will stop my A2 endeavors here - since I also noticed that OberonGadgets apparently disappeared from later A2 versions, I'd probably stick with earlier versions anyway :D

Regards,

Michael -- Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon

-- Dr. Felix Friedrich, Senior Scientists Department of Computer Science ETH Zurich, UNG F 14 Universitätsstr. 19 8092 Zurich, Switzerland tel.: +41 44 632 8312

On Sat, 29 Jun 2019 at 22:10, Michael Schierl <schierlm@gmx.de> wrote:

So I guess, to wrap this up, the issue with recent A2 native builds is that the linked image got too large for being loaded with OBL.Bin, and the alternative OBLUnreal.Bin does not work (on all hardware where OBL.Bin worked). Probably one could spend a lot of time finding the latest version that can get stripped down to fit into conventional memory, but I don't see a point in doing that myself.

Other solutions could be to either implement a self-decompressing image (so it can be loaded with original OBL.bin; but even that might be "not enough" at some point) or add support for creating Multiboot or Multiboot2 images (and load them with a Multiboot-supporting bootloader, like SYSLINUX, ISOLINUX, PXELINUX or GRUB; disadvantage being that it is no longer possible to install A2 to an empty hard disk just from within A2). But both of them are a lot more work than I'd like to spend on this (side-)project.

So I will stop my A2 endeavors here - since I also noticed that OberonGadgets apparently disappeared from later A2 versions, I'd probably stick with earlier versions anyway :D

I am a bit late but I wanted to thank you for your investigative efforts. It's great work even if the results are a little gloomy... -- Liam Proven - Profile: https://about.me/liamproven Email: lproven@cix.co.uk - Google Mail/Hangouts/Plus: lproven@gmail.com Twitter/Facebook/Flickr: lproven - Skype/LinkedIn: liamproven UK: +44 7939-087884 - ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053