All your nightly are belong to us

Yay, I’ve killed all nightly builds. Sorry ๐Ÿ˜‰

That was the short version. Last weekend I was busy with removing some legal hacks from AROS sources. The hack on the schedule was commonly used ThisTask pointer in the SysBase. Now, at least in my local branch of AROS for RaspberryPi the SysBase->ThisTask points to a nirvana place where all code is either happy crashing, or dead, or both. ThisTask points to NULL ๐Ÿ™‚

No, it didn’t disappeared completely. The ThisTask pointer has been moved (and is used there) to something similar to a thread local storage. It is local, but not local for a thread. It is local to a CPU core. On RPi2 we use four independent local storages and each of them has it’s own ThisTask pointer. Don’t hold your breath, it’s not SMP yet. Far from it ๐Ÿ™‚ The scheduler works only on the CPU#0. At least for now.

The TLS is used exclusively by the kernel.resource, which knows best about the low-level part of the system. Exec has become two new architecture-specific macros, named GET_THIS_TASK and SET_THIS_TASK(x). On all architectures they do expand to SysBase->ThisTask, on RaspberryPi they expand to TLS_GET(ThisTask) and equivalent TLS_SET. What about the rest of the AROS code? Well, in that case the only sane way to get ThisTask shall be used — the FindTask(NULL) call.

And here we come to the point where I’ve killed all nightlies. During my ThisTask removal fun I brokeย accidentally one macro in AROSTCP network stack ๐Ÿ™‚ It should be fixed already.

Hello Core 1, hello Core 2, Core 3 – wake up!

Porting AROS to RaspberryPi is a lot of fun, I told that already. There’s also a lot of frustration and You know that. This time because of 4 CPU cores…

From very beginning I have noticed that the speed of frame buffer was relatively slow. At least not as fast as I would expect form a nearly 1 GHz machine. Well, issue there, ignored first. I followed with AROS porting and came to a point where AROS was booting into desktop and running programs. As a simple example I have added Clock to WBStartup folder, thus making this app start automatically once the system is up. Of course I have had full debug enabled in screen console and over serial port.

Huh, it took AROS nearly 30 seconds to boot. Not bad, but could be better for sure. Slow redrawing od the screen was worrying me but hey, we do have the simplest graphics driver ever. No acceleration, just a simple portion of memory filled pixel by pixel (with some help of our base graphics class of course). So far so good.

IMG_3069

Then out of curiosity I decided to take a look at an old raspberry pi model I have on my desktop. I booted it and looked on the Clock and gone mad. Old raspberry pi with arm11 CPU booted in about 20 seconds. 2/3 of RaspberryPi2 speed! Can’t be, I thought. The new machine cannot be that bad, can it? Have I missed some cache setup? Frame buffer can’t be cached, right? Why was linux frame buffer console faster?

Finally I found a forum where Bare Metal guys were discussing their great efforts to develop standalone software for RaspberryPi. Luckily for me one of them had similar issue I had. He also led me to the final solution. It turned out, that the CPU cores of RaspberryPi2 are not silently seeping and waiting for an interrupt when start.elf transfers the control over to the ARM cpu. No, instead they are busy looping and polling the registers, anxiously waiting to start and do some useful work. As you can imagine polling technique is not something very effective, it’s rather the contrary. The additional CPU cores were stealing the precious bus cycles, leaving less for the CPU#0 which was actually running AROS code. Eureka!

There are two solutions and I have found both of them working with AROS. The first one is to extend the config.txt file (the file which is read and parsed by VideoCore). There, one has to add following parameter

ย arm_control=0x1000

It forces the additional CPUs to go sleep and wait for interrupts instead of do busy looping. I tested it and it really helped. After adding that line AROS really flies on that tiny computer! Frame buffer refreshes quickly, display redraws quickly, few demos redraw their windows nearly immediately. Boo! Now the machine not only feels faster than old RPi, it actually is faster.

Letting the additional CPUs to sleep alone is good, but not something I liked very much. Sure, start.elf does good job but I wanted to make AROS do that job. So I started to code ๐Ÿ™‚ I wrote small assembly routine, a trampoline which initializes caches and MMU of the woken up core. The trampoline initializes also the supervisor stack and jumps to a routine in C code. At the moment the C routine is rather simple. It checks CPU type, enables VFP and enters endless wait-for-interrupt loop. Ah, the C routine babbles on the system log of course to let me know it is actually working. What I got was:

[KRN] Co]e o Co eUp ani idiwir igr rrutatuots
s
0a008

Uh. Not very readable. Forgot something? Ah yes, there is no locking in our bug() function, which means all cores were fighting on the serial line. Proper locking will come later, since it has to be done right, for now I have only added some delays. This is how it looks now

Bildschirmfoto 2015-04-21 um 21.53.40

Please note that the “Core x up and waiting” lines are sent to the console respectively by different ARM cores. It’s not SMP, not even AMP. It’s just small initialization routine. But at least it work as expected…

And with current setup AROS really flies on the RaspberryPi 2 ๐Ÿ˜€

 

EfikaMX meets AROS again

After me and Pavel made the linux-hosted ARM version of AROS, I was wondering who will try to make a great use of it and when. I haven’t had to wait long, at least not long in terms of Amiga way ๐Ÿ˜‰ I found out that the very interesting Linux hosted distribution, namely Broadway X, not only is actively developed, but also targets the EfikaMX machines! This is just great!

AROS on ARM cpu’s gives the user really good experience of small, fast and lightweight operating system. It’s so much different from regular linux distributions! All programs start within a second or less, the graphical user interface is very responsive. If only we had more apps…

This is exactly the place, where BroadwayX (I would prefer it to be Broadway MX ;)) helps. Here, with help of tiny lx command, it is possible to launch linux-side applications directly from AROS environment. Because of that, you can use AROS on EfikaMX all the time. If you lack any application, just launch linux one. I must admit I haven’t tested that distribution personally yet, but I will do that as soon as possible ๐Ÿ™‚

Another exciting news related to AROS on EfikaMX, is the OpenGL for AROS hosted bounty. Once finished, AROS hosted distribution will get hardware accelerated 3D support. Another milestone towards better AROS!

Cube 2 on AROS hosted

Status of AROS for EfikaMX

Hello,

Two weeks ago Raquel and Bill announced price drop for EfikaMX nettop and smartbook. The prices in the store have been updated already, and the Genesi store for EU citizens is open. A nice gift for all of us living on this side of The Pond. These nice machines attract interest of many people of our small community and so, some of You asked me about the status of AROS for ARM machines, especially AROS for EfikaMX. So, here it is:

AROS hosted on linux

Here, the nightly build of core package is available on AROS website for download. This linux-arm-system build is done automatically every night. Therefore, there is no guarantee that it will work out of the box, nor that it will give you all the bells and whistles you know from the very great Icaros distribution. If the binary doesn’t work, try to download it again in one or few days. Nevertheless, most of the builds are working. Even better — this build benefits from the improvements of other AROS ports, like the AROS m68k one, so it “improves” each day. In some near future I will add to this build some of our contrib packaged. OWB, maybe?

AROS native for EfikaMX

The native port of AROS for EfikaMX is still on the schedule. I will take care of it as soon as I find the time. Right now I’m involved in few other projects and, therefore, native AROS for this ARM has to wait. Don’t worry — it will be available.

Future of AROS for ARM

What the future of AROS for ARM will be? Well, it’s not only in my hands — it depends on all of you. AROS never was a one-man project, and was always dependent on the community. Many years ago the community was very weak and AROS was hardly noticeable outside our development mailing list. Nowadays, the community grew and so grows AROS. We had x86 nightly builds only, now we have two great distributions and some commercial software. The same applies for ARM target — whether it will grow or not, is up to You.

Big kernel BLOB? Not anymore!

Hope springs eternal – everyone knows…

Once upon a time I have promised to some of AROS enthusiasts improvements on the x86 kernel, among others support for modularized kernel. It seemed, we have got rid of the nice feature of Amiga-like operating systems — the strong separation of all essential components of the system in libraries, devices and resources. That’s how original kickstart was made, it was a bunch of different modules put together on one read only memory. Which components were there, that was unknown for AmigaOS unless it scanned entire ROM for resident modules. We did the same in AROS kernel, at least for native targets, but we also linked all modules together, into one single executable. How silly!

Sure, such approach has it’s own advantages. Some static libraries (like librom.a) could be reused by all modules and thus saved some space. However, we do link all of it into one big file — think about any potential licensing issues. Not only that, big statically linked kernel means, there was no way to replace one module with a new version, no way to add module of your own. Do you all need ability to boot from USB media? No? Pity you, all the necessary classes are there anyway. Does any of you ever thought about GUI-less core components of operating system, used for some imagined device? Well, compile and link all of it yourself, have trouble and solve it all alone. The modular kernel opens many opportunities, limited only by our imagination.

So, the promise was given, years passed and nothing happened. Until now. In some spare time between my real life, activities at the university and work on Aura, I’ve added the support for loadable modules to native x86 AROS target. There’s still the large kernel to see, but it’s a matter of writting new GRUB config file (which I didn’t had time). Feel free to test the nightly build, look at GRUB config file (to find a way how to add more modules) and be happy. And, of course, don’t forget visiting this site for some more news about Linux, Aura, AROS and others ๐Ÿ™‚