the following patch was just integrated into master:
commit 636cc858bb6979cbd51abaa1d75842146b0c29f7
Author: Sol Boucher <solb(a)chromium.org>
Date: Fri Apr 3 09:13:04 2015 -0700
cbfstool: Make the add action choose an aligned entries capacity
This fixes an inconsistency between `cbfstool create` and `cbfstool add` that
was resulting in confusing claims about the amount of free space at the end of a
CBFS. Calls to `cbfstool add` check whether a file fits under a given empty file
entry by testing whether it would collide with the beginning of the *subsequent*
file header; thus, if a file's end is unaligned, its reported size will not
match the actual available capacity. Although deleted entries always end on an
alignment boundary because `cbfstool remove` expands them to fill the available
space, `cbfstool create` doesn't necessarily size a new entries region to result
in an empty entry with an aligned end.
This problem never resulted in clobbering important data because cbfstool would
blindly reserve 64B (or the selected alignment) of free space immediately after
the all-inclusive empty file entry. This change alters the way this reservation
is reported: only the overhang past the alignment is used as hidden padding, and
the empty entry's capacity is always reported such that it ends at an aligned
address.
Much of the time that went into this patch was spent building trust in the
trickery cbfstool employs to avoid explicitly tracking the image's total
capacity for entries, so below are two proofs of correctness to save others time
and discourage inadvertent breakage:
OBSERVATION (A): A check in cbfs_image_create() guarantees that an aligned CBFS
empty file header is small enough that it won't cross another aligned address.
OBSERVATION (B): In cbfs_image_create(), the initial empty entry is sized such
that its contents end on an aligned address.
THM. 1: Placing a new file within an empty entry located below an existing file
entry will never leave an aligned flash address containing neither the beginning
of a file header nor part of a file.
We can prove this by contradiction: assume a newly-added file neither fills to
the end of the preexisting empty entry nor leaves room for another aligned
empty header after it. Then the first aligned address after the end of the
newly-inserted file...
- CASE 1: ...already contains a preexisting file entry header.
+ Then that address contains a file header.
- CASE 2: ...does not already house a file entry header.
+ Then because CBFS content doesn't fall outside headers, the area between
there and the *next* aligned address after that is unused.
+ By (A), we can fit a file header without clobbering anything.
+ Then that address now contains a file header.
THM. 2: Placing a new file in an empty entry at the very end of the image such
that it fits, but leaves no room for a final header, is guaranteed not to change
the total amount of space for entries, even if that new file is later removed
from the CBFS.
Again, we use contradiction: assume that creating such a file causes a
permanent...
- CASE 1: ...increase in the amount of available space.
+ Then the combination of the inserted file, its header, and any padding
must have exceeded the empty entry in size enough for it to cross at
least one additional aligned address, since aligned addresses are how
the limit on an entry's capacity is determined.
+ But adding the file couldn't have caused us to write past any further
aligned addresses because they are the boundary's used when verifying
that sufficient capacity exists; furthermore, by (B), no entry can ever
terminate beyond where the initial empty entry did when the CBFS was
first created.
+ Then the creation of the file did not result in a space increase.
- CASE 2: ...decrease in the amount of available space.
+ Then the end of the new file entry crosses at least one fewer aligned
address than did the empty file entry.
+ Then by (A), there is room to place a new file entry that describes the
remaining available space at the first available aligned address.
+ Then there is now a new record showing the same amount of available space.
+ Then the creation of the file did not result in a space decrease.
BUG=chromium:473726
TEST=Had the following conversation with cbfstool:
$ ./cbfstool test.image create -s 0x100000 -m arm
Created CBFS image (capacity = 1048408 bytes)
$ ./cbfstool test.image print
test.image: 1024 kB, bootblocksize 0, romsize 1048576, offset 0x40
alignment: 64 bytes, architecture: arm
Name Offset Type Size
(empty) 0x40 null 1048408
$ dd if=/dev/zero of=toobigmed.bin bs=1048409 count=1
1+0 records in
1+0 records out
1048409 bytes (1.0 MB) copied, 0.0057865 s, 181 MB/s
$ ./cbfstool test.image add -t 0x50 -f toobigmed.bin -n toobig
E: Could not add [toobigmed.bin, 1048409 bytes (1023 KB)@0x0]; too big?
E: Failed to add 'toobigmed.bin' into ROM image.
$ truncate -s -1 toobigmed.bin
$ ./cbfstool test.image add -t 0x50 -f toobigmed.bin -n toobig
$ ./cbfstool test.image print
test.image: 1024 kB, bootblocksize 0, romsize 1048576, offset 0x40
alignment: 64 bytes, architecture: arm
Name Offset Type Size
toobig 0x40 raw 1048408
$ ./cbfstool test.image remove
-n toobig
$ ./cbfstool test.image print
test.image: 1024 kB, bootblocksize 0, romsize 1048576, offset 0x40
alignment: 64 bytes, architecture: arm
Name Offset Type Size
(empty) 0x40 deleted 1048408
$ ./cbfstool test.image print
test.image: 1024 kB, bootblocksize 0, romsize 1048576, offset 0x40
alignment: 64 bytes, architecture: arm
Name Offset Type Size
(empty) 0x40 deleted 1048408
BRANCH=None
Change-Id: I118743e37469ef0226970decc900db5d9b92c5df
Signed-off-by: Sol Boucher <solb(a)chromium.org>
Original-Commit-Id: e317ddca14bc36bc36e6406b758378c88e9ae04e
Original-Change-Id: I294ee489b4918646c359b06aa1581918f2d8badc
Original-Signed-off-by: Sol Boucher <solb(a)chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/263962
Original-Reviewed-by: Hung-Te Lin <hungte(a)chromium.org>
Original-Reviewed-by: Stefan Reinauer <reinauer(a)google.com>
Reviewed-on: http://review.coreboot.org/9939
Tested-by: build bot (Jenkins)
See http://review.coreboot.org/9939 for details.
-gerrit
Dave Frodin (dave.frodin(a)se-eng.com) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/10144
-gerrit
commit f744130e3e82602ddbabc33eef9222bba41d4246
Author: Dave Frodin <dave.frodin(a)se-eng.com>
Date: Fri May 8 07:20:48 2015 -0600
Add a function to do indexed I/O reads/writes
There are multiple superio functions defined to
do indexed I/O reads and writes. These generic
functions will replace them in a follow on patch.
Change-Id: I491a40e51d304496c5ec45a8171370b281669048
Signed-off-by: Dave Frodin <dave.frodin(a)se-eng.com>
---
src/arch/x86/lib/Makefile.inc | 2 ++
src/arch/x86/lib/io_index.c | 33 +++++++++++++++++++++++++++++++++
src/include/io_index.h | 21 +++++++++++++++++++++
3 files changed, 56 insertions(+)
diff --git a/src/arch/x86/lib/Makefile.inc b/src/arch/x86/lib/Makefile.inc
index c7e8b62..ea1430d 100644
--- a/src/arch/x86/lib/Makefile.inc
+++ b/src/arch/x86/lib/Makefile.inc
@@ -2,6 +2,7 @@
ifeq ($(CONFIG_ARCH_ROMSTAGE_X86_32),y)
romstage-y += cbfs_and_run.c
+romstage-y += io_index.c
romstage-y += memset.c
romstage-y += memcpy.c
romstage-y += memmove.c
@@ -13,6 +14,7 @@ ifeq ($(CONFIG_ARCH_RAMSTAGE_X86_32),y)
ramstage-y += c_start.S
ramstage-y += cpu.c
+ramstage-y += io_index.c
ramstage-y += pci_ops_conf1.c
ramstage-$(CONFIG_MMCONF_SUPPORT) += pci_ops_mmconf.c
ramstage-y += exception.c
diff --git a/src/arch/x86/lib/io_index.c b/src/arch/x86/lib/io_index.c
new file mode 100644
index 0000000..a8e4b2d
--- /dev/null
+++ b/src/arch/x86/lib/io_index.c
@@ -0,0 +1,33 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2015 Sage Electronic Engineering, LLC.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include <arch/io.h>
+#include <io_index.h>
+
+u8 io_read_index(u16 port, u8 reg)
+{
+ outb(reg, port);
+ return inb(port + 1);
+}
+
+void io_write_index(u16 port, u8 reg, u8 value)
+{
+ outb(reg, port);
+ outb(value, port + 1);
+}
diff --git a/src/include/io_index.h b/src/include/io_index.h
new file mode 100644
index 0000000..7054dd9
--- /dev/null
+++ b/src/include/io_index.h
@@ -0,0 +1,21 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2015 Sage Electronic Engineering, LLC.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+u8 io_read_index(u16 port, u8 reg);
+void io_write_index(u16 port, u8 reg, u8 value);
the following patch was just integrated into master:
commit b11be321a895aa70adeaa8cb92fcfcd5dcbd748c
Author: Patrick Georgi <pgeorgi(a)chromium.org>
Date: Thu May 7 22:27:01 2015 +0200
build system: use platform specific ar(1) for libverstage
Shouldn't be necessary, doesn't hurt either.
Change-Id: I4fa5cc2931523b5beac5ea5126e3e8b841446017
Signed-off-by: Patrick Georgi <pgeorgi(a)chromium.org>
Reviewed-on: http://review.coreboot.org/10140
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin(a)chromium.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org>
Reviewed-by: Paul Menzel <paulepanter(a)users.sourceforge.net>
See http://review.coreboot.org/10140 for details.
-gerrit