In the download section on aros.org, under today's date, there is a Nightly Build: raspi-armhf-system

decription: The native version for ARMv6 based Raspberry Pi computers. Contains all files needed to boot from a FAT formatted sd-card.

Does this mean we have a working native port on Raspberry Pi?!

Hi,

I think ARMv6 is 32bit as the latest pis are 64bit ARMv8, so maybe it is an old build. Not sure how advanced feature wise it was.

The port was done a long time ago, but I don't recall to which extend it was working. Recently a new developer seems to be fixing some of the RasPi support so maybe in future there will be a working port.

And I'm wondering why the hosted Linux version won't run on my RPi 500+... Because it's 32-bit
So we don't have anything for 64-bit ARM...

No, I don't think so. As far as I remember the work on ARM port was done around 10 years ago.

That's around the time I used a hosted Linux to build an OrangePi distro. Now I understand where I'm at.

Hi, have you tried the build?

I am also interested. I have a rpi3b that the only destiny Will be aros/amiga stuff.

Atm im (the ai) doing support for raspberry peripherals (sound, usb and bluetooth) to interact with an emulator.

Dunno how bad would be to make the native build work.

Regards,
Ps:aarch64

I tried running the hosted Linux version on my RPi 500+, and AROSBootstrap wouldn't run. Since it's a 32-bit version, it shouldn't have been.
I'm still interested in this AROS development line, but it seems to be a dry branch. It's a shame, because I think the latest Raspberry Pi projects are great. It would be great if the developer working on the native ARM port would comment on the matter.
Well, then, we'll have to focus on the x64 version.

fwiw:
The native (32-bit) version of AROS for ARM never managed to boot all the way through. The developer at that time took another route and started working on the PI to be included in a native Amiga as an accelerator (sorry, the exact name of this hardware eludes me at time of writing this).

One of the issues with the native version for the PI is the firmware of that specific hardware, as it changes all the time and back then broke things on a regular base. No idea if that is still the case though.

The hosted version however worked as intended back then on a 32 bit-linux host. It should still work but haven't tried for ages as somewhere along the line something broke for the 32-bit ARM AROS hosted version in that I was unable to build it (the nightly builds failed as well back then). I have not ran this version since then.

Emu68 for PiStorm?

Yeah, that's the name indeed. Thank you very much @cdimauro for that (it really escaped from memory).

Wow, that is News for me.
Aros never fully boots on aarch64 native?
(Dunno why i thought it was missing only the drivers, like usb etc)

Anyway, i would like to try the build some day (not today, that i need to take care of projects not related to amiga and aros)

I hope this week to close the arm side support of the emulator (missing bluetooth and sound. USB working hid and msc, but not a cheap and old keyboard, thought)

That should be enough to make the first version of the readme. (No sense have an emulator that you cant interact with 😬)

Regards,

Michal Schulz was working on AROS then he started to develop Emu68. :-)

Let me be cautious with wording in order to not discredit all the efforts and/or other people... it never did for me (pi3) but might have worked for the developer back then (I do not recall exactly but maybe the original aros-exec forum posts are able to shed a light on that topic).


It did missed the drivers initially but one of the issues here is that in order to boot AROS (the workbench) you'd need access to the USB (technically the postoffice protocol) to be able to actually load something of disk (SD-card in this instance).


@miker: yeah indeed, it was basically michal (together with kalamatee) who was working on ARM support for AROS back then but he got sidetracked a little (nice little sidetrack though) :-)

Strange, you can acesso the sdcard without the USB, but i Will take a look when i build it (atm fighting with bluetooth, really, low level is quite a strange land … )

I want to finish this (arm support) and hope the experience can help the AI to handle the AROS scenario.

(I am using external libraries for usb and bluetooth, but i have even use the AROS code to give some light on the usb bring up 😁)

Regards,

FYI: This guys is working on AROS for RasPi - he has a number of development/fixing branches. Maybe try contacting him and see if you can help/support him. Would be great if he can join the forum and start showing his work to wider audience.

https://github.com/bsek/AROS

Hi @deadwood , i dont know if it is something i could handle (upstream code), i can try to make things work (AI alucinates a lot, but on the end it work somehow)

Atm im having a lot of going foward and Back with bluetooth. I hope that i can bring the experience with the emulator to aros code, but its not a real bet (the chipset code it mostly did all the way again, the same mistakes than before)

Probably i Will try to make it work and show on mine repo for a good review.

I had think of try to add big endian support to cherryusb, but i am not sure. It make BE support for it in my project, but its diferent when is a consolidate project.

Lets ser how it Goes, atm bluetooth (its a living hell thing, it messyes the serial output. Some times i can scan entries, but nothing realiable yer)

Anyway i would love to contribute to AROS development, but it couldnt follow a regular workflow. First i need to make it work and than evaluate if its working properlly for upstream grade.

This project is a kind of school for me, and i think it (the AI) can generate working code for AROS, but from this to be something upstreamable it would be another class of learning.

Regards,
Ps: its not a thing that i can discuss (AI opinions are not realiable, i can only trust in the results and from there the code would need to be reviewed)

You May see that its not vaporware

https://github.co.../bellatrix

But its still labs in the learning sense of the word

Not saying that I am able to recall everything a 100% correct as it has been over a decade (at that time there were no drivers, everything was closed source or only a binary blob and the openfirmware implementation for the pi did not exist yet)

But ... I think I made a mistake as I interpreted your earlier message as you refering to native code while the code you (later on with the repo) seem to refer to what looks to me as an abstraction layer (as in not being bare-metal).

A raspi boots using the video-core and at that time there isn't a cpu (yet). This requires a complete other approach than what I was able to locate in the bellatrix repo (unless I missed something, though I am also not up-to-date with regards to the (current) pi boot process).

Not saying that what you seem to be doing is simple but it is a lot easier to address things when there is an actual abstraction layer in place. The benefit of such an layer is that you can concentrate on an actual implementation of/for a driver.

What I am not sure about (I was unable to tell from the repo on such short notice not to mention github being an arse lately) is where that extraction layer is coming from, is that your (own) doing @CoolCat5000?

Hi @magorium ,

Im not sure if i understood you.
Bellatrix is a bare metal emulator build on top of emu68 (i reuse the emu68 raspberry setup)

In the case of the vídeocore, emu68 does the setup and i use the framebuffer pointer. But the AI could do this, im using the EMU68 setup cause it hás simd(neon) stuff and específico irq stuff, and i want to use the EMU68 JIT on the emulator. (And rely on the emu68 setup gives me updates for free 🙂)

(Btw, i could have an IRQ based blutooth handler, but i didnt cause i am afraid of messy the jit)

It is my iniciative, but its full AI coding (2 blinds, me and the AI)

What do you mean about extraction layer?

Regards,
(Ps: móbile auto correction is a hell 😒)

Oh, o think i understant now @magorium , 🙂

You mean the abstraction layer … that is the place in the code that you need to adapt for each plataform Port.

🙂