On Sat, 2009-06-27 at 13:18 +0200, Robert Millan wrote:
> Ok but note that word size == pointer size is not always true. In fact
> I'm working on a project where it isn't :-)
>
> (if you're curious: https://savannah.gnu.org/task/?9437)
OK, when GRUB is changed to support that architecture, we
On Fri, Jun 26, 2009 at 11:08:23PM -0400, Pavel Roskin wrote:
> On Sat, 2009-06-27 at 01:57 +0200, Robert Millan wrote:
> > On Fri, Jun 26, 2009 at 06:26:57PM -0400, Pavel Roskin wrote:
> > > --- a/include/grub/elf.h
> > > +++ b/include/grub/elf.h
> > > @@ -2330,4 +2330,48 @@ typedef Elf32_Addr Elf
On Sat, 2009-06-27 at 01:57 +0200, Robert Millan wrote:
> On Fri, Jun 26, 2009 at 06:26:57PM -0400, Pavel Roskin wrote:
> > --- a/include/grub/elf.h
> > +++ b/include/grub/elf.h
> > @@ -2330,4 +2330,48 @@ typedef Elf32_Addr Elf32_Conflict;
> >
> > #define R_X86_64_NUM 24
> >
> >
On Fri, Jun 26, 2009 at 06:26:57PM -0400, Pavel Roskin wrote:
> --- a/include/grub/elf.h
> +++ b/include/grub/elf.h
> @@ -2330,4 +2330,48 @@ typedef Elf32_Addr Elf32_Conflict;
>
> #define R_X86_64_NUM 24
>
> +#ifndef DEFAULT_ELF_BITS
> +#define DEFAULT_ELF_BITS (8 * GRUB_TARGET_SIZEOF_
On Fri, 2009-06-26 at 19:43 +0200, Robert Millan wrote:
> On Fri, Jun 26, 2009 at 01:16:57PM -0400, Pavel Roskin wrote:
> > > But as for 02-elf-renames.patch we could try to make this more
> > > consistent. In
> > > efiemu I used 'W' (inspired by ElfW() macro in glibc), then in some
> > > places
On Fri, 2009-06-26 at 19:43 +0200, Robert Millan wrote:
> Ok, I don't mind. Unless you have any objections, I'll merge your two
> patches with mine and commit that.
Please let me try to do it in a nicer way.
--
Regards,
Pavel Roskin
___
Grub-devel
On Fri, Jun 26, 2009 at 01:16:57PM -0400, Pavel Roskin wrote:
> > But as for 02-elf-renames.patch we could try to make this more consistent.
> > In
> > efiemu I used 'W' (inspired by ElfW() macro in glibc), then in some places
> > you
> > use 'K' and in other places 'T'. Can we use the same eve
On Fri, 2009-06-26 at 19:03 +0200, Robert Millan wrote:
> 03-simple-symtab.patch looks nice, much cleaner than what I had.
Thanks!
> But as for 02-elf-renames.patch we could try to make this more consistent. In
> efiemu I used 'W' (inspired by ElfW() macro in glibc), then in some places you
> u
On Fri, Jun 26, 2009 at 12:44:07PM -0400, Pavel Roskin wrote:
> On Fri, 2009-06-26 at 16:41 +0200, Robert Millan wrote:
> > On Thu, Jun 25, 2009 at 04:51:11PM -0400, Pavel Roskin wrote:
> > >
> > > I'd like to avoid preprocessor conditionals in kern/ARCH/dl.c files if
> > > possible.
> >
> > Alri
On Fri, 2009-06-26 at 16:41 +0200, Robert Millan wrote:
> On Thu, Jun 25, 2009 at 04:51:11PM -0400, Pavel Roskin wrote:
> >
> > I'd like to avoid preprocessor conditionals in kern/ARCH/dl.c files if
> > possible.
>
> Alright, here's a new patch. It follows your earlier suggestion to use
> a wrap
On Thu, Jun 25, 2009 at 04:51:11PM -0400, Pavel Roskin wrote:
>
> I'd like to avoid preprocessor conditionals in kern/ARCH/dl.c files if
> possible.
Alright, here's a new patch. It follows your earlier suggestion to use
a wrapper to obtain the initialization address for symtab. This way we
don'
On Thu, 2009-06-25 at 22:31 +0200, Robert Millan wrote:
> You mean for efiemu? Seems fine. But I wouldn't use "target/host"
> naming, since it doesn't match with existing usage of those names
> elsewhere, which makes it very confusing.
>
> How about "native/cross"?
Fine with me. Whatever is m
On Thu, Jun 25, 2009 at 03:53:28PM -0400, Pavel Roskin wrote:
> On Thu, 2009-06-25 at 01:10 +0200, Robert Millan wrote:
> > On Wed, Jun 24, 2009 at 03:00:32AM +0200, Robert Millan wrote:
> > > A possible solution to this could be to make grub_dl_load_core() create a
> > > copy of the module and wor
On Thu, 2009-06-25 at 01:10 +0200, Robert Millan wrote:
> On Wed, Jun 24, 2009 at 03:00:32AM +0200, Robert Millan wrote:
> > A possible solution to this could be to make grub_dl_load_core() create a
> > copy of the module and work on the copy. This could even be ifdef'ed,
> > but I doubt the perfo
On Wed, Jun 24, 2009 at 03:00:32AM +0200, Robert Millan wrote:
> A possible solution to this could be to make grub_dl_load_core() create a
> copy of the module and work on the copy. This could even be ifdef'ed,
> but I doubt the performance hit would be significant.
I found a better approach; in
Another solution is to just leave the modules where they are (I/O map at
top of memory), and load them directly from that location. This allows
us to put the kernel in low memory without size problems.
However, our module loader assumes the memory that contains the ELFs is
writable (for example,
On Tue, Jun 23, 2009 at 01:38:50PM +0200, Robert Millan wrote:
> > If I use all modules, the image is too big:
> > grub-mkimage: error: Core image is too big (0xa8200 > 0xa)
>
> Strange, with all modules I get 0x88200. Anyway, GRUB_MEMORY_MACHINE_UPPER
> can be increased up to GRUB_BOOT_MACHI
On Mon, Jun 22, 2009 at 09:29:41PM -0400, Pavel Roskin wrote:
> On Tue, 2009-06-23 at 01:07 +0200, Robert Millan wrote:
> > This is my first "clean" (kludge-free) patch for the i386-qemu port. It
> > doesn't depend on any other patch; I send it for some final review before
> > checking it in.
>
On Mon, Jun 22, 2009 at 08:53:36PM -0400, Pavel Roskin wrote:
> On Tue, 2009-06-23 at 00:43 +0200, Robert Millan wrote:
>
> > If I omit ADDR32 on i386-pc, I get:
> >
> > 836f: 2e 66 0f 01 16 68 83lgdtl %cs:-0x7c98
> >
> > "-0x7c98" being the signed version of 0x8368, which is also
On Tue, 2009-06-23 at 01:07 +0200, Robert Millan wrote:
> This is my first "clean" (kludge-free) patch for the i386-qemu port. It
> doesn't depend on any other patch; I send it for some final review before
> checking it in.
In some cases, "2" appears on the command line. Perhaps the initial
key
On Tue, 2009-06-23 at 00:43 +0200, Robert Millan wrote:
> If I omit ADDR32 on i386-pc, I get:
>
> 836f: 2e 66 0f 01 16 68 83lgdtl %cs:-0x7c98
>
> "-0x7c98" being the signed version of 0x8368, which is also 16-bit. What is
> really odd is that you got 0x168 which is an offset to 0
On Tue, 2009-06-23 at 00:50 +0200, Vladimir 'phcoder' Serbinenko wrote:
> I made 3 images with the gap of 0x4000, 0x8000 and 0xc000.
> Then I added
> an uninitialized array to the kernel, 0x4000 bytes long, and
> made
> another 3 images with the same gap si
This is my first "clean" (kludge-free) patch for the i386-qemu port. It
doesn't depend on any other patch; I send it for some final review before
checking it in.
Comments?
--
Robert Millan
The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
how) you may access your
On Mon, Jun 22, 2009 at 05:36:22PM -0400, Pavel Roskin wrote:
> > What's the problem with removing %cs? It's presence there is bogus. It
> > *seems* to indicate gdtdesc is a segment-relative reference, but in fact
> > it's not, and it just happens to work because %cs was set to 0.
>
> I just wan
On Mon, Jun 22, 2009 at 9:51 PM, Pavel Roskin wrote:
> On Sun, 2009-06-21 at 21:33 +0200, Robert Millan wrote:
> > On Sun, Jun 21, 2009 at 03:08:19PM -0400, Pavel Roskin wrote:
> > > On Sun, 2009-06-21 at 20:50 +0200, Robert Millan wrote:
> > >
> > > > Does anyone know why do we align ELF targets
On Mon, Jun 22, 2009 at 05:44:43PM -0400, Pavel Roskin wrote:
> On Mon, 2009-06-22 at 23:32 +0200, Robert Millan wrote:
> > On Mon, Jun 22, 2009 at 10:52:13PM +0200, Robert Millan wrote:
> > > I don't think it's possible to use relative addresses
> > > with this particular instruction.
> >
> > Uhm
On Mon, Jun 22, 2009 at 05:45:54PM -0400, Pavel Roskin wrote:
> On Mon, 2009-06-22 at 23:22 +0200, Robert Millan wrote:
> > On Mon, Jun 22, 2009 at 04:51:43PM -0400, Pavel Roskin wrote:
> > >
> > > You may want to use 4 byte alignment too. It's a good thing to align
> > > 32-bit addresses in the
On Mon, 2009-06-22 at 23:22 +0200, Robert Millan wrote:
> On Mon, Jun 22, 2009 at 04:51:43PM -0400, Pavel Roskin wrote:
> >
> > You may want to use 4 byte alignment too. It's a good thing to align
> > 32-bit addresses in the ELF headers.
>
> Ok, but we aren't doing it on i386-pc, and this never
On Mon, 2009-06-22 at 23:32 +0200, Robert Millan wrote:
> On Mon, Jun 22, 2009 at 10:52:13PM +0200, Robert Millan wrote:
> > I don't think it's possible to use relative addresses
> > with this particular instruction.
>
> Uhm sorry, this was silly. Of course you can use addresses relative to a
> s
On Mon, 2009-06-22 at 22:52 +0200, Robert Millan wrote:
> On Mon, Jun 22, 2009 at 03:39:03PM -0400, Pavel Roskin wrote:
> > On Mon, 2009-06-22 at 11:52 +0200, Robert Millan wrote:
> > > > Since %cs is pointing to the code, it should be possible to point it to
> > > > gdtdesc. They should be nearb
On Mon, Jun 22, 2009 at 10:52:13PM +0200, Robert Millan wrote:
> I don't think it's possible to use relative addresses
> with this particular instruction.
Uhm sorry, this was silly. Of course you can use addresses relative to a
segment in lgdt, but this doesn't change the fact that GAS always giv
On Mon, Jun 22, 2009 at 04:51:43PM -0400, Pavel Roskin wrote:
>
> You may want to use 4 byte alignment too. It's a good thing to align
> 32-bit addresses in the ELF headers.
Ok, but we aren't doing it on i386-pc, and this never caused trouble. The
ELF headers in our modules are only loaded by G
On Mon, Jun 22, 2009 at 03:39:03PM -0400, Pavel Roskin wrote:
> On Mon, 2009-06-22 at 11:52 +0200, Robert Millan wrote:
> > > Since %cs is pointing to the code, it should be possible to point it to
> > > gdtdesc. They should be nearby.
> >
> > It is nearby, but the address reference for `gdtdesc
On Mon, 2009-06-22 at 22:41 +0200, Robert Millan wrote:
> On Mon, Jun 22, 2009 at 03:43:17PM -0400, Pavel Roskin wrote:
> > On Mon, 2009-06-22 at 14:31 +0200, Robert Millan wrote:
> > > Well it seems that OLPC (i386-ieee1275) needs alignment, but coreboot
> > > doesn't.
> > > It must be some OFW-s
On Mon, Jun 22, 2009 at 03:43:17PM -0400, Pavel Roskin wrote:
> On Mon, 2009-06-22 at 14:31 +0200, Robert Millan wrote:
> > Well it seems that OLPC (i386-ieee1275) needs alignment, but coreboot
> > doesn't.
> > It must be some OFW-specific oddity.
> >
> > This patch makes the alignment ieee1275-s
On Sun, 2009-06-21 at 21:33 +0200, Robert Millan wrote:
> On Sun, Jun 21, 2009 at 03:08:19PM -0400, Pavel Roskin wrote:
> > On Sun, 2009-06-21 at 20:50 +0200, Robert Millan wrote:
> >
> > > Does anyone know why do we align ELF targets? When I did the coreboot
> > > port,
> > > the ELF part was b
On Mon, 2009-06-22 at 14:31 +0200, Robert Millan wrote:
> Well it seems that OLPC (i386-ieee1275) needs alignment, but coreboot doesn't.
> It must be some OFW-specific oddity.
>
> This patch makes the alignment ieee1275-specific on i386.
We can define GRUB_MOD_ALIGN to 1 for such architectures an
On Mon, 2009-06-22 at 11:52 +0200, Robert Millan wrote:
> > Since %cs is pointing to the code, it should be possible to point it to
> > gdtdesc. They should be nearby.
>
> It is nearby, but the address reference for `gdtdesc' is absolute, NOT
> relative to %cs. Of course, when %cs is 0 that's n
On Mon, 2009-06-22 at 17:02 +0200, Robert Millan wrote:
> My latest qemu patch removes the redundancy between boot.img link address
> and GRUB_BOOT_MACHINE_SIZE. This requires two macros for distinguishing
> between kernel & boot link addresses:
>
> GRUB_BOOT_MACHINE_LINK_ADDR = 0xffe00
> GRU
On Mon, Jun 22, 2009 at 12:16:35PM -0400, Pavel Roskin wrote:
> On Mon, 2009-06-22 at 12:10 +0200, Robert Millan wrote:
>
> > My aim was to move this to C code so it can be shared between i386-qemu
> > and i386-coreboot. However, this code will be the same on other i386
> > ports, but we don't ye
On Mon, 2009-06-22 at 12:26 +0200, Robert Millan wrote:
> On Sun, Jun 21, 2009 at 09:22:41PM -0400, Pavel Roskin wrote:
> >
> > Then I guess the Apple compiler won't accepted %ds: either, so if we
> > want to use %ds, we should omit it.
>
> Btw, it's Apple assembler that matters here. AFAIK thei
On Mon, 2009-06-22 at 12:10 +0200, Robert Millan wrote:
> My aim was to move this to C code so it can be shared between i386-qemu
> and i386-coreboot. However, this code will be the same on other i386
> ports, but we don't yet have a generic .S file for i386 code.
>
> How about kern/i386/misc.S
My latest qemu patch removes the redundancy between boot.img link address
and GRUB_BOOT_MACHINE_SIZE. This requires two macros for distinguishing
between kernel & boot link addresses:
GRUB_BOOT_MACHINE_LINK_ADDR = 0xffe00
GRUB_KERNEL_MACHINE_LINK_ADDR = 0x8200
whereas the existing GRUB_ME
On Sun, Jun 21, 2009 at 09:30:11PM +0200, Robert Millan wrote:
> On Sun, Jun 21, 2009 at 03:00:42PM -0400, Pavel Roskin wrote:
> > > The result is you can do e.g.
> > >
> > > $ sudo grub-mkrawimage at_keyboard normal etc -o /usr/share/qemu/grub
> >
> > Please consider if we can call it grub-mki
Well it seems that OLPC (i386-ieee1275) needs alignment, but coreboot doesn't.
It must be some OFW-specific oddity.
This patch makes the alignment ieee1275-specific on i386.
--
Robert Millan
The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
how) you may access your
On Sun, Jun 21, 2009 at 09:50:25PM -0400, Pavel Roskin wrote:
> On Sun, 2009-06-21 at 22:22 +0200, Robert Millan wrote:
> > New patch, after a bunch of misc cleanup, turning hardcoded numbers into
> > macros, improving comments, etc.
>
> kernel_img_FORMAT is defined but never used.
It's used by t
On Sun, Jun 21, 2009 at 09:56:42PM -0400, Pavel Roskin wrote:
> On Sun, 2009-06-21 at 21:52 +0200, Robert Millan wrote:
> > When doing the i386-coreboot port I made this choice completely backwards.
> >
> > I thought real_to_prot() was only useful on i386-pc, because we needed it
> > for returning
On Sun, Jun 21, 2009 at 10:20:04PM -0400, Pavel Roskin wrote:
> On Sun, 2009-06-21 at 21:19 +0200, Robert Millan wrote:
> > If you check my earlier patch, you'll see i386-qemu.rmk is just a stub
> > that includes i386-coreboot.rmk. This is to reduce code duplication
> > (untill we have a more flex
On Sun, Jun 21, 2009 at 09:22:41PM -0400, Pavel Roskin wrote:
>
> Then I guess the Apple compiler won't accepted %ds: either, so if we
> want to use %ds, we should omit it.
Btw, it's Apple assembler that matters here. AFAIK their compiler is GCC.
I think those checks would need some adjustment,
On Sun, Jun 21, 2009 at 10:14:13PM -0400, Pavel Roskin wrote:
> On Sun, 2009-06-21 at 21:25 +0200, Robert Millan wrote:
> > On Sun, Jun 21, 2009 at 03:05:56PM -0400, Pavel Roskin wrote:
> > > On Sun, 2009-06-21 at 20:54 +0200, Robert Millan wrote:
> > > > Move grub_stop to init.c to ease code shari
On Sun, Jun 21, 2009 at 09:22:41PM -0400, Pavel Roskin wrote:
> On Mon, 2009-06-22 at 00:53 +0200, Robert Millan wrote:
> > In this line of code in real_to_prot():
> >
> > DATA32 ADDR32 lgdt%cs:gdtdesc
> >
> > GAS generates an absolute address for `gdtdesc' (not relative to segment),
>
On Sun, 2009-06-21 at 21:19 +0200, Robert Millan wrote:
> If you check my earlier patch, you'll see i386-qemu.rmk is just a stub
> that includes i386-coreboot.rmk. This is to reduce code duplication
> (untill we have a more flexible build system).
>
> This patch renames kernel.elf to kernel.img i
On Sun, 2009-06-21 at 21:25 +0200, Robert Millan wrote:
> On Sun, Jun 21, 2009 at 03:05:56PM -0400, Pavel Roskin wrote:
> > On Sun, 2009-06-21 at 20:54 +0200, Robert Millan wrote:
> > > Move grub_stop to init.c to ease code sharing with i386-qemu.
> >
> > That's not quite a movement. grub_cpu_idl
On Sun, 2009-06-21 at 21:52 +0200, Robert Millan wrote:
> When doing the i386-coreboot port I made this choice completely backwards.
>
> I thought real_to_prot() was only useful on i386-pc, because we needed it
> for returning from BIOS, and prot_to_real() was useful elsewhere, because
> the Linux
On Sun, 2009-06-21 at 22:22 +0200, Robert Millan wrote:
> New patch, after a bunch of misc cleanup, turning hardcoded numbers into
> macros, improving comments, etc.
kernel_img_FORMAT is defined but never used.
GRUB_MEMORY_MACHINE_LINK_ADDR doesn't need to be conditional, it's the
same for corebo
On Mon, 2009-06-22 at 00:53 +0200, Robert Millan wrote:
> In this line of code in real_to_prot():
>
> DATA32 ADDR32 lgdt%cs:gdtdesc
>
> GAS generates an absolute address for `gdtdesc' (not relative to segment),
> and so for the code to work %cs must be zero. In current usage of
> rea
In this line of code in real_to_prot():
DATA32 ADDR32 lgdt%cs:gdtdesc
GAS generates an absolute address for `gdtdesc' (not relative to segment),
and so for the code to work %cs must be zero. In current usage of
real_to_prot(), %cs is always zero because we jump to 0x0:0x82xx early
On Sun, Jun 21, 2009 at 10:34 PM, Robert Millan wrote:
> On Sun, Jun 21, 2009 at 03:00:42PM -0400, Pavel Roskin wrote:
> > On Sun, 2009-06-21 at 20:17 +0200, Robert Millan wrote:
> > > Hi,
> > >
> > > I ported GRUB to QEMU. It's mostly based on the coreboot port, with
> the
> > > main difference
On Sun, Jun 21, 2009 at 03:00:42PM -0400, Pavel Roskin wrote:
> On Sun, 2009-06-21 at 20:17 +0200, Robert Millan wrote:
> > Hi,
> >
> > I ported GRUB to QEMU. It's mostly based on the coreboot port, with the
> > main difference being that we include code to transition from i8086 mode,
> > an i386
New patch, after a bunch of misc cleanup, turning hardcoded numbers into
macros, improving comments, etc.
--
Robert Millan
The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to
When doing the i386-coreboot port I made this choice completely backwards.
I thought real_to_prot() was only useful on i386-pc, because we needed it
for returning from BIOS, and prot_to_real() was useful elsewhere, because
the Linux loader would use it.
Turns out we need real_to_prot() on i386-q
On Sun, Jun 21, 2009 at 03:08:19PM -0400, Pavel Roskin wrote:
> On Sun, 2009-06-21 at 20:50 +0200, Robert Millan wrote:
>
> > Does anyone know why do we align ELF targets? When I did the coreboot port,
> > the ELF part was based on existing Ieee1275 code, so I guess I just mimicked
> > it. Is th
On Sun, Jun 21, 2009 at 03:00:42PM -0400, Pavel Roskin wrote:
> > The result is you can do e.g.
> >
> > $ sudo grub-mkrawimage at_keyboard normal etc -o /usr/share/qemu/grub
>
> Please consider if we can call it grub-mkimage unless grub-mkimage would
> make sense as a separate executable for th
On Sun, Jun 21, 2009 at 03:05:56PM -0400, Pavel Roskin wrote:
> On Sun, 2009-06-21 at 20:54 +0200, Robert Millan wrote:
> > Move grub_stop to init.c to ease code sharing with i386-qemu.
>
> That's not quite a movement. grub_cpu_idle() does nothing.
Well, the major problem with grub_cpu_idle() do
If you check my earlier patch, you'll see i386-qemu.rmk is just a stub
that includes i386-coreboot.rmk. This is to reduce code duplication
(untill we have a more flexible build system).
This patch renames kernel.elf to kernel.img in ELF platforms, so that
more variables / etc can be shared with
On Sun, 2009-06-21 at 20:50 +0200, Robert Millan wrote:
> Does anyone know why do we align ELF targets? When I did the coreboot port,
> the ELF part was based on existing Ieee1275 code, so I guess I just mimicked
> it. Is there some issue with non-i386 CPUs or with some Ieee1275
> implementation
On Sun, 2009-06-21 at 20:54 +0200, Robert Millan wrote:
> Move grub_stop to init.c to ease code sharing with i386-qemu.
That's not quite a movement. grub_cpu_idle() does nothing.
I think we need to have several implementations of grub_stop: hard halt
with interrupts disabled, exit from qemu, exi
On Sun, 2009-06-21 at 20:17 +0200, Robert Millan wrote:
> Hi,
>
> I ported GRUB to QEMU. It's mostly based on the coreboot port, with the
> main difference being that we include code to transition from i8086 mode,
> an i386 firmware entry point and produce raw code images instead of ELF.
That's
Move grub_stop to init.c to ease code sharing with i386-qemu.
--
Robert Millan
The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all."
On Sun, Jun 21, 2009 at 08:17:48PM +0200, Robert Millan wrote:
> grub_addr_t
> grub_arch_modules_addr (void)
> {
> - return ALIGN_UP((grub_addr_t) _end, GRUB_MOD_ALIGN);
> +// return ALIGN_UP((grub_addr_t) _end, GRUB_MOD_ALIGN);
> + return _end;
> }
Some comments on this one. It seems core
Hi,
I ported GRUB to QEMU. It's mostly based on the coreboot port, with the
main difference being that we include code to transition from i8086 mode,
an i386 firmware entry point and produce raw code images instead of ELF.
The result is you can do e.g.
$ sudo grub-mkrawimage at_keyboard norm
71 matches
Mail list logo
