I'm alive and 64-bit
After a long break here I am again!. And I have some good news aswell :-)
Few weeks ago I made my brand new x86_64 system working. It was really a fight. Within only few days I've installed several SuSE distros - all of them failed with my SATA-2 harddrive. It was a nightmare.
And then, finally, I have discoverred the problem. The DSDT ACPI table which is stored in BIOS of my A8N-VM CSM mainboard is simply broken. It contains non-ASCII character in one name, which is illegal. After short fix (fixing the character, disassembling the table, sort of programming again, in order to make the code cleaner and then comiling again - it all took 30 minutes, not more!) and adding the table to initrd image, everything started to work perfectly.
The 32-bit aros compiles well on this machine, even using the gcc4. I've tested only hosted so far, but I would not expect any issues with the native.
The 64-bit Aros is not yet done (sight, who would expect it to be done within three weeks). All types and machine-specific includes are done now. Thanks to that, some libraries compile just fine, others don't.
Right now I'm working on the bootstrap code. It is a small 32-bit application executed by GRUB, which prepares a clean 64-bit environment for native AROS. Additionally, it will allow loading of external libraries and linking them with aros kernel during a boot. Therefore, x86-64 kernel may be as small as bootstrap+exec+some addons, and the rest may be linked with it later. In the future, such bootstrap code may be easily extended in order to support some VESA mode selection.
PS. And recently, I've finally completed my first draft of my PhD disseration :-).
Few weeks ago I made my brand new x86_64 system working. It was really a fight. Within only few days I've installed several SuSE distros - all of them failed with my SATA-2 harddrive. It was a nightmare.
And then, finally, I have discoverred the problem. The DSDT ACPI table which is stored in BIOS of my A8N-VM CSM mainboard is simply broken. It contains non-ASCII character in one name, which is illegal. After short fix (fixing the character, disassembling the table, sort of programming again, in order to make the code cleaner and then comiling again - it all took 30 minutes, not more!) and adding the table to initrd image, everything started to work perfectly.
The 32-bit aros compiles well on this machine, even using the gcc4. I've tested only hosted so far, but I would not expect any issues with the native.
The 64-bit Aros is not yet done (sight, who would expect it to be done within three weeks). All types and machine-specific includes are done now. Thanks to that, some libraries compile just fine, others don't.
Right now I'm working on the bootstrap code. It is a small 32-bit application executed by GRUB, which prepares a clean 64-bit environment for native AROS. Additionally, it will allow loading of external libraries and linking them with aros kernel during a boot. Therefore, x86-64 kernel may be as small as bootstrap+exec+some addons, and the rest may be linked with it later. In the future, such bootstrap code may be easily extended in order to support some VESA mode selection.
PS. And recently, I've finally completed my first draft of my PhD disseration :-).
posted by Michal Schulz at 08:38
3 Comments:
Great news Michal!
just a thought and perhaps its not a great one but why just VESA mode?
i thought that the 3DFX code while
also old was fully documented and would perhaps be a better fit to hack it to become the base for hardware exeleration on todays cards perhaps as part of the HAL and a wrapper to cover the basic ATI/Intel/Nvidea etc ?....
am i compleatley off the wall!
just a thought and perhaps its not a great one but why just.
...............
Juli
Wow, check out this site called www.fluc.combr/>. Free SMS and free mobile ads!! Its fantastic
Post a Comment
<< Home