Re: How to prepare an ISO 9660 CD for booting via GRUB ?
Hi, The urge to upgrade might earn you a whining user. Well, if you develop you have to use current version (IMO). Sure. As long as i occupy your time i will follow your proposals. Nevertheless, at some point i will have to look at older versions. After all, 1.96 is distributed with the current Debian release. Hopefully i will know enough then to help myself on the first hand. Have a nice day :) Thomas ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Multiboot2 Suggestions
Brendan Trotter wrote: Hi, 2010/3/28 Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com: Also I'm aware that at least some people want more tags. Feel free to propose new ones. In short all ammendment ideas are welcome. Here's my list.. :-) 1) If GRUB was using a serial port as a console device (e.g. on a headless system) it'd be nice if the OS could continue using the same serial port with the same configuration instead of resetting the serial port, etc. A new tag (for 80x86, 8250/6550 compatible serial ports) would include base I/O port, the serial line configuration (e.g. 8 data bits, no stop bit, no parity), the baud rate (e.g. 9600), The kernel can read data bits, stop bits, parity and divisor from registers itself. I think it's more useful to supply a base frequency since there are a lot of almost compatible cards which differ only in base frequency. the IRQ number (if known/used by the boot loader) and the protocol being used (ASCII, VT100, etc). I think it's more useful to supply directly usable strings termcap strings rather than an abstract ID If the boot loader doesn't know which IRQ the serial port uses (e.g. it uses polling) then it sets the IRQ number to 0x. Where the serial port has a different interface (e.g. if the serial port uses MMIO or if it's not 8250/6550 compatible) a different tag with different fields are used to describe it. I think it's more useful to have an I/O selector since yeeloong serial interface is basically the same, just attached differently I think we need following fields: 1) I/O space selector (e.g. 0 = 32-bit MMIO, 1 = 64-bit MMIO, 2 = i386 I/O) 2) IRQ type selector (0 = None, 1 = standard platform interrupt) 3) 16-bit padding 4) address in I/O space (up to 64-bits) 5) Base frequency in Hz (32-bit) 6) IRQ (32-bit or even 64-bit since it's not excluded some platforms would use 64-bit IRQ ids, though I'm not aware of such). telnet+ethernet It would need network tag first 2) The OS image format information should be expanded, so that the OS can tell the boot loader if it supports 8250/6550 compatible serial ports (and which protocols), and any other console devices (for the same reason the OS image format already has flags, etc for video). Console flags tag is for this 3) There should be an (optional?) critical error notification method tag that tells the OS which method/s it can/should use to tell the user it encountered a problem before it was able to setup it's console output. For example, can/should the OS return to the boot loader, or use the PC speaker to beep, or make a PS/2 keyboard's LEDs flash, or something else. Processing such a selector may prove as difficult as setting up a console based on console tags. So I doubt its usefullness 4) The section on Machine State is missing lots of information, and needs to indicate the state of *all* hardware on all architectures (regardles of firmware type). For example; for 80x86/PC it should say that PCI devices are left in an undefined state (so that the boot loader is not responsible for configuring PCI devices if the firmware didn't for any reason), except for any PCI device that is indirectly mentioned in the multi-boot information (e.g. if there's a serial port tag then the OS can assume that serial port is configured, if there's a video information tag then the OS can assume the video cards is configured, etc). Everything not said explicitly is undefined. However I would like to add a sentence that some basic PCI initialisation OS usually expects and which is done by firmware to be present. 5) The boot loader should always provide a memory map. If the boot loader is unable to get a memory map from the firmware then the boot loader constructs a fake memory map from any/all information it can find, including known areas that aren't RAM. For e.g. on 80x86 BIOS if int 0x15, eax=0xE820 isn't supported, then other BIOS functions are used to find usable RAM and the boot loader creates an entry that marks the area from 0x000A to 0x000F as system or unknown. Where bootloader gets memory map from isn't part of specification and I see no reason to change that The mem_upper/mem_lower tag should removed from the specification. If more people speak against this tag then yes. 7) The memory map needs more area types. Any RAM that is reported by firmware as faulty should use area type 5 so that the OS can know that some RAM is faulty, and (for e.g.) could tell a system administrator about it. Also, area type 0x should be used for unknown, as this allows the OS to determine the difference between boot loader doesn't know what the area is and boot loader does know what the area is but the area type is defined in a newer version of the multi-boot specification. What's the difference between type 2 and type 5 8) Any RAM that is not immediately usable by the OS should not be reported as
MIPS multiboot2 available
Hello, MIPS multiboot2 specification is available in branches/multiboot2 and is implemented in bazaar trunk grub. Example kernel will be available when I'll clean it up -- Regards Vladimir 'φ-coder/phcoder' Serbinenko signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to prepare an ISO 9660 CD for booting via GRUB ?
Thomas Schmitt wrote: Hi, The urge to upgrade might earn you a whining user. Well, if you develop you have to use current version (IMO). Sure. As long as i occupy your time i will follow your proposals. Nevertheless, at some point i will have to look at older versions. After all, 1.96 is distributed with the current Debian release. Hopefully i will know enough then to help myself on the first hand. The point is basically that even if you release 1.96 support right now it won't make it into distributions before GRUB 1.98 does. Additionally you must be aware that we don't accept bug reports for 1.96 anymore (and it had enough of bugs). So I would like to ask not to make this support. At very least it will save you and me few bug reports for version we don't support. Have a nice day :) Thomas ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Regards Vladimir 'φ-coder/phcoder' Serbinenko signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
[RFC] Multiboot2 drafting
Hello, all. In GRUB2 community we're currently working on a next-generation multiboot specification. It has goals similar to the original multiboot specification but with important flaws fixed: 1) Instead of having bunch of pointers to subtables it uses a tagged structure now. It allows it to be easier expandable, consume less space if some fields aren't used and is easier to relocate. 2) Now it's portable. It has fields for specification of architecture and proper field alignment. So now adding a new arcitecture is as easy as adding a new arcitecture id and a section dealing with architecture-specific problems like register usage to pass information. Currently it has only i386 and mips though. Both are implemented in bzr trunk grub[1] Short summary: Multiboot specification is done as an unified protocol between bootloader and kernel to allow supporting more kernels and bootloaders with less effort. The easiest way to use it is to create an ELF image with an additional header which announces multiboot support and specific kernel requirements. But it's also possible to put loading address in multiboot header and use a non-ELF format. When image is loaded one of GPRs contaians a magic number to identify that kernel was loaded as multiboot and another GPR contains a pointer to information table. The most needed information is already there, more is in review progress, and if you feel like we're missing somethin feel free to contact. Complete specification is available at http://bzr.savannah.gnu.org/r/grub/branches/multiboot2/ or at http://download.savannah.gnu.org/releases-noredirect/grub/phcoder/multiboot.pdf Some advantages: 1) Removes the need to support a fundamentaly different boot protocol for every architecture. In future it may even be possible to have just one image per ISA and rely on information supplied by bootloader to differentiate between platforms (it doesn't prevent creation of an image optimised for one platform) 2) Better collaboration between bootloaders and kernels by avoiding to implement one protocol per kernel. 3) Possibility to inform bootloader of exact kernel requirements and supported features. 4) Uniform interface for retrieving e.g. memory map and initial console info across platforms. Anything else you request ;) Any comment about multiboot2 spec is welcome. Would it be possible for Linux in perspective to use multiboot2 instead or in addition to current protocols? Thanks for your time. [1] Available with bzr co --lightweight http://bzr.savannah.gnu.org/r/grub/trunk/grub/ or as a tarball at http://download.savannah.gnu.org/releases-noredirect/grub/phcoder/grub-r2283.tgz -- Regards Vladimir 'φ-coder/phcoder' Serbinenko signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Grub UEFI memory allocation patch
Hi,
I was trying for a few days to enable EFI boot on my laptop, and i've
encountered some issues with Grub2.
My motherboard is one of the modern Intel chipset motherboard, that
come with UEFI v2, and when i tried to boot using grub 1.98, compiled
with efi support, there was some memory allocation error message at
the kernel loading time, saying cannot allocate protected mode page
or something like that.
So, i looked into the grub source code, and found that it tries to
allocate memory at a hard coded memory address (0X1), that was
already in use, for my computer.
I've also found parts of the code in loader/i386/linux.c that were
looking for free pages in the memory map, which is already done by the
EFI memory allocation function.
Actually, i've managed to make it working, by letting EFI find free
memory pages and allocate them, but i dont really know how important
this 0x1 address is.
My fix works for me, but I think it may be connected to the fact I've
also build a relocatable kernel. I don't know enough about kernel
loading and bootloaders to determine if my fix will work well in all
situations or not, so maybe someone can tell me that.
Actually, i've still have an issue at shutdown time : the kernel (or
grub ?) crashes with an error message Bad RIP value and a full stack
trace with an EFI call, just when it is expected to power down. So, i
need to poweroff or reboot it manually, using the power switch. I
anyone have an idea from where the error comes, i'm interested.
Rémi
diff --git a/include/grub/efi/efi.h b/include/grub/efi/efi.h
index 5852a47..996b545 100644
--- a/include/grub/efi/efi.h
+++ b/include/grub/efi/efi.h
@@ -37,9 +37,22 @@ void *EXPORT_FUNC(grub_efi_open_protocol) (grub_efi_handle_t handle,
grub_efi_uint32_t attributes);
int EXPORT_FUNC(grub_efi_set_text_mode) (int on);
void EXPORT_FUNC(grub_efi_stall) (grub_efi_uintn_t microseconds);
+
+void *
+EXPORT_FUNC(grub_efi_allocate_any_pages) (grub_efi_uintn_t pages,
+ grub_efi_memory_type_t memtype);
+void *
+EXPORT_FUNC(grub_efi_allocate_pages_before) (grub_efi_physical_address_t address,
+ grub_efi_uintn_t pages,
+ grub_efi_memory_type_t memtype);
void *
EXPORT_FUNC(grub_efi_allocate_pages) (grub_efi_physical_address_t address,
grub_efi_uintn_t pages);
+void *
+EXPORT_FUNC(grub_efi_typed_allocate_pages) (grub_efi_physical_address_t address,
+ grub_efi_uintn_t pages,
+ grub_efi_allocate_type_t type,
+ grub_efi_memory_type_t memtype);
void EXPORT_FUNC(grub_efi_free_pages) (grub_efi_physical_address_t address,
grub_efi_uintn_t pages);
int
diff --git a/kern/efi/mm.c b/kern/efi/mm.c
index ceb8fc9..0138ed3 100644
--- a/kern/efi/mm.c
+++ b/kern/efi/mm.c
@@ -49,6 +49,20 @@ static struct allocated_page *allocated_pages = 0;
#define MIN_HEAP_SIZE 0x10
#define MAX_HEAP_SIZE (1600 * 0x10)
+void *
+grub_efi_allocate_any_pages (grub_efi_uintn_t pages,
+ grub_efi_memory_type_t memtype)
+{
+ return grub_efi_typed_allocate_pages (0, pages, GRUB_EFI_ALLOCATE_ANY_PAGES, memtype);
+}
+
+void *
+grub_efi_allocate_pages_before (grub_efi_physical_address_t address,
+ grub_efi_uintn_t pages,
+grub_efi_memory_type_t memtype)
+{
+ return grub_efi_typed_allocate_pages (address, pages, GRUB_EFI_ALLOCATE_MAX_ADDRESS, memtype);
+}
/* Allocate pages. Return the pointer to the first of allocated pages. */
void *
@@ -56,14 +70,6 @@ grub_efi_allocate_pages (grub_efi_physical_address_t address,
grub_efi_uintn_t pages)
{
grub_efi_allocate_type_t type;
- grub_efi_status_t status;
- grub_efi_boot_services_t *b;
-
-#if GRUB_TARGET_SIZEOF_VOID_P 8
- /* Limit the memory access to less than 4GB for 32-bit platforms. */
- if (address 0x)
-return 0;
-#endif
#if GRUB_TARGET_SIZEOF_VOID_P 8 || defined (MCMODEL_SMALL)
if (address == 0)
@@ -80,20 +86,40 @@ grub_efi_allocate_pages (grub_efi_physical_address_t address,
type = GRUB_EFI_ALLOCATE_ADDRESS;
#endif
+ return grub_efi_typed_allocate_pages (address, pages, type, GRUB_EFI_LOADER_DATA);
+}
+
+void *
+grub_efi_typed_allocate_pages (grub_efi_physical_address_t address,
+ grub_efi_uintn_t pages,
+ grub_efi_allocate_type_t type,
+ grub_efi_memory_type_t memtype)
+{
+ grub_efi_status_t status;
+ grub_efi_boot_services_t *b;
+
+#if GRUB_TARGET_SIZEOF_VOID_P 8
+ /* Limit the memory access to less than 4GB for 32-bit platforms. */
+ if (address 0x)
+return 0;
+#endif
+
b = grub_efi_system_table-boot_services;
- status = efi_call_4 (b-allocate_pages, type, GRUB_EFI_LOADER_DATA, pages, address);
- if (status != GRUB_EFI_SUCCESS)
+ status = efi_call_4 (b-allocate_pages, type, memtype, pages, address);
+ if (status != GRUB_EFI_SUCCESS) {
return 0;
Re: Grub UEFI memory allocation patch
Bernon wrote: I've also found parts of the code in loader/i386/linux.c that were looking for free pages in the memory map, which is already done by the EFI memory allocation function. Actually, i've managed to make it working, by letting EFI find free memory pages and allocate them, but i dont really know how important this 0x1 address is. It is important and we have an experimental stuff in my newreloc branch to workaround the problem. It was already explained on the list -- Regards Vladimir 'φ-coder/phcoder' Serbinenko signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Grub UEFI memory allocation patch
Actually, I've read the answer you made to someone who had the same memory issue as I had, and I tried the newreloc branch, but it doesn't even build when targeting efi platform. The loader/i386/efi/linux.c file is missing in this branch. I will look for explanation about this part of code, in the mailing list archives, however, as i said, the fix works fine for me. The only error i have noticed, occurs on shutdown, and also occurs when i boot using elilo. Regards, Rémi Bernon ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Grub UEFI memory allocation patch
Bernon wrote: Actually, I've read the answer you made to someone who had the same memory issue as I had, and I tried the newreloc branch, but it doesn't even build when targeting efi platform. The loader/i386/efi/linux.c file is missing in this branch. It was a mismerge. I've fixed it. Recently I was working on making this branch mergeable into experimental and for this it needed some restructure. I recommend trying r2130 of newreloc I will look for explanation about this part of code, in the mailing list archives, however, as i said, the fix works fine for me. Even if it does it needs a special support from kernel and doesn't allow to handle e.g. FreeBSD so when it will be mergeable (probably next week) your fix will be obsolete The only error i have noticed, occurs on shutdown, and also occurs when i boot using elilo. Regards, Rémi Bernon ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Regards Vladimir 'φ-coder/phcoder' Serbinenko signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Grub UEFI memory allocation patch
That's fine. I suspected that this required a specific kernel configuration, as you have confirmed. I will try again the newreloc branch. Thanks. Regards, Rémi Bernon 2010/4/3 Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com: Bernon wrote: Actually, I've read the answer you made to someone who had the same memory issue as I had, and I tried the newreloc branch, but it doesn't even build when targeting efi platform. The loader/i386/efi/linux.c file is missing in this branch. It was a mismerge. I've fixed it. Recently I was working on making this branch mergeable into experimental and for this it needed some restructure. I recommend trying r2130 of newreloc I will look for explanation about this part of code, in the mailing list archives, however, as i said, the fix works fine for me. Even if it does it needs a special support from kernel and doesn't allow to handle e.g. FreeBSD so when it will be mergeable (probably next week) your fix will be obsolete The only error i have noticed, occurs on shutdown, and also occurs when i boot using elilo. Regards, Rémi Bernon ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ 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
Supporting for MINIX v3 filesystem
Hi! I assume by now only MINIX v1 and v2 filesystems are supported by GRUB2, is it possible for MFS v3 to be accessed, which is the only used filesystem for the latest MINIX releases. We have a project to make MINIX Multiboot compliant, so if it is the case, I'd like to try to add that support to GRUB. Please share your suggestions. -- Best Regards! Fam ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
