For those interested in testing: here is a rediff and some updates. Soon
I'll split it into components
phcoder wrote:
Robert Millan wrote:
Would it be hard to split the patch and make it more granular? I see it
implements base mmap / lsmmap support on efi, then ports the *BSD loaders
and the M
On Wednesday 01 April 2009 21:57:55 Robert Millan wrote:
> On Sat, Mar 28, 2009 at 11:31:14PM +0900, Yoshinori K. Okuji wrote:
> > On Saturday 28 March 2009 22:13:06 Robert Millan wrote:
> > > Do we need the memory map to be sorted? AFAIK loadees can cope with
> > > unsorted maps fine; is there a
On Sat, Mar 28, 2009 at 11:31:14PM +0900, Yoshinori K. Okuji wrote:
> On Saturday 28 March 2009 22:13:06 Robert Millan wrote:
> > Do we need the memory map to be sorted? AFAIK loadees can cope with
> > unsorted maps fine; is there an exception?
>
> As I wrote in the draft, a boot loader should s
Robert Millan wrote:
Would it be hard to split the patch and make it more granular? I see it
implements base mmap / lsmmap support on efi, then ports the *BSD loaders
and the Multiboot loader too, and the uppermem facility.
The only reason why it's not splitted is that it's totally "preview".
W
On Saturday 28 March 2009 22:13:06 Robert Millan wrote:
> Do we need the memory map to be sorted? AFAIK loadees can cope with
> unsorted maps fine; is there an exception?
As I wrote in the draft, a boot loader should sort the memory map. An OS image
must deal with an unsorted memory map, becaus
On Mon, Mar 23, 2009 at 01:29:55PM +0100, phcoder wrote:
> Hello. Here is an initial version of patch for booting multiboot kernels
> on i386-efi. No Changelog yet because it's not for inclusion yet.
Very nice!
Would it be hard to split the patch and make it more granular? I see it
implements
Hello. Unfortunately my laptop broke down. I have a copy of all my data but
no system suitable for developement. So I'll take a break (about a week
probably) from grub2 developement.
BTW I have also some initial work on i386/linux and i386/efi/linux
unification.
On Tue, Mar 24, 2009 at 11:58 AM,
Ok. I see.
So I will wait for rediffed patches and number of revision.
Thank you in advance.
On Tue, Mar 24, 2009 at 12:54 PM, phcoder wrote:
> Hello. I have to write rights to svn. And even if I had I would never commit
> a code in such stage (not reviewed, tested only on qemu, still in
> deve
Hello. I have to write rights to svn. And even if I had I would never
commit a code in such stage (not reviewed, tested only on qemu, still in
developement)
However I'll rediff the code against HEAD when I'll have time
uzer cheg wrote:
Dear Vladimir,
I tried rev 2030 and 2037.
And I also had f
Dear Vladimir,
I tried rev 2030 and 2037.
And I also had few errors on patching stage.
I think it is a good idea to commit your code to head branch.
I will wait for it and try it asap.
Thank you.
On Tue, Mar 24, 2009 at 12:14 AM, phcoder wrote:
> Try with 2030. Actually it's diffed against 2030
You may also need my elf bugfix patch (was applied as rev 2037)
phcoder wrote:
Try with 2030. Actually it's diffed against 2030+some of my posted and
unposted patches. If it still doesn't apply please report I'll update
and rediff it against HEAD.
I'm interested in behaviour of this code on real
Try with 2030. Actually it's diffed against 2030+some of my posted and
unposted patches. If it still doesn't apply please report I'll update
and rediff it against HEAD.
I'm interested in behaviour of this code on real EFI however doesn't
expect this version to be able to work completely.
x86_64
Vladimir,
First of all I'd like to say thank you for a quick feedback and development.
I tried to apply your patches and test it on my Apple Xserve Intel 32 bit.
I've done following;
# svn co svn://svn.sv.gnu.org/grub/trunk/grub2
# cd ./grub2
# patch -b -p1 < ./uppermem.diff
patching file conf/
13 matches
Mail list logo
