thank you.
but what i need also is the gdb stub to debug over serial. do you know where
i could find the right one to apply onlatest svn?
thx
-jf
On Fri, Jun 19, 2009 at 10:41 AM, wangji wrote:
> I have put the L Kundrak 's patches for grub2-gdb adjusted to svn
> revision -due to genmk.rb chang
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 Mon, Jun 22, 2009 at 11:38:35AM +0800, Bean wrote:
> >
> > I'm feeling uneasy about having a parser in GRUB that is not used by
> > default, but it's not related to the quality of the patch.
>
> Actually, this is about to change.
I don't mind LUA being supported if it's useful for some users,
On Sun, Jun 21, 2009 at 07:42:13PM -0400, Pavel Roskin wrote:
> On Sun, 2009-06-21 at 22:09 +0100, Carles Pina i Estany wrote:
>
> > > Do we really need to localize the bootloader? I think localization of
> > > the tools should be sufficient.
> >
> > By the moment I translated this string (as an
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 Mon, Jun 22, 2009 at 11:39:56AM +0200, Robert Millan wrote:
> On Sun, Jun 21, 2009 at 07:42:13PM -0400, Pavel Roskin wrote:
> > Actually, Colin D Bennett posted a link to a proposal to eliminate that
> > text. That's the link to the screenshots:
> >
> > http://ubuntuforums.org/showpost.php?p=7
On Mon, Jun 22, 2009 at 5:44 PM, Robert Millan wrote:
> On Mon, Jun 22, 2009 at 11:38:35AM +0800, Bean wrote:
>> >
>> > I'm feeling uneasy about having a parser in GRUB that is not used by
>> > default, but it's not related to the quality of the patch.
>>
>> Actually, this is about to change.
>
> I
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: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: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 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 Mon, Jun 22, 2009 at 06:26:02PM +0800, Bean wrote:
> On Mon, Jun 22, 2009 at 5:44 PM, Robert Millan wrote:
> > On Mon, Jun 22, 2009 at 11:38:35AM +0800, Bean wrote:
> >> >
> >> > I'm feeling uneasy about having a parser in GRUB that is not used by
> >> > default, but it's not related to the qual
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: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
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 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
Hi,
Update for this patch:
1, enum_device now pass fs and uuid as well
2, enum_file change parameter order, now the callback function is the
first, path is the second
3, add parameter checking for library function
4, add three function
file_eof - test if eof is encounter for a file
file_exist -
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 Tue, 2009-06-23 at 01:37 +0800, Bean wrote:
> Hi,
>
> Update for this patch:
>
> 1, enum_device now pass fs and uuid as well
> 2, enum_file change parameter order, now the callback function is the
> first, path is the second
> 3, add parameter checking for library function
> 4, add three funct
On Tue, Jun 23, 2009 at 2:31 AM, Pavel Roskin wrote:
> On Tue, 2009-06-23 at 01:37 +0800, Bean wrote:
>> Hi,
>>
>> Update for this patch:
>>
>> 1, enum_device now pass fs and uuid as well
>> 2, enum_file change parameter order, now the callback function is the
>> first, path is the second
>> 3, add
On Tue, 2009-06-23 at 02:49 +0800, Bean wrote:
> What's the name of kernel and initrd.img ?
vmlinuz-2.6.30-wl and initrd-2.6.30-wl.img
--
Regards,
Pavel Roskin
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub
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 Sun, Jun 21, 2009 at 11:18:08PM +0200, Robert Millan wrote:
> > +" Use the %C and %C keys to select which entry is highlighted.\n"
> >
> > +" Press enter to boot the selected OS, 'e' to edit the\n"
> > +" commands before booting or 'c' for a command-line."
> Uhm this string seems
On Tue, Jun 23, 2009 at 2:59 AM, Pavel Roskin wrote:
> On Tue, 2009-06-23 at 02:49 +0800, Bean wrote:
>
>> What's the name of kernel and initrd.img ?
>
> vmlinuz-2.6.30-wl and initrd-2.6.30-wl.img
Hi,
Oh, find the bug now, try this one.
>
> --
> Regards,
> Pavel Roskin
>
>
>
On Tue, 2009-06-23 at 03:15 +0800, Bean wrote:
> Oh, find the bug now, try this one.
This one fails to find anything:
sh:grub> source /boot/grub/osdetect.lua
error: Lua: grub:1: attempt to call field 'enum_device' (a nil value)
sh:grub>
--
Regards,
Pavel Roskin
__
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
El lun, 22-06-2009 a las 21:03 +0200, Jordi Mallach escribió:
> What is VERY important is that all the \n lines are part of a single msgid.
> What would be problematic (really!) would be something like:
>
> msgid "Use the %C and %C keys to select which entry is highlighted."
> msgid "Press enter t
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 Tue, Jun 23, 2009 at 3:28 AM, Pavel Roskin wrote:
> On Tue, 2009-06-23 at 03:15 +0800, Bean wrote:
>
>> Oh, find the bug now, try this one.
>
> This one fails to find anything:
>
> sh:grub> source /boot/grub/osdetect.lua
> error: Lua: grub:1: attempt to call field 'enum_device' (a nil value)
> 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 Tue, 2009-06-23 at 03:50 +0800, Bean wrote:
> strange, it's working here, what's the device list ?
My mistake. I installed an unpatched GRUB.
The entries are created now. However, the initrd is not picked up. The
old kernel (vmlinuz-2.6.30-wl.old) goes before the new one
(vmlinuz-2.6.30-wl
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 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: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, 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 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, 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, 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 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 Sat, 2009-06-20 at 09:04 +0200, Christian Franke wrote:
> I would prefer an output here even if the test done isn't a 'real'
> configure check. Would also make sense when we later apply your
> 'Use common linker script for all i386-pc systems' suggestion.
>
> But if you want to remove this me
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, 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 Thu, 2009-06-18 at 02:25 +0200, Vladimir 'phcoder' Serbinenko wrote:
> Index: util/hostdisk.c
> ===
> --- util/hostdisk.c(revision 2340)
> +++ util/hostdisk.c(working copy)
> @@ -344,7 +344,7 @@
> #else /* ! __linux__ */
>
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: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
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
Hi,
This patch adds an option to the search command to restrict the search of
a file to a given disk. It will then probe for the file in each of its
partitions, but not in other disks.
--
Robert Millan
The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
how) you may
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
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 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 01:48 +0200, Robert Millan wrote:
> This patch adds an option to the search command to restrict the search of
> a file to a given disk. It will then probe for the file in each of its
> partitions, but not in other disks.
First of all, it would be great is all proposals to a
52 matches
Mail list logo
