On 08.04.2011 16:43, Goswin von Brederlow wrote: > "Vladimir 'φ-coder/phcoder' Serbinenko" <phco...@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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
