x86 embedded - Problem getting past 'move compressed kernel before decompression'

x86 embedded - Problem getting past 'move compressed kernel before decompression'

[Graeme Russ]

Hello,

I am trying to port Linux to an AMD SC520 based custom (not PC based)
hardware. I have spent a lot of time recently getting the x86 port of
U-Boot to the point where I can load a bzImage into memory and jump into
the startup_32 entry point in linux-2.6/arch/x86/boot/compressed/head_32.S

The hardware is in no way based on any kind of PC architecture, it does not
have a BIOS. U-Boot transitions straight into Protected Mode (refer to
U-Boot\cpu\i386\resetvec.S U-Boot\cpu\i386\start16.S and  performs all the
hardware initialisation in Protected Mode. So I want to use the "32-bit
BOOT PROTOCOL" as described in linux-2.6/Documentation/x86/boot.txt

Now the GDT in U-Boot is defined as follows:

    0x0000, 0x0000, 0x0000, 0x0000	/* 0x00 NULL */
    0x0000, 0x0000, 0x0000, 0x0000	/* 0x08 Unused */
    0xFFFF, 0x0000, 0x9B00, 0x00CF	/* 0x10 32-bit Code */
    0xFFFF, 0x0000, 0x9300, 0x00CF	/* 0x18 32-bit Data */
    0xFFFF, 0x0000, 0x9B00, 0x0010	/* 0x20 16-bit Code */
    0xFFFF, 0x0000, 0x9300, 0x0010	/* 0x28 16-bit Data */

The first 4 entries (in particular 0x10 and 0x18) are identical to how
setup_gdt() in linux-2.6/arch/x86/boot/pm.c appears to set up the GDT and
is as described in the "32-bit BOOT PROTOCOL"

I now also have U-Boot successfully copying the Real Mode (16-bit) part of
bzImage to 0x90000 and the Protected Mode (32-bit) part to 0x100000 (1M)
(copying the Real Mode part is a bit of a legacy and it gives convenient
access to the setup header)

The following is something I have hacked together to jump into the 32-bit
start address of the Linux Kernel:

struct boot_params boot_params __attribute__((aligned(16)));
struct setup_header *hdr = (struct setup_header *)(0x90000 + 0x1f1);

void boot_zimage(void *setup_base)
{
	memset(&boot_params, 0x00, sizeof boot_params);
	memcpy(&boot_params.hdr, hdr, sizeof (*hdr));

	boot_params.alt_mem_k = 128 * 1024;
	boot_params.e820_entries = 1;
	boot_params.e820_map[0].addr = 0x00000000;
	boot_params.e820_map[0].size = 128 * 1024;
	boot_params.e820_map[0].type = 1;

	asm(	"movw	$0x18, %%cx\n" \
		"movl	%%ecx, %%ds\n" \
		"movl	%%ecx, %%es\n" \
		"movl	%%ecx, %%fs\n" \
		"movl	%%ecx, %%gs\n" \
		"movl	%%ecx, %%ss\n" \
		"xorl	%%ebp, %%ebp\n" \
		"xorl	%%edi, %%edi\n" \
		"xorl	%%ebx, %%ebx\n" \
		"movl	%0, %%esi\n"
		"movl   $0x100000, %%eax\n" \
		"jmpl	*%%eax" : : "r"(&boot_params));
}

I have added several instances of the following to test the progress of the
boot-up in linux-2.6/arch/x86/boot/compressed/head_32.S:

	pushl	%eax
	pushl	%edx
	movb	$'!', %al
	movw	$0x3f8, %dx
	outb	%al, %dx
	popl	%edx
	popl	%eax

At first, I noticed that the copy code at lines 96 to 104 was not copying
the compressed kernel as expected. I have since found that the default
build address is now actually 0x1000000 (16M) and not 0x100000 (1M). I
found the only way to change this was to use 'menuconfig' to turn on the
EMBEDDED option which then exposed the CONFIG_PHYSICAL_START option. I
adjusted this to 0x100000 (1M) and now the copy works as expected, but code
execution never reaches the reloacted: label at line 104

I am now a little stuck as to how to further diagnose the problem. If
anyone could provide some ideas, I would be really thankful

TIA

Regards,

Graeme

PS: Can you please Cc me (graeme.russ@gmail.com) as I have not subscribed
to this list (yet)

Re: x86 embedded - Problem getting past 'move compressed kernel before decompression'

[H. Peter Anvin]

On 02/20/2010 06:03 PM, Graeme Russ wrote:
> 
> The following is something I have hacked together to jump into the 32-bit
> start address of the Linux Kernel:
> 
> struct boot_params boot_params __attribute__((aligned(16)));
> struct setup_header *hdr = (struct setup_header *)(0x90000 + 0x1f1);
> 
> void boot_zimage(void *setup_base)
> {
> 	memset(&boot_params, 0x00, sizeof boot_params);
> 	memcpy(&boot_params.hdr, hdr, sizeof (*hdr));
> 
> 	boot_params.alt_mem_k = 128 * 1024;
> 	boot_params.e820_entries = 1;
> 	boot_params.e820_map[0].addr = 0x00000000;
> 	boot_params.e820_map[0].size = 128 * 1024;
> 	boot_params.e820_map[0].type = 1;
> 
> 	asm(	"movw	$0x18, %%cx\n" \
> 		"movl	%%ecx, %%ds\n" \
> 		"movl	%%ecx, %%es\n" \
> 		"movl	%%ecx, %%fs\n" \
> 		"movl	%%ecx, %%gs\n" \
> 		"movl	%%ecx, %%ss\n" \
> 		"xorl	%%ebp, %%ebp\n" \
> 		"xorl	%%edi, %%edi\n" \
> 		"xorl	%%ebx, %%ebx\n" \
> 		"movl	%0, %%esi\n"
                        ^^
> 		"movl   $0x100000, %%eax\n" \
> 		"jmpl	*%%eax" : : "r"(&boot_params));
                                     ^

At this point you have probably clobbered the register that you have
your boot_params in.

Instead, do something like:

	asm volatile(
 		"movl	%0, %%ds\n" \
 		"movl	%0, %%es\n" \
 		"movl	%0, %%fs\n" \
 		"movl	%0, %%gs\n" \
		"movl	%0, %%ss\n" \
		"xorl	%ebp, %ebp\n" \
		"xorl	%ebx, %ebx\n" \
 		"movl   $0x100000, %%eax\n" \
 		"ljmpl	$0x10,$0x100000"
	 : : "S" (&boot_params), "D" (0), "c" (0x18));

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: x86 embedded - Problem getting past 'move compressed kernel before decompression'

[H. Peter Anvin]

On 02/20/2010 09:45 PM, H. Peter Anvin wrote:
> 
> Instead, do something like:
> 
> 	asm volatile(
>  		"movl	%0, %%ds\n" \
>  		"movl	%0, %%es\n" \
>  		"movl	%0, %%fs\n" \
>  		"movl	%0, %%gs\n" \
> 		"movl	%0, %%ss\n" \
> 		"xorl	%ebp, %ebp\n" \
> 		"xorl	%ebx, %ebx\n" \
>  		"movl   $0x100000, %%eax\n" \
>  		"ljmpl	$0x10,$0x100000"
> 	 : : "S" (&boot_params), "D" (0), "c" (0x18));
> 
> 	-hpa
> 

Make that:

 	asm volatile(
  		"movl	%2, %%ds\n" \
  		"movl	%2, %%es\n" \
  		"movl	%2, %%fs\n" \
  		"movl	%2, %%gs\n" \
 		"movl	%2, %%ss\n" \
 		"xorl	%ebp, %ebp\n" \
 		"xorl	%ebx, %ebx\n" \
  		"ljmpl	$0x10,$0x100000"
 	 : : "S" (&boot_params), "D" (0), "r" (0x18));

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

RE: x86 embedded - Problem getting past 'move compressed kernel before decompression'

[Yuhong Bao]

> Make that:
>
> asm volatile(
> "movl %2, %%ds\n" \
> "movl %2, %%es\n" \
> "movl %2, %%fs\n" \
> "movl %2, %%gs\n" \
> "movl %2, %%ss\n" \
> "xorl %ebp, %ebp\n" \
> "xorl %ebx, %ebx\n" \
> "ljmpl $0x10,$0x100000"
> : : "S" (&boot_params), "D" (0), "r" (0x18));
Or if you don't want a far jmp, something like this for non-PIC:

asm volatile(

"movl %4, %%ds\n" \

"movl %4, %%es\n" \

"movl %4, %%fs\n" \

"movl %4, %%gs\n" \

"movl %4, %%ss\n" \

"xorl %ebp, %ebp\n" \

"jmpl *%3"

: : "S" (&boot_params), "D" (0), "b" (0), "r" (0x100000), "r" (0x18));

This for PIC:


asm volatile(


"movl %3, %%ds\n" \


"movl %3, %%es\n" \


"movl %3, %%fs\n" \


"movl %3, %%gs\n" \


"movl %3, %%ss\n" \


"xorl %ebp, %ebp\n" \
"xorl %ebx, %ebx\n" \


"jmpl *%2"


: : "S" (&boot_params), "D" (0), "r" (0x100000), "r" (0x18));


Yuhong Bao 		 	   		  
_________________________________________________________________
Your E-mail and More On-the-Go. Get Windows Live Hotmail Free.
http://clk.atdmt.com/GBL/go/201469229/direct/01/

Re: x86 embedded - Problem getting past 'move compressed kernel before decompression'

[Graeme Russ]

On Sun, Feb 21, 2010 at 4:53 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 02/20/2010 09:45 PM, H. Peter Anvin wrote:
>
> Make that:
>
>        asm volatile(
>                "movl   %2, %%ds\n" \
>                "movl   %2, %%es\n" \
>                "movl   %2, %%fs\n" \
>                "movl   %2, %%gs\n" \
>                "movl   %2, %%ss\n" \
>                "xorl   %ebp, %ebp\n" \
>                "xorl   %ebx, %ebx\n" \
>                "ljmpl  $0x10,$0x100000"
>         : : "S" (&boot_params), "D" (0), "r" (0x18));
>

Thanks Peter - I gave that a try but no luck. I am in the process of
writing some routines which will dump the contents of the registers
upon entering startup_32 and the relocation jump address prior to
the jump.

My assembler is a bit rusty, so it is taking a bit of time

What other information should I dump?

Regards,

Graeme

Re: x86 embedded - Problem getting past 'move compressed kernel before decompression'

[Graeme Russ]

Graeme Russ wrote:
> On Sun, Feb 21, 2010 at 4:53 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>> On 02/20/2010 09:45 PM, H. Peter Anvin wrote:
>>
> Thanks Peter - I gave that a try but no luck. I am in the process of
> writing some routines which will dump the contents of the registers
> upon entering startup_32 and the relocation jump address prior to
> the jump.
> 
> My assembler is a bit rusty, so it is taking a bit of time
> 

Sorry for the delay - been very busy lately.

I borrowed __show_regs() from process_32.c and implemented crash dump and
break dump handlers in u-boot. So now I can int3 and dump all registers.

To give some context to what I am doing in u-boot:

#define DECLARE_INTERRUPT(x) \
	".globl irq_"#x"\n" \
	".hidden irq_"#x"\n" \
	".type irq_"#x", @function\n" \
	"irq_"#x":\n" \
	"pushl $"#x"\n" \
	"jmp irq_common_entry\n"

asm(".globl irq_common_entry\n" \
	".hidden irq_common_entry\n" \
	".type irq_common_entry, @function\n" \
	"irq_common_entry:\n" \
	"cld\n" \
	"pushl %gs\n" \
	"pushl %fs\n" \
	"pushl %es\n" \
	"pushl %ds\n" \
	"pushl %eax\n" \
	"pushl %ebp\n" \
	"pushl %edi\n" \
	"pushl %esi\n" \
	"pushl %edx\n" \
	"pushl %ecx\n" \
	"pushl %ebx\n" \
	"mov   %esp, %eax\n" \
	"pushl %ebp\n" \
	"movl %esp,%ebp\n" \
	"pushl %eax\n" \
	"call irq_llsr\n" \
	"popl %eax\n" \
	"leave\n"\
	"popl %ebx\n" \
	"popl %ecx\n" \
	"popl %edx\n" \
	"popl %esi\n" \
	"popl %edi\n" \
	"popl %ebp\n" \
	"popl %eax\n" \
	"popl %ds\n" \
	"popl %es\n" \
	"popl %fs\n" \
	"popl %gs\n" \
	"add  $4, %esp\n" \
	"iret\n" \
	DECLARE_INTERRUPT(0) \
	DECLARE_INTERRUPT(1) \
	DECLARE_INTERRUPT(2) \
.
.
.
	DECLARE_INTERRUPT(255)

/* IRQ Low-Level Service Routine */
__isr__ irq_llsr(struct pt_regs *regs)
{
	switch (regs->orig_eax) {
 	case 0x00:
		printf("Divide Error (Division by zero)\n");
		dump_regs(regs);
 		while(1);
 		break;
 	case 0x01:
		printf("Debug Interrupt (Single step)\n");
		dump_regs(regs);
 		break;
 	case 0x02:
		printf("NMI Interrupt\n");
		dump_regs(regs);
 		break;
 	case 0x03:
		printf("Breakpoint\n");
		dump_regs(regs);
 		break;
etc
}

dump_regs() is pretty much the same as __show_regs() in process_32.c

I've pulled the latest 6.2.33 kernel source and applied the following patch
to trace progress through the 32-bit Boot Protocol:

diff --git a/arch/x86/boot/compressed/head_32.S
b/arch/x86/boot/compressed/head_32.S
index f543b70..3535470 100644
--- a/arch/x86/boot/compressed/head_32.S
+++ b/arch/x86/boot/compressed/head_32.S
@@ -32,6 +32,7 @@

 	__HEAD
 ENTRY(startup_32)
+	int3
 	cld
 	/*
 	 * Test KEEP_SEGMENTS flag to see if the bootloader is asking
@@ -93,12 +94,14 @@ ENTRY(startup_32)
  * Copy the compressed kernel to the end of our buffer
  * where decompression in place becomes safe.
  */
+	int3
 	pushl	%esi
 	leal	(_bss-4)(%ebp), %esi
 	leal	(_bss-4)(%ebx), %edi
 	movl	$(_bss - startup_32), %ecx
 	shrl	$2, %ecx
 	std
+	int3
 	rep	movsl
 	cld
 	popl	%esi
@@ -106,12 +109,15 @@ ENTRY(startup_32)
 /*
  * Jump to the relocated address.
  */
+	int3
 	leal	relocated(%ebx), %eax
+	int3
 	jmp	*%eax
 ENDPROC(startup_32)

 	.text
 relocated:
+	int3

 /*
  * Clear BSS (stack is currently empty)

and in u-boot, to boot the kernel, I have:

struct boot_params boot_params __attribute__((aligned(16)));
struct setup_header *hdr = (struct setup_header *)(0x90000 + 0x1f1);

void boot_zimage(void *setup_base)
{
	printf("&boot_params = 0x%8.8lx\n", (ulong)&boot_params);
	printf("sizeof (*hdr) = 0x%8.8lx\n", (ulong)(sizeof (*hdr)));

	memset(&boot_params, 0x00, sizeof boot_params);
	memcpy(&boot_params.hdr, hdr, sizeof (*hdr));

	boot_params.alt_mem_k = 128 * 1024;
	boot_params.e820_entries = 1;
	boot_params.e820_map[0].addr = 0x00000000;
	boot_params.e820_map[0].size = 128 * 1024;
	boot_params.e820_map[0].type = 1;

	printf("Entering Linux\n");

       asm volatile(
               "movl   %2, %%ds\n" \
               "movl   %2, %%es\n" \
               "movl   %2, %%fs\n" \
               "movl   %2, %%gs\n" \
               "movl   %2, %%ss\n" \
               "xorl   %%ebp, %%ebp\n" \
               "xorl   %%ebx, %%ebx\n" \
               "int3\n" \
               "ljmpl  $0x10,$0x100000"
	        : : "S" (&boot_params), "D" (0), "r" (0x18));
}


The result is:

&boot_params = 0x03ffb350
sizeof (*hdr) = 0x00000067
Entering Linux
Breakpoint
EIP: 0010:[<03fe3e0b>] EFLAGS: 00000046
EAX: 00000018 EBX: 00000000 ECX: 000003f8 EDX: 000003f8
ESI: 03ffb350 EDI: 00000000 EBP: 00000000 ESP: 03ff42f3
 DS: 0018 ES: 0018 FS: 0018 GS: 0018 SS: 01f1
CR0: 00000033 CR2: 00000000 CR3: 00000000 CR4: 00080099
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: ffff0ff0 DR7: 00000400
Breakpoint
EIP: 0010:[<00100001>] EFLAGS: 00000046
EAX: 00000018 EBX: 00000000 ECX: 000003f8 EDX: 000003f8
ESI: 03ffb350 EDI: 00000000 EBP: 00000000 ESP: 03ff42f3
 DS: 0018 ES: 0018 FS: 0018 GS: 0018 SS: 01f1
CR0: 00000033 CR2: 00000000 CR3: 00000000 CR4: 00080099
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: ffff0ff0 DR7: 00000400
Breakpoint
EIP: 0010:[<00100042>] EFLAGS: 00000002
EAX: 00000018 EBX: 00377000 ECX: 000003f8 EDX: 000003f8
ESI: 03ffb350 EDI: 00000000 EBP: 00100000 ESP: 00000000
 DS: 0018 ES: 0018 FS: 0018 GS: 0018 SS: 0000
CR0: 00000033 CR2: 00000000 CR3: 00000000 CR4: 00080099
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: ffff0ff0 DR7: 00000400
Breakpoint
EIP: 0010:[<00100059>] EFLAGS: 00000416
EAX: 00000018 EBX: 00377000 ECX: 00070828 EDX: 000003f8
ESI: 002c209c EDI: 0053909c EBP: 00100000 ESP: 03ffb350
 DS: 0018 ES: 0018 FS: 0018 GS: 0018 SS: 0000
CR0: 00000033 CR2: 00000000 CR3: 00000000 CR4: 00080099
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: ffff0ff0 DR7: 00000400
Breakpoint
EIP: 0010:[<0010005e>] EFLAGS: 00000016
EAX: 00000018 EBX: 00377000 ECX: 00000000 EDX: 000003f8
ESI: 03ffb350 EDI: 00376ffc EBP: 00100000 ESP: 00000000
 DS: 0018 ES: 0018 FS: 0018 GS: 0018 SS: 0000
CR0: 00000033 CR2: 00000000 CR3: 00000000 CR4: 00080099
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: ffff0ff0 DR7: 00000400
Breakpoint
EIP: 0010:[<00100065>] EFLAGS: 00000016
EAX: 005379c4 EBX: 00377000 ECX: 00000000 EDX: 000003f8
ESI: 03ffb350 EDI: 00376ffc EBP: 00100000 ESP: 00000000
 DS: 0018 ES: 0018 FS: 0018 GS: 0018 SS: 0000
CR0: 00000033 CR2: 00000000 CR3: 00000000 CR4: 00080099
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: ffff0ff0 DR7: 00000400
Invalid Opcode (UnDefined Opcode)
EIP: 0010:[<dd013ea8>] EFLAGS: 00010016
EAX: 005379c4 EBX: 00377000 ECX: 00000000 EDX: 873d0328
ESI: 03ffb350 EDI: 00376ffc EBP: 00100000 ESP: 00000018
 DS: 0018 ES: 0018 FS: 0018 GS: 0018 SS: 0000
CR0: 00000033 CR2: 00000000 CR3: 00000000 CR4: 00080099
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: ffff0ff0 DR7: 00000400

I don't understand what is going on with SS and ESP, but everything else is
looking good up until:
 	jmp	*%eax

At which point, eax appears to hold a reasonably value. But:

boot > md 5379c4
005379c4: c11c0e7f b0c2ea61 2d43c068 f02e6fa0    ....a...h.C-.o..
005379d4: 3d0328ba 76651e87 c4c6e98e 26fddcad    .(.=..ev.......&
005379e4: 1983b874 c9edece7 793c2ce4 a8de5f50    t........,<yP_..
005379f4: a29afa5b e7b42f13 c4233d0a bc6e8424    [..../...=#.$.n.
00537a04: cb90001b dcea7bb4 969601e8 707fbe4a    .....{......J..p
00537a14: dfead2ec b8e62d5b fd7d2b53 b8ad16ef    ....[-..S+}.....
00537a24: e0252df2 28044367 9c80c800 beec457e    .-%.gC.(....~E..
00537a34: 22d27b84 4f32a8cc 9d1eb9b3 aac36b6a    .{."..2O....jk..
00537a44: f7f79e53 54af3ec6 f32eebe6 5a89fe1d    S....>.T.......Z
00537a54: 3e3aadfa 63e0b27f 5086cadd b438532e    ..:>...c...P.S8.
00537a64: 0a4daef6 f68fb9fc b525a3f1 c0cd58e7    ..M.......%..X..
00537a74: 3f727ad6 061e1199 793d150a 5fd8a267    .zr?......=yg.._
00537a84: fca2d658 4f1e392c dbdd62d3 4fed04dd    X...,9.O.b.....O
00537a94: 07caba83 1274f371 e18ef1f5 e1c32aef    ....q.t......*..
00537aa4: 964ff812 f214be9d a59e8b2c 281d0dd6    ..O.....,......(
00537ab4: 0d5a95fc 818d59e7 11d33442 73b99e6b    ..Z..Y..B4..k..s

(Note: each of the above longs is in reverse byte order, so 0x005379c4 is
actually 0x7f

I would have expected a 0xcc at 0x005379c4.

>From u-boot, if I jump straight to 0x005379c4 I get pretty much the same
crash. So it looks like a problem with the calculation of the copy source
or target address, or the calculation of the relocated jump address.

Any ideas?

Regards

Graeme

Re: x86 embedded - Problem getting past 'move compressed kernel before decompression'

[Graeme Russ]

Graeme Russ wrote:
> Graeme Russ wrote:
>> On Sun, Feb 21, 2010 at 4:53 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>>> On 02/20/2010 09:45 PM, H. Peter Anvin wrote:
>>>

> I borrowed __show_regs() from process_32.c and implemented crash dump and
> break dump handlers in u-boot. So now I can int3 and dump all registers.
> 
> 
> I don't understand what is going on with SS and ESP, but everything else is
> looking good up until:
>  	jmp	*%eax
> 
> At which point, eax appears to hold a reasonably value. But:
> 
> boot > md 5379c4
> 005379c4: c11c0e7f b0c2ea61 2d43c068 f02e6fa0    ....a...h.C-.o..

> I would have expected a 0xcc at 0x005379c4.
> 

I have done a little more digging. By adding an ascii string before
relocated: label, I am able to determine that the int3 after the relocated:
label exists in bzImage at offset 0x1C3FD7

EAX holds (for the jump) 0x5379d0 (different bzImage of course). The
contents of memory at this address is in bzImage at offset 0x1C09D7 - A
difference of 0x3600 (seems too even to be random)

I'm obviously doing something hideously wrong, but what?

Regards,

Graeme

Re: x86 embedded - Problem getting past 'move compressed kernel before decompression'

[H. Peter Anvin]

On 03/01/2010 03:56 AM, Graeme Russ wrote:
> 
> I have done a little more digging. By adding an ascii string before
> relocated: label, I am able to determine that the int3 after the relocated:
> label exists in bzImage at offset 0x1C3FD7
> 
> EAX holds (for the jump) 0x5379d0 (different bzImage of course). The
> contents of memory at this address is in bzImage at offset 0x1C09D7 - A
> difference of 0x3600 (seems too even to be random)
> 
> I'm obviously doing something hideously wrong, but what?
> 

0x3600 sounds like the size of the real-mode code in bzImage.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: x86 embedded - Problem getting past 'move compressed kernel before decompression'

[Graeme Russ]

H. Peter Anvin wrote:
> On 03/01/2010 03:56 AM, Graeme Russ wrote:
>> I have done a little more digging. By adding an ascii string before
>> relocated: label, I am able to determine that the int3 after the relocated:
>> label exists in bzImage at offset 0x1C3FD7
>>
>> EAX holds (for the jump) 0x5379d0 (different bzImage of course). The
>> contents of memory at this address is in bzImage at offset 0x1C09D7 - A
>> difference of 0x3600 (seems too even to be random)
>>
>> I'm obviously doing something hideously wrong, but what?
>>
> 
> 0x3600 sounds like the size of the real-mode code in bzImage.
> 

But what could I be doing to cause the miscalculation? From what I
understand, everything looks to be calculated at build time

Graeme

Re: x86 embedded - Problem getting past 'move compressed kernel before decompression'

[H. Peter Anvin]

On 03/01/2010 11:41 AM, Graeme Russ wrote:
> H. Peter Anvin wrote:
>> On 03/01/2010 03:56 AM, Graeme Russ wrote:
>>> I have done a little more digging. By adding an ascii string before
>>> relocated: label, I am able to determine that the int3 after the relocated:
>>> label exists in bzImage at offset 0x1C3FD7
>>>
>>> EAX holds (for the jump) 0x5379d0 (different bzImage of course). The
>>> contents of memory at this address is in bzImage at offset 0x1C09D7 - A
>>> difference of 0x3600 (seems too even to be random)
>>>
>>> I'm obviously doing something hideously wrong, but what?
>>>
>>
>> 0x3600 sounds like the size of the real-mode code in bzImage.
>>
> 
> But what could I be doing to cause the miscalculation? From what I
> understand, everything looks to be calculated at build time
> 

If I were to guess, you loaded the entire bzImage into high memory,
rather than just the PM portion thereof.

	-hpa

Re: x86 embedded - Problem getting past 'move compressed kernel before decompression'

[Graeme Russ]

H. Peter Anvin wrote:
> On 03/01/2010 11:41 AM, Graeme Russ wrote:
>> H. Peter Anvin wrote:
>>> On 03/01/2010 03:56 AM, Graeme Russ wrote:
>>>> I have done a little more digging. By adding an ascii string before
>>>> relocated: label, I am able to determine that the int3 after the relocated:
>>>> label exists in bzImage at offset 0x1C3FD7
>>>>
>>>> EAX holds (for the jump) 0x5379d0 (different bzImage of course). The
>>>> contents of memory at this address is in bzImage at offset 0x1C09D7 - A
>>>> difference of 0x3600 (seems too even to be random)
>>>>
>>>> I'm obviously doing something hideously wrong, but what?
>>>>
>>> 0x3600 sounds like the size of the real-mode code in bzImage.
>>>
>> But what could I be doing to cause the miscalculation? From what I
>> understand, everything looks to be calculated at build time
>>
> 
> If I were to guess, you loaded the entire bzImage into high memory,
> rather than just the PM portion thereof.
> 
I which case I would not think I would be jumping to 0x100000 as the
entry-point for the 32-bit protocol (at a guess I would be jumping to 0x103600)

Graeme

Re: x86 embedded - Problem getting past 'move compressed kernel before decompression'

[Graeme Russ]

Graeme Russ wrote:
> H. Peter Anvin wrote:
>> On 03/01/2010 11:41 AM, Graeme Russ wrote:
>>> H. Peter Anvin wrote:
>>>> On 03/01/2010 03:56 AM, Graeme Russ wrote:
>>>>> I have done a little more digging. By adding an ascii string before
>>>>> relocated: label, I am able to determine that the int3 after the relocated:
>>>>> label exists in bzImage at offset 0x1C3FD7
>>>>>
>>>>> EAX holds (for the jump) 0x5379d0 (different bzImage of course). The
>>>>> contents of memory at this address is in bzImage at offset 0x1C09D7 - A
>>>>> difference of 0x3600 (seems too even to be random)
>>>>>

I've had a close look at the memory dumps and it looks like U-Boot is not
loading in the .text section which is _after_ the compressed vmlinux. This
is what contains the code after the relocated: label. Looks like the
bzImage anatomy information on the net is a little out of date - They
appear to have all the decompression code before the compressed kernel...

I've taken a slightly different tack now - I am tftp'ing the entire bzImage
to 0xfca00 (0x100000 - 0x3600) and adjusting the setup_header pointer to
0xfca00 + 0x1f1 and jumping to 0x10000. After a few false starts, I am able
to get an lzo compressed bzImage up to startup_32 in arch/x86/kernel/head_32.S

My next problem is at Enable Paging:

/*
 * Enable paging
 */
	movl $pa(swapper_pg_dir),%eax
	movl %eax,%cr3		/* set the page table pointer.. */
	movl %cr0,%eax
	orl  $X86_CR0_PG,%eax
	movl %eax,%cr0		/* ..and set paging (PG) bit */
	ljmp $__BOOT_CS,$1f	/* Clear prefetch and normalize %eip */


The kernel crashes at:
	movl %eax,%cr0		/* ..and set paging (PG) bit */

Argh, so close, yet so far :(

regards.

Graeme