ROS Port ARM

Сборка

Скачайте ReactOS Build Environment for ARM (RosBE-ARM). Последняя версия 1.0 и доступна на sourceforge.net.

Запустите RosBE-ARM и введите команду:

makex

Через несколько минут вы должны получить все файлы для сборки.

Создание RAM-диска

На данный момент ARM порт загружается только с RAM-диска - c NOR/NAND флеш памяти на реальном устройстве, либо с эмулируемого при помощи QEMU. В данном случае RAM-диск - это простой файл образа, загружаемый в оперативную память.

Для создания образов вы можете использовать инструменты, такие как qemu-img, утилиту Disk Image под Mac OS, или любой другой инструмент, создающий файлы образов жёстких дисков. Вам потребуется сгенерировать образ RAM-диска размером не более 32 МБ.

Далее вам потребуется инструмент (под Windows), либо набор команд для монтирования этого файла образа в качестве виртуального жёсткого диска на своей машине. Это необходимо, поскольку ARM порт не имеет привычного установщика системы, который мог бы выполнить разметку жёсткого диска. Поэтому вам придётся сделать это самостоятельно.

Под Linux можно воспользоваться обычным монтированием при помощи mount, после чего запустить mkfs_fat на смонтированном диске. Вы можете отформатировать его в FAT16 или FAT32, так как обе эти файловые системы были успешно протестированы. Под OS X утилита работы с дисками сама предложит вам разметить и отформатировать образ диска - убедитесь, что вы выбрали тип разметки "MS-DOS". Под Windows можно воспользоваться утилитой vdkmount. В качестве альтернативы можно использовать этот же файл образа в качестве жёсткого диска для QEMU, запустив установку x86 версии ReactOS. Пройдите все шаги установки вплоть до разметки и форматирования диска. После того, как установщик отформатировал образ диска и записал загрузчик, закройте QEMU.

ВАЖНО: Как правило, созданный образ будет выглядеть, как реальный жёсткий диск. У него будет MBR сектор по нулевому смещению, за которым будет следовать загрузочный сектор первого раздела. Сам раздел может находиться в разных местах - это может быть сектор 63, 2, 1, 60, и т.д. Вам потребуется узнать смещение этого раздела. Чаще всего оно будет 0x7E00 (32256), впрочем под Mac OS X с образами .dmg оно такое: 0x200. В принципе, найти смещение достаточно легко, используя один из инструментов для работы с образами дисков при монтировании, либо используя hex-редактор для поиска подстроки "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. Although the original ARM port of ReactOS was designed for ARMv5 and ARMv4, these cores have an MMU that is incompatible with ReactOS/Windows requirements, and lacks instructions needed for synchronization done in user-mode. 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.

Status

• ntoskrnl/mm/ARM3
• hal/halarm
• boot/armllb
• ntoskrnl/config/arm
• ntoskrnl/ps/arm
• ntoskrnl/rtl/arm
• boot/freeldr/freeldr/arch/arm
• ntoskrnl/include/internal/arm
• ntoskrnl/ke/arm
• hal/halarm
• ntoskrnl/mm/ARM3
• ntoskrnl/mm/arm

r56035: Two Part Patch which fixes ARM3 Section Support (not yet enabled). This had been enabled in the past for testing and resulted in bizare crashes during testing. The amount of fixing required should reveal why:

Part 1: Page Fault Path Fixes

• [NTOS]: As an optimization, someone seems to have had changed the MiResolveDemandZeroFault prototype not to require a PTE, and to instead take a protection mask directly. While clever, this broke support for ARM3 sections, because the code was now assuming that the protection of the PTE for the input address should be used -- while in NT Sections we instead use what are called ProtoType PTEs. This was very annoying to debug, but since the cause has been fixed, I've reverted back to the old convention in which the PTE is passed-in, and this can be a different PTE than the PTE for the address, as it should be.
• [NTOS]: Due to the reverting of the original path, another optimization, in which MiResolveDemandZeroFault was being called directly instead of going through MiDispatchFault and writing an invalid demand-zero PDE has also been removed. PDE faults are now going through the correct, expected path.
• [NTOS]: MiResolveDemandZeroFault was always creating Kernel PTEs. It should create User PTEs when necessary.
• [NTOS]: MiDeletePte was assuming any prototype PTE is a forked PTE. Forked PTEs only happen when the addresses in the PTE don't match, so check for that too.

Part 2: ARM3 Section Object Fixes

• [NTOS]: Fix issue when trying to make both ROS_SECTION_OBJECTs and NT's SECTION co-exist. We relied on the *caller* knowing what kind of section this is, and that can't be a good idea. Now, when the caller requests an ARM3 section vs a ROS section, we use a marker to detect what kind of section this is for later APIs.
• [NTOS]: For section VADs, we were storing the ReactOS MEMORY_AREA in the ControlArea... however, the mappings of one individual section object share a single control area, even though they have multiple MEMORY_AREAs (one for each mapping). As such, we overwrote the MEMORY_AREA continously, and at free-time, double or triple-freed the same memory area.
• [NTOS]: Moved the MEMORY_AREA to the "Banked" field of the long VAD, instead of the ControlArea. Allocate MMVAD_LONGs for ARM3 sections for now, to support this. Also, after deleting the MEMORY_AREA while parsing VADs, we now use a special marker to detect double-frees, and we also use a special marker to make sure we have a Long VAD as expected.