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 reinauer@chromium.org 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 rminnich@gmail.com 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