[patch 1/3] PCI support (abstract interface)
Hello,
Here is a patch to add pci support to grub2.
2006-05-16 Vincent Guffens [EMAIL PROTECTED]
* drivers/: New directory
* conf/i386-pc.rmk (pkgdata_MODULES): Added pci.mod
to the list of modules.
(DRIVERS_CFLAGS): Added.
(pci_mod_SOURCES): Likewise.
(pci_mod_CFLAGS): Likewise.
(pci_mod_LDFLAGS): Likewise.
* drivers/include/grub/pci.h: New file.
* drivers/include/grub/list.h: Likewise.
* drivers/pci/pci.c: Likewise.
diff -rNu grub2/ChangeLog grub2-pci/ChangeLog
--- grub2/ChangeLog 2006-05-14 22:16:16.0 +0100
+++ grub2-pci/ChangeLog 2006-05-16 21:51:22.0 +0100
@@ -1,3 +1,18 @@
+2006-05-16 Vincent Guffens [EMAIL PROTECTED]
+
+ * drivers/: New directory.
+
+ * conf/i386-pc.rmk (pkgdata_MODULES): Added pci.mod
+ to the list of modules.
+ (DRIVERS_CFLAGS): Added.
+ (pci_mod_SOURCES): Likewise.
+ (pci_mod_CFLAGS): Likewise.
+ (pci_mod_LDFLAGS): Likewise.
+
+ * drivers/include/grub/pci.h: New file.
+ * drivers/include/grub/list.h: Likewise.
+ * drivers/pci/pci.c: Likewise.
+
2006-05-14 Yoshinori K. Okuji [EMAIL PROTECTED]
* kern/i386/pc/startup.S: Include grub/cpu/linux.h instead of
diff -rNu grub2/conf/i386-pc.rmk grub2-pci/conf/i386-pc.rmk
--- grub2/conf/i386-pc.rmk 2006-05-07 19:28:23.0 +0100
+++ grub2-pci/conf/i386-pc.rmk 2006-05-16 21:07:30.0 +0100
@@ -3,6 +3,7 @@
COMMON_ASFLAGS = -nostdinc -fno-builtin
COMMON_CFLAGS = -fno-builtin -mrtd -mregparm=3 -m32
COMMON_LDFLAGS = -melf_i386 -nostdlib
+DRIVERS_CFLAGS = -Idrivers/include -fno-strict-aliasing
# Images.
pkgdata_IMAGES = boot.img diskboot.img kernel.img pxeboot.img
@@ -116,7 +117,7 @@
pkgdata_MODULES = _chain.mod _linux.mod linux.mod normal.mod \
_multiboot.mod chain.mod multiboot.mod reboot.mod halt.mod \
vbe.mod vbetest.mod vbeinfo.mod video.mod gfxterm.mod \
- videotest.mod play.mod
+ videotest.mod play.mod pci.mod
# For _chain.mod.
_chain_mod_SOURCES = loader/i386/pc/chainloader.c
@@ -209,4 +210,9 @@
videotest_mod_CFLAGS = $(COMMON_CFLAGS)
videotest_mod_LDFLAGS = $(COMMON_LDFLAGS)
+# For pci.mod
+pci_mod_SOURCES = drivers/pci/pci.c
+pci_mod_CFLAGS = $(COMMON_CFLAGS) $(DRIVERS_CFLAGS)
+pci_mod_LDFLAGS = $(COMMON_LDFLAGS)
+
include $(srcdir)/conf/common.mk
diff -rNu grub2/drivers/include/grub/list.h
grub2-pci/drivers/include/grub/list.h
--- grub2/drivers/include/grub/list.h 1970-01-01 01:00:00.0 +0100
+++ grub2-pci/drivers/include/grub/list.h 2006-05-16 21:10:58.0
+0100
@@ -0,0 +1,86 @@
+/* list.h - A very simple list. */
+/*
+ * GRUB -- GRand Unified Bootloader
+ * Copyright (C) 2006 Free Software Foundation, Inc.
+ *
+ * GRUB is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with GRUB; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+
+/*
+ If you want a list of struct myitem
+ you do
+
+ struct myitem *item_list;
+
+ where myitem MUST have its next pointer as the FIRST field
+
+ and you can then add, delete the EL item,
+ grub_add_list (item_list, el);
+ grub_del_list (item_list, el);
+
+ or call HOOK(item) for each element of the list
+ grub_iterate_list (item_list, hook);
+
+ This brk version will point el to the list item for which
+ HOOK(EL) returns a non-null value
+ grub_iterate_list_brk (item_list, hook, el);
+ */
+
+struct obj {
+ struct obj *next; /* MUST BE FIRST */
+};
+
+#define grub_del_list(list, el) _grub_del_list((struct obj**) list,
(struct obj*) el)
+#define grub_add_list(list, el) _grub_add_list((struct obj**) list,
(struct obj*) el)
+#define grub_find_list(list, el) \
+ (typeof(list)) _grub_find_list((struct obj*) list, (struct obj*) el)
+#define grub_iterate_list(list, func) \
+ {typeof(list) el = list; while (el) {func(el); el=el-next;}}
+#define grub_iterate_list_brk(list, func, it) \
+ {typeof(list) el = list; it = 0; \
+while (el) {if (func(el)) {it = el; break;} el=el-next; }}
+
+static inline struct obj* _grub_find_list (struct obj *list, struct
obj *el)
+{
+ struct obj *it = list;
+ for (it = list; it; it=it-next)
+ {
+if (it == el) return el;
+ }
+ return 0;
+};
+
+static inline void _grub_add_list (struct obj **list, struct obj *el)
+{
+ if ( (!el) || (_grub_find_list (*list, el)) )
+return;
+
+ el-next = *list;
+ *list
[patch 2/3] PCI support (implementation from etherboot)
Some directories, other than drivers/include/etherboot/i386 might have to be created by hand. 2006-05-16 Vincent Guffens [EMAIL PROTECTED] * drivers/include/etherboot/: New directory. * drivers/pci/i386/: Likewise. * configure.ac (AC_CONFIG_LINKS): Added drivers/include/etherboot/cpu links. * conf/i386-pc.rmk (pkgdata_MODULES): Added pci_etherboot.mod to the list of modules. (pci_etherboot_mod_SOURCES): Added. (pci_etherboot_mod_CFLAGS): Likewise. (pci_etherboot_mod_LDFLAGS): Likewise. * drivers/include/etherboot/pci_ids.h: New file. * drivers/include/etherboot/pci_defs.h: Likewise. * drivers/include/etherboot/i386/io.h: Likewise. * drivers/include/etherboot/i386/limits.h: Likewise. * drivers/pci/pci_etherboot.c: Likewise. * drivers/pci/i386/pci_io.c: Likewise. diff -rNu grub2-pci/ChangeLog grub2-pci_etherboot/ChangeLog --- grub2-pci/ChangeLog 2006-05-16 21:51:22.0 +0100 +++ grub2-pci_etherboot/ChangeLog 2006-05-16 21:51:44.0 +0100 @@ -1,5 +1,26 @@ 2006-05-16 Vincent Guffens [EMAIL PROTECTED] + * drivers/include/etherboot/: New directory. + * drivers/pci/i386/: Likewise. + + * configure.ac (AC_CONFIG_LINKS): Added drivers/include/etherboot/cpu + links. + + * conf/i386-pc.rmk (pkgdata_MODULES): Added pci_etherboot.mod + to the list of modules. + (pci_etherboot_mod_SOURCES): Added. + (pci_etherboot_mod_CFLAGS): Likewise. + (pci_etherboot_mod_LDFLAGS): Likewise. + + * drivers/include/etherboot/pci_ids.h: New file. + * drivers/include/etherboot/pci_defs.h: Likewise. + * drivers/include/etherboot/i386/io.h: Likewise. + * drivers/include/etherboot/i386/limits.h: Likewise. + * drivers/pci/pci_etherboot.c: Likewise. + * drivers/pci/i386/pci_io.c: Likewise. + +2006-05-16 Vincent Guffens [EMAIL PROTECTED] + * drivers/: New directory. * conf/i386-pc.rmk (pkgdata_MODULES): Added pci.mod Binary files grub2-pci/.ChangeLog.swp and grub2-pci_etherboot/.ChangeLog.swp differ diff -rNu grub2-pci/conf/i386-pc.rmk grub2-pci_etherboot/conf/i386-pc.rmk --- grub2-pci/conf/i386-pc.rmk 2006-05-16 21:07:30.0 +0100 +++ grub2-pci_etherboot/conf/i386-pc.rmk2006-05-16 21:27:03.0 +0100 @@ -117,7 +117,7 @@ pkgdata_MODULES = _chain.mod _linux.mod linux.mod normal.mod \ _multiboot.mod chain.mod multiboot.mod reboot.mod halt.mod \ vbe.mod vbetest.mod vbeinfo.mod video.mod gfxterm.mod \ - videotest.mod play.mod pci.mod + videotest.mod play.mod pci.mod pci_etherboot.mod # For _chain.mod. _chain_mod_SOURCES = loader/i386/pc/chainloader.c @@ -215,4 +215,9 @@ pci_mod_CFLAGS = $(COMMON_CFLAGS) $(DRIVERS_CFLAGS) pci_mod_LDFLAGS = $(COMMON_LDFLAGS) +# For pci_etherboot.mod +pci_etherboot_mod_SOURCES = drivers/pci/pci_etherboot.c drivers/pci/i386/pci_io.c +pci_etherboot_mod_CFLAGS = $(COMMON_CFLAGS) $(DRIVERS_CFLAGS) +pci_etherboot_mod_LDFLAGS = $(COMMON_LDFLAGS) + include $(srcdir)/conf/common.mk diff -rNu grub2-pci/configure.ac grub2-pci_etherboot/configure.ac --- grub2-pci/configure.ac 2006-05-16 21:53:10.0 +0100 +++ grub2-pci_etherboot/configure.ac2006-05-16 21:53:29.0 +0100 @@ -208,6 +208,7 @@ # Output files. AC_CONFIG_LINKS([include/grub/cpu:include/grub/$host_cpu +drivers/include/etherboot/cpu:drivers/include/etherboot/$host_cpu include/grub/machine:include/grub/$host_cpu/$platform]) AC_CONFIG_FILES([Makefile gensymlist.sh genkernsyms.sh]) AC_CONFIG_FILES([stamp-h], [echo timestamp stamp-h]) diff -rNu grub2-pci/drivers/include/etherboot/i386/io.h grub2-pci_etherboot/drivers/include/etherboot/i386/io.h --- grub2-pci/drivers/include/etherboot/i386/io.h 1970-01-01 01:00:00.0 +0100 +++ grub2-pci_etherboot/drivers/include/etherboot/i386/io.h 2006-05-16 21:31:31.0 +0100 @@ -0,0 +1,206 @@ +/* io.h - Architecture specific input/output functions */ +/* Imported from Etherboot 5.4.1 */ + +#ifndefETHERBOOT_IO_H +#define ETHERBOOT_IO_H + +/* + * This file contains the definitions for the x86 IO instructions + * inb/inw/inl/outb/outw/outl and the string versions of the same + * (insb/insw/insl/outsb/outsw/outsl). You can also use pausing + * versions of the single-IO instructions (inb_p/inw_p/..). + * + * This file is not meant to be obfuscating: it's just complicated + * to (a) handle it all in a way that makes gcc able to optimize it + * as well as possible and (b) trying to avoid writing the same thing + * over and over again with slight variations and possibly making a + * mistake somewhere. + */ + +/* + * Thanks to James van Artsdalen for a better timing-fix than + * the two short jumps: using outb's to a nonexistent port seems + * to guarantee better timings even on fast machines. + * + * On the other hand, I'd like to be sure of a non
[patch 3/3] PCI support (simple test driver)
And here comes the last part, this test driver detects the ne2000 card
in qemu.
2006-05-16 Vincent Guffens [EMAIL PROTECTED]
* drivers/net/: New directory.
* conf/i386-pc.rmk (pkgdata_MODULES): Added test_driver.mod
to the list of modules.
(test_driver_mod_SOURCES): Added.
(test_driver_mod_CFLAGS): Likewise.
(test_driver_mod_LDFLAGS): Likewise.
* driver/net/test_driver.c: New file.
diff -rNu grub2-pci_etherboot/ChangeLog grub2-pci_test_driver/ChangeLog
--- grub2-pci_etherboot/ChangeLog 2006-05-16 21:51:44.0 +0100
+++ grub2-pci_test_driver/ChangeLog 2006-05-16 21:52:08.0 +0100
@@ -1,5 +1,17 @@
2006-05-16 Vincent Guffens [EMAIL PROTECTED]
+ * drivers/net/: New directory.
+
+ * conf/i386-pc.rmk (pkgdata_MODULES): Added test_driver.mod
+ to the list of modules.
+ (test_driver_mod_SOURCES): Added.
+ (test_driver_mod_CFLAGS): Likewise.
+ (test_driver_mod_LDFLAGS): Likewise.
+
+ * driver/net/test_driver.c: New file.
+
+2006-05-16 Vincent Guffens [EMAIL PROTECTED]
+
* drivers/include/etherboot/: New directory.
* drivers/pci/i386/: Likewise.
diff -rNu grub2-pci_etherboot/conf/i386-pc.rmk
grub2-pci_test_driver/conf/i386-pc.rmk
--- grub2-pci_etherboot/conf/i386-pc.rmk2006-05-16 21:27:03.0
+0100
+++ grub2-pci_test_driver/conf/i386-pc.rmk 2006-05-16 21:39:54.0
+0100
@@ -117,7 +117,8 @@
pkgdata_MODULES = _chain.mod _linux.mod linux.mod normal.mod \
_multiboot.mod chain.mod multiboot.mod reboot.mod halt.mod \
vbe.mod vbetest.mod vbeinfo.mod video.mod gfxterm.mod \
- videotest.mod play.mod pci.mod pci_etherboot.mod
+ videotest.mod play.mod pci.mod pci_etherboot.mod \
+test_driver.mod
# For _chain.mod.
_chain_mod_SOURCES = loader/i386/pc/chainloader.c
@@ -220,4 +221,9 @@
pci_etherboot_mod_CFLAGS = $(COMMON_CFLAGS) $(DRIVERS_CFLAGS)
pci_etherboot_mod_LDFLAGS = $(COMMON_LDFLAGS)
+# For test_driver.mod
+test_driver_mod_SOURCES = drivers/net/test_driver.c
+test_driver_mod_CFLAGS = $(COMMON_CFLAGS) $(DRIVERS_CFLAGS)
+test_driver_mod_LDFLAGS = $(COMMON_LDFLAGS)
+
include $(srcdir)/conf/common.mk
diff -rNu grub2-pci_etherboot/drivers/net/test_driver.c
grub2-pci_test_driver/drivers/net/test_driver.c
--- grub2-pci_etherboot/drivers/net/test_driver.c 1970-01-01
01:00:00.0 +0100
+++ grub2-pci_test_driver/drivers/net/test_driver.c 2006-05-16
21:40:07.0 +0100
@@ -0,0 +1,40 @@
+#include grub/pci.h
+#include grub/dl.h
+#include grub/normal.h
+#include grub/err.h
+#include etherboot/pci_ids.h
+
+static grub_err_t
+test_driver_probe (grub_pci_device_t pdev __attribute__((unused)))
+{
+ /* Whah! if it was always so simple. */
+ return GRUB_ERR_NONE;
+}
+
+static struct grub_pci_ids test_driver_ids[] =
+{
+ {0x10ec, 0x8029, realtek 8029 test},
+ {0x1186, 0x0300, dlink-528},
+};
+
+static struct grub_pci_driver test_driver =
+{
+ .next = 0,
+ .type = GRUB_NET_ETHERNET,
+ .name = Test driver,
+ .probe = test_driver_probe,
+ .ids = test_driver_ids,
+ .id_count = sizeof(test_driver_ids)/sizeof(test_driver_ids[0]),
+ .class = 0, /* could be PCI_CLASS_NETWORK_ETHERNET
+ for generic drivers */
+};
+
+GRUB_MOD_INIT(test_driver)
+{
+ grub_register_pci_driver (test_driver);
+}
+
+GRUB_MOD_FINI(test_driver)
+{
+ grub_unregister_pci_driver (test_driver);
+}
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: RE : a simple list
; } }; ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Vincent Guffens Intelligent Systems Networks Group Research associate, Imperial College ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB2 netboot development
Rudy Attias wrote: Netboot is taking a different direction? I'm curious about that, can you give some details? yes, grub legacy also used the drivers from Etherboot and it was reported not be easily manageable. When Etherboot developpers decide to change something, the glue code written in grub might have to change too and so grub developper must constantly track these changes. Also, this messy glue code is not particularly elegant and is not very funny to program. It does not seem to me that it would happen too often but it will happen and I don't have the experience that developpers from grub legacy have. So now the idea is to have a unique UNDI driver or maybe to find a way to call into etherboot and come back into grub if the PXE/UNDI is not supported. For the moment it is not clear for anyone I think how calling into etherboot would be done. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
pci support
Hi!
I was wondering if there was still an interest in pci support as
discussed previously. That is a general interface exported by a module
such as
struct grub_pci_support
{
/* My name. */
const char *name;
void (*init)(void);
void (*fini)(void);
void (*adjust) (grub_pci_device_t p);
/* Base Address Register helper functions. There are up to 6 BARs
PCI_BASE_ADDRESS_{[0-5]} in the configuration space of each device */
unsigned long (*bar_start) (grub_pci_device_t, unsigned int bar);
unsigned long (*bar_size) (grub_pci_device_t, unsigned int bar);
int (*find_capability) (grub_pci_device_t, int cap);
/* Call HOOK with each pci device. */
grub_err_t (*iterate) (int (*hook) (grub_pci_device_t));
/* Fill the pci device structure (romaddr, ioaddr, membase, irq)*/
grub_err_t (*init_pdev) (grub_pci_device_t);
/* Low level io functions. */
struct grub_pci_io_support *io;
};
which allows multiple implementations such as one for instance from
etherboot which I have now.
It was written original with the idea of importing the etherboot drivers
so I don't know if it would still be usefull. The implementation that I
have uses direct pci access which maybe does not fit very well with the
idea of using pxe later on as it will require dealing with some bios
stuff anyway. It is basically usefull now for the lspci command which
could be made to print some nice text just like the Linux lspci command.
If so, I can prepare a separated patch for it and prepare the changelog.
Cheers,
--
Vincent Guffens
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: pci support
Marco Gerards wrote: vincent guffens [EMAIL PROTECTED] writes: Marco Gerards wrote: vincent guffens [EMAIL PROTECTED] writes: Hi Vincent, I was wondering if there was still an interest in pci support as discussed previously. That is a general interface exported by a module such as Yes, that will make it possible to implement all kinds of drivers and make something like lspci possible. Sorry I still didn't start working on the networking stuff as planned. Scripting and other stuff occupies me longer than I originally expected. :) Sure, no problem! In fact, I was wondering if it would be possible to have a discussion about the overall networking strategy that will be put in place for grub2 (and which is schedulled for the next release !). Sure! As I understand, supporting the etherboot drivers is no longer the primary option. As it is out of the question to have its own set of driver, the UNDI driver seems like a good idea. However, UNDI support would constrain significantly the design of the network stack. In particular, it defines a lot of structure such as dhcp header, ipv4 addresses and so on. It also involves interruption while it was assumed previously that the interfaces would be polled. Well, I do not really know UNDI. I had the impression it was able to send and receive raw ehternet frames. Which is what I want, nothing more and nothing less. At interrupt time, you can store the frames in a queue so they can be polled at a later moment. Or the design should be changed so interruptions can be supported. That's not a big issue I think. yes, you can use it with a polling mechanism as well. But UNDI has a much more complex API then just sending and receiving raw frames. You have API calls to request a file via tftp or even mtftp, get the information received from the dhcp server, send UDP packets and so on. It would be waste, I think, to go through the work of supporting UNDI and not getting the entire benefit which would require a strong coordination between the PXE/UNDI code and the net code of grub2 (through the PXE specification) There is also the option of calling etherboot from grub2, which seems quite appealing but I think I don't really quite get that. Is that etherboot specific or is that the case for every UNDI implementation? well, I just mentioned the idea that was raised by Okuji in an earlier post. That is what I meant and I don't know if I understood properly but etherboot implements a PXE stacks. So if a network card does not support it, it would be possible to use etherboot as the PXE stack. But I don't know how it would work. When etherboot is located in an extension rom, then maybe the bios can scan it and use it ? I am not sure but I have sent the question to the etherboot mailing list, I am waiting for some comments. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
netboot related projects
Hi, I just wanted to let you know that I contacted the maintainer of Etherboot to inform him of my current attempt to port the etherboot drivers to grub2. As I understand (don't hesitate to correct me or give more details if you know them), the development of etherboot will stop and future development will be done on a new project called gpxe. This will occur shortly when Etherboot will reach its version 5.5. gpxe will have more features such as memory allocation, availability for more platforms and so on. gpxe will also replace the development of nilo. The etherboot drivers will be used but I was told that the interface will change. -- Vincent Guffens ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: netboot related projects
Yoshinori K. Okuji wrote: On Saturday 29 April 2006 22:15, Marco Gerards wrote: vincent guffens [EMAIL PROTECTED] writes: Hi Vincent, I just wanted to let you know that I contacted the maintainer of Etherboot to inform him of my current attempt to port the etherboot drivers to grub2. Is he willing to cooperate with us so it will be easier to share code? I think I once sent him an email about it... But I am not sure anymore. :-) Honestly, I don't like to copy Etherboot's drivers to GRUB any longer. I rather consider how to use the UNDI interface provided by Etherboot. When I worked on netboot in GRUB Legacy, Etherboot didn't support UNDI, so I had to copy the drivers. According to him, the current Etherboot supports UNDI, so it should be feasible to use Etherboot's drivers via UNDI. I think the difficulty is the case where GRUB is not loaded by Etherboot, for example, when GRUB boots from a disk directly. In this case, one way would be to hack Etherboot so that Etherboot can be invoked by GRUB and give the control back to GRUB. From the experience of GRUB Legacy, I know how painful to synchronize code with an external project, so I'd like to investigate this direction. true, but this is why the idea here is to use the drivers without modification or at least with as few modifications as possible. The driver that I have working now (ns8390 to drive the qemu NE2000 emulation) works with no modification at all, it only requires the inclusion of a few lines of code before the driver code and at the end (i.e could be scripted in a general way). Further it does not put any constraint on the GRUB interface. I don't know much about UNDI but I checked that there is an UNDI driver in etherboot that could, I think, be included just as mentioned above. Of course, this require an additional glue layer which is not particularly elegant. Please, let me know what you think about this way of doing think as am I still spending some time of it in the hope that it could be usefull for grub2 (the latest version can be found at http://www.inma.ucl.ac.be/~guffens/grub2_netboot/ ). -- Vincent Guffens ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Status of UNDI Support
I am resending this mail, it looks that it didn't get through: Martin Vogt wrote: Hello grub2 developers, I just tried pxegrub2, but I found out that the network support is missing. (can load pxegrub, but no menu.lst or kernel etc) hi, i have been working on netboot support for grub2 for a while and even got it working once using code from etherboot. I am now grubifying the work in order to submit a patch. The PCI support is on its way and is going to feature an abstract interface which should ease the merging of new implementations. My experience with grub1 and the etherboot based nic support, is that it does not work well, so I still use pxelinux. I always thought that grub2 wont use etheboot and only supports UNDI, like pxelinux. As far as I know, a lot of problems related to netboot in grub were linked to the fact that the drivers could not easily be linked together as it could result in grub freezing of behaving improperly. The idea in grub2 is still to use the etherboot drivers but not to be limited by them. There will be a glue layer in order to import the etherboot drivers, hopefully with as little modifications as possible, but it will be possible to extend that. Isnt it possible to re-use some UNDI support from pxelinux and put it into grub2? I don't know very much about this UNDI support but this is certainly not incompatible with using the etherboot drivers for supported cards anyway. Grub is very flexible and we can certainly have both support if it is worth it. regards, Martin -- Vincent Guffens Intelligent Systems Networks Group Research associate, Imperial College ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: PCI config space patcher
Marco Gerards wrote: Clemens Fruhwirth [EMAIL PROTECTED] writes: Hi Clemens, I have had a problem with VIA chipsets. I abused GRUB to solve it. The intermediate product is a PCI config space patcher in GRUB. Not that it's anything new, as GRUB already contains proper PCI in netboot. However, I added a command line interface so it's available at boot. This list is about GRUB 2, while what you did is for GRUB Legacy. But I think you might be interested in GRUB 2 as well. It will get PCI support by default (Vincent is working on this, at the moment), so it might be easier to patch GRUB 2 when it is ready. -- Marco indeed the PCI implementation for grub2 is on its way. As the rest of grub2, it will be object oriented and will allow for easily adding a new implementation. You should therefore find it easy to add your patch to this framework once it is done. At least I hope so ! -- Vincent Guffens Intelligent Systems Networks Group Research associate, Imperial College ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: FOSDEM 2006
Marco Gerards wrote: Hi, Who will go to FOSDEM 24th-26th of February? Vincent Guffens and Vincent Pelletier will most likely be there (right?) and I will certainly be there. Unfortunately we do not have a hackers room and can not share a room. I expected the Hurd hackers would get a room, but that unfortunately did not happen. It would be nice if we could meet somewhere during FOSDEM. -- Marco ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel Yes, I am definitively going and for those of you who would be interested, I can provide accommodation at a friend's place not too far from the FOSDEM place (around 20 min on food, possibility to take a bus). -- Vincent Guffens UCL/CESAME +32 10 47 80 30 Euler Building A017 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: FOSDEM 2006
for me, and if I find time to improve the work before that, it would be great to discuss with everyone the merge from etherboot with grub2 for netboot support. On Fri, 18 Nov 2005 13:31:16 +0100, Marco Gerards wrote Yoshinori K. Okuji [EMAIL PROTECTED] writes: Hi, As you may know, FOSDEM 2006 is planned at the end of February. And, they started to accept applications to DevRooms: http://www.fosdem.org/index/press/devrooms_call_for_presence_2006 For now, I really have no idea if I am available at that time, but I promise that I would go, if my schedule permits. Same for me. I will go if there are no exams or so the week after that. So I have some questions: - How many people would like to attend FOSDEM? - Would anybody like to make a presentation of GRUB 2 or Multiboot Specification 2? I am willing to do that, although I suck at giving presentations. Both one or two talks are fine for me. I can give a talk about last years changes (assuming about the same people will attend) and multiboot 2. - Do we want to have our own DevRoom or share with another group as we did last year? For two talks, we won't get a room. In my opinion, sharing a DevRoom is better, if we are not too many, and another group accepts it, because we should listen to what OS developers think. Such a group can be Hurd (like last year), OpenSolaris, or a GNU/Linux distribution project (such as Debian or Ubuntu). Right, I agree. Thanks, Marco ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Vincent Guffens UCL/CESAME +32 10 47 80 30 Euler Building A017 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: FOSDEM 2006
ok, here is the status : http://www.inma.ucl.ac.be/~guffens/grub2_netboot/index.html you can see there that it is possible to cat file and I was able to boot with it. Also it is very easy to use the driver from etherboot. The problems are : 1) it has not changed since the 23rd of june and grub has changed a lot since 2) the code does not intgrate vey well into grub as I used a lot of code from etherboot directly. I should rewrite every sub component and send them one by one. On Fri, 18 Nov 2005 14:48:53 +0100, Marco Gerards wrote Vincent Guffens [EMAIL PROTECTED] writes: for me, and if I find time to improve the work before that, it would be great to discuss with everyone the merge from etherboot with grub2 for netboot support. Cool! What's the status of netboot support? Perhaps it would be nice if at least some part of it can be merged or so? -- Marco ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Vincent Guffens UCL/CESAME +32 10 47 80 30 Euler Building A017 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: backtrace support
Hi, I will make change to the patch according to these comments. +void EXPORT_FUNC(grub_register_debug_sym) (const char*, void*, grub_size_t); +void EXPORT_FUNC(grub_unregister_debug_sym) (void *); +int EXPORT_FUNC(grub_print_debug_sym) (grub_addr_t); +void EXPORT_FUNC(grub_backtrace) (void); Why do you need to export these functions? Are they used outside the kernel? grub_register_debug_sym is used by the module responsible for loading the debug symbols. grub_backtrace could be used by other modules. -- Vincent Guffens PhD Student UCL/CESAME tel: +32 10 47 80 30 Value your freedom, or you will lose it, teaches history. Don't bother us with politics, respond those who don't want to learn. -- Richard M. Stallman ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
backtrace support
Here is a new version of the backtrace support. I have written the
ChangeLog and modified the code according to your advices.
To compile with the backtrace support use ./configure --with-debug and
load grub2 with the kern_debug module. The kern module will be unloaded
automatically after having registered all the kernel symbols in a linked
list that also contains the module symbols. Any files that includes
grub/backtrace.h can now call grub_backtrace().
The functions that handle the linked list with the debug symbols are
generic and are put in kern/backtrace.c. The function grub_backtrace()
however is architecture dependant and is put in kern/i386/pc/backtrace.c.
This is a problem because I would say that it breaks compilation for
other architectures. I think that the other architectures should have a
function grub_backtrace() that does nothing, or even better that really
does print a backtrace(). However, I don't know how to do it and I can't
test it anyway.
I have also slightly modified the way genmk.rb generates the rule to
create the modules. I hope this slight change does not do anything silly
that I missed.
I hope this backtrace will be usefull, but not too much !
--
Vincent Guffens
PhD Student UCL/CESAME
tel: +32 10 47 80 30
Value your freedom, or you will lose it, teaches history.
Don't bother us with politics, respond those who don't want to learn.
-- Richard M. Stallman
diff -ru -N -b -B grub2/ChangeLog grub2-backtrace/ChangeLog
--- grub2/ChangeLog 2005-08-20 10:25:51.0 +0200
+++ grub2-backtrace/ChangeLog 2005-08-22 22:52:47.934165416 +0200
@@ -1,3 +1,45 @@
+2005-08-22 Vincent Guffens [EMAIL PROTECTED]
+
+ * conf/i386-pc.rmk : Added kern/backtrace.c, kern/i386/pc/backtrace.c
+ in the kernel dependancy list and backtrace.h in the header list. Added
a
+ new module kern_debug.mod.
+
+ * grub2/configure.ac : Added a configure switch : --with-debug.
+ Turn the gcc optimization flag to -O0 and define a variable
GRUB_DEBUG=1
+ in Makefile.in if this switch is used.
+
+ * gendebugkern.sh : New file : shell script which generates the debug
+ symbols for the kernel.
+
+ * genmk.rb : Do not strip the uneeded symbols from the objects if
+ GRUB_DEBUG=1. Add a variable $(#{prefix}_OTHERDEP) in the dependancy
list
+ of the modules. This variable can be set to something useful in
i386-pc.rmk.
+ Do not compile the module with all the dependances, just use the
sources.
+
+ * include/grub/backtrace.h : New file
+
+ * kern/backtrace.c : New file
+ (grub_register_debug_sym): New function
+ (grub_unregister_debug_sym): Likewise
+ (grub_print_debug_sym) : Likewise
+
+ * kern/dl.c : (Un)Register the debug symbols when a module is
(un)loaded.
+
+ * kern/err.c (grub_fatal) : Call grub_backtrace()
+
+ * kern/i386/pc/backtrace.c : New file
+ (get_fp) : New function
+ (grub_backtrace) : likewise
+
+ * kern/kern_debug.c : New file : This is the source for the new module
+ kern_debug. It registers the kernel symbol during its initialisation and
+ does nothing else. It is automatically removed later.
+
+ * kern/main.c (grub_load_modules) : Try to unregister the kern_debug
module.
+
+ * Makefile.in : Add a new variable GRUB_DEBUG which is set by
configure. Add
+ the rule to create the kernel symbol list in kern/grub_debug_kern.sym.
+
2005-08-20 Yoshinori K. Okuji [EMAIL PROTECTED]
* loader/powerpc/ieee1275/linux.c (grub_rescue_cmd_linux): Specify
diff -ru -N -b -B grub2/conf/i386-pc.rmk grub2-backtrace/conf/i386-pc.rmk
--- grub2/conf/i386-pc.rmk 2005-08-20 09:49:01.0 +0200
+++ grub2-backtrace/conf/i386-pc.rmk2005-08-22 20:54:51.0 +0200
@@ -28,13 +28,13 @@
kern/i386/dl.c kern/i386/pc/init.c kern/partition.c \
kern/env.c disk/i386/pc/biosdisk.c \
term/i386/pc/console.c \
- symlist.c
+ symlist.c kern/backtrace.c kern/i386/pc/backtrace.c
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 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
+ machine/vbe.h backtrace.h
kernel_img_CFLAGS = $(COMMON_CFLAGS)
kernel_img_ASFLAGS = $(COMMON_ASFLAGS)
kernel_img_LDFLAGS = -nostdlib -Wl,-N,-Ttext,8200
@@ -93,7 +93,7 @@
partmap/amiga.c partmap/apple.c partmap/pc.c partmap/sun.c \
util/console.c util/grub-emu.c util/misc.c \
util/i386/pc/biosdisk.c util/i386/pc/getroot.c \
- util
backtrace support
Hi, After having searched for the reason of the unaligned pointer caused by the nested functions bug, I thought that it could be interesting to have a backtrace in grub. It would be triggered in grub_fatal and would print the last few function calls that triggered the problem. I have implemented such a backtrace function using the stack base pointer. You can see how it looks like on the picture attached. This is a screenshot taken after the bug mentioned above and it points directly to the cause of the problem. However, the price to pay for that, at least with my implementation, is quite high. One has to disable the optimization flag to prevent the -fomit-frame-pointer and the module must not be stripped. Still, during the developpement phase, it might be usefull to get good bug reports. The feature is added with ./configure --with-backtrace and grub must be compile with ./btmake instead of make which is a simple script which calls make twice instead of only once. I include the patch as attachment, if not for inclusion in grub, at least for the potential interrested reader. -- Vincent Guffens PhD Student UCL/CESAME tel: +32 10 47 80 30 Value your freedom, or you will lose it, teaches history. Don't bother us with politics, respond those who don't want to learn. -- Richard M. Stallman attachment: backtrace.jpg diff -ru -N -b -B grub2/btmake grub2-backtrace/btmake --- grub2/btmake1970-01-01 01:00:00.0 +0100 +++ grub2-backtrace/btmake 2005-08-18 18:48:36.0 +0200 @@ -0,0 +1,9 @@ +#!/bin/sh +# Create a grub kernel image with backtrace support +# configure must have been run with : --with-backtrace +make +./genbtsym.sh kernel.exec kern/i386/pc/grub_btsym_list.txt +rm kernel_img-kern_i386_pc_backtrace.d +rm kernel_img-kern_i386_pc_backtrace.o +make + diff -ru -N -b -B grub2/conf/i386-pc.rmk grub2-backtrace/conf/i386-pc.rmk --- grub2/conf/i386-pc.rmk 2005-08-12 21:53:32.0 +0200 +++ grub2-backtrace/conf/i386-pc.rmk2005-08-15 16:22:03.0 +0200 @@ -25,7 +25,7 @@ kernel_img_SOURCES = kern/i386/pc/startup.S kern/main.c kern/device.c \ kern/disk.c kern/dl.c kern/file.c kern/fs.c kern/err.c \ kern/misc.c kern/mm.c kern/loader.c kern/rescue.c kern/term.c \ - kern/i386/dl.c kern/i386/pc/init.c kern/partition.c \ + kern/i386/dl.c kern/i386/pc/init.c kern/i386/pc/backtrace.c kern/partition.c \ kern/env.c disk/i386/pc/biosdisk.c \ term/i386/pc/console.c \ symlist.c @@ -92,7 +92,7 @@ partmap/amiga.c partmap/apple.c partmap/pc.c partmap/sun.c \ util/console.c util/grub-emu.c util/misc.c \ util/i386/pc/biosdisk.c util/i386/pc/getroot.c \ - util/i386/pc/misc.c + util/i386/pc/misc.c kern/i386/pc/backtrace.c grub_emu_LDFLAGS = $(LIBCURSES) diff -ru -N -b -B grub2/config.h.in grub2-backtrace/config.h.in --- grub2/config.h.in 2005-08-09 01:15:21.0 +0200 +++ grub2-backtrace/config.h.in 2005-08-13 18:32:23.0 +0200 @@ -16,6 +16,9 @@ /* Define it to either end or _end */ #undef END_SYMBOL +/* enable backtrace support */ +#undef GRUB_BACKTRACE + /* Define if C symbols get an underscore after compilation */ #undef HAVE_ASM_USCORE diff -ru -N -b -B grub2/configure.ac grub2-backtrace/configure.ac --- grub2/configure.ac 2005-08-09 01:15:21.0 +0200 +++ grub2-backtrace/configure.ac2005-08-18 17:36:26.0 +0200 @@ -57,9 +57,19 @@ AC_TRY_COMPILE(, , size_flag=yes, size_flag=no) ]) if test x$size_flag = xyes; then + if test $with_backtrace == yes + then + tmp_CFLAGS=$tmp_CFLAGS -O0 + else tmp_CFLAGS=$tmp_CFLAGS -Os + fi + else + if test $with_backtrace == yes + then + tmp_CFLAGS=$tmp_CFLAGS -O0 -fno-strength-reduce -fno-unroll-loops else -tmp_CFLAGS=$tmp_CFLAGS -O2 -fno-strength-reduce -fno-unroll-loops + tmp_CFLAGS=$tmp_CFLAGS -Os -fno-strength-reduce -fno-unroll-loops + fi fi # Force no alignment to save space on i386. @@ -108,6 +118,16 @@ # This is not a must. AC_PATH_PROG(RUBY, ruby) +# Include the stack trace support ? +AC_ARG_WITH(backtrace, [ --with-backtraceenable stack trace support for i386]) +if test $with_backtrace == yes +then + case $host_cpu in + i[[3456]]86) AC_DEFINE([GRUB_BACKTRACE], [], [enable backtrace support]) ;; + *) AC_MSG_NOTICE([backtrace support available for i386 only]) ;; + esac +fi + # For cross-compiling. if test x$build != x$host; then AC_CHECK_PROGS(BUILD_CC, [gcc egcs cc], diff -ru -N -b -B grub2/genbtsym.sh grub2-backtrace/genbtsym.sh --- grub2/genbtsym.sh 1970-01-01 01:00:00.0 +0100 +++ grub2-backtrace/genbtsym.sh 2005
Re: doc on memory management
Hi, I put the document on the wiki: http://www.autistici.org/grub/moin.cgi/MemoryManagement However, the links to the images points to my website as I found no other way to inline images. Is it possible to upload these images on the wiki server ? thanks, Marco Gerards wrote: Vincent Guffens [EMAIL PROTECTED] writes: Hi Vincent, I have written some doc about mm in grub2. I know this is not the most important think to do now but I had it in mind so I thought it would not be lost. The document is in latex, there is a makefile to create a pdf, dvi, ps and html. Let me know if you want to add this document somewhere and you need some other format. The pdf can be found here : http://www.auto.ucl.ac.be/~guffens/article/grub_mm_doc.pdf and the tgz with the source : http://www.auto.ucl.ac.be/~guffens/article/grub_mm_doc.tgz It's a really nice document. Thanks a lot! -- Marco ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Vincent Guffens PhD Student UCL/CESAME tel: +32 10 47 80 30 Value your freedom, or you will lose it, teaches history. Don't bother us with politics, respond those who don't want to learn. -- Richard M. Stallman ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
rmll - grub2 presentation
hi, I saw on the wiki that a presentation about grub2 is schedulled during the RMLL. Do you have more info about that such as when and where ? From here, Dijon is on the way to hollidays so I might possibly go there, and it would be great to meet people involved in grub devel. Thanks, -- Vincent Guffens PhD Student UCL/CESAME tel: +32 10 47 80 30 Value your freedom, or you will lose it, teaches history. Don't bother us with politics, respond those who don't want to learn. -- Richard M. Stallman ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: free magic is broken
Yoshinori K. Okuji wrote: On Wednesday 22 June 2005 23:13, Vincent Guffens wrote: I have prepared a small web page with some details as it is a little bit long to explain here. See it there if you want more information: http://www.auto.ucl.ac.be/~guffens/grub2_netboot/free_magic_broken.html Thank you very much for your analysis! I finally understood what's wrong, and checked in a fix (a bit different from yours). I guess it was very hard to find how to reproduce this bug. Okuji yes, it was good fun (and a long night)! I managed to post a wrong test version yesterday. In the test program, this is not grub_malloc(base-first-size*(16-1)); but grub_malloc(base-first-size*16-16); Although it turns out to be equivalent as far as the bug is concerned, in this particular example. It is good to have that nasty one behind ! -- Vincent Guffens PhD Student UCL/CESAME tel: +32 10 47 80 30 Value your freedom, or you will lose it, teaches history. Don't bother us with politics, respond those who don't want to learn. -- Richard M. Stallman ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
free magic is broken
Hi,
I have made a small test program that uses the memory management of grub2 to
manage an allocated buffer and I can reproduce the free magic is broken
problem with it.
I have prepared a small web page with some details as it is a little bit long
to explain here. See it there if you want more information:
http://www.auto.ucl.ac.be/~guffens/grub2_netboot/free_magic_broken.html
I propose the following patch to fix this problem. This patch will modify the
mm code of grub2 only when the problem would occur in subsequent call to
grub_free:
diff -ru grub2/kern/mm.c grub2_free_magic_broken/kern/mm.c
--- grub2/kern/mm.c 2005-01-20 18:25:39.0 +0100
+++ grub2_free_magic_broken/kern/mm.c 2005-06-22 22:59:58.660577232 +0200
@@ -298,6 +298,10 @@
p-next-magic = 0;
p-size += p-next-size;
p-next = p-next-next;
+ if (q-magic != GRUB_MM_FREE_MAGIC) {
+ r-first = p;
+ return;
+ }
}
if (q + q-size == p)
--
Vincent Guffens
UCL/CESAME +32 10 47 80 30
Euler Building A017
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
network support : memory management problem
Hi,
I sent a similar e-mail yesterday but I think it didn't get through.
I have a working version of the netboot support in grub2. I can issue
commands like (seeking in file is not yet possible):
cat (nd0)test.txt
linux (nd0)linux24
but depending on where in the code I free my data blocks, I sometimes
get a free magic is broken fatal error msg from grub_free().
I found out that if I use the grub_printf() function just before the
call to grub_free(), the problem disappears.
That is to say that in my grub_net_close function (the close file
function associated with the net binding file system), I do something like:
struct grub_netfs_data * priv = (struct grub_netfs_data *) file-data;
struct grub_netfs_block *pp, * p = priv-head;
grub_printf(FREEING\n);
if (p)
pp = p-next;
while (p) {
if ((p-data)){
grub_free(p-data);
}
If I remove the FREEING msg, I have the panic error message, otherwise,
everything looks fine. The exact error message is
free magic is broken at 0x85900: 0x0
Does someone has an idea ? Is there some documentation available about
the mm in grub2 ?
The full code is available on this web page:
http://www.auto.ucl.ac.be/~guffens/grub2_netboot/index.html
--
Vincent Guffens
PhD Student UCL/CESAME
tel: +32 10 47 80 30
Value your freedom, or you will lose it, teaches history.
Don't bother us with politics, respond those who don't want to learn.
-- Richard M. Stallman
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: compiling with 2.95
[...]
so I have also replaced in gencmdlist.sh the following line:
#grep -v ^# | sed -ne /grub_register_command *( *\/{s/.*(
*\\([^\]*\)\.*/\1: $module/;p}
grep -v ^# | grep -e grub_register_command *( *\ | sed -ne
s/.*grub_register_command *( *\\([^,\]*\).*/\1: $module/;p
Oh, really? This is a very standard sed expression, I think. Ummh... What
should I do?
It looks like the problem comes from the braces in the expression, if I
try a simple one like this:
$ cat test | sed -e /grub_register/{s/register/test/;p}
sed: -e expression #1, char 35: Extra characters after command
So I split the expression in two parts. From my understanding of it, the
following is equivalent to the original sed expression:
grep -v ^# | grep -e grub_register_command *( *\ | sed -ne s/.*(
*\\([^\]*\)\.*/\1: $module/;p
which is not the same line than the one I sent in the previous mail
(although they give the same command.lst)
--
Vincent Guffens
PhD Student UCL/CESAME
tel: +32 10 47 80 30
Value your freedom, or you will lose it, teaches history.
Don't bother us with politics, respond those who don't want to learn.
-- Richard M. Stallman
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
