Re: multiboot on EFI

[uzer cheg]

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+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-efi isn't supported by this patch yet
> Also if xen uses any bios interrupts it will probably triple fault. On IRC
> we discussed a possibility of loading seabios and it's probably feasible but
> will take more time
> uzer cheg wrote:
>>
>> 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/i386.rmk
>> patching file lib/i386/uppermem.c
>>  --- it's Ok
>>  --- Than
>> #  patch -b -p1 < ./efiboot.diff
>> patching file conf/common.rmk
>> Hunk #1 succeeded at 503 (offset -4 lines).
>> patching file conf/i386-coreboot.rmk
>> Hunk #1 succeeded at 99 with fuzz 2 (offset -3 lines).
>> Hunk #2 succeeded at 200 (offset -10 lines).
>> patching file conf/i386-efi.rmk
>> Hunk #1 FAILED at 80.
>> Hunk #2 FAILED at 103.
>> ...
>> etc.
>>
>>
>> I would like to ask you for what revision of grub2 this patches where
>> done?
>> Do I have to checkout any specific branch of grub2?
>>
>> Thank you in advance.
>>
>> 2009/3/23 phcoder :
>>>
>>> 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.
>>> --
>>>
>>> Regards
>>> Vladimir 'phcoder' Serbinenko
>>>
>>> ___
>>> Grub-devel mailing list
>>> Grub-devel@gnu.org
>>> http://lists.gnu.org/mailman/listinfo/grub-devel
>>>
>>>
>>
>>
>> ___
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>
> --
>
> Regards
> Vladimir 'phcoder' Serbinenko
>
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: multiboot on EFI

[phcoder]

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 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+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-efi isn't supported by this patch yet
Also if xen uses any bios interrupts it will probably triple fault. On IRC
we discussed a possibility of loading seabios and it's probably feasible but
will take more time
uzer cheg wrote:

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/i386.rmk
patching file lib/i386/uppermem.c
 --- it's Ok
 --- Than
#  patch -b -p1 < ./efiboot.diff
patching file conf/common.rmk
Hunk #1 succeeded at 503 (offset -4 lines).
patching file conf/i386-coreboot.rmk
Hunk #1 succeeded at 99 with fuzz 2 (offset -3 lines).
Hunk #2 succeeded at 200 (offset -10 lines).
patching file conf/i386-efi.rmk
Hunk #1 FAILED at 80.
Hunk #2 FAILED at 103.
...
etc.


I would like to ask you for what revision of grub2 this patches where
done?
Do I have to checkout any specific branch of grub2?

Thank you in advance.

2009/3/23 phcoder :

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.
--

Regards
Vladimir 'phcoder' Serbinenko

___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel




___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel


--

Regards
Vladimir 'phcoder' Serbinenko


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel




___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel



--

Regards
Vladimir 'phcoder' Serbinenko


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: multiboot on EFI

[uzer cheg]

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
> 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 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+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-efi isn't supported by this patch yet
>>> Also if xen uses any bios interrupts it will probably triple fault. On
>>> IRC
>>> we discussed a possibility of loading seabios and it's probably feasible
>>> but
>>> will take more time
>>> uzer cheg wrote:

 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/i386.rmk
 patching file lib/i386/uppermem.c
  --- it's Ok
  --- Than
 #  patch -b -p1 < ./efiboot.diff
 patching file conf/common.rmk
 Hunk #1 succeeded at 503 (offset -4 lines).
 patching file conf/i386-coreboot.rmk
 Hunk #1 succeeded at 99 with fuzz 2 (offset -3 lines).
 Hunk #2 succeeded at 200 (offset -10 lines).
 patching file conf/i386-efi.rmk
 Hunk #1 FAILED at 80.
 Hunk #2 FAILED at 103.
 ...
 etc.


 I would like to ask you for what revision of grub2 this patches where
 done?
 Do I have to checkout any specific branch of grub2?

 Thank you in advance.

 2009/3/23 phcoder :
>
> 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.
> --
>
> Regards
> Vladimir 'phcoder' Serbinenko
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>

 ___
 Grub-devel mailing list
 Grub-devel@gnu.org
 http://lists.gnu.org/mailman/listinfo/grub-devel
>>>
>>> --
>>>
>>> Regards
>>> Vladimir 'phcoder' Serbinenko
>>>
>>>
>>> ___
>>> Grub-devel mailing list
>>> Grub-devel@gnu.org
>>> http://lists.gnu.org/mailman/listinfo/grub-devel
>>>
>>
>>
>> ___
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>
> --
>
> Regards
> Vladimir 'phcoder' Serbinenko
>
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] New frame buffer detection algorithm and loadrom command for efi platform

[Peter Cros]

Hi,
svn rev 2043 patched loadrom.diff on imac81 with ati fglrx.

I find loadrom needs time when called in menuentry, otherwise linux load
fails or loadrom fails. So I had to use sleep.
Then it works very nicely.
--
insmod sleep

menuentry "loadrom hd0,4 sda4" {
search --set /ivt.bin
loadrom /bios.bin /ivt.bin
sleep 1
root=hd0,4
linux /vmlinuz root=/dev/sda4 video=vesafb
initrd /initrd.img
}

This is not apparent from command line with manual entry pauses.
-

2009/3/21 Bean 

> Hi,
>
> This patch improves the frame buffer detection algorithm. It uses pci
> to find the video memory base, then scan it for frame buffer.
>
> It also add a loadrom command which can be used to enable accel
> graphic driver. The idea is that you can grab the video bios dump, and
> optionally the IVT from pc mode, then load them in efi.
>
> To grab bios dump:
> sudo dd if=/dev/mem of=bios.bin bs=65536 skip=12 count=1
>
> You can also include the system bios by changing the count to 4.
>
> To grab IVT dump:
> sudo dd if=/dev/mem of=ivt.bin bs=1024 count=1
>
> Then, to load them in grub-efi (ivt.bin is optionally):
> loadrom /bios.bin /ivt.bin
>
> Here are some of the findings concerning different video cards:
>
> Old 32-bit efi model, intel card:
> Works with intel driver, no need to load vbios or ivt.
>
> New 64-bit efi model, intel card:
> Works with intel driver, needs to load vbios.
>
> New 64-bit efi model, nvidia card:
> Works with nvidia driver, no needs to load vbios or ivt. However, the
> backlight value is set too low so desktop is barely visible. You need
> to use a small tool to adjust backlight. The nv driver doesn't work.
>
> New 64-bit efi model, ati radeon card:
> Works with fglrx driver, needs to load vbios and ivt. The radeonhd
> driver doesn't work.
>
> --
> Bean
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>


-- 
Cros (pxw)
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: GRUB2 is not working from pendrive

[J. Bakshi]

On Mon, 23 Mar 2009 21:21:41 -0400
Pavel Roskin  wrote:

> On Sun, 2009-03-15 at 21:06 +0530, J.Bakshi wrote:
> > Dear list,
> > 
> > With legacy GRUB I have no problem to install it on a pendrive and
> > boot the grub legacy from that drive. Presently I am trying to do
> > the same with grub2.
> > 
> > My pendrive is 8 GB Transcend with 2 partitions. /devsda1 is fat32
> > (2 GB) and /dev/sda2 is reiserfs (6 GB).
> > 
> > My system is debian lenny and grub Version: 1.96+20080724-16
> > 
> > I have mounted my pendrive as ( the reiserfs partition)
> > 
> > ~
> > mount /dev/sda2  /mnt/pen
> > ~~~
> > 
> > Then install grub as
> > 
> > ~
> > grub-install --root-directory=/mnt/pen /dev/sda2
> > ~
> 
> This installs the bootloader to the first sector of the
> partition /dev/sda2, not to the MBR (the first sector of the whole
> drive).  BIOS loads the code from the MBR.  To install GRUB2 to the
> MBR of the drive, use

thanks a lot. Actually the grub did not recognise the device node of
pendrive. I re-generate the device map with pendrive attached at USB
and now I have no problem to install grub on it. And yes; it must be 
grub-install --root-directory=/mnt/pen /dev/sda

Thanks


> 
> grub-install --root-directory=/mnt/pen /dev/sda
> 
> > Grub install reports a success message. Then I copy grub.cfg from
> > my HDD to the pendrive at the same location i.e /mnt/pen/boot/grub/
> > 
> > Now If I try to boot from the pendrive it says found boot
> > record ...OK and then displays GRUB but nothing further happens :-(
> 
> Perhaps you have an old GRUB bootloader in the MBR but it fails to
> find its files.
> 
> I checked reiserfs support in the current GRUB2 and it appears to be
> OK.
> 
> > What might be the wrong I have done here ?
> 
> You installed the bootloader to a place where BIOS cannot access it.
> It's not a regression.  grub-legacy would have the same problem.
> 


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

unknown command 'boot' with coreboot/grub2

[Ward Vandewege]

I've built grub2 from source (r2045). My modules list is:

MODULES="minicmd normal ls cat help ext2 iso9660 reiserfs xfs fat pc gpt ata
serial memdisk multiboot linux configfile search tar"

but when booting a multiboot xen kernel I get

 unknown command 'boot'

My grub stanza is:

  menuentry "Xen 3.1.4" {
set root=(ata0,1)
multiboot /boot/xen-3.gz no-real-mode com1=115200,8n1 console=com1,vga
module /boot/vmlinuz-2.6.18.8-xen root=/dev/hda1 ro console=tty0 
console=ttyS0,115200n8
module  /boot/initrd.img-2.6.18.8-xen
  }

Am I missing a module, or is the order wrong?

Thanks,
Ward.

-- 
Ward Vandewege 
Free Software Foundation - Senior Systems Administrator


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: precision formatting in grub_printf

[Christian Franke]

Deepak Vankadaru wrote:

Hi,

There was a redundant piece of code in the diff file I sent earlier. I 
have removed it and prepared another patch file. I am attaching the 
same. Please use this one instead.


Following is the changelog.

Changelog:
2008-08-17  Deepak Vankadaru  >


   Support for precision formatting in grub_printf

   * kern/misc.c: modified grub_vsprintf to parse and handle 
precision formatting




Thanks.

Unfortunately, the patch can no longer be applied to current svn without 
a conflict.
The precision parsing and '%s' precision (truncation) handling is 
already implemented.


But the '%d' precision (zero fill) handling part of your patch is still 
missing in the code.


Could you please repost an updated patch in diff -u format?
Note that the current code does not use a format2_default flag buts sets 
format2 to ~0U ('infinite' :-) if no precision is specified.


Thanks

--
Christian Franke



___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

grub-emu is broken since rev 2036

[Felix Zielcke]

Hi,

since revision 2036, i.e. Bean's command rewrite grub-emu is broken. On
every command you'll get `invalid arch independent ELF magic'.

-- 
Felix Zielcke



___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Overlaying default grub.cfg makes qemu "fat:" partition inaccessible

[James Collier]

Hi all,
I'm using GRUB2 from svn (r2039) with qemu.
Steps I take to reproduce:
1. create an overlay directory e.g. /grub2/overlay
2. populate the directory with
overlay/boot
overlay/boot/grub
overlay/goot/grub/grub.cfg
Where grub.cfg contains "some-menuentry" for example I use:
menuentry "Viengoos" {
multiboot /viengoos -D 3 -o serial
module /hieronymus
}

3. run (option1): 
$ cd /grub2
$ grub-mkrescue --image-type=floppy --emulation=floppy \
--overlay=overlay  grub2-boot-floppy


or (option2): 
$ cd /grub2
$ grub-mkrescue --image-type=cdrom --overlay=overlay \ grub2-boot-cdrom

4. start qemu with:
$ cd /grub2
(option 1):
$ qemu --serial stdio -hda fat:kernel-dir -fda grub2-boot-floppy -boot a
or
(option 2):
$ qemu --serial stdio -hda fat:kernel-dir -fda grub2-boot-cdrom -boot d

In the case of option 1, grub2 boots straight to the menu as expected.
Typeing 'c' to get to the prompt then 'ls' at the prompt reveals only
the (memdisk) device.
It was expected that at least (hd0,1) for the -hda fat: partition would
be available

Option: following the above and typing 'ls' at the prompt reveals
(hd0) and (hd96) where (hd0,1) was also expected as above.

qemu version 0.9.1

Thanks,

James Collier


signature.asc
Description: This is a digitally signed message part
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Overlaying default grub.cfg makes qemu "fat:" partition inaccessible

[Pavel Roskin]

Quoting James Collier :


In the case of option 1, grub2 boots straight to the menu as expected.
Typeing 'c' to get to the prompt then 'ls' at the prompt reveals only
the (memdisk) device.
It was expected that at least (hd0,1) for the -hda fat: partition would
be available


Even without the -hda option, you should get (fd0).  I can reproduce  
the problem with the current GRUB.


My impression is that loading grub.cfg stops the initial automatic  
loading of the modules for the existing hardware.  You still can load  
such modules manually:


insmod biosdisk
insmod pc

After that, ls will show (fd0) and other devices.

It looks like a bug to me.

--
Regards,
Pavel Roskin


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: grub-emu is broken since rev 2036

[Bean]

On Wed, Mar 25, 2009 at 5:41 AM, Felix Zielcke  wrote:
> Hi,
>
> since revision 2036, i.e. Bean's command rewrite grub-emu is broken. On
> every command you'll get `invalid arch independent ELF magic'.

Hi,

This is caused by the dynamic loading of commands. In normal.mod, it
scans command.lst and tries to load command on demand. However, the
modules on disk are pc booting, they can't be loaded by grub-emu. The
solution is to point the root device elsewhere with -r option, so that
command.lst won't be found.

-- 
Bean


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel