Re: PPC64 mlongcall gcc flag
On Tue, 2008-11-04 at 18:48 -0500, Pavel Roskin wrote: However, it would be nice to have a better explanation why -mlongcall is needed. If it's only needed for modules and has significant overhead, we may want to introduce MODULE_CFLAGS, which would only be used for modules. It absolutely should only be used for modules. It's needed because a PowerPC branch instruction can only target +/- 32MB. -mlongcall replaces the direct branch with an indirect one (using mtctr/bctrl instructions). This can target the full 32-bit address space. By the way, I tried cross-compiling for PowerPC with and without -mlongcall with gcc 4.2.4. With -mlongcall, the size of all modules combined is 426424 bytes. Without -mlongcall, the size of all modules combined is 354464 bytes. That's a significant difference for a bootloader and should be avoided if possible. To be fair, if we are that worried about footprint, why do we have a runtime ELF linker in a bootloader? At any rate, the point of having dynamically loadable modules is so you can only load the ones you need. On that scale I think the size increase is less of an issue. Maybe there is a way to keep the modules and the core in the first 32 megabytes? Actually I'm confused about something here Manoel. Module memory is allocated by grub_malloc(), but as you can see at http://svn.savannah.gnu.org/viewvc/trunk/grub2/kern/ieee1275/init.c?revision=1806root=grubview=markup the GRUB heap capped at 4MB (I don't mean size, I mean the end of the heap). So how are your modules appearing in memory above 32MB? -- Hollis Blanchard IBM Linux Technology Center ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: PPC64
On Tue, 2008-11-04 at 14:05 -0200, Manoel wrote: I was able to solve this thanks to Hollis and Segher. What was need was a flag to gcc ( -mlong-call) so that gcc puts indirect branches instead of direct branches when needed to prevent the 32mb limitation (as stated at gcc manpages). My doubt is where is the best place to put this flag so that it will be passed to all gcc calls by default? You don't want it on all gcc calls; you only want it when building the modules. -- Hollis Blanchard IBM Linux Technology Center ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: PPC64
Traditionally, firmware has refused to load an ELF file without a NOTE segment. I feel like I heard that actually changed recently (maybe in the p5 timeframe), but I never investigated further. You could easily test by running grub-mkimage without the -n switch. -- Hollis Blanchard IBM Linux Technology Center On Fri, 2008-10-24 at 10:10 -0200, Manoel wrote: I changed the load-base to 0x20 in the note segment that mkelfimage creates. After that grub2 found the modules info header in the correct position (as stated in the program header) and was able to load all modules correctly. Maybe the Open Firmware detected the overlapping and tried to load the segment in another place, and for some reason the data write was corrupted. Sounds like a OF's bug and I'll report it as you suggested. To me the correct behavior would be load things in place and correctly even with overlapping memory. And about the note section, what is the point in create it with hardcoded variables? I don't see a reason to have this note segment unless the user want to use different variables values than the configured in OF. Thanks for the help so far, it was very useful. On Thu, 2008-10-23 at 14:08 -0500, Hollis Blanchard wrote: On Thu, 2008-10-23 at 16:00 -0200, Manoel wrote: I talked with some folks at #pppc64 on freenode an they suggest that the OF is loading things in the wrong place could a problem with my load-base: real-basec0 c0 virt-base real-size100 100 virt-size load-base40004000 they suggested to change load-base from 4000 to 20 but I hava yet to try it. They also said that the note section can override load-base (and maybe we have some problem there?) It's possible. See below. I'm now reading PARP documentation to learn more about OF behavior. I thought these machine were CHRP but they are actually PARP (is that right?). Son only today I was able to get the correct documentation. PAPR was based on the older CHRP specification. Look at the segment list again: Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0xb4 0x0001 0x0001 0x0cbe4 0x14098 RWE 0x10 GNU_STACK 0x00cc98 0x 0x 0x0 0x0 RWE 0x4 LOAD 0x00cc98 0x0002d000 0x0002d000 0x5c1c8 0x5c1c8 RWE 0x4 NOTE 0x068e60 0x 0x 0x0002c 0x0 R 0x4 NOTE 0x068e60 0x 0x 0x0002c 0x0 R 0x4 this line look somehow wrong. NOTE will be loaded at the address 0? and will occupy no memory? that is the same as don't having NOTE at all right? NOTE is interpreted by the loader (firmware), but not actually loaded into memory. This is a binary structure that can be used to set some of the environment variables you mention above. The NOTE segment (segment, not section) is created by util/elf/grub-mkimage.c . You can see that load-base is set to 0x4000 in that code. Since your text starts at 0x1, that means your binary can be at most 0xc000 bytes (48KB) large before it overlaps the text area. That isn't necessarily a problem; firmware is probably using memmove() (which handles overlapping areas) to load the segments into place. It's probably worth trying a different load-base to see if that could be the problem here. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: PPC64
Please CC me, since I'm no longer subscribed to grub-devel. From: Manoel [EMAIL PROTECTED] To: The development of GRUB 2 grub-devel@gnu.org Subject: Re: PPC64 Date: Tue, 21 Oct 2008 14:43:25 -0200 Hi Hollis, On Mon, 2008-10-20 at 14:32 -0500, Hollis Blanchard wrote: On Mon, 2008-10-20 at 17:18 -0200, Manoel wrote: I'm working in a project to use grub2 to boot some ppc machines(p6 , p5 and so on) and we had some difficulties with a grub modules problem. Grub fails to load modules. When debugging I noted that grub try to find the headerinfo modules struc (which is identified by the magic number 0x676d696d) in the address 0x2d000 (_end + gap aligned in 4k blocks). but this address does not contains the headerinfo. So i altered the source code such as the memory is searched to find the magic number. It is then found at address 0x38f4c and then grub find some modules (but fails after) has showed in attachment grub2.txt. ... ../kern/dl.c:527: module at 0x3e0dc, size 0xc9c ../kern/dl.c:556: relocating to 0x28720 ../kern/dl.c:513: flushing 0x4 bytes at 0x28190 ../kern/dl.c:513: flushing 0x14 bytes at 0x281d0 ../kern/dl.c:513: flushing 0x68 bytes at 0x28220 ../kern/dl.c:513: flushing 0x410 bytes at 0x282c0 ../kern/dl.c:570: module name: amiga ../kern/dl.c:571: init function: 0x282c0 ../kern/dl.c:527: module at 0x3ed84, size 0xe28 ../kern/dl.c:556: relocating to 0x280a0 ../kern/dl.c:513: flushing 0x4 bytes at 0x27a30 ../kern/dl.c:513: flushing 0x14 bytes at 0x27a70 ../kern/dl.c:513: flushing 0xfc bytes at 0x27ac0 ../kern/dl.c:513: flushing 0x458 bytes at 0x27bf0 ../kern/dl.c:570: module name: apple ../kern/dl.c:571: init function: 0x27bf0 ../kern/dl.c:527: module at 0x3fbb8, size 0xeca4 ../kern/dl.c:556: relocating to 0x27940 Notice how much larger that last module is than the ones before it. That's a bit suspicious... do you have any modules that size? I'd like to address this issue later but their size are really messed up. Grub can find the modules (how you can see by the modules names) though. The modules should have 7k at most but grub identified them has having about 50k. That is really strange. I wonder if you have an ABI issue like sizeof(long)... how is the grub-mkimage tool compiled? Please make sure it's 32-bit. The grub binary that executes at boot should also 32-bit. I'm also curious why we must have a GAP between _end and the modules. Why do not put the modules right after the _end address. We put the modules into a separate PT_LOAD ELF segment, and these must be aligned. One other possibility is that your firmware doesn't like the way grub-mkimage throws out the section table on the ELF file. You could try changing that behavior. I suppose you could also try to extend the existing PT_LOAD segment instead of creating a new one, but architecturally creating a new segment for the modules is much nicer. I need to look more into the source code but I noted the modules are allocated in address in a decrementing order. The next module is always loaded in a address below the previous module. I don't know if this memory is allocated by the OF or if Grub forces the address to load the modules this way. How I have said before that I will look at this issue after the modules header info location address issue is resolved. that address calculation led me to believe that I can tell where the struct will be on memory based in its place in the binary. I also noted that basemod ( indicates where the modules sections begin) used by grub_mkelfimage is the same calculated by grub (_end + GAP). but it seems to not store it on the necessary address. using hexedit I could see that in the address 0xCC98 (in the file generated by grub_mkelfimage) is stored the struct header info. Well, hmm. Given the readelf output below, file offset 0xcc98 should be loaded right at 0x2d000. Since you can see the magic number there (correct?), I can't explain why the ELF loaded places it at 0x38f4c. Yes, the magic number is exactly at the address 0xcc98 on the file generated by the grub_mkelfimage. How can you tell the address it should appear in memory based on its address in file? Maybe it's only valid in some old OF version? Look at the segment list again: Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0xb4 0x0001 0x0001 0x0cbe4 0x14098 RWE 0x10 GNU_STACK 0x00cc98 0x 0x 0x0 0x0 RWE 0x4 LOAD 0x00cc98 0x0002d000 0x0002d000 0x5c1c8 0x5c1c8 RWE 0x4 NOTE 0x068e60 0x 0x 0x0002c 0x0 R 0x4 Offset tells you where in the file each segment begins. FileSiz is how many bytes to read from the file. VirtAddr/PhysAddr is where in memory to copy it, and MemSiz is how many bytes the segment will occupy in memory. (If MemSiz FileSiz
Re: PPC64
On Tue, 2008-10-21 at 18:04 -0400, Pavel Roskin wrote: util/ieee1275/grub-install.in is not suitable for PowerPC. It worked great for me. :) It assumes that /boot is on the HFS boot partition. I documented the partitioning assumptions it uses: http://grub.enbug.org/TestingOnPowerPC It's not the case for Fedora and perhaps any distro. The HFS boot partition is not mounted and should be accessed by hfstools. The modules should be installed under /boot/grub. The path to /boot/grub should be embedded into the core image. We have support for embedding the default module path now. We need a better script that would not put all modules on the short HFS boot partition. Considering that the SPARC port is defunct, I would just rewrite util/ieee1275/grub-install.in. The boot partition is an unnecessary hack instituted by a particularly opinionated ybin developer, and a great inconvenience. It's ridiculous to have scripts to copy and convert yaboot.conf files into a secret partition, especially since the bootloader is perfectly capable of discovering files at run time (unlike lilo, where the ybin model came from). Also, have you looked at those scripts? shudder On IBM POWER servers, there is no HFS partition at all. Instead, there is a raw partition onto which you dd an ELF file. Firmware loads the whole thing into memory and jumps at offset 0. Traditionally, yaboot is installed there, and when it runs it does a shoddy job of trying to walk the (DOS) partition table, searching for /etc/yaboot.conf. Once GRUB replaces yaboot/ybin we can happily wave both of these anachronisms goodbye. Firmware on both systems is fully capable of loading ELF files from a filesystem, and since it's on a filesystem there is no need to embed anything or search anywhere: all files (grub.cfg and the modules) should be placed adjacent to the executable. As for embedding the path in the executable itself, that's a nice idea until you copy the executable to another system or move your hard disk to another system where devices have different Open Firmware paths and aliases. Another big pain point is building bootable CDs, since these also unfortunately cannot make assumptions about the Open Firmware devices available. Just put all the files in the same directory on a real filesystem and be happy. I know I am. :) -- Hollis Blanchard IBM Linux Technology Center ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: PPC64
On Mon, 2008-10-20 at 17:18 -0200, Manoel wrote: I'm working in a project to use grub2 to boot some ppc machines(p6 , p5 and so on) and we had some difficulties with a grub modules problem. Grub fails to load modules. When debugging I noted that grub try to find the headerinfo modules struc (which is identified by the magic number 0x676d696d) in the address 0x2d000 (_end + gap aligned in 4k blocks). but this address does not contains the headerinfo. So i altered the source code such as the memory is searched to find the magic number. It is then found at address 0x38f4c and then grub find some modules (but fails after) has showed in attachment grub2.txt. ... ../kern/dl.c:527: module at 0x3e0dc, size 0xc9c ../kern/dl.c:556: relocating to 0x28720 ../kern/dl.c:513: flushing 0x4 bytes at 0x28190 ../kern/dl.c:513: flushing 0x14 bytes at 0x281d0 ../kern/dl.c:513: flushing 0x68 bytes at 0x28220 ../kern/dl.c:513: flushing 0x410 bytes at 0x282c0 ../kern/dl.c:570: module name: amiga ../kern/dl.c:571: init function: 0x282c0 ../kern/dl.c:527: module at 0x3ed84, size 0xe28 ../kern/dl.c:556: relocating to 0x280a0 ../kern/dl.c:513: flushing 0x4 bytes at 0x27a30 ../kern/dl.c:513: flushing 0x14 bytes at 0x27a70 ../kern/dl.c:513: flushing 0xfc bytes at 0x27ac0 ../kern/dl.c:513: flushing 0x458 bytes at 0x27bf0 ../kern/dl.c:570: module name: apple ../kern/dl.c:571: init function: 0x27bf0 ../kern/dl.c:527: module at 0x3fbb8, size 0xeca4 ../kern/dl.c:556: relocating to 0x27940 Notice how much larger that last module is than the ones before it. That's a bit suspicious... do you have any modules that size? that address calculation led me to believe that I can tell where the struct will be on memory based in its place in the binary. I also noted that basemod ( indicates where the modules sections begin) used by grub_mkelfimage is the same calculated by grub (_end + GAP). but it seems to not store it on the necessary address. using hexedit I could see that in the address 0xCC98 (in the file generated by grub_mkelfimage) is stored the struct header info. Well, hmm. Given the readelf output below, file offset 0xcc98 should be loaded right at 0x2d000. Since you can see the magic number there (correct?), I can't explain why the ELF loaded places it at 0x38f4c. Can you report what memory firmware is using on this system? IIRC you can decode it from the available properties in the memory nodes. so in resume. address where grub tries to find the header 0x2d000. address where it is actually stored 0x38f4c. address where it is in the generated file 0xCC98. So my doubts are: How this address calculation works? How can I know where the struct will be in memory based in its address in the binary? It really works or only in some old OpenFirmare version? I followed the wiki tutorial in the process. That is the exit of the command: readelf -l (binary + modules): Elf file type is EXEC (Executable file) Entry point 0x1 There are 4 program headers, starting at offset 52 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0xb4 0x0001 0x0001 0x0cbe4 0x14098 RWE 0x10 GNU_STACK 0x00cc98 0x 0x 0x0 0x0 RWE 0x4 LOAD 0x00cc98 0x0002d000 0x0002d000 0x5c1c8 0x5c1c8 RWE 0x4 NOTE 0x068e60 0x 0x 0x0002c 0x0 R 0x4 the exit of readelf -a is showed in attachment readelf.txt If you could help me, I will appreciate it. Thanks in advance! Best regards. Abranches, Manoel R. -- Hollis Blanchard IBM Linux Technology Center ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: New command dump
On 8/3/07, Bean [EMAIL PROTECTED] wrote:
Hi,
I have written a new command dump, it can hex dump content of file or memory.
usage:
dump [-s skip] [-n length] { FILE | (mem) }
The output look just like command hexdump.
If you use (mem) as filename, it will dump physical memory instead of
file. when dumping memory, the default length is 256, but when dumping
normal file, the default length is the whole file.
Inside grub2, modules can call function dump directly:
void dump(unsigned long base,char* buf, int len);
Thanks, I've been meaning to submit something like this for a long time. :)
The module I wrote actually had one more convenience feature: it keeps
a position pointer, and if you run the command again without an
address, it displays the memory immediately after the last dump.
-Hollis
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] efika memory issues
On 7/31/07, Robert Millan [EMAIL PROTECTED] wrote:
On Tue, Jul 31, 2007 at 10:55:09AM -0500, Hollis Blanchard wrote:
I think the simplest solution will be to allocate Efika's heap high,
as we talked about earlier. If the first available region is above
4MB, just reserve 4MB and don't worry about where it is. In general we
should try to keep 4MB free, but at the end of the day it's Efika's
fault and probably won't be a big deal for them anyways.
Ok, let's do that. But what do we do if the first available region is
just a few kBs below 4MB? Or if it's just too small? I think we need to
determine what is the minimum heap size we want to accept, such that the
ability to keep 4MB free still compensates having a small heap.
Any suggestion?
Yup, it's a pain. Here's one idea: set a GET_HEAP_FROM_WHEREVER
flag, then later do
if (GET_HEAP_FROM_WHEREVER) {
grub_addr_t heap_addr;
grub_ieee1275_claim(0, MIN_HEAP_SIZE, 4, heap_addr);
}
That will ask firmware to find us a suitable area of memory.and return
the address. It might even work.
We could try doing that in all situations, except:
- this method isn't often used, so firmwares can have bugs here
- if MIN_HEAP_SIZE were small enough (e.g. 2MB), it would mean we
probably would still have 4MB+ free. However, that depends on the size
of the modules. I would hate to document oh, if you can't load your
OS, try using fewer GRUB modules. On the other hand, we already have
this problem to some extent: if our modules are too large, we will
fail to allocate any heap. So maybe this isn't a practical concern.
-Hollis
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] efika memory issues
On 7/31/07, Robert Millan [EMAIL PROTECTED] wrote: On Mon, Jul 30, 2007 at 05:35:28PM -0500, Hollis Blanchard wrote: When GRUB_IEEE1275_FLAG_EFIKA_SECRET_AVAILABLE_REGION was set, release hardcoded 0x4000:0xffc000 region. Hmm, does this actually work? Since GRUB itself falls within that regions, the grub_ieee1275_release() call will mark all the memory that the GRUB kernel and modules occupy as free, which means they will be clobbered by heap usage. Didn't think of this.. (by chance it worked here, though). How about using max(_end,0x4000) instead of 0x4000 ? (and adjusting region length not to overflow 0x100) That won't quite work because the modules are loaded in the area immediately following the kernel. However, because they are added in a post-processing step, we don't know their end address at link time. I think the simplest solution will be to allocate Efika's heap high, as we talked about earlier. If the first available region is above 4MB, just reserve 4MB and don't worry about where it is. In general we should try to keep 4MB free, but at the end of the day it's Efika's fault and probably won't be a big deal for them anyways. -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] efika memory issues
On 7/30/07, Robert Millan [EMAIL PROTECTED] wrote: On Sun, Jul 29, 2007 at 09:30:11PM +0200, Robert Millan wrote: Hi Sven, I have a pair of questions about the memory issue.. [...] Ok, after some discussion on IRC, and invaluable help by Sven in documenting smartfirmware behaviour, I came up with this patch. Please let me know what you think. If there are no objections I'll check it in in a few days. 2007-07-30 Robert Millan [EMAIL PROTECTED] * include/grub/ieee1275/ieee1275.h (grub_ieee1275_flag): Add GRUB_IEEE1275_FLAG_EFIKA_SECRET_AVAILABLE_REGION flag. * kern/powerpc/ieee1275/cmain.c (grub_ieee1275_find_options): Set GRUB_IEEE1275_FLAG_EFIKA_SECRET_AVAILABLE_REGION flag when running on an Efika (SmartFirmware). * kern/powerpc/ieee1275/init.c (grub_claim_heap): Fail gracefuly when addr heaplimit. Use grub_printf instead of grub_error for error reporting, since grub_error doesn't work at this point of execution. When GRUB_IEEE1275_FLAG_EFIKA_SECRET_AVAILABLE_REGION was set, release hardcoded 0x4000:0xffc000 region. Hmm, does this actually work? Since GRUB itself falls within that regions, the grub_ieee1275_release() call will mark all the memory that the GRUB kernel and modules occupy as free, which means they will be clobbered by heap usage. -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] [PATCH] Add multiboot 2 capabilities
On 7/25/07, Stefan Reinauer [EMAIL PROTECTED] wrote: * 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? Yes, it supported this before the multiboot2 commit, and it still supports it now. In fact Jerone did work to make it all user-invisible: the same multiboot command will automatically select the appropriate loader type (either mb1 or mb2), and the same module command will behave according to the multiboot kernel type. -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: memory management issue (Re: another regression on Efika)
On 7/25/07, Robert Millan [EMAIL PROTECTED] wrote: On Wed, Jul 25, 2007 at 12:51:27PM -0500, Hollis Blanchard wrote: I was indeed trying to make it absolute. GRUB is linked at 0x1, or 64KB. Add in all the modules and you still are only using a couple hundred KB. But if GRUB is linked at 0x1, how come the firmware loads it since that's below the 0x19111e4 limit? (or am I missing some physical vs logical issue here?) No, you are correct; obviously firmware is doing something wrong. The question is can we accommodate it, and if so, how? I don't remember *why* I was trying to make it absolute; I'm sure it was to fix a problem (rather than I was bored). If we could get away from this anachronistic Changelog crap, the commit message would have told us exactly what we need to know. I pasted the ChangeLog entries in an earlier mail. Do you mean the CVS commit message might have more information? I mean if this were any other project I participate in, I would have explicitly spelled out why the commit was done. I *think* it was because we have a relocation problem with OSes that are linked at 4MB, which is the case with Xen (and I believe yaboot). If GRUB is using that memory, we simply can't load anything there. I think we can add some somewhat-special-case logic that says if there is nothing available below HEAP_LIMIT, claim something beginning as low as we can. That reduces functionality on such platforms (as described above), but there's little we can do about that unless firmware is fixed. So the purpose of HEAP_LIMIT is to support code that is linked at fixed addresses? Yes. This includes yaboot, Xen, and Linux zImages. I think zImages relocate themselves no matter where they were loaded though. My big question is this: why is Efika firmware saying that 0x19111e4 (around 25MB) is the first available address? What is wrong with that? Is it general practice that all firmwares load at low addresses so that non-relocatable code can be linked at 4MB or such? Not at all. IBM pSeries firmwares load at a default of 12MB, and I've seen others that load at the top of RAM to stay out of the way. It's clear that Efika firmware isn't *really* using all memory below 25MB; we know this because we managed to load grub there. This undoubtedly an Efika firmware bug, but as I described earlier I think we can devise another workaround for it without hurting the common case. -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB_IEEE1275_FLAG_NO_PARTITION_0
On Mon, 2007-07-09 at 17:05 +0200, Robert Millan wrote: What's the point of GRUB_IEEE1275_FLAG_NO_PARTITION_0 ? We have code that checks this flag, but nobody initialises it: disk/ieee1275/ofdisk.c: if (! grub_ieee1275_test_flag (GRUB_IEEE1275_FLAG_NO_PARTITION_0)) include/grub/ieee1275/ieee1275.h: GRUB_IEEE1275_FLAG_NO_PARTITION_0, In IEEE1275, partition 0 (as in disk:0) means the whole disk. However, CodeGen-based firmware (that means Genesi) have a bug where partition 0 is actually disk partition 1. In that case, to access the whole disk, GRUB must open disk instead of disk:0. I have no idea how the initialization got lost; it should be initialized in the same place that the other flags are. Checking cvs history may be in order. -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: memory management issue (Re: another regression on Efika)
On Tue, 2007-07-10 at 16:08 +0200, Robert Millan wrote: On Tue, Jul 10, 2007 at 12:04:44PM +0200, Jordi Mallach wrote: Hey, On Wed, Jul 04, 2007, Hollis said: This problem could be caused by firmware presenting an incorrect /memory/available property. I would instrument grub_available_iterate() and heap_init() to confirm. That property lists unclaimed areas of memory, which are free for us to use as heap. The memory used for firmware itself (including exception handlers at 0), and the memory used by the loaded ELF file (GRUB), are missing from /memory/available, so we know not to try to use those regions for the heap. If that is in fact the problem (which wouldn't surprise me given this particular firmware's track record), then we'll have to add some hardcoded hack particularly for Efika in grub_machine_init(), bypassing the more general code we have now. I'm afraid there must be more to this. [...] When the package was later on updated to a CVS snapshot of 20070505, GRUB started dropping me to OF at boot time. On Saturday, Robert helped me track this regression down to this same commit. After reverting and regenerating grub, I'm happy to report that for the first time my Powerbook G4 laptop was able to boot with me pressing no keys at all, using GRUB. So you're talking about a completely different failure mode, correct? In short, whatever is causing these crashes is not only an Efika issue. I suspect Apple, or Apple powerbooks at least, are also affected. I got Sjoerd to try this on his powerbook, and he confirms this fixes for him. Paul also tried, with the same results. Not all the powerbooks are the very same model, there are different model revisions involved. The error Jordi was seeing before reverting your commits was very similar to what I get on my Efika (something like claim failed). Hollis, do you still think this is a firmware bug? Could somebody please debug it and report back if it is really a GRUB issue? It could be as simple as adjusting the link address, or it could mean instrumenting grub_available_iterate() and checking that output with the contents of /memory/available. -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: PowerMac hack breaks Efika
On Mon, 2007-07-02 at 14:48 +0200, Stefan Reinauer wrote: * 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? (Note: this is about PowerMacs too, not just PowerBooks.) The default output device is a graphics card. However, console output doesn't actually display to the default output device (presumably to preserve Apple's logo splash screen). Yes, this violates section 7.4.5 of IEEE1275. To get console output, we need to open the output device. However, we can't hardcode a particular device (e.g. the screen device alias), since that could break users with serial console. 'output-device' returns a string specifying the default output device. 'output' changes console output to the specified device. In other words, this command opens the output device that should already be open. I believe I tested this code on briQ, which shares a code lineage with Efika, but Efika certainly could have broken something. It's entirely possible that a particular firmware does not correctly implement these commands. We already have a framework for such cases, and we already work around SmartFirmware bugs with it. 1. define a GRUB_IEEE1275_FLAG_BROKEN_OUTPUT flag in include/grub/ieee1275/ieee1275.h 2. call grub_ieee1275_set_flag() in grub_ieee1275_find_options() 3. use grub_ieee1275_test_flag() in grub_ofconsole_init() -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: another regression on Efika
On Mon, 2007-07-02 at 20:16 +0200, Robert Millan wrote: Hi, I spotted another regression, caused by the following commits: 2007-02-21 Hollis Blanchard [EMAIL PROTECTED] * kern/powerpc/ieee1275/init.c (HEAP_SIZE): Removed. (HEAP_LIMIT): New macro. (grub_claim_heap): Claim memory up to `heaplimit'. 2007-02-21 Hollis Blanchard [EMAIL PROTECTED] * conf/powerpc-ieee1275.rmk (kernel_elf_LDFLAGS): Link at 64KB. * kern/powerpc/ieee1275/init.c (_end): Add declaration. (_start): Likewise. (grub_arch_modules_addr): Return address after `_end'. * util/powerpc/ieee1275/grub-mkimage.c: Include grub/misc.h. (load_modules): Use new parameter as `p_paddr' and `p_vaddr'. (add_segments): Calculate `_end' from phdr size and location. (ALIGN_UP): Moved to ... * include/grub/misc.h: here. * include/grub/powerpc/ieee1275/kernel.h (GRUB_IEEE1275_MOD_ALIGN): New macro. (GRUB_IEEE1275_MODULE_BASE): Removed. They move GRUB from being able to initialise and fire up the menu (although still unable to access disks), to abort with: kern/mm.c: grub_error (GRUB_ERR_OUT_OF_MEMORY, out of memory); This is probably because grub_mm_init_region() was never called, or wasn't called enough. Unfortunately my limited expertise doesn't let me figure out what these changes are doing. I'm attaching a reverse diff of the commit, such that when applied to HEAD makes GRUB work again (verified) [1]. Perhaps someone can make sense of it. This problem could be caused by firmware presenting an incorrect /memory/available property. I would instrument grub_available_iterate() and heap_init() to confirm. That property lists unclaimed areas of memory, which are free for us to use as heap. The memory used for firmware itself (including exception handlers at 0), and the memory used by the loaded ELF file (GRUB), are missing from /memory/available, so we know not to try to use those regions for the heap. If that is in fact the problem (which wouldn't surprise me given this particular firmware's track record), then we'll have to add some hardcoded hack particularly for Efika in grub_machine_init(), bypassing the more general code we have now. -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: EFI and binary distributors
On Wed, 2007-05-02 at 15:42 +0200, Robert Millan wrote: What about powerpc? Has EFI ever been used there? I've never heard of such a thing. -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Two SoC ideas
On Fri, 2007-03-23 at 23:46 +0800, Wei Shen wrote: 2) addr option for module command Add nn option: addr = value to the module command. If the addr option is specified, Grub will load the module to address value instead of the default address. Why? -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub2 ChangeLog config.h.in fs/ext2.c
On Sun, 2007-03-18 at 01:18 +, Yoshinori K. Okuji wrote: Log message: 2007-03-18 Yoshinori K. Okuji [EMAIL PROTECTED] * fs/ext2.c (grub_ext2_read_inode): Use the inode size in a superblock instead of the structure size to compute an offset. This fixes the problem that GRUB could not read a filesystem when inode size is different from 128-byte. diff -u -r1.13 -r1.14 --- grub2/fs/ext2.c 2006/06/04 15:56:54 1.13 +++ grub2/fs/ext2.c 2007/03/18 01:18:39 1.14 @@ -294,7 +294,7 @@ if (grub_disk_read (data-disk, ((grub_le_to_cpu32 (blkgrp.inode_table_id) + blkno) LOG2_EXT2_BLOCK_SIZE (data)), - sizeof (struct grub_ext2_inode) * blkoff, + grub_le_to_cpu16 (sblock-inode_size) * blkoff, sizeof (struct grub_ext2_inode), (char *) inode)) return grub_errno; If the inode size is not 128 bytes, why do we still read `sizeof (struct grub_ext2_inode)' bytes from disk? What is the layout of a non-128-byte inode? -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Fix build of sparc64 port implement setjmp/longjmp
On Sun, 2007-03-04 at 16:14 +0100, Vincent Pelletier wrote: Hi. Here is a (mostly) maintainance patch for sparc64 port. It only fixes the build and implements setjmp/longjmp so that one can jump to rescue mode. It looks like you also introduce new ELF relocations, I guess because you've stumbled across modload errors? I prefer to post the patch for validation before commiting, it's been too long I haven't post to go on my own :) . (changelog is in the diff :p ). Could you remove the commented-out code in setjmp.S please? Also, it doesn't look like you're actually calling grub_claim_heap(). In that case, why add it to kern/sparc64/ieee1275/init.c ? +typedef grub_uint64_t grub_jmp_buf[10]; ... -grub_jmp_buf grub_exit_env; +grub_jmp_buf grub_exit_env __attribute__ ((__aligned__(8))); grub_jmp_buf should already be 8-byte aligned (because grub_uint64_t is, right?), so you should leave grub_exit_env alone. -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB header magic numbers
On Tue, 2007-02-27 at 16:46 -0800, Daniel Weaver wrote: Hello, I have created a proprietary loader that serves much the same function as GRUB. It is used to load a proprietary operating system. One of the things I need in my system is the load length of the operating system. Rather than reinvent the wheel I wish to use a GRUB style header to provide this information. Some day in the future we may decide to change either the loader or the operating system and the use of a standard loader header will make the transition much easier. My web searches have turned up two very similar multiboot headers. One with a magic number of 0x1BAD002 and another with a magic number of 0xe85250d6. First off, why are there two numbers? They are from different versions of the Multiboot specification: http://www.gnu.org/software/grub/manual/multiboot/html_node/Header-magic-fields.html#Header-magic-fields http://grub.enbug.org/MultibootDraft It's not just the numbers; the formats are completely different. And which is more likely to be used in the long run? The multiboot2 format, though multiboot1 will likely not go away in the near term. multiboot1 was written without any thought for portability, and since it's a large data structure it is very brittle. The multiboot2 format is portable and much more flexible and extensible, since it is based on a list of small structures. That said, it is not yet in use by any major project (much like grub2 itself). There is no multiboot2 loader for grub 0.9x (which is the version currently in use by all Linux distributions). If you're looking for a format to support, I would recommend multiboot2, especially since you don't depend on interoperability with the current generation of Linux software. If you do choose to use multiboot2 and have any comments, questions, or suggestions about the format, we'd love to hear about them here. -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
RE: Fancy menu requirements
On Fri, 2007-02-23 at 19:51 +0100, Ernest Sales wrote: On Mon, 19 Feb 2007 15:16:25 -0500, Jason Morganson [EMAIL PROTECTED] wrote: Because of how important this feature will be to GRUB I wanted to put this up where everyone can change and comment on it. Do you really think a boot manager needs graphics and soft fonts? The Linux distributions believe this. I find text menus smart enough for this, the beauty of simplicity if you like. On the other hand, what I would ask for is self-containment (code in first disc sector, or else in its own partition) and autodetect-and-config as a start point to further customization. I took a glance at GRUB's site, I am loosely following this list for a while, and can't yet figure if GRUB supports these features. Yes, it does. -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
[RFC][PATCH] multiboot2 loader
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 this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include grub/multiboot2.h
+#include grub/err.h
+#include grub/normal.h
+#include grub/dl.h
+#include grub/machine/loader.h
+
+static grub_err_t
+grub_normal_cmd_multiboot2 (UNUSED struct grub_arg_list *state,
+ int argc, char **args)
+{
+ grub_rescue_cmd_multiboot2 (argc, args);
+ return grub_errno;
+}
+
+static grub_err_t
+grub_normal_cmd_module2 (UNUSED struct grub_arg_list *state,
+ int argc, char **args)
+{
+ grub_rescue_cmd_module2 (argc, args);
+ return grub_errno;
+}
+
+GRUB_MOD_INIT(multiboot2_normal)
+{
+ (void) mod; /* To stop warning. */
+ grub_register_command (multiboot, grub_normal_cmd_multiboot2,
+GRUB_COMMAND_FLAG_BOTH
+| GRUB_COMMAND_FLAG_NO_ARG_PARSE,
+multiboot FILE [ARGS...],
+Load a Multiboot kernel., 0);
+
+ grub_register_command (module, grub_normal_cmd_module2,
+GRUB_COMMAND_FLAG_BOTH
+| GRUB_COMMAND_FLAG_NO_ARG_PARSE,
+module FILE [ARGS...],
+Load a Multiboot module., 0);
+}
+
+GRUB_MOD_FINI(multiboot_normal)
+{
+ grub_unregister_command (multiboot2);
+ grub_unregister_command (module2);
+}
--
Hollis Blanchard
IBM Linux Technology Center
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] [UPDATE 2] More enhanced GNU GRUB program name transformations
On Tue, 2007-02-13 at 17:30 +0100, Lubomir Kundrak wrote: Hi Hollis, On Mon, 2007-02-12 at 19:01 -0600, Hollis Blanchard wrote: On Mon, 2007-02-12 at 00:20 -0600, Jerone Young wrote: This patch is derived from the patch sent earlier by Lubomir Kundrak. What this patch adds is for library directories and directories in /boot to be changed as well. So the user can easily launch ./configure --program-transform-name=s/grub/grub2/ This seems a little over-engineered to me. Why not just rename all the grub2 stuff to be grub2-* to begin with? Do you think it is a good practice to rename the program names by default? In my opinion is not the good place to tell what version of the program the binary belongs to. This technique is commonly used to separate versions of software when more than one version it is in use -- temporarily, till it gets wider acceptance. So users will have both grub-* and grub2-* installed? When grub2 is the default, they and all their scripts will need to learn to run grub2-* instead of grub-*. Then one day grub1 will be removed, grub2 will be renamed to grub-*, and the user must learn this and all those tools will need to be reverted to call grub-* again? I don't think changing the name more than once is a good idea. And if we're only going to change it once, let's just do it and avoid this transform stuff. That's why I think it is good that it is configurable. Additionally we merely use autoconf's feature, not add or invent new stuff, so it hardly can be called over-engineering. All those | sed $(transform) additions don't look like an autoconf feature to me... -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Adapting GRUB to boot directly from RAM in protected mode
On Thu, 2007-02-08 at 11:25 -0800, Patrick Connolly wrote: Can anyone think of a straightforward way to modify GRUB to boot a linux kernel directly from RAM in protected mode? We have an embedded system with a special BIOS that places a file (any file) at a fixed location in RAM and executes it (in protected mode) starting at that same fixed location. We'd like the file to be a linux kernel (with boot code) and we're wondering if GRUB could be adapted to do this. We realize that some assembly-level modifications would be needed but we aren't sure how extensive those modifications might be expected to be. You should be able to easily write a simple loader for GRUB2. No idea about GRUB Legacy. -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub on lvm2
On Sat, 2007-02-03 at 04:15 -0800, Mark Hannessen wrote:
Hi list,
I have read on some websites that grub1.95 can boot from lvm
So I thought I'd give it a try.
I am quite new to grub2, so please forgive me my noobischness.
This is what i did:
1) I added /dev/hda to the physical extents ( pvcreate /dev/hda )
2) created a volume group on it ( vgcreate lvm2_core /dev/hda )
3) and created a boot partition on it ( lvcreate -L100M boot lvm2_core )
4) and wrote a partition on it: ( mkfs.reiserfs /dev/lvm2_core/boot )
5) mounted it on /boot and copied a bunch of grub .mod files to /boot/grub
6) created a config file called grub.cfg in /boot/grub/grub.cfg that
looks like this:
# begin grub.cfg
set timeout=10
set default=0
menuentry My Linux Kernel on (lvm2_core-boot) {
set root=(lvm2_core_boot)
linux /boot/vmlinuz root=/dev/ram
initrd /initrd
# end grub.cfg
I don't believe set root behaves properly. If that's the problem, you
will need to duplicate that value into both following lines.
so far so good (i hope..)
I now tried various combinations of grub-setup and grub-install but I
can't seem to get it right...
Perhaps you could be a little more specific.
could anyone give me a syntax that should work here?
or perhaps some documentation so I could figure it out myself..
All GRUB2 documentation is in the wiki: http://grub.enbug.org/
-Hollis
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: identifying module types
On Sat, 2006-12-09 at 06:31 +0100, Tristan Gingold wrote: On Fri, Dec 08, 2006 at 06:02:31PM -0600, Hollis Blanchard wrote: On Fri, 2006-10-27 at 06:09 +0200, Tristan Gingold wrote: BTW, why not adding a type field for module tag. The type (which should be an UUID IMHO) should indicate the type of the module. One usage could be for Xen. On Xen you can load 3 modules: the linux kernel, the linux ramdisk and an ACM configuration. Xen relies on order and on some magic checks to find the module type. The command syntax could be: module [-type TYPE] file [cmdline] As I'm implementing the Xen side of this, I can now see the need. Xen uses a handful of modules: - xen kernel - dom0 kernel - dom0 initrd - security policy (binary blob) - possibly others On the consumer side of multiboot (in this case Xen), we need to loop over the tags, and when we find a module tag, how do we know which it is? The Multiboot2 spec tells us The order of modules is not guaranteed. (Why not?) Currently Xen relies on the order. Maybe the spec should be slighly changed? If we can't rely on the order, then we have no reliable way to distinguish the type of module we're looking at, so a type field would be extremely useful. For example: multiboot (hd1,1)/xen module -t xenhv-dom0 (hd1,1)/vmlinux module -t xenhv-dom0-initrd (hd1,1)/initrd or multiboot (hd0,0)/boot/gnumach.gz root=device:hd2s1 module -t hurd-something (hd0,0)/lib/ld.so.1 One option is a fixed-length encoded field, say 32 bytes wide. To avoid namespace collisions, we could require that projects prefix types with their project name, which must be at least 4 bytes. Nb: UUID are 16 bytes and collisions are avoided. Please detail your proposal. I prefer the use of a fixed-length field. Me too. But that's my own opinion (UUID are easy to generate, to compare and well-known - do not reinvent the wheel). UUIDs, e.g. 550e8400-e29b-41d4-a716-44665544, are also completely unintelligible, so they cannot be the only answer. So far you seem to be advocating the following: module [--type TYPE | --uuid UUID] file TYPE: an English word that GRUB translates to a UUID. GRUB must therefor maintain a table of known types and their associated UUIDs. UUID: a 16-byte number which can be represented as 36 ASCII characters (including hyphens). How should we generate the UUIDs for the table in GRUB? I'll just run uuidgen here and create them myself? Does anybody object to this scheme? -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: identifying module types
On Fri, 2006-12-08 at 18:02 -0600, Hollis Blanchard wrote: On the consumer side of multiboot (in this case Xen), we need to loop over the tags, and when we find a module tag, how do we know which it is? The Multiboot2 spec tells us The order of modules is not guaranteed. (Why not?) Of course, requiring that the order be preserved is the simplest solution, so unless there is a compelling reason to avoid that, I think we should avoid the UUID complexity. -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: identifying module types
On Tue, 2006-12-12 at 23:28 +0100, Yoshinori K. Okuji wrote: On Saturday 09 December 2006 01:02, Hollis Blanchard wrote: On the consumer side of multiboot (in this case Xen), we need to loop over the tags, and when we find a module tag, how do we know which it is? The Multiboot2 spec tells us The order of modules is not guaranteed. (Why not?) Because the spec does not know how modules are loaded by a boot loader at all. It does not know how to configure a boot loader. It does not know whether it is possible to interact with a boot loader at runtime. On the assumption in the spec, all we can say is that it is recommended that modules are loaded in the order specified by the user, if possible. We may not say must here. I guess I'm not clear on this. The modules must be enumerated in some order, whether manually by the user or in a config file or by a script. Wouldn't it be appropriate to require that this order be preserved? Are you envisioning a scenario like a collection of module files in a menuentry.d directory, and then what is the order? Xen could go on depending on the ordering, with the caveat that bootloaders which reorder modules won't work. One option is a fixed-length encoded field, say 32 bytes wide. To avoid namespace collisions, we could require that projects prefix types with their project name, which must be at least 4 bytes. Another alternative would be a NULL-terminated string, which would appear in memory just before the NULL-terminated command line, e.g. x e n \0 c o n s o l e = c o m 2 \0 This is more flexible, but slightly more awkward on the consumer side: type = module_tag-text; cmdline = strchr(module_tag-text, '\0') + 1; Isn't it easier to pass two strings rather than packing them to a single string? type = module-type; cmdline = module-cmdline; That only works if module-type is of fixed size. What size would you like? Aside from the arbitrary user-visible limit, a fixed size may make namespace collisions more likely (though certainly we would need to account for collisions even if the size were variable). -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: disk vs partition numbering
On Tue, 2006-12-12 at 23:46 +0100, Yoshinori K. Okuji wrote: The critical thing is how to reduce new things that people would have to study for using a program. GRUB Legacy made a mistake, since nearly all operating systems use 0-based for disks, and 1-based for partitions. Since I'm used to Linux, which assigns disks letters rather than numbers, I was unaware that other OSs like BSD number disks from 0. Since that's the case, and neither 0 nor 1 will make sense to people expecting a, I'm OK with 0. Now, some people say that this is inconsistent against GRUB Legacy. OK. I admit it. But which is more important in a long run: easy for existing users to migrate to GRUB 2, or easy for new comers to adapt GRUB 2? How difficult is it that existing users know GRUB now follows the same rule as others? How difficult is it that beginners study a rule different from others, so not intuitive at all? Yes, I definitely agree with the decision to number partitions from 1. (Hopefully we can do the same with menu entries too. :) Making this change at a time when the config file syntax changes is the only good opportunity. -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: multiboot2: make multiboot header optional
On Tue, 2006-12-12 at 23:08 +0100, Yoshinori K. Okuji wrote: On Thursday 07 December 2006 23:39, Hollis Blanchard wrote: I thought we had two options: embedding tags, or ORing bits into an embedded long. When I suggested embedding tags, you told me it was too complicated so will cause developer errors. Have I misunderstood? I meant that the complexity of using bitfields plus a fixed-size structure is identical to that of using tags. But I bet that it is more complicated to use tags _by hand_. For me, complex and complicated are quite different. Besides how to make it look easier by predefined macros, please consider the spec itself. With bitfields and fixed-size fields, all you must remember is: - What bits mean what - How to order values passed to a boot loader With tags, you need to remember: - What tags mean what - What tag size is expected to each tag - What tags must be combined with a given tag If you generate tags by programming, I don't think the use of tags is more complicated. It can be even easier for a parser. However, when specifying tags by hand, I cannot believe that it is as straightforward as using fields. If you allow me to use a big gun, I would tell you that most system programmers are used to fields, while they are not familar with writing tags. I'm willing to go along with this, since I realized that only a tiny number of people will need to use this flags (and that number does not include me :). It seemed to work for GRUB Legacy, so I guess it can work here too. My loader code doesn't currently read either tags or flags, and since most people don't need this functionality I plan to check it in without that; it can be added later as needed. -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: identifying module types
On Fri, 2006-10-27 at 06:09 +0200, Tristan Gingold wrote: BTW, why not adding a type field for module tag. The type (which should be an UUID IMHO) should indicate the type of the module. One usage could be for Xen. On Xen you can load 3 modules: the linux kernel, the linux ramdisk and an ACM configuration. Xen relies on order and on some magic checks to find the module type. The command syntax could be: module [-type TYPE] file [cmdline] As I'm implementing the Xen side of this, I can now see the need. Xen uses a handful of modules: - xen kernel - dom0 kernel - dom0 initrd - security policy (binary blob) - possibly others On the consumer side of multiboot (in this case Xen), we need to loop over the tags, and when we find a module tag, how do we know which it is? The Multiboot2 spec tells us The order of modules is not guaranteed. (Why not?) If we can't rely on the order, then we have no reliable way to distinguish the type of module we're looking at, so a type field would be extremely useful. For example: multiboot (hd1,1)/xen module -t xenhv-dom0 (hd1,1)/vmlinux module -t xenhv-dom0-initrd (hd1,1)/initrd or multiboot (hd0,0)/boot/gnumach.gz root=device:hd2s1 module -t hurd-something (hd0,0)/lib/ld.so.1 One option is a fixed-length encoded field, say 32 bytes wide. To avoid namespace collisions, we could require that projects prefix types with their project name, which must be at least 4 bytes. Another alternative would be a NULL-terminated string, which would appear in memory just before the NULL-terminated command line, e.g. x e n \0 c o n s o l e = c o m 2 \0 This is more flexible, but slightly more awkward on the consumer side: type = module_tag-text; cmdline = strchr(module_tag-text, '\0') + 1; -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: disk vs partition numbering
On Tue, 2006-12-05 at 20:46 +0100, Yoshinori K. Okuji wrote: Oh, btw, it's HIGHLY confusing that disks start at 0, partitions at 1. Could you please fix it and make it consequently? either hd1,1 or hd0,0, but not hd0,1 or hd1,0. No. It is consistent with most operating systems, so less confusing to the user. GRUB Legacy used 0-based counting for partitions, and I have received an uncountable number of complaints. Thus it is really a bad idea to make GRUB inconsistent against other systems. I am very glad partitions are now numbered from one; that will certainly reduce user confusion (although we should expect complaints from people who know how grub1 works). However, we will now receive lots of complaints, like this one, because disks start at zero but partitions start at one. After all, we've all learned that consistency is critical for good user interface... -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: multiboot2: using tags in the multiboot header
On Tue, 2006-12-05 at 21:23 +0100, Yoshinori K. Okuji wrote: Is it a good spec which forces one to use sample code to be error-free? Please be serious. I'm really not sure why you have such strong objections to this. We're talking about a change that is MINOR in terms of code, but will make the interface cleaner and more convenient for everybody. Please take a step back and consider. -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: multiboot2: make multiboot header optional
On Mon, 2006-12-04 at 21:35 +0100, Marco Gerards wrote: Yoshinori K. Okuji [EMAIL PROTECTED] writes: On Saturday 02 December 2006 17:18, Marco Gerards wrote: What is the problem with typing? I do not think this is really complex? Weird. It was _you_ who pointed out that specifying tags would be annoying on the IRC... I am all for something that is simple. Initially it looked like Hollis' proposal was more complex, but IIRC he mentioned he wanted to work on making this easier to use. Isn't this what he did? Or did I misunderstand something? If someone (Hollis in this case) thinks I am wrong and comes with a good argumentation, I am always willing to change my opinion. I already illustrated how easy it is: MB_HEADER() MB_START_TAGS() MB_LOADADDR(0x1234) MB_ENTRYADDR(0x1234) MB_END_TAGS() Please explain if you think this it too difficult. Note: I refuse to believe that ORing flags into a .long is less complex. -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: multiboot2: make multiboot header optional
On Sat, 2006-12-02 at 18:27 +0100, Yoshinori K. Okuji wrote: Reversely, I ask you a question. What is the real advantage in using tags in a Multiboot header? From my point of view, it is not necessarily very extensible or flexible, as our experience shows that changes to the Multiboot header are rarely demanded (so far, only once, IIRC). It should be pretty clear that 32 bits are a finite number, and tags are unlimited. In fact it's worse than that, since the bit partitioning means we have far fewer available bits for any particular flag. The bit numbering is also confusing, especially the partitioning of meanings (this is required, this is requested, this is arch-specific, this isn't). Finally, using flags for some things and tags for others is inconsistent. The extensibility argument alone is enough to seal it for me, especially since the code can be written in such an error-free manner, as I've demonstrated. -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
grub2 accessibility: beeps
One topic that I've heard a lot about in the past few weeks is
accessibility in grub2. Blind users, who otherwise have various devices
like screen readers and brail TTYs, need to be able to interact with the
bootloader.
This can be as simple as using the PC speaker to beep when GRUB starts,
and also to beep differently (e.g. different pitch, or different number
of beeps) when highlighting different menu entries.
Thanks to Vincent, we already have a PC speaker driver (cool!). However,
we lack the ability to trigger it when switching menu entries (without
selecting one). The problem boils down to this:
menuentry foo {
linux foo
}
The commands inside the menuentry block are only executed when the entry
is selected, not highlighted. Perhaps the menuentry command could be
extended to take an optional beep argument:
menuentry foo pitch duration {
linux foo
}
But wouldn't it be better to have something more general? Something like
menuentry {
title foo
beep pitch duration
}
{
linux foo
}
Thoughts?
-Hollis
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: user-defined hooks
On Thu, 2006-11-30 at 20:50 +0100, Marco Gerards wrote:
Actually, what I would prefer is something hooks. It would be nice if
the C code in GRUB and perhaps also scripts can be hooked anywhere.
We have to be very careful about this, so perhaps limit the sets of
commands that can be used this way. But I think it will make GRUB
more flexible while it is not too much effort.
I like this idea.
I am thinking of the following functions:
One to install a hook:
grub_err_t grub_hook_register (const char *name, (*hook) (...));
To trigger the hook (for example, when the user types something,
selects another menu entry, etc.
void grub_hook_call (const char *name, ...);
How to pass arguments to functions and to scripts is something that we
have to think about. For example, scripting functions have to get
strings, while in other cases we just want to deal with regular
function calls. Perhaps a printf-like mechanism can help us with
this.
I do not think it's important that we be able to hook C functions
directly. In other words, the argument passed to --function (below)
should be a script command (or script function), and not a C function
name.
In that case your problem can be solved by using:
function handlemenu {
beep depending on menuentry selected, the index is passed to this function
}
hook --install --hook=select-menu-entry --function=handlemenu
Defining the set of useful hooks, the arguments passed to each, and
documenting them will be critical. Also, just like with commands, once
we implement a hook we can't remove or change it without breaking config
files.
-Hollis
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Booting MacOSX on powerpc?
On Fri, 2006-12-01 at 12:22 +1100, Aaron Kerr wrote: Heya, To support the development grub2 for powerpc I am testing grub2 from cvs two days ago) on my ibook (G4). I have successfully installed grub2 and can boot into linux. I have been unable to work-out how to boot in to MacOSX. When trying to use chainloader I get the following error message. Booting 'MacOSX' error: unknown command `chainloader' Press any key to continue... Hi Aaron, unfortunately grub2 does not yet support booting Mac OS X. I was working on a loader for it a while back, but didn't get it working and haven't touched it in a while. You can look for the patches in the archives if you're interested in taking a look. -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] multiboot2 loader
On Sun, 2006-11-26 at 11:18 +0100, Tomáš Ebenlendr wrote: There is plenty of precedent here. So I still see nothing wrong with putting a header file, which describes an interface, under a non-GPL license. Because GRUB is not a library. The spec is available independently, so you can write your own header easily. Nothing prevents you from doing this. Okuji And should the multiboot header file be Grub's? What about having Multiboot's header as a part of Multiboot project. Such project should contain only specification, and header file, that can be freely copied. The only thing that should be forbidden is that some third party will claim she owns the header. I think that GPL is too restrictive for this purpose. Such header file can be then added to grub as well as to BSD-licenced and other software. Great point. A multiboot project could easily be created, and wouldn't even need the approval of the GRUB project. Beyond the specification and header file, it could also contain a Hello World multiboot kernel. -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: multiboot2: variable data size
On Wed, 2006-11-22 at 12:55 -0800, Joe Bonasera wrote: If grub2 really needs to make the format/content variant, I would much rather see it vary based on the target OS type. Or better yet, just always use the larger size data types/content - even for 32 bit booting. I agree; I think experience has shown that not changing the data size at all is the best solution. That will also simplify the GRUB implementation, and I will make that change (to code and spec) soon. -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: multiboot2: variable data size
On Sat, 2006-11-25 at 04:10 +0100, Yoshinori K. Okuji wrote: On Saturday 25 November 2006 03:09, Hollis Blanchard wrote: On Wed, 2006-11-22 at 12:55 -0800, Joe Bonasera wrote: If grub2 really needs to make the format/content variant, I would much rather see it vary based on the target OS type. Or better yet, just always use the larger size data types/content - even for 32 bit booting. I agree; I think experience has shown that not changing the data size at all is the best solution. That will also simplify the GRUB implementation, and I will make that change (to code and spec) soon. I disagree. Please don't make such a change. I'm not willing to make difference between i386 and x86_64 in the Multiboot Specification. That's exactly the point: there will be no difference. Both architectures will use 64-bit types. The wording in question is this: a boot loader must follow natural address size which is defined on each architecture a boot loader must define the address size as 32-bit and 64-bit for ELF32 and ELF64, respectively etc. -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: multiboot2: variable data size
On Sat, 2006-11-25 at 05:36 +0100, Yoshinori K. Okuji wrote: On Saturday 25 November 2006 05:08, Hollis Blanchard wrote: OK, I don't have a problem with this. We should clarify the spec. It will limit e.g. module sizes and addresses to less than 4GB, but practically speaking I don't think that is too big a deal. I agree, although I don't know what will happen in the future. ;) In the future we can provide tags like MODULE64, which will use 64-bit values instead of 32-bit. (Maybe a bad example, but you get the idea. :) Along that line of thinking, we should explicitly identify data widths in each tag, rather than a generic everything is 32-bit unless specified otherwise. -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: why I can't build grub under the ubuntu 6.10? Here is the log file.
It is in the top level source directory, next to configure. -Hollis On Tue, 2006-11-21 at 17:27 +0800, zhihang wang wrote: what is autogen.sh? Where can I download it? On 11/21/06, Hollis Blanchard [EMAIL PROTECTED] wrote: On Sat, 2006-11-18 at 22:42 -0500, zhihang wang wrote: configure:2132: checking for C compiler default output file name configure:2135: gccconftest.c 5 as: unrecognized option `--32' This seems to be the problem. I cannot see anything in GRUB that uses this (invalid) switch, so I wonder where it could come from. Does running autogen.sh fix it? -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
multiboot2: remove a.out kludge requirement
One requirement listed for multiboot2 was that ELF headers should be ignored, because NetBSD was setting their ELF addresses incorrectly. This has now been fixed (see http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=32865), so I've removed that requirement. ELF headers tell you where to load an executable far better than the kludge, so it really doesn't make sense to ignore ELF. -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: multiboot2: remove a.out kludge requirement
On Fri, 2006-11-17 at 15:27 -0600, Andrei E. Warkentin wrote: How about having a custom e_type for ELF images booted by GRUB? Something in the range between ET_LOOS and ET_HIOS (the OS specific types). This way one could avoid the Multiboot header in ELF, as the file would itself would identify self as GRUB-bootable or not. Why would we need a custom e_type? We know how to load ELF; we can already omit the multiboot header. Are you worried about a user accidentally running multiboot /bin/ls? I'm not... :) Also... I am not familiar with the module architecture in GRUB2 (whether mods are ET_REL or ET_DYN), but having a custom type for those would sure simplify those code paths too. How would it simplify the code? (Modules are ET_REL, for the record.) -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: multiboot2: remove a.out kludge requirement
That is true. However I'm not sure how easily that field can be modified. Would we need a custom tool for that? Could it be done with a linker script? We are talking specifically about ELF here, so it might make more sense to require a PT_NOTE segment. I'm not sure I agree with Okuji though. If the multiboot header is beyond the 8KB limit, it is an OS programming error, and GRUB cannot be responsible for trying to prevent all programming errors. On the other hand, if this is an error we could catch that would make OS debugging easier, it might be worth it. Right now in my loader I just have a debug message that appears if the header is not found. An OS developer who finds her kernel no longer boots could simply 'set debug=loader' and then boot, and the debug message would indicate the problem (since she knows she's *supposed* to have a multiboot header). I think the debug message solves the debugging issue, and it doesn't burden OSs that don't need the header. -Hollis On Fri, 2006-11-17 at 16:36 -0600, Andrei E. Warkentin wrote: No, I think Okuji mentioned that he didn't want to omit the Multiboot header out of the possibility of not registering the Multiboot header's presence if it is past the 8K mark (i.e. corrupt multiboot kernel). With a custom e_type you could be sure it's really a Multiboot kernel or not... and not ever be concerned with corrupt files with the header past 8K. Andrei Evgenievich Warkentin [EMAIL PROTECTED] Cell: (+1) (847) 321-15-55 On 17.11.2006, at 16:01, Hollis Blanchard wrote: On Fri, 2006-11-17 at 15:27 -0600, Andrei E. Warkentin wrote: How about having a custom e_type for ELF images booted by GRUB? Something in the range between ET_LOOS and ET_HIOS (the OS specific types). This way one could avoid the Multiboot header in ELF, as the file would itself would identify self as GRUB-bootable or not. Why would we need a custom e_type? We know how to load ELF; we can already omit the multiboot header. Are you worried about a user accidentally running multiboot /bin/ls? I'm not... :) Also... I am not familiar with the module architecture in GRUB2 (whether mods are ET_REL or ET_DYN), but having a custom type for those would sure simplify those code paths too. How would it simplify the code? (Modules are ET_REL, for the record.) -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [Fwd: Re: [LinuxBIOS] grub2 as payload
On Thu, 2006-11-16 at 22:57 +0100, Stefan Reinauer wrote: * 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. I don't believe this is currently possible on x86. On PowerPC, the build process creates kernel.elf and *.mod. util/powerpc/ieee1275/grub-mkimage.c then adds the modules to the kernel by creating a new PT_LOAD segment at a well-known address (I'd like that address to be dynamic but don't want to try to rewrite a global in the .data section, and linking twice sucks). On x86, grub-mkimage creates an x86-bootable image, which of course is not an ELF file. * which module contains the int13 disk code ? So I dont accidentially use it. disk/i386/pc/biosdisk.c . However, that's always built in to the core kernel (kernel.img). * 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 serial.mod Helper modules like gzio.mod and fshelp.mod will be pulled in automatically if needed (see moddep.lst, which is used by grub-mkimage). You don't *need* normal.mod. Of course you will need to provide your own disk module to replace biosdisk.mod. * What's the difference between _chain and chain? multiboot and _multiboot? This is really lame and I don't like it at all. _foo is where the real work is done, and it's supposed to be built in to rescue mode, i.e. grub.img. foo is just a wrapper so you can access the same functionality from normal mode. Rescue mode is the small image that can be loaded without needing any modules. It includes the modules needed to load *.mod from a filesystem on a disk, which gets you into normal mode with all the fancy menu and tab-completion. -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: multiboot2: kernel-GRUB communication
On Wed, 2006-11-15 at 09:36 +0100, [EMAIL PROTECTED] wrote: Quoting Hollis Blanchard [EMAIL PROTECTED]: Right now the multiboot2 spec calls for bits to be set in the kernel image to indicate to GRUB that various features are required or requested. I'm trying to come up with a cleaner way. I find all these bits very confusing, actually, and I think it would be more clear if we had something like this instead: [... multiboot header ...] .ascii header_addr: 0xf00 .ascii load_addr: 0x0 .ascii ... (Actually, is it even worth supporting a.out at this point? This particular example may be obsolete.) I am not a big fan of having ascii addresses because it is difficult to generate them from as and almost impossible from ld. OK, good point. -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] multiboot2 loader
On Wed, 2006-11-15 at 22:33 +0200, Yoshinori K. Okuji wrote: On Tuesday 14 November 2006 02:16, Hollis Blanchard wrote: I've placed a generic multiboot.h directly into include/ (not in the grub subdirectory), since it it suitable for using in kernels independently of GRUB. As for the license, I believe that include/multiboot.h should NOT be GPL, to allow it to be used directly for non-GPL operating systems like the BSDs. GRUB is entirely licensed under GPL. Please don't make an exception. An exception is exactly what I am proposing. What is your objection? Actually, we probably want to leave the old x86-only multiboot loader around to allow people to boot multiboot1 kernels... how should we name the two? This is what I had in mind: one multiboot module should provide support for both. Multiboot Specification version 2 is (and must be) a superset of features found in version 0.x. So we should implement support version 2 first, and translate Multiboot information if a kernel is for version 0.x. I'm not sure translation makes sense, but we can probably share a lot of the code. -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] multiboot2 loader
On Thu, 2006-11-16 at 00:15 +0200, Yoshinori K. Okuji wrote: On Wednesday 15 November 2006 22:10, Hollis Blanchard wrote: On Wed, 2006-11-15 at 22:33 +0200, Yoshinori K. Okuji wrote: On Tuesday 14 November 2006 02:16, Hollis Blanchard wrote: I've placed a generic multiboot.h directly into include/ (not in the grub subdirectory), since it it suitable for using in kernels independently of GRUB. As for the license, I believe that include/multiboot.h should NOT be GPL, to allow it to be used directly for non-GPL operating systems like the BSDs. GRUB is entirely licensed under GPL. Please don't make an exception. An exception is exactly what I am proposing. What is your objection? The GNU Project endorses the use of GPL to promote freedom. Don't forget that GRUB is a part of GNU. The GNU project also includes GCC, which is used to build non-Free software. In fact GCC even contains libgcc, which is *linked* with non-free software. The GNU project also includes glibc, which is linked with (almost?) all non-Free software on Linux. The GNU project also uses the LGPL license, which allows all sorts of Free software to be used with non-Free software. GRUB itself is used to boot non-Free operating systems. There is plenty of precedent here. So I still see nothing wrong with putting a header file, which describes an interface, under a non-GPL license. -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: does disk geometry depend on partition table?
On Tue, 2006-11-14 at 13:03 +0800, Zhixu Liu wrote: Hi, Hollis, We've tried something like this, and found it works for some platform, but still failed for one platform. Indeed, in this weird platform, we get both wrong CHS value with and without partition table. But the OS always get the correct value. The problem is due to either BIOS or Disk for this particular platform, we think. But we're not clear. That platform must have a BIOS bug and we have no known workaround. :/ Anyway, the patch works for some cases, and should for most cases. OK. I will commit this soon unless I hear an objection. -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
multiboot2: kernel-GRUB communication
Right now the multiboot2 spec calls for bits to be set in the kernel image to indicate to GRUB that various features are required or requested. I'm trying to come up with a cleaner way. I find all these bits very confusing, actually, and I think it would be more clear if we had something like this instead: [... multiboot header ...] .ascii header_addr: 0xf00 .ascii load_addr: 0x0 .ascii ... (Actually, is it even worth supporting a.out at this point? This particular example may be obsolete.) Video mode information: .ascii vga_mode: text .ascii columns: 80 .ascii rows: 24 Thoughts? -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
multiboot2: make multiboot header optional
I would like to make the in-kernel multiboot header optional. If it's an ELF file, we can load it, even if it doesn't have the header. We can also pass the address of the multiboot tags to its entry point (it can't hurt anything). For kernels that need to communicate information to GRUB (e.g. vga_mode from my previous email, or a.out load addresses), the multiboot header would be needed for GRUB to locate the parameter area within the executable. -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Cross compiling GRUB 1.95
On Sun, 2006-11-05 at 16:24 -0500, Will Buik wrote:
I am trying to cross compile GRUB 1.95 from an i686 linux system to an
i686 linux uclibc system. However, when I run the configure script I
get the error:
checking if GCC has the regparm=3 bug... configure: error: cannot run
test program while cross compiling
How can I bypass this test or otherwise get it to compile?
Hmm. From the documentation
(http://www.gnu.org/software/autoconf/manual/html_node/Runtime.html), I
would expect something like the following to work:
Index: aclocal.m4
===
RCS file: /cvsroot/grub/grub2/aclocal.m4,v
retrieving revision 1.5
diff -u -p -r1.5 aclocal.m4
--- aclocal.m4 13 Aug 2005 18:44:14 - 1.5
+++ aclocal.m4 14 Nov 2006 03:14:21 -
@@ -327,6 +327,7 @@ main (void)
}
]])],
[grub_cv_i386_check_nested_functions=no],
+ [grub_cv_i386_check_nested_functions=yes],
[grub_cv_i386_check_nested_functions=yes])])
AC_MSG_RESULT([$grub_cv_i386_check_nested_functions])
Even worse though, it seems this test is totally ignored -- regparm(2)
is always used, no matter the outcome. So perhaps we should do this
instead:
Index: aclocal.m4
===
RCS file: /cvsroot/grub/grub2/aclocal.m4,v
retrieving revision 1.5
diff -u -p -r1.5 aclocal.m4
--- aclocal.m4 13 Aug 2005 18:44:14 - 1.5
+++ aclocal.m4 14 Nov 2006 03:17:44 -
@@ -291,55 +291,3 @@ else
fi
])
-dnl Check if the C compiler has a bug while using nested functions when
-dnl mregparm is used on the i386. Some gcc versions do not pass the third
-dnl parameter correctly to the nested function.
-dnl Written by Marco Gerards.
-AC_DEFUN(grub_I386_CHECK_REGPARM_BUG,
-[AC_REQUIRE([AC_PROG_CC])
-AC_MSG_CHECKING([if GCC has the regparm=3 bug])
-AC_CACHE_VAL(grub_cv_i386_check_nested_functions,
-[AC_RUN_IFELSE([AC_LANG_SOURCE(
-[[
-static int
-test (int *n)
-{
- return *n == -1;
-}
-
-static int
-testfunc (int __attribute__ ((__regparm__ (3))) (*hook) (int a, int b, int
*c))-{
- int a = 0;
- int b = 0;
- int c = -1;
- return hook (a, b, c);
-}
-
-int
-main (void)
-{
- int __attribute__ ((__regparm__ (3))) nestedfunc (int a, int b, int *c)
-{
- return a == b test (c);
-}
- return testfunc (nestedfunc) ? 0 : 1;
-}
-]])],
- [grub_cv_i386_check_nested_functions=no],
- [grub_cv_i386_check_nested_functions=yes])])
-
-AC_MSG_RESULT([$grub_cv_i386_check_nested_functions])
-
-if test x$grub_cv_i386_check_nested_functions = xyes; then
- AC_DEFINE([NESTED_FUNC_ATTR],
- [__attribute__ ((__regparm__ (2)))],
- [Catch gcc bug])
-else
-dnl Unfortunately, the above test does not detect a bug in gcc-4.0.
-dnl So use regparm 2 until a better test is found.
- AC_DEFINE([NESTED_FUNC_ATTR],
- [__attribute__ ((__regparm__ (2)))],
- [Catch gcc bug])
-fi
-])
Index: configure.ac
===
RCS file: /cvsroot/grub/grub2/configure.ac,v
retrieving revision 1.33
diff -u -p -r1.33 configure.ac
--- configure.ac12 Jul 2006 20:42:52 - 1.33
+++ configure.ac14 Nov 2006 03:17:44 -
@@ -253,7 +253,13 @@ if test x$target_cpu = xi386; then
grub_I386_ASM_PREFIX_REQUIREMENT
grub_I386_ASM_ADDR32
grub_I386_ASM_ABSOLUTE_WITHOUT_ASTERISK
- grub_I386_CHECK_REGPARM_BUG
+
+ # Check if the C compiler has a bug while using nested functions when
+ # mregparm is used on the i386. Some gcc versions do not pass the third
+ # parameter correctly to the nested function.
+ AC_DEFINE([NESTED_FUNC_ATTR],
+ [__attribute__ ((__regparm__ (2)))],
+ [Catch gcc bug])
else
AC_DEFINE([NESTED_FUNC_ATTR], [], [Catch gcc bug])
fi
But wait, it gets even better! It turns out there are almost no users of
NESTED_FUNC_ATTR in grub2; only a few filesystems use it. If it only
affects nested functions with three or more arguments, then at least
functions like read_blocklist() would be broken. (If it affects all
nested functions, then almost everything is broken.)
Some attention is needed here from people who know what NESTED_FUNC_ATTR
is supposed to be doing.
-Hollis
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: cygwin objcopy failure
On Thu, 2006-11-02 at 16:24 +0900, Brandon Sho wrote: Is it possible that the configure script testing for absoluteness is wrong? Or that cygwin can not handle absolutes (which is nonsense since thats machine level). As it turns out, the absolute message is a red herring; I don't know why it says that. The test is really, for executables linked at 0x2000, 0x8000, and 0x7c00, does objcopy -O binary work? What is the objcopy error in your configure.log? -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: __unused
On Wed, 2006-11-01 at 13:48 +0100, Johan Rydberg wrote:
Hollis Blanchard [EMAIL PROTECTED] writes:
--- grub2-cvs.orig/include/grub/types.h 2006-10-31 19:06:47.0
-0600
+++ grub2-cvs/include/grub/types.h 2006-10-31 19:06:58.0 -0600
@@ -23,6 +23,8 @@
#include config.h
#include grub/cpu/types.h
+#define __unused __attribute__ ((unused))
+
First when I saw this it made me wanna comment on it, and tell you
that defines should all be in uppercase. But then I poked through the
code, and saw the usage of it, and it looked quite nice, with the
exception of the __-prefix. There are a lot of common words that
are keywords in C; inline, const and auto for example. Maybe we
should make unused a reserved keyword in GRUB? That would allow
us to write code like;
I left it as __unused for now, to match Linux's usage. (We can change
it later if needed.)
int
grub_foo (int x, unused int foo)
{
...
}
I believe gcc attributes can't be used as naturally as this; it would
have to be int unused foo or int unused *foo (from memory).
-Hollis
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] generic ELF loading #3
On Thu, 2006-11-02 at 21:58 +0200, Yoshinori K. Okuji wrote: On Wednesday 01 November 2006 02:23, Hollis Blanchard wrote: Here is pass #3 of the ELF loader. Changes from #2: - the `load' callback no longer modifies the phdr directly I still don't understand why you want to pass a hook. Why don't you simply pass a load address? How do I know what the load address should be before I've even looked at the program header? Just because the x86 loader uses fixed values doesn't mean other loaders should. In particular, the PowerPC loader is happy to load the ELF file wherever it likes, as long as that memory isn't in use. -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] generic ELF loading (updated)
On Mon, 2006-10-30 at 21:19 +0200, Yoshinori K. Okuji wrote: On Saturday 28 October 2006 20:35, Hollis Blanchard wrote: On Sat, 2006-10-28 at 16:16 +0200, Yoshinori K. Okuji wrote: On Friday 27 October 2006 21:19, Hollis Blanchard wrote: Comments please. Also see next mail to see how the PPC Linux loader uses it. So this still loads an image to paddr directly, right? I think we need these features: - an ability to pass an address to load an image - an ability to pass the size of a loading area - an ability to get the size of a loaded image The PowerPC loader patch I sent already does 1 and 3, and you can easily see how 2 can be done in the exact same way. Please look at that code, in particular 'calcsize' and 'offset_paddr'. As for calcsize, I do not think it is a good idea to put this to architecture-specific code. We always need this feature, so it should be a part of the API. As for offset_paddr, I do not like modifying a member of a header. This changes a read value, so the state of a header changes after calling grub_elf*_load. This kind of side effect often makes debugging harder. I prefer to specify an address more explicitly. What exactly would you suggest? Using a hook to modify the struct phdr (or veto it) seems quite elegant to me. -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: some multiboot2 comments
On Mon, 2006-10-30 at 21:15 +0200, Yoshinori K. Okuji wrote: On Saturday 28 October 2006 20:32, Hollis Blanchard wrote: Are you saying that given tag-key == foo, tag-length == sizeof(struct tag_foo)? I think it makes far more sense to allow 'length' to be independent of 'key', and that means we don't need this 'reserved' stuff. 'length' is sometimes somehow independent. When passing data whose size is variable, 'length' specifies the size. The size of an item is indirectly defined by 'length'. The size of an item can be different from the size of data, because of a padding for an alignment. That definition doesn't take advantage of the flexibility 'length' could give us. We should be able to use arbitrary values for 'length', even when the tag structure size is well-defined. There is no reason not to... -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] generic ELF loading (updated)
On Sat, 2006-10-28 at 16:16 +0200, Yoshinori K. Okuji wrote: On Friday 27 October 2006 21:19, Hollis Blanchard wrote: Comments please. Also see next mail to see how the PPC Linux loader uses it. So this still loads an image to paddr directly, right? I think we need these features: - an ability to pass an address to load an image - an ability to pass the size of a loading area - an ability to get the size of a loaded image The PowerPC loader patch I sent already does 1 and 3, and you can easily see how 2 can be done in the exact same way. Please look at that code, in particular 'calcsize' and 'offset_paddr'. -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] generic ELF loading (updated)
Here is the updated ELF loading infrastructure. A couple notes: It is now a module, which will be auto-loaded by loaders that need it. However, I don't know where to put elf.c. The only similar files are io/gzio.c and fs/fshelp.c, but clearly elf.c doesn't belong in either of those directories. I have not updated i386/pc/multiboot.c to use this. That file needs refactoring for multiboot2 anyways, so the work I'm doing for multiboot2 will replace that loader. Comments please. Also see next mail to see how the PPC Linux loader uses it. (Sorry about the .mk noise.) -Hollis Index: grub2-cvs/conf/i386-efi.mk === --- grub2-cvs.orig/conf/i386-efi.mk 2006-10-27 13:38:45.0 -0500 +++ grub2-cvs/conf/i386-efi.mk 2006-10-27 13:54:46.0 -0500 @@ -486,9 +486,9 @@ fs-kernel_mod-disk_efi_efidisk.lst: disk set -e; $(TARGET_CC) -Idisk/efi -I$(srcdir)/disk/efi $(TARGET_CPPFLAGS) $(TARGET_CFLAGS) $(kernel_mod_CFLAGS) -E $ | sh $(srcdir)/genfslist.sh kernel $@ || (rm -f $@; exit 1) -kernel_mod_HEADERS = arg.h boot.h device.h disk.h dl.h elf.h env.h err.h \ - file.h fs.h kernel.h loader.h misc.h mm.h net.h parser.h partition.h \ - pc_partition.h rescue.h symbol.h term.h types.h \ +kernel_mod_HEADERS = arg.h boot.h cache.h device.h disk.h dl.h elf.h elfload.h \ + env.h err.h file.h fs.h kernel.h loader.h misc.h mm.h net.h parser.h \ + partition.h pc_partition.h rescue.h symbol.h term.h types.h \ i386/efi/time.h efi/efi.h efi/time.h efi/disk.h kernel_mod_CFLAGS = $(COMMON_CFLAGS) kernel_mod_ASFLAGS = $(COMMON_ASFLAGS) Index: grub2-cvs/conf/i386-efi.rmk === --- grub2-cvs.orig/conf/i386-efi.rmk2006-10-27 13:38:45.0 -0500 +++ grub2-cvs/conf/i386-efi.rmk 2006-10-27 13:54:46.0 -0500 @@ -43,7 +43,8 @@ grub_emu_SOURCES = commands/boot.c comma fs/affs.c fs/ext2.c fs/fat.c fs/fshelp.c fs/hfs.c fs/iso9660.c \ fs/jfs.c fs/minix.c fs/sfs.c fs/ufs.c fs/xfs.c fs/hfsplus.c \ io/gzio.c \ - kern/device.c kern/disk.c kern/dl.c kern/env.c kern/err.c \ + kern/device.c kern/disk.c kern/dl.c kern/elf.c kern/env.c \ + kern/err.c \ normal/execute.c kern/file.c kern/fs.c normal/lexer.c \ kern/loader.c kern/main.c kern/misc.c kern/parser.c \ grub_script.tab.c kern/partition.c kern/rescue.c kern/term.c\ @@ -76,9 +77,9 @@ kernel_mod_SOURCES = kern/i386/efi/start kern/i386/dl.c kern/i386/efi/init.c kern/parser.c kern/partition.c \ kern/env.c symlist.c kern/efi/efi.c kern/efi/init.c kern/efi/mm.c \ term/efi/console.c disk/efi/efidisk.c -kernel_mod_HEADERS = arg.h boot.h device.h disk.h dl.h elf.h env.h err.h \ - file.h fs.h kernel.h loader.h misc.h mm.h net.h parser.h partition.h \ - pc_partition.h rescue.h symbol.h term.h types.h \ +kernel_mod_HEADERS = arg.h boot.h cache.h device.h disk.h dl.h elf.h elfload.h \ + env.h err.h file.h fs.h kernel.h loader.h misc.h mm.h net.h parser.h \ + partition.h pc_partition.h rescue.h symbol.h term.h types.h \ i386/efi/time.h efi/efi.h efi/time.h efi/disk.h kernel_mod_CFLAGS = $(COMMON_CFLAGS) kernel_mod_ASFLAGS = $(COMMON_ASFLAGS) Index: grub2-cvs/conf/i386-pc.mk === --- grub2-cvs.orig/conf/i386-pc.mk 2006-10-27 13:38:45.0 -0500 +++ grub2-cvs/conf/i386-pc.mk 2006-10-27 13:54:46.0 -0500 @@ -162,9 +162,9 @@ kernel_img-symlist.o: symlist.c $(TARGET_CC) -I. -I$(srcdir)/. $(TARGET_CPPFLAGS) $(TARGET_CFLAGS) $(kernel_img_CFLAGS) -MD -c -o $@ $ -include kernel_img-symlist.d -kernel_img_HEADERS = arg.h boot.h device.h disk.h dl.h elf.h env.h err.h \ - file.h fs.h kernel.h loader.h misc.h mm.h net.h parser.h partition.h \ - pc_partition.h rescue.h symbol.h term.h types.h \ +kernel_img_HEADERS = arg.h boot.h cache.h device.h disk.h dl.h elf.h elfload.h \ + env.h err.h file.h fs.h kernel.h loader.h misc.h mm.h net.h parser.h \ + partition.h pc_partition.h rescue.h symbol.h term.h types.h \ machine/biosdisk.h machine/boot.h machine/console.h machine/init.h \ machine/memory.h machine/loader.h machine/time.h machine/vga.h \ machine/vbe.h Index: grub2-cvs/conf/i386-pc.rmk === --- grub2-cvs.orig/conf/i386-pc.rmk 2006-10-27 13:38:45.0 -0500 +++ grub2-cvs/conf/i386-pc.rmk 2006-10-27 13:54:46.0 -0500 @@ -30,9 +30,9 @@ kernel_img_SOURCES = kern/i386/pc/startu kern/env.c disk/i386/pc/biosdisk.c \ term/i386/pc/console.c \ symlist.c -kernel_img_HEADERS = arg.h boot.h device.h disk.h dl.h
Re: [Fwd: Re: [LinuxBIOS] grub2 as payload
On Wed, 2006-10-25 at 21:31 +0200, Tristan Gingold wrote: If you are interested, I have written an IDE driver for grub. Not complete but working. Does it support CD-ROMs? That seems to be the most important issue, because it's a serious usability problem on legacy BIOS. Have you worked out your copyright assignment? -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] generic ELF loading
On Sat, 2006-10-14 at 17:33 +0200, Yoshinori K. Okuji wrote:
On Saturday 14 October 2006 00:37, Hollis Blanchard wrote:
This patch adds generic ELF loading infrastructure for both 32-bit and
64-bit ELF. It provides an iterate function for program headers, and a
load function for convenience.
The idea is very good. But I don't like that loaded areas are always
allocated
from the heap. GRUB has a staging area for OS images on i386-pc, and I prefer
to load an image directly instead of consuming the heap.
Actually I'm not using the heap, I'm just directly copying wherever
phdr-p_paddr says to. That's not a good thing actually; in the future
we should add some error checking to make sure we don't clobber GRUB
itself.
Also, I made sure that the load hook could veto loading each segment. So
the x86 loader would do something like this:
int x86_load_hook (Elf32_Phdr *phdr)
{
if (phdr-p_paddr not in x86 OS load area)
return 1;
return 0;
}
grub_elf32_load (elf, x86_load_hook);
-Hollis
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: multiboot for PowerPC
On Fri, 2006-10-13 at 15:06 -0500, Andrei E. Warkentin wrote: I just stalk this mailing list, but I think it'd be great to turn the Multiboot specification less PC BIOS-centric. The Multiboot spec exposes various legacy structures for the x86 PC. How do you intend to work in platform specifics? Just expose the OF interface, or clone the device tree? What about non-OF systems? Have you read the wiki page? http://grub.enbug.org/MultibootDraft I don't intend to put any Open Firmware information into the multiboot structure, since OF will still be live when the OS is executed. Slightly OT, but has any work been done to make Multiboot ia32/x64 EFI-friendly? Should be the same situation I guess. -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Scripting (IMPORTANT!)
On Thu, 2006-10-05 at 15:41 +0200, Marco Gerards wrote: I'm looking forwards to your ideas, questions, suggestions, criticism and bug reports. :-) How hard do you think it will be to implement all these features (and handle the bugs)? I wonder if we wouldn't be better served by a simpler scripting language, rather than trying to emulate bash. -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: how to increase commandline size (patch + changelog)
On Tue, 2006-10-10 at 09:03 +0800, Jeff Chua wrote: +#include asm/param.h I don't think this is a good idea because it requires we build on a Linux host. -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: how to increase commandline size (patch + changelog)
On Tue, 2006-10-10 at 11:08 +0800, Jeff Chua wrote: On Mon, 9 Oct 2006, Hollis Blanchard wrote: +#include asm/param.h I don't think this is a good idea because it requires we build on a Linux host. Shall I use '#ifdef __linux__' to include asm/param.h only on linux, and '#define COMMAND_LINE_SIZE 255' for non-linux system? Well, does this number change often? If not, let's just copy it. If so, then we're screwed anyways because asm/param.h would only match the installed kernel's limit, so may not work for other kernel versions. In that case, let's just copy it and shrink it in a lowest common denominator approach. -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Scripting - write to HD support?
On Fri, 2006-10-06 at 20:43 +0200, Marco Gerards wrote: Markus Laire [EMAIL PROTECTED] writes: On 10/5/06, Marco Gerards [EMAIL PROTECTED] wrote: I'm looking forwards to your ideas, questions, suggestions, criticism and bug reports. :-) Will there be any support for writing data to HD? Even a simple support for writing some data to HD would allow quite a lot of ideas to be implemented in grub which would be impossible with read-only access. I agree this would be a great feature. The disk support in GRUB 2 supports writing to disk. However, it is not used. Full support for writing to filesystems is likely far too much to ask. Right. But what about a possibility to create a certain file in advance (e.g. /boot/grub/mydata filled with e.g. 1MB of zeroes) and then an ability to write to that file without changing the size of the file. Writing zero's reliable. For example, filesystem implementations might change this into a sparse file. Another problem could be reiserfs, which stores metadata and data in the same sectors, IIRC. So instead of using zero's, we could of course use ones. For reiserfs we would have to look how big the file has to be to make sure metadata won't share this sector. But still, it is something we have to be extremely careful with. And a more important question is: Why do you want this, do you have specific uses for such feature in mind? I can think of things like fallback, etc. Yeah, we should focus on enabling some specific features. Alternative idea would be to create a partition (without any filesystem) specifically for saving some data from grub, and then grub would just give a read/write access to that partition as a single block of data. I don't like this, it will make it hard or impossible to install GRUB on certain systems. I like this; it's nice and simple. It's also similar to the situation with Open Firmware and NVRAM. This approach could extend to NVRAM on other systems as well... Systems without a free partition just wouldn't be able to take advantage of the feature. -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Grub for ia64 - function descriptors
On Tue, 2006-10-03 at 06:04 +0200, [EMAIL PROTECTED] wrote: Selon Hollis Blanchard [EMAIL PROTECTED]: On Mon, 02 Oct 2006 08:31:10 +0200, [EMAIL PROTECTED] said: Quoting Hollis Blanchard [EMAIL PROTECTED]: [...] I assume IA64 is similar here, and given that, a module_jump function implemented in assembly by each architecture would solve this problem. I'd prefer modules to export pointers. Seems to be easier to deal. I don't know what you mean; please elaborate (with pseudo-code if possible). I'd propose modules export struct grub_dl. This struct contains init and fini functions pointers. Getting the address of a data structure is much more portable. Dealing with function pointers would be a matter of the relocator. It looks like this is only done twice in the current code: mod-init and mod-fini. Wouldn't it be easy to do this: --- kern/dl.c 28 May 2006 23:01:43 - 1.12 +++ kern/dl.c 3 Oct 2006 02:15:51 - @@ -380,9 +380,9 @@ grub_dl_resolve_symbols (grub_dl_t mod, return grub_errno; if (grub_strcmp (name, grub_mod_init) == 0) - mod-init = (void (*) (grub_dl_t)) sym-st_value; + mod-init = grub_dl_arch_func (sym-st_value); else if (grub_strcmp (name, grub_mod_fini) == 0) - mod-fini = (void (*) (void)) sym-st_value; + mod-fini = grub_dl_arch_func (sym-st_value); break; case STT_SECTION: To create descriptor, grub_dl_arch_func have to grub_malloc memory. How to free it ? What about this: grub_dl_arch_func(mod-init, sym-st_value); I always prefer to use static memory when I can do that: code is smaller and safer. That's the reason why I'd prefer to have struct grub_dl declared static. Of course this is just my opinion. Sure, and I'm not really opposed to exporting a struct grub_dl from modules; I'm just trying to make sure we don't overcomplicate what could be a simple change. Do you have a patch illustrating your idea? -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Grub for ia64 - function descriptors
On Mon, 02 Oct 2006 08:31:10 +0200, [EMAIL PROTECTED] said: Quoting Hollis Blanchard [EMAIL PROTECTED]: On Fri, 2006-09-29 at 08:59 +0200, [EMAIL PROTECTED] wrote: Quoting Hollis Blanchard [EMAIL PROTECTED]: On Thu, 2006-09-28 at 15:45 +0200, [EMAIL PROTECTED] wrote: if (grub_strcmp (name, grub_mod_init) == 0) mod-init = (void (*) (grub_dl_t)) sym-st_value; This won't work on ia64 AFAIK. Can't this problem be solved with an architecture-specific macro? FWIW, 64-bit PowerPC also uses function descriptors. They look something like: long code_address long table_of_contents long unused The table_of_contents (TOC) value needs to be placed into r2 when jumping at code_address (and of course the old one needs to be restored when returning). Indeed, same issue. I assume IA64 is similar here, and given that, a module_jump function implemented in assembly by each architecture would solve this problem. I'd prefer modules to export pointers. Seems to be easier to deal. I don't know what you mean; please elaborate (with pseudo-code if possible). I'd propose modules export struct grub_dl. This struct contains init and fini functions pointers. Getting the address of a data structure is much more portable. Dealing with function pointers would be a matter of the relocator. It looks like this is only done twice in the current code: mod-init and mod-fini. Wouldn't it be easy to do this: --- kern/dl.c 28 May 2006 23:01:43 - 1.12 +++ kern/dl.c 3 Oct 2006 02:15:51 - @@ -380,9 +380,9 @@ grub_dl_resolve_symbols (grub_dl_t mod, return grub_errno; if (grub_strcmp (name, grub_mod_init) == 0) - mod-init = (void (*) (grub_dl_t)) sym-st_value; + mod-init = grub_dl_arch_func (sym-st_value); else if (grub_strcmp (name, grub_mod_fini) == 0) - mod-fini = (void (*) (void)) sym-st_value; + mod-fini = grub_dl_arch_func (sym-st_value); break; case STT_SECTION: -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Grub for ia64 - function descriptors
On Fri, 2006-09-29 at 08:59 +0200, [EMAIL PROTECTED] wrote: Quoting Hollis Blanchard [EMAIL PROTECTED]: On Thu, 2006-09-28 at 15:45 +0200, [EMAIL PROTECTED] wrote: if (grub_strcmp (name, grub_mod_init) == 0) mod-init = (void (*) (grub_dl_t)) sym-st_value; This won't work on ia64 AFAIK. Can't this problem be solved with an architecture-specific macro? FWIW, 64-bit PowerPC also uses function descriptors. They look something like: long code_address long table_of_contents long unused The table_of_contents (TOC) value needs to be placed into r2 when jumping at code_address (and of course the old one needs to be restored when returning). Indeed, same issue. I assume IA64 is similar here, and given that, a module_jump function implemented in assembly by each architecture would solve this problem. I'd prefer modules to export pointers. Seems to be easier to deal. I don't know what you mean; please elaborate (with pseudo-code if possible). -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to install a module into the kernel
On Thu, 2006-09-21 at 08:51 +0800, 袁源 wrote: hi, recently I have been working under grub2. I wrote some of my own modules and I don't know how to add it to the grub2 kernel (I mean how to pack it to the core.img,not using the command :insmod).I tried to find ways through the Internet but i got none. I am very glad if you can help me solve this. Hi, welcome! It looks like you need to add your files to kernel_img_SOURCES in conf/*.rmk. Could you tell us more about the modules you've written? Why do you need to have them built in? In other words, why can't you use insmod? Are they block device drivers? -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: unused elf fields
On Wed, 2006-09-20 at 15:22 +0530, kanishk rastogi wrote: hi all, are there any unused fiels in the os ELF image which will not be used by the grub in any of the ELF headers any references will be helpful thanks in advance What are you trying to do? -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub 2 on debian amd64
On Mon, 2006-09-25 at 19:42 -0700, Colin Lamarre wrote: Hi, I set out to install grub 2 on a debian/amd64, win2k, xp machine just for fun, kinda like the jackass of computing. I don't see any simple way, has anyone put together an easy 2 step proc yet? Kew code btw, must be difficult to debug, good luck! Have you seen the wiki at http://grub.enbug.org ? -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Let core developers vote to accept patches.
On Tue, 2006-08-15 at 00:37 +0200, Johan Rydberg wrote: Hi, In other projects that I've worked on, we've used a system where the core developers can either give a +1 or a -1 on a contributed patch. If a patch receives two +1's or more, it is accepted (if there are no -1's) and committed by one of the developers. I think this idea makes a lot of sense. -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Support for reading LVM volumes
On Sun, 2006-08-13 at 17:13 +0200, Jeroen Dekkers wrote: I've just commited the code for reading LVM volumes. The only issue that I know of is that it currently doesn't support reading snapshot volumes. All the normal LVM volumes (striped and linear) are supported however. Very nice. :) I'm going to work on adding support for LVM to grub-setup now. That's the last remaining thing in my SoC project. What will happen to the google-soc2006 CVS branch when you're done? -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Support for reading LVM volumes
On Sun, 2006-08-13 at 20:23 +0200, Jeroen Dekkers wrote: At Sun, 13 Aug 2006 11:49:06 -0500, Hollis Blanchard wrote: What will happen to the google-soc2006 CVS branch when you're done? It should be merged into the mainline. Well, of course. :) My question wasn't what _should_ happen? but rather what _will_ happen?. Who is going to do this? Does this fall outside the scope of your SoC project? I understand that branches in CVS are extremely cumbersome, so will this be a difficult process? -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Let GCC generate deps with -MD.
On Sat, 2006-08-12 at 18:07 +0200, Johan Rydberg wrote: Instead of generating the dependencies separately it can be done the first time a file is compiled, with the -MD option to GCC. Just curious... does this solve the problem that occurs when you delete a .c file? -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: I want to contribute...
On Fri, 2006-08-11 at 14:58 +0200, Marco Gerards wrote: Karuppuswamy Thangaraj - TLS , Chennai [EMAIL PROTECTED] writes: Hi, I am a newbie to GRUB mailing list. I am interested in open source OS and applications. So far I have been a user in open source. Now I want to contribute something for my pleasure of coding, so that it **may** :-) be useful for others also. How to start. Since I am more interested in low level coding stuff (and also a regular GRUB user), I selected GRUB to contribute. Here is my profile: If you want to get started, just download the GRUB 2 sourcecode from CVS, play a bit with it and when you find a bug or missing feature you can just start in sending patches. For details on how to send in patches (ChangeLog entries, style, indentation, etc) just have a look at the GNU Coding Standards document or feel free to ask me when you are not sure. Be sure to check out the wiki pages that help you get started: http://grub.enbug.org/TestingOnX86 http://grub.enbug.org/TestingOnPowerPC I would start by installing and using GRUB2, and then you'll doubtless find things that could be improved (from installation process to user interface to missing functionality). -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC][PATCH] vmlinux/vmlinux.bin loading capability
On Thu, 2006-08-03 at 00:57 -0600, Maciek Nowacki wrote: Here is an attempt at a patch to load and execute a vmlinux kernel image, only tested with QEMU for x86_64. It is very preliminary, excludes a large amount of planned functionality, and so far only boots the raw vmlinux.bin file found in arch/[x86_64,i386]/boot/vmlinux.bin after compiling Linux with the 'make vmlinux' target (and 'make bzImage' as well). This means that the user must supply the entry point of the kernel on the GRUB command line. This nastiness will be easily removed once vmlinux is used in place of vmlinux.bin. vmlinux.bin is a derivative of the vmlinux kernel executable that is produced by: objcopy -O binary linux-2.6.xx/vmlinux vmlinux.bin I have no comments on your motivation, but I do think that a binary loader would be valuable. In that case, it might make sense to refactor this code into a binary loader that exports a function that your Linux binary loader calls. Then you can isolate all this linux_kernel_header stuff from the binary loader. You want to combine these lines: + asm( movl %0,%%esi :: m (lh) ); + asm(jmp *%0 :: m (begin)); into a single asm statement (and make it volatile too). Otherwise, the compiler can insert instructions between the asm statements (especially at -O0), making you a very sad debugger. There are pretty flagrant coding style violations all over the place, so I won't comment on those. I will however say that /* notes: grub leaks memory. */ is an extraordinarily bad way to submit a bug report. Finally, please don't call this a vmlinux loader. vmlinux is an ELF file. What you're loading is not. -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Build environment
On Sat, 2006-08-05 at 05:16 -0700, Jeff Bailey wrote: I'll start by saying that I have nothing but hate for the build environment in grub2. In general I'd agree with that. I realise that automake can be equally confusing in many ways, but it has two main advantages: 1) Everyone knows it already, 2) Other people are helping solve bugs with it. As far as I've seen, most projects using automake barely understand it. Everyone knows it already sounds like a huge overstatement to me. Assuming that we're stuck with this, is it home grown or is there some upstream project using it? The types of problems that I've seen: It seems to be some homegrown Ruby that Okuji wrote. * No autodetection of Makefile snippet, to auto update them. No generic rules to handle the updating when testing. * No obvious well to tell how it's getting to any given phase. No documentation. * Dependancy generation is run too early. Initial dependancies are broken. * No obvious way to add dependancies to specific files that need them. * Order in .mk files is important even for seemingly unrelated clauses. Adding or deleting files results in incredibly frustrating can't find .d file messages, even when trying to run make clean! That one has caused me a lot of aggravation. The build system for grub2 just gets in the way of coding the program itself. I have a working version of grub-emu now for hppa-ipl, but most of my coding time has been spent staring at Makefiles, wondering how the other targets work, and copying segments of .rmk files that are essentially identical in other files. Done right, I suspect that I could've done the port to this point in about 4 lines of Makefile snippet. I agree, there is also a huge amount of duplication in the mk files. They can and should be refactored to simplify them. I've hated the build system for years, and the fact that none of the people in #grub seem to understand it either doesn't help. I've offered to fix it up using the usual set of autotools a number of times, and the offer still stands. I'm no fan of autotools. -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Port to hppa-ipl
On Sat, 2006-08-05 at 05:37 -0700, Jeff Bailey wrote: +fstd,ma %fr12,8(%r19) +fstd,ma %fr13,8(%r19) +fstd,ma %fr14,8(%r19) +fstd,ma %fr15,8(%r19) +fstd,ma %fr16,8(%r19) +fstd,ma %fr17,8(%r19) +fstd,ma %fr18,8(%r19) +fstd,ma %fr19,8(%r19) +fstd,ma %fr20,8(%r19) +fstd %fr21,0(%r19) Are those floating point stores? Is that really needed? For reference, the PowerPC port builds with -msoft-float, for a couple reasons: - there are some PPC without FPUs (though admittedly none that run GRUB right now) - on PPC with FPUs, with some firmwares you need to go out of your way to enable it via assembly in _start In general it doesn't seem like there's any need for FPU in GRUB, so we just don't use it. -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Regarding Documentation
On Thu, 2006-06-29 at 11:41 +0530, pragun goyal wrote: I noticed that GRUB2 lacks docs , howtos and other things. I am not a programmer. But i want to contribute to grub2 by helping in writing docs. There is some information in the wiki (in the Testing pages) that should help get you started. (For example, there are some sample config files.) -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [patch] Fix for building correct code on i386-pc (CVS-HEAD)
On Wed, 2006-05-31 at 00:08 +0300, Vesa Jääskeläinen wrote: Attached patch fixes problems for compiling correct code on i386-pc... other platforms needs to be modified similarly too... I'm confused by this; could you explain? If _TARGET_CFLAGS is used for everything to be run on the target, perhaps we should just rename _CFLAGS to _TARGET_CFLAGS. Also, in the future, could you please supply best-guess code for other architectures? It's ok if you don't know, but in this case it seems it would be easy enough to duplicate your i386-pc.mk changes for the other .mk files. Index: conf/common.rmk === RCS file: /sources/grub/grub2/conf/common.rmk,v retrieving revision 1.7 diff -u -r1.7 common.rmk --- conf/common.rmk 27 May 2006 21:09:25 - 1.7 +++ conf/common.rmk 30 May 2006 21:00:02 - @@ -27,61 +27,73 @@ # For fshelp.mod. fshelp_mod_SOURCES = fs/fshelp.c fshelp_mod_CFLAGS = $(COMMON_CFLAGS) +fshelp_mod_TARGET_CFLAGS = $(COMMON_TARGET_CFLAGS) fshelp_mod_LDFLAGS = $(COMMON_LDFLAGS) ... --- conf/i386-pc.rmk 28 May 2006 23:01:43 - 1.65 +++ conf/i386-pc.rmk 30 May 2006 21:00:02 - @@ -2,6 +2,7 @@ COMMON_ASFLAGS = -nostdinc -fno-builtin COMMON_CFLAGS = -fno-builtin -mrtd -mregparm=3 -m32 +COMMON_TARGET_CFLAGS = -fno-builtin -mrtd -mregparm=3 -m32 COMMON_LDFLAGS = -melf_i386 -nostdlib ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Debugging GRUB2 with GDB and QEMU
On Thu, 2006-05-18 at 14:27 +0200, Lubomir Kundrak wrote: On Sat, May 13, 2006 at 06:38:26AM +0200, Yoshinori K. Okuji wrote: On i386 GCC generates full stack frames even with -O optizations. It only omits frame pointer on architectures on which it doesn't interfere with debugging. I started a small HOWTO recently, so here is it: [1]. Enjoy :o) [1] http://NetBSD.sk/~lkundrak/misc/grub2-gdb/howto.html This looks like very interesting stuff, but wouldn't it be better to put this in the wiki? Please see http://grub.enbug.org. -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: counting partitions in gpt partition map
On Tue, 2006-04-25 at 21:44 +0200, Yoshinori K. Okuji wrote: Why does the gpt partition map count partitions from one instead of zero, unlike other partition maps in GRUB? I don't object to changing the base number to one in GRUB 2, but they should be at least consistent. I would *love* to have the numbering start at one. This would be consistent with Open Firmware, Linux, and probably every other OSs' numbering, which will reduce user confusion. -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub_machine_set_prefix, --enable-mm-debug
On Apr 25, 2006, at 3:08 PM, Yoshinori K. Okuji wrote: A new machine-specific function grub_machine_set_prefix is defined. This is called after loading modules, so that a prefix initialization can use modules. I think you broke grub-emu with this change, because grub-emu uses kern/main.c, but nothing provides grub_machine_set_prefix() there. Also, this change adds an intensive debugging feature for the memory manager via the configure option --enable-mm-debug. Is there a reason not to use the runtime debugging infrastructure we have? Most of that is intensive as well... -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [patch] rename grubof to grub
On Apr 21, 2006, at 4:15 AM, Marco Gerards wrote: Hollis Blanchard [EMAIL PROTECTED] writes: This patch renames grubof, the executable name for PPC and Sparc, to grub. I'm still not sure what the naming convention should be for the executable output by grub-mkimage; I'm thinking maybe grub.ppc. It isn't an image (grub.img); it's still an ELF file... Personally I would prefer something like `_grub' so people see there is something special about it and just don't use it like that. After that the output file can just be called grub if people want that. 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. I was just bit by this issue myself, when I tried to run grubof without any modules. :) Unfortunately, because the module memory wasn't even mapped, when I tried to check the magic number I just ended up crashing my crappy Open Firmware. :( Need to come up with a better solution for that... -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: --enable-mm-debug breakage
On Apr 25, 2006, at 3:08 PM, Yoshinori K. Okuji wrote: Also, this change adds an intensive debugging feature for the memory manager via the configure option --enable-mm-debug. ... and finally, the debug functions seem to introduce runtime breakage (out of memory errors). I have no idea how, and I've wasted too much time trying to figure that out. It's as easy as trying to load a vmlinux: out of memory. When I hack out the EXPORT stuff so I can build without --enable-mm-debug, everything runs fine. -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [patch] set-colors
On Apr 20, 2006, at 8:18 PM, Hollis Blanchard wrote: 2nd: after the tests were successful, I changed my OpenFirmware configuration and switched to grubof.modules. After reboot, I got a black screen. What happens is that grub does boot, but it shows black on black text, so you can't see anything. Pressing enter to boot your default entry works as expected, and Linux boots. Hmmm. It looks like we're using call-method color! to set colors. BootX is using call-method set-colors instead, and ybin does the same (but from Forth). I'm guessing the color! method doesn't exist in your card's firmware, and we should move to set-colors instead. Vincent, do you know how/if this will affect Sparc? If OpenBoot doesn't have set-colors, we can abstract it into an arch-specific function, but it would be nice if it does. Jordi and Vincent, could you both please try this patch? It's working for me (but of course so was color!). -Hollis Index: kern/ieee1275/ieee1275.c === RCS file: /sources/grub/grub2/kern/ieee1275/ieee1275.c,v retrieving revision 1.2 diff -u -p -r1.2 ieee1275.c --- kern/ieee1275/ieee1275.c21 Aug 2005 18:42:55 - 1.2 +++ kern/ieee1275/ieee1275.c21 Apr 2006 01:46:54 - @@ -536,6 +536,7 @@ grub_ieee1275_set_color (grub_ieee1275_i struct grub_ieee1275_common_hdr common; char *method; grub_ieee1275_ihandle_t ihandle; +grub_ieee1275_cell_t numcolors; grub_ieee1275_cell_t index; grub_ieee1275_cell_t b; grub_ieee1275_cell_t g; @@ -545,8 +546,9 @@ grub_ieee1275_set_color (grub_ieee1275_i args; INIT_IEEE1275_COMMON (args.common, call-method, 6, 1); - args.method = color!; + args.method = set-colors; args.ihandle = ihandle; + args.numcolors = 1; args.index = index; args.r = r; args.g = g; ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub cvs ... configfile
On Apr 19, 2006, at 9:36 PM, Yoshinori K. Okuji wrote: On Wednesday 19 April 2006 18:35, Marco Gerards wrote: Hollis Blanchard [EMAIL PROTECTED] writes: I think the menuentry were much better and more descriptive. I don't think there is a need to have both and it only confuses people. So I would propose to remove @-version. I agree. The @ is a very odd syntax. Since menuentry works as well, I think @ should be removed. It was added because Okuji wanted something short for this. I do not care as long as there is a long command. Marco is right. This was my request. @ is just a command aliased for menuentry, and I like it. Since you are not obligated to use @, please do not remove it. Offering multiple commands that do the same thing is not a good design philosphy, and from the other comments on this subject I know I'm not alone in that belief. No offense, but I don't think one developer liking it is a good enough reason. I still would like to see it removed. -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
[ppc patch] fix biarch linking
2006-04-18 Hollis Blanchard [EMAIL PROTECTED]
* Makefile.in (LDFLAGS): Add variable.
(LD): Remove variable.
* configure.ac: Add -m32 to LDFLAGS.
* genmk.rb (PModule#rule): Use $(CC) instead of $(LD).
* conf/powerpc-ieee1275.rmk (COMMON_LDFLAGS): Add variable.
(grubof_LDFLAGS): Use $(COMMON_LDFLAGS).
(_linux_mod_LDFLAGS, linux_mod_LDFLAGS, normal_mod_LDFLAGS,
suspend_mod_LDFLAGS, reboot_mod_LDFLAGS, halt_mod_LDFLAGS): New
variables.
Could somebody please confirm that x86 still builds and works with this
patch? Thanks.
-Hollis
Index: Makefile.in
===
RCS file: /sources/grub/grub2/Makefile.in,v
retrieving revision 1.18
diff -u -p -r1.18 Makefile.in
--- Makefile.in 18 Apr 2006 06:18:15 - 1.18
+++ Makefile.in 19 Apr 2006 02:40:08 -
@@ -56,6 +56,7 @@ mkinstalldirs = $(srcdir)/mkinstalldirs
CC = @CC@
CFLAGS = @CFLAGS@
+LDFLAGS = @LDFLAGS@
CPPFLAGS = -I. -Iinclude -I$(srcdir)/include -Wall -W
BUILD_CC = @BUILD_CC@
BUILD_CFLAGS = -g -O2
@@ -64,7 +65,6 @@ BUILD_CPPFLAGS = -I. -Iinclude -I$(srcdi
OBJCOPY = @OBJCOPY@
STRIP = @STRIP@
NM = @NM@
-LD = @LD@
RUBY = @RUBY@
LIBCURSES = @LIBCURSES@
LIBLZO = @LIBLZO@
Index: configure.ac
===
RCS file: /sources/grub/grub2/configure.ac,v
retrieving revision 1.22
diff -u -p -r1.22 configure.ac
--- configure.ac2 Apr 2006 08:53:31 - 1.22
+++ configure.ac19 Apr 2006 02:40:09 -
@@ -89,6 +89,8 @@ if test x$default_CFLAGS = xyes; then
if test x$biarch32 = x1; then
tmp_CFLAGS=$tmp_CFLAGS -m32
+LDFLAGS=$LDFLAGS -m32
+AC_SUBST(LDFLAGS)
fi
CFLAGS=$tmp_CFLAGS
Index: genmk.rb
===
RCS file: /sources/grub/grub2/genmk.rb,v
retrieving revision 1.19
diff -u -p -r1.19 genmk.rb
--- genmk.rb18 Apr 2006 06:18:15 - 1.19
+++ genmk.rb19 Apr 2006 02:40:09 -
@@ -121,12 +121,12 @@ UNDSYMFILES += #{undsym}
[EMAIL PROTECTED]: #{pre_obj} #{mod_obj}
-rm -f $@
- $(LD) $(#{prefix}_LDFLAGS) $(LDFLAGS) -r -d -o $@ $^
+ $(CC) $(#{prefix}_LDFLAGS) $(LDFLAGS) -Wl,-r,-d -o $@ $^
$(STRIP) --strip-unneeded -K grub_mod_init -K grub_mod_fini -R .note -R
.comment $@
#{pre_obj}: #{objs_str}
-rm -f $@
- $(LD) $(#{prefix}_LDFLAGS) -r -d -o $@ $^
+ $(CC) $(#{prefix}_LDFLAGS) $(LDFLAGS) -Wl,-r,-d -o $@ $^
#{mod_obj}: #{mod_src}
$(CC) $(CPPFLAGS) $(CFLAGS) $(#{prefix}_CFLAGS) -c -o $@ $
Index: conf/powerpc-ieee1275.rmk
===
RCS file: /sources/grub/grub2/conf/powerpc-ieee1275.rmk,v
retrieving revision 1.52
diff -u -p -r1.52 powerpc-ieee1275.rmk
--- conf/powerpc-ieee1275.rmk 25 Dec 2005 15:59:50 - 1.52
+++ conf/powerpc-ieee1275.rmk 19 Apr 2006 02:40:09 -
@@ -3,6 +3,7 @@
COMMON_ASFLAGS = -nostdinc -D__ASSEMBLY__
COMMON_CFLAGS = -ffreestanding -msoft-float
+COMMON_LDFLAGS += -nostdlib
# Images.
@@ -69,7 +70,8 @@ grubof_SOURCES = kern/powerpc/ieee1275/c
grubof_HEADERS = grub/powerpc/ieee1275/ieee1275.h
grubof_CFLAGS = $(COMMON_CFLAGS)
grubof_ASFLAGS = $(COMMON_ASFLAGS)
-grubof_LDFLAGS = -nostdlib -static-libgcc -lgcc
-Wl,-N,-S,-Ttext,0x20,-Bstatic
+grubof_LDFLAGS = $(COMMON_LDFLAGS) -static-libgcc -lgcc \
+ -Wl,-N,-S,-Ttext,0x20,-Bstatic
# For genmoddep.
genmoddep_SOURCES = util/genmoddep.c
@@ -91,10 +93,12 @@ pkgdata_MODULES = halt.mod \
# For _linux.mod.
_linux_mod_SOURCES = loader/powerpc/ieee1275/linux.c
_linux_mod_CFLAGS = $(COMMON_CFLAGS)
+_linux_mod_LDFLAGS = $(COMMON_LDFLAGS)
# For linux.mod.
linux_mod_SOURCES = loader/powerpc/ieee1275/linux_normal.c
linux_mod_CFLAGS = $(COMMON_CFLAGS)
+linux_mod_LDFLAGS = $(COMMON_LDFLAGS)
# For normal.mod.
normal_mod_SOURCES = normal/arg.c normal/cmdline.c normal/command.c\
@@ -103,18 +107,22 @@ normal_mod_SOURCES = normal/arg.c normal
normal/menu_entry.c normal/misc.c grub_script.tab.c \
normal/script.c normal/powerpc/setjmp.S
normal_mod_CFLAGS = $(COMMON_CFLAGS)
+normal_mod_LDFLAGS = $(COMMON_LDFLAGS)
normal_mod_ASFLAGS = $(COMMON_ASFLAGS)
# For suspend.mod
suspend_mod_SOURCES = commands/ieee1275/suspend.c
suspend_mod_CFLAGS = $(COMMON_CFLAGS)
+suspend_mod_LDFLAGS = $(COMMON_LDFLAGS)
# For reboot.mod
reboot_mod_SOURCES = commands/ieee1275/reboot.c
reboot_mod_CFLAGS = $(COMMON_CFLAGS)
+reboot_mod_LDFLAGS = $(COMMON_LDFLAGS)
# For halt.mod
halt_mod_SOURCES = commands/ieee1275/halt.c
halt_mod_CFLAGS = $(COMMON_CFLAGS)
+halt_mod_LDFLAGS = $(COMMON_LDFLAGS)
include $(srcdir)/conf/common.mk
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: TCP timers and telnet
On Apr 1, 2006, at 10:30 AM, Marco Gerards wrote: Yoshinori K. Okuji [EMAIL PROTECTED] writes: On Saturday 01 April 2006 18:15, Marco Gerards wrote: So I was thinking, why not add such functionality to GRUB 2? It's easy to implement with the networking code I currently have. The only thing about it that sucks is that we have to implement multitheading, kinda... I object to multithreading. It makes our life just harder. I prefer an event-driven approach as you suggested before. My previous suggestion would have worked, if you didn't telnet into GRUB. The current discussion is about having multiple different GRUB sessions simultaniously. So in that case you will need locking, etc. What about allowing only a single telnet connection? Or multiple connections, but they all show the same session? -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [patch] Moved font fixup from manager to font converter
On Apr 1, 2006, at 1:39 PM, Vesa Jääskeläinen wrote: http://jumi.lut.fi/~vjaaskel/grub2/grub-glyphs.png Looks great! Nice work. :) -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [patch] Distribute grub-install.in for powerpc
On Mar 28, 2006, at 9:51 AM, Marco Gerards wrote: Hollis Blanchard [EMAIL PROTECTED] writes: On Mar 28, 2006, at 3:39 AM, Roger Leigh wrote: The attached patch distributes grub-install.in for powerpc. Thanks for the patch! However, don't we want to distribute grub-install, not grub-install.in? We distribute it for the PC already, so I think we can better do the same for the PPC. So for consistency reasons we either have to include it, or remove the other. I think we should distribute all sourcefiles so people can reproduce everything. Besides that, grub-install depends on how you configure GRUB. Because of that reason we should not distribute it. Oh, I thought we were talking about make install. I guess we're talking about make dist. Carry on... -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: NewWorld CD Booting?
On Mar 14, 2006, at 10:43 PM, Andrei Warkentin wrote: I really don't know who else to approach with this, and this is (potentially) GRUB 2 related (if/when GRUB2 boots from CD). GRUB2 should boot just fine from a CD. Basically I hack away at my kernel attempt on a an '05 iBook (dev system is 10.4), and decided to look into making a bootable CD so I could use QEMU PPC emulator instead of rebooting to test after every compile. I created the bootinfo file (like this): snip If I boot up while holding C, I get the gray screen, I can hear the CDROM spin up, then I get kicked back to the white and black OF screen and there is an error about memory access violation. You didn't mention where you placed the bootinfo.txt. It should be /ppc/chrp/bootinfo.txt on the CD. http://penguinppc.org/ppc64/power-bootable-iso/ may have some information that helps you (though some of it isn't directly applicable). -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: OF default catch on grub2 on 43p-260
On Tuesday 07 March 2006 14:29, Chris Abbey wrote: I just tried out grub2 on my ppc64 box, a 43p-260 using cvs as of 6 March. It 0 setenv debug all ok 0 0 0 printenv debug debugall ok This part here won't work. GRUB doesn't look for an OF variable named debug (technically such a thing does not exist, according to IEEE1275), but rather a commandline argument. So you would do this: 0 boot debug=all or even 0 boot floppy debug=all ... but in this particular case, the crash is very very early, and also we already got our helpful debugging message. 0 boot Failed to claim heap at 0x4000, len 0x1fb000 This is telling us that GRUB attempted to claim some memory for its heap (at that address and that length), but some of it was already in use, so the request failed. From the OF prompt, before you boot GRUB, could you do the following and send the output: 0 dev /[EMAIL PROTECTED] 0 .properties In particular, the available property is the one I'm interested in. That will tell us what areas of memory are considered free... -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: OF default catch on grub2 on 43p-260
On Mar 8, 2006, at 3:28 PM, Chris Abbey wrote: On Wednesday 08 March 2006 11:35 am, Hollis Blanchard wrote: From the OF prompt, before you boot GRUB, could you do the following and send the output: 0 dev /[EMAIL PROTECTED] 0 .properties In particular, the available property is the one I'm interested in. That will tell us what areas of memory are considered free... 0 dev /[EMAIL PROTECTED] ok 0 .properties namememory device_type memory reg 4000 available 4000 00bfc000 0140 3ec0 #address-cells 0001 #size-cells 0 boot floppy:,grubof.mod debug=all Failed to claim heap at 0x4000, len 0x1fb000 DEFAULT CATCH!, code=fff00700 at %SRR0: 00206090 %SRR1: 00023000 ok 0 So If I'm reading that correctly, there is 0x00bfc000 bytes availabel at an offest of 0x4000, since grub is asking for 0x001fb000, and that is less than 0x00bfc000... I don't get why it's failing. Me neither. In the source, could you try adjusting the 0x4000 (it's hardcoded in kern/powerpc/ieee1275/init.c) to 0x5000 or 0x8000 or something? -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: oldworld powermac boot loader?
On Fri, 10 Feb 2006 17:18:56 +1100 (EST), Finn Thain [EMAIL PROTECTED] said: I just Googled up some of your work on grub 2, and wanted to ask a couple of questions. You see, I ran into that bug in the biege g3 firmware that prevents booting an OS not installed in the first 8 GB. So my question is, does grub 2 work on oldworld machines? If so, can it boot OS 9, OS X and Linux? Should I create a partition for a future grub 2 stage? Hi Finn, I hope you don't mind if I CC the grub-devel mailing list (and sorry for the mail resend issues). GRUB2 does not currently work on Old World PowerMacs. It will require some effort to change that; in particular we will need to write a stage1 loader of our own, similar to quik's stage1. That code needs to fit in 512 bytes, so will have to be done in assembly. Actually, I started Old World support by just using quik's stage1. Unfortunately that is limited to loading only 64KB of stage2, and grub2 is over 200KB the last time I looked. This on my TODO list, but pretty low on my list. I would be more than happy to help anybody interested in the problem. -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
