Update on xnu.mod

Update on xnu.mod

[phcoder]

[-- Attachment #1: Type: text/plain, Size: 44 bytes --]


-- 

Regards
Vladimir 'phcoder' Serbinenko

[-- Attachment #2: xnu.mod --]
[-- Type: audio/x-mod, Size: 42200 bytes --]

Re: Update on xnu.mod

[phcoder]

Sorry this was supposed to be personal email to step21. I would never 
send a binary to a list
phcoder wrote:
> 


-- 

Regards
Vladimir 'phcoder' Serbinenko

Kexec loading grub2

[Joey Korkames]

For a number of weird reasons, I would find the ability to kexec into grub2 from a running linux system useful.

In looking at the current code out there, there seems to be two ways to make 
grub2 able to support this:

1)  Add a 32-bit load segment to boot/i386/pc/lnxboot.S as described by
 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/x86/boot.txt (at the bottom)

  grub4dos (which is kexec'able) implements this in startup_32: @ http://svn.gna.org/viewcvs/grub4dos/trunk/stage2/dosstart.S?view=markup


2) Adjust the ELF images made by grub-mkimage (for coreboot) to be loaded by kexec-tools's ELF loader (or vice-versa).
  
  I figure this is the best route to go about adding kexec boot ability to grub2
  since the BIOS-services-less kexec environment may be similar to coreboot's environment.

  Currently, loading this image:

    grub-mkelfimage --directory=/usr/lib/grub/i386-coreboot --prefix="/boot/grub" --output=grub2.elf --memdisk=memdisk.cpio memdisk cpio

    #readelf -l grub2.elf 
    > 
    > Elf file type is EXEC (Executable file)
    > Entry point 0x8200
    > There are 3 program headers, starting at offset 52
    > 
    > Program Headers:
    >   Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
    >   LOAD           0x000094 0x00008200 0x00008200 0x06fd8 0x0e86c RWE 0x20
    >   GNU_STACK      0x00706c 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4
    >   LOAD           0x00706c 0x00017000 0x00017000 0x73fb0 0x73fb0 RWE 0x4
    > 

    #file -k grub2.elf 
    > grub2.elf: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped
  
  like so:
  (using latest git://git.kernel.org/pub/scm/linux/kernel/git/horms/kexec-tools.git)
  # kexec --type multiboot-x86 --load grub2.elf
  
  issues this error:
  > Base address: 8200 is not page aligned
  
  The original kexec kernel patch maintainer had these things to say about that:
  https://lists.linux-foundation.org/pipermail/fastboot/2005-August/008743.html
  http://www.mail-archive.com/fastboot@lists.linux-foundation.org/msg00249.html

  I noticed this line in the grub2 src:
   ./conf/i386-coreboot.rmk:36:kernel_elf_LDFLAGS = $(COMMON_LDFLAGS) -Wl,-N,-S,-Ttext,0x8200,-Bstatic
  but I'm sure there's gonna be more involved than just changing that to 0x8000.
  
  kexec_test is an example of a kexec-loadable elf:
   (http://git.kernel.org/?p=linux/kernel/git/horms/kexec-tools.git;a=tree;f=kexec_test;hb=HEAD)
   #file -k kexec-tools.git/build/lib/kexec-tools/kexec_test
   > kexec_test: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, not stripped

   #readelf -l /tmp/kexec-tools/build/lib/kexec-tools/kexec
   > 
   > Elf file type is EXEC (Executable file)
   > Entry point 0x109c4
   > There are 2 program headers, starting at offset 52
   > 
   > Program Headers:
   >   Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
   >   LOAD           0x001000 0x00010000 0x00010000 0x00e40 0x00e40 R E 0x1000
   >   LOAD           0x002000 0x00011000 0x00011000 0x00000 0x0102c RW  0x1000
   > 
   >  Section to Segment mapping:
   >   Segment Sections...
   >    00     .text 
   >    01     .bss
   

I don't have the know-how currently to implement either route but I may be able to
learn with a little guidance. I'm asking about it here so as not to repeat any work-in-progress.

Thanks
-joey

Re: Kexec loading grub2

[Robert Millan]

On Tue, Apr 14, 2009 at 02:28:21PM -0700, Joey Korkames wrote:
> 1)  Add a 32-bit load segment to boot/i386/pc/lnxboot.S as described by
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/x86/boot.txt (at the bottom)
>
>  grub4dos (which is kexec'able) implements this in startup_32: @ http://svn.gna.org/viewcvs/grub4dos/trunk/stage2/dosstart.S?view=markup

Please use Multiboot.  It's about time we start standarising on boot
protocols...

>  # kexec --type multiboot-x86 --load grub2.elf
>   issues this error:
>  > Base address: 8200 is not page aligned

Multiboot doesn't require that load addresses are page aligned, but I think you
can change the link address without much trouble.

If you use 0x100000, though, the Linux loader will probably stop working.

-- 
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."

Re: Kexec loading grub2

[Joey Korkames]

> Please use Multiboot.  It's about time we start standarising on boot
> protocols...
> 
>>  # kexec --type multiboot-x86 --load grub2.elf
>>   issues this error:
>>  > Base address: 8200 is not page aligned
> 
> Multiboot doesn't require that load addresses are page aligned, but I think you
> can change the link address without much trouble.
> 

I'll try changing the load address in the .rmk and 
see where that goes with --type multiboot-x86.

> If you use 0x100000, though, the Linux loader will probably stop working.

I'm not too worried about breaking the linux loader since kexec can load linux 
directly...as long as it can load some other OS's (multiboot - kexec can only multiboot Xen, *BSD)
or chainloader, I'll be happy.

Thanks for the response!

-joey

Re: Kexec loading grub2

[Robert Millan]

On Sat, May 02, 2009 at 03:04:47PM -0700, Joey Korkames wrote:
>> If you use 0x100000, though, the Linux loader will probably stop working.
>
> I'm not too worried about breaking the linux loader since kexec can load 
> linux directly...as long as it can load some other OS's (multiboot - 
> kexec can only multiboot Xen, *BSD)
> or chainloader, I'll be happy.

Our multiboot loader is very flexible, it can load _anywhere_, including
its own heap, stack, code or data segments.  However, not all payloads are
prepared to accept any load address.

-- 
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."