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
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
__
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
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
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
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
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
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
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
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
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"
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
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
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
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
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
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
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
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
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
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
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
> 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
> 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
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
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).
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
27 matches
Mail list logo