Am Samstag, den 06.04.2013, 15:36 +0200 schrieb Patrick Georgi: > Am 06.04.2013 10:59, schrieb Paul Menzel: > > Remove the LZMA compressed payload and adding the payload manually > > (uncompressed) and rewriting the image, the GRUB payload is started > > without problems. > > [...] > > > > So I would claim, the payload is functional. > Can you try if the payload is bootable with a cbfstool built after > reverting aa3f7ba36ebe3a933aa664f826382f60b31e86f1?
commit aa3f7ba36ebe3a933aa664f826382f60b31e86f1
Author: Stefan Reinauer <[email protected]>
Date: Thu Mar 28 16:51:45 2013 -0700
cbfstool: Replace C++ code with C code
Reviewed-on: http://review.coreboot.org/3010
I reverted this commit on top of
commit 161ccc76ea0f8941a34c5bed323cc9ba1fe0221d
Author: Ronald G. Minnich <[email protected]>
Date: Fri Apr 5 13:35:29 2013 -0700
exynos5250: add a chip.h file for the display register
settings
Reviewed-on: http://review.coreboot.org/3031
and rebuild the whole port and a LZMA compressed GRUB payload was loaded
without any problems. GNUtoo in #coreboot also reported problems with a
LZMA compressed GRUB payload with latest master including the LZMA
rewrite.
> It's possible that this changes cbfstool behaviour for lzma compression
> in some edge cases.
In #coreboot on irc.freenode.net, phcoder wrote the following.
• possible LZMA bug trigger is that GRUB uses 2 chunks
• I suppose that some variables aren't reset properly between chunks
Thanks,
Paul
signature.asc
Description: This is a digitally signed message part
-- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
