Moving OS from Grub 32 bit bootloader to Pure64 0.5.0

[brain]

Hi all,

I've had my eye on Pure64 for some time now as a viable replacement for Grub 32 bit which i am currently using to boot my 32 bit kernel. As i see it, it would save me a whole whack of coding and debugging in migrating my 32 bit OS to 64 bit, giving me a leg up on the mundane parts.

Apart from the obvious stuff such as if i enable SMP to ensure my locking mechanisms are up to par, can anyone see any pros or cons i may have missed in attempting this migration (beyond the obvious things i have found by good old RTFM, maybe from your own personal experiences of such an endevour)?

Bear in mind my OS is generally in a state that means portability to 64 bit shouldnt be too difficult in terms of code change but theres enough code there to keep me busy for a while testing and adjusting everything.

NB: I do have my own 64 bit boot trampoline (for grub) but it is nowhere near as advanced as Pure64 nor does it do the SMP part, so this saves me lots of time i simply do not have to develop these features myself as a busy person with a family.

Advice would as always be welcomed.

[KernelDeveloper]

You can move from 32bit to 64bit but the kernel would be useless until you utlize 64bit registers, etc.

For example, you hav coded your code with ebx,eax,etc but when you move to 64 there will be 64 bit registers as RAX,RBX,RCX,RDX and also many other changes.

What I mean is you would make no difference in 32 and 64 if you don't update your 32bit code to 64bit code.

[brain]

Well 99% of the code is C, so simply rebuilding with an x64 cross compiler will sort that, somewhere I also have paging code for x64 and assembly code for x64 IDT handling. These will definitely be required. Thanks for the reply, though

[bluemoon]

KernelDeveloper, In fact there are much more to consider when porting to 64-bit. It's not just registers, paging and IDTs.
To name a few major issues,
1) Do you plan for first milestone to just run compatible mode applications but utilize 48-bit addressing in kernel? (This is not trivial as it seems, you need to verify all interfaces to be 32/64 compatible)

2) Do you like to host a 32-bit compatible environment (API level wrapper or another 32-bit kernel instance) within 64-bit kernel?

But from my observation brain is elite enough to handle those issues.

To the original question, my choice is write a 32-bit stub for the 64-bit kernel until things(ie. the boot loaders) get stabilized for 64-bit systems.
It's very possible that before you even ported your kernel to 64, Grub, Pure64 and bababa will get update and may involve major changes and break your boot logic.

[brain]

1) Do you plan for first milestone to just run compatible mode applications but utilize 48-bit addressing in kernel? (This is not trivial as it seems, you need to verify all interfaces to be 32/64 compatible)

Yes this is the general first milestone,to make this work i would have to check through all my drivers and code for 64 bit compliance. For the most part i have not been assuming pointer sizes, but for some code this was unfortunately neccessary (e.g. bios memory map handling etc) so these would need to be addressed.

2) Do you like to host a 32-bit compatible environment (API level wrapper or another 32-bit kernel instance) within 64-bit kernel?

I don't really plan to do this, or need it (most of the userland code is interpreted inside a sandbox) so this does cut down on development time and issues.

But from my observation brain is elite enough to handle those issues.

To the original question, my choice is write a 32-bit stub for the 64-bit kernel until things(ie. the boot loaders) get stabilized for 64-bit systems.
It's very possible that before you even ported your kernel to 64, Grub, Pure64 and bababa will get update and may involve major changes and break your boot logic.

Thanks for the advice I do think it is quite likely that one or the other could change in the interim, in fact i am a little tempted to add fat32 support to pure64 if i am to use it, as i do not support fat16 in my OS (only fat32) and it seems the less backwards of two options...

[IanSeyler]

While I do agree that Pure64 is awesome (I may be biased though), you may want to check out Hydrogen if you are already used to GRUB. Hydrogen is based on the ideas of Pure64. Keep in mind that Pure64 only supports loading a kernel from a FAT16-formatted hard drive.

-Ian

[bluemoon]

for some code this was unfortunately neccessary (e.g. bios memory map handling etc)

The BIOS memory map comes in 64-bit. I use the same routine to parse the structure in both 32-bit and 64-bit compiles:
In order to reject memory address higher than page table size could allow, I do a checking like:

Code: Select all

  uint64_t phy_address = XXXX;
  if ( phy_address >SIZE_MAX ) { ... }

This filter out address>4G in 32-bit compiles (I do without PAE), while allow full address in 64-bit compiles.

[brain]

While I do agree that Pure64 is awesome (I may be biased though), you may want to check out Hydrogen if you are already used to GRUB. Hydrogen is based on the ideas of Pure64. Keep in mind that Pure64 only supports loading a kernel from a FAT16-formatted hard drive.

-Ian

Wow. just. wow. I am sold, will definitely use hydrogen. It looks like it has all the bits that pure64 was missing by being a stage 2 loader and I am able to control a lot more of its operation so its all good I will let you know how it goes.

Thanks bluemoon, I did know the fields are 64 bit but what I mean is my code currently throws away the top 32 bits of the values, there are lots of iffy bits of old code like this to keep me busy for ages...