On Mon, Aug 10, 2009 at 06:10:40PM +0200, Robert Millan wrote:
I think it's time we begin the discussion on GRUB 1.97. What do we want to
see in it, and a rough schedule. 1.97 is meant to be a point release, without
any major changes (I mean, except for those we already have ;-)), and it
On Wed, Aug 12, 2009 at 02:43:34AM +0200, Robert Millan wrote:
On Mon, Aug 10, 2009 at 07:10:12PM +0200, Vladimir 'phcoder' Serbinenko wrote:
What about savedefault? Which savedefault way you prefer?
I think it would be good to have. But I haven't followed on the savedefault
discussion, I
On Wed, Aug 12, 2009 at 09:41:39AM +0100, Colin Watson wrote:
On Wed, Aug 12, 2009 at 02:43:34AM +0200, Robert Millan wrote:
On Mon, Aug 10, 2009 at 07:10:12PM +0200, Vladimir 'phcoder' Serbinenko
wrote:
What about savedefault? Which savedefault way you prefer?
I think it would be
2009/8/12 Robert Millan r...@aybabtu.com:
On Tue, Aug 11, 2009 at 03:33:13PM +0200, Vladimir 'phcoder' Serbinenko wrote:
Hello. A bug was filed that embedding code in grub-setup.c was
ignoring partmap metadata which could cause its overwriting. To avoid
usage of metadata and because of
2009/8/10 Vladimir 'phcoder' Serbinenko phco...@gmail.com:
What is the state of graphics on EFI?
in efi/linux.c there is a stub with a mixture of UGA and direct
access. I would prefer to switch to own drivers since EFI tries to
abstract video. Bean has GOP patch but only few mobos support it.
With GOP we get access to the framebuffer which is about as good or bad as
VBE.
GOP is supported only on UEFI 2.0, not EFI 1.10
UGA is a different story. It only supports Blt (and FillRect), not
direct access, and the the Blt data probably has to be the same format
as the screen data.
Colin Watson a crit:
On Wed, Aug 12, 2009 at 02:43:34AM +0200, Robert Millan wrote:
On Mon, Aug 10, 2009 at 07:10:12PM +0200, Vladimir 'phcoder' Serbinenko wrote:
What about savedefault? Which savedefault way you prefer?
I think it would be good to
- Low memory heap (useful to move code off kern/i386/pc/startup.S).
Originally I thought of a path relocator32-relocator users-mm
relocator32 is ready for next round of review but is untested. Now I
think about it mm patch isn't actually dependent on relocator32, just
you won't get some
On Wed, Aug 12, 2009 at 2:38 AM, Robert Millanr...@aybabtu.com wrote:
On Tue, Aug 11, 2009 at 03:33:13PM +0200, Vladimir 'phcoder' Serbinenko wrote:
Hello. A bug was filed that embedding code in grub-setup.c was
ignoring partmap metadata which could cause its overwriting. To avoid
usage of
2009/8/10 Vladimir 'phcoder' Serbinenko phco...@gmail.com:
On Mon, Aug 10, 2009 at 4:38 PM, Michal Suchanekhramr...@centrum.cz wrote:
Yes, but set_viewport works on the active target. You create an
offscreen target and set it as the active target and want to set the
viewport on it. Depending
On Wed, Aug 12, 2009 at 3:08 PM, Michal Suchanekhramr...@centrum.cz wrote:
2009/8/10 Vladimir 'phcoder' Serbinenko phco...@gmail.com:
On Mon, Aug 10, 2009 at 4:38 PM, Michal Suchanekhramr...@centrum.cz wrote:
Yes, but set_viewport works on the active target. You create an
offscreen target and
2009/8/10 Vladimir 'phcoder' Serbinenko phco...@gmail.com:
I would like a video_fb function like
grub_video_fb_create_render_target_from_buffer(void * buffer, int
allocated, const grub_video_mode_info_t * mode_info)
Well this is pretty much what we do directly. New fields can be added
to
2009/8/12 Vladimir 'phcoder' Serbinenko phco...@gmail.com:
On Wed, Aug 12, 2009 at 3:08 PM, Michal Suchanekhramr...@centrum.cz wrote:
2009/8/10 Vladimir 'phcoder' Serbinenko phco...@gmail.com:
On Mon, Aug 10, 2009 at 4:38 PM, Michal Suchanekhramr...@centrum.cz wrote:
Yes, but set_viewport
On Wed, Aug 12, 2009 at 3:17 PM, Michal Suchanekhramr...@centrum.cz wrote:
2009/8/10 Vladimir 'phcoder' Serbinenko phco...@gmail.com:
I would like a video_fb function like
grub_video_fb_create_render_target_from_buffer(void * buffer, int
allocated, const grub_video_mode_info_t * mode_info)
On Wed, Aug 12, 2009 at 6:10 PM, Vladimir 'phcoder'
Serbinenkophco...@gmail.com wrote:
This is based on previous work in GRUB Legacy by Kristian and Peter
(CCed). Peter tells me that Red Hat has an assignment already on file,
and it looks like mine is finally making some progress ...
We would
This is based on previous work in GRUB Legacy by Kristian and Peter
(CCed). Peter tells me that Red Hat has an assignment already on file,
and it looks like mine is finally making some progress ...
We would need RedHat and Kristian to sign some papers.
Constants are i386-pc specific. In
Hello list,
HDT (Hardware Detection Tool) is a Syslinux com32 module designed to display
low-level information for any x86 compatible system.
HDT runs directly on the SYSLINUX bootloader. So it doesn't need to boot first
into an operating system like DOS, linux or Windows.
Is it possible to
Hi,
I am developing an eductional/hobby OS that is multiboot-compliant that
has been booted by Legacy GRUB successfully. In this particular
instance, I am examining the Memory Map information that I obtain from
the Multiboot Information structure that Legacy GRUB returns
successfully. Available
However, when I boot using GRUB2, the Memory Map seems to have been
written over.
Some observations:
1) Legacy GRUB seems to use a combination of ELF and Multiboot header
information to boot the OS image; however, GRUB2 using the multiboot
kernel type will use strictly Multiboot protocol.
On Wed, Aug 12, 2009 at 7:42 PM, J. Bakshibaksh...@gmail.com wrote:
Hello list,
HDT (Hardware Detection Tool) is a Syslinux com32 module designed to display
low-level information for any x86 compatible system.
HDT runs directly on the SYSLINUX bootloader. So it doesn't need to boot
first
Hi Vlad (phcoder),
On Wed, 2009-08-12 at 22:09 +0200, Vladimir 'phcoder' Serbinenko wrote:
However, when I boot using GRUB2, the Memory Map seems to have been
written over.
Some observations:
1) Legacy GRUB seems to use a combination of ELF and Multiboot header
information to boot
On Wed, Aug 12, 2009 at 06:10:18PM +0200, Vladimir 'phcoder' Serbinenko wrote:
Colin Watson wrote:
This is based on previous work in GRUB Legacy by Kristian and Peter
(CCed). Peter tells me that Red Hat has an assignment already on file,
and it looks like mine is finally making some
On Tue, 2009-06-16 at 12:49 +0200, Vladimir 'phcoder' Serbinenko wrote:
+#ifdef APPLE_CC
+ movl $(mmaphook_mmap_rel), %esi
+#else
movw $(DS(mmaphook_mmap)), %si
+#endif
That's not an equivalent replacement. The
On Thu, 2009-07-16 at 18:31 +0200, Vladimir 'phcoder' Serbinenko wrote:
On Thu, Jul 16, 2009 at 5:47 AM, Pavel Roskinpro...@gnu.org wrote:
ChangeLog:
* boot/i386/pc/boot.S: Remove all code dependent on APPLE_CC.
Use local labels starting with L_ so that Apple assembler
On Fri, 2009-08-07 at 19:15 +0200, Vladimir 'phcoder' Serbinenko wrote:
gcc2 even the one updated by haiku has bugs. I don't think we should
go long way just to support it. Hence I withdraw my request for
holding this patch back because of it
Both patches have been committed.
Mirroring to
25 matches
Mail list logo
