Re: [LinuxBIOS] Complete and generic 32bit/64bit support

[Myles Watson]

This is the same patch as the one Jordan sent before, but

1. Making UCLIBC_VER work

2. Adding a few forgotten files

3. Adding a few more devices in devices.txt so that the hard drives
and CD can be used once you're in linux

I tested it with 64-bit serengeti cheetah and 32-bit tyan s2891.

Some things still don't work, but not because of this patch:

1. Building 32-bit kexec-boot-loader is broken on 64-bit machines
(cross-compile flags issue)
2. The ROM ends up being too large for tyan s2891 LAB

Signed-off-by: Myles Watson

[LinuxBIOS] Complete and generic 32bit/64bit support

[Jordan Crouse]

Thanks Myles - I don't want to leave this on the floor, but we probably
won't get any traction on it until Monday.  Ward, if you don't mind,
could you rebase your patches against this one?  If not, thats cool,
I can do it too.

Jordan

PS:  I would be remiss if I didn't say - Go Utes! :)

On 16/11/07 16:09 -0700, Myles Watson wrote:
> This is the same patch as the one Jordan sent before, but
>
> Making UCLIBC_VER work
>
> Adding a few forgotten files
>
> Adding a few more devices in devices.txt so that the hard drives
>
> and CD can be used once you're in linux
>
> I tested it with 64-bit serengeti cheetah and 32-bit tyan s2891.
>
> Some things still don't work, but not because of this patch:
> Building 32-bit kexec-boot-loader is broken on 64-bit machines
>
> (cross-compile flags issue)
> 2. The ROM ends up being too large for tyan s2891 LAB
>
> Signed-off-by: Myles Watson

[LinuxBIOS] Complete and generic 32bit/64bit support

[Ward Vandewege]

Hi Myles,

On 16/11/07 16:09 -0700, Myles Watson wrote:
> This is the same patch as the one Jordan sent before, but
>
> Making UCLIBC_VER work
>
> Adding a few forgotten files
>
> Adding a few more devices in devices.txt so that the hard drives
>
> and CD can be used once you're in linux
>
> I tested it with 64-bit serengeti cheetah and 32-bit tyan s2891.
>
> Some things still don't work, but not because of this patch:
> Building 32-bit kexec-boot-loader is broken on 64-bit machines
>
> (cross-compile flags issue)
> 2. The ROM ends up being too large for tyan s2891 LAB
>
> Signed-off-by: Myles Watson

This patch does not set the UCLIBC_ARCH variable correctly on 32 bit; it
needs to be forced to i386 there instead of $(TARGET_ARCH), which is i686 on
my box.

For 64 bit it's fine, because there the UCLIBC_ARCH variable needs to be
x86_64 which happens to match $(TARGET_ARCH).

Here's a simple fix for the m57sli board:

--- config/platforms/m57sli.conf        (revision 57)
+++ config/platforms/m57sli.conf        (working copy)
@@ -6,8 +6,15 @@
 STRIP=strip
 AS=as

+ifeq ($(CONFIG_TARGET_64BIT),y)
+TARGET_ARCH=x86_64
+UCLIBC_ARCH=x86_64
+CFLAGS_platform =
+else
 TARGET_ARCH=i686
-CFLAGS_platform = -m32
+UCLIBC_ARCH=i386
+CFLAGS_platform =
+endif

Can you fix that for all boards?

The other thing I was wondering about is why the exit -1 is dropped in
buildrom-devel/bin/checkrom.sh when the image won't fit? It's nice for the
build to fail explicitly if the image is too big instead of producing obscure
linker errors further down the line.

For the rest this looks good to me; your patch passed a build test here on 32
bit. We may want to add some warnings bout the LAB size issues when building
on 64 bit. And I'm actually also a little curious why we are having problems
there.

If the above get fixed,

Acked-by: Ward Vandewege

Thanks,
Ward.

[LinuxBIOS] Complete and generic 32bit/64bit support

[Myles Watson]

> This patch does not set the UCLIBC_ARCH variable correctly on 32 bit; it
> needs to be forced to i386 there instead of $(TARGET_ARCH), which is i686 on
> my box.
>
> For 64 bit it's fine, because there the UCLIBC_ARCH variable needs to be
> x86_64 which happens to match $(TARGET_ARCH).
>
> Here's a simple fix for the m57sli board:
>
> --- config/platforms/m57sli.conf        (revision 57)
> +++ config/platforms/m57sli.conf        (working copy)
> @@ -6,8 +6,15 @@
>  STRIP=strip
>  AS=as
>
> +ifeq ($(CONFIG_TARGET_64BIT),y)
> +TARGET_ARCH=x86_64
> +UCLIBC_ARCH=x86_64
> +CFLAGS_platform =
> +else
>  TARGET_ARCH=i686
> -CFLAGS_platform = -m32
> +UCLIBC_ARCH=i386
> +CFLAGS_platform =
> +endif
>
> Can you fix that for all boards?

How about this fix?  Can you test the attached patch?  It fixes it in
uclibc.mk instead of in each individual board.

If the patch works for you, I'll send a full patch from the latest svn.
> The other thing I was wondering about is why the exit -1 is dropped in
> buildrom-devel/bin/checkrom.sh when the image won't fit? It's nice for the
> build to fail explicitly if the image is too big instead of producing obscure
> linker errors further down the line.

The problem is that the amount that is free in the ROM is dependent on
the size of the ROM, the size of LinuxBIOS, and any other payloads you
have in your configuration.  Thus checkrom depends on a magic number
to say if it will fail or not.

Choose a platform with a ROM_SIZE smaller than 1 MB and checkrom
doesn't protect you from linker errors.  Choose to use a 2 MB ROM and
checkrom fails even when it shouldn't.

Maybe the warning needs to be more verbose, but I really don't like
the magic number test and fail.

Myles

[LinuxBIOS] Complete and generic 32bit/64bit support

[Ward Vandewege]

On Wed, Nov 21, 2007 at 10:43:09AM -0700, Myles Watson wrote:
> How about this fix?  Can you test the attached patch?  It fixes it in
> uclibc.mk instead of in each individual board.

Very good, that works for me and it's more elegant.
> If the patch works for you, I'll send a full patch from the latest svn.

Excellent.
> The problem is that the amount that is free in the ROM is dependent on
> the size of the ROM, the size of LinuxBIOS, and any other payloads you
> have in your configuration.  Thus checkrom depends on a magic number
> to say if it will fail or not.
>
> Choose a platform with a ROM_SIZE smaller than 1 MB and checkrom
> doesn't protect you from linker errors.  Choose to use a 2 MB ROM and
> checkrom fails even when it shouldn't.

Ok, that makes sense. Is there a way to export ROM_SIZE and access it from
the check_rom script? That way this check would always make sense.

If that's easy it would be great to add it now; otherwise we should probably
leave it for a future patch.

Acked-by: Ward Vandewege

Thanks,
Ward.

[LinuxBIOS] Complete and generic 32bit/64bit support

[Myles Watson]

On 11/21/07, Ward Vandewege  wrote:
> On Wed, Nov 21, 2007 at 10:43:09AM -0700, Myles Watson wrote:
> > How about this fix?  Can you test the attached patch?  It fixes it in
> > uclibc.mk instead of in each individual board.
>
> Very good, that works for me and it's more elegant.
> > If the patch works for you, I'll send a full patch from the latest svn.
>
> Excellent.
> > The problem is that the amount that is free in the ROM is dependent on
> > the size of the ROM, the size of LinuxBIOS, and any other payloads you
> > have in your configuration.  Thus checkrom depends on a magic number
> > to say if it will fail or not.
> >
> > Choose a platform with a ROM_SIZE smaller than 1 MB and checkrom
> > doesn't protect you from linker errors.  Choose to use a 2 MB ROM and
> > checkrom fails even when it shouldn't.
>
> Ok, that makes sense. Is there a way to export ROM_SIZE and access it from
> the check_rom script? That way this check would always make sense.
>
> If that's easy it would be great to add it now; otherwise we should probably
> leave it for a future patch.

Left for the future.
> Acked-by: Ward Vandewege

Here it is again.

It makes the same changes as mentioned before, but it also uses the
correct kernel image depending on the architecture.  mkelfimage
doesn't work with an x86_64 vmlinux, and with an i386 bzImage it
generates a _much_ larger elf.

Signed-off-by: Myles Watson

[LinuxBIOS] Complete and generic 32bit/64bit support

[Ward Vandewege]

Hi Myles,

On Wed, Nov 21, 2007 at 12:13:23PM -0700, Myles Watson wrote:
> It makes the same changes as mentioned before, but it also uses the
> correct kernel image depending on the architecture.  mkelfimage
> doesn't work with an x86_64 vmlinux, and with an i386 bzImage it
> generates a _much_ larger elf.

Ah, is that what's happening? Bug in mkelfimage?

I've built an m57sli-s4 LAB image on 32-bit, and just booted it. Great work.
> Signed-off-by: Myles Watson

Acked-by: Ward Vandewege

Thanks,
Ward.

[LinuxBIOS] Complete and generic 32bit/64bit support

[Myles Watson]

> On Wed, Nov 21, 2007 at 12:13:23PM -0700, Myles Watson wrote:
> > It makes the same changes as mentioned before, but it also uses the
> > correct kernel image depending on the architecture.  mkelfimage
> > doesn't work with an x86_64 vmlinux, and with an i386 bzImage it
> > generates a _much_ larger elf.
>
> Ah, is that what's happening? Bug in mkelfimage?

I guess so.  It took me a long time and a lot of random tries to figure out
that it worked with x86_64 because all the makefiles used vmlinux.

It was last year, so I don't remember why I finally tried using a bzImage,
but at least it works now.
> I've built an m57sli-s4 LAB image on 32-bit, and just booted it. Great
> work.
> > Signed-off-by: Myles Watson
>
> Acked-by: Ward Vandewege

Thanks for testing it.

Myles
> Thanks,
> Ward.

[LinuxBIOS] Complete and generic 32bit/64bit support

[yhlu]

On Nov 21, 2007 12:03 PM, Myles Watson  wrote:
> > On Wed, Nov 21, 2007 at 12:13:23PM -0700, Myles Watson wrote:
> > > It makes the same changes as mentioned before, but it also uses the
> > > correct kernel image depending on the architecture.  mkelfimage
> > > doesn't work with an x86_64 vmlinux, and with an i386 bzImage it
> > > generates a _much_ larger elf.

for x86_64 support
there is a patch i posted several months ago.

because late x86_64 kernel vmlinux is elf64, you need to use melfImage
to convert that to elf32.

YH

[LinuxBIOS] Complete and generic 32bit/64bit support

[Jordan Crouse]

On 21/11/07 13:37 -0800, yhlu wrote:
> On Nov 21, 2007 12:03 PM, Myles Watson  wrote:
> > > On Wed, Nov 21, 2007 at 12:13:23PM -0700, Myles Watson wrote:
> > > > It makes the same changes as mentioned before, but it also uses the
> > > > correct kernel image depending on the architecture.  mkelfimage
> > > > doesn't work with an x86_64 vmlinux, and with an i386 bzImage it
> > > > generates a _much_ larger elf.
>
> for x86_64 support
> there is a patch i posted several months ago.

Excellent!  This should fit into buildrom very nicely.
Thanks.

Jordan
> [PATCH] mkelfImage: Take elf64 vmlinux and produce elf32
>
> change to use e_entry instead of hardcode for vmlinux
> if e_entry is not equal to paddr of fist phdr, will use paddr instead, and not switch to 64bit in convert
> otherwise will use e_entry and switch to 64bit in convert
>
> also fix the bss_size calculation.
>
> Signed-off-By: Yinghai Lu
>
> diff -uNr mkelfImage-2.7/linux-i386/convert.h mkelfImage-2.7.new/linux-i386/convert.h
> --- mkelfImage-2.7/linux-i386/convert.h	2006-03-17 06:08:21.000000000 -0800
> +++ mkelfImage-2.7.new/linux-i386/convert.h	2006-11-08 12:32:15.000000000 -0800
> @@ -3,6 +3,8 @@
>  #define CONVERTLOC 		0x10000
>  #define REAL_MODE_DATA_LOC	0x20000
>  #define GDTLOC	   		0x21000
> +#define GDT64LOC		0x22000
> +#define PGTLOC			0x23000
>
> #define DEFAULT_ROOT_DEV ((0x3<<8)| 0)
>
> @@ -18,10 +20,13 @@
>  struct image_parameters {
>    uint32_t convert_magic; /* a signature to verify mkelfImage was built properly */
>    uint32_t gdt_size;
> uint32_t gdt64_size;
> uint32_t pgt_size;
> uint32_t bss_size;
> uint16_t ramdisk_flags;
> uint16_t root_dev;
> uint32_t entry;
> uint32_t switch_64;
> uint32_t initrd_start;
> uint32_t initrd_size;
> uint8_t  cmdline[CMDLINE_MAX];
>
> diff -uNr mkelfImage-2.7/linux-i386/convert.lds mkelfImage-2.7.new/linux-i386/convert.lds
> --- mkelfImage-2.7/linux-i386/convert.lds	2003-01-16 13:41:14.000000000 -0800
> +++ mkelfImage-2.7.new/linux-i386/convert.lds	2006-11-08 12:19:12.000000000 -0800
> @@ -27,7 +27,7 @@
>    	*(.bss)
>    }
>    _end = . ;
> bss_size = _end - _bss;
>
> bss_sizex = _end - _bss;
>
> /DISCARD/ : {
> *(.comment)
>
> diff -uNr mkelfImage-2.7/linux-i386/head.S mkelfImage-2.7.new/linux-i386/head.S
> --- mkelfImage-2.7/linux-i386/head.S	2003-01-24 14:48:03.000000000 -0800
> +++ mkelfImage-2.7.new/linux-i386/head.S	2006-11-08 12:19:32.000000000 -0800
> @@ -59,7 +59,7 @@
>    movl	$GDTLOC, %edi
>    movl	$(gdt_end - gdt), %ecx
>    rep	movsb
> # Linux makes stupid assumptions about the segments
>  # that are already setup, so setup a new gdt & ldt
>  # and then reload the segment registers.
>
> @@ -95,22 +95,113 @@
>    # Flag to indicate we are the bootstrap processor
>    xorl	%ebx, %ebx
> movl    switch_64, %eax
> cmp	$1, %eax
> jz	switch_to_64
> # Clear the unspecified registers for good measure
>  xorl	%eax, %eax
>  xorl	%ecx, %ecx
>  xorl	%edx, %edx
>  xorl	%edi, %edi
> xorl	%esp, %esp
> xorl	%ebp, %ebp
> # do not clear esp, we still need to use lret later
>    pushl $PROT_CODE_SEG
>    movl entry, %eax
>    pushl %eax
> lret
>
> +switch_to_64:
> /* We need to switch to 64bit before use startup_64 entry go to kernel */
> /*
> Prepare for entering 64 bit mode
> */
>    # Move the gdt64 where Linux will not smash it during decompression
> movl	%esi, %eax # save the real mode pointer
> movl    $gdt64, %esi
> movl    $GDT64LOC, %edi
> movl    $(gdt64_end - gdt64), %ecx
> rep     movsb
> movl	%eax, %esi
> /* Load new GDT with the 64bit segments using 32bit descriptor */
> lgdt	gdt64
> /* Enable PAE mode */
> xorl    %eax, %eax
> btsl    $5, %eax
> movl    %eax, %cr4
> /*
> Build early 4G boot pagetable
> */
>   /* Initialize Page tables to 0*/
>   movl    $PGTLOC, %edi
>   xorl    %eax, %eax
>   movl    $((4096*6)/4), %ecx
>   rep     stosl
>   /* Build Level 4 */
>   movl    $(PGTLOC + 0), %edi
>   leal    0x1007 (%edi), %eax
>   movl    %eax, 0(%edi)
>   /* Build Level 3 */
>   movl    $(PGTLOC + 0x1000), %edi
>   leal    0x1007(%edi), %eax
>   movl    $4, %ecx
>
> +1:     movl    %eax, 0x00(%edi)
>   addl    $0x00001000, %eax
>   addl    $8, %edi
>   decl    %ecx
>   jnz     1b
>   /* Build Level 2 */
>   movl    $(PGTLOC + 0x2000), %edi
>   movl    $0x00000183, %eax
>   movl    $2048, %ecx
>
> +1:     movl    %eax, 0(%edi)
>   addl    $0x00200000, %eax
>   addl    $8, %edi
>   decl    %ecx
>   jnz     1b
>   /* Enable the boot page tables */
>   movl    $PGTLOC, %eax
>   movl    %eax, %cr3
>   /* Enable Long mode in EFER (Extended Feature Enable Register) */
>   movl    $0xc0000080, %ecx
>   rdmsr
>   btsl    $8, %eax
>   wrmsr
> /* Preparing for 64bit jmp */
>    pushl $PROT_CODE_SEG
>    movl entry, %eax
>    pushl %eax
>   /* Enter paged protected Mode, activating Long Mode */
>    xorl    %eax, %eax
>    btsl    $31, %eax
>    btsl    $0, %eax
>    movl    %eax, %cr0
>    /*
>     * At this point we're in long mode but in 32bit compatibility mode
>     * with EFER.LME = 1, CS.L = 0, CS.D = 1 (and in turn
>     * EFER.LMA = 1). Now we want to jump in 64bit mode, to do that we use
>     * the new gdt/idt that has __KERNEL_CS with CS.L = 1.
>     */
>
> # Jump to the linux kernel
> ljmp	$ PROT_CODE_SEG , $ 0x100000
>
> lret
>
> /* Routines to query the BIOS... */
>
> /**************************************************************************
>  E820_MEMSIZE - Get a listing of memory regions
>  **************************************************************************/
> @@ -409,6 +500,7 @@
>    .word	0x9200				# data read/write
>    .word	0x00CF				# granularity = 4096, 386
>    					#  (+5th nibble of limit)
>
> /*
> The layout of the per-CPU GDT under Linux:
>
> @@ -446,7 +538,14 @@
>   */
>  gdt_end:
>
> +gdt64:
> .word	gdt64_end - gdt64
> .long	GDT64LOC
> .word	0
> .quad	0x0000000000000000	/* NULL descriptor */
> .quad	0x00af9a000000ffff	/* __KERNEL_CS */
> .quad	0x00cf92000000ffff	/* __KERNEL_DS */
>
> +gdt64_end:
>
> .section ".trailer", "a"
>    /* Constants set at build time, these are at the very end of my image */
> @@ -458,14 +557,20 @@
>    .long	CONVERT_MAGIC
>  gdt_size:
>    .long	gdt_end - gdt
> +gdt64_size:
> .long	gdt64_end - gdt64
>
> +pgt_size:
> .long   4096*6
>
> bss_size:
> .long	bss_size
> .long	bss_sizex
>
> ramdisk_flags:
>    .word	0
>  root_dev:
>    .word	DEFAULT_ROOT_DEV
>  entry:
>    .long	0
> +switch_64:
> .long	0
>
> initrd_start:
>    .long	0
>  initrd_size:
> diff -uNr mkelfImage-2.7/linux-i386/mkelf-linux-i386.c mkelfImage-2.7.new/linux-i386/mkelf-linux-i386.c
> --- mkelfImage-2.7/linux-i386/mkelf-linux-i386.c	2006-03-17 06:08:22.000000000 -0800
> +++ mkelfImage-2.7.new/linux-i386/mkelf-linux-i386.c	2006-11-08 09:54:58.000000000 -0800
> @@ -19,13 +19,16 @@
>  static void (*parse_kernel_type)(struct kernel_info *info, char *kernel_buf, size_t kernel_size);
>  static void parse_bzImage_kernel(struct kernel_info *info, char *kernel_buf, size_t kernel_size);
>  static void parse_elf32_kernel(struct kernel_info *info, char *kernel_buf, size_t kernel_size);
> +static void parse_elf64_kernel(struct kernel_info *info, char *kernel_buf, size_t kernel_size);
>
> +char *vmlinux_x86_64_probe(char *kernel_buf, off_t kernel_size);
>
> char *vmlinux_i386_probe(char *kernel_buf, off_t kernel_size)
>  {
>    Elf32_Ehdr *ehdr;
>    Elf32_Phdr *phdr;
>    int i;
> int hdr1, hdr2;
> int phdrs;
> ehdr = (Elf32_Ehdr *)kernel_buf;
> if (
> (ehdr->e_ident[EI_MAG0] != ELFMAG0) ||
>
> @@ -35,7 +38,8 @@
>    	return "No ELF signature found on kernel\n";
>    }
>    if (ehdr->e_ident[EI_CLASS] != ELFCLASS32) {
> return "Not a 32bit ELF kernel\n";
> return vmlinux_x86_64_probe(kernel_buf, kernel_size);
>
> +//		return "Not a 32bit ELF kernel\n";
>    }
>    if (ehdr->e_ident[EI_DATA]  != ELFDATA2LSB) {
>    	return "Not a little endian ELF kernel\n";
> @@ -54,27 +58,64 @@
>    	return "Kernel uses bad program header size.\n";
>    }
>    phdr = (Elf32_Phdr *)(kernel_buf + le32_to_cpu(ehdr->e_phoff));
> hdr1 = hdr2 = -1;
> for(i = 0; i < le32_to_cpu(ehdr->e_phnum); i++) {
> phdrs = 0;
> for(i = 0; i < le16_to_cpu(ehdr->e_phnum); i++) {
> if (le32_to_cpu(phdr[i].p_type) != PT_LOAD)
> 	continue;
> if (((hdr1 != -1) && 
> 	((le32_to_cpu(phdr[hdr1].p_paddr) & 0xfffffff) != 0x100000)) ||
> 	(hdr2 != -1)) {
> 	return "Too many PT_LOAD segments to be a linux kernel\n";
> }
> if (hdr1 == -1) {
> 	hdr1 = i;
> } else {
> 	hdr2 = i;
> }
> phdrs++;
> }
> if (hdr1 == -1) {
> if (phdrs == 0) {
> return "No PT_LOAD segments!\n";
> }
> parse_kernel_type = parse_elf32_kernel;
> return 0;
>
> }
> +char *vmlinux_x86_64_probe(char *kernel_buf, off_t kernel_size)
> +{
>    Elf64_Ehdr *ehdr;
>    Elf64_Phdr *phdr;
>    int i;
> int phdrs = 0;
>    ehdr = (Elf64_Ehdr *)kernel_buf;
>    if (
>            (ehdr->e_ident[EI_MAG0] != ELFMAG0) ||
>            (ehdr->e_ident[EI_MAG1] != ELFMAG1) ||
>            (ehdr->e_ident[EI_MAG2] != ELFMAG2) ||
>            (ehdr->e_ident[EI_MAG3] != ELFMAG3)) {
>            return "No ELF signature found on kernel\n";
>    }
>    if (ehdr->e_ident[EI_CLASS] != ELFCLASS64) {
>            return "Not a 64bit ELF kernel\n";
>    }
>    if (ehdr->e_ident[EI_DATA]  != ELFDATA2LSB) {
>            return "Not a little endian ELF kernel\n";
>    }
>    if (le16_to_cpu(ehdr->e_type) != ET_EXEC) {
>            return "Not an executable kernel\n";
>    }
>    if (le16_to_cpu(ehdr->e_machine) != EM_X86_64) {
>            return "Not an x86_64 kernel\n";
>    }
>    if (    (ehdr->e_ident[EI_VERSION] != EV_CURRENT) ||
>            (le32_to_cpu(ehdr->e_version) != EV_CURRENT)) {
>            return "Kernel not using ELF version 1.\n";
>    }
>    if (le16_to_cpu(ehdr->e_phentsize) != sizeof(*phdr)) {
>            return "Kernel uses bad program header size.\n";
>    }
>    phdr = (Elf64_Phdr *)(kernel_buf + le64_to_cpu(ehdr->e_phoff));
> phdrs = 0;
>    for(i = 0; i < le16_to_cpu(ehdr->e_phnum); i++) {
>            if (le32_to_cpu(phdr[i].p_type) != PT_LOAD)
>                    continue;
> phdrs++;
>    }
>    if (phdrs == 0) {
>            return "No PT_LOAD segments!\n";
>    }
>    parse_kernel_type = parse_elf64_kernel;
>    return 0;
>
> +}
>
> char *bzImage_i386_probe(char *kernel_buf, off_t kernel_size)
>  {
> @@ -118,17 +159,14 @@
>
> struct kernel_info
>  {
> void *kernel;
> size_t filesz;
> size_t memsz;
> size_t paddr;
> size_t vaddr;
> void *kernel2;
> size_t filesz2;
> size_t memsz2;
> size_t paddr2;
> size_t vaddr2;
> int phdrs;
> void *kernel[4];
> size_t filesz[4];
> size_t memsz[4];
> size_t paddr[4];
> size_t vaddr[4];
> size_t entry;
> size_t switch_64;
> char *version;
>
> };
>
> @@ -137,43 +175,68 @@
>    Elf32_Ehdr *ehdr;
>    Elf32_Phdr *phdr;
>    int i;
> int hdr1, hdr2;
> int phdrs;
> ehdr = (Elf32_Ehdr *)kernel_buf;
> phdr = (Elf32_Phdr *)(kernel_buf + ehdr->e_phoff);
> hdr1 = hdr2 = -1;
> phdrs = 0;
> for(i = 0; i < le16_to_cpu(ehdr->e_phnum); i++) {
> if (le32_to_cpu(phdr[i].p_type) != PT_LOAD)
> 	continue;
> if (hdr2 != -1) {
> 	die("Too many PT_LOAD segments to be a linux kernel\n");
> }
> if (hdr1 == -1) {
> 	hdr1 = i;
> } else {
> 	hdr2 = i;
> }
> }
> if (hdr1 == -1) {
> die("No PT_LOAD segments!\n");
> info->kernel[phdrs]  = kernel_buf + le32_to_cpu(phdr[i].p_offset);
> info->filesz[phdrs]  = le32_to_cpu(phdr[i].p_filesz);
> info->memsz[phdrs]   = le32_to_cpu(phdr[i].p_memsz);
> info->paddr[phdrs]   = le32_to_cpu(phdr[i].p_paddr) & 0xfffffff;
> info->vaddr[phdrs]   = le32_to_cpu(phdr[i].p_vaddr);
> phdrs++;
> }
> info->kernel  = kernel_buf + le32_to_cpu(phdr[hdr1].p_offset);
> info->filesz  = le32_to_cpu(phdr[hdr1].p_filesz);
> info->memsz   = le32_to_cpu(phdr[hdr1].p_memsz);
> info->paddr   = le32_to_cpu(phdr[hdr1].p_paddr) & 0xfffffff;
> info->vaddr   = le32_to_cpu(phdr[hdr1].p_vaddr);
> if (hdr2 != -1) {
> info->kernel2 = kernel_buf + le32_to_cpu(phdr[hdr2].p_offset);
> info->filesz2 = le32_to_cpu(phdr[hdr2].p_filesz);
> info->memsz2  = le32_to_cpu(phdr[hdr2].p_memsz);
> info->paddr2  = le32_to_cpu(phdr[hdr2].p_paddr) & 0xfffffff;
> info->vaddr2  = le32_to_cpu(phdr[hdr2].p_vaddr);
> if(!phdrs)
> die("We need at least one phdr\n");
> info->phdrs = phdrs;
>    info->entry   = le32_to_cpu(ehdr->e_entry);
> info->switch_64   = 0; //not convert from elf64
> info->version = "unknown";
>
> +}
>
> +static void parse_elf64_kernel(struct kernel_info *info, char *kernel_buf, size_t kernel_size)
> +{
>    Elf64_Ehdr *ehdr;
>    Elf64_Phdr *phdr;
>    int i;
> int phdrs;
>    ehdr = (Elf64_Ehdr *)kernel_buf;
>    phdr = (Elf64_Phdr *)(kernel_buf + le64_to_cpu(ehdr->e_phoff));
> phdrs = 0;
> for(i = 0; i < le16_to_cpu(ehdr->e_phnum); i++) {
> if (le32_to_cpu(phdr[i].p_type) != PT_LOAD)
> 	continue;
> info->kernel[phdrs]  = kernel_buf + le64_to_cpu(phdr[i].p_offset);
> info->filesz[phdrs]  = le64_to_cpu(phdr[i].p_filesz);
> info->memsz[phdrs]   = le64_to_cpu(phdr[i].p_memsz);
> info->paddr[phdrs]   = le64_to_cpu(phdr[i].p_paddr) & 0xffffff;
> info->vaddr[phdrs]   = le64_to_cpu(phdr[i].p_vaddr);
> phdrs++;
> }
> if(!phdrs)
> die("We need at least one phdr\n");
>
> info->entry   = 0x100000;
> info->version = "unknown";
> info->phdrs = phdrs;
>    info->entry   = le64_to_cpu(ehdr->e_entry);
>
> +#if  0
> if (info->entry != info->paddr[0]) {
> info->entry = info->paddr[0]; // we still have startup_32 there
> info->switch_64   = 0; //not convert from elf64
> } else
>
> +#endif
> info->switch_64   = 1; //convert from elf64
>    info->version = "unknown";
>
> }
>
> static void parse_bzImage_kernel(struct kernel_info *info, char *kernel_buf, size_t kernel_size)
>  {
>    struct x86_linux_header *hdr;
> @@ -186,12 +249,14 @@
>    }
>    offset = 512 + (512 *setup_sects);
> info->kernel  = kernel_buf + offset;
> info->filesz  = kernel_size - offset;
> info->memsz   = 0x700000;
> info->paddr   = 0x100000;
> info->vaddr   = 0x100000;
> info->entry   = info->paddr;
> info->kernel[0]  = kernel_buf + offset;
> info->filesz[0]  = kernel_size - offset;
> info->memsz[0]   = 0x700000;
> info->paddr[0]   = 0x100000;
> info->vaddr[0]   = 0x100000;
> info->phdrs = 1;
> info->entry   = info->paddr[0];
> info->switch_64   = 0; //not convert from elf64, even later bzImage become elf64, it still includes startup_32
> info->version = kernel_buf + 512 + le16_to_cpu(hdr->kver_addr);
>
> }
>
> @@ -237,6 +302,7 @@
>    struct kernel_info kinfo;
>    struct image_parameters *params;
>    int index;
>
> int i;
>
> int opt;
> static const struct option options[] = {
>
> @@ -310,7 +376,7 @@
>
> /* Add a program header for the note section */
>    index = 4;
> index += kinfo.kernel2 ? 1:0;
> index += (kinfo.phdrs - 1);
> index += ramdisk_size ? 1:0;
> phdr = add_program_headers(ehdr, index);
>
> @@ -328,23 +394,24 @@
>    phdr[2].p_paddr  = REAL_MODE_DATA_LOC;
>    phdr[2].p_vaddr  = REAL_MODE_DATA_LOC;
>    phdr[2].p_filesz = 0;
> phdr[2].p_memsz  = (GDTLOC - REAL_MODE_DATA_LOC) + params->gdt_size;
> if(!kinfo.switch_64)
> phdr[2].p_memsz = (GDTLOC - REAL_MODE_DATA_LOC) + params->gdt_size;
> else
> phdr[2].p_memsz = (PGTLOC - REAL_MODE_DATA_LOC) + params->pgt_size;
> phdr[2].p_data   = 0;
> phdr[3].p_paddr  = kinfo.paddr;
> phdr[3].p_vaddr  = kinfo.vaddr;
> phdr[3].p_filesz = kinfo.filesz;
> phdr[3].p_memsz  = kinfo.memsz;
> phdr[3].p_data   = kinfo.kernel;
> if( (phdr[1].p_paddr + phdr[1].p_memsz) > phdr[2].p_paddr) {
> die("Internal error: need to increase REAL_MODE_DATA_LOC !\n");
> }
> index = 4;
> index = 3;
> /* Put the second kernel frament if present */
> if (kinfo.kernel2) {
> phdr[index].p_paddr  = kinfo.paddr2;
> phdr[index].p_vaddr  = kinfo.vaddr2;
> phdr[index].p_filesz = kinfo.filesz2;
> phdr[index].p_memsz  = kinfo.memsz2;
> phdr[index].p_data   = kinfo.kernel2;
> for(i=0;i<kinfo.phdrs;i++) {
> phdr[index].p_paddr  = kinfo.paddr[i];
> phdr[index].p_vaddr  = kinfo.vaddr[i];
> phdr[index].p_filesz = kinfo.filesz[i];
> phdr[index].p_memsz  = kinfo.memsz[i];
> phdr[index].p_data   = kinfo.kernel[i];
> index++;
> }
>
> @@ -352,6 +419,10 @@
>     */
>    params->initrd_start = params->initrd_size = 0;
>    if (ramdisk_size) {
> if( (phdr[index-1].p_paddr + phdr[index-1].p_memsz) > ramdisk_base) {
> 	die("need to increase increase ramdisk_base !\n");
> }
> phdr[index].p_paddr  = ramdisk_base;
>   phdr[index].p_vaddr  = ramdisk_base;
>   phdr[index].p_filesz = ramdisk_size;
>
> @@ -364,6 +435,7 @@
>
> /* Set the start location */
>    params->entry = kinfo.entry;
>
> params->switch_64 = kinfo.switch_64;
> ehdr->e_entry = phdr[1].p_paddr;
>
> /* Setup the elf notes */
>
> diff -uNr mkelfImage-2.7/linux-ia64/mkelf-linux-ia64.c mkelfImage-2.7.new/linux-ia64/mkelf-linux-ia64.c
> --- mkelfImage-2.7/linux-ia64/mkelf-linux-ia64.c	2006-03-17 10:09:16.000000000 -0800
> +++ mkelfImage-2.7.new/linux-ia64/mkelf-linux-ia64.c	2006-11-07 18:14:27.000000000 -0800
> @@ -81,7 +81,7 @@
>    phdr = (Elf64_Phdr *)(kernel_buf + le64_to_cpu(ehdr->e_phoff));
>    phdrs = 0;
>    for(i = 0; i < le16_to_cpu(ehdr->e_phnum); i++) {
> if (le16_to_cpu(phdr[i].p_type) != PT_LOAD)
> if (le32_to_cpu(phdr[i].p_type) != PT_LOAD)
> continue;
> phdrs++;
> }
>

[LinuxBIOS] Complete and generic 32bit/64bit support

[Myles Watson]

On 11/21/07, yhlu  wrote:
> On Nov 21, 2007 12:03 PM, Myles Watson  wrote:
> > > On Wed, Nov 21, 2007 at 12:13:23PM -0700, Myles Watson wrote:
> > > > It makes the same changes as mentioned before, but it also uses the
> > > > correct kernel image depending on the architecture.  mkelfimage
> > > > doesn't work with an x86_64 vmlinux, and with an i386 bzImage it
> > > > generates a _much_ larger elf.
>
> for x86_64 support
> there is a patch i posted several months ago.
>
> because late x86_64 kernel vmlinux is elf64, you need to use melfImage
> to convert that to elf32.
>
> YH

I tested it using the amd serengeti_cheetah LAB (64-bit) platform in buildrom

With mkelfimage 2.5 using bzImage (vmlinux doesn't work)
Payload takes 901210 Bytes (880 KBytes) in ROM:

With mkelfimage 2.7 and Yinghai's patch using bzImage
Payload takes 900919 Bytes (879 KBytes) in ROM:

With mkelfimage 2.7 and Yinghai's patch using vmlinux
Payload takes 770726 Bytes (752 KBytes) in ROM:

So 2.7 is marginally better anyway, and blows 2.5 away by using vmlinux.

I tested it and it boots.  I think we should upgrade to 2.7 and use the patch.

My patch makes it so all targets use vmlinux and 2.7
Signed-off-by: Myles Watson

[LinuxBIOS] Complete and generic 32bit/64bit support

[yhlu]

On Nov 21, 2007 3:29 PM, Myles Watson  wrote:
> On 11/21/07, yhlu  wrote:
> > On Nov 21, 2007 12:03 PM, Myles Watson  wrote:
> > > > On Wed, Nov 21, 2007 at 12:13:23PM -0700, Myles Watson wrote:
> > > > > It makes the same changes as mentioned before, but it also uses the
> > > > > correct kernel image depending on the architecture.  mkelfimage
> > > > > doesn't work with an x86_64 vmlinux, and with an i386 bzImage it
> > > > > generates a _much_ larger elf.
> >
> > for x86_64 support
> > there is a patch i posted several months ago.
> >
> > because late x86_64 kernel vmlinux is elf64, you need to use melfImage
> > to convert that to elf32.
> >
> > YH
>
> I tested it using the amd serengeti_cheetah LAB (64-bit) platform in buildrom
>
> With mkelfimage 2.5 using bzImage (vmlinux doesn't work)
> Payload takes 901210 Bytes (880 KBytes) in ROM:
>
> With mkelfimage 2.7 and Yinghai's patch using bzImage
> Payload takes 900919 Bytes (879 KBytes) in ROM:
>
> With mkelfimage 2.7 and Yinghai's patch using vmlinux
> Payload takes 770726 Bytes (752 KBytes) in ROM:
>
> So 2.7 is marginally better anyway, and blows 2.5 away by using vmlinux.
>
> I tested it and it boots.  I think we should upgrade to 2.7 and use the patch.

this afternoon, played a while linuxbios + tiny kernel on l1_2pvv.
find something interesting.

vmlinux 2.6.18.1 in buildrom
A. built from on my laptop with opensuse 10.3 64bit
B. built from my workstation with Suse 10.0 pro 64bit

A is much bigger than B, Also A doesn't work mkelfImage + LinuxBIOS,
but B work with mkelfImage + LinuxBIOS

then I tried 2.6.24-rc3 from git, it works with A and B.

maybe some gcc default setting difference about stack checking cause that.

BTW, what is the kernel version in LAB now?

YH

[LinuxBIOS] Complete and generic 32bit/64bit support

[Ward Vandewege]

On Wed, Nov 21, 2007 at 07:51:34PM -0800, yhlu wrote:
> this afternoon, played a while linuxbios + tiny kernel on l1_2pvv.
> find something interesting.
>
> vmlinux 2.6.18.1 in buildrom
> A. built from on my laptop with opensuse 10.3 64bit
> B. built from my workstation with Suse 10.0 pro 64bit
>
> A is much bigger than B, Also A doesn't work mkelfImage + LinuxBIOS,
> but B work with mkelfImage + LinuxBIOS
>
> then I tried 2.6.24-rc3 from git, it works with A and B.
>
> maybe some gcc default setting difference about stack checking cause that.
>
> BTW, what is the kernel version in LAB now?

The non-geode boards seem to be at 2.6.22.2 (plus corresponding tiny
patches); the geode boards have KERNEL_VERSION set to 2.6.20.2 but I don't
know how recently LAB has been tested on those.

Looks like the last Linux-Tiny patch set is for 2.6.23.

Thanks,
Ward.

[LinuxBIOS] Complete and generic 32bit/64bit support

[Ward Vandewege]

On Wed, Nov 21, 2007 at 04:29:43PM -0700, Myles Watson wrote:
> I tested it using the amd serengeti_cheetah LAB (64-bit) platform in buildrom
>
> With mkelfimage 2.5 using bzImage (vmlinux doesn't work)
> Payload takes 901210 Bytes (880 KBytes) in ROM:
>
> With mkelfimage 2.7 and Yinghai's patch using bzImage
> Payload takes 900919 Bytes (879 KBytes) in ROM:
>
> With mkelfimage 2.7 and Yinghai's patch using vmlinux
> Payload takes 770726 Bytes (752 KBytes) in ROM:

Wow! That's a very large difference.

Your patch seems ok, except it does not pass -fno-stack-protector through to
mkelfimage anymore, which breaks the build on modern Debian based systems.

Can you fix that?

Thanks,
Ward.

[LinuxBIOS] Complete and generic 32bit/64bit support

[Myles Watson]

> Your patch seems ok, except it does not pass -fno-stack-protector through
> to
> mkelfimage anymore, which breaks the build on modern Debian based systems.
>
> Can you fix that?

Can you help me know how I broke it?  I don't see anywhere that I modified
the flags passed to the compiler in mkelfimage.mk.  I also looked at the
other changes in the patch, but didn't see anything obvious.  I don't have
Debian, so it's less obvious for me.

Thanks,
Myles

[LinuxBIOS] Complete and generic 32bit/64bit support

[Ward Vandewege]

Hi Myles,

On Mon, Nov 26, 2007 at 07:55:48AM -0700, Myles Watson wrote:
> > Your patch seems ok, except it does not pass -fno-stack-protector through
> > to
> > mkelfimage anymore, which breaks the build on modern Debian based systems.
> >
> > Can you fix that?
>
> Can you help me know how I broke it?  I don't see anywhere that I modified
> the flags passed to the compiler in mkelfimage.mk.  I also looked at the
> other changes in the patch, but didn't see anything obvious.  I don't have
> Debian, so it's less obvious for me.

It's unclear to me as well. Basically buildrom is not perfect yet wrt adding
-fno-stack-protector.

I suggest we merge your patch now, and fix that later. Other parts of the LAB
payload also don't get -fno-stack-protector as they should.

Thanks,
Ward.

[LinuxBIOS] Complete and generic 32bit/64bit support

[Myles Watson]

> -----Original Message-----
> From: Ward Vandewege [mailto:[e-mail]]
> Sent: Tuesday, November 27, 2007 2:05 PM
> To: Myles Watson
> Cc: 'Jordan Crouse'; 'Linuxbios'
> Subject: Re: [LinuxBIOS] Complete and generic 32bit/64bit support
>
> Hi Myles,
>
> On Mon, Nov 26, 2007 at 07:55:48AM -0700, Myles Watson wrote:
> > > Your patch seems ok, except it does not pass -fno-stack-protector
>
> through
> > > to
> > > mkelfimage anymore, which breaks the build on modern Debian based
>
> systems.
> > > Can you fix that?
> >
> > Can you help me know how I broke it?  I don't see anywhere that I
>
> modified
> > the flags passed to the compiler in mkelfimage.mk.  I also looked at the
> > other changes in the patch, but didn't see anything obvious.  I don't
>
> have
> > Debian, so it's less obvious for me.
>
> It's unclear to me as well. Basically buildrom is not perfect yet wrt
> adding
> -fno-stack-protector.
>
> I suggest we merge your patch now, and fix that later. Other parts of the
> LAB
> payload also don't get -fno-stack-protector as they should.

Sounds good.
Myles
> Thanks,
> Ward.

[LinuxBIOS] Complete and generic 32bit/64bit support

[Jordan Crouse]

On 27/11/07 16:32 -0700, Myles Watson wrote:
> > -----Original Message-----
> > From: Ward Vandewege [mailto:[e-mail]]
> > Sent: Tuesday, November 27, 2007 2:05 PM
> > To: Myles Watson
> > Cc: 'Jordan Crouse'; 'Linuxbios'
> > Subject: Re: [LinuxBIOS] Complete and generic 32bit/64bit support
> >
> > Hi Myles,
> >
> > On Mon, Nov 26, 2007 at 07:55:48AM -0700, Myles Watson wrote:
> > > > Your patch seems ok, except it does not pass -fno-stack-protector
> >
> > through
> > > > to
> > > > mkelfimage anymore, which breaks the build on modern Debian based
> >
> > systems.
> > > > Can you fix that?
> > >
> > > Can you help me know how I broke it?  I don't see anywhere that I
> >
> > modified
> > > the flags passed to the compiler in mkelfimage.mk.  I also looked at the
> > > other changes in the patch, but didn't see anything obvious.  I don't
> >
> > have
> > > Debian, so it's less obvious for me.
> >
> > It's unclear to me as well. Basically buildrom is not perfect yet wrt
> > adding
> > -fno-stack-protector.
> >
> > I suggest we merge your patch now, and fix that later. Other parts of the
> > LAB
> > payload also don't get -fno-stack-protector as they should.
>
> Sounds good.
> Myles

WOrking on it right now.
> > Thanks,
> > Ward.

[LinuxBIOS] Complete and generic 32bit/64bit support

[Jordan Crouse]

On 21/11/07 16:29 -0700, Myles Watson wrote:
> My patch makes it so all targets use vmlinux and 2.7
> Signed-off-by: Myles Watson

Committed, thanks.

[LinuxBIOS] Complete and generic 32bit/64bit support

[Jordan Crouse]

On 21/11/07 14:51 -0500, Ward Vandewege wrote:
> On Wed, Nov 21, 2007 at 12:13:23PM -0700, Myles Watson wrote:
> > It makes the same changes as mentioned before, but it also uses the
> > correct kernel image depending on the architecture.  mkelfimage
> > doesn't work with an x86_64 vmlinux, and with an i386 bzImage it
> > generates a _much_ larger elf.
>
> Ah, is that what's happening? Bug in mkelfimage?
>
> I've built an m57sli-s4 LAB image on 32-bit, and just booted it. Great work.
> > Signed-off-by: Myles Watson
>
> Acked-by: Ward Vandewege

r58 - thanks a lot to everybody!  Happy thanksgiving if that happens to
be a holiday in your part of the world.

Jordan

[LinuxBIOS] Complete and generic 32bit/64bit support

[Myles Watson]

I forgot to add these 3 files to the diff.  Sorry.
I also don't know how to remove s-c-payload.patch from
packages/linuxbios/patches and have it show up in the patch.

Thanks,
Myles

In case we need a separate signed off
Signed-off-by: Myles Watson

On 11/21/07, Jordan Crouse  wrote:
> On 21/11/07 14:51 -0500, Ward Vandewege wrote:
> > On Wed, Nov 21, 2007 at 12:13:23PM -0700, Myles Watson wrote:
> > > It makes the same changes as mentioned before, but it also uses the
> > > correct kernel image depending on the architecture.  mkelfimage
> > > doesn't work with an x86_64 vmlinux, and with an i386 bzImage it
> > > generates a _much_ larger elf.
> >
> > Ah, is that what's happening? Bug in mkelfimage?
> >
> > I've built an m57sli-s4 LAB image on 32-bit, and just booted it. Great work.
> > > Signed-off-by: Myles Watson
> >
> > Acked-by: Ward Vandewege
>
> r58 - thanks a lot to everybody!  Happy thanksgiving if that happens to
> be a holiday in your part of the world.
>
> Jordan

[LinuxBIOS] Complete and generic 32bit/64bit support

[Jordan Crouse]

On 21/11/07 16:41 -0700, Myles Watson wrote:
> I forgot to add these 3 files to the diff.  Sorry.
> I also don't know how to remove s-c-payload.patch from
> packages/linuxbios/patches and have it show up in the patch.

I don't get this patch - do we still need
packages/kernel/serengeti_cheetah-kernel-x86_64.mk?  kernel.inc does all
the heavy lifting now.  Or not?

Jordan
> Thanks,
> Myles
>
> In case we need a separate signed off
> Signed-off-by: Myles Watson
>
> On 11/21/07, Jordan Crouse  wrote:
> > On 21/11/07 14:51 -0500, Ward Vandewege wrote:
> > > On Wed, Nov 21, 2007 at 12:13:23PM -0700, Myles Watson wrote:
> > > > It makes the same changes as mentioned before, but it also uses the
> > > > correct kernel image depending on the architecture.  mkelfimage
> > > > doesn't work with an x86_64 vmlinux, and with an i386 bzImage it
> > > > generates a _much_ larger elf.
> > >
> > > Ah, is that what's happening? Bug in mkelfimage?
> > >
> > > I've built an m57sli-s4 LAB image on 32-bit, and just booted it. Great work.
> > > > Signed-off-by: Myles Watson
> > >
> > > Acked-by: Ward Vandewege
> >
> > r58 - thanks a lot to everybody!  Happy thanksgiving if that happens to
> > be a holiday in your part of the world.
> >
> > Jordan

[LinuxBIOS] Complete and generic 32bit/64bit support

[Myles Watson]

> -----Original Message-----
> From: Jordan Crouse [mailto:[e-mail]]
> On 21/11/07 16:41 -0700, Myles Watson wrote:
> > I forgot to add these 3 files to the diff.  Sorry.
> > I also don't know how to remove s-c-payload.patch from
> > packages/linuxbios/patches and have it show up in the patch.
>
> I don't get this patch - do we still need
> packages/kernel/serengeti_cheetah-kernel-x86_64.mk?  kernel.inc does all
> the heavy lifting now.  Or not?

My understanding is that packages/kernel/serengeti_cheetah-kernel-x86_64.mk
sets the kernel version, url, config file, etc.  kernel.inc builds the
kernel you specified in the .mk file.

The other two files are Config.lb files depending on which payload you want
to use.

Myles
> Jordan

[LinuxBIOS] Complete and generic 32bit/64bit support

[Jordan Crouse]

On 26/11/07 16:36 -0700, Myles Watson wrote:
> > -----Original Message-----
> > From: Jordan Crouse [mailto:[e-mail]]
> > On 21/11/07 16:41 -0700, Myles Watson wrote:
> > > I forgot to add these 3 files to the diff.  Sorry.
> > > I also don't know how to remove s-c-payload.patch from
> > > packages/linuxbios/patches and have it show up in the patch.
> >
> > I don't get this patch - do we still need
> > packages/kernel/serengeti_cheetah-kernel-x86_64.mk?  kernel.inc does all
> > the heavy lifting now.  Or not?
>
> My understanding is that packages/kernel/serengeti_cheetah-kernel-x86_64.mk
> sets the kernel version, url, config file, etc.  kernel.inc builds the
> kernel you specified in the .mk file.

is there enough different about it that we need two files?  I was planning
on setting the configuration information in the platform configuration:

ifeq ($(CONFIG_TARGET_64BIT),y)
KERNEL_VERSION=2.6.22.2
KERNEL_MK=$(PACKAGE_DIR)/kernel/serengeti_cheetah-kernel-x86_64.mk
KERNEL_CONFIG=$(PACKAGE_DIR)/kernel/conf/defconfig-serengeti_cheetah-x86_64
BUSYBOX_CONFIG=defconfig-serengeti_cheetah-x86_64
UCLIBC_VER=0.9.29
UCLIBC_CONFIG=defconfig-x86_64
else
KERNEL_VERSION=2.6.20.2
KERNEL_CONFIG=$(PACKAGE_DIR)/kernel/conf/defconfig-serengeti_cheetah
UCLIBC_VER=0.9.28
endif

That would save us having to have mutiple copies of the kernel make files
for 32 and 64 bit.  Is this bad?

Jordan
> The other two files are Config.lb files depending on which payload you want
> to use.

Yes - those made sense to me.
> Myles
> > Jordan

[LinuxBIOS] Complete and generic 32bit/64bit support

[Myles Watson]

> -----Original Message-----
> From: Jordan Crouse [mailto:[e-mail]]
> Sent: Monday, November 26, 2007 4:54 PM
> To: Myles Watson
> Cc: 'Linuxbios'
> Subject: Re: Complete and generic 32bit/64bit support
>
> On 26/11/07 16:36 -0700, Myles Watson wrote:
> > > -----Original Message-----
> > > From: Jordan Crouse [mailto:[e-mail]]
> > > On 21/11/07 16:41 -0700, Myles Watson wrote:
> > > > I forgot to add these 3 files to the diff.  Sorry.
> > > > I also don't know how to remove s-c-payload.patch from
> > > > packages/linuxbios/patches and have it show up in the patch.
> > >
> > > I don't get this patch - do we still need
> > > packages/kernel/serengeti_cheetah-kernel-x86_64.mk?  kernel.inc does
>
> all
> > > the heavy lifting now.  Or not?
> >
> > My understanding is that packages/kernel/serengeti_cheetah-kernel-
>
> x86_64.mk
> > sets the kernel version, url, config file, etc.  kernel.inc builds the
> > kernel you specified in the .mk file.
>
> is there enough different about it that we need two files?  I was planning
> on setting the configuration information in the platform configuration:
>
> ifeq ($(CONFIG_TARGET_64BIT),y)
> KERNEL_VERSION=2.6.22.2
> KERNEL_MK=$(PACKAGE_DIR)/kernel/serengeti_cheetah-kernel-x86_64.mk
> KERNEL_CONFIG=$(PACKAGE_DIR)/kernel/conf/defconfig-serengeti_cheetah-
> x86_64
> BUSYBOX_CONFIG=defconfig-serengeti_cheetah-x86_64
> UCLIBC_VER=0.9.29
> UCLIBC_CONFIG=defconfig-x86_64
> else
> KERNEL_VERSION=2.6.20.2
> KERNEL_CONFIG=$(PACKAGE_DIR)/kernel/conf/defconfig-serengeti_cheetah
> UCLIBC_VER=0.9.28
> endif

That's fine with me.  The other difference is the tiny patches.

It won't build for 64-bit Serengeti cheetah until we figure it out.

Myles
> That would save us having to have mutiple copies of the kernel make files
> for 32 and 64 bit.  Is this bad?
>
> Jordan
> > The other two files are Config.lb files depending on which payload you
>
> want
> > to use.
>
> Yes - those made sense to me.
> > Myles
> > > Jordan

[LinuxBIOS] Complete and generic 32bit/64bit support

[Myles Watson]

> > > I don't get this patch - do we still need
> > > packages/kernel/serengeti_cheetah-kernel-x86_64.mk?  kernel.inc does
>
> all
> > > the heavy lifting now.  Or not?
> >
> > My understanding is that packages/kernel/serengeti_cheetah-kernel-
>
> x86_64.mk
> > sets the kernel version, url, config file, etc.  kernel.inc builds the
> > kernel you specified in the .mk file.
>
> is there enough different about it that we need two files?  I was planning
> on setting the configuration information in the platform configuration:
>
> ifeq ($(CONFIG_TARGET_64BIT),y)
> KERNEL_VERSION=2.6.22.2
> KERNEL_MK=$(PACKAGE_DIR)/kernel/serengeti_cheetah-kernel-x86_64.mk

So do you want to remove this line if you only want one .mk file?  Do we
want to make a new variable CONFIG_TINY that downloads the tiny patches for
the KERNEL_VERSION we've selected?  Once we go that far is there any reason
to have board-specific .mk files for the kernel at all?  That would be nice
from my perspective (many of the boards can/do use the same kernel
versions), but it is a major change.

Myles
> KERNEL_CONFIG=$(PACKAGE_DIR)/kernel/conf/defconfig-serengeti_cheetah-
> x86_64
> BUSYBOX_CONFIG=defconfig-serengeti_cheetah-x86_64
> UCLIBC_VER=0.9.29
> UCLIBC_CONFIG=defconfig-x86_64
> else
> KERNEL_VERSION=2.6.20.2
> KERNEL_CONFIG=$(PACKAGE_DIR)/kernel/conf/defconfig-serengeti_cheetah
> UCLIBC_VER=0.9.28
> endif
>
> That would save us having to have mutiple copies of the kernel make files
> for 32 and 64 bit.  Is this bad?
>
> Jordan
> > The other two files are Config.lb files depending on which payload you
>
> want
> > to use.
>
> Yes - those made sense to me.
> > Myles
> > > Jordan

[LinuxBIOS] Complete and generic 32bit/64bit support

[Jordan Crouse]

On 21/11/07 16:41 -0700, Myles Watson wrote:
> I forgot to add these 3 files to the diff.  Sorry.
> I also don't know how to remove s-c-payload.patch from
> packages/linuxbios/patches and have it show up in the patch.

Comitted, thanks.

Jordan