ELF64 patch

2005-07-13 Thread Ruslan Nikolaev
k_header(ehdr, sizeof(*ehdr))) + goto bad_header; + x86_elf64to32(buffer); +} + /* usual ELF32 for i386 */ + else if (grub_dl_check_header (ehdr, sizeof(*ehdr))) { + bad_header: grub_error (GRUB_ERR_UNKNOWN

Re: [PATCH] ELF64

2005-07-14 Thread Ruslan Nikolaev
Yesterday I sent patch for ELF64 multiboot support: http://lists.gnu.org/archive/html/grub-devel/2005-07/msg00102.html Any ideas about it?   -- ___Sign-up for Ads Free at Mail.com http://www.mail.com/?sr=signup __

[PATCH] new ELF64 patch

2005-07-16 Thread Ruslan Nikolaev
Hi! Ok patch for x86_64 ELF64 support was rewritten. diff -urN old/multiboot.c new/multiboot.c --- old/multiboot.c 2005-07-17 02:50:11.978394408 +0400 +++ new/multiboot.c 2005-07-17 02:49:41.069093336 +0400 @@ -89,7 +89,14 @@ struct grub_multiboot_header *header; grub_ssize

Re: [PATCH] new ELF64 patch

2005-07-17 Thread Ruslan Nikolaev
Hi! I sent new patch for mutiboot: http://lists.gnu.org/archive/html/grub-devel/2005-07/msg00130.html  Is it correct now? By the way... I have seen that grub2 has a 4Gb limit when detecting memory size and mmap. I think that is not good for both x86 and x86_64. i686 for example can use 64 Gb of RAM

Re: 4Gb memory limit and ELF64

2005-07-18 Thread Ruslan Nikolaev
Hi! When I say about 4Gb limit it means 4Gb limit when GRUB passing memory information for OS using multiboot specs. I have seen that GRUB doesn't want to detect more than 4Gb of RAM. In that case OS gets only 4Gb using multiboot specs. Of course GRUB doesn't need more than 4Gb and it's OK, but OS

Re: [PATCH] ELF64 and changelog and 4Gb

2005-07-19 Thread Ruslan Nikolaev
y->len); add_mem_region (addr, len);   } Memory regions addr and len also is a 32-bit when BIOS provides it as a 64-bit numbers. Of course I can be wrong because I don't know grub code very well.   New ChangeLog: 2005-07-17 Ruslan Nikolaev <[EMAIL PROTECTED]> * multiboot.c (gr

[PATCH] Updated ELF64 multiboot

2005-07-27 Thread Ruslan Nikolaev
Hi! I've found some time and update patch. Now it contains functions grub_load_elf32, grub_load_elf64 and grub_load_elf. The changes are the same but now code splitted into 3 functions. In fact I don't have free time at all now :(   New patch: diff -urN old/multiboot.c new/multiboot.c--- old/multib

mmap question

2005-08-02 Thread Ruslan Nikolaev
OK. Possible I'll get free time next week and can do something :) I have some questions: 1. Memory limit that was argued not long ago. I think that memory size variable should be 64-bit size and also full mmap support would come... I can try to do it. 2. Also I have a question about disk offsets. N

[PATCH] x86_64 compiling

2005-08-08 Thread Ruslan Nikolaev
uring configuring. What do you think about it? 2005-08-08  Ruslan Nikolaev  <[EMAIL PROTECTED]>  * configure.ac: Added x86_64 support.   PATCH: diff -urN old/configure.ac new/configure.ac --- old/configure.ac 2005-08-08 19:08:41.0 + +++ new/configure.ac 2005-08-09 01:25:14.1352

[PATCH] x86_64 compiling (fixed message)

2005-08-08 Thread Ruslan Nikolaev
I'm sorry... Previous message contains patch w/o new lines. PATCH: diff -urN old/configure.ac new/configure.ac --- old/configure.ac 2005-08-08 19:08:41.0 + +++ new/configure.ac 2005-08-09 01:25:14.135290880 + @@ -22,16 +22,27 @@ case "$host_cpu" in i[[3456]]86) host_cpu=i386 ;; + x

[PATCH] compiling on x86_64 (again)

2005-08-09 Thread Ruslan Nikolaev
  Ruslan Nikolaev  <[EMAIL PROTECTED]>    * configure.ac: Added x86_64 support.   PATCH:   diff -urN old/configure.ac new/configure.ac--- old/configure.ac 2005-08-08 19:08:41.0 ++++ new/configure.ac 2005-08-09 01:25:14.135290880 +@@ -22,16 +22,27 @@  case "$host_cpu"

[PATCH] mmap support and x86_64 CPU detection

2005-08-13 Thread Ruslan Nikolaev
data size checking (just for testing my patch). ChangeLog: ChangeLog: 2005-08-13  Ruslan Nikolaev  <[EMAIL PROTECTED]>  * kern/i386/pc/startup.S (grub_x86_64_cpu): New function.  * loader/i386/pc/multiboot.c (grub_multiboot_mmap): New function. (grub_load_elf64): Make sure that we h

Re: [PATCH] mmap support and x86_64 detection

2005-08-14 Thread Ruslan Nikolaev
Hi!   Yesterday I sent patch for mmap support and x86_64 detection. What do you think about? I need to known about it becuase I'll be busy this week...   Ruslan. Start your day with Yahoo! - make it your home page ___ Grub-devel mailing list Grub-deve

[PATCH] new (mmap support and x86_64 detection)

2005-08-15 Thread Ruslan Nikolaev
  Is it good now? What do you think?   Ruslan.   ChangeLog:   2005-08-16  Ruslan Nikolaev  <[EMAIL PROTECTED]>  * loader/i386/pc/multiboot.c (grub_multiboot_mmap): New function.  (grub_x86_64_cpu): Likewise. (grub_multiboot_load_elf64): Make sure that we have deal with x86_64 CPU. (grub_resc

Re: [PATCH] new (mmap support and x86_64 detection)

2005-08-16 Thread Ruslan Nikolaev
OK. I've changed it to grub_multiboot_detect_x86_64(). I'll busy for a week or even more. Please say if something wrong. diff -urN old/grub-1.90/include/grub/i386/pc/init.h new/grub-1.90/include/grub/i386/pc/init.h --- old/grub-1.90/include/grub/i386/pc/init.h 2005-02-01 00:40:25.0 +0300

[DISCUSSION] Multiboot entry point

2005-08-17 Thread Ruslan Nikolaev
Hi!   I have a one question. GRUB requires have a kernel as an executable file (at least for ELF). This is not very good from user point. For example user can try to load such kernel at operating system and get something like "Segmentation fault".   I think that having kernel as a non-executable fi

[QUESTION] Multiboot again

2005-08-18 Thread Ruslan Nikolaev
t;[EMAIL PROTECTED]> wrote: On Thursday 18 August 2005 00:27, Ruslan Nikolaev wrote:> I have a one question. GRUB requires have a kernel as an executable file> (at least for ELF). This is not very good from user point. For example user> can try to load such kernel at operating

[PATCH] x86_64 again (related with my previous topics)

2005-08-19 Thread Ruslan Nikolaev
Hi all! First of all I want to say that all things I said are related with x86_64.x86_64 implements 48-bit virtual address space. As AMD writes the bits from 64 to 48 (or implementation limit) should be all ones or all zeros.In that case with have "sign-extended" address.Also x86_64 uses 4 memory m

Re: [PATCH] x86_64 again (related with my previous topics)

2005-08-20 Thread Ruslan Nikolaev
vides negative virtual addresses for all symbols (you can find it in System.map or directly in vmlinux ELF). Entry point for ELF also has negative address. For example you can see it in my previous post. --   "Yoshinori K. Okuji" <[EMAIL PROTECTED]> wrote: On Saturday 20 A

x86_64 imporatant information

2005-08-20 Thread Ruslan Nikolaev
In my previous post I forgot to say about the most imporatant reason to use negative addresses.   Take a look on the following information:   - /usr/src/linux/vmlinux: file format elf64-x86-64 Sections:Idx Name  Size  VMA   LMA

thank you

2005-08-21 Thread Ruslan Nikolaev
i" <[EMAIL PROTECTED]> wrote: On Sunday 21 August 2005 01:25, Ruslan Nikolaev wrote:> I think it's just because we need to use special memory model> "-mcmodel=kernel" that's designed especially for kernel. Does we have> problems when LMA != VMA and using this mem

[PATCH] new patch for amd64

2005-09-20 Thread Ruslan Nikolaev
Hi all! I have seen another patch for amd64 by Marco Gerards. In fact month ago I sent the patch that also allows compiling on x86_64.   By the way I decided to send new patch (it's really works with amd64).   Some bugs was fixed: - it doesn't break x86 compiling now (small bug) - it allows you to

Re: 2Marco Gerards

2005-09-21 Thread Ruslan Nikolaev
> Why can't you test for the regparam=3 bug?   Because it requires to build 32-bit file. As I said before this patch will work even the OS can't load 32-bit executables at all. I'm not sure about compiling it as a 64-bit file because it generates another code; moreover x86_64 accepts regparam=6. Pe

Re: 2Yoshinori K. Okuji

2005-09-21 Thread Ruslan Nikolaev
> I have no idea which patch is better, so please decide it with Marco. I also can't say what is better. However my patch already works perfectly on my x86_64 machine with Linux w/o 32-bit binaries support. All compiled utilities are 64-bit. Chainloading, multiboot and linux loading working. The pa

Re: 2Marco Gerards (new)

2005-09-21 Thread Ruslan Nikolaev
2Marco Gerards   My mistake. Please read first line as "Because it requires to load 32-bit file..."Ruslan Nikolaev <[EMAIL PROTECTED]> wrote: > Why can't you test for the regparam=3 bug?   Because it requires to build 32-bit file. As I said before this patch will work e

Re: 2Marco Gerards (important info)

2005-09-22 Thread Ruslan Nikolaev
Just want to inform you about other problems.   Please note that all other testings (expect for OBJCOPY) during configure _MUST_ BE DONE in 64-bit mode compiling. Otherwise I had problems with Linux w/o 32-bit support (there are problems with building because I haven't 32-bit libraries and so on).

Re: 2Marco Gerards (answer)

2005-09-24 Thread Ruslan Nikolaev
The problem that is related with REGPARAM test:   During configuring the test of regparm bug will be compiled and then executed. First: it can't properly compiled if you haven't 32-bit libraries Second: it can't be executed if system can't execute 32-bit executables Third: you can't compile this te