Re: [solved] Re: USB device not seen by grub
Chris Jones wrote:
> On Thu, Dec 03, 2009 at 05:52:37PM EST, Vladimir 'φ-coder/phcoder' Serbinenko
> wrote:
>
> [..]
>
>
>> This is just module loading. I guess your terminal is slow which causes
>> an enormous slowback when loading module. You can using
>>
>
>
>> debug=usb,uhci,ohci
>> instead of
>> debug=all
>>
>
> I was able to boot the partition I had copied over to the USB stick after
> this:
>
> grub:> debug=uhci,ohci,usbms
> grub:> insmod uhci
> grub:> insmod usbms
> grub:> debug=
>
> Why do I have to enable tracing to make it work?
>
>
Because a dprintf acted as a forgotten millisleep. This patch should fix
it. On my machine I still have issues because uhci.c has problems with
second port
> Also, is there any way I can run the grub command line on a system
> that's already booted, so I can explore its possibities in a context
> where I have internet access, browse documentation, etc..?
>
>
I'm working on it but the current problem is that I haven't found a
syscall in linux to get physical address of a page. Does anyone has a
suggestion?
> Thanks,
>
> CJ
>
>
>
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
=== modified file 'bus/usb/uhci.c'
--- bus/usb/uhci.c 2009-10-14 08:11:59 +
+++ bus/usb/uhci.c 2009-12-05 09:13:21 +
@@ -23,7 +23,6 @@
#include
#include
#include
-#include
#include
#include
@@ -435,6 +434,7 @@
grub_uhci_td_t td_prev = NULL;
grub_usb_err_t err = GRUB_USB_ERR_NONE;
int i;
+ grub_uint64_t endtime;
/* Allocate a queue head for the transfer queue. */
qh = grub_alloc_qh (u, GRUB_USB_TRANSACTION_TYPE_CONTROL);
@@ -483,6 +483,7 @@
/* Wait until either the transaction completed or an error
occurred. */
+ endtime = grub_get_time_ms () + 1000;
for (;;)
{
grub_uhci_td_t errtd;
@@ -534,6 +535,13 @@
updated. */
grub_dprintf ("uhci", "transaction fallthrough\n");
}
+ if (grub_get_time_ms () > endtime)
+ {
+ err = GRUB_USB_ERR_STALL;
+ grub_dprintf ("uhci", "transaction timed out\n");
+ goto fail;
+ }
+ grub_cpu_idle ();
}
grub_dprintf ("uhci", "transaction complete\n");
@@ -573,6 +581,7 @@
struct grub_uhci *u = (struct grub_uhci *) dev->data;
int reg;
unsigned int status;
+ grub_uint64_t endtime;
grub_dprintf ("uhci", "enable=%d port=%d\n", enable, port);
@@ -595,6 +604,7 @@
status = grub_uhci_readreg16 (u, reg);
grub_uhci_writereg16 (u, reg, status & ~(1 << 9));
grub_dprintf ("uhci", "reset completed\n");
+ grub_millisleep (10);
/* Enable the port. */
grub_uhci_writereg16 (u, reg, enable << 2);
@@ -602,7 +612,10 @@
grub_dprintf ("uhci", "waiting for the port to be enabled\n");
- while (! (grub_uhci_readreg16 (u, reg) & (1 << 2)));
+ endtime = grub_get_time_ms () + 1000;
+ while (! (grub_uhci_readreg16 (u, reg) & (1 << 2)))
+if (grub_get_time_ms () > endtime)
+ return grub_error (GRUB_ERR_IO, "UHCI Timed out");
status = grub_uhci_readreg16 (u, reg);
grub_dprintf ("uhci", ">3detect=0x%02x\n", status);
=== modified file 'bus/usb/usbhub.c'
--- bus/usb/usbhub.c 2009-07-16 22:14:09 +
+++ bus/usb/usbhub.c 2009-12-04 16:54:09 +
@@ -48,7 +48,7 @@
if (! grub_usb_devs[i])
break;
}
- if (grub_usb_devs[i])
+ if (i == 128)
{
grub_error (GRUB_ERR_IO, "Can't assign address to USB device");
return NULL;
@@ -60,6 +60,7 @@
| GRUB_USB_REQTYPE_TARGET_DEV),
GRUB_USB_REQ_SET_ADDRESS,
i, 0, 0, NULL);
+
dev->addr = i;
dev->initialized = 1;
grub_usb_devs[i] = dev;
=== modified file 'commands/usbtest.c'
--- commands/usbtest.c 2009-11-09 17:43:53 +
+++ commands/usbtest.c 2009-12-04 01:33:17 +
@@ -146,6 +146,7 @@
usb_print_str ("Configuration:", dev, config->strconfig);
}
+ if (dev->config[0].descconf)
for (i = 0; i < dev->config[0].descconf->numif; i++)
{
int j;
signature.asc
Description: OpenPGP digital signature
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Grub2 hanging in (my) qemu
Hello, Doing some tests in Grub2 and my qemu (same environtment than some days ago): when I move the cursor down in the main menu Grub2 hangs. First revision that this happens is 1907 Itth the patch: --- 2009-12-02 Robert Millan Use the same reboot approach on i386 coreboot and qemu as we do on BIOS. --- I'm using Debian with qemu 0.10.6-1. Grub2 boots, loads the menu and when I move the highlighted menu entry just hangs. Or if I wait the timeout and tries to load something hangs too, without pressing keys. Thanks, -- Carles Pina i Estany http://pinux.info ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Grub2 hanging in (my) qemu
Hello, On Dec/05/2009, Carles Pina i Estany wrote: > Doing some tests in Grub2 and my qemu (same environtment than some days > ago): when I move the cursor down in the main menu Grub2 hangs. I forgot to mention it: Vladimir fixed in in revno 1913. -- Carles Pina i Estany http://pinux.info ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
New Chinese (simplified) PO file for 'grub' (version 1.97+20091122)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'grub' has been submitted by the Chinese (simplified) team of translators. The file is available at: http://translationproject.org/latest/grub/zh_CN.po (We can arrange things so that in the future such files are automatically e-mailed to you when they arrive. Ask at the address below if you want this.) All other PO files for your package are available in: http://translationproject.org/latest/grub/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/grub.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Cryptography
Robert Millan wrote: > On Tue, Nov 17, 2009 at 01:21:07PM +0100, Robert Millan wrote: > >> On Mon, Nov 16, 2009 at 02:48:02PM +0100, Vladimir 'phcoder' Serbinenko >> wrote: >> >>> === added file 'include/grub/cipher_wrap.h' >>> --- include/grub/cipher_wrap.h 1970-01-01 00:00:00 + >>> +++ include/grub/cipher_wrap.h 2009-11-13 16:51:09 + >>> >> Can we avoid cluttering the grub/ namespace with glue code? >> > > Sorry, what I said is confusing. I didn't mean the grub/ namespace, I mean > the "default" namespace (in which grub/* is included but also multiboot.h). > > lib-linux has its own namespace where we put things like linux/* and asm/*, > I think a similar approach would be desireable for consistency. > > This and other problems were fixed and now crypto is in experimental except Simon Peter's and Michael Gorven's work -- Regards Vladimir 'φ-coder/phcoder' Serbinenko signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
gettext: normal/*
Hello,
I have finished in my computer normal/* (looks very nice to see Grub2
screens in Catalan :-) ).
There is one string in function grub_normal_reader_init:
---
grub_printf (_("\
[ Minimal BASH-like line editing is supported. For the first word, TAB\n\
lists possible command completions. Anywhere else TAB lists possible\n\
device/file completions.%s ]\n\n"),
reader_nested ? " ESC at any time exits." : "");
---
I could use the grub_printf_indent but then on screen would look like:
[ Minimal BASH-like line editing is supported. For the first word, TAB
lists possible command completions. Anywhere else TAB lists possible
device/file completions. ESC at any time exits. ]
Do you want to extend a bit grub_printf_indent to support the special indenting
of "[" or doesn't matter?
My opinion is that doesn't matter, keep it simple. But if we prefer the other
way I would do.
--
Carles Pina i Estany
http://pinux.info
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: USB device not seen by grub
On Fri, Dec 04, 2009 at 09:28:32PM -0600, richardvo...@gmail.com wrote: > > And all of this only to make good to someone who would like to see every > > free software die? > > Not all supporters of free software share that philosophy, quite a few > of us like to be able to tell people "that proprietary software you > use, well, it works better with free software". And sometimes free > software is enriched by playing well with closed-source. Our standpoint is very clear: proprietary software restraints users; this is unethical and therefore proprietary software should not exist. However, we do support interoperation with proprietary software. In fact the Linux images that are loaded by GRUB include non-free firmware in them more often than not. And we also support systems that are entirely non-free. When we do this, it is not a matter of principle but a matter of strategy. MS Windows already has its own proprietary bootloader, and GRUB isn't even capable of acting as a full replacement to it. GRUB isn't helping Microsoft build their proprietary OS (the GPL prevents this), so there's no benefit in refusing to support it. The situation is similar for e.g. MacOS X. As for adding generic support for BIOS callbacks, I appreciate Vladimir's remarks, and conclude that this needs to be considered carefully. Even from a purely technical point of view, I don't have a clear idea what it would be used for. Perhaps you can explain the situations on which you think this is useful? If you seek to persuade us, this is much more effective than the philosophical debate, since our goals are already well stablished, and the only question is whether this proposed feature helps us bring them further or does the opposite instead. -- 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: gettext: normal/*
On Sat, Dec 05, 2009 at 07:31:02PM +, Carles Pina i Estany wrote:
>
> Hello,
>
> I have finished in my computer normal/* (looks very nice to see Grub2
> screens in Catalan :-) ).
>
> There is one string in function grub_normal_reader_init:
>
> ---
> grub_printf (_("\
> [ Minimal BASH-like line editing is supported. For the first word, TAB\n\
>lists possible command completions. Anywhere else TAB lists possible\n\
>device/file completions.%s ]\n\n"),
>reader_nested ? " ESC at any time exits." : "");
> ---
>
> I could use the grub_printf_indent but then on screen would look like:
>
> [ Minimal BASH-like line editing is supported. For the first word, TAB
> lists possible command completions. Anywhere else TAB lists possible
> device/file completions. ESC at any time exits. ]
>
> Do you want to extend a bit grub_printf_indent to support the special
> indenting
> of "[" or doesn't matter?
>
> My opinion is that doesn't matter, keep it simple. But if we prefer the other
> way I would do.
Doesn't matter. But if you do this, please remove the brackets.
--
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: USB device not seen by grub
On Fri, Dec 04, 2009 at 04:45:01PM -0600, richardvo...@gmail.com wrote: > There are actually quite a lot of devices like this. Most notebooks > have broken BIOS that won't load the extension ROM from a PCMCIA slot, > if grub could do so it would enable booting from a wide variety of > PCMCIA/CardBus/ExpressCard-to-SCSI/SATA/USB adapters. PCI ROM processing is a feature we need. The reason we need this is not to help proprietary OSes, but so that modules like vbe or biosdisk can work on other platforms (e.g. coreboot). The code in those ROMs is often proprietary, but it is external to the motherboard. This is important, because GRUB may act as the primary firmware for PC-class motherboards (when combined with coreboot). In this kind of setup, GRUB itself can't support external cards using its own drivers and must rely on the PCI ROM ones. Therefore this interaction is always needed. Also, some platforms like EFI insist on acting as a wrapper between these PCI ROM drivers and the bootloader. Since this wrapper is completely useless and just adding overhead, we might as well skip it. -- 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: Miscellaneous file cleanup
On Fri, Dec 04, 2009 at 06:05:37PM -0600, Bruce Dubbs wrote:
> + docs/{grub.info,version.texi,stamp-vti}
This seems bash-specific. Have you tested it with another shell?
--
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: gettext: normal/*
Hi,
On Dec/05/2009, Robert Millan wrote:
> > There is one string in function grub_normal_reader_init:
> >
> > ---
> > grub_printf (_("\
> > [ Minimal BASH-like line editing is supported. For the first word, TAB\n\
> >lists possible command completions. Anywhere else TAB lists possible\n\
> >device/file completions.%s ]\n\n"),
> >reader_nested ? " ESC at any time exits." : "");
> > ---
> Doesn't matter. But if you do this, please remove the brackets.
Now it's indented like the other indented messages. See the attached
patch.
If needed I can reduce the left and right margins (adding a parameter to
print_message_indented).
Tested in my system and works fine in English and my Catalan draft.
If it's fine I would commit.
Thanks,
--
Carles Pina i Estany
http://pinux.info
=== modified file 'include/grub/normal.h'
--- include/grub/normal.h 2009-08-24 23:55:06 +
+++ include/grub/normal.h 2009-12-05 20:14:56 +
@@ -73,6 +73,7 @@ void grub_parse_color_name_pair (grub_ui
/* Defined in `menu_text.c'. */
void grub_wait_after_message (void);
+void print_message_indented (const char *msg);
/* Defined in `handler.c'. */
void read_handler_list (void);
=== modified file 'normal/auth.c'
--- normal/auth.c 2009-11-09 14:30:47 +
+++ normal/auth.c 2009-12-05 19:10:45 +
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
struct grub_auth_user
{
@@ -237,7 +238,7 @@ grub_auth_check_authentication (const ch
return GRUB_ERR_NONE;
}
- if (!grub_cmdline_get ("Enter username: ", login, sizeof (login) - 1,
+ if (!grub_cmdline_get (_("Enter username: "), login, sizeof (login) - 1,
0, 0, 0))
goto access_denied;
=== modified file 'normal/color.c'
--- normal/color.c 2008-03-26 13:01:02 +
+++ normal/color.c 2009-12-05 19:12:14 +
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
/* Borrowed from GRUB Legacy */
static char *color_list[16] =
@@ -76,7 +77,7 @@ grub_parse_color_name_pair (grub_uint8_t
bg_name = grub_strchr (fg_name, '/');
if (bg_name == NULL)
{
- grub_printf ("Warning: syntax error (missing slash) in `%s'\n", fg_name);
+ grub_printf (_("Warning: syntax error (missing slash) in `%s'\n"), fg_name);
grub_wait_after_message ();
goto free_and_return;
}
@@ -85,13 +86,13 @@ grub_parse_color_name_pair (grub_uint8_t
if (parse_color_name (&fg, fg_name) == -1)
{
- grub_printf ("Warning: invalid foreground color `%s'\n", fg_name);
+ grub_printf (_("Warning: invalid foreground color `%s'\n"), fg_name);
grub_wait_after_message ();
goto free_and_return;
}
if (parse_color_name (&bg, bg_name) == -1)
{
- grub_printf ("Warning: invalid background color `%s'\n", bg_name);
+ grub_printf (_("Warning: invalid background color `%s'\n"), bg_name);
grub_wait_after_message ();
goto free_and_return;
}
=== modified file 'normal/main.c'
--- normal/main.c 2009-11-25 03:48:33 +
+++ normal/main.c 2009-12-05 20:36:30 +
@@ -509,11 +509,19 @@ grub_normal_reader_init (void)
grub_normal_init_page ();
grub_setcursor (1);
- grub_printf (_("\
- [ Minimal BASH-like line editing is supported. For the first word, TAB\n\
- lists possible command completions. Anywhere else TAB lists possible\n\
- device/file completions.%s ]\n\n"),
- reader_nested ? " ESC at any time exits." : "");
+ const char *msg = _("Minimal BASH-like line editing is supported. For \
+the first word, TAB lists possible command completions. Anywhere else TAB \
+lists possible device/file completions. %s");
+ const char *msg_esc = _("ESC at any time exits.");
+
+ char *msg_formatted = grub_malloc (sizeof (char) * (grub_strlen (msg) +
+ grub_strlen(msg_esc) + 1));
+
+ grub_sprintf (msg_formatted, msg, reader_nested ? msg_esc : "");
+ print_message_indented (msg_formatted);
+ grub_printf ("\n\n");
+
+ grub_free (msg_formatted);
return 0;
}
=== modified file 'normal/menu_text.c'
--- normal/menu_text.c 2009-12-05 11:25:07 +
+++ normal/menu_text.c 2009-12-05 20:30:23 +
@@ -77,7 +77,7 @@ getstringwidth (grub_uint32_t * str, con
return width;
}
-static void
+void
print_message_indented (const char *msg)
{
const int line_len = GRUB_TERM_WIDTH - grub_getcharwidth ('m') * 15;
=== modified file 'normal/misc.c'
--- normal/misc.c 2009-06-10 21:04:23 +
+++ normal/misc.c 2009-12-05 19:18:21 +
@@ -24,6 +24,8 @@
#include
#include
#include
+#include
+#include
/* Print the information on the device NAME. */
grub_err_t
@@ -34,13 +36,16 @@ grub_normal_print_device_info (const cha
p = grub_strchr (name, ',');
if (p)
-grub_printf ("\tPartition %s: ", name);
+{
+ grub_putchar ('\t');
+ grub_printf (_("Partition %s: "), name);
+}
else
-grub_printf ("Device %s: ", name);
+grub_printf (_("Device %s: "), name);
dev = grub_device_open (name);
Re: Documenting the GRUB configure (during build)
On Fri, Dec 04, 2009 at 07:46:24PM -0600, Bruce Dubbs wrote: > I want to submit an update to the INSTALL file. In looking at > ./configure, it does some guessing. We have: Note that we don't need to document all configure flags, only the ones that are set in stone like --prefix. If we document all of them, then we have an added burden of keeping INSTALL up to date with all these small changes, which in this case doesn't pay off IMO. -- 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: Miscellaneous file cleanup
Robert Millan wrote:
On Fri, Dec 04, 2009 at 06:05:37PM -0600, Bruce Dubbs wrote:
+ docs/{grub.info,version.texi,stamp-vti}
This seems bash-specific. Have you tested it with another shell?
No I didn't. Sorry about that. Try this patch.
-- Bruce
=== modified file 'Makefile.in'
--- Makefile.in 2009-11-30 01:25:57 +
+++ Makefile.in 2009-12-05 21:27:46 +
@@ -139,7 +139,9 @@
MOSTLYCLEANFILES =
DISTCLEANFILES = config.status config.cache config.log config.h \
Makefile stamp-h include/grub/cpu include/grub/machine \
- gensymlist.sh genkernsyms.sh build_env.mk
+ gensymlist.sh genkernsyms.sh build_env.mk \
+ docs/grub.info docs/version.texi docs/stamp-vti
+
MAINTAINER_CLEANFILES = $(srcdir)/configure $(addprefix $(srcdir)/,$(MKFILES))
\
$(srcdir)/DISTLIST $(srcdir)/config.h.in $(srcdir)/stamp-h.in $(INFOS)
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Documenting the GRUB configure (during build)
Robert Millan wrote: On Fri, Dec 04, 2009 at 07:46:24PM -0600, Bruce Dubbs wrote: I want to submit an update to the INSTALL file. In looking at ./configure, it does some guessing. We have: Note that we don't need to document all configure flags, only the ones that are set in stone like --prefix. If we document all of them, then we have an added burden of keeping INSTALL up to date with all these small changes, which in this case doesn't pay off IMO. I'm afraid I don't agree that the solution to documenting changes is not to document anything. That may be a little harsh, but I firmly believe that documentation is key to acceptance. I do understand the issues surrounding documentation that does not keep up with the coding, but the idea is to help users and not make everyone figure things out for themselves. In that vein, I propose using the attached INSTALL file based on what I figured out from reading the code. I'm including the full file and the diff so you can easily see it in context as well as looking at the specific changes. -- Bruce -*- Text -*- This is the GRUB. Welcome. This file contains instructions for compiling and installing the GRUB. The Requirements GRUB depends on some software packages installed into your system. If you don't have any of them, please obtain and install them before configuring the GRUB. * GCC 4.1.3 or later * GNU Make 3.81 or later * GNU Bison 2.3 or later * GNU Binutils 2.18 or later * Other standard GNU/Unix tools If you use a development snapshot or want to hack on GRUB you may need the following. * Ruby 1.6 or later * Python 2.5.2 or later * GNU Autoconf 2.60 or later * GNU Automake 1.10.1 or later * Fontconfig 2.6.0 or later * GNU Ncurses 5.7 or later * Libusb 0.9 or later Configuring the GRUB The `configure' shell script attempts to guess correct values for various system-dependent variables used during compilation. It uses those values to create a `Makefile' in each directory of the package. It may also create one or more `.h' files containing system-dependent definitions. Finally, it creates a shell script `config.status' that you can run in the future to recreate the current configuration, a file `config.cache' that saves the results of its tests to speed up reconfiguring, and a file `config.log' containing compiler output (useful mainly for debugging `configure'). If you need to do unusual things to compile the package, please try to figure out how `configure' could check whether to do them, and mail diffs or instructions to the address given in the `README' so they can be considered for the next release. If at some point `config.cache' contains results you don't want to keep, you may remove or edit it. The file `configure.ac' is used to create `configure' by a program called `autoconf'. You only need `configure.in' if you want to change it or regenerate `configure' using a newer version of `autoconf'. Building the GRUB = The recommended way to compile this package is: 1. `cd' to the directory containing the package's source code. 2. If you don't use a release tarball you have to type `sh autogen.sh'. 3. Create a build directory, `mkdir -p build; cd build' 4. Type `../configure' to configure the package for your system. If you're using `csh' on an old version of System V, you might need to type `sh ../configure' instead to prevent `csh' from trying to execute `configure' itself. While running, `configure' prints messages telling which features it is checking. 5. Type `make' to compile the package. 6. Type `make install' to install the programs and, data files, and documentation. 7. You can remove the program binaries and object files from the source code directory by typing `make clean'. To also remove the files that `configure' created (so you can compile the package for a different kind of computer), type `make distclean'. There is also a `make maintainer-clean' target, but that is intended mainly for the package's developers. If you use it, you may have to get all sorts of other programs in order to regenerate files that came with the distribution. Compiling For Multiple Architectures You can compile the package for more than one kind of computer at the same time, by placing the object files for each architecture in their own directory. `cd' to the directory where you want the object files and executables to go and run the `configure' script. `configure' automatically checks for the source code in the directory that `configure' is in and in `..'. Installation Names == By default, `make install' will install the package's files in `/usr/local/bin', `/usr/local/man', etc. You can specify an installation prefix by giving `configure' the option `--prefix=PATH'. You can specify separate installation prefi
Re: fonts for gfxmenu, help needed
2009/11/30 Michal Suchanek : > 2009/11/30 Qianqian Fang : >> Michal Suchanek wrote: >>> >>> Aestetics is relative but uniform stroke width is not. >>> >>> Yes, I suspected it would not be a common character, my character >>> table does not list a meaning for it. >>> >>> However, similar issue can be seen with the 刀 character in the >>> microhei_24px and microhei_32px rasterization. In fact, the stroke >>> width is almost inverted in these two rasterizations although they are >>> supposedly the same font. >>> >> >> I agree with you that the CJK autohinter is far from perfect. >> It does a much worse job in smaller sizes. > > If it does decent job on larger font sizes then perhaps we could > render a large enough font and rely on bitmap fonts for smaller sizes. > > I guess I should also install some more fonts and try to convert them > to bitmap in Fontforge. > I tried rasterizing Arphic fonts in Fontforge and I am disappointed. First, fontforge sucks at this kind of task. There is no reasonable way to select multiple glyphs, save a Unicode range. You can choose them one by one or drag by mouse. The semantic of drag operation is different on selected and non-selected glyphs. Pressing Esc to get out of menu or clicking somewhere deselects the glyphs again with no way of re-selecting the glyphs I was working with. Terrible user interface. The results of rasterization are also disappointing. The UMingTW font seems somewhat reasonable at 48 and 64 px (but not 52 px so it's probably just a matter of skimming through more glyphs to find some examples of terrible rasterization). In UKaiTW there is no problem with the 刀 character because its strokes are slanted enough to not get turned into a line with width-stepping but there is a problem with 口 and similar glyphs. The problem are near-vertical or near-horizontal lines that get rasterized quite poorly. Glyphs with multiple vertical or horizontal strokes often get strokes of different widths because some of the strokes get rasterized on the pixel boundary while others do not. The same issues can be seen in the outline view without antialiasing, and antialiasing greatly improves the glyph shapes, and at least for me it improves readability as well. So to me rasterizing to bitmaps looks like a dead end. We either need grayscale support or vector support or take only the limited set of fonts which are manually drawn as bitmaps. Thanks Michal ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Just a cosmetic question about grub_vprintf()?
Colin Watson wrote:
On Sat, Nov 28, 2009 at 06:21:20PM +, rubisher wrote:
Robert Millan wrote:
On Sun, Nov 22, 2009 at 01:10:11PM +, rubisher wrote:
But as far as the 1st parameter of grub_vsprintf is a pointer,
wouldn't it be better to write:
--- kern/misc.c.orig2009-11-22 13:07:22.0 +
+++ kern/misc.c 2009-11-22 13:07:51.0 +
@@ -160,7 +160,7 @@
{
int ret;
- ret = grub_vsprintf (0, fmt, args);
+ ret = grub_vsprintf (NULL, fmt, args);
return ret;
}
Yes. But we have many of those, so we don't go huntin' them. If you'd
like to help us, a patch that does this change in bulk would be welcome.
It will be of great pleasure for me, but I didn't foreseen so much (the
most difficult to me are 'opaque pointer') but I hoppe that such 'sparse'
would help me for the most ;<)
If you do this, make sure you understand why it makes no difference in
standards-compliant C. In particular, this understanding matters when
functions with variable-length argument lists are concerned.
(See the C FAQ for more details.)
Ok, I will take care.
In the mean time I just have enough time to try this diff to add enable-sparse
option using cgcc wrapper:
--- configure.ac2009-12-05 10:12:22 +
+++ configure.ac2009-12-05 19:14:14 +
@@ -537,6 +537,20 @@
[AC_DEFINE([MM_DEBUG], [1],
[Define to 1 if you enable memory manager
debugging.])])
+AC_ARG_ENABLE([sparse],
+ AS_HELP_STRING([--enable-sparse],
+ [enable sparse code checking]), ,
+enable_sparse=no
+)
+
+# Set cgcc as compiler and add sparse flags if --enable-sparse was specified.
+if test "$enable_sparse" = "yes"; then
+CC="REAL_CC=$CC cgcc"
+CFLAGS="$CFLAGS -Wbitwise -Wnon-pointer-null"
+TARGET_CC="REAL_CC=$TARGET_CC cgcc"
+TARGET_CFLAGS="$TARGET_CFLAGS -Wbitwise -Wnon-pointer-null"
+fi
+
AC_ARG_ENABLE([grub-emu-usb],
[AS_HELP_STRING([--enable-grub-emu-usb],
[build and install the `grub-emu' debugging
utility with USB support (default=guessed)])])
=== <> ===
That seems to works on my side but all advise are welcome ;<)
Tx,
J.
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Documenting the GRUB configure (during build)
+10 :). --S On Dec 5, 2009, at 1:42 PM, Bruce Dubbs wrote: Robert Millan wrote: On Fri, Dec 04, 2009 at 07:46:24PM -0600, Bruce Dubbs wrote: I want to submit an update to the INSTALL file. In looking at ./ configure, it does some guessing. We have: Note that we don't need to document all configure flags, only the ones that are set in stone like --prefix. If we document all of them, then we have an added burden of keeping INSTALL up to date with all these small changes, which in this case doesn't pay off IMO. I'm afraid I don't agree that the solution to documenting changes is not to document anything. That may be a little harsh, but I firmly believe that documentation is key to acceptance. I do understand the issues surrounding documentation that does not keep up with the coding, but the idea is to help users and not make everyone figure things out for themselves. In that vein, I propose using the attached INSTALL file based on what I figured out from reading the code. I'm including the full file and the diff so you can easily see it in context as well as looking at the specific changes. -- Bruce -*- Text -*- This is the GRUB. Welcome. This file contains instructions for compiling and installing the GRUB. The Requirements GRUB depends on some software packages installed into your system. If you don't have any of them, please obtain and install them before configuring the GRUB. * GCC 4.1.3 or later * GNU Make 3.81 or later * GNU Bison 2.3 or later * GNU Binutils 2.18 or later * Other standard GNU/Unix tools If you use a development snapshot or want to hack on GRUB you may need the following. * Ruby 1.6 or later * Python 2.5.2 or later * GNU Autoconf 2.60 or later * GNU Automake 1.10.1 or later * Fontconfig 2.6.0 or later * GNU Ncurses 5.7 or later * Libusb 0.9 or later Configuring the GRUB The `configure' shell script attempts to guess correct values for various system-dependent variables used during compilation. It uses those values to create a `Makefile' in each directory of the package. It may also create one or more `.h' files containing system-dependent definitions. Finally, it creates a shell script `config.status' that you can run in the future to recreate the current configuration, a file `config.cache' that saves the results of its tests to speed up reconfiguring, and a file `config.log' containing compiler output (useful mainly for debugging `configure'). If you need to do unusual things to compile the package, please try to figure out how `configure' could check whether to do them, and mail diffs or instructions to the address given in the `README' so they can be considered for the next release. If at some point `config.cache' contains results you don't want to keep, you may remove or edit it. The file `configure.ac' is used to create `configure' by a program called `autoconf'. You only need `configure.in' if you want to change it or regenerate `configure' using a newer version of `autoconf'. Building the GRUB = The recommended way to compile this package is: 1. `cd' to the directory containing the package's source code. 2. If you don't use a release tarball you have to type `sh autogen.sh'. 3. Create a build directory, `mkdir -p build; cd build' 4. Type `../configure' to configure the package for your system. If you're using `csh' on an old version of System V, you might need to type `sh ../configure' instead to prevent `csh' from trying to execute `configure' itself. While running, `configure' prints messages telling which features it is checking. 5. Type `make' to compile the package. 6. Type `make install' to install the programs and, data files, and documentation. 7. You can remove the program binaries and object files from the source code directory by typing `make clean'. To also remove the files that `configure' created (so you can compile the package for a different kind of computer), type `make distclean'. There is also a `make maintainer-clean' target, but that is intended mainly for the package's developers. If you use it, you may have to get all sorts of other programs in order to regenerate files that came with the distribution. Compiling For Multiple Architectures You can compile the package for more than one kind of computer at the same time, by placing the object files for each architecture in their own directory. `cd' to the directory where you want the object files and executables to go and run the `configure' script. `configure' automatically checks for the source code in the directory that `configure' is in and in `..'. Installation Names == By default, `make install' will install the package's files in `/usr/local/bin', `/usr/local/man', etc. You can specify an installation prefix by giving `configure' the option `--
Re: gettext: normal/*
Hello,
I think that my patch is fine. I only want to ask for two particular
things:
> === modified file 'include/grub/normal.h'
> --- include/grub/normal.h 2009-08-24 23:55:06 +
> +++ include/grub/normal.h 2009-12-05 20:14:56 +
> @@ -73,6 +73,7 @@ void grub_parse_color_name_pair (grub_ui
>
> /* Defined in `menu_text.c'. */
> void grub_wait_after_message (void);
> +void print_message_indented (const char *msg);
Is it fine to add the declaration of print_message_indented in normal.h
to be used from menu_text.c and main.c ? Or you would prefer some other
place and declare the function in other .c file?
> - if (!grub_cmdline_get ("Enter username: ", login, sizeof (login) - 1,
> + if (!grub_cmdline_get (_("Enter username: "), login, sizeof (login) - 1,
Is it fine to have a translatable string ended with a space? I think
that it's fine (same case than \n, even thought in this case msgfmt is
not warning).
(there are other 2 strings that ends with a space, but that ones are
easier to replace with a grub_putchar after it)
When these two things are confirmed I will commit (ok?) and then
hopefully add i18n support to the grub modules or util.
Thanks,
--
Carles Pina i Estany
http://pinux.info
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
kern/device.c and https://savannah.gnu.org/bugs/?26834
Hi, I rebuilt grub2 from Debian unstable sources with the following
patch applied and have no longer had to manually remove the "search"
line in my grub.gfg in order to boot on a hard disk with /boot partition
visible to the BIOS where the entire disk is bigger than what the BIOS
recognises.
This *is* a relatively common configuration for old machines with
replaced hard disks.
Someone suggested posting this patch here. I forget who posted it in
IRC, but it worked (-:.
There is still one error message about a filesystem with a particular
UUID not being found, but the boot process is now automatic.
Arthur.
*** kern/device.c 2009-11-30 13:12:15.0 +1030
--- ../device.c 2009-11-30 19:27:03.0 +1030
*** grub_device_iterate (int (*hook) (const
*** 109,114
--- 109,116
(void) grub_partition_iterate (dev->disk, iterate_partition);
grub_device_close (dev);
+ grub_errno = GRUB_ERR_NONE;
+
p = ents;
while (p != NULL)
{
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [Gnewsense-dev] Re: [Announce] Initial GRUB2 on Yeeloong
On Wed, Oct 28, 2009 at 09:02:06PM +0100, Vladimir 'phcoder' Serbinenko wrote: > >> Create a font.bin as explained here: http://grub.enbug.org/gfxterm > > ./grub-mkimage -O elf -o grub.elf -d . -f font.bin sm712 gfxterm sh normal > at_keyboard ata linux part_msdos ext2 Hi, Vladimir's port of GRUB to the Yeeloong has been merged in GRUB experimental tree, and is now packaged and will be available in metad in a few hours. There's no grub-install yet. For those of you who want to try, install the grub-yeeloong package and follow Vladimir's instructions (quoted above). When running system-wide grub-mkimage, you may skip the "-d ." flag (in fact, you probably have to). -- 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
