Aros/Platforms/x86 64 support

Starting from November 2007, AROS got its 64-bit port. It lacks software and drivers support, but have some new features AROS never had - some kind of memory protection and

x86_64 Native Environment

AROS x86_64 is targeted towards new PC systems, with both AMD and Intel processors. Also you can try this port in QEMU emulator, using its 64-bit mode. Please note that PCI cards and other stuff from x86 can be used, so this page mostly devoted to CPU/Chipsets/Laptops support.

x86_64 Compatible Drivers

KNOWN WORKING HARDWARE

Laptop

Motherboard

VMWare Virtual PC.
ECS 755-A2 with Athlon 64 CPU.

Boots from CD on SIS5513 IDE Controller. This M/b has SATA SIS180 controller with

1 PATA and 2 SATA channels. Installation on an HD however, failed with

"Unknown Error 100" message. (pleas add date tested .. 17:10, 20 August 2008 (UTC))

Shuttle

Graphic Card

Sound Card

Network Interface Cards

KNOWN PROBLEMATIC HARDWARE, WHICH WORKS BUT THE SUPPORT IS LIMITED

Laptop

Acer Aspire 5101AWLMi (AMD Turion 64 MK-36 - 2 GHz, 512KB L2 Cache, ATI Xpress 1100 chipset, 1Gb DDR2-533 MHz,ATI Mobility Radeon x1300, 15.4" TFT (1280 x 800), Wireless LAN: 802.11b/g )

Boots fine. Video (vesa/vga) and touchpad/USB mouse works. AHI prefs hangs the system. Experiences random hangs on software launch.

Motherboard

Graphic Card

Sound Card

Network Interface Cards

Intel Gigabit NIC - Driver not yet complete .. see Networking Docs.

NOT WORKING HARDWARE

Laptop

Motherboard

Graphic Card

Sound Card

Network Interface Cards

References

Well at the moment I cant even test this again since it crashes in the bootloader -:

[BOOT] Entered AROS Bootstrap @ 001100d0
[BOOT] Stack @ 00116e40, [65536 bytes]
[BOOT] Multiboot structure @ 011271b0
[BOOT] Command line @ 01127228 : 'vesa=1024x768x16 ATA=32bit
nomonitors debug=serial'
[BOOT] Memory map at 0x011272d0, length 288
[BOOT] Low memory 638 KB, upper memory 522176 KB
[BOOT] Backing up low memory, buffer at 0x001271a0
[BOOT] setupVESA: vesa.bin @ 001155dc [size=6197]
[BOOT] setupVESA: BestModeMatch for 1024x768x16 =

Is all that is displayed, and then the machine reboots.

Check VESA code carefully. Something could be damaged during bootstrap refactor. Could not test VESA code because i'm testing on Mac, EFI doesn't provide PC BIOS API in native mode. And, if this appeared recently, check how the embedded 16-bit code links. Jason played with %rule_link_binary, perhaps this is the reason. And, you can work around this by running in VGA or native display mode.

The beginning of acpi.resource. For now it just attempts to locate RSDP. When scanning EBDA it gurus because of page fault. Even when running inside SuperState()/UserState(). These functions by themselves work, tests confirm this. Additionally, processor.resource successfully queries CPU speed.

'Present' flag in MMU tables affects supervisor too, it was set to '0'. However currently i diverted into switching to Multiboot V2. In EFI environment you need a pointer to EFI system table in order to retrieve RSDP. There's neither EBDA nor BIOS image provided (scanning fails). BTW i committed my WIP code (there's not much there, just RSDP locator).

Studied AMD's manual, 64-bit mode is extremely simple, i just have a descriptor with privilege level in CS and that's all. May be i have something wrong in MMU tables ? You can examine the code, it's up to date, i don't have uncommitted parts except acpi.resource skeleton. One which reads the info that kernel resource currently has. Im fighting with Intel's ACPI code atm to try and get it to build and link into the resource. I was going to remove this code from kernel.resource.

The idea was:

acpi.resource RTF_COLDSTART Pri=125 - parse ACPI tables.
processor.resource launches other CPUs. It has own boot code for them. This code calls InitCode(RTF_SINGLETASK).
kernel.resource detects secondary CPUs and interrupts InitCode().

What it gives:

Independency on modules' private data.
Modularity, as a consequence.
When secondary CPUs start up, we already have working kernel and even exec environment.

Like only using the version of thisTask stored in TLS in the scheduling code (so that separate cores see their own correct version), adding task execution time using the apic local timer (based on how sam440 does it..) and tried to tidy up the APIC/IPI code a little, but I cant check how well it works currently.

acpi.resource is initialized at SINGLETASK level. After all SINGLETASK residents are done, InitCode() returns into boot code. This allows to perform additional setup, whatever is needed. Multitask starts up in exec.library, which is the first COLDSTART resident. Additionally, SINGLETASK is called with supervisor privileges, this gets rid of additional clutter. This is very close to original AmigaOS boot sequence. And allows to completely separate hardware-controlling components from kernel.

Additionally, processor.resource successfully queries CPU speed. Studied AMD's manual, 64-bit mode is extremely simple, i just have a descriptor with privilege level in CS and that's all. May be i have something wrong in MMU tables ? You can examine the code, it's up to date, i don't have uncommitted parts except acpi.resource skeleton. Additionally processor.resource would have to call the CPU detection code on each core to gather information. However can such code be executed before kernel.resource? IMHO it should be done where it is (in kernel resource) because it interacts directly with the system resources that kernel resource controls. Trying to move it all out is just going to add code duplication/unnecessary bloat. Always envisioned that kernel.resource sets up cores and then has a function that allows executing code on specific core. Such function is used by processor.resource to run core capabilities detection code.