On Thursday 24 January 2008 12:49, Bean wrote:
> On Jan 24, 2008 7:32 PM, Robert Millan <[EMAIL PROTECTED]> wrote:
> > Sorry, my question was confusing; what I meant is, where is it located
> > when core.img is started. But Just checked in our Linux loader, and it
> > seems to be at a very high a
Robert Millan <[EMAIL PROTECTED]> writes:
> On Fri, Jan 25, 2008 at 01:04:34AM +0800, Bean wrote:
>> On Jan 25, 2008 12:55 AM, Robert Millan <[EMAIL PROTECTED]> wrote:
>> > On Thu, Jan 24, 2008 at 03:25:51PM +0100, Robert Millan wrote:
>> > >
>> > > You want to add a feature that only works when y
On Fri, Jan 25, 2008 at 01:04:34AM +0800, Bean wrote:
> On Jan 25, 2008 12:55 AM, Robert Millan <[EMAIL PROTECTED]> wrote:
> > On Thu, Jan 24, 2008 at 03:25:51PM +0100, Robert Millan wrote:
> > >
> > > You want to add a feature that only works when you have the ability to
> > > load
> > > images o
On Jan 25, 2008 12:55 AM, Robert Millan <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 24, 2008 at 03:25:51PM +0100, Robert Millan wrote:
> >
> > You want to add a feature that only works when you have the ability to load
> > images of an arbitrary size. However, if we had this ability we wouldn't
> >
On Thu, Jan 24, 2008 at 03:25:51PM +0100, Robert Millan wrote:
>
> You want to add a feature that only works when you have the ability to load
> images of an arbitrary size. However, if we had this ability we wouldn't have
> to compress core.img, or make it small in the first place. We would the
On Thu, Jan 24, 2008 at 10:57:46PM +0800, Bean wrote:
> >
> > However, my point is more about the loadee than the loader. We provide a
> > multiboot image, which can also be a linux image with lnxboot.img, however,
> > this image needs to be very small, because it's intended usage is with
> > grub
On Jan 24, 2008 10:25 PM, Robert Millan <[EMAIL PROTECTED]> wrote:
>
> On Thu, Jan 24, 2008 at 07:49:23PM +0800, Bean wrote:
> > On Jan 24, 2008 7:32 PM, Robert Millan <[EMAIL PROTECTED]> wrote:
> > > Sorry, my question was confusing; what I meant is, where is it located
> > > when
> > > core.img
On Thu, Jan 24, 2008 at 07:49:23PM +0800, Bean wrote:
> On Jan 24, 2008 7:32 PM, Robert Millan <[EMAIL PROTECTED]> wrote:
> > Sorry, my question was confusing; what I meant is, where is it located when
> > core.img is started. But Just checked in our Linux loader, and it seems to
> > be
> > at a
On Jan 24, 2008 7:32 PM, Robert Millan <[EMAIL PROTECTED]> wrote:
> Sorry, my question was confusing; what I meant is, where is it located when
> core.img is started. But Just checked in our Linux loader, and it seems to be
> at a very high address.
>
> However, a very high address doesn't garant
On Thu, Jan 24, 2008 at 11:40:25AM +0800, Bean wrote:
> On Jan 24, 2008 5:15 AM, Robert Millan <[EMAIL PROTECTED]> wrote:
> >
> > On Thu, Jan 24, 2008 at 05:04:56AM +0800, Bean wrote:
> > > On Jan 24, 2008 4:15 AM, Robert Millan <[EMAIL PROTECTED]> wrote:
> > > > The region where memdisk is normall
On Jan 24, 2008 5:15 AM, Robert Millan <[EMAIL PROTECTED]> wrote:
>
> On Thu, Jan 24, 2008 at 05:04:56AM +0800, Bean wrote:
> > On Jan 24, 2008 4:15 AM, Robert Millan <[EMAIL PROTECTED]> wrote:
> > > The region where memdisk is normally put has no size limit, only the core
> > > image itself does.
On Thu, Jan 24, 2008 at 05:04:56AM +0800, Bean wrote:
> On Jan 24, 2008 4:15 AM, Robert Millan <[EMAIL PROTECTED]> wrote:
> > The region where memdisk is normally put has no size limit, only the core
> > image itself does. Why not load it at the same address?
>
> I just check, the lzo decompressi
On Jan 24, 2008 4:15 AM, Robert Millan <[EMAIL PROTECTED]> wrote:
> The region where memdisk is normally put has no size limit, only the core
> image itself does. Why not load it at the same address?
I just check, the lzo decompression will overwrite the area, so we
can't copy initrd there.
--
On Thu, Jan 24, 2008 at 03:24:37AM +0800, Bean wrote:
> On Jan 24, 2008 3:14 AM, Robert Millan <[EMAIL PROTECTED]> wrote:
> > On Thu, Jan 24, 2008 at 03:01:33AM +0800, Bean wrote:
> > > On Jan 24, 2008 12:18 AM, Bean <[EMAIL PROTECTED]> wrote:
> > > > On Jan 23, 2008 4:54 PM, Marco Gerards <[EMAIL
On Jan 24, 2008 3:14 AM, Robert Millan <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 24, 2008 at 03:01:33AM +0800, Bean wrote:
> > On Jan 24, 2008 12:18 AM, Bean <[EMAIL PROTECTED]> wrote:
> > > On Jan 23, 2008 4:54 PM, Marco Gerards <[EMAIL PROTECTED]> wrote:
> > > > When is this feature useful? Can y
On Thu, Jan 24, 2008 at 03:01:33AM +0800, Bean wrote:
> On Jan 24, 2008 12:18 AM, Bean <[EMAIL PROTECTED]> wrote:
> > On Jan 23, 2008 4:54 PM, Marco Gerards <[EMAIL PROTECTED]> wrote:
> > > When is this feature useful? Can you give an example? More features
> > > can mean more bugs, more maintain
On Thu, Jan 24, 2008 at 12:18:43AM +0800, Bean wrote:
> On Jan 23, 2008 4:54 PM, Marco Gerards <[EMAIL PROTECTED]> wrote:
> > When is this feature useful? Can you give an example? More features
> > can mean more bugs, more maintainance work, etc. If the feature is
> > not worthwhile for more tha
On Jan 24, 2008 12:18 AM, Bean <[EMAIL PROTECTED]> wrote:
> On Jan 23, 2008 4:54 PM, Marco Gerards <[EMAIL PROTECTED]> wrote:
> > When is this feature useful? Can you give an example? More features
> > can mean more bugs, more maintainance work, etc. If the feature is
> > not worthwhile for more
On Jan 23, 2008 4:54 PM, Marco Gerards <[EMAIL PROTECTED]> wrote:
> When is this feature useful? Can you give an example? More features
> can mean more bugs, more maintainance work, etc. If the feature is
> not worthwhile for more than one person, I am not sure if it should be
> included. Perha
Robert Millan <[EMAIL PROTECTED]> writes:
>> 2. Easy to modify
>> users may not know how to create core.img, but modifying files in a,
>> say, tar or cpio archive is very easy. They can do simple tasks like
>> replacing splash image without too much knowledge of grub2.
>>
>> 3. Multiple configurat
Bean <[EMAIL PROTECTED]> writes:
[...]
> 2. Easy to modify
> users may not know how to create core.img, but modifying files in a,
> say, tar or cpio archive is very easy. They can do simple tasks like
> replacing splash image without too much knowledge of grub2.
It seems easier, but isn't. Firs
On Wed, Jan 23, 2008 at 01:17:43AM +0800, Bean wrote:
> On Jan 23, 2008 12:51 AM, Robert Millan <[EMAIL PROTECTED]> wrote:
> > I don't like this very much. We don't have grub-mkimage options to
> > concatenate
> > it with boot.img, so why with lnxboot.img ?
>
> The reason for new option is that
On Jan 23, 2008 12:51 AM, Robert Millan <[EMAIL PROTECTED]> wrote:
> I don't like this very much. We don't have grub-mkimage options to
> concatenate
> it with boot.img, so why with lnxboot.img ?
The reason for new option is that the length of core.img needs to
stored in lnxboot.img. Previously,
On Wed, Jan 23, 2008 at 12:22:32AM +0800, Bean wrote:
> * util/i386/pc/grub-mkimage.c (generate_image) : Add is_linux parameter.
> If it's set, use lnxboot.img as header instead of diskboot.img.
> (options): Add "linux"|'x' option
> (main): Parse --linux|-x option, and pass
On Jan 22, 2008 9:57 PM, Robert Millan <[EMAIL PROTECTED]> wrote:
> On Tue, Jan 22, 2008 at 12:25:49PM +0800, Bean wrote:
> > > but, what is the advantage in that? Is there any use case in which the
> > > first
> > > option is not good but the second is?
> >
> > Some advantages of using external
On Tue, Jan 22, 2008 at 12:25:49PM +0800, Bean wrote:
> > but, what is the advantage in that? Is there any use case in which the
> > first
> > option is not good but the second is?
>
> Some advantages of using external initrd:
>
> 1, Resolve size limit for core.img
> core.img can't be too large
On Jan 21, 2008 7:24 AM, Robert Millan <[EMAIL PROTECTED]> wrote:
> On Sun, Dec 30, 2007 at 02:48:24PM +0100, Robert Millan wrote:
> > On Sat, Dec 29, 2007 at 05:05:16PM +0800, Bean wrote:
> > > Hi,
> > >
> > > This patch is based on robert's memdisk patch. I also modify lnxboot
> > > so that it ca
On Sun, Dec 30, 2007 at 02:48:24PM +0100, Robert Millan wrote:
> On Sat, Dec 29, 2007 at 05:05:16PM +0800, Bean wrote:
> > Hi,
> >
> > This patch is based on robert's memdisk patch. I also modify lnxboot
> > so that it can load the memdisk using initrd. Changes:
>
> I'd really like to keep this s
On Sat, Dec 29, 2007 at 05:05:16PM +0800, Bean wrote:
> Hi,
>
> This patch is based on robert's memdisk patch. I also modify lnxboot
> so that it can load the memdisk using initrd. Changes:
I'd really like to keep this separate, and get memdisk merged first.
I recall Marco had some objections to
Hi,
This patch is based on robert's memdisk patch. I also modify lnxboot
so that it can load the memdisk using initrd. Changes:
1, copy memdisk to grub_alloc'ed memory in grub_machine_init, so that
it won't be corrupted.
2, code cleanup for lnxboot.S, now it doesn't contain code that uses
32-bit
30 matches
Mail list logo
