Status of Raspberry Pi native support

NinjaCowboy · 25465

« previous next »
Pages: 1 2 3 ... 9   Go Down

NinjaCowboy

  • Junior Member
  • **
    • Posts: 66
    • Karma: +18/-0
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?


nikos

  • Senior Member
  • ****
    • Posts: 374
    • Karma: +71/-3
    • aspireos
Reply #1 on: January 15, 2019, 09:27:38 AM
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.
« Last Edit: January 15, 2019, 09:45:49 AM by nikos »


NinjaCowboy

  • Junior Member
  • **
    • Posts: 66
    • Karma: +18/-0
Reply #2 on: January 15, 2019, 09:42:27 AM
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.


nikos

  • Senior Member
  • ****
    • Posts: 374
    • Karma: +71/-3
    • aspireos
Reply #3 on: January 15, 2019, 10:00:33 AM
Quote from: NinjaCowboy on January 15, 2019, 09:42:27 AM

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?



 
« Last Edit: January 15, 2019, 10:12:14 AM by nikos »


dizzy

  • Junior Member
  • **
    • Posts: 59
    • Karma: +60/-0
    • YouTube channel
Reply #4 on: January 15, 2019, 10:42:58 AM
Quote from: 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?

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)
« Last Edit: January 15, 2019, 10:47:25 AM by dizzy »


NinjaCowboy

  • Junior Member
  • **
    • Posts: 66
    • Karma: +18/-0
Reply #5 on: January 16, 2019, 10:29:44 AM
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.


dizzy

  • Junior Member
  • **
    • Posts: 59
    • Karma: +60/-0
    • YouTube channel
Reply #6 on: January 16, 2019, 02:07:32 PM
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.


dizzy

  • Junior Member
  • **
    • Posts: 59
    • Karma: +60/-0
    • YouTube channel
Reply #7 on: January 16, 2019, 02:23:38 PM
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.


NinjaCowboy

  • Junior Member
  • **
    • Posts: 66
    • Karma: +18/-0
Reply #8 on: January 17, 2019, 10:15:19 AM
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


nikos

  • Senior Member
  • ****
    • Posts: 374
    • Karma: +71/-3
    • aspireos
Reply #9 on: January 17, 2019, 10:22:00 AM
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.


NinjaCowboy

  • Junior Member
  • **
    • Posts: 66
    • Karma: +18/-0
Reply #10 on: January 17, 2019, 06:28:58 PM
I tried compiling, but got this error.
Code: [Select]
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++.


x-vision

  • Junior Member
  • **
    • Posts: 50
    • Karma: +5/-2
Reply #11 on: January 19, 2019, 10:46:40 AM
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.


NinjaCowboy

  • Junior Member
  • **
    • Posts: 66
    • Karma: +18/-0
Reply #12 on: January 19, 2019, 11:09:12 AM
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?


Samurai_Crow

  • Junior Member
  • **
    • Posts: 88
    • Karma: +32/-0
  • Hobby coder
Reply #13 on: January 19, 2019, 02:14:36 PM
Quote from: NinjaCowboy on January 19, 2019, 11:09:12 AM
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.


x-vision

  • Junior Member
  • **
    • Posts: 50
    • Karma: +5/-2
Reply #14 on: January 19, 2019, 03:08:26 PM
Quote from: NinjaCowboy on January 19, 2019, 11:09:12 AM
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


Pages: 1 2 3 ... 9   Go Up
« previous next »