[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
+#include
+#include
+#include
+#include
+
+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
[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.
[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)) )
Re: RE : a simple list
Eric Salomé wrote:
> Hi Vincent,
>
> I picked up your email from the archive as I didn't received it yet.
>
> As you see, it's very easy with a simple #define to create simple code
> for simple cases and yet be powerful for more complex cases :
> #define grub_iterate_list_brk(list, func, context, it) \
> {typeof(list) el = list; it = 0; \
> while (el) {if (func(context, el)) {it = el; break;} el=el->next; }}
>
> that you can call with
>
> grub_iterate_list_brk(grub_devices, compare, dev, it);
>
> with the simpliest compare function between two devices, and you get
> in-line functions nearly as simpler as the one you wrote.
>
> But let's try this :
>
> item * grub_iterate_list_brk (item * start,
> void * (*fct) (void * a, void * b), void * search) {
> while (start && fct(search, (void *) start)) start =
> start->next;
> return start ? start : (item *) fct(search, NULL);
> }
>
> that you can call with :
>
> it = (dev *) grub_iterate_list_brk((item *) grub_devices,
> devcompare, device);
Thank you very, this is definitely interesting although I don't like
these explicit castings in the code, especially not the one to (item *).
But at the end of the day I think this is overkilled and the while (dev)
seems more appropriate for simple tasks like the one I need.
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: RE : RE : grub-emu state of the art
Eric Salomé wrote: > Hi folks, > > > > This email to explain how I worked on grub-emu module loading, the > choices I have made (for now) and the diff from grub-1.93 delivery. > Marco asked me for details (well, that will make it a pretty long email > :-)). > > > > I worked only on the i386-pc architecture but I believe same steps will > lead to a working grub-emu with module loading on powerpc architecture > (though I can't do that myself). > > > > I’ve got results : My modules are loading fine, but That may be by > chance :-) > > (I still have great doubts about memory management). I did not look at your attachment so I am not sure what your are speaking about but I wonder why you mention memory management ? Memory management in grub-emu isn't done with the usual malloc and free ? ___ 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
Re: RE : a simple 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 = el;
> };
>
> static inline void _grub_del_list (struct obj **list, struct obj *el)
> {
> struct obj **p;
> struct obj *q;
>
> for (p = list, q = *p; q; p = &(q->next), q = q->next)
> if (q == el)
> {
> *p = q->next;
> break;
> }
> };
>
>
>
>
>
>
> ___
> 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: 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
Re: pci support
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 !). 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. There is also the option of calling etherboot from grub2, which seems quite appealing but I think I don't really quite get that. cheers! ___ 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: GRUB2 netboot development
Rudy Attias wrote:
> Hey,
>
>
>
> I'm interested to know, how to add drivers to the new pluggable
> architecture (grub2_netboot_7.tgz) from etherboot sources?
>
>
>
> Also wanted to say that you guys do great job with this boot loader! Now
> it needs to learn to boot from RAID and make coffee and its perfect!
>
>
>
> Rudy Attias
>
Hi!
Adding a driver from etherboot (I used 5.4.1) to this version of grub2
should be easy. Note that I have only tried the ns8390 driver so far so
it is likely that the process of addind news drivers requires more
manual interventions for the moment. The idea is that it could be made
completely automatic but it is not yet done. Also note that according to
a previous post, this mechanism which allows importing etherboot drivers
will not make it to the official grub2. The netboot support wil be based
on pxe and undi instead.
Anyway, here are the steps:
1) Copy the drivers files from the driver you want from Etherboot to
grub (Look where ns8390.c and ns8390.h are).
2) Edit the c file and add the following code at the begining of the file:
/* Added for GRUB support */
#include
/* Added for GRUB support */
3) locate in the c code the structure (probably at the bottom) marked
with __pci_driver. It must be called something like NAME_driver.
4) At the end of the c file, add the following code where NAME should be
replaced appropriately:
/* Added for GRUB support */
grub_ether_declare_probe(NAME);
grub_ether_declare_driver_struct(NAME);
GRUB_MOD_INIT(NAME)
{
(void)mod; /* To stop warning. */
grub_ether_fill_driver(NAME);
grub_register_pci_driver(&NAME_grub_driver);
}
GRUB_MOD_FINI(NAME)
{
grub_unregister_pci_driver(&NAME_grub_driver);
}
/* Added for GRUB support */
5) You now have to instruct the building process to compile a module for
your new driver. This is done by modifying the file conf/i386-pc.rmk.
Do a search for ns8390.mod and notice that it is assigned to a variable
called pkgdata_MODULES. Add your module, i.e add NAME.mod to the list of
modules assigned to this variable.
6) Do a search for ns8390.mod again and add these lines, changing what
needs to be changed
# For ns8390.mod
ns8390_mod_SOURCES = drivers/net/ns8390.c
ns8390_mod_CFLAGS = $(DRIVERS_NET_CFLAGS) $(COMMON_CFLAGS) $(DRIVERS_CFLAGS)
ns8390_mod_LDFLAGS = $(COMMON_LDFLAGS)
7) This is it, autoconf && ./configure && make and see how it goes
In order to test your news driver, you have to use the modules pci,
pci_etherboot, as well as your new module. You can use the command lspci
to check if pci support list your card and lspci_driver to see if your
driver was added properly. To probe fo your card, use scan_pci_device.
If everything goes well, you can then use tx_test to check for the
successfull transmission of a test frame.
Good luck, let me know how it goes!
___
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
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: 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: Status of UNDI Support
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
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: 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: backtrace support
I have the idea that another array for the symbols is not required. I think we can use one common table. The symbol name and symbol address are already in there. The hard thing is would getting the size, perhaps we could leave that open and fill it in with a function, or can we use a ld/gcc feature to do that? This will make the backtrace code simpler and it saves memory. Do you think that is somehow possible? This is true, another list of symbols is not required for this backtrace support but it makes the implementation a lot less intrusive. It would be possible to use some #ifdef here and there around the structures that are used already to add a field for the symbol size but it would not be very nice. If you turn the debug flag off, the code comes back to the original so I thought it would not be a problem. However, I found using a simple example that using -O2 still allows for using the frame pointer. This is to be verified but if it turns to be usable, than maybe using the --enable-debug will be less a problem and more popular so it would then be wise not to have the kernel symbol list twice. What do you think ? To correct the rest, I think I will read the GCS in detail. -- 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: 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
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
Re: backtrace support
Marco Gerards wrote: Vincent Guffens <[EMAIL PROTECTED]> writes: Hi Vincent, 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. Neat! I would like to have this in GRUB2 for debugging. If Okuji likes it too and you can send in a Changelog entry as well, I will proofread the patch so it can be applied ASAP. cool ! I will wait a little bit for your comments and those from Okuji as there are a few changes I made that I'm not sure if they are very clean, especially those in genmk.rb. I used some "cat config.h" and maybe there are some better ways. Also, I did not mention that the debuging symbol list is somehow redundant with the already existing symbol list but that way, it does not modify anything if the backtrace support is not compiled in. Should the Changelog entries be included in the patch or is it generated with the cvs log and it should then be sent in the mail body ? ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
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 <> 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"; th
Re: [PATCH] set correct gcc version in INSTALL
On Sun, 14 Aug 2005 22:29:41 -0500, Hollis Blanchard wrote > On Aug 11, 2005, at 4:44 AM, Vincent Guffens wrote: > > > The first reference I could find in the gcc doc about unnamed union > > was in 3.1.1, > > > > http://gcc.gnu.org/onlinedocs/gcc-3.1.1/gcc/Unnamed- > > Fields.html#Unnamed%20Fields > > > > If someone is however interrested, I have a version of grub (at least > > 6 months old) which compiles with 2.95. > > I can check this in, but it seems like it would be even better to > avoid unnamed unions. How big was the patch? I guess it was mostly > filesystem code? > yes it was. In fact I realize that I sent the patch already to the list. The previous post is there : http://lists.gnu.org/archive/html/grub-devel/2005-03/msg1.html Nothing was changed at that time. Maybe having the support for 2.95 isn't worth the change ? > -Hollis > > ___ > 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
problem with NESTED_FUNC_ATTR : unaligned pointer
With recent version of GRUB, I have some problem when doing some ls or
tab-completion commands.It says unaligned pointer or out of range pointer.
I spent some time on it and I think I found the problem.
In the file config.h, the NESTED_FUNC_ATTR has no value but it should be
set to :
#define NESTED_FUNC_ATTR __attribute__ ((__regparm__ (2)))
By comparing a version that work on my pc and the one that doesn't work,
I found that that in aclocal.m4, the line return nestedfunc(0,0,0) was
now ! nestedfunc(0,0,0).
As a result, the macro NESTED_FUNC_ATTR is not defined anymore and a
pointer that was pasted as a third argument of a nested function was
corrupted. This appends in grub_ext2_dir() in the nested iterate()
function which does a grub_free(node). The pointer node is the one that
was corrupted.
Maybe this is also the same problem that the one that has been reported
recently for the 1.90 release although the description is quite different.
--
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
[PATCH] set correct gcc version in INSTALL
The first reference I could find in the gcc doc about unnamed union was
in 3.1.1,
http://gcc.gnu.org/onlinedocs/gcc-3.1.1/gcc/Unnamed-Fields.html#Unnamed%20Fields
If someone is however interrested, I have a version of grub (at least 6
months old) which compiles with 2.95.
diff -ru grub2/ChangeLog grub2-gcc-ver/ChangeLog
--- grub2/ChangeLog Tue Aug 9 16:39:50 2005
+++ grub2-gcc-ver/ChangeLog Thu Aug 11 11:31:11 2005
@@ -1,3 +1,6 @@
+2005-08-11 Vincent Guffens <[EMAIL PROTECTED]>
+ * INSTALL: needed gcc version is >= 3.1.1 because of unnamed union
+
2005-08-09 Vesa Jaaskelainen <[EMAIL PROTECTED]>
* conf/i386-pc.rmk (kernel_img_HEADERS): Added machine/vbe.h.
diff -ru grub2/INSTALL grub2-gcc-ver/INSTALL
--- grub2/INSTALL Sun Apr 4 15:45:59 2004
+++ grub2-gcc-ver/INSTALL Thu Aug 11 11:28:46 2005
@@ -11,7 +11,7 @@
you don't have any of them, please obtain and install them before
configuring the GRUB.
-* GCC 2.95 or later
+* GCC 3.1.1 or later
* GNU Make
* GNU binutils 2.9.1.0.23 or later
* Other standard GNU/Unix tools
--
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: 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
Re: doc on memory management
thanks, this is corrected now !
Vladimir Serbinenko wrote:
You made an error in grub_memalign prototype:
it's
void *grub_memalign (grub_size_t align, grub_size_t size);
Not:
void grub_memalign (grub_size_t align, grub_size_t size);
Vladimir
___
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
Re: doc on memory management
Vincent Pelletier wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vincent Guffens wrote: I have written some doc about mm in grub2. Nice work, explained with nice and clear schematics. Now I understand that piece of code :). I had trouble understanding : the macro you explain in "Allocation memory" Is it the calculation of the number of blocks n to allocate ? the reason why the first free chunk of the ring is sometime moved I found one reason in the Knuth's book I mentioned in the introduction but I'm not too sure it really applies. The argument is that if you always start looking at the same first header, you will tend to accumulate after a few allocations/deallocations a long list of free small chunks after the first free chunk. So if you have to allocate a bigger block, you will have to traverse this list first. the reason why alloc'ed chunks were removed from the list It makes the allocation faster as the list you have to traverse is smaller. I wonder why the region header contains, to me, a useless field : addr. It is only set in grub_mm_init_region, invariably to the first header which is invariably at the same offset from the region beginning, defined by GRUB_MM_ALIGN. I don't think loosing sizeof(int) bytes is critical, though, as it would be padded anyway. It only made my comprehension of what's going on a little harder :). yes, it is not used anywhere ! I see a light improvement in grub_mm_init_region : /* If this region is too small, ignore it. */ if (size < GRUB_MM_ALIGN * 2) return; If the region is 2*GRUB_MM_ALIGN, we can put a grub_mm_header_t plus a grub_mm_region_t, and it would be full. Maybe adding 1 byte (or more) might make more sense (but has it any practical impact...). My realloc implementation handled the case where the realloc'ed block had enough space after to expand. I might send a patch for this someday if anyone finds it interesting to add. That would probably be a better way of doing it. I also implemented a memory defrag that merges successive free chunks in one bigger. Although it relied on the fact both alloc'ed and free chucks are known I think it can be adapted (if h->next != h+h->size*16, don't merge h and h->next) and even a bit faster (as we only see free chunks). I don't think this is needed in this case as all the necessary merging is done when a chunk is freed. Vincent Pelletier -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC75z7FEQoKRQyjtURAla2AJ9SZk9V8RSHhDHm0hajC5uOA+f28wCglptX mpVBwRDWdcPc+uAxuSvJcWA= =1Sd1 -END PGP SIGNATURE- ___ Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger Téléchargez cette version sur http://fr.messenger.yahoo.com ___ 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
doc on memory management
hi, 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 -- 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: [PATCH] Huge changes in mm.c
Vincent Pelletier wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi. In my attempt to port grub 2 to usparc, I had big problems with all the memory allocation things, so I decided to rewrite the functions after reading them (I wasn't able to understand at all 20% of the code). Some comments : It *seems* that before the alloc'ed chunks weren't linked any more with other chunks. Now all the chunks of a region are part of the same ring. Chunks were allocated from the end of the memory to the beginning, I kept this behaviour. From what I understood by reading the sources, the allocated chunks were not linked to other free chunks as you can easily recover the header of such an allocated memory chunk by using the pointer returned by the malloc function. This is simply p-1. It is not possible to free an allocated region without that pointer anyway as it is not possible to know if someone is still using that memory region. It must be released by the one who called the malloc. It *seems* that the chunk headers were "forgotten" in the malloc process, which led to my problems on usparc : a chunk was overwriting the header of the previous one. It's now fixed. Maybe it is specific of that architecture. The function grub_malloc calls grub_memalign (0, size). Then the size is converted in blocks with grub_size_t n = ((size + GRUB_MM_ALIGN - 1) >> GRUB_MM_ALIGN_LOG2) + 1; which adds the extra block for the header. Which headers were overwritten exactly, I spent quite some time on that code and I couldn't see any problem except for the "grub free magic is broken" problem but off course it was not with that architecture in mind. -- 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
netboot and memory problem : solved ?
hi !
what do you think about the following change in grub_free ?
Instead of (at the end of the function)
if (p + p->size == p->next)
{
p->next->magic = 0;
p->size += p->next->size;
p->next = p->next->next;
}
[...]
r->first = q;
I tried the following
if (p + p->size == p->next)
{
p->next->magic = 0;
p->size += p->next->size;
p->next = p->next->next;
r->first = p;
return;
}
as a reminder, my problem was that sometimes, grub2 would fataly print
(error message from grub_free):
free magic is broken at 0x37e50: 0x0
I'm quite sure that my problem is linked with that region of the code,
but I'm not too sure about the consequences of that possible fix.
At least, I can't repoduce the problem on my pc but I'll do some more
testing on monday as this problem is kind of "volatile".
I hope it's the one ! Have a good week-end !
--
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: network support : memory management problem
On Wed, 08 Jun 2005 21:38:20 +0200, Marco Gerards wrote > Vincent Guffens <[EMAIL PROTECTED]> writes: > > > I have tested three different card: Tulip, e1000, nforce2 as well as > > three compilers: gcc-2.95, gcc-3.0, gcc-3.3 However, the memory > > problem is still there, and I have no idea where it comes from. It > > varies depending on the compiler, the optimization flag, and some very > > small changes in the code. But it is always possible to find one > > combination of these for which the problem appears after loading a > > linux kernel or after the command boot or after a cat of a text file > > in the loopback device. > > It can even be in some other code you did not write... If you can > reproduce this problem easily, it would be very nice. yes, it is easy to reproduce, if you want to try by yourslef, you can find the code here: http://www.auto.ucl.ac.be/~guffens/grub2_netboot/index.html I will try again next week to find where the problem comes from. > > -- > 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: network support : memory management problem
Marco Gerards wrote:
Vincent Guffens <[EMAIL PROTECTED]> writes:
it looks like the problem is gone. I changed the way I allocate the
memory to hold a block. I changed from:
int load_block ()
char * p = (char *) grub_malloc(len*sizeof(char));
to
int load_block ()
char * p;
[...]
p = (char *) grub_malloc(len*sizeof(char));
This code is just the same. I think the problem is still there but
just does not show up anymore. I have seen a similar error before,
but I did not have the time to debug it.
Indead the problem is still there. It is now possible to do something like:
grub> ifconfig
[...]
grub> loopback lo (nd)tfile
[...]
grub> ls (lo)/
[...]
grub> cat (lo)/file.txt
[...]
I have tested three different card: Tulip, e1000, nforce2 as well as
three compilers: gcc-2.95, gcc-3.0, gcc-3.3 However, the memory problem
is still there, and I have no idea where it comes from. It varies
depending on the compiler, the optimization flag, and some very small
changes in the code. But it is always possible to find one combination
of these for which the problem appears after loading a linux kernel or
after the command boot or after a cat of a text file in the loopback device.
--
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: network support : memory management problem
it looks like the problem is gone. I changed the way I allocate the
memory to hold a block. I changed from:
int load_block ()
char * p = (char *) grub_malloc(len*sizeof(char));
to
int load_block ()
char * p;
[...]
p = (char *) grub_malloc(len*sizeof(char));
but still, I would be interested in documentation about the memory
layout and the memory management of grub2, if available.
Thanks !
Vincent Guffens wrote:
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
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: network support
Marco Gerards wrote:
Vincent Guffens <[EMAIL PROTECTED]> writes:
Hi Vincent,
I just wanted to make a small update on the network support as I've
just had grub2 sending bootp request. Here is the request as seen from
my laptop directly connected to my test pc:
Cool! nice to hear about this progress. I am sorry that I am slow
with my replies. Please keep hacking, I do care but I just have
little time.
As for now, it compiles with as many warning as there are stars in the
sky but it at least, it does something.
What I've done is as follows:
* module : grub_pci
o provided grub command : lspci, lspci_driver
Is it possible to split this up like I described in a previous email?
basically, I think this is it. The lspci_driver does nothing when you
load this module but the module exports the pci_register_driver which
take a pci_driver structure and adds it to a linked list. Then,
lspci_driver just goes through the list and display the driver name.
Drivers are not yet inited.
* module : drv_*
o provide grub command : none
o description : driver from etherboot. Uses the
pci_register_driver to register itself and do nothing else
o files: depends on the driver
Would it be later to register other kinds of devices with
pci_register_driver or is it very specific to NICs?
yes, all the etherboot drivers should just be fine after a small
modification.
* module : pcimodprobe
o provide grub command : ifconfig
o description : initialises the nic, probes for the config
o files :
Config files?
Probing for the config here means looking for a dhcp server, obtaining
an IP address, the gateway and the next-server. It does not yet look for
the dhcp option-150 for the menu.
Now, at that point, the idea is that when you type a filename looking like
(nd0,tftp)/dir/file or (nd0)/dir/file
grub2 uses its IP address to contact the next-server with tftp to
download the file /dir/file
For that purpose, I register a netfs file system. When the open method
of the fs is called, the file is downladed and all the tftp blocks are
stored in a linked list. The read method simply goes throught these
blocks and reads a given lenght of data.
The tftp option in (nd0,tftp) is there for the future if we want to add
some more download protocols like http or nfs as they do in etherboot.
The drivers are nearly no modified at all. I just changed
printf/grub_printf, added some #include and added the code to register
themselves.
Ok, cool :)
Thanks,
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
Re: network support
Hi,
I just wanted to make a small update on the network support as I've just
had grub2 sending bootp request. Here is the request as seen from my
laptop directly connected to my test pc:
14:39:44.915056 0:c0:9f:16:f6:4c Broadcast ip 590: 0.0.0.0.bootpc >
255.255.255.255.bootps: xid:0x9f16f945 [|bootp]
and it gets its address back as can be seen from the next frame:
14:39:44.915423 0:c0:9f:16:f6:4c Broadcast ip 590: muskar.bootpc >
255.255.255.255.bootps: xid:0x9f16f945 [|bootp]
As for now, it compiles with as many warning as there are stars in the
sky but it at least, it does something.
What I've done is as follows:
* module : grub_pci
o provided grub command : lspci, lspci_driver
o description : loads the core pci routine, initiliases the
pci_device list (dev_list), export the symbols need to register new drivers
o files: grub_pci.c, pci_io.c, i386_timer.c, timer.c
* module : drv_*
o provide grub command : none
o description : driver from etherboot. Uses the
pci_register_driver to register itself and do nothing else
o files: depends on the driver
* module : pcimodprobe
o provide grub command : ifconfig
o description : initialises the nic, probes for the config
o files :
The drivers are nearly no modified at all. I just changed
printf/grub_printf, added some #include and added the code to register
themselves.
Cheers,
Marco Gerards wrote:
Vincent Guffens <[EMAIL PROTECTED]> writes:
yes but I was just thinking about other people who would like to work
on it meanwhile. As I have never done that before, it might take some
time and I might not be able to do it at all. But, ok it is a good
start to have this lspci working. I go back to work and see how it
goes.
Yeah, cool. I am looking forwards to a patch. If you need any help
or testers, feel free to contact me over email or IRC.
--
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
Re: network support
Marco Gerards wrote:
[...]
Also, if we add a tftp command, what should we do with the downloaded
file. Maybe it would be convenient to have some kind of ramfs to be
able to copy the files there ?
Why? The loader could load the file into memory, no?
it is just that I was thinking about tftp'ing module in the filesystem
and loading them from there or something like that but it not necessary
now.
What should I do now ? It is not practical to send a patch as they are
many news files coming directly from etherboot. Would it be an idea to
have a new netboot branch in the cvs so that it would be possible to
experiment with it without breaking anything else ?
Perhaps it would be better to wait until you have things working? I
could test rtl8029, rtl8139 and some other cards I forgot about.
yes but I was just thinking about other people who would like to work on
it meanwhile. As I have never done that before, it might take some time
and I might not be able to do it at all. But, ok it is a good start to
have this lspci working. I go back to work and see how it goes.
cheers !
--
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
network support
Hi,
I started to integrate network support into grub2 using the code from
etherboot 5.3.14.
Although it is still very basic, I sent it now as I saw the post
"question" about network support, so it might be time to discuss about it.
What I've done so far is simply to add a "lspci" command as a grub
module, which seems to work on my pc. Because it uses the pci code from
etherboot, it should be a good starting point to start porting all their
drivers.
I was thinking that it could be a good idea to be able to use their
drivers with no modification at all so that future management would be
easier. New driver in grub would also mean new drivers in etherboot and
the other way around.
In grub legacy, there was this problem when compiling a lot of drivers
in. How do we avoid it here ? I was thinking that it could be possible
to use the lspci to find out the device id and initialize only the right
driver, but maybe it is not practical ? Is it done anywhere else like
that or do they probe the card by trying the iniliazation routine of the
driver ?
Also, if we add a tftp command, what should we do with the downloaded
file. Maybe it would be convenient to have some kind of ramfs to be able
to copy the files there ?
What should I do now ? It is not practical to send a patch as they are
many news files coming directly from etherboot. Would it be an idea to
have a new netboot branch in the cvs so that it would be possible to
experiment with it without breaking anything else ?
--
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
Re: compiling with 2.95
Marco Gerards wrote:
"Yoshinori K. Okuji" <[EMAIL PROTECTED]> writes:
Although I don't know if you are interrested in that or not, I'm
sending some modifications about these three items that allows grub 2
to be compiled with 2.95.4 (at least on my system).
Your patch is definitely useful. But I'm not sure about unnamed union...
It is not so convenient to specify union names. I think the code was
written by Marco, so I'd like to hear his opinion about this.
This weekend I will have a look at this. I had the feeling it
should've worked with gcc 2.95, but I never tried it myself.
Hopefully I can find some box with gcc 2.95... In the weekend I will
try to do some other hacking as well.
I had a look in google about unnamed unions and I have seen some
references about them with 2.95 but I was not able to compile with them.
Maybe there is a gcc switch for them ?
Also, when compiling with an "old" system, there is this sed error message:
sed: -e expression #1, char 69: Extra characters after command
the sed version is:
$ sed -V
GNU sed version 3.02
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"
--
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
compiling with 2.95
eld))
#define INODE_SIZE(data) INODE_ENDIAN (data,size,32,64)
#define INODE_MODE(data) INODE_ENDIAN (data,mode,16,16)
#define INODE_BLKSZ(data) (data->ufs_type == UFS1 ? 32 : 64)
#define INODE_DIRBLOCKS(data,blk) INODE_ENDIAN \
- (data,blocks.dir_blocks[blk],32,64)
+
(data,ufs_inode_union.blocks.dir_blocks[blk],32,64)
#define INODE_INDIRBLOCKS(data,blk) INODE_ENDIAN \
- (data,blocks.indir_blocks[blk],32,64)
+
(data,ufs_inode_union.blocks.indir_blocks[blk],32,64)
/* The blocks on which the superblock can be found. */
static int sblocklist[] = { 128, 16, 0, 512, -1 };
@@ -112,7 +112,7 @@
grub_uint32_t indir_blocks[GRUB_UFS_INDIRBLKS];
} blocks;
grub_uint8_t symlink[(GRUB_UFS_DIRBLKS + GRUB_UFS_INDIRBLKS) * 4];
- };
+ } ufs_inode_union;
grub_uint32_t flags;
grub_uint32_t nblocks;
grub_uint32_t gen;
@@ -151,7 +151,7 @@
grub_uint64_t indir_blocks[GRUB_UFS_INDIRBLKS];
} blocks;
grub_uint8_t symlink[(GRUB_UFS_DIRBLKS + GRUB_UFS_INDIRBLKS) * 8];
- };
+ } ufs_inode_union;
grub_uint8_t unused[24];
};
@@ -174,7 +174,9 @@
{
struct grub_ufs_inode inode;
struct grub_ufs2_inode inode2;
- };
+ } ufs_data_union ;
+#define ufs_inode ufs_data_union.inode
+#define ufs_inode2 ufs_data_union.inode2
enum
{
UFS1,
@@ -323,7 +325,7 @@
if (data->ufs_type == UFS1)
{
- struct grub_ufs_inode *inode = &data->inode;
+ struct grub_ufs_inode *inode = &data->ufs_inode;
grub_disk_read (data->disk,
(((grub_le_to_cpu32 (sblock->inoblk_offs) + grpblk)
@@ -335,7 +337,7 @@
}
else
{
- struct grub_ufs2_inode *inode = &data->inode2;
+ struct grub_ufs2_inode *inode = &data->ufs_inode2;
grub_disk_read (data->disk,
(((grub_le_to_cpu32 (sblock->inoblk_offs) + grpblk)
diff -ru grub2/include/grub/misc.h grub2-mod/include/grub/misc.h
--- grub2/include/grub/misc.h Sat Jan 29 23:01:53 2005
+++ grub2-mod/include/grub/misc.h Wed Mar 2 11:38:21 2005
@@ -35,6 +35,7 @@
char *EXPORT_FUNC(grub_stpcpy) (char *dest, const char *src);
char *EXPORT_FUNC(grub_strcat) (char *dest, const char *src);
char *EXPORT_FUNC(grub_strncat) (char *dest, const char *src, int c);
+void *EXPORT_FUNC(memset) (void *s, int c, grub_size_t n);
/* Prototypes for aliases. */
void *EXPORT_FUNC(memmove) (void *dest, const void *src, grub_size_t n);
--
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
