As per discussion with lawyers[tm], it's not a good idea to
shorten the license header too much - not for legal reasons
but because there are tools that look for them, and giving
them a standard pattern simplifies things.
However, we got confirmation that we don't have to update
every file ever added to coreboot whenever the FSF gets a
new lease, but can drop the address instead.
util/kconfig is excluded because that's imported code that
we may want to synchronize every now and then.
$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, *MA[, ]*02110-1301[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 59 Temple Place[-, ]*Suite 330, Boston, MA *02111-1307[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.:Foundation, Inc.:" {} +
$ find * -type f
-a \! -name \*.patch \
-a \! -name \*_shipped \
-a \! -name LICENSE_GPL \
-a \! -name LGPL.txt \
-a \! -name COPYING \
-a \! -name DISCLAIMER \
-exec sed -i "/Foundation, Inc./ N;s:Foundation, Inc.* USA\.* *:Foundation, Inc. :;s:Foundation, Inc. $:Foundation, Inc.:" {} +
Change-Id: Icc968a5a5f3a5df8d32b940f9cdb35350654bef9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9233
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Be more conservative and only add VGA devices' prefetchable
resources as write-combining in the address space. Previously
all prefetchable memory was added as a write-combining memory
type. Some hardware incorrectly advertises its BAR as
prefetchable when it shouldn't be.
A new memranges_add_resources_filter() function is added
to provide additional filtering on device and resource.
Change-Id: I3fc55b90d8c5b694c5aa9e2f34db1b4ef845ce10
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5169
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Tested-by: build bot (Jenkins)
The memranges_update_tag() function replaces all instances
that are tagged with old_tag and update to new_tag. This
can be helpful in the MTRR code by adjusting the address
space if certain memory types cause the MTRR usage to
become too large.
Change-Id: Ie5c405204de2fdd9fd1dd5d6190b223925d6d318
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5150
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Two convenience functions are added to operate on a range_entry:
- range_entry_update_tag() - update the entry's tag
- memranges_next_entry() - get the next entry after the one provide
These functions will be used by a follow on patch to the MTRR code
to allow hole punching in WB region when the default MTRR type is
UC.
Change-Id: I3c2be19c8ea1bbbdf7736c867e4a2aa82df2d611
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2924
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The memrange infrastructure allows for keeping track of the
machine's physical address space. Each memory_range entry in
a memory_ranges structure can be tagged with an arbitrary value.
It supports merging and deleting ranges as well as filling in
holes in the address space with a particular tag.
The memrange infrastructure will serve as a shared implementation
for address tracking by the MTRR and coreboot mem table code.
Change-Id: Id5bea9d2a419114fca55c59af0fdca063551110e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2888
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Patrick Georgi