Re: [PATCH] unused constants in i386/boot.h

[Yves Blusseau]

On Thu, Jul 09, 2009 at 10:45:43AM +0200, Yves Blusseau wrote:






style="font-family: -moz-fixed; font-size: 13px;" lang="x- 
western">Here's

the patch to remove unused constants.
The real constants used are GRUB_BOOT_MACHINE_KERNEL_ADDR and
GRUB_BOOT_MACHINE_KERNEL_SEG.


Hi,

As long as boot/i386/pc/boot.S has the variables whose offset these  
macros

are describing, I think it's fine to keep them.

Btw, please include a non-HTML version in your emails :-)

--
Robert Millan

 The DRM opt-in fallacy: "Your data belongs to us. We will decide  
when (and
 how) you may access your data; but nobody's threatening your  
freedom: we

 still allow you to remove your data and not access it at all."


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


Hi

boot/i386/pc/boot.S DON'T use this macros.

They're only defined in i386/boot.h but they are not used anywhere.  
The new name of this constants are GRUB_BOOT_MACHINE_KERNEL_ADDR and  
GRUB_BOOT_MACHINE_KERNEL_SEG.
So the GRUB_BOOT_MACHINE_KERNEL_ADDRESS and  
GRUB_BOOT_MACHINE_KERNEL_SEGMENT (see the difference with the  
constants below) constants can be definitively removed, and it's  
better to remove them to avoid confusion.


Yves Blusseau


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

Re: [PATCH] unused constants in i386/boot.h

[Pavel Roskin]

Quoting Yves Blusseau :


As long as boot/i386/pc/boot.S has the variables whose offset these macros
are describing, I think it's fine to keep them.


I'd rather not keep the macros that are not used outside boot.S.  They  
give a wrong impression that somebody somewhere needs to know that  
offset.


As for the macros that are used, we should always have assembler  
statements ensuring that the described field is indeed there.



boot/i386/pc/boot.S DON'T use this macros.

They're only defined in i386/boot.h but they are not used anywhere. The
new name of this constants are GRUB_BOOT_MACHINE_KERNEL_ADDR and
GRUB_BOOT_MACHINE_KERNEL_SEG.
So the GRUB_BOOT_MACHINE_KERNEL_ADDRESS and
GRUB_BOOT_MACHINE_KERNEL_SEGMENT (see the difference with the constants
below) constants can be definitively removed, and it's better to remove
them to avoid confusion.


I believe we should use every such removal to simplify the code.  We  
can now use direct jump instead of an indirect.  That would hopefully  
save us two bytes we need to implement fat32 support.


I think we should also remove the version from boot.S, as it's not  
being checked anywhere.


I realize that somebody might suggest adding such check, but I'd  
rather append those to bytes at the end of the bootsector.  The extra  
bytes would be checked and stripped by grub-setup, so that they don't  
take space in the actual bootsector.  Also, if we add such check, we  
need a very clear message in i386/boot.h requiring the version to be  
updated whenever any change to the offsets is made.  The version  
number should be a plain integer, perhaps 16-bit, without distinction  
between major and minor versions, so that nobody needs to think where  
their change calls for a major version increase.


--
Regards,
Pavel Roskin


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

Re: boot.img Fix

[Pavel Roskin]

Quoting Robert Millan :


I agree GRUB should be very careful not to destroy potentially valuable
data.  However, that's not to say FAT install is important.  Typically
our install doesn't collide or interfere with any filesystem, it's only
a few corner cases that do, and IMO we should try to discourage those.

But of course, destroying someone's filesystem is not the right way to
discourage something :-)


I think installing to the first (or any) sector of a filesystem not  
known specifically to allow that should at least require --force.


I'm fine with supporting fat32, I just want to use the opportunity to  
fix some related issues.


--
Regards,
Pavel Roskin


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

Re: Some ideas about new features of grub

[Pavel Roskin]

Quoting Bean :


IIRC, os-prober is a collection of shell script to detect os, but grub
already have them in util/grub.d. This method is based on linux, so
you need to enter linux in order to update the menu. On the other
hand, lua script generate the menu inside grub, there is no need to
enter any os.


I imagine most distros would want tight control over what appears in  
the menu.  Nobody would want their distro appear last in the list.  So  
osdetect.lua is a great thing, but it's not for everyone.



Another problem is the drive number. It's impossible to decide bios
drive number from inside linux, so we can't insert the correct
drivemap command required to boot DOS/Windows from secondary drive.
This information must be gathered at boot time.


It should be possible to find the partition using uuid or a unique  
file.  drivemap accepts partitions as arguments (it did last time I  
checked).


--
Regards,
Pavel Roskin


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

[PATCH] Support graphics output protocol in EFI

[Bean]

Hi,

MacBooks 5.x supports the new graphics output protocol in UEFI, while
the older UGA draw protocol doesn't work anymore. This patch add
support for graphics output protocol so that linux loader can get
video information correctly.

-- 
Bean
diff --git a/include/grub/efi/graphics_output.h b/include/grub/efi/graphics_output.h
new file mode 100644
index 000..a100c09
--- /dev/null
+++ b/include/grub/efi/graphics_output.h
@@ -0,0 +1,92 @@
+/* graphics_output.h - definitions of the graphics output protocol */
+/*
+ *  GRUB  --  GRand Unified Bootloader
+ *  Copyright (C) 2009  Free Software Foundation, Inc.
+ *
+ *  GRUB is free software: you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation, either version 3 of the License, or
+ *  (at your option) any later version.
+ *
+ *  GRUB is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with GRUB.  If not, see .
+ */
+
+#ifndef GRUB_EFI_GRAPHICS_OUTPUT_HEADER
+#define GRUB_EFI_GRAPHICS_OUTPUT_HEADER	1
+
+#include 
+
+#define GRUB_EFI_GRAPHICS_OUTPUT_GUID \
+  { 0x9042a9de, 0x23dc, 0x4a38, { 0x96, 0xfb, 0x7a, 0xde, 0xd0, 0x80, 0x51, 0x6a }}
+
+struct grub_efi_pixel_bitmask
+{
+  grub_uint32_t red_mask;
+  grub_uint32_t green_mask;
+  grub_uint32_t blue_mask;
+  grub_uint32_t reserved_mask;
+};
+
+enum grub_efi_graphics_pixel_format
+  {
+GRUB_EFI_PIXEL_RGB_RESERVED_8BIT_PER_COLOR,
+GRUB_EFI_PIXEL_BGR_RESERVED_8BIT_PER_COLOR,
+GRUB_EFI_PIXEL_BIT_MASK,
+GRUB_EFI_PIXEL_BLT_ONLY,
+GRUB_EFI_PIXEL_FORMAT_MAX
+  };
+
+struct grub_efi_graphics_output_mode_information
+{
+  grub_uint32_t version;
+  grub_uint32_t horizontal_resolution;
+  grub_uint32_t vertical_resolution;
+  enum grub_efi_graphics_pixel_format pixel_format;
+  struct grub_efi_pixel_bitmask pixel_information;
+  grub_uint32_t pixels_per_scan_line;
+};
+
+struct grub_efi_graphics_output_mode
+{
+  grub_uint32_t max_mode;
+  grub_uint32_t mode;
+  struct grub_efi_graphics_output_mode_information *info;
+  grub_efi_uintn_t size_of_info;
+  grub_efi_physical_address_t frame_buffer_base;
+  grub_efi_uintn_t frame_buffer_size;
+};
+
+struct grub_efi_graphics_output_protocol
+{
+  grub_efi_status_t
+  (*query_mode) (struct grub_efi_graphics_output_protocol *this,
+		 grub_uint32_t mode_number,
+		 grub_efi_uintn_t *size_of_info,
+		 struct grub_efi_graphics_output_mode_information **info);
+
+  grub_efi_status_t
+  (*set_mode) (struct grub_efi_graphics_output_protocol *this,
+	   grub_uint32_t mode_number);
+
+  grub_efi_status_t
+  (*blt) (struct grub_efi_uga_draw_protocol *this,
+	  struct grub_efi_uga_pixel *blt_buffer,
+	  enum grub_efi_uga_blt_operation blt_operation,
+	  grub_efi_uintn_t src_x,
+	  grub_efi_uintn_t src_y,
+	  grub_efi_uintn_t dest_x,
+	  grub_efi_uintn_t dest_y,
+	  grub_efi_uintn_t width,
+	  grub_efi_uintn_t height,
+	  grub_efi_uintn_t delta);
+
+  struct grub_efi_graphics_output_mode *mode;
+};
+
+#endif
diff --git a/loader/i386/efi/linux.c b/loader/i386/efi/linux.c
index f96c60e..8d3b555 100644
--- a/loader/i386/efi/linux.c
+++ b/loader/i386/efi/linux.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -425,7 +426,7 @@ grub_linux_unload (void)
 }
 
 static grub_efi_guid_t uga_draw_guid = GRUB_EFI_UGA_DRAW_GUID;
-
+static grub_efi_guid_t graphics_output_guid = GRUB_EFI_GRAPHICS_OUTPUT_GUID;
 
 #define RGB_MASK	0xff
 #define RGB_MAGIC	0x121314
@@ -539,32 +540,55 @@ find_framebuf (grub_uint32_t *fb_base, grub_uint32_t *line_len)
 static int
 grub_linux_setup_video (struct linux_kernel_params *params)
 {
-  grub_efi_uga_draw_protocol_t *c;
-  grub_uint32_t width, height, depth, rate, pixel, fb_base, line_len;
+  struct grub_efi_graphics_output_protocol *gop;
+  grub_uint32_t width, height, depth, fb_base, fb_size, line_len;
   int ret;
 
-  c = grub_efi_locate_protocol (&uga_draw_guid, 0);
-  if (! c)
-return 1;
+  gop = grub_efi_locate_protocol (&graphics_output_guid, 0);
+  if (gop)
+{
+  width = gop->mode->info->horizontal_resolution;
+  height = gop->mode->info->vertical_resolution;
+  depth = 32;
+  line_len = 4 * gop->mode->info->pixels_per_scan_line;
+  fb_base = gop->mode->frame_buffer_base;
+  fb_size = gop->mode->frame_buffer_size;
+}
+  else
+{
+  grub_efi_uga_draw_protocol_t *c;
+  grub_uint32_t rate, pixel;
+
+  c = grub_efi_locate_protocol (&uga_draw_guid, 0);
+  if (! c)
+	{
+	  grub_printf ("Can\'t locate uga protocol\n");
+	  return 1;
+	}
 
-  if (efi_call_5 (c->get_mode, c, &width, &height, &depth, &rate))
-return 1;
+  if (efi_call_5 (c->get_m

Are you going to Debconf9?

[adrian15 adrian15]

Hi,

I am adrian15 from Super Grub Disk. I have been quite for a while.
I was asking myself if some of you are going to Debconf.

I won't mind meeting some of you and learning about grub2 (I am a bit
outdated) and maybe try to code some lines.

Or just meet someone like _x86, marco_g or nyu face to face.

http://debconf9.debconf.org/index.xhtml.en

Debian Conference is the annual Debian developers meeting, an event
filled with coding parties, discussions and workshops - all of them
highly technical in nature. It will be held in Cáceres, Extremadura,
Spain, from July 23 to 30, 2009.

Thank you.

adrian15
-- 
Support free software. Donate to Super Grub Disk. Apoya el software
libre. Dona a Super Grub Disk.
http://www.supergrubdisk.org/index.php?pid=10


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

Grub2, ext3 boot/root on LVM on RAID 5

[Patrik Horník]

Hello,

should booting from ext3 boot/root filesystem installed on LVM volume
work with Grub2? LVM is created on top of couple of RAID 5 arrays.

I've tested today's version of Grub2 from Debian testing and also
revision 2404 from SVN and it did not work. Both grub-probe and grub
on boot stop with error "unknown filesystem". Module ext2 is included
in core.img and ls command in grub rescue lists also LVM volume on
which the boot files and root filesystem resides. grub-probe detects
ext2 on native partitions, so I guess problem is in combination ext2 +
LVM + RAID 5...

Thanks.

Best regards,

Patrik Horník


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

Re: Grub & accessibility

[Pavel Roskin]

Quoting Samuel Thibault :


(sorry phcoder for the duplication)

Robert Millan, le Fri 10 Jul 2009 19:22:48 +0200, a écrit :

We've made some exceptions, but in general, we'd like to keep the GRUB
codebase made entirely of FSF-copyrighted code, or at least code we
have disclaimers for.

OTOH, we don't want to discard valuable work that wasn't written   
specifically

for GRUB.  Perhaps Marco or Okuji will allow an exception for this case.


The thing is that it would be sad to re-implement these drivers, as
getting hardware to make sure they work is hard.


One of the main advantages of Free Software is that it allows code  
sharing.  For a GNU project to reject accessibility code solely  
because it's copyrighted by others would be a very bad move from the  
PR perspective.  I can easily imagine stories badmouthing FSF and  
GPLv3 over the issue.  Someone or something hurting disabled people is  
the kind of story journalists like.


It would still be legal for another entity to take the GRUB code and  
combine it with the accessibility code, but it would be an unnecessary  
fork.


--
Regards,
Pavel Roskin


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

Re: Grub2, ext3 boot/root on LVM on RAID 5

[Wojciech Pyczak]

It doesn't work for me either, however it's works with LVM on RAID0/1
(file system doesn't matter).


Dnia 2009-07-12, nie o godzinie 16:25 +0200, Patrik Horník pisze:
> Hello,
> 
> should booting from ext3 boot/root filesystem installed on LVM volume
> work with Grub2? LVM is created on top of couple of RAID 5 arrays.
> 
> I've tested today's version of Grub2 from Debian testing and also
> revision 2404 from SVN and it did not work. Both grub-probe and grub
> on boot stop with error "unknown filesystem". Module ext2 is included
> in core.img and ls command in grub rescue lists also LVM volume on
> which the boot files and root filesystem resides. grub-probe detects
> ext2 on native partitions, so I guess problem is in combination ext2 +
> LVM + RAID 5...
> 
> Thanks.
> 
> Best regards,
> 
> Patrik Horník
> 
> 
> ___
> 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