Re: Would a cleanup+extending of docs/multiboot.h be acceptable?

["Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2600 bytes --]

On 08.04.2011 16:43, Goswin von Brederlow wrote:
> "Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com> writes:
>
>> On 07.04.2011 19:32, Goswin von Brederlow wrote:
>>> I see that you have added 32bit MIPS support. No 64bit x86_64 support
>>> though. So my trampoline + 64bit kernel stuff would still be interesting
>>> to people.
>> We already have the needed infrastructure to load in 64-bit mode. Have a
>> look at loader/i386/bsd.c. Mostly you just need to use
>> grub_relocator64_boot and not grub_relocator32_boot. The main issue is
>> clear specification of intended behaviour.
> I'm adding an implementation of this to kvm, proof of concept kind of
> way. For that I'm assuming the following changes to the specs:
>
> // Why is this in steps of 4?
> #define MULTIBOOT_ARCHITECTURE_X86_64  8
> #define MULTIBOOT_ARCHITECTURE_MIPS64  12
>
Because the lower 2 bits pertain to the number of bits on platform.
0 -> 32
1 -> 64
2 -> 16
3 -> everything else
Are you familiar with mips? Unlike on x86, mips32 and mips64 don't refer
to different modes but mips32 is a subset of mips64. So unless you're
familiar with mips, leave this part out for now.
> All structures remain as they are. That means that addresses must be
> below 4GB (maybe even 2GB or sign extention screws things up) unless
> they are defined as 64bit (memory mappings use 64bit, entry point only
> 32bit). The kernel + modules must be loaded below 4GB (2GB?).
>
No. For 64-bit mode all fields must be extended to 64-bit and kernel and
modules can be loaded anywhere
> The system state when leaving the bootloader is like in 32bit but
> modified as follows:
>
> - PAE is enabled
> - Paging is enabled
> - Long mode is enabled
> - Long mode is active
> - CS contains a 64bit code segment
> - the lower 4GB of memory are mapped 1:1 accessible R/W to Ring 0 and in
>   2MB granularity
>
I would rather make it "all segments reffered to in memory map are P=V
mapped". It may be good to specify where page table is to be located to
ease avoiding overwriting it.
> I'm tempted to add 2 new info tags: multiboot_tag_gpt and
This would be a separate proposal. I think it would be better to have a
tag for partition start and end byte rather than the partition number.
> multiboot_tag_page_tables. The later would contain the number of tables
> and an array of pointers to the pages. But that might be too i386/x86
> specific.
>
This information is available through cr registers.
> MfG
>         Goswin
>
>


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]