Re: multiboot on EFI

2009-03-24 Thread 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 phco...@gmail.com 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 phco...@gmail.com:

 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

2009-03-24 Thread 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 phco...@gmail.com 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 phco...@gmail.com:

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

2009-03-24 Thread 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 phco...@gmail.com 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 phco...@gmail.com 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 phco...@gmail.com:

 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

2009-03-24 Thread 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 bean12...@gmail.com

 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

2009-03-24 Thread J. Bakshi
On Mon, 23 Mar 2009 21:21:41 -0400
Pavel Roskin pro...@gnu.org 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

2009-03-24 Thread 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 w...@fsf.org
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

2009-03-24 Thread 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  deepak.vankad...@gmail.com 
mailto:deepak.vankad...@gmail.com


   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


Overlaying default grub.cfg makes qemu fat: partition inaccessible

2009-03-24 Thread 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

2009-03-24 Thread Pavel Roskin

Quoting James Collier james.collier...@gmail.com:


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

2009-03-24 Thread Bean
On Wed, Mar 25, 2009 at 5:41 AM, Felix Zielcke fziel...@z-51.de 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