Aros Raspberry

[Jezry]

Hi everybody.
Is there Any news Regarding native Aros on Raspberry pi.
Or Any other of the arm sbc boards out there.
 

[Alexandrabzh]

Hello all
yes good question, i have a new pi4 4 go so it will be really cool to get aros on it and i hope at full speed

[Samurai_Crow]

Dr. Michal Schulz has been buying various ARM Linux machines including a PineBook Pro but hasn't gotten the ARM EB (big endian) version complete yet.  He's mostly working on the 68k compatability JIT right now.

[mschulz]

Hello all
yes good question, i have a new pi4 4 go so it will be really cool to get aros on it and i hope at full speed

The status of AROS for RasPi was quite good already. System booting, USB working (although with some issues but I have a plan to fix them). Where I got stuck was modifying the ABI (application binary interface) and adjusting binutils/gcc to support it. I wanted to have real executable files but I got stuck a little - I had to change the type of relocations embedded in ARM files and I'm not sure if this very type is well supported, on the other hand without this changes ARM version of AROS wouldn't work well. By reverting the change to ABI we could have a (somehow) working AROS on RasPi, but unfortunately still unstable.

In parallel I was working on m68k emulation. Surprised by the performance (in positive way) I have focused on developing it. The project called Emu68 is at the moment intensively developed. The project brings a very fast m68k JIT working on bare metal ARM. On top of that emulator there will be a m68k version of AROS working. So yes, not exactly a full speed, but still much faster than a real amiga emulation. The JIT is already at a stage where it can execute simple m68k apps (of course those which do not need AmigaOS or AROS) which talk to RasPi hardware directly. In next stage which I'm going to start in few weeks, I will start building a m68k AROS version working on this JIT.

PS: The Emu68 supports RasPi2B, RasPi3B, RasPi3B+ and RasPi4. Support for other machines (RockPro64, PineBookPro) is planned. You can follow the progress here: https://www.patreon.com/michal_schulz/posts?tag=JIT or watch the repository on GitHub: https://github.com/michalsc/Emu68

[OldAmigan]

Excellent news. Thanks for the update and thank you very much for your work.

Fred

[Jezry]

Great.
Thank you for that great  answer.
Regards Johan

[mschulz]

Emu68 is going AArch64! The 32bit and 64bit ARM versions will be developed in parallel.

https://www.patreon.com/posts/32705355

Happy New Year!

[Samurai_Crow]

Excellent news, mschulz!

[x-vision]

Hello all
yes good question, i have a new pi4 4 go so it will be really cool to get aros on it and i hope at full speed

The status of AROS for RasPi was quite good already. System booting, USB working (although with some issues but I have a plan to fix them). Where I got stuck was modifying the ABI (application binary interface) and adjusting binutils/gcc to support it. I wanted to have real executable files but I got stuck a little - I had to change the type of relocations embedded in ARM files and I'm not sure if this very type is well supported, on the other hand without this changes ARM version of AROS wouldn't work well. By reverting the change to ABI we could have a (somehow) working AROS on RasPi, but unfortunately still unstable.

In parallel I was working on m68k emulation. Surprised by the performance (in positive way) I have focused on developing it. The project called Emu68 is at the moment intensively developed. The project brings a very fast m68k JIT working on bare metal ARM. On top of that emulator there will be a m68k version of AROS working. So yes, not exactly a full speed, but still much faster than a real amiga emulation. The JIT is already at a stage where it can execute simple m68k apps (of course those which do not need AmigaOS or AROS) which talk to RasPi hardware directly. In next stage which I'm going to start in few weeks, I will start building a m68k AROS version working on this JIT.

PS: The Emu68 supports RasPi2B, RasPi3B, RasPi3B+ and RasPi4. Support for other machines (RockPro64, PineBookPro) is planned. You can follow the progress here: https://www.patreon.com/michal_schulz/posts?tag=JIT or watch the repository on GitHub: https://github.com/michalsc/Emu68

Thanks for the update, and great job! but: does that mean we will never have a native version? I think it is important because many people is waiting to adopt it as their main Aros system, but also because it will attract many new devs from outside the community.

[moochris]

Thanks for the update, and great job! but: does that mean we will never have a native version? I think it is important because many people is waiting to adopt it as their main Aros system, but also because it will attract many new devs from outside the community.

I have been wondering about this myself, and I have a couple of thoughts about this that may or may not be correct... 

I think the most important thing is that this is written for big endian mode ARM. This means that:

• The emulated 68K is also big endian and so the emulator doesn't have to do any kind of expensive byte reordering, so this thing is fast.
• Remember Amithlon? It had a provision for native code to run to accelerate datatypes etc., but had to deal with endian conversion. This wouldn't be a problem here with BE mode ARM code.

As I understand from mschulz's posts, there will be direct access to the hardware from the 68K side as well for drivers etc., so it won't be a like a virtualisation with abstracted hardware - the 68K will have full access.

Chris

[x-vision]

Thanks for the update, and great job! but: does that mean we will never have a native version? I think it is important because many people is waiting to adopt it as their main Aros system, but also because it will attract many new devs from outside the community.

I have been wondering about this myself, and I have a couple of thoughts about this that may or may not be correct... 

I think the most important thing is that this is written for big endian mode ARM. This means that:

• The emulated 68K is also big endian and so the emulator doesn't have to do any kind of expensive byte reordering, so this thing is fast.
• Remember Amithlon? It had a provision for native code to run to accelerate datatypes etc., but had to deal with endian conversion. This wouldn't be a problem here with BE mode ARM code.

As I understand from mschulz's posts, there will be direct access to the hardware from the 68K side as well for drivers etc., so it won't be a like a virtualisation with abstracted hardware - the 68K will have full access.

Chris

I don't have any doubts that his code will be wonderful. And that it will be very fast, but from an amigan perspective. Devs and users form outside, I'm afraid they won't be seduced by this translation penalty.

As I know it is very hard to convince people about this, let me bring an example: there are amazing emulators that perform an blazing fast JIT translation from x86 code to arm, so imagine the vast amount of amazing software and games library that it instantly brings to Pi. Well, it does not succeed. It does not sell well. Almost nobody care about it. Why will they do it with 68K code? just because we are cooler?

Pi users want to explore the system limits and features, not be  "constrained" by any kind of translation even it is the most transparent and thin it can be.

This will be cool for us amigans, but just for us. Very few people more. And it will always have the problem of the lack of support for any feature (devices or processor/core) that it is not supported by the emulator.

This is a step forward from an Amiga user perspective, but not from a Pi or a new user perspective.

[aGGreSSor]

This is a step forward from an Amiga user perspective, but not from a Pi or a new user perspective.

Pi lives as long as his SD card lives. if you are using linux for Pi, then SD card dies quickly. Lots of small files do it and doesn't depend on the class and vendor.
This is the real reason why pi doesn't live in every hole. In fact, the new user will just have AROS among the available images or not.
I don't think that Win10 IoT will be more popular.

[OldAmigan]

@msschultz, @Samurai Crow

Is there anything that the non-coder/user can do to assist your coding efforts?

E.g. could you give out a job to compile something which we would be able to do as a mechanical process (follow instructions in a repetitive way) which would save you having to do i and free some time up for you to concentrate on another task? or any other task - beta testing som code, or whatever?


Do your efforts include the RPi400?

[Samurai_Crow]

@OldAmigan

The RasPi 400 has a USB3.0 controller that isn't supported by AROS that I know of.  The RasPi 4b has the same problem.  The last I talked to PurpleMelbourne, we discussed using a RasPi compute module with an FPGA in place of the USB 3.0 controller running a MiniMig derivative for Amiga chipset emulation.  Nothing seems to have come of it yet.

I've got a PineBook Pro laptop like MSchulz has and was hoping PurpleMelbourne could come up with a small FPGA expansion for it.  I guess the chip shortage has hit hobbyists hard.

In the meantime, I'm trying to get the Haiku operating system going with multiple architectures.  At least Haiku has multicore support working already.  The real trick is the drivers.

[OldAmigan]

@Samurai_Crow

Does that mean that the RasPi400 USB3.0 won't work at all, or will work but at USB 2.0 speeds?