4f3bb801ed
This change started with tracking down a bug where the trampoline size was not being taken into account for sizing the output buffer leading to a heap corruption. I was having a hard time keeping track of what num_segments actually tracked as well as what parts were being placed in the output buffer. Here's my attempt at hopefully providing more clarity. This change doesn't crash when adding a bzImage: $ dd if=/dev/zero of=bb.bin bs=64 count=1 $ ./cbfstool tmp.rom create -s 4M -B bb.bin -m x86 -a 64 $ ./cbfstool tmp.rom add-payload -f ~/Downloads/bzImage -C "1" -n "fallback"/payload Change-Id: Ib1de1ddfec3c7102facffc5815c52b340fcdc628 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/5408 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-by: Marc Jones <marc.jones@se-eng.com> |
||
|---|---|---|
| .. | ||
| lzma | ||
| EXAMPLE | ||
| Makefile | ||
| Makefile.inc | ||
| cbfs-mkpayload.c | ||
| cbfs-mkstage.c | ||
| cbfs-payload-linux.c | ||
| cbfs.h | ||
| cbfs_image.c | ||
| cbfs_image.h | ||
| cbfstool.c | ||
| coff.h | ||
| common.c | ||
| common.h | ||
| compress.c | ||
| elf.h | ||
| elfheaders.c | ||
| elfparsing.h | ||
| fit.c | ||
| fit.h | ||
| fv.h | ||
| linux.h | ||
| linux_trampoline.c | ||
| rmodtool.c | ||
| rmodule.c | ||
| rmodule.h | ||
| swab.h | ||
| xdr.c | ||