objcopy fix (for x86_64)
This prevents objcopy from copying sections other than .text during the
./configure absolute address test. On i386, our conftest only has .text
and .comment (which is skipped), but on x86_64 there's an additional
.eh_frame section which isn't skipped unless you tell it to.
Just one step further towards x86_64 grub ;-)
Comments?
--
Robert Millan
GPLv2 I know my rights; I want my phone call!
DRM What use is a phone call, if you are unable to speak?
(as seen on /.)
* aclocal.m4 (grub_PROG_OBJCOPY_ABSOLUTE): Pass `--only-section=.text'
to objcopy.
diff -ur grub2.old/aclocal.m4 grub2/aclocal.m4
--- grub2.old/aclocal.m4 2007-02-03 12:36:13.0 +0100
+++ grub2/aclocal.m4 2007-11-18 11:34:06.0 +0100
@@ -61,7 +61,7 @@
else
AC_MSG_ERROR([${CC-cc} cannot link at address $link_addr])
fi
- if AC_TRY_COMMAND([${OBJCOPY-objcopy} -O binary conftest.exec conftest]); then :
+ if AC_TRY_COMMAND([${OBJCOPY-objcopy} --only-section=.text -O binary conftest.exec conftest]); then :
else
AC_MSG_ERROR([${OBJCOPY-objcopy} cannot create binary files])
fi
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Outline menu
Markus Elfring [EMAIL PROTECTED] writes: I want to make something to generate menu entries from a script. Is that what you mean? I see two places where common settings could be written. 1. menu configuration 2. source code generation script Where do you want to place them? Both, if I understand you correctly. The scripting language should eventually be capable of generating meny entries. -- Marco ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: FS: write ability
Oleg Strikov [EMAIL PROTECTED] writes: I'm going to code new grub2 mechanism to provide not only read, but write ability to grub loader. First of all i need such feature for ext2/3 FS, but i think it'll be great to enlarge it to all supported FS. If anybody can help with some code or recommend interesting approach - feel free to tell me Please understand that this cannot be included in GRUB 2, at least as far as I am concerned. Although it is very nice to work on write support, it goes beyond the goal of a bootloader. If it is included in GRUB, it means we have to maintain it. We already have a lack of time to maintain the current code base. Besides that, there is little added value. While write support is *very* complex, can damage filesystems when there is a bug, etc. It's also a lot of work, even for a single filesystem. Why do you need write support? Perhaps there is another solution to the problem you are trying to fix? -- Marco ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Fix eisa_mmap evaluation, add memory existence check
On Sun, Nov 18, 2007 at 12:09:25PM +0100, Marco Gerards wrote: Robert Millan [EMAIL PROTECTED] writes: On Fri, Nov 09, 2007 at 10:53:23PM +0100, Christian Franke wrote: Ah, and why 0xcf instead of 0xff ? ... or 0xaa or 0x55. 0xaa and 0x55 are typicaly used directly in memory because every bit is negated, which is precisely what `^ 0xff' would do. Robert, can you take care of this patch? You have more expertise with this than I do :-) Sure. -- Robert Millan GPLv2 I know my rights; I want my phone call! DRM What use is a phone call, if you are unable to speak? (as seen on /.) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB 2 development
Yoshinori K. Okuji [EMAIL PROTECTED] writes: On Saturday 10 November 2007 18:53, Marco Gerards wrote: The problem currently is that, accidently, we lose track of outstanding bugs and patches. It is frustrating to both developers and people sending in patches/bugreports. Ah, really. For me, it is not accidentally but naturally. ;) :-) Hopefully we can start using a bug tracker soon. There are many that are good. In my opinion the mailinglist and wiki doesn't work for us anymore. Hmm... I don't agree completely with this argument in my experience. When the aim is to track issues, email or wiki does not work so well (unless you use a kind of plugin to the wiki to make wiki a bug tracker). But for discussions, email or irc is much better. A bug tracker could work as well as email, if it supports email integration (which I tried with BugCommunicator, and failed due to many inconsistencies among email client implementations). My goal is to track issues. Perhaps I was not clear, but I really like IRC and especially email for discussions. So, in reality, I used a bug tracker only for recording purpose. Bugs are registered, then discussions are done in email. Once something is determined (fixed, cancelled or whatever), the bug tracker is updated. After then, I realized that a wiki was good enough for recording. I felt that it was easier to access and update info on a wiki than on a bug tracker. It just doesn't work out... Besides that, bug tracking systems are better when you are working on something with a group of people. Besides that, maybe as I said before, the real problem is noise. For GRUB Legacy, I mostly used email. When a message looked important, and I didn't have time to deal with it immediately, I marked the message as important so that I could look up for such messages later (a feature implemented by any modern MUA). If a message was just bogus, I just skipped it over. Once I started to use the bug tracker on Savannah, of course, people started to post bugs there. Then, all messages were important, because they were registered in the database. A lot of my time was consumed to deal with silly posts, such as just GRUB does not work, help me!. So, instead of marking important messages, I had to mark non-important messages. Other people can't see how we mark messages in our inbox. That's the problem... So did it make my life any easier to have a bug tracker? I hardly believe it. Therefore, these days, my usage of bug/issue trackers is to limit people who can post bugs to known people. This way, I can make my email-based-hand-made tracker a bit more structured and sharable with other people, yet not having noise very much. Surely, this way also has a disadvantage that somebody else must submit a bug to a tracker every time when an important issue is raised by an unknown person. The question is, after all, whether bad messages should be deleted or good messages should be added... Personally, I think it is rather a rare event that an unknown person makes a good report, in comparison with from a known person, especially when taking it into account that a good reporter tends to become a repeater, thus become a known person quickly. So I don't object to having a bug trakcer, but I recommend you considering carefully whether you want to encourage everybody to submit bugs to a bug tracker. We could ask people to send an email and after that put the bug on the bugtracker? If people submit reports that cannot be understand, we simply have to remove the report I think, otherwise it becomes noisy. Many projects use bugzilla. Perhaps it isn't perfect, but it does what I want. I just do not have the resources to set that up. Perhaps someone else knows something better. No, the current trend is trac or a trac-like system, such as redMine. :) Ah :) So can we use savannah? And for what shall we use it? Bugs, patches, todo items? If it doesn't work out, we can switch or stop using it. But as I see it now, we need such tool for good collaboration. -- Marco ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Fix eisa_mmap evaluation, add memory existence check
On Tue, Oct 23, 2007 at 09:06:16PM +0200, Christian Franke wrote:
+/* Check memory address */
+static int
+addr_is_valid (grub_addr_t addr)
+{
+ volatile unsigned char * p = (volatile unsigned char *)addr;
+ unsigned char x, y;
+ x = *p;
+ *p = x ^ 0xcf;
+ y = *p;
+ *p = x;
+ return y == (x ^ 0xcf);
+}
0xff would be better IMO.
+ if (!(addr + size addr addr_is_valid (addr) addr_is_valid
(addr+size-1)))
+grub_fatal (invalid memory region %p - %p, (char*)addr,
(char*)addr+size-1);
Should `addr + size addr' be optimized out as `size 0' ? (or if we need it
this way to check for overflows, should we prevent gcc from optimizing it?)
--
Robert Millan
GPLv2 I know my rights; I want my phone call!
DRM What use is a phone call, if you are unable to speak?
(as seen on /.)
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] mkdevicemap for Cygwin
Christian Franke [EMAIL PROTECTED] writes: Some changes for grub-mkdevicemap on Cygwin. Christian 2007-11-13 Christian Franke [EMAIL PROTECTED] * util/grub-mkdevicemap.c (get_floppy_disk_name): Add Cygwin device names. (get_ide_disk_name): Disable on __CYGWIN__. [__CYGWIN__] (get_ide_disk_name): Disable. (get_scsi_disk_name): Add Cygwin device names. (check_device): Add static. Return error instead of success on empty string. Can you explain this? Does this break something on GNU/Linux? (make_device_map): Disable IDE loop on __CYGWIN__. [__CYGWIN__] (make_device_map): Disable IDE loop. Move label inside linux specific code to prevent compiler warning. (make_device_map): Move label inside linux specific code to prevent compiler warning. Otherwise fine, so this can be committed if there aren't any other problems with this patch. -- Marco ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: serial port
Robert Millan [EMAIL PROTECTED] writes: Hi, Any reason why the serial port is not enabled in grub_serial_init() ? grub terminal Available terminal(s): console Current terminal: console grub serial grub terminal Available terminal(s): serial console Current terminal: serial Perhaps because the serial command sets it up? Although I agree it seems a bit weird that it works this way. Perhaps it should be enabled with the same defaults from the beginning? One problem of initializing it is that hardware will be accessed, while it might not be desirable. -- Marco ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Building GRUB on platforms without ELF support
Robert Millan [EMAIL PROTECTED] writes: On Fri, Nov 16, 2007 at 11:58:14PM +0100, Christian Franke wrote: Building GRUB modules requires ELF support in gas and ld. For platforms where ELF is not the native format, ld may support ELF output. If not (like on Cywin) some conversion to ELF is necessary. In general, GNU objcopy allows conversion between object file formats. Unfortunately, objcopy (and BFD itself) does not include any support for the conversion of relocation formats (even conversion between ELF variants do not work). In particular, when converting PE (a COFF variant) to ELF, objcopy does not abort but silently produces bad PC-relative relocation offsets. In my first Cygwin patch, there is a hack to fix this in the GRUB ELF loader. For specific conversions, fixing this in objcopy itself is easy. But there is not much chance that such pragmatic patches will be accepted upstream. (http://sourceware.org/ml/binutils/2007-10/threads.html#00302) I have prepared a reduced (~680 LoC) version of objcopy with the PE-ELF fix added. To support build on non-ELF platforms, I would suggest to add this to the GRUB codebase. It can be later extended for other platforms if desired. I'm not sure what the GRUB maintainers will think, but I'm not very inclined to duplicate stuff that binutils already have. So am I. How about building binutils with --enable-targets=i386-elf ? Maybe the Cygwin maintainers would even add it as default. We could also have a configure check that aborts build when -m elf_i386 is not supported (which may also be a problem on pure-x86_64 environment!) and prompt user to rebuild binutils. That would be a nice check to have. -- Marco ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] generic ELF version of grub-mkimage
Robert Millan [EMAIL PROTECTED] writes: On Fri, Oct 12, 2007 at 05:55:03PM +0200, Robert Millan wrote: Ok. But no, I didn't really notice. I'll fix this entry and keep trying to get it right next time. Does this look good? Yes. -- Marco ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Fix eisa_mmap evaluation, add memory existence check
Robert Millan [EMAIL PROTECTED] writes: On Fri, Nov 09, 2007 at 10:53:23PM +0100, Christian Franke wrote: Ah, and why 0xcf instead of 0xff ? ... or 0xaa or 0x55. 0xaa and 0x55 are typicaly used directly in memory because every bit is negated, which is precisely what `^ 0xff' would do. Robert, can you take care of this patch? You have more expertise with this than I do :-) -- Marco ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Improving the website about GRUB 2 development
Robert Millan [EMAIL PROTECTED] writes: On Sat, Nov 10, 2007 at 07:19:34PM +0100, Marco Gerards wrote: If we put this on a website in a friendly and attractive way, we might get more contributions. Getting more contributions sounds nice; but can we cope with them? I think it's more important to make sure we can properly (and timely!) attend all the contributions we receive first. It would be easier to cope with them if econtributors know what to take care of. That can help in decreasing the delay we currently have in replying to patches. -- Marco ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Use getopt_long() instead of argp_parse() in grub-emu
Christian Franke [EMAIL PROTECTED] writes: Marco Gerards wrote: Christian Franke [EMAIL PROTECTED] writes: Unlike the other GRUB2 utils, grub-emu uses the glibc extension argp_parse(). It is unavailable on Cygwin, which might also be the case for other platforms where glibc is not the native runtime. This has been brought up before, BSD has the same problem. The outcome of the discussion was (IIRC) that we will use argp. When argp is not available we can use gnulib or a standalone argp parser (argp-standalone) to support this. In that case it will mean changing configure.ac. Will argp_parse() be a pre-requisite for building GRUB2 or will argp-standalone be included (some other projects do) ? Personally, I would prefer it if it could be used as an external library. The more we include, the more we need to care about. If you really want argp, why is it used only for the few trivial options of grub-emu ? The other utils still use getopt_long(). grub-emu does not benefit much from argp, but introduces another portability issue. It's what happened :-) Perhaps we should consider getopt_long, for now. It's one file to change... Does anyone else object? Otherwise I'll review this patch. -- Marco ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Fixed ieee1275 console
Marcin Kurek [EMAIL PROTECTED] writes: Hi, Can you provide something that makes use of that? Hmm, I should have example code somewhere on disk. I will try to find it. :-) Will do :-) I already send e-mail to fsf today as there was no reply to my previous e-mail. Great! -- Marco ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: serial port
Robert Millan wrote: On Sun, Nov 18, 2007 at 12:33:00PM +0100, Marco Gerards wrote: Robert Millan [EMAIL PROTECTED] writes: Perhaps because the serial command sets it up? Although I agree it seems a bit weird that it works this way. Perhaps it should be enabled with the same defaults from the beginning? One problem of initializing it is that hardware will be accessed, while it might not be desirable. Maybe we could move this to grub_term.init ? This way hardware is not accessed untill user requests a switch. This is the same way it works with gfxterm. You define video mode beforehand of the switch. But there is actually a one architectual issue here... How are we going to support graphical terminal and serial terminal at the same time? eg. allow user to enable multiple terminals... ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: serial port
On Sun, Nov 18, 2007 at 12:33:00PM +0100, Marco Gerards wrote: Robert Millan [EMAIL PROTECTED] writes: Hi, Any reason why the serial port is not enabled in grub_serial_init() ? grub terminal Available terminal(s): console Current terminal: console grub serial grub terminal Available terminal(s): serial console Current terminal: serial Perhaps because the serial command sets it up? Although I agree it seems a bit weird that it works this way. Perhaps it should be enabled with the same defaults from the beginning? One problem of initializing it is that hardware will be accessed, while it might not be desirable. Maybe we could move this to grub_term.init ? This way hardware is not accessed untill user requests a switch. -- Robert Millan GPLv2 I know my rights; I want my phone call! DRM What use is a phone call, if you are unable to speak? (as seen on /.) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] generic ELF version of grub-mkimage
On Sun, Nov 18, 2007 at 12:39:29PM +0100, Marco Gerards wrote: Robert Millan [EMAIL PROTECTED] writes: On Fri, Oct 12, 2007 at 05:55:03PM +0200, Robert Millan wrote: Ok. But no, I didn't really notice. I'll fix this entry and keep trying to get it right next time. Does this look good? Yes. Ok, fixed. -- Robert Millan GPLv2 I know my rights; I want my phone call! DRM What use is a phone call, if you are unable to speak? (as seen on /.) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: serial port
Robert Millan [EMAIL PROTECTED] writes: On Sun, Nov 18, 2007 at 12:33:00PM +0100, Marco Gerards wrote: Robert Millan [EMAIL PROTECTED] writes: Hi, Any reason why the serial port is not enabled in grub_serial_init() ? grub terminal Available terminal(s): console Current terminal: console grub serial grub terminal Available terminal(s): serial console Current terminal: serial Perhaps because the serial command sets it up? Although I agree it seems a bit weird that it works this way. Perhaps it should be enabled with the same defaults from the beginning? One problem of initializing it is that hardware will be accessed, while it might not be desirable. Maybe we could move this to grub_term.init ? This way hardware is not accessed untill user requests a switch. As long as it stays within serial.mod. Is that what you propose? -- Marco ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: objcopy fix (for x86_64)
Robert Millan [EMAIL PROTECTED] writes: This prevents objcopy from copying sections other than .text during the ./configure absolute address test. On i386, our conftest only has .text and .comment (which is skipped), but on x86_64 there's an additional .eh_frame section which isn't skipped unless you tell it to. Just one step further towards x86_64 grub ;-) Comments? -- Robert Millan GPLv2 I know my rights; I want my phone call! DRM What use is a phone call, if you are unable to speak? (as seen on /.) * aclocal.m4 (grub_PROG_OBJCOPY_ABSOLUTE): Pass `--only-section=.text' to objcopy. Looks fine to me. -- Marco ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: serial port
Robert Millan [EMAIL PROTECTED] writes: On Sun, Nov 18, 2007 at 02:12:59PM +0200, Vesa Jääskeläinen wrote: Robert Millan wrote: On Sun, Nov 18, 2007 at 12:33:00PM +0100, Marco Gerards wrote: Robert Millan [EMAIL PROTECTED] writes: Perhaps because the serial command sets it up? Although I agree it seems a bit weird that it works this way. Perhaps it should be enabled with the same defaults from the beginning? One problem of initializing it is that hardware will be accessed, while it might not be desirable. Maybe we could move this to grub_term.init ? This way hardware is not accessed untill user requests a switch. This is the same way it works with gfxterm. You define video mode beforehand of the switch. But there is actually a one architectual issue here... How are we going to support graphical terminal and serial terminal at the same time? eg. allow user to enable multiple terminals... For input or output? Both? IT would be a nice feature to have. -- Marco ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Layout testing for graphical menu
Vesa Jääskeläinen [EMAIL PROTECTED] writes: Hi, I was hoping that someone else might stand-up but as there wasn't really interest I made a draft. This is basically using Okuji's idea of using CSS for specifying look. I made HTML page and example CSS filling information. And of course it looks ugly as I didn't spent too much on tuning it. Actually, I am still hoping you are interested in working on this! :-) What is the state of the current framebuffer support? Are backgrounds, etc supported? I think I have a local copy that supports backgrounds. I was kinda waiting that new menu system would take over this. But I think new plan would be to do several iterations on it... so I might commit improved gfxterm that supports background (and is a bit faster, though needs more memory). Next iteration would be to replace this functionality with improved menu/themes. That version probably will not be backwards compatible with first iteration, but I think we can live with that. Who cares about backwards compatibility? ;-) I am looking forwards to your patches :-) -- Marco ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: serial port
On Sun, Nov 18, 2007 at 02:12:59PM +0200, Vesa Jääskeläinen wrote: Robert Millan wrote: On Sun, Nov 18, 2007 at 12:33:00PM +0100, Marco Gerards wrote: Robert Millan [EMAIL PROTECTED] writes: Perhaps because the serial command sets it up? Although I agree it seems a bit weird that it works this way. Perhaps it should be enabled with the same defaults from the beginning? One problem of initializing it is that hardware will be accessed, while it might not be desirable. Maybe we could move this to grub_term.init ? This way hardware is not accessed untill user requests a switch. This is the same way it works with gfxterm. You define video mode beforehand of the switch. But there is actually a one architectual issue here... How are we going to support graphical terminal and serial terminal at the same time? eg. allow user to enable multiple terminals... For input or output? -- Robert Millan GPLv2 I know my rights; I want my phone call! DRM What use is a phone call, if you are unable to speak? (as seen on /.) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Fix eisa_mmap evaluation, add memory existence check
On Sun, Nov 18, 2007 at 12:27:37PM +0100, Robert Millan wrote:
On Tue, Oct 23, 2007 at 09:06:16PM +0200, Christian Franke wrote:
+/* Check memory address */
+static int
+addr_is_valid (grub_addr_t addr)
+{
+ volatile unsigned char * p = (volatile unsigned char *)addr;
+ unsigned char x, y;
+ x = *p;
+ *p = x ^ 0xcf;
+ y = *p;
+ *p = x;
+ return y == (x ^ 0xcf);
+}
0xff would be better IMO.
Uhm actually, I just remembered that we have the ~ operator precisely for
that :-)
--
Robert Millan
GPLv2 I know my rights; I want my phone call!
DRM What use is a phone call, if you are unable to speak?
(as seen on /.)
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: serial port
Vesa Jääskeläinen [EMAIL PROTECTED] writes: Robert Millan wrote: On Sun, Nov 18, 2007 at 12:33:00PM +0100, Marco Gerards wrote: Robert Millan [EMAIL PROTECTED] writes: Perhaps because the serial command sets it up? Although I agree it seems a bit weird that it works this way. Perhaps it should be enabled with the same defaults from the beginning? One problem of initializing it is that hardware will be accessed, while it might not be desirable. Maybe we could move this to grub_term.init ? This way hardware is not accessed untill user requests a switch. This is the same way it works with gfxterm. You define video mode beforehand of the switch. But there is actually a one architectual issue here... How are we going to support graphical terminal and serial terminal at the same time? eg. allow user to enable multiple terminals... It's not possible yet. It would be a nice feature to have. The problem is that the sizes do not match. Should we use the smallest terminal? -- Marco ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: serial port
Marco Gerards wrote: Vesa Jääskeläinen [EMAIL PROTECTED] writes: This is the same way it works with gfxterm. You define video mode beforehand of the switch. But there is actually a one architectual issue here... How are we going to support graphical terminal and serial terminal at the same time? eg. allow user to enable multiple terminals... It's not possible yet. It would be a nice feature to have. The problem is that the sizes do not match. Should we use the smallest terminal? Or just completely different ones? For graphical menu I see that menu system would use different rendering method than text mode menu. Actually this is a requirement for graphical menu anyway. Different input methods could be merged after input translations has been completed. And separate output methods for specific terminal types? How this would work in reality I have not thought it yet. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Fixed ieee1275 console
Marcin Kurek [EMAIL PROTECTED] writes: Hi, I prefer if it can be detected if this is Efika or for example an apple implementation of OF and handle these characters depending on that. IIRC this code does work on the apple, but unfortunately I cannot check this anymore. Attached current console patchset. The graphical frames workaround is used only for SmartFirmware then Apple machines should get cp437 frames normaly. Sorry still no time to split it :( Anyway I will try to explain a bit each of them. Whoops, I almost missed this patch :-) Simple Console: Generaly it seems cp437 frames are used on pc, same for simple frames using '-' characters which are used for ncurses console and serial console on pc. I think keep same code in many places is not so good idea then I moved conversion rutines in to one place and introduce two term flags GRUB_TERM_SIMPLE_MENU and GRUB_TERM_CP437_MENU. In case when term has GRUB_TERM_SIMPLE_MENU set it would automaticly use '-' frames and same for GRUB_TERM_CP437_MENU to use cp437 frames. If no flags is set there would be no charset translation for frames. AFAIK it is not certain if it is CP437 that is used. This is just the case for PPC. Cosmetic: In general I see no reason to use multiple grub_ieee1275_write() calls if we can use single one. Nothing important, but good to have IMHO. Right, we can use this and always revert if it causes problems. Backspace: As I already wrote my version of OF seems to sent \b del sequence for backspace key. This change cause no side effects on Efika (USB keyboard) and Pegasos 1 with PS/2 keyboard. Can anyone check it on Apple OF ? In case of any troubles we can still use a IEEE1275 flag to use it only for SmartFw. Right. OFConsole: A biggest patch in pack. Generaly the grub console is completly broken here (Pegasos 1 2, Efika) The x/y cursor tracking not works as expect to and cursor position is random after few written lines. Right. Generaly I introduce realy working x/y position tracking and in result this give me a working console output in all cases (no random cursor position after 'ls' command, no empty screen after more than one output, etc) Great! Second change was detection of console type (serial, screen, framebuffer) The reason was to draw frames which looks good in all three. Default ofconsole uses now simple frames (same for serial console) and switch to cp437 frames if detect normal screen console, unfortunatly if of uses framebuffer mode (efika, unofficial OF upgrade for Pegasos 2) we can not use this frame type as framebuffer font lack required characters. The reason why framebuffer mode and serial mode are separated is planned vesa support as I already have a basic vesa framework we will be able to use it when finished (Then simple frames on serial console, cp437 on normal console and graphical frames on framebuffer) The PegasosII has VESA support!? This code uses some new flags: GRUB_IEEE1275_FLAG_NOFB_ROWS25: For some reason all versions of SF has 25 rows on normal console, but report only 24 which broke the grub console. This flag was added to workaround this problem. Weird... GRUB_IEEE1275_FLAG_NOCLS: Pegasos 1 OF seems to not interpret the cls escape then if detected we use \n workaround. Ok. GRUB_IEEE1275_FLAG_BPLAN_LOGO: Arghhh, we can use cp437 frames on pegasos, but it seems a parts of characters used by grub are replaced by bPlan logo. Use a workaround proposed here in this case and in a result have a nice looking grub menu on pegasos/efika too. Workaround as in using - to draw the menu? I hope I explain everything here. In another e-mail I attach rest of my patches for grub. Great! -- --- Marcin 'Morgoth' Kurek --- diff -urN grub2.org/include/grub/term.h grub2/include/grub/term.h --- grub2.org/include/grub/term.h 2007-07-22 01:32:22.0 +0200 +++ grub2/include/grub/term.h 2007-10-15 21:26:48.401210358 +0200 @@ -51,6 +51,10 @@ #define GRUB_TERM_NO_EDIT(1 1) /* Set when the terminal cannot do fancy things. */ #define GRUB_TERM_DUMB (1 2) +/* Set to use ascii menu borders. */ +#define GRUB_TERM_SIMPLE_MENU(1 3) +/* Set to use cp437 menu borders. */ +#define GRUB_TERM_CP437_MENU (1 4) Only the GRUB_TERM_SIMPLE_MENU flag should be sufficient, right? /* Set when the terminal needs to be initialized. */ #define GRUB_TERM_NEED_INIT (1 16) diff -urN grub2.org/kern/term.c grub2/kern/term.c --- grub2.org/kern/term.c 2007-07-22 01:32:26.0 +0200 +++ grub2/kern/term.c 2007-10-15 21:26:48.402210358 +0200 @@ -90,6 +90,94 @@ return grub_cur_term; } +static +grub_uint32_t remap_border(grub_uint32_t code) Please follow the same coding style as we do: the GCS. Return types are on a separate line, the ( is prefixed by a space. Thus: static grub_uint32_t remap_border (grub_uint32_t code) Remap is a somewhat confusing name. Perhaps something
Re: grub-setup: error: Non-sector-aligned data is found in the core file
On Nov 18, 2007 8:02 AM, Robert Millan [EMAIL PROTECTED] wrote: On Sun, Nov 11, 2007 at 02:47:21PM +0200, UrJiZ wrote: I just had the first success of loading grub from an Option ROM in qemu. I modified ROMOS code mostly just removing the disk emulation system and making it a simple core.img loader (the loading is a memory copy + setting dl to what the user has defined + jmp 0:8200h). I can post this code if someone is interested. Might be useful for us, but in that case... It is written in assembler, x86 intel syntax, compiled using nasm If you want that code in GRUB, it needs to be converted to ATT syntax. I'm not a real fan of gas and ATT syntax. I'll propably make this my project an external add-on which an user can download and extract to his grub2 directory, atleast if no-one is willing to do the conversion. (btw, can gas do incbin? ) ATM everything specific to this project is (on my computer) in a folder called romboot. and at the moment the rom checksum fixing is done by the same dos tool(romchk.exe) as for romos, Is romchk.exe free software? I don't know, but i rewrote it from scratch (only looking at it's textual output) to prevent using dosbox (didn't look at any source). Now i have both biosdisk and ata modules in the core, and the dl-register-based rootdisk detection just uses fd if dl 80h or hd if dl 80h. Having the possibility of selecting an ata drive via some special value of dl would be great, i was thinking of F0h = ata0 ... FFh = ata15 (although ata15 is not yet possible, but maybe possible in future). I don't understand. Isn't setting rootdisk in %dl a BIOS task? Or you changed that? Well, for an ISA Option ROM, bios doesn't provide any value for us (because the rom isn't really a booted device, bios would continue after the ROM executes RETF), the loader i wrote can choose this arbitarily. As background, ISA Option ROM's were used for example in SCSI controllers to provide bios disk services for scsi disks, etc. Also, I'm not sure of this, but it seems that the ata driver blocks out the hd*-devices and i understand this, but it also blocks fd*-devices and this is something i don't really understand, I'd really like to access both cdrom's and floppy disks. ata and biosdisk can't really coexist. The block is just there to prevent undefined results. You probably just want to only load biosdisk and discard the ata module for now. Well, I prefer to dump the biosdisk module instead of ata. A native floppy disk driver would be great. And for the including of files in core.img, all i really need is a way to include grub.cfg in there so that my ROM grub can display a menu even without a root disk. I would be willing to attempt to work on this, but i'd like to hear some suggestions/specification of how it should be done (eq in what layer of grub, whether to have only grub.cfg possible or to be able to have an entire filesystem (will propably take more time for me), etc..). My idea is to allow grub-mkimage to include an image (at least one) with arbitrary content, which will later be dumped in memory. Then make sure the runtime module loader won't attempt to treat it as a module, and find a way to locate it in memory. At that point, it's as simple as writing a disk/ driver that just maps accesses to that memory region. Then of course, the image would normally contain a filesystem, with anything grub might need (grub.cfg, unifont.pff, ...). I played around and got a menu-only solution ready, but I'm not happy about it (more a hack than a real solution). Modified init.c to map dl=0x10 = (host) and made a fs driver called cfgfs (from hostfs.c) that provides only static /boot/grub/grub.cfg. Added host disk driver and cfgfs fs driver to the build and now i can get a menu. What i'm worried about in your solution is that the overhead of any fs image (several sectors) in core.img would make me drop many useful modules. (64k of space) Of course, this would be very useful for any other type of loading. (real diskette, netbooting (could carry kernel and initrd over network withing core.img), etc...) -- urjaman ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] Make make dist create proper tarballs again
I did not attach DISTLIST patch. I believe that file should be removed and added to .cvsignore. -- Lubomir Kundrak (Red Hat Security Response Team) Index: ChangeLog === RCS file: /sources/grub/grub2/ChangeLog,v retrieving revision 1.450 diff -u -p -r1.450 ChangeLog --- ChangeLog 18 Nov 2007 11:54:12 - 1.450 +++ ChangeLog 18 Nov 2007 17:48:21 - @@ -1,3 +1,6 @@ +2007-11-18 Lubomir Kundrak [EMAIL PROTECTED] + * gendistlist.sh: Make make dist work again + 2007-11-18 Christian Franke [EMAIL PROTECTED] * util/console.c (grub_ncurses_getkey): Change curses KEY_* mapping, Index: gendistlist.sh === RCS file: /sources/grub/grub2/gendistlist.sh,v retrieving revision 1.2 diff -u -p -r1.2 gendistlist.sh --- gendistlist.sh 22 Aug 2005 17:28:59 - 1.2 +++ gendistlist.sh 18 Nov 2007 17:48:22 - @@ -17,7 +17,10 @@ EXTRA_DISTFILES=AUTHORS COPYING ChangeL THANKS TODO Makefile.in aclocal.m4 autogen.sh config.guess \ config.h.in config.sub configure configure.ac gencmdlist.sh \ gendistlist.sh genfslist.sh genkernsyms.sh genmk.rb \ - genmodsrc.sh gensymlist.sh install-sh mkinstalldirs stamp-h.in + genmodsrc.sh gensymlist.sh install-sh mkinstalldirs stamp-h.in \ + geninitheader.sh geninit.sh genkernsyms.sh.in genmoddep.awk \ + gensymlist.sh.in + DISTDIRS=boot commands conf disk font fs hello include io kern loader \ normal partmap term util video @@ -32,7 +35,7 @@ cd $dir for dir in $DISTDIRS; do for d in `find $dir -type d | sort`; do find $d -maxdepth 1 -name '*.[chS]' -o -name '*.mk' -o -name '*.rmk' \ - -o -name '*.rb' -o -name '*.in' \ + -o -name '*.rb' -o -name '*.in' -o -name '*.y' -o -name 'README' \ | sort done done ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub2 efi patches
Hello,
Sorry for not replying earlier, I'm currently busy trying to figure out how to
access the Compatibility Support Module, and possibly enable lecagy boot.
Le Sat, Nov 10, 2007 at 04:45:43PM +0100, Marco Gerards a écrit :
Alexandre Boeglin [EMAIL PROTECTED] writes:
grub2_efi_grub_prefix.patch uses the grub_prefix variable to set the prefix
environment variable, instead of the directory in which grub.efi is. This
allows to have grub.efi and the modules in different folders, and the old
behaviour should be preserved, if the grub_prefix is an empty string,
How about passing it as an argument to GRUB 2? I assume EFI can do
this? This is what we do on open firmware, IIRC.
Well, this should also work if grub is the main bootloader of your machine,
but I think it would be a bit harder in the case you have grub on a EFI
bootable CD or USB stick (or that would depend on the primary bootloader in
this case). But actually, I don't know this part very well ...
I also still have to clean the chainloader options patch, but here is the
changelog for the others:
2007-11-18 Alexandre Boeglin [EMAIL PROTECTED]
* normal/arg.c (grub_arg_parse): If one of the args is --, add remaining
N args, instead of -- N times.
* commands/i386/efi/halt.c: New file.
* commands/i386/efi/reboot.c: New file.
* conf/i386-efi.rmk (grub_emu_SOURCES): Replace i386/pc/halt.c and reboot.c by
i386/efi/halt.c and reboot.c.
(grub_install_SOURCES): Add halt.mod and reboot.mod.
(halt_mod_SOURCES): New variable.
(halt_mod_CFLAGS): Likewise.
(halt_mod_LDFLAGS): Likewise.
(reboot_mod_SOURCES): Likewise.
(reboot_mod_CFLAGS): Likewise.
(reboot_mod_LDFLAGS): Likewise.
* include/grub/efi/efi.h (grub_reboot): New function declaration.
(grub_halt): Likewise.
* kern/efi/efi.c (grub_reboot): New function.
(grub_halt): Likewise.
And I just received the copyright assignment papers yesterday. I will post
them on monday.
Regards,
Alex
Index: normal/arg.c
===
RCS file: /sources/grub/grub2/normal/arg.c,v
retrieving revision 1.7
diff -u -p -r1.7 arg.c
--- normal/arg.c 21 Jul 2007 23:32:28 - 1.7
+++ normal/arg.c 18 Nov 2007 15:12:05 -
@@ -313,7 +313,7 @@ grub_arg_parse (grub_command_t cmd, int
if (grub_strlen (arg) == 2)
{
for (curarg++; curarg argc; curarg++)
- if (add_arg (arg) != 0)
+ if (add_arg (argv[curarg]) != 0)
goto fail;
break;
}
Index: commands/i386/efi/halt.c
===
RCS file: commands/i386/efi/halt.c
diff -N commands/i386/efi/halt.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ commands/i386/efi/halt.c 18 Nov 2007 17:49:37 -
@@ -0,0 +1,47 @@
+/* halt.c - command to halt the computer. */
+/*
+ * GRUB -- GRand Unified Bootloader
+ * Copyright (C) 2005,2007 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 http://www.gnu.org/licenses/.
+ */
+
+#include grub/normal.h
+#include grub/dl.h
+#include grub/arg.h
+#include grub/efi/efi.h
+
+static grub_err_t
+grub_cmd_halt (struct grub_arg_list *state __attribute__ ((unused)),
+ int argc __attribute__ ((unused)),
+ char **args __attribute__ ((unused)))
+
+{
+ grub_halt ();
+ return 0;
+}
+
+
+
+GRUB_MOD_INIT(halt)
+{
+ (void)mod; /* To stop warning. */
+ grub_register_command (halt, grub_cmd_halt, GRUB_COMMAND_FLAG_BOTH,
+ halt, Halt the computer, 0);
+}
+
+GRUB_MOD_FINI(halt)
+{
+ grub_unregister_command (halt);
+}
Index: commands/i386/efi/reboot.c
===
RCS file: commands/i386/efi/reboot.c
diff -N commands/i386/efi/reboot.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ commands/i386/efi/reboot.c 18 Nov 2007 17:49:37 -
@@ -0,0 +1,47 @@
+/* reboot.c - command to reboot the computer. */
+/*
+ * GRUB -- GRand Unified Bootloader
+ * Copyright (C) 2005,2007 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
Re: [PATCH] Use getopt_long() instead of argp_parse() in grub-emu
Marco Gerards wrote: Christian Franke ... writes: ... Will argp_parse() be a pre-requisite for building GRUB2 or will argp-standalone be included (some other projects do) ? Personally, I would prefer it if it could be used as an external library. The more we include, the more we need to care about. Yes, but then future package maintainers will have fewer portability issues to care about :-) If you really want argp, why is it used only for the few trivial options of grub-emu ? The other utils still use getopt_long(). grub-emu does not benefit much from argp, but introduces another portability issue. It's what happened :-) Perhaps we should consider getopt_long, for now. It's one file to change... Does anyone else object? Otherwise I'll review this patch. I would appreciate this. Christian ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] mkdevicemap for Cygwin
Marco Gerards wrote: Christian Franke [EMAIL PROTECTED] writes: Some changes for grub-mkdevicemap on Cygwin. Christian 2007-11-13 Christian Franke [EMAIL PROTECTED] * util/grub-mkdevicemap.c (get_floppy_disk_name): Add Cygwin device names. (get_ide_disk_name): Disable on __CYGWIN__. [__CYGWIN__] (get_ide_disk_name): Disable. (get_scsi_disk_name): Add Cygwin device names. (check_device): Add static. Return error instead of success on empty string. Can you explain this? Does this break something on GNU/Linux? See last mail. Should not break GNU/Linux, because (*name = 0) is not used then. (make_device_map): Disable IDE loop on __CYGWIN__. [__CYGWIN__] (make_device_map): Disable IDE loop. Move label inside linux specific code to prevent compiler warning. (make_device_map): Move label inside linux specific code to prevent compiler warning. Otherwise fine, so this can be committed if there aren't any other problems with this patch. Thanks, new changelog below. Christian 2007-11-18 Christian Franke [EMAIL PROTECTED] * util/grub-mkdevicemap.c (get_floppy_disk_name): Add Cygwin device names. [__CYGWIN__] (get_ide_disk_name): Disable. (get_scsi_disk_name): Add Cygwin device names. (check_device): Add static. Return error instead of success on empty string. [__CYGWIN__] (make_device_map): Disable IDE loop. (make_device_map): Move label inside linux specific code to prevent compiler warning. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] mkdevicemap for Cygwin
Robert Millan wrote:
On Tue, Nov 13, 2007 at 09:42:26PM +0100, Christian Franke wrote:
+#elif defined(__CYGWIN__)
+ /* Cygwin */
+ sprintf (name, /dev/fd%d, unit);
Cygwin has /dev now? :-)
At least since 2003.
+#ifndef __CYGWIN__
static void
get_ide_disk_name (char *name, int unit)
{
@@ -213,6 +217,7 @@ get_ide_disk_name (char *name, int unit)
*name = 0;
#endif
}
+#endif /* __CYGWIN__ */
[...]
+#ifndef __CYGWIN__
/* IDE disks. */
for (i = 0; i 8; i++)
{
@@ -431,6 +440,7 @@ make_device_map (const char *device_map,
num_hd++;
}
}
+#endif /* __CYGWIN__ */
Is the generic case (`*name = 0', then print that) good enough?
No, it did not work because check_device() returned 1 (exists) on
(*name == 0). This results in 8 bogus (hd N)\t\n lines and wrong N for
the real devices.
Yes, it would work now, because the patch also fixes this bug :-)
Christian
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Handle C symbols with leading underscore (HAVE_ASM_USCORE)
Robert Millan wrote: diff -rup grub2.orig/kern/dl.c grub2/kern/dl.c --- grub2.orig/kern/dl.c2007-07-22 01:32:26.0 +0200 +++ grub2/kern/dl.c 2007-11-11 18:01:50.578125000 +0100 @@ -53,6 +53,12 @@ typedef Elf64_Sym Elf_Sym; #endif +#ifdef HAVE_ASM_USCORE +# define SYM_USCORE _ +#else +# define SYM_USCORE +#endif Should this be global? We already have START_SYMBOL and END_SYMBOL. Perhaps this should be next to them? START_SYMBOL and END_SYMBOL are in config.h. SYM_USCORE is derived from a config.h symbol and therefore cannot be placed there without changing configure.ac. The symbol is (and likely will be) only used once, so it IMO makes no sense to declare it non-locally. Christian ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: serial port
Vesa Jääskeläinen wrote: Robert Millan wrote: On Sun, Nov 18, 2007 at 12:33:00PM +0100, Marco Gerards wrote: Robert Millan [EMAIL PROTECTED] writes: Perhaps because the serial command sets it up? Although I agree it seems a bit weird that it works this way. Perhaps it should be enabled with the same defaults from the beginning? One problem of initializing it is that hardware will be accessed, while it might not be desirable. Maybe we could move this to grub_term.init ? This way hardware is not accessed untill user requests a switch. This is the same way it works with gfxterm. You define video mode beforehand of the switch. But there is actually a one architectual issue here... How are we going to support graphical terminal and serial terminal at the same time? eg. allow user to enable multiple terminals... ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel Just thought I'd put my two cents in to this discussion, I'm not really planning on contributing code to Grub 2, though I might help stimulate discussion... If you wanted to enable both serial and graphical terminals (or any other kind(s) of terminals, just that there are more than one enabled at once), you'd really have to switch to using the Model/View/Controller architecture for user interaction. However there is also the difficulty that when you have two separate terminals into the same session (or whatever else you want to think of), that might become a security issue. Just my two cents on this matter. Hope this helps (though it might not), Daryl Van Humbeck. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
