ReactOS Forum

I was thinking that support for Raspberry Pi might give the ReactOS project a leg up, since the hardware is standard. Other than ARM and usb 1 support. I don't see how it would be too much different than what the operating system looks like now. And it might make the OS much more popular, riding the coat tails of R Pi.

The problem with this: ARM
I don't think we have any ARM developers here. Last time there was a group which did ros-arm-bringup or somewhat similar, but they vanished into the shadow and happened to stay anonymous.

See the article in the ReactOS Wiki named "ReactOS ports". Look for the heading "Not under active development", subheading "ARM".

I realize it's highly unlikely, but an ARM port for ReactOS would be awesome. Imagine all those millions of RPi's out there running ReactOS, it could (potentially) be an awesome audience. Perhaps future developers will give it a go as the release matures further.

I just wanted to say, that I have a little of knowledge of ARM arhcitecture (both 32 and 64 bit), assembly languages, are familiar with EABI, other architectural specifics, so it would be interesting to participate, but it's not the task for one. And RPi is the worst ARM SBC out there, to be perfectly honest. Nothing against RPi as an organization, but, really there are just better boards by price/feature set ratio. Much better. If I were about to pick a few targets for the ReactOS, I'd choose the shiny new RockPro64 board - with a hexa-core dual cluster CPU, with PCIe. USB3 and up to 4GB of LPDDR4 RAM! For only 79$! Other boards from Pine64, Odroids, Oranges, Bananas etc. They all are better than RPi.
And the community capacity RPi fans so love to brag about hardly will help with this effort, since all that is around linux which is of zero use for NT-like OS. Actually, unlike monolithic linux, for ReactOS it would be easier to provide support for different boards - it's all about drivers, when the kernel is standing on both feet. Just using more capable boards (than RPi) as a target, will be better. Just compare RPi3 and RockPro64 and you'll get what I mean.

anthracen wrote:I just wanted to say, that I have a little of knowledge of ARM arhcitecture (both 32 and 64 bit), assembly languages, are familiar with EABI, other architectural specifics, so it would be interesting to participate, but it's not the task for one. And RPi is the worst ARM SBC out there, to be perfectly honest. Nothing against RPi as an organization, but, really there are just better boards by price/feature set ratio. Much better. If I were about to pick a few targets for the ReactOS, I'd choose the shiny new RockPro64 board - with a hexa-core dual cluster CPU, with PCIe. USB3 and up to 4GB of LPDDR4 RAM! For only 79$! Other boards from Pine64, Odroids, Oranges, Bananas etc. They all are better than RPi.
And the community capacity RPi fans so love to brag about hardly will help with this effort, since all that is around linux which is of zero use for NT-like OS. Actually, unlike monolithic linux, for ReactOS it would be easier to provide support for different boards - it's all about drivers, when the kernel is standing on both feet. Just using more capable boards (than RPi) as a target, will be better. Just compare RPi3 and RockPro64 and you'll get what I mean.

A first challenge would be to get it to compile again in ARM,
the second step would be to provide arm-specific implementations of syscalls, exception handling and all platform or arch specific stuff.

Almost nothing in ReactOS is something for a single person, but if you start on it, who knows who will join in?

At least for the start one needs to know what the ReactOS kernel does expect from the loader, the protocol in a broad sense. where is this information floating, compactly if possible?

anthracen wrote:At least for the start one needs to know what the ReactOS kernel does expect from the loader, the protocol in a broad sense. where is this information floating, compactly if possible?

https://reactos.org/wiki/ARM_Port has some documentation on what kind of setup works.
However the build system no longer works as described, there's no "make install", and you'll have to build with MSVC because GCC dropped their ARM-PE target and ROS dropped support for old GCC. There's also a bunch of stuff in configure.cmd that's likely untested -- so the first challenge is to get anything to compile in the first place. The second is to figure out what modules you need to build and how to organize them for ROS to find. Then you can worry about a boot loader.

And EXACTLY WHAT will you do with an ARM port? - ReactOS is only an OS, not a "suite of apps"! So will you then handle compiling everything on ARM by yourself, from Firefox to LibreOffice? It "sounds nice", but is entirely pointless in a greater perspective right now.

Aeneas wrote: ↑Fri Jul 06, 2018 12:03 pm And EXACTLY WHAT will you do with an ARM port? - ReactOS is only an OS, not a "suite of apps"! So will you then handle compiling everything on ARM by yourself, from Firefox to LibreOffice? It "sounds nice", but is entirely pointless in a greater perspective right now.

Windows 10 on ARM uses emulation to run x86 executables.

We need to make a GCC toolchain with target to ARM64 COFF PE first.

Carlo Bramix wrote: ↑Sat Jul 07, 2018 6:02 pm We need to make a GCC toolchain with target to ARM64 COFF PE first.

It would be kewl of course, but how do you estimate it's "easy"? Edk (Tianocore) for example, somehow, uses ELF->PE translation tools IIRC. despite there is a lot of linaro dudes over there. Probably it's not something trivial. Maybe easier would be to have your own ELF->PE translation?

I am going to do something like that, but so far it's only a fragile and incomplete tool targetting only MIPS32. Very soon I am going to add ARM.

As a hobby, I write my own osdev project on these SBCs. on ARM, I managed to run my first loader code on both armv7 and armv8 boards (the real ones). Let's show the screeshot here too. The bottom 5 lines are printed by it (directly into UART). Here, it's a 64 bit machine (running in the aarch64 executaion state), the chip is Allwinner a64, the board - Pine64+. Also I tested 32 bit code on Cubieboard 2 and Banana Pi M2 Ultra (Allwinner a20 and r40 respectively). Upcomming are Beagle Bone Black (TI am3358, 32 bit) and Rock64 (Rockchip rk3328, 64 bit and 4 gigs of RAM!). After this screenshot was made I added the code that parses command line transferred to it (by uboot), from where it takes addresses of the kernel and hal image files shadowed into RAM and extracts RAM info from either ATAGS (cubieboard 2) or device tree (banana and pine64). Next is building some page tables for mapping the "static area" (non-pageable) of 16MB of RAM to properly load these images (binding them, applying relocations), switching on Virtual Memory and ... jumping into the kernel!
I just wanted to say that it's possible and interesting. I would be glad to do something for ReactOS in this direction, but as I've said, I need to know, what "protocols/interfaces" ReactOS does expect from its loader to comply with.
[ external image ]

ThFabba wrote: ↑Sat Jun 16, 2018 3:19 pm https://reactos.org/wiki/ARM_Port has some documentation on what kind of setup works.
However the build system no longer works as described, there's no "make install", and you'll have to build with MSVC because GCC dropped their ARM-PE target and ROS dropped support for old GCC. There's also a bunch of stuff in configure.cmd that's likely untested -- so the first challenge is to get anything to compile in the first place. The second is to figure out what modules you need to build and how to organize them for ROS to find. Then you can worry about a boot loader.

Just created a very relevant thread:
viewtopic.php?f=2&t=17977

Aeneas wrote: ↑Fri Jul 06, 2018 12:03 pm And EXACTLY WHAT will you do with an ARM port? - ReactOS is only an OS, not a "suite of apps"! So will you then handle compiling everything on ARM by yourself, from Firefox to LibreOffice? It "sounds nice", but is entirely pointless in a greater perspective right now.

Windows 10 RT is migrating toward mixed ARM and X86 applications. The OS is native ARM, but has an X86 emulator for applications. Thus you can run (slowly) X86 applications interpreted on the ARM NT system. My guess is a port of ROS would need to analyze both how Microsoft supports native ARM applications and how it supports X86 interpretation. An X86 interpreter would have to be a component added to ROS to enable broad compatibility with existing Windows software.

GCC dropped their ARM-PE target

You can use ELF to PE converter like Linux EFI developers.