AROS World Exec
Platforms => AROS - Raspberry Pi => Topic started by: NinjaCowboy on January 15, 2019, 09:13:15 AM
-
What is the current status of getting AROS up and running on the Raspberry Pi? I looked into this years ago, and some developer was having trouble getting the USB to work. I've done some bare metal programming for the Pi, and it would be fun to help improve hardware support. Can someone point me to documentation on compiling AROS, how the repository is organized, and driver development?
-
Mschulz. The father of AROS picked up the Pi port again a few months ago.
Seams he is very close to a AROS Pi native image where we can all play around with it.
https://www.patreon.com/michal_schulz/posts
The AROS night builds are here.
http://www.aros.org/nightly1.php
I don't see any arm build yet, but pretty sure it will show up soon. I can see Mschulz commited some code recently.
I'm sure he is very interested in help with drivers.
It is a very exiting project. It is for sure a platform AROS could be popular.
-
That's great news! I thought the Raspberry Pi project had died.
In some ways, the Raspberry Pi is an ideal platform for AROS. It's inexpensive, popular with hobbyists, and has few hardware configurations to support compared to PCs.
-
In some ways, the Raspberry Pi is an ideal platform for AROS. It's inexpensive, popular with hobbyists, and has few hardware configurations to support compared to PCs.
Exactly. It is not very likely people would buy expensive hardware for this OS. AROS is, and will most likely always be a fun platform for multimedia, games.
I don't see the point being an Linux alternative. There are limitations in AROS regarding security, memory protection that are very hard to overcome.
That does not matter much as long as we focus at where we are good and what made the Amiga great in the first place. How boring is not the security part of Linux with sudo this and that. I don't see it welcome in AROS what so ever. That is at least how I think about this OS.
As you say the Pi is a specific hardware platform that does not need tons of different drivers. Everyone can afford it. It is small (does not take up much space)
Even sceners could be interested in this platform. What can you make out of a Pi :D
We can even put a Pi into a laptop. I know it's been done already :)
The CPU is not that powerfull, but it will be more powerfull in years to come.
The GPU is quite good. That is something we must take advantage of. Just like in the Amiga days with custom chips.
Do you know anything about the GPU in the Pi and how to program it?
-
What is the current status of getting AROS up and running on the Raspberry Pi? I looked into this years ago, and some developer was having trouble getting the USB to work. I've done some bare metal programming for the Pi, and it would be fun to help improve hardware support. Can someone point me to documentation on compiling AROS, how the repository is organized, and driver development?
It's best to develop under Linux. AROS build system can make a cross compiler for your platform. Build system uses metamake, takes a bit to get used to, but it does it's job if not asked too much.
For driver development you should know how Exec works (library and device) and how messages are passed around. Then comes the AROS macros to actually define the LVO's...
There is only host mode support for USB, we have no VID/PID nor code in Poseidon (USB stack) for having it behave as a device. No OTG.
For USB driver development the USB specs are a source of good information... Poseidon drivers can be programmed with that information. There are the working PCIUSB driver (all nicely bundled together OHCI/UHCI/EHCI) and couple not so working examples of my conception (XHCI and somewhat working libusb based hosted implementation VUSBHCI, virtual usb host controller interface)
-
I'm not familiar in-depth with the inner workings of AROS, but I do know quite a bit about how operating systems work in general.
As I understand it, AROS uses a microkernel called Exec, and all drivers run in userspace. I don't really know the architecture of the driver system, but they seem to use BOOPSI, or something like it for an object oriented approach. Poseidon seems to be the USB stack (Cute name, haha, since the USB logo looks like a trident), but I'm not sure exactly what functionality it provides over what the drivers do.
I have programmed the VideoCore, but that was just using Broadcom's closed source userspace libraries on Linux. Nothing bare metal. There does seem to be Gallium3D support for it, which is good news.
-
Poseidons preference program is called Trident, it's not a coincidence.
For coding a driver you first need to understand Exec signals, messages, iorequests and lists.
For a driver (device normally) there are only a few "functions" DoIO, SendIO etc. The details are in the IO request fields. Take a look at the VUSBHCI driver. There's no hw stuff, only high level code for Poseidon driver and libusb.
VUSBHCI is also much more readable as I've put everything in plain sight in structures. You will recognize usb spec things in it and how things are passed around.
-
Poseidon is the main USB code, it doesn't know by itself anything about the hardware. Driver code is attached to it. Poseidon takes care of all the preferences, classes and drivers. Drivers only try to satisfie higher level requests from Poseidon or it's classes more specificly.
Every driver has to have a roothub as per usb spec. Roothub represents your hw. Roothub has ports, these are the physical ports that the host controller has (doesn't have to be... You could also implement a virtual port and have virtual devices attach)
hub.class calls your roothub and your driver has to respond to roothub requests. It's all in the usb specs. Poseidon doesn't yeat know anything about usb 3.x requests. Driver also responds to requests to the physical device and conveys messages between the host and device.
-
Thanks for the info. I'll try setting up a cross compiler on my Linux machine tonight. Should I be using ABI v0 or v1? Are the latest RPi developments on this branch? https://github.com/ezrec/AROS-mirror/tree/ABI_V1/AROS
-
Set up for abi v.1
It is always possible to backport to abi v.0 if needed.
Hopefully everything will be abi v.1 some day.
It is only for the x86 cpu we are still are using abi v.0
The reason for this is that we have a lot of software for that platform. Abi v.1 is not 100% ready either so it will be broken again and then another recompile of software is needed.
For arm, amd64, 68k it is all abi v.1
I don't think Mschulz have commited all the new stuff for Pi.
He come around here from time to time. Guess he is the best to answer that question.
-
I tried compiling, but got this error.
Link failed: /home/user/programming/aros-rpi/bin/linux-x86_64/tools/crosstools/arm-aros-gcc /home/user/programming/aros-rpi/bin/raspi-arm/gen/developer/debug/test/misc/getcpuinfo.o -o /home/user/programming/aros-rpi/bin/raspi-arm/AROS/Developer/Debug/Tests/misc/getcpuinfo -lpthread
There are undefined symbols in '/home/user/programming/aros-rpi/bin/raspi-arm/gen/developer/debug/test/misc/getcpuinfo':
w __cxa_begin_cleanup /home/user/programming/aros-rpi/bin/linux-x86_64/Ports/host/gcc/gcc-4.6.4/libgcc/../gcc/config/arm/unwind-arm.c:1094
w __cxa_call_unexpected /home/user/programming/aros-rpi/bin/linux-x86_64/Ports/host/gcc/gcc-4.6.4/libgcc/../gcc/config/arm/unwind-arm.c:1208
w __cxa_type_match /home/user/programming/aros-rpi/bin/linux-x86_64/Ports/host/gcc/gcc-4.6.4/libgcc/../gcc/config/arm/unwind-arm.c:1174
I can't find those functions anywhere in the code base. Apparently, they're generated by C++ code, even though getcpuinfo is written in C, not C++.
-
https://www.patreon.com/posts/better-is-worse-24050291
New entry about the progress of the project. Not very good in the short term, but maybe great in the long one: having a good and robust FAT driver is very important.
Anyway it's also good to see it is still alive, progressing, and close to a 1st release. Interesting times ahead.
-
Awesome. Looks like some nice progress. Why is big endian ARM targeted instead of little endian, which ARM traditionally uses? Is it to make it easier to emulate software for the Motorola 68k, which is also big endian?
-
Awesome. Looks like some nice progress. Why is big endian ARM targeted instead of little endian, which ARM traditionally uses? Is it to make it easier to emulate software for the Motorola 68k, which is also big endian?
Exactly! Now you get it!
It's reasons like this that MorphOS and AmigaOS 4 can JIT 68k code quickly and seamlessly while AROS x86 stumbles along with a UAE derivative emulator. That and that many open source projects use AmosPro, AmiBlitz and AmigaE or other programming languages that don't run with little endian CPU support.
-
Awesome. Looks like some nice progress. Why is big endian ARM targeted instead of little endian, which ARM traditionally uses? Is it to make it easier to emulate software for the Motorola 68k, which is also big endian?
It was explained in an old entry. Too long explanation and too little time for me right now to enter into detail again
-
If there is one thing that we need for the Pi port, it is the Amiga 68k stuff running.
-
Awesome. Looks like some nice progress. Why is big endian ARM targeted instead of little endian, which ARM traditionally uses? Is it to make it easier to emulate software for the Motorola 68k, which is also big endian?
Exactly! Now you get it!
It's reasons like this that MorphOS and AmigaOS 4 can JIT 68k code quickly and seamlessly while AROS x86 stumbles along with a UAE derivative emulator. That and that many open source projects use AmosPro, AmiBlitz and AmigaE or other programming languages that don't run with little endian CPU support.
What does the PowerPC version of AROS use for emulation? While it's easier to use the same endianness, I doubt it's that big of a performance barrier. The only instructions affected are those that read and write to memory, and those are slow anyway because memory speed is always a bottleneck in modern computers. x86 also has fast byte swapping instructions that can be used.
-
aros has no tranparent emulation like morphos or os4 at this time. so far it is janus uae afaik, a version of winuae, with a mui frontend, (coorect me if im wrong). michal is inclined to add that transparent emu layer, on pi since it would make sense on big endian host.
btw. are you compiling/building armeb (big endian taget)?
if you share your mail with me (pm?) i can invite you to the slack channel michal is monitoring. also you could get there other assistance what concerns aros concepts and details from experienced developers who might not post here.
-
What does the PowerPC version of AROS use for emulation? While it's easier to use the same endianness, I doubt it's that big of a performance barrier. The only instructions affected are those that read and write to memory, and those are slow anyway because memory speed is always a bottleneck in modern computers. x86 also has fast byte swapping instructions that can be used.
To use a BSwap opcode on 486+ the JIT would have to be specially written to use it or a big endian version of x86 AROS using a custom C backend in GCC would have to be written. Either would be difficult to maintain and would be noticeably slower than regular AROS.
AMD64 has byte swapping load and store opcodes. But they still don't support the reads built upon the CISC style addressing modes present so those wouldn't be faster than BSwap.
Having a global big endian mode like ARM7 and MIPS use are definitely advantageous in these situations.
-
AMD64 has no byte swapping load and store opcodes. If you refer to MOVBE, it was first introduced on Intel's Atoms, and then on subsequent Intel's processor. Later it was also implemented on AMD processors.
So, MOVBE isn't part of the standard AMD64 ISA, but only some processors have it (there's a CPU flag to check for its presence).
MOVBE is definitely MUCH better than BSWAP, because it allows to load and store BE data using any x86/x64 addressing modes, which is a vast improvement over the BSWAP. And performances gained much more benefits compared to the latter.
-
Well, I meant that you can still use any of your x86 load/store instructions within whatever addressing mode. The only difference would be that you'd insert a bswap/xchg instruction before storing and after loading. There's no reason to modify GCC or anything, as this would only occur in the code generated by the JIT in the m68k emulator.
Back on topic, I think making the Pi version big endian is quite interesting, since I don't think anyone has ever run a big endian OS on the Pi before.
-
Well, I meant that you can still use any of your x86 load/store instructions within whatever addressing mode. The only difference would be that you'd insert a bswap/xchg instruction before storing and after loading. There's no reason to modify GCC or anything, as this would only occur in the code generated by the JIT in the m68k emulator.
No you can't. This has been discussed many many times on different forums already. Since any Amiga-like OS shares its all internals with all running programs you have to use the same endianness for both the OS and applications. Because of that you cannot make BigEndian m68k emulation layer for LittleEndian x86 AROS, because you never know what kind of access you are translating and if there is a need for endian swap or not. Besides your translated binaries would be lost if they would fetch data as multiplies of the type size (e.g. 4 UBYTEs fetched as one ULONG).
-
Update again :)
Now USB works as should :)
https://www.patreon.com/posts/c-standard-and-24108999
-
Great! :) Could a well placed volatile make a difference how GCC treats things?
-
Well, I meant that you can still use any of your x86 load/store instructions within whatever addressing mode. The only difference would be that you'd insert a bswap/xchg instruction before storing and after loading. There's no reason to modify GCC or anything, as this would only occur in the code generated by the JIT in the m68k emulator.
No you can't. This has been discussed many many times on different forums already. Since any Amiga-like OS shares its all internals with all running programs you have to use the same endianness for both the OS and applications. Because of that you cannot make BigEndian m68k emulation layer for LittleEndian x86 AROS, because you never know what kind of access you are translating and if there is a need for endian swap or not. Besides your translated binaries would be lost if they would fetch data as multiplies of the type size (e.g. 4 UBYTEs fetched as one ULONG).
Yeah, I thought about it more, and realized that wouldn't work in unioned fields that are read both in words and bytes. It wouldn't be a problem if the m68k code was emulated in isolation (like UAE), but it wouldn't work for memory that's accessed by both the native x86 and emulated m68k code.
-
Congrats on getting Poseidon running! Making the pointer volatile should prevent the use of ldm. I think the best solution would be to use _attribute_((aligned(4))) where that buffer is defined in order to force the compiler to align it to a 4 byte boundary. Unaligned access is still a performance penalty even though the hardware supports it. If that's not possible (due to a packed struct or something where the field absolutely cannot be aligned) then volatile should work, or maybe a macro that assembles a long from individual bytes if you want to be more portable.
-
Making the pointer volatile should prevent the use of ldm.
Since preventing from fetch merge through ldm is just a side effect of volatile, I will avoid overusing it as much as possible. It's not what volatile is meant for.
I think the best solution would be to use _attribute_((aligned(4))) where that buffer is defined in order to force the compiler to align it to a 4 byte boundary
That would not help. Originally it has even better alignment since the memory area comes from AllocMem call, but unfortunately IFF is internally packet to 2 byte boundary so it wouldn't help at all.
or maybe a macro that assembles a long from individual bytes if you want to be more portable.
This is exactly what I did as you can read on my Patreon page :) Actually I have not used a macro but rather static inline function.
-
Ping!
Now that there is a new Pi out getting the shake down
-
Now that there is a new Pi out getting the shake down
Hi! Sorry for no actual status reports. So far I have spent a lot of time fighting with AROS ABI for ARM. I'm at a stage where I have real executable files with all information I need inside, but the GNU's linker has some issues making a bootstrap binary from them. Apart from that I have fixed ARM crosscospiler build - the gcc 9.1, and at the moment I am adapting compiler flags in order to let the ARM port behave the same as x86/x86_64/m68k.
And yes, I have RasPi4 on my desktop. Good news there - it does not use the DWC2 OTG usb controller which brought me sleepless nights and headaches. Instead, they have there XHCI controller on one PCIe lane.
-
That really is fantastic news - over the last couple of weeks I've been looking at putting an RPi 4 system togeter to replace my aging x86 laptops (and it's going to be reasonably straighforward as there's an embarassment of screens, power supplies and, well, everything for those boards) and it's great to know I might have an alternative to having to run Raspian.
Cheers,
Nigel.
-
Great to hear there is progress. Does this meen that AROS Pi will first of all be for Pi 4?
I guess it is no point fighting more with the USB interface on the older Pies.
-
I'm thinking about getting a Raspberry Pi for AROS, but I'm not quite sure which models will be supported. I don't really need the performance (or the heat ;D) of the RPi 4 so an RPi 2B would be better for me, if AROS will run on it. Any advices?
-
I'm thinking about getting a Raspberry Pi for AROS, but I'm not quite sure which models will be supported. I don't really need the performance (or the heat ;D) of the RPi 4 so an RPi 2B would be better for me, if AROS will run on it. Any advices?
I would go for model 4. There are something with the USB hardware on earlier models that are very difficult to deal with.
I know Mschulz have model 4 now. It is still best to hear it from him. He have not said anything official about it.
I'm also looking forward to the Pi port. It is the most exiting Amiga like project in my opinion. Let's hope it will be a success.
-
I know about the USB ordeal, I was following the Patreon updates about it. According to this post it's almost there, so it would make no sense to throw it all away because of the Pi 4 is there:
https://www.patreon.com/posts/raspi-code-in-24407450
This is why I'd like to know which versions of the Pi will be supported.
-
BSzili: I sent message to Mschulz. He say there will be AROS for Pi4. It will be much faster than previous Pi versions too. From what we know maybe there will never be AROS for more early Pi versions cause of the problem with the USB controller. It is a no brainer if you ask me.
-
Then there's no question, I have to get a Pi4 for AROS. I'll wait for the new Flirc case is released for it, because it doubles as a heatsink, so you don't need any additional fans. I hope it won't dampen the WiFi signal too much, although I have a pretty beefy router at home.
-
Then there's no question, I have to get a Pi4 for AROS. I'll wait for the new Flirc case is released for it, because it doubles as a heatsink, so you don't need any additional fans. I hope it won't dampen the WiFi signal too much, although I have a pretty beefy router at home.
Does Pi4 generate much more heat than previous versions?
-
Yeah, the Pi4 has thermal throttling issues under heavy loads Even with the recent patch to adjust voltages
Quite a few YT videos on it
-
How much memory will the native Pi port of AROS support? Since the 68k integration is planned, will it be limited to 31-bit addressing (2 GB), like MorphOS?
-
How much memory will the native Pi port of AROS support? Since the 68k integration is planned, will it be limited to 31-bit addressing (2 GB), like MorphOS?
That is a good question. As you say for classic integration it must be 31-bit.
-
How much memory will the native Pi port of AROS support? Since the 68k integration is planned, will it be limited to 31-bit addressing (2 GB), like MorphOS?
Hope that doesnt happen. 68k apps will run fine through the 64bits emulator (specially if it has jit) for most cases, so it would be an absurd to throw away 2gb just to run old apps a tiny bit faster.
We are always saying that Pi must be reference platform for Aros, so it would be a bad referece distro.
-
The problem here is that is if we want to run classic stuff as it was native. That was the plan, but I don't know if Mschulz have taken any final desition about this. As we all know classic stuff can also be hit and miss regarding different amiga models, extra ram, more powerfull 68k CPU and so on. All this can be adjusted within the GUI of some emulator. Sure the binary compatible AROS arm version could also have some emulator where these things can be adjusted. What I'm afraid of is as everything go 64-bit it will be difficult to port future Amiga emulators.
There are hit and miss for any options. Loosing 2GB memory is not as bad as loosing 3 cores.
Even if AROS has proven to run multicore it will break most compatibility with software from what I learned.
The way I see it.
1. Be binary compatible with Amiga classic + easy to recompile NG Amiga software. Will have limitation of max 1 core + 2 GB memory.
2. Fork AROS and start something new. Will be 64-bit, multicore and maybe even have memory protection. Run classic in an emulator like WinUAE and maybe it would even be possible with some AROS classic emulator.
3. Use AROS-64 as is with limitation of 1 core.
Option 2
We might atract a lot of intrest from outside Amiga land. I still think the development time before we have something usefull will be years. It is for sure more future proof.
Option 1
More safe. We will have lot's to play with from day 1.
Option 3
Same as Option 1 but not binary compatible with classic.
I'm pretty sure we could make a poll and Mschulz will take that into consideration.
Personaly I think I'm for option 3 with a port of recent WinUAE to run classic. Someone with enought knowledge like Mschulz should explain the technical advantages, disadvantages.
If option 1 could run most classic. games, demos, programs like native I'm for that one.
I understand people want different things from AROS. Some want it to be everything OS like Linux or Windows.
For me I like it to be a fun platform like Amiga was. Trackers, pixel gfx and old school games. Not realy any need
for multicore or 4GB of ram for any of that.
8MB of ram is plenty to run any whdload game from Amiga 1200 ;)
Most Amiga games every made ran on 500k memory :D
I know things changed but even today 2GB of memory will do for most. I don't see that as a huge limitation ;)
-
The problem here is that is if we want to run classic stuff as it was native. That was the plan, but I don't know if Mschulz have taken any final desition about this.
First of all, althought the poll thing is a good idea, I won't go for any option, because we are just talking, while very smart people is programming it, so I will respect their decision (agreeing to it or not). I just wanted to remember to take some perspective and express my dissapointment if we are not taking into account what Aros really is, and what purpose an eventual Pi4 version could serve.
I understand people want different things from AROS. Some want it to be everything OS like Linux or Windows.
For me I like it to be a fun platform like Amiga was. Trackers, pixel gfx and old school games. Not realy any need
for multicore or 4GB of ram for any of that.
8MB of ram is plenty to run any whdload game from Amiga 1200 ;)
Most Amiga games every made ran on 500k memory :D
I know things changed but even today 2GB of memory will do for most. I don't see that as a huge limitation ;)
We have already a very powerful and superfunny Amiga on Pi with Amiberry
https://www.youtube.com/watch?v=A3DRZQHZMPw
Which drive us again to my previous question: What will be the point in porting an Aros version which will offer very little advantages and a lot of inconveniences against that?? it's kind of pointless.
We said a thousand times that Pi 4 can be a platform to attract new developers to Aros, but it will not attract any new developer if you tell them: No, you cannot use all the memory. No, you cannot use all the cores. No, you have these and those limits. And also this list of issues. And this and that is 90s stuff. Imagine what they will think and do...
Now that the work on ABI 1, 64 bits and multicore (and even OpenGL) is going somewhere, it seems like the perfect moment to create a "clean" version of Aros with all these features, with a minimal distro as base to start porting apps, which surely will take some effort, but not too much, and soon will have a lot of the already existing software ported. With a decent IDE and a browser, it will be the ONLY way to attract new developers (or returning old ones) and users.
-
Let me turn that question back at you: what would your "clean" AROS port that has virtually no software available offer compared to Linux? People with nostalgia would play around with it a bit, and then go back to Linux and Amiga emulation. An x64 port of MorphOS would face the same issue. On the other hand, if it offers the same level of 68k integration as MOS or OS4 currently on PPC, then you have an NG Amiga OS that can run system friendly Amiga programs out of the box, and could potentially offer more features for native software (access to more memory, set the processor affinity for threads, etc.). This is why Michal decided to target big endian ARM to begin with.
-
Let me turn that question back at you: what would your "clean" AROS port that has virtually no software available offer compared to Linux? People with nostalgia would play around with it a bit, and then go back to Linux and Amiga emulation. An x64 port of MorphOS would face the same issue. On the other hand, if it offers the same level of 68k integration as MOS or OS4 currently on PPC, then you have an NG Amiga OS that can run system friendly Amiga programs out of the box, and could potentially offer more features for native software (access to more memory, set the processor affinity for threads, etc.). This is why Michal decided to target big endian ARM to begin with.
+1
You can not make a new 64-bit system supporting multi-core etc. etc. and think that you can port back any classic software like DOpus. A fork of AROS "Amiga OS structure" would require new development suite, it would require so many developers and time that it will not very likely ever be a success.
Amiberry is nothing more than a classic 68k emulator that sucks. At least compared to WinUAE.
AROS for Pi will be a mix of classic and NG.
-
Let me turn that question back at you: what would your "clean" AROS port that has virtually no software available offer compared to Linux? People with nostalgia would play around with it a bit, and then go back to Linux and Amiga emulation. An x64 port of MorphOS would face the same issue. On the other hand, if it offers the same level of 68k integration as MOS or OS4 currently on PPC, then you have an NG Amiga OS that can run system friendly Amiga programs out of the box, and could potentially offer more features for native software (access to more memory, set the processor affinity for threads, etc.). This is why Michal decided to target big endian ARM to begin with.
Are you comparing with Linux? really there was no better answer than that?? that option is always there, but I didn't mean that the first version it is aimed at new users, and the porting of apps is not so hard, as Paolo is already proving and doing. ;)
But Aros is precisely for people who don't like linux for many reasons, because there are reasons for that, but you have to offer a viable alternative. Something kind of serious. It was said so many times here that a lot of users could like it for their Pi because its ease of use against the demanding knowledge of linux. And it could even compete in responsiveness.
Or ok: forget it. Let's stick forever behind everything else and being always supporting ancient features with ancient solutions until we get completely dissolved in computing history, as it is already happening. I say there is a chance for having a future, you say there is no future, let it die peacefully.
-
Or ok: forget it. Let's stick forever behind everything else and being always supporting ancient features with ancient solutions until we get completely dissolved in computing history, as it is already happening. I say there is a chance for having a future, you say there is no future, let it die peacefully.
That's exactly what my goal is, so I'm glad we agree at least on this point ;)
-
x-vision: Why do you think porting of apps. is not so hard? It is cause it is from other Amiga ports that we are compatible with. No offence to Paolo but he did not port any advanced stuff.
At once we break Amiga compatibility it is very hard porting software from anything. Even how powerfull AROS have been compared to other Amiga like platform it is not we took huge advantage of it. Why you think Amiga classic is way more popular than any Amiga NG system? It is cause it have lot's of good software and games. I don't even see the need for so up to date hardware. Greatest update to PC hardware the last years been SSD unless you like to play the most advanced games.
Regarding Pi we will have a very cheap NG Amiga system. If people like BSzili will use it I'm sure he will port lot of stuff to it as he already done to AROS. That will at least make me happy. It is something for fun. Whatever Amiga system will die when we are gone. I agree ;)
-
Personally I have no interest in Pi, but it's obvious there is enough interest for AROS to explore that direction. Although, I'll bet that some out there would prefer to see Os4 on Pi. ::)
-
Personally I have no interest in Pi, but it's obvious there is enough interest for AROS to explore that direction. Although, I'll bet that some out there would prefer to see Os4 on Pi. ::)
I would prefer i386, amd64 as well. The problem is that it is not a success. Where can we be more successfull and why are we not more successfull already?
First and foremost software is everything. OS without software is nothing. We have a lot of software for AROS but most are no good. The ones that are good you can also find on other platforms except Zune tools like Zunepaint and Zuneview.
Since AROS is an Amiga clone I'm sure integration with classic is very important and where never good enough. Integration in Amiga NG and MorphOS where better and felt more like native. That might change with Pi.
Pi is also cheap and future proof with arm onboard. We will probably never see anything new from PPC unless something fpga but that is not very likely.
-
PowerPC is not dead..
There is the Power9 Processor from IBM and a very Powerfull Workstation System with Power9 CPU
https://www.raptorcs.com/TALOSII/
-
PowerPC is not dead..
There is the Power9 Processor from IBM and a very Powerfull Workstation System with Power9 CPU
https://www.raptorcs.com/TALOSII/
...it's just on life support.
Let's try to stay on topic.
-
x-vision: Why do you think porting of apps. is not so hard? It is cause it is from other Amiga ports that we are compatible with. No offence to Paolo but he did not port any advanced stuff.
At once we break Amiga compatibility it is very hard porting software from anything. Even how powerfull AROS have been compared to other Amiga like platform it is not we took huge advantage of it.
Advanced stuff is never easy to port, but once GCC is in good condition, porting to 64 bits won't be specially complicated. If you said making something multicore, or translating all the graphic tasks taking advantage of latest OpenGL, etc... I would maybe agree. But worrying too much about 64bits sounds like a lame excuse.
Why you think Amiga classic is way more popular than any Amiga NG system? It is cause it have lot's of good software and games. I don't even see the need for so up to date hardware. Greatest update to PC hardware the last years been SSD unless you like to play the most advanced games.
NOSTALGIA. Just that. I won't even comment on the pc hardware statement because it so... :facepalm:
Regarding Pi we will have a very cheap NG Amiga system. If people like BSzili will use it I'm sure he will port lot of stuff to it as he already done to AROS. That will at least make me happy. It is something for fun. Whatever Amiga system will die when we are gone. I agree ;)
I disagree. I am AGAINST that. So I think you better suit to OS3 or OS4 fans than Aros, because with that attitude Aros would have never been done. Apple would have never move from MacOS 8 to X, etc, etc... I could keep bringing examples for ages.
Personally I have no interest in Pi, but it's obvious there is enough interest for AROS to explore that direction. Although, I'll bet that some out there would prefer to see Os4 on Pi. ::)
I would prefer i386, amd64 as well. The problem is that it is not a success. Where can we be more successfull and why are we not more successfull already?
First and foremost software is everything. OS without software is nothing. We have a lot of software for AROS but most are no good. The ones that are good you can also find on other platforms except Zune tools like Zunepaint and Zuneview.
Since AROS is an Amiga clone I'm sure integration with classic is very important and where never good enough. Integration in Amiga NG and MorphOS where better and felt more like native. That might change with Pi.
Pi is also cheap and future proof with arm onboard. We will probably never see anything new from PPC unless something fpga but that is not very likely.
Always looking to the past eh? PPC, really?? I have some news: old software is not important anymore. Even Directory Opus is not important anymore, and even rejected by many users, as Paolo recently found out. Run Amiga software? sure, but it is not the most important feature anymore. A good emulation layer it's more than enough. It is more important to take care of the present and the future, as Aros developers always knew (when they thought they would have to support new hardware, new features, and improve already ancient features, they needed to create new ones) this day would come. Keeping always stuck in the past is more comforting, but it is also the path to death.
If you don't risk, you'll never win. ;)
-
X-vision: So what software for AROS is so important to run? Software development take years to bring to perfection. There are some ports from SDL and very few native apps. Classic have lots of games, scene productions and apps. that are really good. Not found on other platforms. I'm not using classic Amiga cause it bring back memories. I don't like that much the games released anymore. There are some like Dirt Rally 1 and 2 + Rocket league but I enjoy mostly older games. Recently I played R-type Delta on PS1 a lot. Even new consoles bring back old titles and they start to sell Nintendo and Super Nintendo hardware again. Problem is that it look mostly crap on digital display, but that most don't understand.
On classic there are many quality releases, mostly from the scene. www.pouet.net
Last year we got a great Amiga 500 commercial game called Worty. This year Amiga 1200 game Reshoot R.
AROS have a chance to be a bridge between classic and new. That is in my opinion the only way it can be successful. It will never be mainstream.
-
Let me turn that question back at you: what would your "clean" AROS port that has virtually no software available offer compared to Linux? People with nostalgia would play around with it a bit, and then go back to Linux and Amiga emulation. An x64 port of MorphOS would face the same issue. On the other hand, if it offers the same level of 68k integration as MOS or OS4 currently on PPC, then you have an NG Amiga OS that can run system friendly Amiga programs out of the box, and could potentially offer more features for native software (access to more memory, set the processor affinity for threads, etc.). This is why Michal decided to target big endian ARM to begin with.
Are you comparing with Linux? really there was no better answer than that?? that option is always there, but I didn't mean that the first version it is aimed at new users, and the porting of apps is not so hard, as Paolo is already proving and doing. ;)
But Aros is precisely for people who don't like linux for many reasons, because there are reasons for that, but you have to offer a viable alternative. Something kind of serious. It was said so many times here that a lot of users could like it for their Pi because its ease of use against the demanding knowledge of linux. And it could even compete in responsiveness.
Or ok: forget it. Let's stick forever behind everything else and being always supporting ancient features with ancient solutions until we get completely dissolved in computing history, as it is already happening. I say there is a chance for having a future, you say there is no future, let it die peacefully.
Compete with Linux? What drugs do you take? I want them too ;D
Seriously Aros cannot compete with mainstream platforms (and Linux is mainstream too)
And "future" is a big word, you certainly define "future" different than other people
Even if Aros would be modern in todays sense (full memory protection, SMP, 64bit and so on) it would still be a small exotic platform and not get new software, even worse all existing software would no longer run on it. A new platform without software and money behind it, looks like a success :D
BTW you are always mentioning "we" in your posts
Who is the group you are talking for?
Everyone here is talking for himself. You do do not like RPi? No problem you do not need to use it. You want to add new features to Aros? No problem Aros is open source. If you cannot do that because of no knowledge then you have to accept whatever direction others are heading with Aros.
-
Let me turn that question back at you: what would your "clean" AROS port that has virtually no software available offer compared to Linux? People with nostalgia would play around with it a bit, and then go back to Linux and Amiga emulation. An x64 port of MorphOS would face the same issue. On the other hand, if it offers the same level of 68k integration as MOS or OS4 currently on PPC, then you have an NG Amiga OS that can run system friendly Amiga programs out of the box, and could potentially offer more features for native software (access to more memory, set the processor affinity for threads, etc.). This is why Michal decided to target big endian ARM to begin with.
Are you comparing with Linux? really there was no better answer than that?? that option is always there, but I didn't mean that the first version it is aimed at new users, and the porting of apps is not so hard, as Paolo is already proving and doing. ;)
But Aros is precisely for people who don't like linux for many reasons, because there are reasons for that, but you have to offer a viable alternative. Something kind of serious. It was said so many times here that a lot of users could like it for their Pi because its ease of use against the demanding knowledge of linux. And it could even compete in responsiveness.
Or ok: forget it. Let's stick forever behind everything else and being always supporting ancient features with ancient solutions until we get completely dissolved in computing history, as it is already happening. I say there is a chance for having a future, you say there is no future, let it die peacefully.
Compete with Linux? What drugs do you take? I want them too ;D
Seriously Aros cannot compete with mainstream platforms (and Linux is mainstream too)
And "future" is a big word, you certainly define "future" different than other people
Even if Aros would be modern in todays sense (full memory protection, SMP, 64bit and so on) it would still be a small exotic platform and not get new software, even worse all existing software would no longer run on it. A new platform without software and money behind it, looks like a success :D
First of all: Respect. We are trying to have a constructive discussion here, no need to make this forum a new Moobunny or Ann.lu
Second: maybe instead of asking for new drugs, you need to remove some (or ask for) what is affecting your eyes, because I never said Aros can compete with linux (just maybe, and I remark maybe, in responsiveness, nothing more). I just remembered that lots of people don't like Linux and prefer alternatives if they are available, and there were around 10 million Amiga users at some moment, many of them technology geeks who buy Raspberry Pis, and would love to try an Amiga system on them. This is a great target audience for Aros, so we should not miss it offering a capped system (no memory, no multicore, etc...).
But all this seems like a pointless discussion also because there is already an ongoing m68K JIT emulator in ARM Aros being developed by M.Schulz (https://www.patreon.com/posts/always-remember-24683131) and he is aware of how troublesome is trying to stay BigEndian, so the only future proof path is to properly support all the available resources of the hardware, not trying to cut our wings again and again and once more, just for nostalgic reasons.
I don't even see the point of all this already: old software and games were not ready for: hd install, 3d hardware supported graphics, audio hardware different from paula, even some behave bad when the processor runs higher than 7 Mhz, so, what should we do? stick to that? or create patches and emulation layers to support old software, but from a modern system? it is obvious we cannot keep stuck to 30 yo hardware, and code which in some cases just run in hardware which is not even supported anymore.
-
I have a Pi Zero and one of the first Pi's ever made, I don't have real use for them. I bought Pi3 I think for my 10 year old son (He likes to run the old game emulator on it, NES and such... Or atleats when he gets of dicking around with Unity. There's some insane shit he does with it, I have no glue. I blame Brackeys for it, https://www.youtube.com/user/Brackeys/videos) That's my retirement plan... It's that or Formula 1 or icehockey, not much to choose from.
Pi's are really slow running a Linux desktop, painfully slow. AROS/AmigaOS shell beats that in a heartbeat, not to mention Workbench. Pi's aren't used or can't be used for replacement of Linux running on multicore and fast GPU... It's just too slow for it and still it has a gigahertz CPU and decent GPU... Distros of Pi OS are also huge...
Pi's seem to run mostly some scripts and network stuff, you know, internet of things... We could make that less painfull atleast for the scripting part? I have no idea what scripts are run when I fire up my Fedora 30. Also as I've done some USB serial things with my stm32 endevour I had to remove Bluetooth from Linux... It always tried to communicate with my serial device... AT commands what?!? Where are they coming from?!? Why?!? I seem to have no control over my machine... Everything needs privileges even if they are physically connected to my computer and I specificly run a certain program... Let's wait until the keyboard and mouse needs privileges, that's a no no regarding security...
Even the baremetal guys are cooking up some sort of OS for their OS'less systems, maybe we can tap into that niche?
-
b-plan didn't succeed with morphos either years ago, and yet the systems were perfomant, server side linux says a lot on the mainstream side, many use windows to play "I'd say a lot", macos is a platform for software side professionals, I use aros because in the past I used to use amiga, and who uses these systems I think they did like me once.
"What's the worry?", I think we'll have the x86_64 bit version and later it will support multicore:
"the software?"
we will never have adobe suites, you have to be realistic, but maybe updated owb and some other utility software.
I can make music with aros, I'm not a professional but I can carry on my hobby quietly.
Translated with www.DeepL.com/Translator
-
I'd prefer x86-64 related things being kept outside of a Raspberry Pi discussion.
But, since I've been mentioned, I would like to make these clear:
1. I am no coder at all and I am NOT porting anything. I am only trying, from time to time, to COMPILE sources that others have written, using the AROS build environment.
2. PORTING and COMPILING are two very different kind-of efforts. PORTING would mean handling the sources and modifying them to follow rules and best practices I don't even know about. For instance, if I have correctly understood, replacing all 32-bit only structures (LONG?) with 64bit friendly ones. COMPILING just means let those sources build with a 'make' command. The former is a far more difficult operation than the latter.
3. If a program compiles at first, I am happy. If a program does not compile and I can fix this by editing a mmakefile.src file, I'm less happy but more proud of the result. But if a program does not compile due to 64bit incompatibilities, or to other language specific mistakes, or to unknown options (flags?) I should pass the crosscompiler... well... I simply stop and ask more skilled people to do that instead of me.
Do not underestimate the effort needed to PORT a big project from an architecture to another. I wonder how many years it will take, for instance, to port Magellan to x86-64. And, on the contrary of what I've read here, it *IS* a important program to me, since it's the default GUI of my operating environment. Moreover, most of Icaros goodies are available only if Magellan is the working GUI of the system. I'm really not so interested in people "rejecting" it.
-
Yes. DOpus from version 4 and up is why many use or used AmigaOS. It is a true workbench replacement if you like. I know some don't like it but that is how it is with everything. Personaly I love it. AmigaOS or Amiga like OS is not the same without it.
Like Paolo say it might be a nightmare to port to 64-bit. Maybe that is another reason to stay 32-bit with Pi version.
-
So, over two years have passed, we had a global pandemic, people did stuff. What is the status of the Raspberry Pi version now? Have the USB woes been solved? I tried booting the latest raspi-armhf-system nightly on my Raspberry Pi 3, but it just hangs at a black screen after the rainbow screen, so I guess things still haven't moved.
-
Yup! You pretty much summed it up.
The focus on RPi has shifted on this 68K emulator called Emu68 which runs as a bare metal emulator for then run 68K version of Amiga OS. However, the work is being done mostly on the Pistorm versions and only with AmigaOS 3.x.
The author MichalsC is also releasing a version of Emu68 for standard RPi but I think no one has managed to boot AROS 68K on a RPi with Emu68 yet.
The RPi shows the Emu68 boot logo but nothing happens when attempting to bootstrap AROS.
https://github.com/michalsc/Emu68/releases (https://github.com/michalsc/Emu68/releases)
-
What advantage does that have over just using UAE on Linux? We are already able to emulate AmigaOS on a Raspberry Pi. Running AROS natively would be something new.
-
Without any doubt, WinUAE is the best solution to use AROS 68k
https://www.youtube.com/watch?v=y2Sh5jWZOYA
-
Yup! You pretty much summed it up.
The focus on RPi has shifted on this 68K emulator called Emu68 which runs as a bare metal emulator for then run 68K version of Amiga OS. However, the work is being done mostly on the Pistorm versions and only with AmigaOS 3.x.
The author MichalsC is also releasing a version of Emu68 for standard RPi but I think no one has managed to boot AROS 68K on a RPi with Emu68 yet.
The RPi shows the Emu68 boot logo but nothing happens when attempting to bootstrap AROS.
https://github.com/michalsc/Emu68/releases (https://github.com/michalsc/Emu68/releases)
Really? As far as I know Caffeine OS from Pedro Cotter boots on PiStorm at least and is based on Aros 68k using magellan as desktop
-
Yup! You pretty much summed it up.
The focus on RPi has shifted on this 68K emulator called Emu68 which runs as a bare metal emulator for then run 68K version of Amiga OS. However, the work is being done mostly on the Pistorm versions and only with AmigaOS 3.x.
The author MichalsC is also releasing a version of Emu68 for standard RPi but I think no one has managed to boot AROS 68K on a RPi with Emu68 yet.
The RPi shows the Emu68 boot logo but nothing happens when attempting to bootstrap AROS.
https://github.com/michalsc/Emu68/releases (https://github.com/michalsc/Emu68/releases)
Really? As far as I know Caffeine OS from Pedro Cotter boots on PiStorm at least and is based on Aros 68k using magellan as desktop
Someone correct me if I'm wrong, but I think Caffeine OS requires the PiStorm add-on board for the Raspberry Pi, while Emu68 aims to work with or without PiStorm.
Apparently, qemu can emulate Raspberry Pi 1, 2, and 3 these days, so assuming the hw emulation is accurate enough, it would allow easier and quicker debugging than real hardware, without needing to write the SD card every time or needing a USB serial adapter to capture UART.
-
Yup! You pretty much summed it up.
The focus on RPi has shifted on this 68K emulator called Emu68 which runs as a bare metal emulator for then run 68K version of Amiga OS. However, the work is being done mostly on the Pistorm versions and only with AmigaOS 3.x.
The author MichalsC is also releasing a version of Emu68 for standard RPi but I think no one has managed to boot AROS 68K on a RPi with Emu68 yet.
The RPi shows the Emu68 boot logo but nothing happens when attempting to bootstrap AROS.
https://github.com/michalsc/Emu68/releases (https://github.com/michalsc/Emu68/releases)
The logic behind has to do with creating the most accurate 68k emulator, afterwards he can then use AROS once it got to a good level.
-
Without native AROS 68k software and without a native AROS 68k "lacking OS3 system software," there can never be real compatibility testing.
The OS3.0/3.1 software pool runs 50/100, of which a 30/100 runs poorly; the 3.9 and 3.2 software is not 100/100 compatible on AROS 68k.
In my opinion one should test these hardware only with "clean" native AROS 68k without the presence of any OS3 software.
-
Afterwards he will concentrate running 100% aros, I was not talking about running AmigaOS inside AROS
-
Yes but you can't test AROS 68k with distributions where there is a lot of OS3 software and very little native AROS 68k software "of system" :)
In the end you will never understand, where the incompatibilities come from.
-
Yup! You pretty much summed it up.
The focus on RPi has shifted on this 68K emulator called Emu68 which runs as a bare metal emulator for then run 68K version of Amiga OS. However, the work is being done mostly on the Pistorm versions and only with AmigaOS 3.x.
The author MichalsC is also releasing a version of Emu68 for standard RPi but I think no one has managed to boot AROS 68K on a RPi with Emu68 yet.
The RPi shows the Emu68 boot logo but nothing happens when attempting to bootstrap AROS.
https://github.com/michalsc/Emu68/releases (https://github.com/michalsc/Emu68/releases)
Really? As far as I know Caffeine OS from Pedro Cotter boots on PiStorm at least and is based on Aros 68k using magellan as desktop
PiStorm is not the same as RPi. Pistorm is an Amiga add-on card which uses a RPi as a piggyback card to emulate CPU, and other components.
I am referring to a standard RPi 3/4/400, standalone here. There is no AROS that can boot natively on it. Only solution may be ARM Linux with UAE emulating Amiga 68K and then load AROS 68K. At this point it's so convoluted that it defeats the purpose of running AROS on it.
-
Really? As far as I know Caffeine OS from Pedro Cotter boots on PiStorm at least and is based on Aros 68k using magellan as desktop
Are you sure that "Caffeine OS" is based on AROS 68k? have you ever tried to boot it with AROS Roms. :)
-
Tried to build the Raspberry Pi version, but alas, it fails.
[MMAKE] Making kernel-kernel-arm in arch/arm-all/kernel
Compiling arch/arm-all/kernel/cpu_init.c
Compile failed: /home/ninja/programming/aros-rpi/AROS/bin/linux-x86_64/tools/crosstools/arm-aros-gcc -iquote /home/ninja/programming/aros-rpi/AROS/arch/arm-all/kernel/ -iquote /home/ninja/programming/aros-rpi/AROS/rom/kernel -iquote /home/ninja/programming/aros-rpi/AROS/arch/arm-all/kernel -iquote . -marm -mfloat-abi=hard -mlittle-endian -march=armv7-a -mfpu=vfpv3-d16 -O2 -fno-common -fno-unwind-tables -fno-asynchronous-unwind-tables -fno-exceptions -Wno-pointer-sign -Wno-parentheses -I/home/ninja/programming/aros-rpi/AROS/arch/arm-native/kernel -I/home/ninja/programming/aros-rpi/AROS/arch/arm-all/kernel -I/home/ninja/programming/aros-rpi/AROS/rom/kernel -I/home/ninja/programming/aros-rpi/AROS/arch/arm-native/exec -I/home/ninja/programming/aros-rpi/AROS/arch/arm-all/exec -I/home/ninja/programming/aros-rpi/AROS/rom/exec -I/home/ninja/programming/aros-rpi/AROS/bin/raspi-arm/gen/include -DAROS_BUILD_TYPE=AROS_BUILD_TYPE_PERSONAL -D__AROS_EXEC_LIBRARY__ -I/home/ninja/programming/aros-rpi/AROS/bin/raspi-arm/gen/rom/kernel/kernel -include /home/ninja/programming/aros-rpi/AROS/bin/raspi-arm/gen/rom/kernel/kernel/include/kernel_deflibdefs.h -D__SRCFILENAME__="arch/arm-all/kernel/cpu_init.c" -c /home/ninja/programming/aros-rpi/AROS/arch/arm-all/kernel/cpu_init.c -o /home/ninja/programming/aros-rpi/AROS/bin/raspi-arm/gen/rom/kernel/kernel/arch/cpu_init.o
In file included from /home/ninja/programming/aros-rpi/AROS/arch/arm-native/kernel/kernel_arch.h:9:0,
from /home/ninja/programming/aros-rpi/AROS/rom/kernel/kernel_base.h:24,
from /home/ninja/programming/aros-rpi/AROS/arch/arm-all/kernel/cpu_init.c:8:
/home/ninja/programming/aros-rpi/AROS/arch/arm-native/kernel/kernel_cpu.h:21:24: error: redefinition of 'struct ExceptionContext'
#define AROSCPUContext ExceptionContext
^
/home/ninja/programming/aros-rpi/AROS/rom/kernel/kernel_cpu.h:21:8: note: in expansion of macro 'AROSCPUContext'
struct AROSCPUContext
^~~~~~~~~~~~~~
In file included from /home/ninja/programming/aros-rpi/AROS/bin/raspi-arm/gen/include/exec/interrupts.h:23:0,
from /home/ninja/programming/aros-rpi/AROS/bin/raspi-arm/gen/include/exec/execbase.h:13,
from /home/ninja/programming/aros-rpi/AROS/bin/raspi-arm/gen/include/aros/symbolsets.h:14,
from /home/ninja/programming/aros-rpi/AROS/arch/arm-all/kernel/cpu_init.c:5:
/home/ninja/programming/aros-rpi/AROS/bin/raspi-arm/gen/include/aros/arm/cpucontext.h:12:8: note: originally defined here
struct ExceptionContext
^~~~~~~~~~~~~~~~
In file included from /home/ninja/programming/aros-rpi/AROS/arch/arm-native/kernel/kernel_arch.h:9:0,
from /home/ninja/programming/aros-rpi/AROS/rom/kernel/kernel_base.h:24,
from /home/ninja/programming/aros-rpi/AROS/arch/arm-all/kernel/cpu_init.c:8:
/home/ninja/programming/aros-rpi/AROS/arch/arm-native/kernel/kernel_cpu.h:19:16: error: two or more data types in declaration specifiers
#define regs_t struct ExceptionContext
^
/home/ninja/programming/aros-rpi/AROS/rom/kernel/kernel_cpu.h:26:31: note: in expansion of macro 'regs_t'
typedef struct AROSCPUContext regs_t;
^~~~~~
/home/ninja/programming/aros-rpi/AROS/arch/arm-native/kernel/kernel_cpu.h:19:23: warning: empty declaration with storage class specifier does not redeclare tag
#define regs_t struct ExceptionContext
^
/home/ninja/programming/aros-rpi/AROS/rom/kernel/kernel_cpu.h:26:31: note: in expansion of macro 'regs_t'
typedef struct AROSCPUContext regs_t;
^~~~~~
In file included from /home/ninja/programming/aros-rpi/AROS/arch/arm-all/kernel/cpu_init.c:9:0:
/home/ninja/programming/aros-rpi/AROS/rom/kernel/kernel_cpu.h:36:0: warning: "krnSysCall" redefined
#define krnSysCall(num)
In file included from /home/ninja/programming/aros-rpi/AROS/arch/arm-native/kernel/kernel_arch.h:9:0,
from /home/ninja/programming/aros-rpi/AROS/rom/kernel/kernel_base.h:24,
from /home/ninja/programming/aros-rpi/AROS/arch/arm-all/kernel/cpu_init.c:8:
/home/ninja/programming/aros-rpi/AROS/arch/arm-native/kernel/kernel_cpu.h:36:0: note: this is the location of the previous definition
#define krnSysCall(n) asm volatile ("swi %[swi_no]\n\t" : : [swi_no] "I" (n) : "lr");
make[1]: *** [mmakefile:183: /home/ninja/programming/aros-rpi/AROS/bin/raspi-arm/gen/rom/kernel/kernel/arch/cpu_init.o] Error 1
[MMAKE] make --no-print-directory TOP=/home/ninja/programming/aros-rpi/AROS SRCDIR=/home/ninja/programming/aros-rpi/AROS CURDIR=arch/arm-all/kernel TARGET=kernel-kernel-arm --file=mmakefile kernel-kernel-arm failed: 512
[MMAKE] Error: Error while running make in arch/arm-all/kernel: No such file or directory
make: *** [Makefile:125: all] Error 10
Looks like someone is using #define instead of typedef. tsk, tsk, tsk
Seems like this commit here https://github.com/aros-development-team/AROS/commit/ed59c9e54ba9ec6533a82d049df32ee9217f6a02#diff-d04b28469b2577b15154d0d5e3b951ee7d988775048a0e3341de0d35a845a8e1 broke it.
-
So, I swapped the include order in cpu_init.c so that kernel_cpu.h is included before kernel_base.h, and that seemed to fix that one error.
But there's another issue.
make[1]: *** No rule to make target 'scanf-examples.c', needed by '/home/ninja/programming/aros-rpi/AROS/bin/raspi-arm/gen/developer/debug/test/crt/posixc/scanf-examples.o'. Stop.
[MMAKE] make --no-print-directory TOP=/home/ninja/programming/aros-rpi/AROS SRCDIR=/home/ninja/programming/aros-rpi/AROS CURDIR=developer/debug/test/crt/posixc TARGET=test-crt-posixc-posix1-scanf --file=mmakefile test-crt-posixc-posix1-scanf failed: 512
[MMAKE] Error: Error while running make in developer/debug/test/crt/posixc: No such file or directory
make: *** [Makefile:125: all] Error 10
-
Really? As far as I know Caffeine OS from Pedro Cotter boots on PiStorm at least and is based on Aros 68k using magellan as desktop
Are you sure that "Caffeine OS" is based on AROS 68k? have you ever tried to boot it with AROS Roms. :)
I am sure. It was official OS on Apollo V4 before they officially switched to ApolloOS. Pedro Cotter then continued for its own
-
Yes but you can't test AROS 68k with distributions where there is a lot of OS3 software and very little native AROS 68k software "of system" :)
In the end you will never understand, where the incompatibilities come from.
I hope with time more and more x86 binaries get compiled over 68k
-
So, I swapped the include order in cpu_init.c so that kernel_cpu.h is included before kernel_base.h, and that seemed to fix that one error.
But there's another issue.
make[1]: *** No rule to make target 'scanf-examples.c', needed by '/home/ninja/programming/aros-rpi/AROS/bin/raspi-arm/gen/developer/debug/test/crt/posixc/scanf-examples.o'. Stop.
[MMAKE] make --no-print-directory TOP=/home/ninja/programming/aros-rpi/AROS SRCDIR=/home/ninja/programming/aros-rpi/AROS CURDIR=developer/debug/test/crt/posixc TARGET=test-crt-posixc-posix1-scanf --file=mmakefile test-crt-posixc-posix1-scanf failed: 512
[MMAKE] Error: Error while running make in developer/debug/test/crt/posixc: No such file or directory
make: *** [Makefile:125: all] Error 10
These error most likely comes from not initialized gitmodules. Try this
git submodule update --init --recursive
Also please note that raspi-armhf target is failing to build on nightly builds right now (https://github.com/aros-development-team/AROS, bottom of page)
-
I am sure. It was official OS on Apollo V4 before they officially switched to ApolloOS. Pedro Cotter then continued for its own
To be sure of what you write you have to try it for yourself.
Read this review of CaffeineOS Testing Online Updater Versione vampiro:
https://www.youtube.com/watch?v=pvphkgy-J9w
Starting with CaffeineOS_Vampire Version 852, the updates can be performed On Line.
Aros version is next.
CaffeineOS 797 ( Amiga Emulation on the next level)
CaffeineOS is a great Amiga OS filled with many application and games and it runs very stable. you should try this out !!!
https://youtu.be/MV6snYm-NLk
-
This means that the versions of CaffeineOS released in recent times did not include AROS 68k, in my screenshot of CaffeineOS downloaded a few months ago, as you can see there is no AROS 68k system software, also only starts with kickstart 3.1
So a distinction must be made between "Aros Caffeine (ApolloOS)" and "CaffeineOS"
(https://ae.amigalife.org/index.php?action=dlattach;topic=176.0;attach=5055;image)
-
that indeed looks like something based on 3.X and not on Aros 68k. It seems he changed it. Low level stuff like MCP not works in Aros 68k and Overscan not exists on Aros 68k. And typical Aros prefs like Zune are not existing. It explains why f.e. IBrowse works in it. I have read a little on discord. It seems he supported different platforms in past with it (Apollo, PiStorm, WinUAE) and reduced it to PiStorm where only 3.X is working.
-
So, I swapped the include order in cpu_init.c so that kernel_cpu.h is included before kernel_base.h, and that seemed to fix that one error.
But there's another issue.
make[1]: *** No rule to make target 'scanf-examples.c', needed by '/home/ninja/programming/aros-rpi/AROS/bin/raspi-arm/gen/developer/debug/test/crt/posixc/scanf-examples.o'. Stop.
[MMAKE] make --no-print-directory TOP=/home/ninja/programming/aros-rpi/AROS SRCDIR=/home/ninja/programming/aros-rpi/AROS CURDIR=developer/debug/test/crt/posixc TARGET=test-crt-posixc-posix1-scanf --file=mmakefile test-crt-posixc-posix1-scanf failed: 512
[MMAKE] Error: Error while running make in developer/debug/test/crt/posixc: No such file or directory
make: *** [Makefile:125: all] Error 10
These error most likely comes from not initialized gitmodules. Try this
git submodule update --init --recursive
Also please note that raspi-armhf target is failing to build on nightly builds right now (https://github.com/aros-development-team/AROS, bottom of page)
Thanks. Is there a compiling guide besides the one here (http://www.aros.org/documentation/developers/compiling.php#building), which is probably really out of date (it mentions gcc 3.2.2 lol)?
Just for the heck of it, I tried building hosted AROS on my Pi, but ran into an error with the compiler options. I don't think the compiler version I have installed would matter, since the build system downloads and builds gcc 6.5.0 anyway. I just ran ./configure with no args to build hosted.
Compiling /home/pi/AROS/compiler/libinit/libentry.c
arm-aros-gcc: error: missing argument to '-mfpu='
arm-aros-gcc: error: missing argument to '-mfpu='
arm-aros-gcc: error: unrecognized command line option '-marmlittle-endian'; did you mean '-mlittle-endian'?
arm-aros-gcc: error: unrecognized command line option '-marmlittle-endian'; did you mean '-mlittle-endian'?
make[1]: *** [mmakefile:574: /home/pi/AROS/bin/linux-arm/gen/compiler/libinit/libentry.o] Error 1
[MMAKE] make --no-print-directory TOP=/home/pi/AROS SRCDIR=/home/pi/AROS CURDIR=compiler/libinit TARGET=libinit-libentry --file=mmakefile libinit-libentry failed: 512
[MMAKE] Error: Error while running make in compiler/libinit: No such file or directory
make: *** [Makefile:125: all] Error 10
-
@NinjaCowboy
Unfortunately I don't think there is a newer guide. I also never tried building hosted directly on the Pi. I did build armhf-hosted some time ago on my x86 64-bit machine. If you have one you can try following these instructions
https://github.com/deadw00d/AROS/blob/master/INSTALL.md
and selecting first the armhf toolchain and them armhf hosted. I do remember I had to uninstall some package from linux or I was getting conflicts during compilation. The armhf targets are not officially supported/maintained in my repo.
-
So, apparently, I was able to get raspi-armhf native to build with few issues by configuring in a separate build directory (Well, actually I did have to comment out the build rule for workbench-datatypes-heic, since that library tries to use C++ exceptions, even though they are disabled in the compiler flags). No idea why it decided to work this time.
I've started debugging with qemu and gdb, but I've noticed something strange. Many of the jump labels are offset by +8, and this seems to make function calls not work properly (basically skipping the function prologue), and I can't breakpoint on functions either because of this. You can see this in the objdump output (notice the +0x8 on all the bl instructions).
AROS-build/bin/raspi-arm/gen/rom/boot/aros-arm-raspi.img.elf: file format elf32-littlearm
Disassembly of section .text:
00008000 <bootstrap>:
8000: e10f4000 mrs r4, CPSR
8004: e204401f and r4, r4, #31
8008: e3a0801a mov r8, #26
800c: e1540008 cmp r4, r8
8010: 0a000007 beq 8034 <leave_hyper>
00008014 <continue_boot>:
8014: f1020013 cps #19
8018: e59fd030 ldr sp, [pc, #48] ; 8050 <tmp_stack_ptr>
801c: ee114f50 mrc 15, 0, r4, cr1, cr0, {2}
8020: e384460f orr r4, r4, #15728640 ; 0xf00000
8024: ee014f50 mcr 15, 0, r4, cr1, cr0, {2}
8028: e3a04101 mov r4, #1073741824 ; 0x40000000
802c: eee84a10 vmsr fpexc, r4
8030: ea000096 b 8290 <boot+0x8>
00008034 <leave_hyper>:
8034: e24f4028 sub r4, pc, #40 ; 0x28
8038: e12ef304 .word 0xe12ef304
803c: e10f4000 mrs r4, CPSR
8040: e204401f and r4, r4, #31
8044: e3844013 orr r4, r4, #19
8048: e16ef304 .word 0xe16ef304
804c: e160006e .word 0xe160006e
00008050 <tmp_stack_ptr>:
8050: 00000ff0 45562400 61203a52 72736f72 .....$VER: arosr
8060: 69707361 676d692e 30347620 2036342e aspi.img v40.46
8070: 6e754a28 20323220 33323032 00000029 (Jun 22 2023)...
00008080 <query_vmem>:
8080: e92d40f0 push {r4, r5, r6, r7, lr}
8084: e30d0244 movw r0, #53828 ; 0xd244
8088: e24dd014 sub sp, sp, #20
808c: e3400000 movt r0, #0
8090: e3076000 movw r6, #28672 ; 0x7000
8094: e3406003 movt r6, #3
8098: eb0003c0 bl 8fa0 <kprintf+0x8>
809c: e3a03a01 mov r3, #4096 ; 0x1000
80a0: e3a05000 mov r5, #0
80a4: e3a04008 mov r4, #8
80a8: e3a02020 mov r2, #32
80ac: e5832000 str r2, [r3]
80b0: e5835004 str r5, [r3, #4]
80b4: e3a02006 mov r2, #6
80b8: e3402001 movt r2, #1
80bc: e5832008 str r2, [r3, #8]
80c0: e583400c str r4, [r3, #12]
80c4: e1a02003 mov r2, r3
80c8: e5835010 str r5, [r3, #16]
80cc: e30b7880 movw r7, #47232 ; 0xb880
80d0: e5835014 str r5, [r3, #20]
80d4: e1a01004 mov r1, r4
80d8: e5835018 str r5, [r3, #24]
80dc: e583501c str r5, [r3, #28]
80e0: e5960000 ldr r0, [r6]
80e4: e0870000 add r0, r7, r0
80e8: eb000444 bl 9200 <vcmb_write+0x8>
80ec: e5960000 ldr r0, [r6]
80f0: e1a01004 mov r1, r4
80f4: e0870000 add r0, r7, r0
80f8: e3a07003 mov r7, #3
80fc: eb000427 bl 91a0 <vcmb_read+0x8>
8100: e1a04000 mov r4, r0
8104: e5901014 ldr r1, [r0, #20]
8108: e5942018 ldr r2, [r4, #24]
810c: e30d025c movw r0, #53852 ; 0xd25c
8110: e3400000 movt r0, #0
8114: eb0003a1 bl 8fa0 <kprintf+0x8>
8118: e596c004 ldr ip, [r6, #4]
811c: e3a0301c mov r3, #28
8120: e34833d0 movt r3, #33744 ; 0x83d0
8124: e3a0201d mov r2, #29
8128: e34823d0 movt r2, #33744 ; 0x83d0
812c: e58c3000 str r3, [ip]
8130: e3a03001 mov r3, #1
8134: e5941014 ldr r1, [r4, #20]
8138: e28cc010 add ip, ip, #16
813c: e50c2008 str r2, [ip, #-8]
8140: e594e014 ldr lr, [r4, #20]
8144: e5942018 ldr r2, [r4, #24]
8148: e50c100c str r1, [ip, #-12]
814c: e5940014 ldr r0, [r4, #20]
8150: e08ee002 add lr, lr, r2
8154: e5941014 ldr r1, [r4, #20]
8158: e5942018 ldr r2, [r4, #24]
815c: e50ce004 str lr, [ip, #-4]
8160: e586c004 str ip, [r6, #4]
8164: e58d5008 str r5, [sp, #8]
8168: e88d00a0 stm sp, {r5, r7}
816c: eb00035d bl 8ee8 <mmu_map_section+0x8>
8170: e28dd014 add sp, sp, #20
8174: e8bd80f0 pop {r4, r5, r6, r7, pc}
It seems the raspi-armhf-system nightly from April 30th also has this issue.
-
If these are local functions, you might be looking at some form of optimization (not creating a new stack frame). Have you tried building with optimizations disabled? --enable-debug should do the trick. You can check OPTIMIZATION_CFLAGS in gen/config/target.cfg.
-
Ah, that makes sense. Most of my ARM coding experience is from GameBoy Advance programming, so I'm not familiar with compiler optimizations for modern ARM CPUs. Even if this code is correct, it does make debugging harder, since gdb is unable to break on the function name when the code jumps inside of it.
I recompiled everything after configuring with --enable-debug, but those branch instructions still have the +0x8 offset. In target.cfg, I see KERNEL_OPTIMIZATION_CFLAGS := -O0 and OPTIMIZATION_CFLAGS = $(strip -O0), so I assume it's disabling optimizations. How do I run make in verbose mode to see the full compiler commands as they are run to be sure?
EDIT: I figured out that make Q='' will print the compiler commands, but it shows that boot.c is still getting compiled with -O2 somehow.
It seems that these files are hardcoded to use -O2. https://github.com/aros-development-team/AROS/blob/master/arch/arm-raspi/boot/mmakefile.src#L13
I changed that to -O0. While that successfully disabled optimizations, the branches are still being offset by 8, skipping prologues and causing the stack to not be initialized properly.
I'd like to add the -S compiler option to output assembly, but I'm not familiar enough with this build system to know where the compile command is defined.
-
A hacky way is to add #error directive in .c file. This will fail the build but you will get the full command line displayed then. You can can copy-paste this command line to modify/get what you want.
-
In ARM, the PC register always points two instructions (8 bytes) ahead of the currently executing one due to prefetch. Any instructions that use the PC (such as branches) need to compensate for this by subtracting 8 from the offset.
I'm mainly looking at this "b boot" instruction in boot.c (https://github.com/aros-development-team/AROS/blob/master/arch/arm-raspi/boot/boot.c#L65), since it's the first one in the file but basically all function calls are affected.
The .o file seems to be compiled correctly with a R_ARM_JUMP24 reloc pointing to boot-0x8.
Disassembly of section .aros.startup:
00000000 <bootstrap>:
0: e10f4000 mrs r4, CPSR
4: e204401f and r4, r4, #31
8: e3a0801a mov r8, #26
c: e1540008 cmp r4, r8
10: 0a000007 beq 34 <leave_hyper>
00000014 <continue_boot>:
14: f1020013 cps #19
18: e59fd030 ldr sp, [pc, #48] ; 50 <tmp_stack_ptr>
1c: ee114f50 mrc 15, 0, r4, cr1, cr0, {2}
20: e384460f orr r4, r4, #15728640 ; 0xf00000
24: ee014f50 mcr 15, 0, r4, cr1, cr0, {2}
28: e3a04101 mov r4, #1073741824 ; 0x40000000
2c: eee84a10 vmsr fpexc, r4
30: ea000000 b 23c <boot+0x8>
30: R_ARM_JUMP24 boot-0x8
00000034 <leave_hyper>:
34: e24f4028 sub r4, pc, #40 ; 0x28
38: e12ef304 msr ELR_hyp, r4
3c: e10f4000 mrs r4, CPSR
40: e204401f and r4, r4, #31
44: e3844013 orr r4, r4, #19
48: e16ef304 msr SPSR_hyp, r4
4c: e160006e eret
but then it's wrong in aros-arm-raspi.img.elf
Disassembly of section .text:
00008000 <bootstrap>:
8000: e10f4000 mrs r4, CPSR
8004: e204401f and r4, r4, #31
8008: e3a0801a mov r8, #26
800c: e1540008 cmp r4, r8
8010: 0a000007 beq 8034 <leave_hyper>
00008014 <continue_boot>:
8014: f1020013 cps #19
8018: e59fd030 ldr sp, [pc, #48] ; 8050 <tmp_stack_ptr>
801c: ee114f50 mrc 15, 0, r4, cr1, cr0, {2}
8020: e384460f orr r4, r4, #15728640 ; 0xf00000
8024: ee014f50 mcr 15, 0, r4, cr1, cr0, {2}
8028: e3a04101 mov r4, #1073741824 ; 0x40000000
802c: eee84a10 vmsr fpexc, r4
8030: ea000096 b 8290 <boot+0x8>
8030: R_ARM_JUMP24 .text+0x280
00008034 <leave_hyper>:
8034: e24f4028 sub r4, pc, #40 ; 0x28
8038: e12ef304 msr ELR_hyp, r4
803c: e10f4000 mrs r4, CPSR
8040: e204401f and r4, r4, #31
8044: e3844013 orr r4, r4, #19
8048: e16ef304 msr SPSR_hyp, r4
804c: e160006e eret
...
00008288 <boot>:
8288: e92d4ef0 push {r4, r5, r6, r7, r9, sl, fp, lr}
828c: e3083050 movw r3, #32848 ; 0x8050
828c: R_ARM_MOVW_ABS_NC .LANCHOR1
8290: e24dd038 sub sp, sp, #56 ; 0x38
8294: e3403000 movt r3, #0
8294: R_ARM_MOVT_ABS .LANCHOR1
8298: e3025000 movw r5, #8192 ; 0x2000
8298: R_ARM_MOVW_ABS_NC .LANCHOR0
829c: e3405005 movt r5, #5
829c: R_ARM_MOVT_ABS .LANCHOR0
82a0: e58d3024 str r3, [sp, #36] ; 0x24
82a4: e1a09001 mov r9, r1
82a8: e5933000 ldr r3, [r3]
82ac: e1a06002 mov r6, r2
82b0: e58d2020 str r2, [sp, #32]
82b4: e2433c0e sub r3, r3, #3584 ; 0xe00
82b8: e5853004 str r3, [r5, #4]
The ea000096 instruction is a branch to pc+0x258 (0x96 * 4 = 0x258), but since pc is always 8 bytes ahead of the current instruction, it jumps to 0x8030+8+0x258 = 0x8290, which ends up being 8 bytes ahead of where it should be. The linker seems to ignore the addend (which is -8 here) for R_ARM_JUMP24 relocations. I also tried putting "b boot-8" in the source, but the linker still keeps ignoring the relocation addend for some reason.
-
I did some more experimentation, this appears to be a compiler issue, not a linker issue. If I edit arch/arm-raspi/boot/mmakefile.src and add add this after the include to simply use my system's ARM compiler instead of the AROS one, the relocations in aros-arm-raspi.img.elf and aros-arm-raspi.img resolve correctly!
TARGET_CC := arm-none-eabi-gcc \
-isystem $(AROSDIR)/Developer/include/aros/posixc \
-isystem $(AROSDIR)/Developer/include/aros/stdc \
-isystem $(AROSDIR)/Developer/include
I will test and see if any of the other AROS compilers besides the default gcc 6.5.0 produce the correct output.
-
From the builds page it looks like the nightly build is using GCC 9.1.0 in this case (and probably a different binutils as well)
-
I just tried with 9.1.0, and it still has the relocation bug. The last successful Raspberry Pi nightly from April also has the relocation bug. I wonder if it's something with how the compiler is configured. @mschulz was apparently able to get something to boot on the Pi. Not sure how he did it.
Actually, it's possible that it could be a problem with the assembler as well, since gcc doesn't produce .o files directly. It just generates assembly and calls "as" to assemble it into a .o file. I'll experiment with combinations of these more today.
Trying to build with llvm is probably not worth it, since there are no successful nightly builds done with it.
-
@mschulz is not on this forum, but you should be able to catch him on discord
-
Now I'm pretty sure that this is a binutils issue. I compiled boot.c with the AROS compiler and had it output assembly. I then assembled it with both the AROS binutils and my system's binutils (both are version 2.32) and used the same exact flags, but got different output for the branch instruction at address 30.
AROS binutils:
Disassembly of section .aros.startup:
00000000 <bootstrap>:
0: e10f4000 mrs r4, CPSR
4: e204401f and r4, r4, #31
8: e3a0801a mov r8, #26
c: e1540008 cmp r4, r8
10: 0a000007 beq 34 <leave_hyper>
00000014 <continue_boot>:
14: f1020013 cps #19
18: e59fd030 ldr sp, [pc, #48] ; 50 <tmp_stack_ptr>
1c: ee114f50 mrc 15, 0, r4, cr1, cr0, {2}
20: e384460f orr r4, r4, #15728640 ; 0xf00000
24: ee014f50 mcr 15, 0, r4, cr1, cr0, {2}
28: e3a04101 mov r4, #1073741824 ; 0x40000000
2c: eee84a10 vmsr fpexc, r4
30: ea000000 b 22c <.LC24+0x4>
30: R_ARM_JUMP24 boot-0x8
00000034 <leave_hyper>:
34: e24f4028 sub r4, pc, #40 ; 0x28
38: e12ef304 msr ELR_hyp, r4
3c: e10f4000 mrs r4, CPSR
40: e204401f and r4, r4, #31
44: e3844013 orr r4, r4, #19
48: e16ef304 msr SPSR_hyp, r4
4c: e160006e eret
00000050 <tmp_stack_ptr>:
50: 00000ff0 strdeq r0, [r0], -r0 ; <UNPREDICTABLE>
System binutils:
Disassembly of section .aros.startup:
00000000 <bootstrap>:
0: e10f4000 mrs r4, CPSR
4: e204401f and r4, r4, #31
8: e3a0801a mov r8, #26
c: e1540008 cmp r4, r8
10: 0a000007 beq 34 <leave_hyper>
00000014 <continue_boot>:
14: f1020013 cps #19
18: e59fd030 ldr sp, [pc, #48] ; 50 <tmp_stack_ptr>
1c: ee114f50 mrc 15, 0, r4, cr1, cr0, {2}
20: e384460f orr r4, r4, #15728640 ; 0xf00000
24: ee014f50 mcr 15, 0, r4, cr1, cr0, {2}
28: e3a04101 mov r4, #1073741824 ; 0x40000000
2c: eee84a10 vmsr fpexc, r4
30: eafffffe b 224 <boot>
30: R_ARM_JUMP24 boot
00000034 <leave_hyper>:
34: e24f4028 sub r4, pc, #40 ; 0x28
38: e12ef304 msr ELR_hyp, r4
3c: e10f4000 mrs r4, CPSR
40: e204401f and r4, r4, #31
44: e3844013 orr r4, r4, #19
48: e16ef304 msr SPSR_hyp, r4
4c: e160006e eret
00000050 <tmp_stack_ptr>:
50: 00000ff0 strdeq r0, [r0], -r0 ; <UNPREDICTABLE>
I realize that we patch binutils to add AROS support. Why do we need to make all of the relocations section-relative here? https://github.com/aros-development-team/AROS/blob/master/tools/crosstools/gnu/binutils-2.32-aros.diff#L190 It seems like this change may be causing the problem.
One thing I've noticed is that my system's arm-none-eabi-as will only write REL relocations (with no addend), while arm-raspi-aros-as will only write RELA relocations. I'm not sure whether the assembler or linker is responsible for the 8 byte fixup for PC-relative instructions. Since RELs don't have an addend, I assume the linker would have to do it, but then again, the AROS assembler produces RELA relocations with a -8 addend already there.
-
As a workaround, I changed elf_backend_may_use_rel_p to 1 and changed elf_backend_may_use_rela_p and elf_backend_default_use_rela_p to 0 here (https://github.com/aros-development-team/AROS/blob/master/tools/crosstools/gnu/binutils-2.32-aros.diff#L339). This forces the assembler to emit REL relocations instead of RELA (which seem to be buggy on ARM), and all of the branch instructions seem to work properly now.
-
Glad you made it work for you :)
-
After tinkering with the code some more, I finally got the kernel to boot on my Pi. Nothing works yet, and it complains about unsupported relocations (yes, more of these bollocks to deal with), but it's progress. I've ordered a USB serial adapter to capture the UART output from the Pi, but it has yet to arrive. In the meantime, the VC framebuffet boot console seems to work, though scrolling is extremely slow. (http://)
-
great that you invest the time ;)
-
many thanks :)
-
I've finally gotten it to run kernel_cstart from core.elf. The elf loader is buggy and doesn't resolve R_ARM_MOVW_ABS_NC and R_ARM_MOVT_ABS relocations correctly (I don't know enough about the details of how these two relocations work to fix it), so access to variables in the .data section is broken. I was able to work around this by recompiling everything with the -mword-relocations flag so that it avoids using movw/movt and simply loads 32-bit values from the pool instead. Now, the kernel gets as far as here (https://github.com/aros-development-team/AROS/blob/master/arch/arm-native/kernel/kernel_startup.c#L316), then crashes. I will look into this more tonight and try to get it further into the boot process.
-
Well, after a bit more work, I can now say that it "boots" on my Raspberry Pi! I had to disable most of Poseidon, since it was causing crashes during boot (which is expected, since the DWC2 USB drivers are incomplete), but Intuition shows up (though all green for some reason). Mice and keyboards don't work yet, so you can't do anything with it, and it seems to have trouble loading Wanderer.
I remember hearing something about AROS not being able to run correctly from a FAT formatted partition. Is there a way to configure AROS so that it runs from a separate partition? Since this is a Raspberry Pi, the kernel and boot rom need to be on a FAT partition, but I imagine I should be able to put the rest of the system on a SFS partition.
-
Congratz on your progress.
As for your question, dos.library is the place to look. In it's boot sequence it assigns which device will be SYS:. You need to look at that code and either hardcode your other partition of check if AROS.boot file will work (if I remember correctly, AROS.boot file put in root of file system indicate this is a partition to boot from). I think AROS.boot has to have a string containing name of architecture (so armhf in your case).
-
@Ninja
I confirm, inside AROS.boot you can find the name of the architecture used there.
Riguado the FAT filesystem, but also NTFS, are supported by AROS, but some apps may not work, as well as some commands do not work correctly, example if you try to rename a file with the same name, the file will be deleted.
In any case if you use InstallAROS you will have only two choices SFS (recommended) and FFS
-
Is there a way to format a SFS or FFS partition in Linux? Can hosted AROS do that?
-
Well, depends on what you have this partition. If it is a pen drive, you can attach it to VM and boot AROS in VM to format it.
-
I'm currently messing with the USB driver, hopefully trying to eventually get a mouse and keyboard working. It's a very frustrating experience, but I'm learning a lot about the USB protocol and AROS drivers in the process.
-
Mouse and Keyboard PS2 and Wireless work perfectly on AROS, if the PC hardware is supported !
-
The system for Raspberry is still in continuous development
-
Mouse and Keyboard PS2 and Wireless work perfectly on AROS, if the PC hardware is supported !
Unfortunately, the Raspberry Pi can't use PS/2 unless you somehow manage to bit bang it over GPIO.
-
Unfortunately, the Raspberry Pi can't use PS/2 unless you somehow manage to bit bang it over GPIO.
Depending on how serious you wish to take things, see f.e. https://hackaday.com/2016/01/14/ps2-keyboard-for-raspberry-pi/ Note that I personally do not have experience with this mod so mileage may vary.
It would at least allow you to circumvent messing with the USB stack.
-
I still want to get USB working, since the vast majority of users have USB keyboards and mice to plug in, and the onboard ethernet controller is connected internally via USB as well.
Although USB is complicated and a bloody pain to implement, it's worth getting it to work.
-
@NinjaCowboy:
Fair enough.
I thought perhaps you wanted to focus on addressing other issues (first).
Yes indeed, it would be very nice to get USB working though as you discovered it is bloody complicated.
Thank you for your efforts so far. It is more progress than I've been able to get.
What Pi(s) are you working with ?
-
I'm working with a Raspberry Pi 3, since that's the only model I own. I'm focusing on USB right now, because without any form of input, the OS is basically useless, and you might as well stare at art on a wall. There are plenty of other issues to address, though.
-
Still struggling with USB. I keep getting things to work in qemu only to have them fail on real hardware. Qemu's emulation of the DWC2 controller seems very inaccurate and is probably just good enough to get Linux running. The more I work on this, the more I believe this isn't a one man job. Unfortunately, I don't know anyone who has experience dealing with low-level USB on Raspberry Pi.
-
Michal Schultz may be able to give some insights.
He can be found on Patreon for Emu68 project for PiStorm & PiStorm 32 Lite.
He has also worked quite a bit on the AROS subsystems for x86 & x86-64 & especially 68k. He wrote some of the hardware drivers for AROS & for the Vampire Standalone v4.
-
+1 on contacting Michal. He is also available on Discord. He most likely will not be interested in developing, but he has VAST experience with AROS and RPi and USB. He wrote the original AROS USB stack (before we integrated Poseidon)
-
Still struggling with USB. I keep getting things to work in qemu only to have them fail on real hardware. Qemu's emulation of the DWC2 controller seems very inaccurate and is probably just good enough to get Linux running. The more I work on this, the more I believe this isn't a one man job. Unfortunately, I don't know anyone who has experience dealing with low-level USB on Raspberry Pi.
Possibly another thing to try is contacting the developers of RiscOS Open (see https://www.riscosopen.org/content/ (https://www.riscosopen.org/content/)) as they seem to have USB working for various models of PRi.
Cheers,
Nigel.
-
Good news is that I've made some progress on USB today. The code for the current OTG driver is quite messy, so I've decided to rewrite it from scratch and use the current one as a reference. So far, I've gotten USB control transfers to work on real hardware, so enumeration now works, and it can properly detect a connected keyboard and mouse. I will need to implement interrupt transfers for the devices to actually do anything, though.
-
But you mean that maybe we will have native AROS for Raspberry :D
(https://i.ibb.co/zRScV6d/Raspberry-Pi-logo.jpg)
-
No guarantees, but I really hope so!
-
many thanks :)
-
No guarantees, but I really hope so!
I also must say many thanks* for your work on this - AROS and RPi would be such a perfect combination. I'd really love to build a very compact AROS box that could be slipped into a pocket (and yes, i know you get the same functionality with a mobile 'phone but I really don't like either Android or iOS...)
Cheers,
Nigel.
* And of course all the AROS developers building the wider system.
-
When would a tailored 68k version for emu68k pistorm make sense?
-
Good news is that I've made some progress on USB today. The code for the current OTG driver is quite messy, so I've decided to rewrite it from scratch and use the current one as a reference. So far, I've gotten USB control transfers to work on real hardware, so enumeration now works, and it can properly detect a connected keyboard and mouse. I will need to implement interrupt transfers for the devices to actually do anything, though.
sounds good :)
thanks for trying to do it. RPi would be a nice little Aros device
-
The last time I did AROS was two years ago, but I have RPI3. I don't think that I will have time to compile applications for it, but I could probably do some tests. I'm writing this simply to assure you that this is the right job. Anyway, thanks for the efforts in this direction.
-
Hello aggressor, glad to see you back on the forum!