grub.efi x86_64 on Apple 64bit efi models - status of testing
I have got to a standstill with this, some major stoppers found and could
use some help to debug further. I hope someone can take a look at this
please, its getting beyond my limited C code reading and hacking
capabilities, but I do want to see grub.efi working on current Apple Intel
Macs.
Apple Linux/OSX users can benefit from grub.efi major advantages over the
Apple pc-bios emulation which cannot boot external drives and has other
installation problems for Linux users. Apple Mac users multi-booting
GNU/Linux and Mac OSX are a good testing ground for EFI booting. A number of
people in the ubuntuforums have tested grub.efi x86 and x86_64 on Apple
intel Macs from intel core2duo on. There have also been some recent reported
problems posted on grub-devel list.
I have not seen anything for IA32/64 machines.
From early 2008, Macs have been using 64bit EFI, needing x86_64 grub.efi,
and I have posted on ubuntuforums a full x86_64 grub.efi package with all
modules and grub.cfg for people to try.
No one has been able to get x86_64 grub.efi to boot and run either Mac OSX
(boot.efi) or ubuntu 810 2.6.27 kernels (configured for EFI). All this works
well for x86 grub.efi on Intel Macs with the earlier 32 bit firmware.
---
Three specific issues are stopping useful testing -
1. Mac models from imac8,1 early 2008 are unable to boot grub.efi 64bit when
4GB RAM is fitted.
Dropping to 2GB RAM enables grub.efi to boot and display grub.cfg menu
with fully functional command line. This leads to the next problems -
2. The grub.efi chainloader command fails to load
/usr/standalone/i386/boot.efi, reporting ' error: cannot load image '
3. grub.efi successfully loads ubuntu x86 2.6.7-7 kernel ( or earlier debian
2.6.26 ) using command line or menuentry, but the boot fails.
After boot command, the boot screen goes to black and no further progress
seen,
except in one case some garbled video indicating possible boot but failure
to init.
4. Finally, there was a problem getting ubuntu 810 amd64 to complete
initialization after booting in earlier 32 bit grub.efi tests, and other
issues with accelerated graphics and keyboard. - Not yet the issue here.
-
I got as far as locating the area in the grub2 code as shown in the attached
diffs of commented files, and will continue to look throught the code, or
can try any suggested debugging. I have some access to an Imac8,1 MacBook
Pro 4,1 and a MacBook2,1.
( So far using set debug=all or selective, grub_printf(); grub_getkey();
asm volatile (ret : : ); )
But I am not a programmer and need help to go further. The x86 32 bit
grub.efi functions very well on MacBook2,1 and other earlier 32 bit EFI
Apples, but the later models need the x86_64 build, and at present it is not
functional at all. The Apple firmware and EFI seems to need special
treatment.
-
Diffs - ( these are just grub2 rev 1972 commented 'pxwdebug' to show where I
got to )
Diff 1. Failing to run grub.efi with 4GB RAM.
grub2 r=1972
--- grub2a/kern/x86_64/efi/startup.S2009-02-04 17:04:14.0 +1100
+++ grub2b/kern/x86_64/efi/startup.S2009-02-09 18:19:32.0 +1100
@@ -57,10 +57,12 @@ VARIABLE(grub_prefix)
codestart:
movq%rcx, EXT_C(grub_efi_image_handle)
movq%rdx, EXT_C(grub_efi_system_table)
+/*pxwdebug - with 4GB RAM, startup hangs before the call */
+
callEXT_C(grub_main)
ret
-
Diff 2. Failure of efi chainloader for Mac OSX
grub2 r=1972
--- grub2a/loader/efi/chainloader.c2009-02-04 17:04:22.0 +1100
+++ grub2b/loader/efi/chainloader.c2009-02-09 17:50:35.0 +1100
@@ -253,21 +253,21 @@ grub_rescue_cmd_chainloader (int argc, c
if (grub_errno == GRUB_ERR_NONE)
grub_error (GRUB_ERR_BAD_OS, too small);
goto fail;
}
-
+/* pxwdebug macosx 10.4 10.5 fail to load with grub.efi x86_64 */
status = efi_call_6 (b-load_image, 0, grub_efi_image_handle, file_path,
(void *) ((grub_addr_t) address), size,
image_handle);
if (status != GRUB_EFI_SUCCESS)
{
if (status == GRUB_EFI_OUT_OF_RESOURCES)
grub_error (GRUB_ERR_OUT_OF_MEMORY, out of resources);
else
grub_error (GRUB_ERR_BAD_OS, cannot load image);
-
+/*pxwdebug error message is cannot load image */
goto fail;
}
---
Diff 3. efi Linux boot fails.
grub2 r=1972
--- grub2a/loader/i386/efi/linux.c2009-02-04 17:04:22.0 +1100
+++ grub2b/loader/i386/efi/linux.c2009-02-09 18:09:22.0 +1100
@@ -419,19 +419,19 @@ grub_linux_boot (void)
asm volatile (cli : : );
/* Load the IDT and the GDT for the bootstrap. */
asm volatile (lidt %0 : : m (idt_desc));
asm volatile (lgdt %0 : : m (gdt_desc));
-
+/*pxwdebug x86_64 linux boot fails */
#ifdef __x86_64__
jumpvector.kernel_entry = (grub_uint64_t) grub_linux_real_boot;
jumpvector.kernel_cs =
Re: grub.efi x86_64 on Apple 64bit efi models - status of testing
--- Three specific issues are stopping useful testing - 1. Mac models from imac8,1 early 2008 are unable to boot grub.efi 64bit when 4GB RAM is fitted. Dropping to 2GB RAM enables grub.efi to boot and display grub.cfg menu with fully functional command line. This leads to the next problems - 2. The grub.efi chainloader command fails to load /usr/standalone/i386/boot.efi, reporting ' error: cannot load image ' 3. grub.efi successfully loads ubuntu x86 2.6.7-7 kernel ( or earlier debian 2.6.26 ) using command line or menuentry, but the boot fails. After boot command, the boot screen goes to black and no further progress seen, except in one case some garbled video indicating possible boot but failure to init. As I pointed out on the forums, the farthest I got with one kernel was for it to show either a shell (with init=/bin/sh) or the debian lenny install screen. All PCI and usb devices seemed to not work at all though, so doesn't 4. Finally, there was a problem getting ubuntu 810 amd64 to complete initialization after booting in earlier 32 bit grub.efi tests, and other issues with accelerated graphics and keyboard. - Not yet the issue here. The accelerated graphics from what I understand are a general issue with EFI booting, not much grub can do about it for now. If I understand it correctly, either grub would have to play a bigger part in video initilization, or more likely, the accelerated graphics drivers would have to be rewritten, not very likely I think. Keyboard and usb in general is already an issue. For example the keyboard in the air, and probably in all macs is connected through usb, which so far seems to mean it for example does not work with a new module calle at_keyboard which should support keymaps and other nice stuff in the future. Before that we had a patch that solved a loss of keyboard input after about 2 mins, for the normal keyboard support. I assume the earlier one worked cause it relied more on callbacks to the EFI subsystem to make the usb. Maybe this sums it up a bit. Of course, if any of the devs feel like I misrepresented some facts, feel free to correct. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [Bugfix] Hang on new mac laptops
On Mon, Feb 09, 2009 at 02:46:01AM +0100, step21 wrote: Ok, confirmed that keyboard is attached with usb. lsusb wans't very helpful cause apart from wireless and bluetooth it only mentioned apple devices and linux foundation devices however os x has a similiar command line tool ioreg which with -p IOUSB can be restricted to usb. Output http://pastebin.com/m4d3e9c83 I then updated to the usb patch with rev 1985, and compiled etc. debug still seemed to do nothing and as previously terminal_input at_keyboard forces to manually swithc the machine off. Use the following: insmod uhci ; insmod usb_keyboard ; terminal_input usb_keyboard It is important to use semicolons, since after insmod uhci your keyboard will stop working (and hopefully be restored with terminal_input usb_keyboard) -- 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
Re: [PATCH] try to avoid false positives on FAT filesystem
On Sun, Feb 08, 2009 at 08:59:58PM +0100, Felix Zielcke wrote: Am Sonntag, den 08.02.2009, 20:56 +0100 schrieb Robert Millan: I reviewed this thread and couldn't find it. Did you send it elsewhere? In my first message where you quoted the changelog entry. Well again attached. Sorry, I must have lost it. 2009-02-05 Felix Zielcke fziel...@z-51.de fs/fat.c (grub_fat_mount): Try to avoid false positives by checking bpb.version_specific.fat12_or_fat16.fstype and bpb.version_specific.fat32.fstype. Index: fs/fat.c === --- fs/fat.c (revision 1973) +++ fs/fat.c (working copy) @@ -187,6 +187,11 @@ grub_fat_mount (grub_disk_t disk) if (grub_disk_read (disk, 0, 0, sizeof (bpb), (char *) bpb)) goto fail; + if (! grub_strncmp((const char *)bpb.version_specific.fat12_or_fat16.fstype,FAT12,5) + || ! grub_strncmp((const char *)bpb.version_specific.fat12_or_fat16.fstype,FAT16,5) + || ! grub_strncmp((const char *)bpb.version_specific.fat32.fstype,FAT32,5)) +goto fail; + /* Get the sizes of logical sectors and clusters. */ data-logical_sector_bits = fat_log2 (grub_le_to_cpu16 (bpb.bytes_per_sector)); Looks good to me. But please add spaces between ')' and 'b', and after ','. -- 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
Re: [PATCH] USB keyboard
On Sun, Feb 08, 2009 at 09:04:56PM +0100, step21 wrote: didn't this work already? or was this only cause of efi? just while testing the input issue on my mac i attached a usb keyboard too, and that worked. When the firmware (BIOS/EFI/OFW) supports USB and GRUB uses its callbacks, then USB keyboards can work. Using the driver helps when the firmware doesn't support USB, or when its USB support is broken in some way. -- 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
Re: [PATCH] Faster text rendering by optimizing font glyph lookup
On Sun, Feb 08, 2009 at 01:49:53PM -0800, Colin D Bennett wrote: This patch greatly—*tremendously*, even, if higher-numbered Unicode characters are used—speeds up retrieving a glyph for a particular Unicode character. This makes text rendering in general much faster. My text benchmark shows the new text rendering speed is somewhere from 2.6x to 31x of the previous speed. Basically, PFF2 font files are now required to have the character index ordered in ascending order of code point. Fonts created by 'grub-mkfont' already satisfy this requirement. Fonts created by my old Java 'fonttool' do not, and cannot be used any longer. The font loader verifies that fonts fulfill the character ordering requirement, refusing to load invalid fonts, but the primary change is in the 'find_glyph()' function, which now uses a binary search rather than a linear search to find the glyph. Very nice! With this patch, how does retrieving glyphs from the complete unicode font compare to retrieving glyphs (without the patch) from the ascii ascii one? Can we make unicode font the default now? -- 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
Re: [PATCH] try to avoid false positives on FAT filesystem
Am Montag, den 09.02.2009, 15:07 +0100 schrieb Robert Millan: Looks good to me. But please add spaces between ')' and 'b', and after ','. Ok commited. -- Felix Zielcke ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: hfs patch (Re: State of GRUB on PowerPC)
On Sat, Feb 07, 2009 at 11:38:36PM -0500, Pavel Roskin wrote:
Quoting Robert Millan r...@aybabtu.com:
On Tue, Jan 27, 2009 at 08:19:41AM +0100, Michel Dänzer wrote:
+/*
+ * unsigned char caseorder[]
+ *
+ * Defines the lexical ordering of characters on the Macintosh
+ *
+ * Composition of the 'casefold' and 'order' tables from ARDI's code
+ * with the entry for 0x20 changed to match that for 0xCA to remove
+ * special case for those two characters.
+ */
+static unsigned char caseorder[256] = {
+
0x00,0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x0A,0x0B,0x0C,0x0D,0x0E,0x0F,
Could you be more specific about what the table contents mean?
Michel may know better, but I think it's the order of characters.
Those with the lower order go first in the sorted binary tree. Those
with the same order are equivalent on the filesystem level. That is,
foo can only be between bar and quux in the node tree. foo
and Foo are the same tree node and thus the same file.
I think what we need here is enough information so that someone can understand
what the table means and be able to modify it if need arised. An undocumented
table just looks like a blob of binary data.
--
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
Re: grub.efi x86_64 on Apple 64bit efi models - status of testing
Mmm, I was under the impression I should test at_keyboard. However now this doesn't seem to make much sense. So usb_keyboard is not loaded automatically or is it? On Mon, Feb 9, 2009 at 3:12 PM, Robert Millan r...@aybabtu.com wrote: On Mon, Feb 09, 2009 at 01:38:49PM +0100, step21 wrote: Keyboard and usb in general is already an issue. For example the keyboard in the air, and probably in all macs is connected through usb, which so far seems to mean it for example does not work with a new module calle at_keyboard which should support keymaps and other nice stuff in the future. Note at_keyboard is for PC/AT keyboards. But what you said applies to usb_keyboard too. -- 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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: gettext patch (beta)
Hi Carles
On Sat, Jan 24, 2009 at 03:26:04PM +0100, Carles Pina i Estany wrote:
Index: Makefile.in
===
--- Makefile.in (revision 1954)
+++ Makefile.in (working copy)
@@ -112,6 +112,7 @@
PKGDATA = $(pkgdata_DATA) $(pkgdata_SRCDIR)
PROGRAMS = $(bin_UTILITIES) $(sbin_UTILITIES)
SCRIPTS = $(bin_SCRIPTS) $(sbin_SCRIPTS) $(grub-mkconfig_SCRIPTS)
+GRUBD = $(srcdir)/util/grub.d
If you're adding GRUBD, perhaps you can use it in other places that currently
hardcode util/grub.d.
+Content-Type: text/plain; charset=CHARSET\n
That should be charset=utf-8
+ Presioneu retorn per arrancar el SO seleccionat, 'e' editar\n
l'SO ;-)
+ les comandes abans d'arrancar, 'c' per línia d'ordres.
The 'í' should be in utf-8 (it displays in utf-8 here because
your mailer set Content-Type to iso-8859-1).
+#: util/grub.d/10_linux.in:148
+#, sh-format
+msgid ${OS}, linux ${version} (single-user mode)
+msgstr ${OS}, linux ${version} (mode mono-usuari)
I wonder if we should replace the original string single-user mode with
something else. Novice users find it confusing, since they may assume
single-user mode is the normal mode for them (a single user) to use
the computer.
+ grub_free(current_string);
+ min=current;
[...]
+current = (max+min)/2;
Remember to add spaces in such places.
+ if (magic != 0x950412de)
This should be a macro. Also, it probably needs endian conversion (use the
macros in types.h).
+ /* Testing:
+ grub_register_command (_, grub_cmd_translate, GRUB_COMMAND_FLAG_BOTH,
+ _, internalization support trans, 0);
+ */
We could register the gettext command and leave it there by default.
+else
+ echo gettext module is not available
+fi
This should have 2, or it might end up as part of grub.cfg. Also it
could be more descriptive (like, letting user know text output will be in
English).
--
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
Re: [PATCH] try to avoid false positives on FAT filesystem
On Sun, Feb 08, 2009 at 10:03:43AM +0100, Felix Zielcke wrote: 2009-02-08 Felix Zielcke fziel...@z-51.de * conf/common.rmk (grub_probe_SOURCES): Move fs/ext2.c before fs/fat.c to avoid false posivites with FAT. (grub_fstest_SOURCES): Likewise. * conf/i386-pc.rmk (grub_emu_SOURCES): Likewise. * conf/x86_64-efi.rmk (grub_emu_SOURCES): Likewise. * conf/powerpc-ieee1275.rmk (grub_emu_SOURCES): Likewise. * conf/i386-coreboot.rmk (grub_emu_SOURCES): Likewise. * conf/sparc64-ieee1275.rmk (grub_emu_SOURCES): Likewise. * conf/i386-ieee1275.rmk (grub_emu_SOURCES): Likewise. Index: conf/common.rmk === --- conf/common.rmk (revision 1980) +++ conf/common.rmk (working copy) @@ -14,7 +14,7 @@ grub_probe_SOURCES = util/grub-probe.c \ kern/device.c kern/disk.c kern/err.c kern/misc.c\ kern/parser.c kern/partition.c kern/file.c \ \ - fs/affs.c fs/cpio.c fs/ext2.c fs/fat.c fs/hfs.c \ + fs/affs.c fs/cpio.c fs/fat.c fs/ext2.c fs/hfs.c \ fs/hfsplus.c fs/iso9660.c fs/udf.c fs/jfs.c fs/minix.c \ fs/ntfs.c fs/ntfscomp.c fs/reiserfs.c fs/sfs.c \ fs/ufs.c fs/xfs.c fs/afs.c fs/tar.c \ After your other commit, is this one still needed/useful? -- 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
Re: grub.efi x86_64 on Apple 64bit efi models - status of testing
On Mon, Feb 09, 2009 at 03:26:25PM +0100, step21 wrote: Mmm, I was under the impression I should test at_keyboard. That'd be because I told you to test at_keyboard ;-) But I was wrong, as Vesa pointed out the keyboard on Mac hardware is wired to the USB controller. So usb_keyboard is not loaded automatically or is it? No. First we need it to be complete / stable and add support for EHCI (btw, anyone feels like writing an EHCI driver?). -- 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
Re: [PATCH] try to avoid false positives on FAT filesystem
Am Montag, den 09.02.2009, 15:40 +0100 schrieb Robert Millan: After your other commit, is this one still needed/useful? Well my other commit just fixes the problem probable for these Dell utiliti FAT partitions because they don't have a valid FAT16 string. It could be still useful for the people who have a broken mkfs.ext2 which doestn't zero out the first 512 bytes of the partition, but did had a real valid FAT partition. And I think it shouldn't hurt to check first for ext2 and then FAT. -- Felix Zielcke ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub.efi x86_64 on Apple 64bit efi models - status of testing
2009/2/9 Robert Millan r...@aybabtu.com: On Mon, Feb 09, 2009 at 03:26:25PM +0100, step21 wrote: Mmm, I was under the impression I should test at_keyboard. That'd be because I told you to test at_keyboard ;-) But I was wrong, as Vesa pointed out the keyboard on Mac hardware is wired to the USB controller. So usb_keyboard is not loaded automatically or is it? No. First we need it to be complete / stable and add support for EHCI (btw, anyone feels like writing an EHCI driver?). Is EHCi driver needed for keyboard support? I was under the impression that keyboards always appear connected to the low-full speed root hub, not the hihg-speed one. Thanks Michal ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub.efi x86_64 on Apple 64bit efi models - status of testing
O.k. I now found the semi-colon on the keyboard (it was indeed the ö key) However now it seems no uhci modules was built. I updated to svn rev 1985 from trunk, what I could see from the list and the web svn view I thought the usb patch was merged there already? Or do I have to pass a flag or something so it gets built? On Mon, Feb 9, 2009 at 3:43 PM, Robert Millan r...@aybabtu.com wrote: On Mon, Feb 09, 2009 at 03:26:25PM +0100, step21 wrote: Mmm, I was under the impression I should test at_keyboard. That'd be because I told you to test at_keyboard ;-) But I was wrong, as Vesa pointed out the keyboard on Mac hardware is wired to the USB controller. So usb_keyboard is not loaded automatically or is it? No. First we need it to be complete / stable and add support for EHCI (btw, anyone feels like writing an EHCI driver?). -- 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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: cat with pagination
On Sunday 08 February 2009 06:33:46 Robert Millan wrote: On Sat, Jan 24, 2009 at 12:29:24PM -0800, Colin D Bennett wrote: There has been also a talk to enable pager=1 as a default. Which, as I recall, Okuji rejected because it could cause a unattended/non-interactive boot process to hang unexpectedly if too much output was produced for some reason. Perhaps the pager could default to being enabled whenever an interactive command line is in use, but default to disabled when the invoking command is not being executed from an interactive command line. This would be the most logical solution IMO. Better CC him. I don't always want to use a pager even from a command line. If GRUB sets pager=1 forcibly, I dislike it. I prefer that computers behave as I like, to that I behave as computers like. BTW, I don't like pager at all personally. For me, this is a hack only for working around that GRUB has no support for pipes. Regards, Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Bugfix: directories: not reported as such on case-insensitive fs
Bugfix. Patch attached
Vladimir 'phcoder' Serbinenko
Index: fs/hfsplus.c
===
--- fs/hfsplus.c (revision 1985)
+++ fs/hfsplus.c (working copy)
@@ -899,8 +899,8 @@
grub_fshelp_node_t node)
{
grub_free (node);
-
- if (filetype == GRUB_FSHELP_DIR)
+
+ if ((filetype GRUB_FSHELP_TYPE_MASK) == GRUB_FSHELP_DIR)
return hook (filename, 1);
else
return hook (filename, 0);
Index: ChangeLog
===
--- ChangeLog (revision 1985)
+++ ChangeLog (working copy)
@@ -1,0 +1,8 @@
+2009-02-09 Vladimir Serbinenko phco...@gmail.com
+
+ Bugfix: directories not reported as such on case-insensitive hfs+
+
+ * include/grub/fshelp.h: included definition of GRUB_FSHELP_TYPE_MASK
+ and GRUB_FSHELP_FLAGS_MASK
+ * fs/hfsplus.c (grub_hfsplus_dir): ignore filetype flags
+
Index: include/grub/fshelp.h
===
--- include/grub/fshelp.h (revision 1985)
+++ include/grub/fshelp.h (working copy)
@@ -27,6 +27,8 @@
typedef struct grub_fshelp_node *grub_fshelp_node_t;
#define GRUB_FSHELP_CASE_INSENSITIVE 0x100
+#define GRUB_FSHELP_TYPE_MASK 0xff
+#define GRUB_FSHELP_FLAGS_MASK 0x100
enum grub_fshelp_filetype
{
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Faster text rendering by optimizing font glyph lookup
On Mon, 9 Feb 2009 15:11:16 +0100 Robert Millan r...@aybabtu.com wrote: On Sun, Feb 08, 2009 at 01:49:53PM -0800, Colin D Bennett wrote: This patch greatly—*tremendously*, even, if higher-numbered Unicode characters are used—speeds up retrieving a glyph for a particular Unicode character. This makes text rendering in general much faster. My text benchmark shows the new text rendering speed is somewhere from 2.6x to 31x of the previous speed. Basically, PFF2 font files are now required to have the character index ordered in ascending order of code point. Fonts created by 'grub-mkfont' already satisfy this requirement. Fonts created by my old Java 'fonttool' do not, and cannot be used any longer. The font loader verifies that fonts fulfill the character ordering requirement, refusing to load invalid fonts, but the primary change is in the 'find_glyph()' function, which now uses a binary search rather than a linear search to find the glyph. Very nice! With this patch, how does retrieving glyphs from the complete unicode font compare to retrieving glyphs (without the patch) from the ascii ascii one? Here is the result of my benchmark with two kinds of text: (1) 104 characters of ASCII English text, and (2) 104 Unicode characters randomly selected from the characters in unifont, uniformly distributed over all 61050 characters in the font. Also, I ran the tests with both the 'ascii.pf2' and 'unicode.pf2' font files generated by GRUB's Makefile. Here are the results: '' 9 February 2009 videotest bench, text rendering benchmark 640x480 resolution ASCII Text Unicode Text Algorithm Unifont used (Chars/s) (Chars/s) --- - -- Linear search ASCII Font 255113 12098 [1] Linear search Unicode Font250874 23068 [2] Binary search ASCII Font 255746 96231 [1] Binary search Unicode Font255113 194741 [2] [1] Note that using the ASCII font for Unicode text results in a performance hit because the grub_font_draw_string() function will use font fallback to search for the missing glyphs in another font. I had other fonts loaded while running the benchmark, so GRUB had to scan them for the missing characters. [2] These numbers, for full Unicode text with the full unifont, show the improvement in worst-case performance when using the binary search versus linear search. '' Note that most of the time is now spent actually rendering the bitmaps on screen (instead of retrieving glyphs from the font), which actually takes longer for the Unicode text because many of the glyphs are wider than the English ASCII characters. (BTW, is there any way to run GRUB in a profiler? I'd like to know where the graphics performance bottlenecks are.) Can we make unicode font the default now? I think so. Using the full Unicode font does not seem to have a significant effect on rendering speed now. I will commit the patch if it looks OK to you. Regards, Colin signature.asc Description: PGP signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] try to avoid false positives on FAT filesystem
On Mon, Feb 09, 2009 at 03:49:46PM +0100, Felix Zielcke wrote: Am Montag, den 09.02.2009, 15:40 +0100 schrieb Robert Millan: After your other commit, is this one still needed/useful? Well my other commit just fixes the problem probable for these Dell utiliti FAT partitions because they don't have a valid FAT16 string. It could be still useful for the people who have a broken mkfs.ext2 which doestn't zero out the first 512 bytes of the partition, but did had a real valid FAT partition. And I think it shouldn't hurt to check first for ext2 and then FAT. No objection from me. -- 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
Re: grub.efi x86_64 on Apple 64bit efi models - status of testing
On Mon, Feb 09, 2009 at 03:56:42PM +0100, Michal Suchanek wrote: So usb_keyboard is not loaded automatically or is it? No. First we need it to be complete / stable and add support for EHCI (btw, anyone feels like writing an EHCI driver?). Is EHCi driver needed for keyboard support? I was under the impression that keyboards always appear connected to the low-full speed root hub, not the hihg-speed one. This would change things. Can someone confirm? -- 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
Re: [PATCH] USB keyboard
O.k., finally got everything patched and booted from it. What I did: Just to be sure set root with root=(hd0,2) then set debug=usbkeyb or usb_keyboard (tried both) then insmod uhci;insmod usb_keyboard; terminal_input usb_keyboard I get no new promp and it hangs. To get debug output, do I have to include a #define DEBUG_USB_KEYBOARD or something in the src too in addition to debug=usbkeyb ? On Mon, Feb 9, 2009 at 3:27 PM, step21 f...@terrorpop.de wrote: Thanks for clarifying this. On Mon, Feb 9, 2009 at 3:09 PM, Robert Millan r...@aybabtu.com wrote: On Sun, Feb 08, 2009 at 09:04:56PM +0100, step21 wrote: didn't this work already? or was this only cause of efi? just while testing the input issue on my mac i attached a usb keyboard too, and that worked. When the firmware (BIOS/EFI/OFW) supports USB and GRUB uses its callbacks, then USB keyboards can work. Using the driver helps when the firmware doesn't support USB, or when its USB support is broken in some way. -- 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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] try to avoid false positives on FAT filesystem
Am Montag, den 09.02.2009, 18:06 +0100 schrieb Robert Millan: No objection from me. Ok commited. -- Felix Zielcke ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] hdparm.mod - get/set ATA disk parameters
Robert Millan wrote: On Sun, Feb 08, 2009 at 12:12:32AM +0100, Christian Franke wrote: Robert Millan wrote: I would suggest to move grub_ata_pass_through() to a new module (e.g. ata2.mod, atax.mod, ataex.mod, ...) How about ata_something.mod? (consistent with ntfs.mod ntfs_comp.mod) It is actually ntfscomp.mod. ata_pthru.mod ? Deal! I will prepare a patch - ata_pthru.mod, atapthru.mod or a more generic name to allow to add other ata_extension functions ? Christian ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: fseeko in Grub2
Hello, On Feb/07/2009, Robert Millan wrote: On Wed, Jan 14, 2009 at 12:03:38AM +0100, Carles Pina i Estany wrote: I would like to use io/bufio.c to read the .mo file, so I would use grub_bufio_open to open, and grub_bufio_read to read. [...] Someone used to program io/bufio.c or something else wants to take a look? Sorry, I'm not familiar with that part of the code, and it looks like nobody else picked it up. If you still need fseeko (btw please don't name it fseek), would you be willing to implement it? by the moment, I'm not using grub_bufio_read but grub_read (not using buffered I/O). If after some time we need it (to speed up), I will reconsider moving to buffer I/O and implement grub_bufio_fseeko -- Carles Pina i EstanyGPG id: 0x17756391 http://pinux.info ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Grub 2 command : uppermem (patch proposal)
Hi, (Somehow I lost some of my emails, so copy pasting for reference.) Robert, please have a look at http://savannah.gnu.org/bugs/?18471 for the related bug report on grub-legacy. This description is wrt grub-legacy and I will soon follow up with my observations with grub2. In short, the systems have a memory hole somewhere at the beginning of the map, and the main problem is due to the fact that grub(legacy) does not find a contiguous memory region. So, if we have a large initrd or if we try to load a multiboot module (as in XEN), grub will bail out with error 28. With load_initrd(), we came up with a way to get away with the initial read of the initrd (please see patch attached with the above bug) and place it where the Linux kernel expects it to be. But with load_module(), it appeared there was no easy way out. So, we used uppermem to fool grub and place the multiboot module somewhere around 15M beyond the uppermem limit set by us. This took care of the problem temporarily. I hadn't had a chance to try Grub2 on these machines, a first glance at grub_multiboot() and related functions tells me that things are significantly different from the way load_module() used to work. I will soon try out grub2 on these machines and come up with my observations. Thanks, Bandan On Tue, Jan 27, 2009 at 08:30:32PM -0500, Bandan Das wrote: Hello List, I was going through the Grub 2 TODO here : http://grub.enbug.org/TodoList and I see that one of the many commands that need to be implemented is uppermem. The text in that list was a bit confusing. We don't have to implement _all_ missing commands, only those we find useful. Having played around with uppermem quite a bit (thanks to the weird systems I have to work with) on Grub Legacy, I was wondering if a patch for the same would be considered for inclusion? Please note that I haven't started work on it yet. I wanted to make sure that it's something desirable before putting up a patch. Could you describe your problem in more detail, so we can discuss if it's something that makes uppermem worthy or we'd rather solve it in some other way? We don't want to leave your use case out in the cold, only to see if it can be supported in a better way. -- Robert Millan ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub.efi x86_64 on Apple 64bit efi models - status of testing
Le 9 févr. 09 à 18:07, Robert Millan a écrit : On Mon, Feb 09, 2009 at 03:56:42PM +0100, Michal Suchanek wrote: So usb_keyboard is not loaded automatically or is it? No. First we need it to be complete / stable and add support for EHCI (btw, anyone feels like writing an EHCI driver?). Is EHCi driver needed for keyboard support? I was under the impression that keyboards always appear connected to the low-full speed root hub, not the hihg-speed one. This would change things. Can someone confirm? Using system-profiler, it show me that the webcam is connected on a High speed usb bus, and not the keyboard : USB Bus: Host Controller Location: Built In USB Host Controller Driver: AppleUSBUHCI PCI Device ID: 0x27c8 PCI Revision ID: 0x0002 PCI Vendor ID: 0x8086 Bus Number: 0x1d Apple Internal Keyboard / Trackpad: Product ID: 0x021b Vendor ID: 0x05ac (Apple Inc.) Version: 0.18 Speed: Up to 12 Mb/sec Manufacturer: Apple Computer Location ID: 0x1d20 Current Available (mA): 500 Current Required (mA): 40 this make sense, as a high speed bus is not really needed for a keyboard, I guess. -- Michael Scherer ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] r1986 broke FAT detection
At r1985, sudo ./grub-probe -t fs -d /dev/fd0 outputs fat with a freshly-formatted VFAT floppy in the drive. At r1986, it spits error: unknown filesystem. The cause is this error, repeated three times: if (! grub_strncmp(something, FAT12, 5)) goto fail; Strncmp does not return a boolean result (i.e. matches or doesn't), but an _integer_ that is supposed to establish a comparison order between strings. Thus, a return value of 0 is actually a match. See why I insist on treating semantic-ints different than semantic-bools even though the language does not? The correction is obvious (a patch is attached): if (0 != grub_strncmp(something, FAT12,5)) goto fail; And I remark the 0 != instead of a simple if (strncmp()) test. BTW, I think the FATx constants should be made into macros or SLT... Magic constants creep me out. -- Lazy Oblivious, Rational Disaster -- Habbit Index: fs/fat.c === --- fs/fat.c (revision 1987) +++ fs/fat.c (working copy) @@ -187,9 +187,9 @@ if (grub_disk_read (disk, 0, 0, sizeof (bpb), (char *) bpb)) goto fail; - if (! grub_strncmp((const char *) bpb.version_specific.fat12_or_fat16.fstype, FAT12,5) - || ! grub_strncmp((const char *) bpb.version_specific.fat12_or_fat16.fstype, FAT16,5) - || ! grub_strncmp((const char *) bpb.version_specific.fat32.fstype, FAT32,5)) + if (0 != grub_strncmp((const char *) bpb.version_specific.fat12_or_fat16.fstype, FAT12, 5) + 0 != grub_strncmp((const char *) bpb.version_specific.fat12_or_fat16.fstype, FAT16, 5) + 0 != grub_strncmp((const char *) bpb.version_specific.fat32.fstype, FAT32, 5)) goto fail; /* Get the sizes of logical sectors and clusters. */ signature.asc Description: Esta parte del mensaje está firmada digitalmente ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: gettext patch (beta)
Robert Millan wrote:
+#: util/grub.d/10_linux.in:148
+#, sh-format
+msgid ${OS}, linux ${version} (single-user mode)
+msgstr ${OS}, linux ${version} (mode mono-usuari)
I wonder if we should replace the original string single-user mode with
something else. Novice users find it confusing, since they may assume
single-user mode is the normal mode for them (a single user) to use
the computer.
===
Thanks for mentioning this Robert, as I could see it being somewhat
confusing to new users of Grub2 without some research. I've written a
piece in the Zenwalk WIKI to explain the use and reason it's added in a
basic grub.cfg. It may indeed be a good idea though to change it to
something more descriptive of what function it performs and that is to
only boot to runlevel 1 of the system. I think that's right, isn't it?
Regards,
Pat
--
---Zenwalk v6.0--Linux 2.6.28---
Registered Linux User #225206
Ever tried Zen computing? http://www.zenwalk.org
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub.efi x86_64 on Apple 64bit efi models - status of testing
Tonight did some debugging on loading uhci / usb_keyboard. For starters: it is confirmed that it is uhci where everything fails so far as insmod uhci; echo 1; insmod usb_keyboard; echo 2; terminal_input usb_keyboard; echo 3 (as suggested by nyu on irc I think) did not produce a single echo output. I inserted some debug statements which so far led me to bus/usb/usbhub.c Output. bus/usb/uhci.c:661: at uhci init bus/usb/uhci.c:663: at inithw bus/usb/usb.c:36:device=uhci bus/usb/usbhub.c:152:ports=2 bus/usb/usbhub.c:156:determined speed bus/usb/usbhub.c:160:assigned device These debug statements were all added by me iirc. To see what I added: http://paste.debian.net/28056/ (usbhub.c) http://paste.debian.net/28058/ (usb.c) btw, did anyone notice that in usbhub.c it says usb.c in the header? confused me for a moment. As far as I can tell so far it fails to enable the port with err = controller-dev-portstatus (controller, i, 1); Why that fails I have no idea though, but I will try to continue with it tomorrow. Best regards, step21 On Mon, Feb 9, 2009 at 6:07 PM, Robert Millan r...@aybabtu.com wrote: On Mon, Feb 09, 2009 at 03:56:42PM +0100, Michal Suchanek wrote: So usb_keyboard is not loaded automatically or is it? No. First we need it to be complete / stable and add support for EHCI (btw, anyone feels like writing an EHCI driver?). Is EHCi driver needed for keyboard support? I was under the impression that keyboards always appear connected to the low-full speed root hub, not the hihg-speed one. This would change things. Can someone confirm? -- 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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [Bugfix] Characters disappearing in gfxterm
Vesa Jääskeläinen wrote: phcoder wrote: Hello. I've run into the bug that when editing menu entry in gfxterm characters disappear after cursor moves away from its position. Here is bugfix I don't think this is a clean fix: Index: term/gfxterm.c === --- term/gfxterm.c (revision 1974) +++ term/gfxterm.c (working copy) @@ -744,6 +744,8 @@ /* Render cursor to text layer. */ grub_video_set_active_render_target (text_layer); grub_video_fill_rect (color, x, y, width, height); + if (! show) +write_char (); grub_video_set_active_render_target (GRUB_VIDEO_RENDER_TARGET_DISPLAY); /* Mark cursor to be redrawn. */ It is not designed to work in there. I think modifying this needs logical level approach and not ad hoc fix. ___ Has this fix been committed yet or is there further work to be done to clean it up before applying it? Pat ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
