Follow-Up to 1MB Allocation Problem

[Bret Barkelew]

Hi,While searching for an answer to the same problem, I stumbled across a
posting on this mailing list:
http://www.mail-archive.com/elilo-discuss-5NWGOfrQmneRv+***@public.gmane.org/msg00085.html

I wanted to take a stab at patching it to work generically using a dynamic
address returned from AllocatePages, but I get the impression that this is
more complicated than just changing the address.

What else needs to be fixed to make it work properly?
Something about relocating the kernel image?

Thanks for any help.

[Jason Fleischli]

Hi, While searching for an answer to the same problem, I stumbled
I wanted to take a stab at patching it to work generically using a
dynamic address returned from AllocatePages, but I get the impression
that this is more complicated than just changing the address.
What else needs to be fixed to make it work properly? Something about
relocating the kernel image?
Thanks for any help.
-- Jonathan Barkelew

Essentially the kernel "relocatable" option implemented in the ia64
subtree (see elilo/ia64/config.c)needs to be implemented for ia32 &
x86_64 or perhaps elilo can be smartened up to figure it out,
havent looked into that route yet.

-jason
--
___________________________________
JASON FLEISCHLI
HP - Alliances, Linux, & Performance Solutions
Ft. Collins CO [phone]


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

[S***@public.gmane.org]

I've been working on this for x86_64 bzimage... for bzimage, if the
kernel was compiled to be relocatable (see the kernel source, in
Documentation/x86/i386/boot.txt, and CONFIG_RELOCATABLE), you just need
to allocate some memory for the kernel and load it there, then jump to
the right address. The startup code checks the address it's at and does
the right thing.

I'm almost done with a patch to add support for relocatable bzimage
kernels for x86_64. I've been running into a problem where I'm getting
an "invalid parameter" error when I try to open files... I think it
might be related to stack usage, and it's definitely related to the
Print function. As soon as I work that out I'll send in my patch.

Thanks,
Stuart

-----Original Message-----
From: Jason Fleischli [mailto:jason.fleischli-***@public.gmane.org]
Sent: Monday, December 01, 2008 5:37 PM
To: Bret Barkelew
Cc: elilo-discuss-5NWGOfrQmneRv+***@public.gmane.org
Subject: Re: [elilo-discuss] Follow-Up to 1MB Allocation Problem

Hi, While searching for an answer to the same problem, I stumbled
85.html
I wanted to take a stab at patching it to work generically using a
dynamic address returned from AllocatePages, but I get the impression
that this is more complicated than just changing the address.
What else needs to be fixed to make it work properly? Something about
relocating the kernel image?
Thanks for any help.
-- Jonathan Barkelew

Essentially the kernel "relocatable" option implemented in the ia64
subtree (see elilo/ia64/config.c)needs to be implemented for ia32 &
x86_64 or perhaps elilo can be smartened up to figure it out, havent
looked into that route yet.

-jason

--
___________________________________
JASON FLEISCHLI
HP - Alliances, Linux, & Performance Solutions Ft. Collins CO
[phone]


------------------------------------------------------------------------
-
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the
world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
elilo-discuss mailing list
elilo-discuss-5NWGOfrQmneRv+***@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/elilo-discuss

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

[Bret Barkelew]

Perhaps this is a terminally stupid question, but I'm a bit new to the
kernel....Would it not be possible to allocate memory, and manually fix-up
the addresses in the kernel image?

Post by S***@public.gmane.org
I've been working on this for x86_64 bzimage... for bzimage, if the
kernel was compiled to be relocatable (see the kernel source, in
Documentation/x86/i386/boot.txt, and CONFIG_RELOCATABLE), you just need
to allocate some memory for the kernel and load it there, then jump to
the right address. The startup code checks the address it's at and does
the right thing.
I'm almost done with a patch to add support for relocatable bzimage
kernels for x86_64. I've been running into a problem where I'm getting
an "invalid parameter" error when I try to open files... I think it
might be related to stack usage, and it's definitely related to the
Print function. As soon as I work that out I'll send in my patch.
Thanks,
Stuart
-----Original Message-----
Sent: Monday, December 01, 2008 5:37 PM
To: Bret Barkelew
Subject: Re: [elilo-discuss] Follow-Up to 1MB Allocation Problem

Hi, While searching for an answer to the same problem, I stumbled
85.html
I wanted to take a stab at patching it to work generically using a
dynamic address returned from AllocatePages, but I get the impression
that this is more complicated than just changing the address.
What else needs to be fixed to make it work properly? Something about
relocating the kernel image?
Thanks for any help.
-- Jonathan Barkelew

Essentially the kernel "relocatable" option implemented in the ia64
subtree (see elilo/ia64/config.c)needs to be implemented for ia32 &
x86_64 or perhaps elilo can be smartened up to figure it out, havent
looked into that route yet.
-jason
--
___________________________________
JASON FLEISCHLI
HP - Alliances, Linux, & Performance Solutions Ft. Collins CO
[phone]
------------------------------------------------------------------------
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
elilo-discuss mailing list
https://lists.sourceforge.net/lists/listinfo/elilo-discuss

[S***@public.gmane.org]

The firmware was returning "invalid arguments" when elilo was trying to
open files (kernel and/or initrd). I would get this sometimes, or not,
based on seemingly unrelated code changes. I found that the problem was
with the "attributes" value being passed to the Open()
function--attributes is a 64-bit number, but the hard-coded "0" that
elilo was passing to uefi_call_wrapper() was defaulting to a 32-bit
number (because uefi_call_wrapper() uses a variable argument list like
printf()!). The upper 64 bits were undefined, and, if they were not 0,
the Open() call would fail because the attributes had invalid bits set.

Here's a patch that fixes that.

Thanks!
Stuart


diff -purN elilo-3.8-3.35-orig//fs/localfs.c
elilo-3.8-3.35-attrfix/fs/localfs.c
--- elilo-3.8-3.35-orig//fs/localfs.c 2008-11-19 07:52:38.000000000
-0600
+++ elilo-3.8-3.35-attrfix/fs/localfs.c 2008-12-04 04:58:10.000000000
-0600
@@ -98,7 +98,7 @@ localfs_open(localfs_interface_t *this,

DBG_PRT((L"localfs_open on %s\n", name));

- status = uefi_call_wrapper(lfs->volume->Open, 5, lfs->volume, &fh,
name, EFI_FILE_MODE_READ, 0);
+ status = uefi_call_wrapper(lfs->volume->Open, 5, lfs->volume, &fh,
name, EFI_FILE_MODE_READ, (UINT64)0);
if (status == EFI_SUCCESS) {
*fd = LOCALFS_F2FD(fh);
}

[S***@public.gmane.org]

Here's one solution to the problem, for bzImages in x86_64 (which could
easily be ported to the other image types and architecture). I tried to
make this minimally invasive. If bzImage_probe() can't load the kernel
where it should be, it will just load the kernel anywhere, and it will
be moved to the right address after elilo exits EFI boot services. (I
also made it read where the kernel should be from the kernel header.)
It looks like it was already loading the initrd just anywhere and then
moving it after exiting boot services.

(I also enhanced the "MEMCPY" macro in x86_64/sysdeps.h so it will copy
to an overlapping area correctly regardless of whether the "from"
address is higher or lower than the "to" address.)

I originally wrote code that would actually check if the kernel was
relocatable and then relocate it, like the ia64 code does. That worked
fine, except that the address that was found overlapped the area where
elilo copies the initrd in start_kernel() after EFI boot services are
exited! Instead of modifying the initrd addresses, too, I decided it
would be easier and less likely to break anyting else (and would work
with non-relocatable kernels, too) to just do it the other way.

Any chance we could get this patch into elilo? I can modify and
resubmit if there are any issues with this approach.

Thanks!
(patch attached)

[Jason Fleischli]

Post by S***@public.gmane.org
I originally wrote code that would actually check if the kernel was
relocatable and then relocate it, like the ia64 code does. That worked
fine, except that the address that was found overlapped the area where
elilo copies the initrd in start_kernel() after EFI boot services are
exited! Instead of modifying the initrd addresses, too, I decided it
would be easier and less likely to break anyting else (and would work
with non-relocatable kernels, too) to just do it the other way.
Any chance we could get this patch into elilo? I can modify and
resubmit if there are any issues with this approach.

I'll have a look, sounds like a better solution. let you know
and Thanks for the work!

-jason