The filo crashes if the filo and coreboot overlap.

[Zheng Bao]

The filo crashes if the filo and coreboot overlap.

Since the CBFS is the must-have feature, my family 10
 board crashes when it jumps to filo. I am trying to
 find out why. I need help.
Based on current code, the AMD Family 10 will cause the filo
and coreboot overlap in RAM. The overlaps_coreboot() in selfboot.c
will return 1. But I am not sure if it will make the system
crashes. If anybody explains briefly what happens if they
overlap.

The coreboot information:
CONFIG_RAMBASE=0x00200000

Thie filo information
#realelf -l filo.elf
Elf file type is EXEC (Executable file)
Entry point 0x10008c
There are 5 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x0000e0 0x00100000 0x00100000 0x14700 0x39be50 RWE 0x20
  LOAD           0x0147e0 0x0049be50 0x0049be50 0x00048 0x00048 RW  0x4
  NOTE           0x0000e0 0x00100000 0x00100000 0x0008c 0x0008c R   0x4
  NOTE           0x013280 0x001131a0 0x001131a0 0x00030 0x00030 R   0x4
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4

Section to Segment mapping:
  Segment Sections...
   00     .note .boot .text .rodata .note.pinfo .eh_frame .data .bss 
   01     .initctx 
   02     .note 
   03     .note.pinfo 
   04     
    	 	   		  
_________________________________________________________________
Windows Live: Friends get your Flickr, Yelp, and Digg updates when they e-mail you.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/soc...

[Patrick Georgi]

Am Samstag, den 31.10.2009, 15:43 +0000 schrieb Zheng Bao:
> The filo crashes if the filo and coreboot overlap.
> Since the CBFS is the must-have feature, my family 10
>  board crashes when it jumps to filo. I am trying to
>  find out why. I need help.
> Based on current code, the AMD Family 10 will cause the filo
> and coreboot overlap in RAM. The overlaps_coreboot() in selfboot.c
> will return 1. But I am not sure if it will make the system
> crashes.

What revision is that? There was an issue like that but I fixed it
several weeks ago.
> If anybody explains briefly what happens if they
> overlap.

When coreboot and payload overlap, coreboot uses a bounce buffer. The
bounce buffer is twice the size of coreboot. The first half is for the
part of the payload that overlaps coreboot, the other half is for
coreboot itself.

The SELF loader loads data that would overlap coreboot to the bounce
buffer, and jumps into jmp_to_elf_entry when it's done with loading.
The jmp_to_elf_entry function copies coreboot to the upper half of the
bounce buffer, and jumps in there, so the code is out of the way.

Then it copies the lower half to the coreboot area and jumps to the
entry point.

There are some complications to that because of the decompression
routine, so the code is not as nice as it should be. But I specifically
tested your scenario (payload from 1mb to 2.3mb or so, coreboot starting
at 2mb)
> The coreboot information:
> CONFIG_RAMBASE=0x00200000

Try changing that to 0x100000.

Patrick

[Bao, Zheng]

In relocate_segment().
If the coreboot and filo overlap, it will "slice off" a piece at the
beginning or end. A new segment is allocated. If it is inserted before
the "seg" that is being processed, is there any chance that the "new"
segment will be processed? I am confused about it. On my fam 10 board,
it seems that the "new" segment was not processed and an error happens
when the code jumps to filo which is actually middle of nowhere.

Zheng

-----Original Message-----
From: coreboot-bounces+zheng.bao=[e-mail]
[mailto:coreboot-bounces+zheng.bao=[e-mail]] On Behalf Of
Patrick Georgi
Sent: Sunday, November 01, 2009 12:13 AM
To: Zheng Bao
Cc: [e-mail]
Subject: Re: [coreboot] The filo crashes if the filo and coreboot
overlap.

Am Samstag, den 31.10.2009, 15:43 +0000 schrieb Zheng Bao:
> The filo crashes if the filo and coreboot overlap.
> Since the CBFS is the must-have feature, my family 10
>  board crashes when it jumps to filo. I am trying to
>  find out why. I need help.
> Based on current code, the AMD Family 10 will cause the filo
> and coreboot overlap in RAM. The overlaps_coreboot() in selfboot.c
> will return 1. But I am not sure if it will make the system
> crashes.

What revision is that? There was an issue like that but I fixed it
several weeks ago.
> If anybody explains briefly what happens if they
> overlap.

When coreboot and payload overlap, coreboot uses a bounce buffer. The
bounce buffer is twice the size of coreboot. The first half is for the
part of the payload that overlaps coreboot, the other half is for
coreboot itself.

The SELF loader loads data that would overlap coreboot to the bounce
buffer, and jumps into jmp_to_elf_entry when it's done with loading.
The jmp_to_elf_entry function copies coreboot to the upper half of the
bounce buffer, and jumps in there, so the code is out of the way.

Then it copies the lower half to the coreboot area and jumps to the
entry point.

There are some complications to that because of the decompression
routine, so the code is not as nice as it should be. But I specifically
tested your scenario (payload from 1mb to 2.3mb or so, coreboot starting
at 2mb)
> The coreboot information:
> CONFIG_RAMBASE=0x00200000

Try changing that to 0x100000.

Patrick

[PATCH] The filo crashes if the filo and coreboot overlap.

[Bao, Zheng]

If the coreboot and filo overlap, it will "slice off" a piece at the
beginning or end. In the beginning case, a new segment is inserted
before the current one.  The ptr will move forward and doesn't seem to
have any chance to process the "new" segment.

ptr ---------+     move --->
                             |
                             V
        +--------+       +--------+
        |        |       |        |
        |  new   | <---> |current | <---> .....
        |        |       |        |
        +--------+       +--------+

Now we change the ptr to the previous one and restart the loop. The
new and current segment will both be processed.

+----------------ptr      move --->
      |
      V
 +--------+        +--------+       +--------+
 |        |        |        |       |        |
 |  prev  | <--->  |  new   | <---> |current | <---> .....
 |        |        |        |       |        |
 +--------+        +--------+       +--------+

It is tested on my Family 10 board.

Zheng

Signed-off-by: Zheng Bao

Index: src/boot/selfboot.c
===================================================================
--- src/boot/selfboot.c	(revision 4892)
+++ src/boot/selfboot.c	(working copy)
@@ -211,19 +211,21 @@
    return !((end <= lb_start) || (start >= lb_end));
 }

-static void relocate_segment(unsigned long buffer, struct segment *seg)
+static int relocate_segment(unsigned long buffer, struct segment *seg)
 {
    /* Modify all segments that want to load onto coreboot
     * to load onto the bounce buffer instead.
     */
-	unsigned long start, middle, end;
+	/* ret:  1 : A new segment is inserted before the seg.
+	 *       0 : A new segment is inserted after the seg, or no new
one. */
+	unsigned long start, middle, end, ret = 0;

printk_spew("lb: [0x%016lx, 0x%016lx)\n", 
    	lb_start, lb_end);

/* I don't conflict with coreboot so get out of here */
    if (!overlaps_coreboot(seg))
-		return;
+		return 0;

start = seg->s_dstaddr;
    middle = start + seg->s_filesz;
@@ -270,6 +272,8 @@
    			new->s_dstaddr, 
    			new->s_dstaddr + new->s_filesz,
    			new->s_dstaddr + new->s_memsz);
+
+			ret = 1;
    	}
    		
    	/* Slice off a piece at the end 
@@ -319,6 +323,8 @@
    	seg->s_dstaddr, 
    	seg->s_dstaddr + seg->s_filesz, 
    	seg->s_dstaddr + seg->s_memsz);
+
+	return ret;
 }

@@ -446,7 +452,10 @@
    	
    	/* Modify the segment to load onto the bounce_buffer if
necessary.
    	 */
-		relocate_segment(bounce_buffer, ptr);
+		if (relocate_segment(bounce_buffer, ptr)) {
+			ptr = (ptr->prev)->prev;
+			continue;
+		}

printk_debug("Post relocation: addr: 0x%016lx memsz:
0x%016lx filesz: 0x%016lx\n",
    		ptr->s_dstaddr, ptr->s_memsz, ptr->s_filesz);

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Bao, Zheng
Sent: Monday, November 02, 2009 11:25 AM
To: Patrick Georgi
Cc: [e-mail]
Subject: Re: [coreboot] The filo crashes if the filo and coreboot
overlap.

In relocate_segment().
If the coreboot and filo overlap, it will "slice off" a piece at the
beginning or end. A new segment is allocated. If it is inserted before
the "seg" that is being processed, is there any chance that the "new"
segment will be processed? I am confused about it. On my fam 10 board,
it seems that the "new" segment was not processed and an error happens
when the code jumps to filo which is actually middle of nowhere.

Zheng

-----Original Message-----
From: coreboot-bounces+zheng.bao=[e-mail]
[mailto:coreboot-bounces+zheng.bao=[e-mail]] On Behalf Of
Patrick Georgi
Sent: Sunday, November 01, 2009 12:13 AM
To: Zheng Bao
Cc: [e-mail]
Subject: Re: [coreboot] The filo crashes if the filo and coreboot
overlap.

Am Samstag, den 31.10.2009, 15:43 +0000 schrieb Zheng Bao:
> The filo crashes if the filo and coreboot overlap.
> Since the CBFS is the must-have feature, my family 10
>  board crashes when it jumps to filo. I am trying to
>  find out why. I need help.
> Based on current code, the AMD Family 10 will cause the filo
> and coreboot overlap in RAM. The overlaps_coreboot() in selfboot.c
> will return 1. But I am not sure if it will make the system
> crashes.

What revision is that? There was an issue like that but I fixed it
several weeks ago.
> If anybody explains briefly what happens if they
> overlap.

When coreboot and payload overlap, coreboot uses a bounce buffer. The
bounce buffer is twice the size of coreboot. The first half is for the
part of the payload that overlaps coreboot, the other half is for
coreboot itself.

The SELF loader loads data that would overlap coreboot to the bounce
buffer, and jumps into jmp_to_elf_entry when it's done with loading.
The jmp_to_elf_entry function copies coreboot to the upper half of the
bounce buffer, and jumps in there, so the code is out of the way.

Then it copies the lower half to the coreboot area and jumps to the
entry point.

There are some complications to that because of the decompression
routine, so the code is not as nice as it should be. But I specifically
tested your scenario (payload from 1mb to 2.3mb or so, coreboot starting
at 2mb)
> The coreboot information:
> CONFIG_RAMBASE=0x00200000

Try changing that to 0x100000.

Patrick

[PATCH] The filo crashes if the filo and coreboot overlap.

[Patrick Georgi]

Am 03.11.2009 04:23, schrieb Bao, Zheng:
> If the coreboot and filo overlap, it will "slice off" a piece at the
> beginning or end. In the beginning case, a new segment is inserted
> before the current one.  The ptr will move forward and doesn't seem to
> have any chance to process the "new" segment.

You are aware that your patch only has an effect for non-compressed 
payloads?

Patrick

[PATCH] The filo crashes if the filo and coreboot overlap.

[Marc Jones]

On Tue, Nov 3, 2009 at 9:12 AM, Patrick Georgi  wrote:
> Am 03.11.2009 04:23, schrieb Bao, Zheng:
> > If the coreboot and filo overlap, it will "slice off" a piece at the
> > beginning or end. In the beginning case, a new segment is inserted
> > before the current one.  The ptr will move forward and doesn't seem to
> > have any chance to process the "new" segment.
>
> You are aware that your patch only has an effect for non-compressed
> payloads?

Patrick and Zheng,

I'm struggling to understand the bug. If the payload is uncompressed,
it can put a segment before coreboot in the bouncebuffer (this seems
to be the bug?). Then the loop needs to be re-run on the newly
split/added segment. If it is compressed, It will skip all of the
coreboot area and not allocate a segment before coreboot (put the
entire thing in the bounce buffer?).

Does this get back to the CONFIG_RAMBASE=0x00200000 on fam10?

Marc

[PATCH] The filo crashes if the filo and coreboot overlap.

[Bao, Zheng]

Marc and Patrick,
The LZMA compressing way doesn't work on my board. I haven't found any solution to resolve the overlapping in current code. ulzma() doesn't seem to know that overlapping happens. It is a problem that has to be solved.

Do you guys agree that my patch anyway fix the bug for non-compressed payloads?

Zheng

-----Original Message-----
From: Marc Jones [mailto:[e-mail]] 
Sent: Wednesday, November 04, 2009 6:42 AM
To: Patrick Georgi
Cc: Bao, Zheng; [e-mail]
Subject: Re: [coreboot] [PATCH] The filo crashes if the filo and coreboot overlap.

On Tue, Nov 3, 2009 at 9:12 AM, Patrick Georgi  wrote:
> Am 03.11.2009 04:23, schrieb Bao, Zheng:
> > If the coreboot and filo overlap, it will "slice off" a piece at the
> > beginning or end. In the beginning case, a new segment is inserted
> > before the current one.  The ptr will move forward and doesn't seem to
> > have any chance to process the "new" segment.
>
> You are aware that your patch only has an effect for non-compressed
> payloads?

Patrick and Zheng,

I'm struggling to understand the bug. If the payload is uncompressed,
it can put a segment before coreboot in the bouncebuffer (this seems
to be the bug?). Then the loop needs to be re-run on the newly
split/added segment. If it is compressed, It will skip all of the
coreboot area and not allocate a segment before coreboot (put the
entire thing in the bounce buffer?).

Does this get back to the CONFIG_RAMBASE=0x00200000 on fam10?

Marc

[PATCH] The filo crashes if the filo and coreboot overlap.

[Patrick Georgi]

Am 04.11.2009 03:34, schrieb Bao, Zheng:
> Marc and Patrick,
> The LZMA compressing way doesn't work on my board. I haven't found any solution to resolve the overlapping in current code. ulzma() doesn't seem to know that overlapping happens. It is a problem that has to be solved.

Thanks for your fix, but I'd like to come back to the ulzma issue.

What do you mean, that LZMA compression doesn't work on your board? 
There is a known problem that decompression takes _very_ long (several 
minutes for a moderately sized payload such as FILO).
If it looks like the boards was stuck in the decompression phase, please 
try again and wait to see if it moves on eventually (15 minutes should 
be enough with some safety margin), so we know if you ran into that 
known issue, or if you found another bug.

If it's something entirely different, I'd also like to hear about it, of 
course :-)

As for ulzma():
ulzma really doesn't know about the overlap, but the compression related 
code compensates for that. The bounce buffer function returns the start 
address of the bounce buffer. The location that is used for 
decompression is (segment_start - RAMBASE + bouncebuffer_base).
If the segment starts before the rambase, the segment is decompressed to 
the bounce buffer and the memory region before it. Right after 
decompression, the memory region before the bounce buffer is copied.
That solution has its own share of problems, but the bounce buffer 
handling code is quite nasty, and I wanted to keep the changes as small 
as possible.

Thanks,
Patrick Georgi

[PATCH] The filo crashes if the filo and corebootoverlap.

[Bao, Zheng]

Ping, before we forget.
Can anyone ack or nack this?

Zheng

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Bao, Zheng
Sent: Tuesday, November 03, 2009 11:23 AM
To: [e-mail]
Subject: Re: [coreboot] [PATCH] The filo crashes if the filo and
corebootoverlap.

If the coreboot and filo overlap, it will "slice off" a piece at the
beginning or end. In the beginning case, a new segment is inserted
before the current one.  The ptr will move forward and doesn't seem to
have any chance to process the "new" segment.

ptr ---------+     move --->
                             |
                             V
        +--------+       +--------+
        |        |       |        |
        |  new   | <---> |current | <---> .....
        |        |       |        |
        +--------+       +--------+

Now we change the ptr to the previous one and restart the loop. The
new and current segment will both be processed.

+----------------ptr      move --->
      |
      V
 +--------+        +--------+       +--------+
 |        |        |        |       |        |
 |  prev  | <--->  |  new   | <---> |current | <---> .....
 |        |        |        |       |        |
 +--------+        +--------+       +--------+

It is tested on my Family 10 board.

Zheng

Signed-off-by: Zheng Bao

Index: src/boot/selfboot.c
===================================================================
--- src/boot/selfboot.c	(revision 4892)
+++ src/boot/selfboot.c	(working copy)
@@ -211,19 +211,21 @@
    return !((end <= lb_start) || (start >= lb_end));
 }

-static void relocate_segment(unsigned long buffer, struct segment *seg)
+static int relocate_segment(unsigned long buffer, struct segment *seg)
 {
    /* Modify all segments that want to load onto coreboot
     * to load onto the bounce buffer instead.
     */
-	unsigned long start, middle, end;
+	/* ret:  1 : A new segment is inserted before the seg.
+	 *       0 : A new segment is inserted after the seg, or no new
one. */
+	unsigned long start, middle, end, ret = 0;

printk_spew("lb: [0x%016lx, 0x%016lx)\n", 
    	lb_start, lb_end);

/* I don't conflict with coreboot so get out of here */
    if (!overlaps_coreboot(seg))
-		return;
+		return 0;

start = seg->s_dstaddr;
    middle = start + seg->s_filesz;
@@ -270,6 +272,8 @@
    			new->s_dstaddr, 
    			new->s_dstaddr + new->s_filesz,
    			new->s_dstaddr + new->s_memsz);
+
+			ret = 1;
    	}
    		
    	/* Slice off a piece at the end 
@@ -319,6 +323,8 @@
    	seg->s_dstaddr, 
    	seg->s_dstaddr + seg->s_filesz, 
    	seg->s_dstaddr + seg->s_memsz);
+
+	return ret;
 }

@@ -446,7 +452,10 @@
    	
    	/* Modify the segment to load onto the bounce_buffer if
necessary.
    	 */
-		relocate_segment(bounce_buffer, ptr);
+		if (relocate_segment(bounce_buffer, ptr)) {
+			ptr = (ptr->prev)->prev;
+			continue;
+		}

printk_debug("Post relocation: addr: 0x%016lx memsz:
0x%016lx filesz: 0x%016lx\n",
    		ptr->s_dstaddr, ptr->s_memsz, ptr->s_filesz);

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Bao, Zheng
Sent: Monday, November 02, 2009 11:25 AM
To: Patrick Georgi
Cc: [e-mail]
Subject: Re: [coreboot] The filo crashes if the filo and coreboot
overlap.

In relocate_segment().
If the coreboot and filo overlap, it will "slice off" a piece at the
beginning or end. A new segment is allocated. If it is inserted before
the "seg" that is being processed, is there any chance that the "new"
segment will be processed? I am confused about it. On my fam 10 board,
it seems that the "new" segment was not processed and an error happens
when the code jumps to filo which is actually middle of nowhere.

Zheng

-----Original Message-----
From: coreboot-bounces+zheng.bao=[e-mail]
[mailto:coreboot-bounces+zheng.bao=[e-mail]] On Behalf Of
Patrick Georgi
Sent: Sunday, November 01, 2009 12:13 AM
To: Zheng Bao
Cc: [e-mail]
Subject: Re: [coreboot] The filo crashes if the filo and coreboot
overlap.

Am Samstag, den 31.10.2009, 15:43 +0000 schrieb Zheng Bao:
> The filo crashes if the filo and coreboot overlap.
> Since the CBFS is the must-have feature, my family 10
>  board crashes when it jumps to filo. I am trying to
>  find out why. I need help.
> Based on current code, the AMD Family 10 will cause the filo
> and coreboot overlap in RAM. The overlaps_coreboot() in selfboot.c
> will return 1. But I am not sure if it will make the system
> crashes.

What revision is that? There was an issue like that but I fixed it
several weeks ago.
> If anybody explains briefly what happens if they
> overlap.

When coreboot and payload overlap, coreboot uses a bounce buffer. The
bounce buffer is twice the size of coreboot. The first half is for the
part of the payload that overlaps coreboot, the other half is for
coreboot itself.

The SELF loader loads data that would overlap coreboot to the bounce
buffer, and jumps into jmp_to_elf_entry when it's done with loading.
The jmp_to_elf_entry function copies coreboot to the upper half of the
bounce buffer, and jumps in there, so the code is out of the way.

Then it copies the lower half to the coreboot area and jumps to the
entry point.

There are some complications to that because of the decompression
routine, so the code is not as nice as it should be. But I specifically
tested your scenario (payload from 1mb to 2.3mb or so, coreboot starting
at 2mb)
> The coreboot information:
> CONFIG_RAMBASE=0x00200000

Try changing that to 0x100000.

Patrick

[PATCH] The filo crashes if the filo and corebootoverlap.

[Stefan Reinauer]

Bao, Zheng wrote:
> Ping, before we forget.
> Can anyone ack or nack this?
>
> Zheng
>
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Bao, Zheng
> Sent: Tuesday, November 03, 2009 11:23 AM
> To: [e-mail]
> Subject: Re: [coreboot] [PATCH] The filo crashes if the filo and
> corebootoverlap.
>
> If the coreboot and filo overlap, it will "slice off" a piece at the
> beginning or end. In the beginning case, a new segment is inserted
> before the current one.  The ptr will move forward and doesn't seem to
> have any chance to process the "new" segment.
>             ptr ---------+     move --->
>                          |
>                          V
>     +--------+       +--------+
>     |        |       |        |
>     |  new   | <---> |current | <---> .....
>     |        |       |        |
>     +--------+       +--------+
>
> Now we change the ptr to the previous one and restart the loop. The
> new and current segment will both be processed.
>   +----------------ptr      move --->
>   |
>   V
>
> +--------+        +--------+       +--------+
>  |        |        |        |       |        |
>  |  prev  | <--->  |  new   | <---> |current | <---> .....
>  |        |        |        |       |        |
>  +--------+        +--------+       +--------+
>
> It is tested on my Family 10 board.

Very nice explanation... :-)

Acked-by: Stefan Reinauer
> Zheng
>
> Signed-off-by: Zheng Bao
> Index: src/boot/selfboot.c
>
> --- src/boot/selfboot.c	(revision 4892)
> +++ src/boot/selfboot.c	(working copy)
> @@ -211,19 +211,21 @@
>    return !((end <= lb_start) || (start >= lb_end));
>  }
>
> -static void relocate_segment(unsigned long buffer, struct segment *seg)
> +static int relocate_segment(unsigned long buffer, struct segment *seg)
>  {
>    /* Modify all segments that want to load onto coreboot
>     * to load onto the bounce buffer instead.
>     */
> unsigned long start, middle, end;
> /* ret:  1 : A new segment is inserted before the seg.
> *       0 : A new segment is inserted after the seg, or no new
>
> one. */
>
> unsigned long start, middle, end, ret = 0;
>
> printk_spew("lb: [0x%016lx, 0x%016lx)\n", 
> lb_start, lb_end);
>
> /* I don't conflict with coreboot so get out of here */
> if (!overlaps_coreboot(seg))
> return;
> return 0;
>
> start = seg->s_dstaddr;
> middle = start + seg->s_filesz;
>
> @@ -270,6 +272,8 @@
>    			new->s_dstaddr, 
>    			new->s_dstaddr + new->s_filesz,
>    			new->s_dstaddr + new->s_memsz);
> 	ret = 1;
> }
> 	
> /* Slice off a piece at the end
>
> @@ -319,6 +323,8 @@
>    	seg->s_dstaddr, 
>    	seg->s_dstaddr + seg->s_filesz, 
>    	seg->s_dstaddr + seg->s_memsz);
> return ret;
>
> }
>
> @@ -446,7 +452,10 @@
>    	
>    	/* Modify the segment to load onto the bounce_buffer if
> necessary.
>    	 */
> relocate_segment(bounce_buffer, ptr);
> if (relocate_segment(bounce_buffer, ptr)) {
> 	ptr = (ptr->prev)->prev;
> 	continue;
> }
>
> printk_debug("Post relocation: addr: 0x%016lx memsz:
>
> 0x%016lx filesz: 0x%016lx\n",
>    		ptr->s_dstaddr, ptr->s_memsz, ptr->s_filesz);
>
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Bao, Zheng
> Sent: Monday, November 02, 2009 11:25 AM
> To: Patrick Georgi
> Cc: [e-mail]
> Subject: Re: [coreboot] The filo crashes if the filo and coreboot
> overlap.
>
> In relocate_segment().
> If the coreboot and filo overlap, it will "slice off" a piece at the
> beginning or end. A new segment is allocated. If it is inserted before
> the "seg" that is being processed, is there any chance that the "new"
> segment will be processed? I am confused about it. On my fam 10 board,
> it seems that the "new" segment was not processed and an error happens
> when the code jumps to filo which is actually middle of nowhere.
>
> Zheng
>
> -----Original Message-----
> From: coreboot-bounces+zheng.bao=[e-mail]
> [mailto:coreboot-bounces+zheng.bao=[e-mail]] On Behalf Of
> Patrick Georgi
> Sent: Sunday, November 01, 2009 12:13 AM
> To: Zheng Bao
> Cc: [e-mail]
> Subject: Re: [coreboot] The filo crashes if the filo and coreboot
> overlap.
>
> Am Samstag, den 31.10.2009, 15:43 +0000 schrieb Zheng Bao:
> > The filo crashes if the filo and coreboot overlap.
> > Since the CBFS is the must-have feature, my family 10
> >  board crashes when it jumps to filo. I am trying to
> >  find out why. I need help.
> > Based on current code, the AMD Family 10 will cause the filo
> > and coreboot overlap in RAM. The overlaps_coreboot() in selfboot.c
> > will return 1. But I am not sure if it will make the system
> > crashes.
>
> What revision is that? There was an issue like that but I fixed it
> several weeks ago.
> > If anybody explains briefly what happens if they
> > overlap.
>
> When coreboot and payload overlap, coreboot uses a bounce buffer. The
> bounce buffer is twice the size of coreboot. The first half is for the
> part of the payload that overlaps coreboot, the other half is for
> coreboot itself.
>
> The SELF loader loads data that would overlap coreboot to the bounce
> buffer, and jumps into jmp_to_elf_entry when it's done with loading.
> The jmp_to_elf_entry function copies coreboot to the upper half of the
> bounce buffer, and jumps in there, so the code is out of the way.
>
> Then it copies the lower half to the coreboot area and jumps to the
> entry point.
>
> There are some complications to that because of the decompression
> routine, so the code is not as nice as it should be. But I specifically
> tested your scenario (payload from 1mb to 2.3mb or so, coreboot starting
> at 2mb)
> > The coreboot information:
> > CONFIG_RAMBASE=0x00200000
>
> Try changing that to 0x100000.
>
> Patrick

[PATCH] The filo crashes if the filo and corebootoverlap.

[Bao, Zheng]

r4912.
Delete some trailing whitespace.

-----Original Message-----
From: Stefan Reinauer [mailto:[e-mail]] 
Sent: Thursday, November 05, 2009 5:15 PM
To: Bao, Zheng
Cc: [e-mail]
Subject: Re: [coreboot] [PATCH] The filo crashes if the filo and corebootoverlap.

Bao, Zheng wrote:
> Ping, before we forget.
> Can anyone ack or nack this?
>
> Zheng
>
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Bao, Zheng
> Sent: Tuesday, November 03, 2009 11:23 AM
> To: [e-mail]
> Subject: Re: [coreboot] [PATCH] The filo crashes if the filo and
> corebootoverlap.
>
> If the coreboot and filo overlap, it will "slice off" a piece at the
> beginning or end. In the beginning case, a new segment is inserted
> before the current one.  The ptr will move forward and doesn't seem to
> have any chance to process the "new" segment.
>             ptr ---------+     move --->
>                          |
>                          V
>     +--------+       +--------+
>     |        |       |        |
>     |  new   | <---> |current | <---> .....
>     |        |       |        |
>     +--------+       +--------+
>
> Now we change the ptr to the previous one and restart the loop. The
> new and current segment will both be processed.
>   +----------------ptr      move --->
>   |
>   V
>
> +--------+        +--------+       +--------+
>  |        |        |        |       |        |
>  |  prev  | <--->  |  new   | <---> |current | <---> .....
>  |        |        |        |       |        |
>  +--------+        +--------+       +--------+
>
> It is tested on my Family 10 board.

Very nice explanation... :-)

Acked-by: Stefan Reinauer
> Zheng
>
> Signed-off-by: Zheng Bao
> Index: src/boot/selfboot.c
>
> --- src/boot/selfboot.c	(revision 4892)
> +++ src/boot/selfboot.c	(working copy)
> @@ -211,19 +211,21 @@
>    return !((end <= lb_start) || (start >= lb_end));
>  }
>
> -static void relocate_segment(unsigned long buffer, struct segment *seg)
> +static int relocate_segment(unsigned long buffer, struct segment *seg)
>  {
>    /* Modify all segments that want to load onto coreboot
>     * to load onto the bounce buffer instead.
>     */
> unsigned long start, middle, end;
> /* ret:  1 : A new segment is inserted before the seg.
> *       0 : A new segment is inserted after the seg, or no new
>
> one. */
>
> unsigned long start, middle, end, ret = 0;
>
> printk_spew("lb: [0x%016lx, 0x%016lx)\n", 
> lb_start, lb_end);
>
> /* I don't conflict with coreboot so get out of here */
> if (!overlaps_coreboot(seg))
> return;
> return 0;
>
> start = seg->s_dstaddr;
> middle = start + seg->s_filesz;
>
> @@ -270,6 +272,8 @@
>    			new->s_dstaddr, 
>    			new->s_dstaddr + new->s_filesz,
>    			new->s_dstaddr + new->s_memsz);
> 	ret = 1;
> }
> 	
> /* Slice off a piece at the end
>
> @@ -319,6 +323,8 @@
>    	seg->s_dstaddr, 
>    	seg->s_dstaddr + seg->s_filesz, 
>    	seg->s_dstaddr + seg->s_memsz);
> return ret;
>
> }
>
> @@ -446,7 +452,10 @@
>    	
>    	/* Modify the segment to load onto the bounce_buffer if
> necessary.
>    	 */
> relocate_segment(bounce_buffer, ptr);
> if (relocate_segment(bounce_buffer, ptr)) {
> 	ptr = (ptr->prev)->prev;
> 	continue;
> }
>
> printk_debug("Post relocation: addr: 0x%016lx memsz:
>
> 0x%016lx filesz: 0x%016lx\n",
>    		ptr->s_dstaddr, ptr->s_memsz, ptr->s_filesz);
>
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Bao, Zheng
> Sent: Monday, November 02, 2009 11:25 AM
> To: Patrick Georgi
> Cc: [e-mail]
> Subject: Re: [coreboot] The filo crashes if the filo and coreboot
> overlap.
>
> In relocate_segment().
> If the coreboot and filo overlap, it will "slice off" a piece at the
> beginning or end. A new segment is allocated. If it is inserted before
> the "seg" that is being processed, is there any chance that the "new"
> segment will be processed? I am confused about it. On my fam 10 board,
> it seems that the "new" segment was not processed and an error happens
> when the code jumps to filo which is actually middle of nowhere.
>
> Zheng
>
> -----Original Message-----
> From: coreboot-bounces+zheng.bao=[e-mail]
> [mailto:coreboot-bounces+zheng.bao=[e-mail]] On Behalf Of
> Patrick Georgi
> Sent: Sunday, November 01, 2009 12:13 AM
> To: Zheng Bao
> Cc: [e-mail]
> Subject: Re: [coreboot] The filo crashes if the filo and coreboot
> overlap.
>
> Am Samstag, den 31.10.2009, 15:43 +0000 schrieb Zheng Bao:
> > The filo crashes if the filo and coreboot overlap.
> > Since the CBFS is the must-have feature, my family 10
> >  board crashes when it jumps to filo. I am trying to
> >  find out why. I need help.
> > Based on current code, the AMD Family 10 will cause the filo
> > and coreboot overlap in RAM. The overlaps_coreboot() in selfboot.c
> > will return 1. But I am not sure if it will make the system
> > crashes.
>
> What revision is that? There was an issue like that but I fixed it
> several weeks ago.
> > If anybody explains briefly what happens if they
> > overlap.
>
> When coreboot and payload overlap, coreboot uses a bounce buffer. The
> bounce buffer is twice the size of coreboot. The first half is for the
> part of the payload that overlaps coreboot, the other half is for
> coreboot itself.
>
> The SELF loader loads data that would overlap coreboot to the bounce
> buffer, and jumps into jmp_to_elf_entry when it's done with loading.
> The jmp_to_elf_entry function copies coreboot to the upper half of the
> bounce buffer, and jumps in there, so the code is out of the way.
>
> Then it copies the lower half to the coreboot area and jumps to the
> entry point.
>
> There are some complications to that because of the decompression
> routine, so the code is not as nice as it should be. But I specifically
> tested your scenario (payload from 1mb to 2.3mb or so, coreboot starting
> at 2mb)
> > The coreboot information:
> > CONFIG_RAMBASE=0x00200000
>
> Try changing that to 0x100000.
>
> Patrick