Gigabyte M57SLI - 4MB Chip - LAB LZMA Error

[Harald Gutmann]

Hello,

as i had some time in the past week i tried to get coreboot running on the m57sli mainboard, but i failed once more. i created the romimage with buildrom-devel, and did some changes to different values.

First here are all my modifications to the svn tree:
buildrom-devel: nothing special, just add a kernel-config for 64bit.
http://phpfi.com/319153

cooreboot v2: change the ROM_SIZE to 4MB and increase the value for ROM_IMAGE_SIZE, as the ld process fails otherwise with the following error: 
build-error: http://phpfi.com/319154
changes to the coreboot svn-tree: http://phpfi.com/319151

Here is the buildrom-devel .config file:
http://phpfi.com/319150

The result on that changes is an 4MB large rom-file, which boots up, but fails on LZMA decompression with this erorr:

rom_stream: 0xffc00000 - 0xfffe7fff
Uncompressing to RAM 0x0100000
Incorrect stream properties
Decoder scratchpad too small!
Decoding error = 1
Unexpected Exeption: 6@10:04000408 - Halting

After looking at the code, with my "little" programming experiences, i found out, that the error results from the function LzmaDecodeProperties and is caused by the value prop0 as it seems to me. I added a printk_warning of prop0 which results in the compilled images in a value of 255, where the code needs it smaller than 9 * 5 * 5, which would be 225.

Here is the code which is interesting for my investigations:
int LzmaDecodeProperties(CLzmaProperties *propsRes, const unsigned char *propsData, int size)
{
  unsigned char prop0;
  if (size < LZMA_PROPERTIES_SIZE)
    return LZMA_RESULT_DATA_ERROR;
  prop0 = propsData[0];		//at that point on trying to boot the image the prop0 value is 255
  if (prop0 >= (9 * 5 * 5))
    return LZMA_RESULT_DATA_ERROR;
  {
    for (propsRes->pb = 0; prop0 >= (9 * 5); propsRes->pb++, prop0 -= (9 * 5));
    for (propsRes->lp = 0; prop0 >= 9; propsRes->lp++, prop0 -= 9);
    propsRes->lc = prop0;
    /*
    unsigned char remainder = (unsigned char)(prop0 / 9);
    propsRes->lc = prop0 % 9;
    propsRes->pb = remainder / 5;
    propsRes->lp = remainder % 5;
    */
  }
  return LZMA_RESULT_OK;
}

Has anyone of you an idea why the lzma decompression fails, or what could be done against that? 
What i tried until now is to increase the "scratchpad" in lzma.c, but that didn't help and was just guessed. The error is the same if i try to build coreboot with the same changes, and just für 32bit.

Kind regards,
Harald Gutmann

[Carl-Daniel Hailfinger]

On 23.05.2008 20:05, Harald Gutmann wrote:
> Hello,
>
> as i had some time in the past week i tried to get coreboot running on the m57sli mainboard, but i failed once more. i created the romimage with buildrom-devel, and did some changes to different values.
>
> First here are all my modifications to the svn tree:
> buildrom-devel: nothing special, just add a kernel-config for 64bit.
> http://phpfi.com/319153
>
> cooreboot v2: change the ROM_SIZE to 4MB and increase the value for ROM_IMAGE_SIZE, as the ld process fails otherwise with the following error: 
> build-error: http://phpfi.com/319154
> changes to the coreboot svn-tree: http://phpfi.com/319151
>
> Here is the buildrom-devel .config file:
> http://phpfi.com/319150
>
> The result on that changes is an 4MB large rom-file, which boots up, but fails on LZMA decompression with this erorr:
>
> rom_stream: 0xffc00000 - 0xfffe7fff
> Uncompressing to RAM 0x0100000
> Incorrect stream properties
> Decoder scratchpad too small!

Try this:
Report actual and wanted LZMA decompression scratchpad size:
Signed-off-by: Carl-Daniel Hailfinger

Index: LinuxBIOSv2-stuff/src/lib/lzma.c
===================================================================
--- LinuxBIOSv2-stuff/src/lib/lzma.c	(Revision 3348)
+++ LinuxBIOSv2-stuff/src/lib/lzma.c	(Arbeitskopie)
@@ -12,6 +12,7 @@

#include "lzmadecode.c"

+#define LZMA_SCRATCHPAD_SIZE 15980

static unsigned long ulzma(unsigned char * src, unsigned char * dst)
 {
@@ -22,7 +23,7 @@
    int res;
    CLzmaDecoderState state;
    SizeT mallocneeds;
-	unsigned char scratchpad[15980];
+	unsigned char scratchpad[LZMA_SCRATCHPAD_SIZE];

memcpy(properties, src, LZMA_PROPERTIES_SIZE);
    outSize = *(UInt32 *)(src + LZMA_PROPERTIES_SIZE);
@@ -30,8 +31,9 @@
    	printk_warning("Incorrect stream properties\n");
    }
    mallocneeds = (LzmaGetNumProbs(&state.Properties) * sizeof(CProb));
-	if (mallocneeds > 15980) {
-		printk_warning("Decoder scratchpad too small!\n");
+	if (mallocneeds > LZMA_SCRATCHPAD_SIZE) {
+		printk_warning("Decoder scratchpad too small, have %i, need %i!\n",
+				LZMA_SCRATCHPAD_SIZE, mallocneeds);
    }
    state.Probs = (CProb *)scratchpad;
    res = LzmaDecode(&state, src + LZMA_PROPERTIES_SIZE + 8, (SizeT)0xffffffff, &inProcessed,

Gigabyte M57SLI - 4MB Chip - LAB doesn't boot like expected (was: LZMA Error)

[Harald Gutmann]

Am Freitag, 23. Mai 2008 20:23:11 schrieb Carl-Daniel Hailfinger:
> Try this:
> Report actual and wanted LZMA decompression scratchpad size:
> Signed-off-by: Carl-Daniel Hailfinger

The patch worked, i had to set the decoder scratchpad size to 50335340, which 
seems quite much to me, but there was no more error on "Uncompressing to 
RAM".

Acked-by: Harald Gutmann 
To add that also into the coreboot v2 reprository, and not just in v3.

But booting with LAB didn't work, the last lines which i get for now are:
"rom_stream: 0xffc00000 - 0xfffe7fff
Uncompressing to RAM 0x0100000"

Maybe, as i set the scratchpad size that high, it takes really long to 
decompress the image to the RAM. I waited about 2 minutes and nothing more 
happened, i think that should be enaugh time to decompress 4MB into the RAM.

Any idea what is wrong with my image, or what could be done to get debug 
informations?
> Index: LinuxBIOSv2-stuff/src/lib/lzma.c
>
> --- LinuxBIOSv2-stuff/src/lib/lzma.c	(Revision 3348)
> +++ LinuxBIOSv2-stuff/src/lib/lzma.c	(Arbeitskopie)
> @@ -12,6 +12,7 @@
>
> #include "lzmadecode.c"
>
> +#define LZMA_SCRATCHPAD_SIZE 15980
>
> static unsigned long ulzma(unsigned char * src, unsigned char * dst)
>  {
> @@ -22,7 +23,7 @@
>    int res;
>    CLzmaDecoderState state;
>    SizeT mallocneeds;
> unsigned char scratchpad[15980];
>
> unsigned char scratchpad[LZMA_SCRATCHPAD_SIZE];
>
> memcpy(properties, src, LZMA_PROPERTIES_SIZE);
> outSize = *(UInt32 *)(src + LZMA_PROPERTIES_SIZE);
>
> @@ -30,8 +31,9 @@
>    	printk_warning("Incorrect stream properties\n");
>    }
>    mallocneeds = (LzmaGetNumProbs(&state.Properties) * sizeof(CProb));
> if (mallocneeds > 15980) {
> printk_warning("Decoder scratchpad too small!\n");
> if (mallocneeds > LZMA_SCRATCHPAD_SIZE) {
> printk_warning("Decoder scratchpad too small, have %i, need %i!\n",
> 		LZMA_SCRATCHPAD_SIZE, mallocneeds);
> }
> state.Probs = (CProb *)scratchpad;
> res = LzmaDecode(&state, src + LZMA_PROPERTIES_SIZE + 8,
>
> (SizeT)0xffffffff, &inProcessed,

Gigabyte M57SLI - 4MB Chip - LAB doesn't boot like expected (was: LZMA Error)

[Peter Stuge]

On Sat, May 24, 2008 at 01:00:32PM +0200, Harald Gutmann wrote:
> The patch worked, i had to set the decoder scratchpad size to
> 50335340, which seems quite much to me,
>
> Acked-by: Harald Gutmann

NAK.
> But booting with LAB didn't work, the last lines which i get for
> now are:

I think that your payload has not been properly compressed.

AFAIK there is no way for the LZMA decompressor to validate the
compressed blob. :\

I've seen the same error message.

//Peter

Gigabyte M57SLI - 4MB Chip - LAB doesn't boot like expected

[Carl-Daniel Hailfinger]

On 24.05.2008 14:13, Peter Stuge wrote:
> On Sat, May 24, 2008 at 01:00:32PM +0200, Harald Gutmann wrote:
> > The patch worked, i had to set the decoder scratchpad size to
> > 50335340, which seems quite much to me,
> >
> > Acked-by: Harald Gutmann
>
> NAK.

Did you NAK my patch or the scratchpad size increase?
> > But booting with LAB didn't work, the last lines which i get for
> > now are:
>
> I think that your payload has not been properly compressed.
>
> AFAIK there is no way for the LZMA decompressor to validate the
> compressed blob. :\

There is, sort of. It will need the return type change I wrote about
earlier.

Regards,
Carl-Daniel

Gigabyte M57SLI - 4MB Chip - LAB doesn't boot like expected

[Harald Gutmann]

Am Samstag, 24. Mai 2008 17:25:18 schrieb Carl-Daniel Hailfinger:
> On 24.05.2008 14:13, Peter Stuge wrote:
> > On Sat, May 24, 2008 at 01:00:32PM +0200, Harald Gutmann wrote:
> > > The patch worked, i had to set the decoder scratchpad size to
> > > 50335340, which seems quite much to me,
> > >
> > > Acked-by: Harald Gutmann
> >
> > NAK.
>
> Did you NAK my patch or the scratchpad size increase?

Just to clarify i Acked Carl's Patch, not the size. The patch ist just for 
more debug information.
> There is, sort of. It will need the return type change I wrote about
> earlier.
>
> Regards,
> Carl-Daniel

Regards,
Harald

Gigabyte M57SLI - 4MB Chip - LAB doesn't boot like expected

[Carl-Daniel Hailfinger]

On 24.05.2008 13:00, Harald Gutmann wrote:
> Am Freitag, 23. Mai 2008 20:23:11 schrieb Carl-Daniel Hailfinger:
> > Try this:
> > Report actual and wanted LZMA decompression scratchpad size:
> > Signed-off-by: Carl-Daniel Hailfinger
>
> The patch worked, i had to set the decoder scratchpad size to 50335340, which 
> seems quite much to me, but there was no more error on "Uncompressing to 
> RAM".

The maximum scratchpad size right now is ~512k. Anything above that will
corrupt memory.
> Acked-by: Harald Gutmann 
> To add that also into the coreboot v2 reprository, and not just in v3.
>
> But booting with LAB didn't work, the last lines which i get for now are:
> "rom_stream: 0xffc00000 - 0xfffe7fff
> Uncompressing to RAM 0x0100000"
>
> Maybe, as i set the scratchpad size that high, it takes really long to 
> decompress the image to the RAM. I waited about 2 minutes and nothing more 
> happened, i think that should be enaugh time to decompress 4MB into the RAM.
>
> Any idea what is wrong with my image, or what could be done to get debug 
> informations?

The scratchpad has to fit in a special area below 1 MB. Considering
various other constraints, the maximum size is probably around 512k. A
bigger scratchpad will clobber interrupt vectors and wrap around to the
top of the 4 GB address space. The decompressor will then write to the
area occupied by ROM (writes discarded) and non-RAM areas (writes
discarded). That's a bad thing.

If a compressed payload needs more than 512k scratchpad, the payload is
most likely corrupt.

Regards,
Carl-Daniel

Gigabyte M57SLI - 4MB Chip - LAB doesn't boot like expected

[Harald Gutmann]

Am Samstag, 24. Mai 2008 14:22:43 schrieb Carl-Daniel Hailfinger:
> On 24.05.2008 13:00, Harald Gutmann wrote:
> > Am Freitag, 23. Mai 2008 20:23:11 schrieb Carl-Daniel Hailfinger:
> > > Try this:
> > > Report actual and wanted LZMA decompression scratchpad size:
> > > Signed-off-by: Carl-Daniel Hailfinger
> >
> > The patch worked, i had to set the decoder scratchpad size to 50335340,
> > which seems quite much to me, but there was no more error on
> > "Uncompressing to RAM".
>
> The maximum scratchpad size right now is ~512k. Anything above that will
> corrupt memory.

That is a good reason why it doesn't work here.
> > Acked-by: Harald Gutmann 
> > To add that also into the coreboot v2 reprository, and not just in v3.
> >
> > But booting with LAB didn't work, the last lines which i get for now are:
> > "rom_stream: 0xffc00000 - 0xfffe7fff
> > Uncompressing to RAM 0x0100000"
> >
> > Maybe, as i set the scratchpad size that high, it takes really long to
> > decompress the image to the RAM. I waited about 2 minutes and nothing
> > more happened, i think that should be enaugh time to decompress 4MB into
> > the RAM.
> >
> > Any idea what is wrong with my image, or what could be done to get debug
> > informations?
>
> The scratchpad has to fit in a special area below 1 MB. Considering
> various other constraints, the maximum size is probably around 512k. A
> bigger scratchpad will clobber interrupt vectors and wrap around to the
> top of the 4 GB address space. The decompressor will then write to the
> area occupied by ROM (writes discarded) and non-RAM areas (writes
> discarded). That's a bad thing.
>
> If a compressed payload needs more than 512k scratchpad, the payload is
> most likely corrupt.

how can i check if the payload is corrupt or not?
the uncompressed payload, the compressed one and an manually uncompressed (
lzma-utils from http://tukaani.org/lzma/) are included here:
http://rapidshare.com/files/117291876/payloads.tar.bz2.html
> Regards,
> Carl-Daniel

Regards,
Harald

Gigabyte M57SLI - 4MB Chip - LAB doesn't boot like expected

[Carl-Daniel Hailfinger]

On 24.05.2008 17:34, Harald Gutmann wrote:
> Am Samstag, 24. Mai 2008 14:22:43 schrieb Carl-Daniel Hailfinger:
> > On 24.05.2008 13:00, Harald Gutmann wrote:
> > > Any idea what is wrong with my image, or what could be done to get debug
> > > informations?
> >
> > The scratchpad has to fit in a special area below 1 MB. Considering
> > various other constraints, the maximum size is probably around 512k. A
> > bigger scratchpad will clobber interrupt vectors and wrap around to the
> > top of the 4 GB address space. The decompressor will then write to the
> > area occupied by ROM (writes discarded) and non-RAM areas (writes
> > discarded). That's a bad thing.
> >
> > If a compressed payload needs more than 512k scratchpad, the payload is
> > most likely corrupt.
>
> how can i check if the payload is corrupt or not?
> the uncompressed payload, the compressed one and an manually uncompressed (
> lzma-utils from http://tukaani.org/lzma/) are included here:
> http://rapidshare.com/files/117291876/payloads.tar.bz2.html

Don't use the tukaani.org lzma-utils. They have a different header
format and our decompression will choke on it.

Regards,
Carl-Daniel

Gigabyte M57SLI - 4MB Chip - LAB doesn't boot like expected

[Harald Gutmann]

Am Samstag, 24. Mai 2008 19:14:59 schrieb Carl-Daniel Hailfinger:
> On 24.05.2008 17:34, Harald Gutmann wrote:
> > how can i check if the payload is corrupt or not?
> > the uncompressed payload, the compressed one and an manually uncompressed
> > ( lzma-utils from http://tukaani.org/lzma/) are included here:
> > http://rapidshare.com/files/117291876/payloads.tar.bz2.html
>
> Don't use the tukaani.org lzma-utils. They have a different header
> format and our decompression will choke on it.

I just used the utils to decompress the compressed payload, and diffed it 
against the uncompressed which is generated from buildrom-devel.

I didn't use those tools to create a coreboot rom file, i just used 
buildrom-devel and did the changes which i posted in the start-mail of that 
thread.

But is there any method to verify the payload if it would work?
> Regards,
> Carl-Daniel

Regards,
Harald

Gigabyte M57SLI - 4MB Chip - LAB doesn't boot like expected

[Carl-Daniel Hailfinger]

On 24.05.2008 19:31, Harald Gutmann wrote:
> Am Samstag, 24. Mai 2008 19:14:59 schrieb Carl-Daniel Hailfinger:
> > On 24.05.2008 17:34, Harald Gutmann wrote:
> > > how can i check if the payload is corrupt or not?
> > > the uncompressed payload, the compressed one and an manually uncompressed
> > > ( lzma-utils from http://tukaani.org/lzma/) are included here:
> > > http://rapidshare.com/files/117291876/payloads.tar.bz2.html
> >
> > Don't use the tukaani.org lzma-utils. They have a different header
> > format and our decompression will choke on it.
>
> I just used the utils to decompress the compressed payload, and diffed it 
> against the uncompressed which is generated from buildrom-devel.
>
> I didn't use those tools to create a coreboot rom file, i just used 
> buildrom-devel and did the changes which i posted in the start-mail of that 
> thread.

Very strange. Can you try the compressed payload I uploaded to
http://rapidshare.de/files/39510268/lab-payload.elf.correctlzma.html and
report back?
> But is there any method to verify the payload if it would work?

I want to write such a tool, but this will need more time.

Regards,
Carl-Daniel

Gigabyte M57SLI - 4MB Chip - LAB doesn't boot like expected

[Harald Gutmann]

Am Samstag, 24. Mai 2008 20:46:49 schrieb Carl-Daniel Hailfinger:
> On 24.05.2008 19:31, Harald Gutmann wrote:
> > Am Samstag, 24. Mai 2008 19:14:59 schrieb Carl-Daniel Hailfinger:
> > On 24.05.2008 17:34, Harald Gutmann wrote:
> > I just used the utils to decompress the compressed payload, and diffed it
> > against the uncompressed which is generated from buildrom-devel.
> >
> > I didn't use those tools to create a coreboot rom file, i just used
> > buildrom-devel and did the changes which i posted in the start-mail of
> > that thread.
>
> Very strange. Can you try the compressed payload I uploaded to
> http://rapidshare.de/files/39510268/lab-payload.elf.correctlzma.html and
> report back?

Yes, that's strange, and doesn't work.

I'll try that file tomorrow, is it a patched file from my original, or is it 
something else?
> > But is there any method to verify the payload if it would work?
>
> I want to write such a tool, but this will need more time.

Okay, but a tool which can do that would be really fine.
> Regards,
> Carl-Daniel

Regards,
Harald

Gigabyte M57SLI - 4MB Chip - LAB doesn't boot like expected

[Carl-Daniel Hailfinger]

On 24.05.2008 21:39, Harald Gutmann wrote:
> Am Samstag, 24. Mai 2008 20:46:49 schrieb Carl-Daniel Hailfinger:
> > On 24.05.2008 19:31, Harald Gutmann wrote:
> > > Am Samstag, 24. Mai 2008 19:14:59 schrieb Carl-Daniel Hailfinger:
> > > On 24.05.2008 17:34, Harald Gutmann wrote:
> > > I just used the utils to decompress the compressed payload, and diffed it
> > > against the uncompressed which is generated from buildrom-devel.
> > >
> > > I didn't use those tools to create a coreboot rom file, i just used
> > > buildrom-devel and did the changes which i posted in the start-mail of
> > > that thread.
> >
> > Very strange. Can you try the compressed payload I uploaded to
> > http://rapidshare.de/files/39510268/lab-payload.elf.correctlzma.html and
> > report back?
>
> Yes, that's strange, and doesn't work.
>
> I'll try that file tomorrow, is it a patched file from my original, or is it 
> something else?

Your original, but I compressed it with my lzma program in the coreboot
v3 tree.
> > > But is there any method to verify the payload if it would work?
> >
> > I want to write such a tool, but this will need more time.
>
> Okay, but a tool which can do that would be really fine.

Yes. Expect something in July. If you don't see anything then, please
remind me.

Regards,
Carl-Daniel

Gigabyte M57SLI - 4MB Chip - LAB doesn't boot like expected

[Harald Gutmann]

Am Samstag, 24. Mai 2008 20:46:49 schrieb Carl-Daniel Hailfinger:
> On 24.05.2008 19:31, Harald Gutmann wrote:
> > Am Samstag, 24. Mai 2008 19:14:59 schrieb Carl-Daniel Hailfinger:
> > > On 24.05.2008 17:34, Harald Gutmann wrote:
> > > > how can i check if the payload is corrupt or not?
> > > > the uncompressed payload, the compressed one and an manually
> > > > uncompressed ( lzma-utils from http://tukaani.org/lzma/) are included
> > > > here: http://rapidshare.com/files/117291876/payloads.tar.bz2.html
> > >
> > > Don't use the tukaani.org lzma-utils. They have a different header
> > > format and our decompression will choke on it.
> >
> > I just used the utils to decompress the compressed payload, and diffed it
> > against the uncompressed which is generated from buildrom-devel.
> >
> > I didn't use those tools to create a coreboot rom file, i just used
> > buildrom-devel and did the changes which i posted in the start-mail of
> > that thread.
>
> Very strange. Can you try the compressed payload I uploaded to
> http://rapidshare.de/files/39510268/lab-payload.elf.correctlzma.html and
> report back?

I tried it now to build an image with the playload from the link, but it has 
the same problem than i've with my coreboot.rom file.
LZMA Error on booting and the scratchpad-size reported with your previous 
patch is also the same like with the original rom-file from me.

Thanks anyway.

Is it possible to flash an rom-file with lower file-size than the chip has, 
and to boot from it? As this would work i'd try to generate a rom-file with 1 
or 2MB. My "problem" is, that i've just an 512kB Chip, and the 4MB one, and 
on 512kB there is too less space for LAB or linux as payload.
> Regards,
> Carl-Daniel

Regards,
Harald

Gigabyte M57SLI - 4MB Chip - LAB doesn't boot like expected

[Carl-Daniel Hailfinger]

On 26.05.2008 23:32, Harald Gutmann wrote:
> Am Samstag, 24. Mai 2008 20:46:49 schrieb Carl-Daniel Hailfinger:
> > On 24.05.2008 19:31, Harald Gutmann wrote:
> > > Am Samstag, 24. Mai 2008 19:14:59 schrieb Carl-Daniel Hailfinger:
> > > > On 24.05.2008 17:34, Harald Gutmann wrote:
> > > > > how can i check if the payload is corrupt or not?
> > > > > the uncompressed payload, the compressed one and an manually
> > > > > uncompressed ( lzma-utils from http://tukaani.org/lzma/) are included
> > > > > here: http://rapidshare.com/files/117291876/payloads.tar.bz2.html
> > > >
> > > > Don't use the tukaani.org lzma-utils. They have a different header
> > > > format and our decompression will choke on it.
> > >
> > > I just used the utils to decompress the compressed payload, and diffed it
> > > against the uncompressed which is generated from buildrom-devel.
> > >
> > > I didn't use those tools to create a coreboot rom file, i just used
> > > buildrom-devel and did the changes which i posted in the start-mail of
> > > that thread.
> >
> > Very strange. Can you try the compressed payload I uploaded to
> > http://rapidshare.de/files/39510268/lab-payload.elf.correctlzma.html and
> > report back?
>
> I tried it now to build an image with the playload from the link, but it has 
> the same problem than i've with my coreboot.rom file.

Thanks for testing.
> LZMA Error on booting and the scratchpad-size reported with your previous 
> patch is also the same like with the original rom-file from me.

I'll have to investigate that after LinuxTag. Most important would be a
runtime check for correct headers. The values you're seeing suggest a
possible problem with ROM mapping. I suspect it will go away if you use
an 1 MB image as described below.
> Is it possible to flash an rom-file with lower file-size than the chip has, 
> and to boot from it? As this would work i'd try to generate a rom-file with 1 
> or 2MB. My "problem" is, that i've just an 512kB Chip, and the 4MB one, and 
> on 512kB there is too less space for LAB or linux as payload.

Try creating a ROM file with 2 MB, then run
cat coreboot.rom coreboot.rom >final.rom
and flash final.rom. A ROM file with 1 MB would use the following:
cat coreboot.rom coreboot.rom coreboot.rom coreboot.rom >final.rom
That should work fine for the ROMsize!=flashsize problem.

Regards,
Carl-Daniel

Gigabyte M57SLI - 4MB Chip - LAB doesn't boot like expected

[Ward Vandewege]

On Tue, May 27, 2008 at 12:11:44AM +0200, Carl-Daniel Hailfinger wrote:
> Try creating a ROM file with 2 MB, then run
> cat coreboot.rom coreboot.rom >final.rom
> and flash final.rom. A ROM file with 1 MB would use the following:
> cat coreboot.rom coreboot.rom coreboot.rom coreboot.rom >final.rom
> That should work fine for the ROMsize!=flashsize problem.

Yeah. I do that all the time (usually to put an 512K image into a 1MB rom).

Thanks,
Ward.

Gigabyte M57SLI - 4MB Chip - LAB doesn't boot like expected

[Harald Gutmann]

Am Dienstag, 27. Mai 2008 00:11:44 schrieben Sie:
> On 26.05.2008 23:32, Harald Gutmann wrote:
> > Am Samstag, 24. Mai 2008 20:46:49 schrieb Carl-Daniel Hailfinger:
> > I tried it now to build an image with the playload from the link, but it
> > has the same problem than i've with my coreboot.rom file.
>
> Thanks for testing.
> > LZMA Error on booting and the scratchpad-size reported with your previous
> > patch is also the same like with the original rom-file from me.
>
> I'll have to investigate that after LinuxTag. Most important would be a
> runtime check for correct headers. The values you're seeing suggest a
> possible problem with ROM mapping. I suspect it will go away if you use
> an 1 MB image as described below.
> > Is it possible to flash an rom-file with lower file-size than the chip
> > has, and to boot from it? As this would work i'd try to generate a
> > rom-file with 1 or 2MB. My "problem" is, that i've just an 512kB Chip,
> > and the 4MB one, and on 512kB there is too less space for LAB or linux as
> > payload.
>
> Try creating a ROM file with 2 MB, then run
> cat coreboot.rom coreboot.rom >final.rom
> and flash final.rom. A ROM file with 1 MB would use the following:
> cat coreboot.rom coreboot.rom coreboot.rom coreboot.rom >final.rom
> That should work fine for the ROMsize!=flashsize problem.

Thanks for the fast answer, but i think that just the ROM-SIZE causes a 
problem somewhere.

At the moment i'm building a 2mb rom-file, and try if there is the same error 
with lzma, or if it works like expected.
> Regards,
> Carl-Daniel

Regars,
Harald

Gigabyte M57SLI - 4MB Chip - LAB doesn't boot like expected

[bari]

Harald Gutmann wrote:
> Am Samstag, 24. Mai 2008 20:46:49 schrieb Carl-Daniel Hailfinger:
> > On 24.05.2008 19:31, Harald Gutmann wrote:
> > > Am Samstag, 24. Mai 2008 19:14:59 schrieb Carl-Daniel Hailfinger:
> > > > On 24.05.2008 17:34, Harald Gutmann wrote:
> > > > > how can i check if the payload is corrupt or not?
> > > > > the uncompressed payload, the compressed one and an manually
> > > > > uncompressed ( lzma-utils from http://tukaani.org/lzma/) are included
> > > > > here: http://rapidshare.com/files/117291876/payloads.tar.bz2.html
> > > >
> > > > Don't use the tukaani.org lzma-utils. They have a different header
> > > > format and our decompression will choke on it.
> > >
> > > I just used the utils to decompress the compressed payload, and diffed it
> > > against the uncompressed which is generated from buildrom-devel.
> > >
> > > I didn't use those tools to create a coreboot rom file, i just used
> > > buildrom-devel and did the changes which i posted in the start-mail of
> > > that thread.
> >
> > Very strange. Can you try the compressed payload I uploaded to
> > http://rapidshare.de/files/39510268/lab-payload.elf.correctlzma.html and
> > report back?
>
> I tried it now to build an image with the playload from the link, but it has 
> the same problem than i've with my coreboot.rom file.
> LZMA Error on booting and the scratchpad-size reported with your previous 
> patch is also the same like with the original rom-file from me.
>
> Thanks anyway.
>
> Is it possible to flash an rom-file with lower file-size than the chip has, 
> and to boot from it? As this would work i'd try to generate a rom-file with 1 
> or 2MB. My "problem" is, that i've just an 512kB Chip, and the 4MB one, and 
> on 512kB there is too less space for LAB or linux as payload.

I've been using buildrom for the kernel+ initrd along with coreboot V2 
to build coreboot + LAB rom images without any issues.

Be sure to use the compressed elf lzma payload that buildrom generates  
lab-payload.elf.lzma  found in the deploy/ directory.

Your Options.lb in your targets/../... directory have to set properly as 
well. It is a bit confusing since the docs are not clear.

Below is what I have been using successfully:

## set option rom size for LAB without BOCHS or vgabios
option ROM_SIZE=1024*1024

option HAVE_OPTION_TABLE=1
option CONFIG_ROM_PAYLOAD=1
option HAVE_FALLBACK_BOOT=1

###
### Compute the location and size of where this firmware image
### (coreboot plus bootloader) will live in the boot rom chip.
###
option FALLBACK_SIZE=ROM_SIZE

## coreboot C code runs at this location in RAM
option _RAMBASE=0x00004000

#
###
### Compute the start location and size size of
### The coreboot bootloader.
###

#
# EPIA-CN
#
romimage "fallback"
    option USE_FALLBACK_IMAGE=1
    option ROM_IMAGE_SIZE=0x0cf00
#    option ROM_IMAGE_SIZE=0x20000
    option COREBOOT_EXTRA_VERSION=".0Fallback"
    option CONFIG_COMPRESSED_PAYLOAD_LZMA=1
    option CONFIG_PRECOMPRESSED_PAYLOAD=1
#    payload $(HOME)/filo-0.5/filo.elf
#    payload $(HOME)/payloads/memtest
    payload $(HOME)/payloads/lab-payload.elf.lzma
end

buildrom ./coreboot.rom ROM_SIZE "fallback"

-Bari

Gigabyte M57SLI - 4MB Chip - LAB doesn't boot like expected

[Torsten Duwe]

On Saturday 24 May 2008, Carl-Daniel Hailfinger wrote:
> Don't use the tukaani.org lzma-utils. They have a different header
> format and our decompression will choke on it.

Huh? They seem to work for me, sticking a Linux kernel into a 1MB ROM, though 
I still lack some initrd magic to avoid the "cannot mount root" panic, but it 
gets that far. Is there anything wrong with staying compatible to the 
official tools?

Gigabyte M57SLI - 4MB Chip - LAB doesn't boot like expected

[Carl-Daniel Hailfinger]

On 25.05.2008 23:29, Torsten Duwe wrote:
> On Saturday 24 May 2008, Carl-Daniel Hailfinger wrote:
> > Don't use the tukaani.org lzma-utils. They have a different header
> > format and our decompression will choke on it.
>
> Huh? They seem to work for me, sticking a Linux kernel into a 1MB ROM, though 
> I still lack some initrd magic to avoid the "cannot mount root" panic, but it 
> gets that far.

Strange. Maybe I misunderstood soemthing about the headers.
> Is there anything wrong with staying compatible to the 
> official tools?

Of course not. lzma-utils are a fork of the lzma utilities in the lzma
SDK. We have to decice whether we want to stay compatible with the SDK
(code state right now) or the fork (supported by your patch). Peronally,
I'd prefer to use the SDK and import the v3 in-tree lzma utilities
(which are identical to those in the SDK) in the v2 tree. That avoids
any current and future incompatibilities.

Regards,
Carl-Daniel