Re: grub-dumpbios
On 04.05.2009 21:27 Uhr, Robert Millan wrote:
Hi,
Do we really need to ship a specific utility just to run two commands?
dd if=/dev/mem of=${output_dir}vbios.bin bs=65536 skip=12 count=1
dd if=/dev/mem of=${output_dir}int10.bin bs=4 skip=16 count=1
Sounds like user will need to read some documentation in order to figure
out what grub-dumpbios is good for, and what to do with those files, so
why not just document the commands there instead? (e.g. in the wiki or
so)
As a side note: On many machines dumping the VGA option rom like that
does not produce good option rom images. Many option roms are
self-modifying and the above method only dumps the modified variants of
the ROMs that are normally not good for POSTing a graphics card
anymore. They're still good for other purposes though I guess.
Stefan
--
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: i...@coresystems.de • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Dell Media Direct button
Robert Millan wrote: On Wed, Aug 20, 2008 at 10:57:22AM +0200, Per Öberg wrote: Hi Some laptops, e.g., from Dell have a special button that they use to boot a special embedded OS for media only instead of the ordinary OS. For my Dell XPS1330M I can determine if the Media button was pressed by first writing 0xf9 to port 0x70 and then testing bit 0x08 of port 0x71. It would be really nice if such a test could be enabled in grub so that grub can go directly to a specific menu alternative without showing the gui if the media button was pressed. Is this interesting? I'd like to contribute but I don't know where to start. Sounds interesting, but this needs some thought on how to design it. I suppose what you want is change the 'default' variable. Perhaps increase it by 1? But then, where do you do this? grub_machine_init is too early as 'default' hasn't been set yet. Maybe we could have a global 'int default_offset' variable that is initialized in grub_machine_init and later on used by normal.mod? The sequence of writing to port 0x70 / reading from port 0x71 reflects reading from the computer's cmos nvram memory. bit 7 of 0x70 is reserved for disabling NMIs, so the actual information is stored in byte 0x79[8] in the cmos. To allow full flexibility, there should just be a module that allows reading / writing the cmos values (could also be useful for other things, such as reading a boot order set by the bios). Everything else makes more sense in scripting: - changing default - changing timeout - support for bit operations in the parser - etc... -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: [EMAIL PROTECTED] • http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg • HRB 7656 Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] cleanup in EFI Linux loader
Robert Millan wrote: On Sun, Aug 17, 2008 at 10:35:38PM +0200, Robert Millan wrote: - grub_printf ( [Linux-EFI, setup=0x%x, size=0x%x]\n, + grub_printf ( [Linux, setup=0x%x, size=0x%x]\n, I looked at the other Linux loaders, and to be consistent this would have to be Linux-bzImage instead. I propose using that then What about printing the Linux version number there? -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: [EMAIL PROTECTED] • http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg • HRB 7656 Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: slight oddity in script parser
Bean wrote: On Fri, Aug 1, 2008 at 7:48 AM, Patrick Georgi [EMAIL PROTECTED] wrote: Hi, I forgot this, so sorry for the separate mail: Currently, the parser expects comments to start at the beginning of the line, so ls /foo # necessary because of baz doesn't work properly I think a good scenario would be to have comments start either on # at pos0, or on #. This way, ls /foo#bar continues to work. Also, currently the following is a single comment, which is an unusual feature: # this comment starts here\ and continues on this line Hi, Actually, # and \ is handled in the read line function, it can't handle complicated situation. Are you implying it is wrong there and should be moved to the parser? -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: [EMAIL PROTECTED] • http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg • HRB 7656 Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: slight oddity in script parser
Bean wrote: On Fri, Aug 1, 2008 at 12:26 PM, Stefan Reinauer [EMAIL PROTECTED] wrote: Bean wrote: On Fri, Aug 1, 2008 at 7:48 AM, Patrick Georgi [EMAIL PROTECTED] wrote: Hi, I forgot this, so sorry for the separate mail: Currently, the parser expects comments to start at the beginning of the line, so ls /foo # necessary because of baz doesn't work properly I think a good scenario would be to have comments start either on # at pos0, or on #. This way, ls /foo#bar continues to work. Also, currently the following is a single comment, which is an unusual feature: # this comment starts here\ and continues on this line Hi, Actually, # and \ is handled in the read line function, it can't handle complicated situation. Are you implying it is wrong there and should be moved to the parser? Hi, In theory, it should be handled by the lexer. but actually, it's not so easy. lexer already has some issue, adding new handling would not help. So, what's the right way to fix it, then? -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: [EMAIL PROTECTED] • http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg • HRB 7656 Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Idea: elimination of the normal mode
Robert Millan wrote: About the duplicated commands, we can create a module minicmd to include the most basic command Then we can't have a rescue shell before heap is initialised and minicmd is loaded. Should we be concerned about this? What would one use that rescue shell for? -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: [EMAIL PROTECTED] • http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg • HRB 7656 Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Idea: elimination of the normal mode
Vesa Jääskeläinen wrote: Stefan Reinauer wrote: Robert Millan wrote: About the duplicated commands, we can create a module minicmd to include the most basic command Then we can't have a rescue shell before heap is initialised and minicmd is loaded. Should we be concerned about this? What would one use that rescue shell for? Idea of the rescue shell is load other modules in case grub itself cannot find them. It provides thin layer of tools so user is able to find them. Personally I would like to keep this functionality in core.img. So, how is the rescue shell different that grub itself. Why would it find modules that grub itself does not find? Stefan -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: [EMAIL PROTECTED] • http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg • HRB 7656 Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Idea: elimination of the normal mode
Vesa Jääskeläinen wrote: Stefan Reinauer wrote: Vesa Jääskeläinen wrote: Idea of the rescue shell is load other modules in case grub itself cannot find them. It provides thin layer of tools so user is able to find them. Personally I would like to keep this functionality in core.img. So, how is the rescue shell different that grub itself. Why would it find modules that grub itself does not find? User can use ls and insmod commands to load those modules from disk. Most common problem with GRUB legacy is that it just prints GRUB on screen. This will kinda remove that problem as user still has a way to boot his system with some keypresses. So the rescue shell has filesystems and a shell? Is the advanced console interface so huge that it can't live with the shell and the filesystems in the rescue shell? -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: [EMAIL PROTECTED] • http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg • HRB 7656 Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Tidy up 'make' output
Robert Millan wrote: On Tue, Jun 17, 2008 at 10:44:48AM -0700, Colin D Bennett wrote: with output that, in my opinion, makes it easier to see warnings and errors: COMPILE ../util/getroot.c COMPILE ../kern/device.c ../kern/device.c: In function 'grub_device_iterate': ../kern/device.c:84: warning: generating trampoline in object (requires executable stack) ../kern/device.c:84: warning: generating trampoline in object (requires executable stack) COMPILE ../kern/disk.c COMPILE ../kern/err.c COMPILE ../kern/misc.c I don't like the idea of hiding information this way. If the goal is to catch warnings, I think -Werror can do a much better job (and catching errors shouldn't be a problem unless you're using make -j or -k). I would not consider this hiding information. The information you see (CFLAGS for example) don't really change across the lines and there's always the chance to say V=1 to see all the compiler lines. The opposite: The current forest of duplicate information is really what is hiding the relevant information between a lot of uninteresting fuzz. Maybe, you guys would prefer to set V=1 as the default, so one would have to say V=0 to get above output? I am currently only compiling grub with make -s, because that is the only way to get any decently parsable output for finding issues in the code. Please, please, don't use -Werror. GRUB2 is currently hard enough to build and the build system is less than optimal and elegant. While I agree that clean code never throughs warnings, the amazing number of different gccs and build environments out there would make developing for grub2 and compiling it very hard. There are quite a number of warnings that do not matter because the developers simply know better than the compiler. -Werror will lead to ugly workarounds to suppress these warnings and make adoption of new tool chain versions a task from hell. Stefan -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: [EMAIL PROTECTED] • http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg • HRB 7656 Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Floating point usage
Robert Millan wrote: Why would i386-linuxbios and i386-ieee1275 need libgcc but i386-pc don't? IIRC the tendency is that CISC platforms tend not to need libgcc for floating point but RISC ones do. Did I make a mistake on these two ports? Those platforms require libgcc even for double precision integer divisions. It's a bit nasty. -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: [EMAIL PROTECTED] • http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg • HRB 7656 Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] ELF program header
* Robert Millan [EMAIL PROTECTED] [071014 14:00]:
We tried the same but the patch was a lot bigger, trying to actually
leave space in the beginning. Your patch might be enough, that would be
really nice.
That's the question. Do we really have to add more space, or is that space
already allocated for us?
Ok, I am not exactly sure how to correctly adapt to the latest
grub-mkimage changes, so please bear that the attached patch is against
Patrick's GSoC version of grub-mkimage.c
With this patch attached, grub-mkimage produces an image that works when
being loaded as payload from LinuxBIOS version 2.
Your smaller version of the patch unfortunately did not work for me.
Flames and suggestions please!
Best wishes,
Stefan
--- grub-mkimage.c.orig 2007-10-05 20:33:50.0 +
+++ grub-mkimage.c 2007-10-15 18:20:03.0 +
@@ -104,7 +104,7 @@
FILE *in;
char *kernel_path;
grub_addr_t grub_end = 0;
- off_t phdroff;
+ off_t phdroff, pstart;
int i;
/* Read ELF header. */
@@ -115,18 +115,27 @@
grub_util_read_at (ehdr, sizeof (ehdr), 0, in);
+ /* The +1 is to leave a hole for the program header for extra modules. */
phdrs = xmalloc (grub_le_to_cpu16 (ehdr.e_phentsize)
- * (grub_le_to_cpu16 (ehdr.e_phnum) + 2));
+ * (grub_le_to_cpu16 (ehdr.e_phnum) + 1));
+
+ /* Append entire segment table to the file. */
+ //phdroff = ALIGN_UP (grub_util_get_fp_size (out), sizeof (long));
+ phdroff = ALIGN_UP (sizeof(ehdr), sizeof (long));
+ grub_util_write_image_at (phdrs, grub_le_to_cpu16 (ehdr.e_phentsize)
+ *(grub_le_to_cpu16 (ehdr.e_phnum) + 1), phdroff,
+ out);
+
/* Copy all existing segments. */
grub_util_info (%u segments, grub_le_to_cpu16 (ehdr.e_phnum));
+ pstart = grub_util_get_fp_size (out);
+ /* set up first phdr offset */
for (i = 0; i grub_le_to_cpu16 (ehdr.e_phnum); i++)
{
char *segment_img;
grub_size_t segment_end;
-
phdr = phdrs + i;
-
- /* Read segment header. */
+ /* Read segment header. */
grub_util_read_at (phdr, sizeof (Elf32_Phdr),
(grub_le_to_cpu32 (ehdr.e_phoff)
+ (i * grub_le_to_cpu16 (ehdr.e_phentsize))),
@@ -146,9 +155,11 @@
grub_util_read_at (segment_img, grub_le_to_cpu32 (phdr-p_filesz),
grub_le_to_cpu32 (phdr-p_offset), in);
- grub_util_write_image_at (segment_img, grub_le_to_cpu32 (phdr-p_filesz),
+ phdr-p_offset = grub_cpu_to_le32(pstart);
+ grub_util_write_image_at (segment_img, grub_le_to_cpu32 (phdr-p_filesz),
grub_le_to_cpu32 (phdr-p_offset), out);
+ pstart += phdr-p_filesz;
free (segment_img);
}
@@ -176,9 +187,9 @@
ehdr.e_shstrndx = 0;
/* Append entire segment table to the file. */
- phdroff = ALIGN_UP (grub_util_get_fp_size (out), sizeof (long));
+ // phdroff = ALIGN_UP (grub_util_get_fp_size (out), sizeof (long));
grub_util_write_image_at (phdrs, grub_le_to_cpu16 (ehdr.e_phentsize)
- * grub_le_to_cpu16 (ehdr.e_phnum), phdroff,
+ * (grub_le_to_cpu16 (ehdr.e_phnum)), phdroff,
out);
/* Write ELF header. */
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] ELF program header
* Robert Millan [EMAIL PROTECTED] [071012 18:19]: It seems that grub-mkimage generates awkward ELF files, in which the Program header table is at the end of the file instead of right after the ELF header. - Our own ELF loader doesn't like phdroff 0x2000 either, from loader/i386/pc/multiboot.c: I think such a fixed address makes little sense, however there are reasons to put the phdr in front. /* FIXME: Should we support program headers at strange locations? */ if (ehdr-e_phoff + ehdr-e_phnum * ehdr-e_phentsize MULTIBOOT_SEARCH) return grub_error (GRUB_ERR_BAD_OS, program header at a too high offset); This breaks self-boot in the LinuxBIOS target. Moving the Program header (see attached patch) fixed it, with no apparent drawbacks or regressions in any of the ELF loaders around (tested on LinuxBIOS ELF loader and Efika OF). I assume this was with LinuxBIOSv3 and Qemu? I'm not completely sure of its correctness though, and would appreciate if someone with a better understanding of ELF can comment on it. There's one good reason to put ELF headers in the beginning, that is streaming of ELF files. If you get your ELF from a streaming decompression algorithm you have to - either copy your elf to memory completely before loading it a second time - or decompress it twice - or you put the phdr in the beginning :-) I don't know if my proposed solution could overwrite valid data. Are the segments garanteed to always leave room for the program header, do we have to explicitly check for that, or perhaps we need to relocate the segments when needed? We tried the same but the patch was a lot bigger, trying to actually leave space in the beginning. Your patch might be enough, that would be really nice. I didn't really get the sense behind the layers of grub magic around read() and write(). Looking at the code, it looks completely wrong, but it surprisingly seemed to work in LBv3. /* Append entire segment table to the file. */ - phdroff = ALIGN_UP (grub_util_get_fp_size (out), sizeof (long)); + phdroff = ALIGN_UP (sizeof (ehdr), sizeof (long)); grub_util_write_image_at (phdrs, grub_target_to_host16 (ehdr.e_phentsize) * grub_target_to_host16 (ehdr.e_phnum), phdroff, out); Stefan -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: [EMAIL PROTECTED] • http://www.coresystems.de/ ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] [PATCH] Add multiboot 2 capabilities
* Marco Gerards [EMAIL PROTECTED] [070725 11:53]: Jerone Young [EMAIL PROTECTED] writes: I'm going to submit a new patch shortly. I'll also check it in. So it will not suffer from code rot :-) Need to make sure some stuff works on ppc then it'll be in. Probably tonight or tomorrow. Great to have multiboot2! Having multiboot2 on the PPC was actually the main reason I started working on GRUB 2 in the first place. You didn't leave me much time to go over it ;-). Do you want me to review it so you can fix up the GCS issues in CVS or did you take care of these issues already? :-) Will grub2 still be able to boot multiboot(1) binaries on x86? Stefan -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: [EMAIL PROTECTED] • http://www.coresystems.de/ ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GPL version 3
* Yoshinori K. Okuji [EMAIL PROTECTED] [070704 21:40]: Hello, I would like to discuss the possibility of migrating to GPL version 3. As you know, GPLv3 has been published, and all GNU software is recommended to migrate from GPLv2 to GPLv3. [..] 1. What are the pros and cons? A discussion as you call it should contain those, while your post clearly did not. 2. Since all people have to sign over their (C) to the FSF in a GNU project, can't the FSF just decide a switch to GPL3 at any time? (If not, what good would such a sign-over of rights be?) Sorry if those are considered stupid or aggravating questions, but I figured a license change is not something that you do easily, such as updating to a newer version of some software, as it includes putting yourself out, vulnerable not to an army of hackers but an army of lawyers. It has to be considered very carefully. Stefan. -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: [EMAIL PROTECTED] • http://www.coresystems.de/ ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GPL version 3
* Jeroen Dekkers [EMAIL PROTECTED] [070704 23:10]: Are you sure about this? Given that we've assigned copyright to the FSF, the FSF can decide under which free software license to license that code. So I don't really see why we can't release the same code under GPLv2 or later in GRUB Legacy and under GPLv3 or later in GRUB2. Oh the v2 or later and v3 or later clauses are more than critical from a lawyers view. How can you have a contract partner and the FSF decide upon the license / contract that applies on your code without that contract existing yet. If, at some point in the future the FSF would decide to add a clause to GPLv4 The author of this software pays a monthly fee of US$100 to the FSF and the user of this software decides to apply GPLv4 to the software because the author allowed it, you would have to pay. The GPL is clearly designed to be a license that protects the _user_ not the _author_ of a given piece of software. No, of course I do not believe that the FSF will ever do something like the above. But law is not about beliefs. Stefan -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: [EMAIL PROTECTED] • http://www.coresystems.de/ ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: PowerMac hack breaks Efika
* Robert Millan [EMAIL PROTECTED] [070702 10:17]: The following lines in grub_ofconsole_init(): /* The latest PowerMacs don't actually initialize the screen for us, so we * use this trick to re-open the output device. */ grub_ieee1275_interpret (output-device output, 0); break Efika (SmartFirmware) and possibly other implementations. After this command is run, all console output is supressed. I'm not sure why (found that via regression test), but on Efika the output-device is screen (/[EMAIL PROTECTED]/[EMAIL PROTECTED]). Can you examine the output property of the /chosen node and see what its original vallue is? I suppose the right fix would be to check for PowerMacs before running this, but I'm not sure how. Any ideas? There's some property in the / or /cpu or /openprom noe that can be used. Don't have a ppc machine from Apple here right now. Why does Apple Powerbook need this? What's their default output device? Stefan -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: [EMAIL PROTECTED] • http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg • HRB 7656 Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: 64 Bit Support?
* Robert Millan [EMAIL PROTECTED] [070617 11:26]: On Sun, Jun 17, 2007 at 02:16:41AM +0200, Jeroen Dekkers wrote: At Sun, 17 Jun 2007 17:11:44 -0600, David Broadfoot wrote: I am wondering if there is plans for Grub 2 to be able to be compiled and run in a 64 bit enviroment. I am a part of the Cross-LFS Dev. team, and Under the pure 64 bit system, we have to use a 32 static version of grub compiled on a 32 computer in order to get it to boot, or use *Cough* lilo. Thanks for your time Interesting would also be to boot pure 64bit kernels. I think some of the BSDs have their bootloader switch to 64bit long mode, so the kernel does not have to dot this anymore. Maybe grub could do the same thing. -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: [EMAIL PROTECTED] • http://www.coresystems.de/ ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: 64 Bit Support?
* Jeroen Dekkers [EMAIL PROTECTED] [070617 13:03]: Interesting would also be to boot pure 64bit kernels. I think some of the BSDs have their bootloader switch to 64bit long mode, so the kernel does not have to dot this anymore. Maybe grub could do the same thing. To enable long mode you have to enable paging and I don't think the bootloader should be doing things like that. I also don't see any problems with the OS enabling long mode. Yes, enabling long mode is overly complex and was not well designed, imho. So I partly agree. We considered enabling long mode in LinuxBIOS a while ago, to avoid the same old cruft situation like with 16bit BIOS and 32bit OS. But you can not enable long mode without a huge amount of overhead (ie. paging), so it can only be done when the RAM controller is enabled and RAM is working. By that time accessing 64bit address space has already become a lot less interesting for the boot firmware. So the next place where it would make sense at all is in the bootloader. The problem might be that Grub2 locks out existing operating systems, if it does not support switching to long mode itself. I read rumours only, so I might be completely wrong. Is anyone booting non-Linux OSes like FreeBSD, NetBSD, OpenBSD, OpenSolaris, etc with GRUB2 yet? Stefan -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: [EMAIL PROTECTED] • http://www.coresystems.de/ ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Feature Request: Alpha-Linux support.. possible?
* Brian Evans [EMAIL PROTECTED] [070615 18:38]: The current DEC Alpha boot loaders MILO and aboot are unmaintained and frequently break with newer tool chains and kernels. I have a machine for aboot, but I don't have a machine for MILO anymore. MILO is still up and running on http://milo.coresystems.de/ but I had no requests for changes in several years now. How hard would it be to add Alpha to Grub-2? It'd probably be a lot easier to add support for SRM based systems than for AlphaBIOS/ARCS based systems since those are using a 32bit PAL code, effectively making the machine a 32bit machine on the BIOS level. The workaround is to load 64bit PAL codes, such as those found in SRM or MILO. The draw back is that you can not use BIOS callbacks anymore after switching the PAL code so you have to provide your own SCSI drivers for each controller. Hence MILO was married with the Linux kernel in a more than unnatural way. One possible scenario however: 1. Get the latest SRM PAL codes for all machines supported by MILO (MILOs PAL codes suck!) 2. Strip down MILO so it does not link against the kernel at all anymore. I know Nikita worked on that a long time ago and I removed that stuff. I had to learn the hard way that this was a mistake 3. Patch Linload.exe/Loadlin.exe to load MILO plus a Kernel plus an initrd from the DOS partition. Jay, do you have the sources for the Ruffian loader? Is it still closed up? Could we change it and recompile it? 4. Have MILO start the Linux kernel from RAM loaded by 3. 5. Use kexec and whatever neat userspace utility to load the real Kernel from disk. Or just write the real kernel to the DOS partition and load it from there with no kexec in the game. The big problem that kept me from trying that is that you need the AlphaBIOS SDK (?) installed on a Windows box to patch loadlin.exe/linload.exe and you need an (Alpha?) Windows box for that which I did not have at the time. However, I do have an Alpha box to test with (read: break). SRM? Alpha BIOS? Although the Alpha platform is no longer producing any new machines, many exist as servers or workstations and could be reused as Linux machines. I want to revive mine, too, but I think I gave my Permedia2 card away by accident and I dont have a supported card at the moment that would also work in VMS :-( Guess Ebay is my friend. Stefan -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: [EMAIL PROTECTED] • http://www.coresystems.de/ ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: TPM chip and Grub bootloader
* Marco Gerards [EMAIL PROTECTED] [070531 18:40]: You do not need a TPM based system. Todays BIOSes prohibit flashing anything not signed by the vendor using SMI and hardware lockdown mechanisms. You are locked out already, even though you might not care or know yet. That sounds terrible. How do you deal with this for LinuxBIOS? currently by pulling the chip and writing it in an external flash writer. But that is a bad option for the people out there without this kind of equipment. -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: [EMAIL PROTECTED] • http://www.coresystems.de/ ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: TPM chip and Grub bootloader
* Robert Millan [EMAIL PROTECTED] [070530 15:18]: IOW, no matter who the keys belong to, the problem is there's a component in the hardware I paid for that is hostile to me, which contains keys that I cannot retrieve (good, because of security), and refuses to use the keys on anything I want it to (bad, because it's inherently an abusive tool). You do not need a TPM based system. Todays BIOSes prohibit flashing anything not signed by the vendor using SMI and hardware lockdown mechanisms. You are locked out already, even though you might not care or know yet. Stefan -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: [EMAIL PROTECTED] • http://www.coresystems.de/ ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] make grub2 compile with libc-less crosscompilers
* Yoshinori K. Okuji [EMAIL PROTECTED] [070519 19:44]: On Saturday 19 May 2007 17:30, Patrick Georgi wrote: I'm now using a cross compiler with target i386-elf, ie. no operating system specification, which works fine so far. With grub2 I had an issue in the configuration process as some tests try to build executables with the target compiler that link libc (and potentially even more libs) - which don't exist in my configuration. As those are not necessary, I decided to modify grub2 instead of messing around even more with the not-so-nice gcc build system. I second this patch. Cleaning out platform dependencies where there should be none is a good goal on the long and stony road to portable software. They are necessary. Otherwise, you cannot make a core image, for example. Also, without grub-emu, how do you plan to debug GRUB? Can you please explain this? I would think grub-emu is something that needs to be compiled with the host compiler, not the target compiler. If you need the target, it is not an emulation, thus pretty useless. BTW I can hardly believe that it is so difficult to use gnu build tools on solaris. Otherwise, how are opensolaris developers building GRUB? Well, niche products are always hard to maintain. Try cross-compiling a driver from the mainstream operating system windows under the niche OS Linux and you will find lots of trouble, too. Not hard to believe. Cross compiling a Linux/BSD only product like Grub under Solaris is for sure easier, but not exactly trivial. Not hard to believe that one would not start fixing auto tools code without a reason ;-) Stefan -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: [EMAIL PROTECTED] • http://www.coresystems.de/ ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: My Summer of Code Project
* Devils-Hawk [EMAIL PROTECTED] [070424 22:06]: You should probably have a look at http://www.linuxbios.org/FILO maybe you can salvage something. FILO supports booting from ElTorito bootable CD media, uses 32-bit mode, and it is free of bios calls. Unfortunately its x86 only, although some work has been done to get it running on PPC. FILO has been used on PPC for quite some time. For simplicity, that version has been integrated into LinuxBIOS directly though. There is a GSoC project for porting Grub2 to work in LinuxBIOS. It will be realized by Patrick Georgi [EMAIL PROTECTED]. Maybe you guys can join efforts on solving this issue? I would like to see FILO die. Which will happen once GRUB2 will work on an x86 machine without 16bit real mode legacy BIOS. Stefan -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: [EMAIL PROTECTED] • http://www.coresystems.de/ ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Does grub2 support background image?
* Vesa Jääskeläinen [EMAIL PROTECTED] [070104 19:28]: Yes, it will support it. All in time. I am currently waiting for my new ADSL connection to get online and then I could continue improving it. Btw. I have a local version that supports background image, but I want (and perhaps others too) it to be more generic and allows better customization. SUSE uses a couple of patches for GRUB legacy that allow all kinds of fancy stuff, like implementing a graphical help system, adding boot options and showing animations. I remember their implementation had a couple of drawbacks, because it had to run in syslinux, too, for easier maintenance. But something along that line would sure suit grub2 very well. Stefan -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: [EMAIL PROTECTED] • http://www.coresystems.de/ ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [Fwd: Re: [LinuxBIOS] grub2 as payload
* Marco Gerards [EMAIL PROTECTED] [061025 19:41]: - add support for compiling grub2 as an elf image. This is possible already. If the ELF image has specific demands, it will not be hard to make such changes. How do I do this. Running configure and make on a checked out grub2 tree leaves me with many many modules. Can you hit my head to some documentation on how to do this? * Is grub-mkimage the way to go? It produces a multiboot image, no ELF. I understand the final image has to be composed from the modules. * which module contains the int13 disk code ? So I dont accidentially use it. * what modules are required to display a grub menu over a serial console and boot a kernel (bzimage) and initrd from ext2? (assuming there is no reiserfs driver yet) What others do I need? Which ones dont I need? - boot.mod - ext2.mod - elf.mod - gzio.mod? - (_)linux.mod - normal.mod(?) - pc.mod - terminal.mod - terminfo.mod * What's the difference between _chain and chain? multiboot and _multiboot? Sorry for the stupid questions, but the documentation is rather short, still: GRUB 2 Documentation is under development. -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: [EMAIL PROTECTED] • http://www.coresystems.de/ ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Stack protection via GCC's `-fstack-protector'
Hi, * Samuel Thibault [EMAIL PROTECTED] [061108 23:14]: Thomas Schwinge, le Wed 08 Nov 2006 22:40:54 +0100, a écrit : then cat gnumach-undef-bad; exit 2; else true; fi stack_chk_fail Is it feasible to have the `-fstack-protector' functionality in GNU Mach and GRUB2 (and how to do that, then) or shall we unconditionally pass `-fno-stack-protector' if available? I'd say it shouldn't be very hard to provide a stack_chk_fail function, even if all it does is just panic(). wont this add unnecessary bloat to the binary? No, not the function calling panic. Or are we seriously concerned about buffer overflows in the bootloader? S. -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: [EMAIL PROTECTED] • http://www.coresystems.de/ ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [Fwd: Re: [LinuxBIOS] grub2 as payload
* Tristan Gingold [EMAIL PROTECTED] [061025 21:31]: Right, it should not be that hard to add an IDE driver. You only have to focus on IDE driver development, not too much on integrating it into GRUB. If you are interested, I have written an IDE driver for grub. Not complete but working. Is this available for download somewhere? There's a pretty complete IDE driver written by Jens Axboe in OpenBIOS, but it would need porting to grub2. -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: [EMAIL PROTECTED] • http://www.coresystems.de/ ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB 1.95 is released
* Vladimir Serbinenko [EMAIL PROTECTED] [061015 17:36]: Hm. What's the reason for being inconsistent here? If changing the partition naming scheme, I would have thought it'd become hd1,1. But why is the first disk 0 and the first partition 1? Using Linux style names might make sense as well... hda1,... It was already discussed plenty of times and the answer is that with BIOS it's impossible to guess the linux's names, so it would just confuse the users Sorry if I missed that. Counting disks from 0 and partitions from 1 will not confuse the users, because ...? ;-) You are right, using Linux conventions is hard to do, as this has a lot to do with how drivers are implemented and in which order they are executed. Note it was only a side thought of my mail, while the original intent, an inconsistent numbering scheme, is still an issue. -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: [EMAIL PROTECTED] • http://www.coresystems.de/ ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB 1.95 is released
* Dennis Clarke [EMAIL PROTECTED] [061015 17:41]: It was already discussed plenty of times and the answer is that with BIOS it's impossible to guess the linux's names, so it would just confuse the users Or it may be Solaris or OS/2 Warp or some OS not yet released. I enjoy the amusement my suggestion obviously provoked. Indeed we could become philosophical and find out that the device naming in the above mentioned might be less broken than the linux naming scheme. But that was evidently not my point when writing the original email. The amusement is on my side in that the original point is turned a blind eye. Stefan -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: [EMAIL PROTECTED] • http://www.coresystems.de/ ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB 1.95 is released
* Dennis Clarke [EMAIL PROTECTED] [061015 17:35]: * Yoshinori K. Okuji [EMAIL PROTECTED] [061015 16:51]: * Number partitions from 1 instead of 0. For instance, the first partition of hd0 is now hd0,1 but not hd0,0. Hm. What's the reason for being inconsistent here? If changing the partition naming scheme, I would have thought it'd become hd1,1. But why is the first disk 0 and the first partition 1? Using Linux style names might make sense as well... hda1,... I would prefer a naming style that is not specific to any OS at all. Good point. (hd0,0) already did that, right? So hard disks numbered as disks and partitions as partition works real well. Keeping in mind that even a partition is an abstraction as opposed to a real thing. We can continue philosophy and discuss that what grub is seeing as disk might be an abstraction as well. It might run in vmware, or on some other hypervisor or emulator. So do I understand you correctly that, abstracted devices are counted from 0, whereas physical devices are counted from 1? Is that the rule this follows? Stefan -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: [EMAIL PROTECTED] • http://www.coresystems.de/ ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB 1.95 is released
* Yoshinori K. Okuji [EMAIL PROTECTED] [061015 16:51]: * Number partitions from 1 instead of 0. For instance, the first partition of hd0 is now hd0,1 but not hd0,0. Hm. What's the reason for being inconsistent here? If changing the partition naming scheme, I would have thought it'd become hd1,1. But why is the first disk 0 and the first partition 1? Using Linux style names might make sense as well... hda1,... Regards, Stefan -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: [EMAIL PROTECTED] • http://www.coresystems.de/ ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [patch] rename grubof to grub
* Roger Leigh [EMAIL PROTECTED] [060427 10:49]: What about grubkernel and grub? Or grub.raw and grub? I'd like to try to stay within 8.3 naming for all files, since people will be deploying the end result on FAT filesystems. How about vmgrub for the grub kernel :) ... and put paging on the feature request list ;-) Stefan -- coresystems GmbH · Brahmsstr. 16 · D-79104 Freiburg i. Br. Tel.: +49 761 7668825 · Fax: +49 761 7664613 Email: [EMAIL PROTECTED] · http://www.coresystems.de/ ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB vs LinuxBIOS question
Hi Svante, * Svante Signell [EMAIL PROTECTED] [051229 17:12]: I'm currently reading the mailing list archives on GRUB V2 and LinuxBIOS development. Can somebody please enlighten me on the interfaces between the two development projects. I've only been marginally following grub2 development, but the short answer is: There are no interfaces at all at the moment. The somewhat longer answer is: From the LinuxBIOS perspective, this is not a bad thing, as LinuxBIOS tries to keep it's interfaces as small as possible. There are only two transitions between LinuxBIOS and a client: 1) LinuxBIOS comes with an ELF loader that can load any static self contained ELF binary from flash and execute it. This means a single binary containing all grub parts that are needed to boot an OS could be packed together with LinuxBIOS and burned to flash. So far: in theory. 2) There is a mechanism to pass information from LinuxBIOS to the outside world called the LinuxBIOS table. This table contains internal information about the BIOS, such as the possible CMOS settings, the RAM map of the machine, etc (there's also E820, PIRQ, MPTABLE and ACPI). NOTE: LinuxBIOS does not provide any legacy bios interrupt callbacks, so no client can call back into the bios to load stuff from the hard disk. This means a client has to provide a driver for this that accesses the hardware, not the BIOS. This is why I wrote in theory above. In an ideal world one should have open source, or preferably free software solutions, for the BIOS code too. Check out www.linuxbios.org and www.openbios.org. From your definition there exists a small ideal world and we are working on making this available on a much wider basis. Are there any overlaps in functionality that could be synchronised between the groups? Basically no. Instead, they both could go hand in hand very well with only little effort. LinuxBIOS only initializes the hardware and passes control to a program running in flash which we generally call a payload. http://www.linuxbios.org/index.php/Payloads There are a couple of payloads available for LinuxBIOS: * OpenBIOS (www.openbios.org) * ADLO (http://www.linuxbios.org/index.php/ADLO) * etherboot (http://www.linuxbios.org/index.php/Etherboot) * FILO (http://www.linuxbios.org/index.php/FILO) I have been working on taking the grub1 frontend and packing it into FILO a while ago. So you can use a grub user interface easily with LinuxBIOS already (with a reduced function set. patches welcome) Is anything tutorial-like written explaining the different functionality of the (Linux)BIOS (CPU, memory, peripheral initialisation, etc) and GRUB (kernel loading, transfer of control to kernel etc). Speaking for the LinuxBIOS project, the information on www.linuxbios.org is getting more and more complete, but we are always seeking to improve the information there. If you are missing something, drop us a note and we will try to fix it. Regards, Stefan ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Fwd: memory probing
* alfred hitch [EMAIL PROTECTED] [050510 12:23]: anyways, how can u get this from processor also ? The processor has little to nothing to do with this.. it's dependent on the northbridge and southbridge. I vaguely remember see'ing some code where someone on a i386 based plattform but WITHOUT bios, used smbus protocol to talk to a device across PIIX4 to get the info. Which might work on one motherboard and fail on another. Even if they both have a PIIX4. I am not familiar with PC architecture, so can someone tell me if there is some standard chip (memory controller? ?) where one can read this on PC type arch. atleast ? No. Not in a portable way. That's why BIOS provides the e820 table. I am on a IXDP425 plattform, and so far I cannot see any such register on the data sheets .. They are usually not disclosed in publically available datasheets. Stefan ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
