Difference between revisions of "ARM Port"

From ReactOS Wiki
Jump to: navigation, search
m (Changed 'is' to 'has' and added 'been')
m (Improve formatting for the commands)
Line 49: Line 49:
 
1.0 and available from: https://download.reactos.org/reactos/RosBE-Windows/arm/1.0/RosBE-ARM-1.0.exe
 
1.0 and available from: https://download.reactos.org/reactos/RosBE-Windows/arm/1.0/RosBE-ARM-1.0.exe
  
Launch the RosBE-ARM command prompt, and type "makex" on the command line. After
+
Launch the RosBE-ARM command prompt, and type <code>makex</code> on the command line. After
 
some minutes, you should have the whole tree built.
 
some minutes, you should have the whole tree built.
  
Line 89: Line 89:
 
Now that you have a mountable, formatted, FAT image file, go ahead and mount it,
 
Now that you have a mountable, formatted, FAT image file, go ahead and mount it,
 
and set your ROS_INSTALL environment variable to the \reactos folder on the virtual
 
and set your ROS_INSTALL environment variable to the \reactos folder on the virtual
drive. For example, if you mapped it to X:\, this would be ROS_INSTALL=X:\reactos.
+
drive. For example, if you mapped it to X:\, this would be <code>ROS_INSTALL=X:\reactos</code>.
  
Now issue a "makex install" from the RosBE command line. This will copy all the
+
Now issue a <code>makex install</code> from the RosBE command line. This will copy all the
 
files to your new RAM disk.
 
files to your new RAM disk.
  
Line 104: Line 104:
 
ARM port basically uses an LLB (Low-Level Bootloader) to initialize the hardware,
 
ARM port basically uses an LLB (Low-Level Bootloader) to initialize the hardware,
 
and then pass control to FreeLDR, the ReactOS Boot Loader. FreeLDR will then use
 
and then pass control to FreeLDR, the ReactOS Boot Loader. FreeLDR will then use
the RAM disk to search for freeldr.ini, present the OS options, etc, and finally
+
the RAM disk to search for <code>freeldr.ini</code>, present the OS options, etc, and finally
 
load the kernel.
 
load the kernel.
  
Line 113: Line 113:
 
for technical reasons beyond the scope of this document.
 
for technical reasons beyond the scope of this document.
  
Thankfully, a tool exists to perform these operations: nandflash. You simply need
+
Thankfully, a tool exists to perform these operations: <code>nandflash</code>. You simply need
to run nandflash (from your output-arm/tools/nandflash directory) with the "1"
+
to run nandflash (from your <code>output-arm/tools/nandflash</code> directory) with the "1"
 
option to instruct it to generate the necessary files. The other use of nandflash
 
option to instruct it to generate the necessary files. The other use of nandflash
 
(without the parameter) is to generate OMAP3 ROM NAND flash files, but that usage
 
(without the parameter) is to generate OMAP3 ROM NAND flash files, but that usage
 
is beyond the scope of this document.
 
is beyond the scope of this document.
  
Note that nandflash expects your image file to have been called ramdisk.img, so
+
Note that nandflash expects your image file to have been called <code>ramdisk.img</code>, so
 
make sure you rename it to match this. After running nandflash, you will have
 
make sure you rename it to match this. After running nandflash, you will have
two new files: ramdisk.bin, which is a modified version of your ramdisk image,
+
two new files: <code>ramdisk.bin</code>, which is a modified version of your ramdisk image,
and reactos.bin, which is the fused LLB and loader together.
+
and <code>reactos.bin</code>, which is the fused LLB and loader together.
  
 
== Booting ==
 
== Booting ==
Line 131: Line 131:
 
the Cortex A8, an ARMv7-a core, which is being used internally for BeagleBoard
 
the Cortex A8, an ARMv7-a core, which is being used internally for BeagleBoard
 
and ZoomII-MDK work.
 
and ZoomII-MDK work.
To specify these two options, use "-M versatilepb -cpu cortex-a8" on your command
+
To specify these two options, use <code>-M versatilepb -cpu cortex-a8</code> on your command
 
line.
 
line.
  
 
You now need to specify the two files that nandflash created for you. You may do
 
You now need to specify the two files that nandflash created for you. You may do
this with the following two options: "-kernel reactos.bin -initrd ramdisk.bin".
+
this with the following two options: <code>-kernel reactos.bin -initrd ramdisk.bin</code>.
  
 
Finally, you need to tell the LLB that we are booting from a RAM disk, and you
 
Finally, you need to tell the LLB that we are booting from a RAM disk, and you
 
need to input the boot sector offset we talked about earlier. You can do this with
 
need to input the boot sector offset we talked about earlier. You can do this with
the following options: "-append boot-device=RAMDISK,rdoffset=0x200". In general,
+
the following options: <code>-append boot-device=RAMDISK,rdoffset=0x200</code>. In general,
"-append" is used to send command-line parameters to the LLB, and you can specify
+
<code>-append</code> is used to send command-line parameters to the LLB, and you can specify
 
additional options by comma-separating them.
 
additional options by comma-separating them.
  
 
Here is an example final command line for QEMU:
 
Here is an example final command line for QEMU:
"qemu-system-arm -M versatilepb -cpu cortex-a8 -kernel reactos.bin -initrd ramdisk.bin -append boot-device=RAMDISK,rdoffset=0x200"
+
qemu-system-arm -M versatilepb -cpu cortex-a8 -kernel reactos.bin -initrd ramdisk.bin -append boot-device=RAMDISK,rdoffset=0x200
  
 
Past this point, the experience should be familiar. Note that the only thing you
 
Past this point, the experience should be familiar. Note that the only thing you

Revision as of 17:17, 20 November 2018

ReactOS 32-bit ARM port was created by ReactOS Portable Systems Group back in 2008. Originally it was designed for ARMv5 and ARMv4, but these cores have an MMU that is incompatible with ReactOS/Windows requirements, and lacks instructions needed for synchronization done in user-mode, so currently the port targets ARMv7 compatible cores.

Since the GCC compiler has dropped the support for ARM PE executables, and the project had to upgrade GCC version, the port become unmaintained somewhere back in 2015 (see #Known facts section).

However in November 2018 Microsoft has added official ARM and ARM64 target support into Visual Studio 15.9, so now it is possible to bring the port back to life!

Follow the discussion in this thread: https://reactos.org/forum/viewtopic.php?f=2&t=17977

Known facts

  • 15 Oct 2009: Last commit by ReactOS Portable Systems Group. [1]
  • 22 Mar 2012: GCC 4.7.0 has dropped support for ARM PE executables. [2] [3]
  • 22 Jul 2012: Timo Kreuzer has added support for MSVC ARM build. [4]
  • 15 May 2015: Beginning with r67740 ReactOS builds for ARM, too. Timo Kreuzer made some effort to get it build and succeeded. [5]
  • 15 Nov 2018: Microsoft announced official ARM target support for Visual Studio 2017. [6]
  • 19 Nov 2018: Support for VS2017 (15.9) compiler was added. [7]

Building

Visual Studio 2017

This is recommended build method. Please refer to these articles:

General TODO list

  • [✓] Make configure.cmd detect the Visual Studio 15.9 environment
  • [✓] Make sure it detects and builds both x86 and x64 ports successfully
  • [✓] Add ARM target support to the configure.cmd build script
  • Fix the ARM port build so it can generate bootcd-arm.iso and livecd-arm.iso
  • Once the whole tree is built without issues, one can step into the development


These pages may be helpful to accomplish the tasks above:


Don't be in hurry and propose a Pull Request for the each fix you have done into the ReactOS repository.

RosBE (outdated)

This build method has not been maintained for some years and may not work.

Obtain the React OS Build Environment for ARM (RosBE-ARM). The latest version is 1.0 and available from: https://download.reactos.org/reactos/RosBE-Windows/arm/1.0/RosBE-ARM-1.0.exe

Launch the RosBE-ARM command prompt, and type makex on the command line. After some minutes, you should have the whole tree built.

Making a RAM disk

Currently, the ARM port will only boot from a RAM disk, either in NOR/NAND flash on a real device, or an emulated one like QEMU. A RAM disk is a simple flat image file that is loaded into memory.

To generate one of these images, you may use a tool such as qemu-img, the Mac OS Disk Image utility, or any other tool capable of generating a raw image file that corresponds to a hard disk image. You should generate a RAM disk of 32MB or less.

You then need a tool (on Windows), or the proper set of commands, to mount this virtual file/image as an actual hard drive on your machine. This step is required as the ARM port does not have an "installer" of any sorts, and cannot partition your disk, so you must do so yourself.

On a system such as Linux, you can use a local loopback mount, and then launch mkfs_fat on the mounted device. You can use either FAT16 or FAT32, as both have been tested with success. On OS X, the Disk Utility will automatically ask you to partition/format the image. Make sure you select "MS-DOS" partitioning when asked. On Windows, you may need to obtain a tool that can mount such images, such as vdkmount. Alternatively, you may use this image as an x86 ReactOS hard disk in QEMU, and then launch the x86 ReactOS setup program. Continue through the installer pages until you reach the formatting step, and allow ReactOS setup to format the disk. After that, you should be able to quit QEMU and have a formatted image file.

IMPORTANT: Usually, your raw image file will look like a real "disk". It will have an MBR sector at 0x00000000, followed by a boot sector for your first partition somewhere else on the disk. Sometimes this is at sector 63, 2, 1, 60, etc. You will need to know the offset of where the partition starts. Often this will be 0x7E00 (32256), although on Mac OS X .dmg images it will be 0x200. This offset is easy to find, either with a tool that understands your image file when mounting it, or by using a hex editor and locating the boot sector (look for "FAT").

Installing

Now that you have a mountable, formatted, FAT image file, go ahead and mount it, and set your ROS_INSTALL environment variable to the \reactos folder on the virtual drive. For example, if you mapped it to X:\, this would be ROS_INSTALL=X:\reactos.

Now issue a makex install from the RosBE command line. This will copy all the files to your new RAM disk.

The last thing you'll need is a freeldr.ini. You can write one from scratch, or simply take the usual one that the x86 ReactOS setup program installs on your x86 ReactOS partition/image file. You'll want to keep the ReactOS entry that's marked as "(RAMDisk)".

Preparing to boot

Now that you have a RAM disk, you are ready to build the final components. The ARM port basically uses an LLB (Low-Level Bootloader) to initialize the hardware, and then pass control to FreeLDR, the ReactOS Boot Loader. FreeLDR will then use the RAM disk to search for freeldr.ini, present the OS options, etc, and finally load the kernel.

Therefore, there are three components that the system needs: the LLB, the loader, and the RAM disk. QEMU has command-line options and support for only loading two image files, and so the LLB and the loader must be fused together into one binary file. Additionally, the RAM disk image file you created must be slightly modified for technical reasons beyond the scope of this document.

Thankfully, a tool exists to perform these operations: nandflash. You simply need to run nandflash (from your output-arm/tools/nandflash directory) with the "1" option to instruct it to generate the necessary files. The other use of nandflash (without the parameter) is to generate OMAP3 ROM NAND flash files, but that usage is beyond the scope of this document.

Note that nandflash expects your image file to have been called ramdisk.img, so make sure you rename it to match this. After running nandflash, you will have two new files: ramdisk.bin, which is a modified version of your ramdisk image, and reactos.bin, which is the fused LLB and loader together.

Booting

You can now instruct QEMU to boot ReactOS for ARM. You will need to obtain the ARM version of QEMU (qemu-system-arm) or build it yourself. Currently, testing is done with the "Versatile/PB" platform, but with a modified CPU target being the Cortex A8, an ARMv7-a core, which is being used internally for BeagleBoard and ZoomII-MDK work. To specify these two options, use -M versatilepb -cpu cortex-a8 on your command line.

You now need to specify the two files that nandflash created for you. You may do this with the following two options: -kernel reactos.bin -initrd ramdisk.bin.

Finally, you need to tell the LLB that we are booting from a RAM disk, and you need to input the boot sector offset we talked about earlier. You can do this with the following options: -append boot-device=RAMDISK,rdoffset=0x200. In general, -append is used to send command-line parameters to the LLB, and you can specify additional options by comma-separating them.

Here is an example final command line for QEMU:

qemu-system-arm -M versatilepb -cpu cortex-a8 -kernel reactos.bin -initrd ramdisk.bin -append boot-device=RAMDISK,rdoffset=0x200

Past this point, the experience should be familiar. Note that the only thing you can do for now is select the OS from the boot selection menu, and see it load a couple of drivers and hang somewhere in the kernel.

Compatible devices list

See this forum post: https://reactos.org/forum/viewtopic.php?f=2&t=17977#p134530

Links

ReactOS ports‎
In active development Intel IA-32 (x86) | AMD64 (x64)
In slow development ARM64 (aarch64) | ARM32 (armv7) | NEC PC-98 (x86) | OG Xbox (x86)
Unmaintained OLPC (x86)
Missing ports that Windows has Intel IA-64 (Itanium) | IBM PS/2 MCA (x86) | SGI 320/540 (x86) | DEC Alpha (axp) | MIPS | PowerPC (ppc)
Ideas for new ports Apple TV 1st Gen (x86) | FM Towns (x86) | PlayStation 4 (x64) | Intel SFI (x86)