some software wants to do an LDN access (trivial).
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4374 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
cbfstool-clean target to the Makefile.
Signed-off-by: Myles Watson <mylesgw@gmail.com>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4371 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
didn't look into it enough to know why fssize is 32 bytes larger than the
offset. There may be another bug here. Maybe something with the CBFS header
not being included or excluded from the calculation?
Anyway, this patch fixes it for all cases size > 32.
I also changed the error message so that it doesn't look like the ROM is full
just because it can't find room for a file.
Signed-off-by: Myles Watson <mylesgw@gmail.com>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4370 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
[base address] parameter is supplied on the command line... This patch fixes
random segfaults when using 'cbfstool add'.
Signed-off-by: Ward Vandewege <ward@gnu.org>
Acked-by: Myles Watson <mylesgw@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4363 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
cbfs files at fixed addresses.
I call this transitional as the approach I am taking is to add
capability to cbfstool but not change code in a way that will break
existing usages. Later, once we're sure nothing has broken, we can start to
smooth the edges.
Right now, fixed address file are only supported via the add command.
There is one additional command syntax, so, example:
cbfstool add rom romstrap optionrom 0xffffd000
Will add the file to that fix location for a romstrap.
The assumption is that the ROM is based at the end of a 32-bit address
space. As you can see from the code, that assumption can easily be
over-ridden, if we ever need to, with a command option.
Here is one example output result.
rminnich@xcpu2:~/src/bios/coreboot-v2/util/cbfstool$ ./cbfstool x.cbf print
x.cbf: 1024 kB, bootblocksize 32768, romsize 1048576, offset 0x0
Alignment: 16 bytes
Name Offset Type Size
h 0x0 optionrom 251
0x130 free 917120
h3 0xdffe0 optionrom 251
0xe0110 free 97960
The way this is implemented is pretty simple. I introduce a new
operator, split, that splits an unallocated area into two unallocated
areas. Then, allocation merely becomes a matter of 0, 1, or 2 splits:
0 split -- the free area is the exact fit
1 splits -- need to split some off the front or back
2 splits -- need to split off BOTH the front and back
I think you'll be able to see what I've done. I call this transitional
because, in the end state, we only need one allocate function; for now
I've left two in, to make sure I don't break compatibilty.
Why I like this better than ldscript approach: I like having the
ROMSTRAP located by cbfs, not linker scripts. For one thing, it makes
romstrap visible as a first class object. I think I would have latched
onto a problem I was having much more quickly had I remembered the
ROMSTRAP. It gets lost in the linker scripts.
At this point, we should be able to start removing special ROMSTRAP location
code from linker scripts.
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Acked-by: Patrick Georgi <patrick.georgi@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4351 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
instead of coreboot.strip. That fixes the normal
image because the calculations for its offset in
the ROM match reality again.
This requires changes in CBFS configurations to
minimize the bootblock size. These are also done
for CBFS boards.
Other than this a couple of minor fixes are in this
patch:
- make asus/m2v-mx_se build with abuild with a
crosscompiler
- move CONFIG_CBFS for hp/dl145_g3 to Options.lb
as it's done everywhere else
- change the default config of abuild to not
provide ROM_IMAGE_SIZE values for the images
in a CBFS configuration
- change abuild's crosscompile autodetection to
not try to use "i386-elf-i386-elf-gcc" (which
is bogus)
Except for the latter two abuild changes (both
in util/abuild/abuild), they're available as
patch set on the mailing list in a mail from
2009-06-05 titled
[PATCH]es to get normal image to work again with CBFS
The changes in util/abuild/abuild are trivial and
abuild tested.
As discussed on the list,
targets/hp/dl145_g3/Config-abuild.lb is
deleted, now that Config.lb works again.
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4344 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
This reverts commit eb7bb49eb5b48c39baf7a256b7c74e23e3da5660.
Stepan pointed out that "s" means string, which makes the following statement
in this commit message invalid: "Since we either have reserved space (which
we shouldn't do anything with in these two functions), an enum or a
hexadecimal value, unsigned int seemed like the way to go."
Signed-off-by: Luc Verhaegen <libv@skynet.be>
Acked-by: Luc Verhaegen <libv@skynet.be>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4335 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
To ease some of my debugging pain on the unichrome, i decided i needed to
move FB size selection into cmos, so i could test a size and then reset it
to the default after loading this value so that the next reboot uses the
(working) default again. This meant implementing set_option in parallel to
get_option.
get_option was then found to have inversed argument ordering (like outb) and
passing char * and then depending on the cmos layout length, which made me
feel quite uncomfortable. Since we either have reserved space (which we
shouldn't do anything with in these two functions), an enum or a
hexadecimal value, unsigned int seemed like the way to go. So all users of
get_option now have their arguments inversed and switched from using ints
to unsigned ints now.
The way get_cmos_value was implemented forced us to not overlap byte and to
have multibyte values be byte aligned. This logic is now adapted to do a
full uint32_t read (when needed) at any offset and any length up to 32, and
the shifting all happens inside an uint32_t as well. set_cmos_value was
implemented similarly. Both routines have been extensively tested in a
quick separate little program as it is not easy to get this stuff right.
build_opt_tbl.c was altered to function correctly within these new
parameters. The enum value retrieval has been changed strol(..., NULL, 10)
to stroul(..., NULL, 0), so that we not only are able to use unsigned ints
now but so that we also interprete hex values correctly. The 32bit limit
gets imposed on all entries not marked reserved, an unused "user_data" field
that appeared in a lot of cmos.layouts has been changed to reserved as well.
Signed-off-by: Luc Verhaegen <libv@skynet.be>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4332 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
with an error code now.
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4329 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
reduce the size of the bootblock (done for kontron/986lcd-m)
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4315 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
- Replace $(PWD) with $(CURDIR) in Makefiles. I don't know why
the Solaris version behaves differently, but CURDIR is a safe
choice on gnu make (and we require gnu make already)
- Use tail -1 instead of tail -n1 in a file that already relies on
tail -1 support in another place
- Use tail -1 as alternative to tail -n1 in another place
- Use #define for ulong_t in romcc, as that name is used on Solaris
- Avoid fprinting a null pointer. The standard doesn't mandate that
this is a special case, and Solaris doesn't implement it that way.
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4305 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
* remove some dead code
* fix indentation
* comment in some destructors and fix some other warnings
* use HOSTCC instead of CC (not all the way cosmetic, but very simple)
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4299 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
header template, as people keep forgetting them.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4296 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
It makes the write part of flashrom dramatically faster with small
payloads like filo; and it also eliminates unnecessary wear on flash
by not writing zeros (it's unlikely this really matters; let me know
next time you flash a BIOS flash 100,000 times!).
More importantly, it allows for future partial flash upgrades with cbfs.
Note that uninitialized_flash_value is a global that can, if we ever need it,
be set by an argument in main. Assuming we ever see a flash where the
"erased" value is 0, not 0xff.
At the same time, "erased" value has been "1" on every EEPROM or
FLASH I've used for some time now.
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4290 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
command.
Make use of it in config.g (Myles)
Signed-off-by: Ward Vandewege <ward@gnu.org>
Acked-by: Myles Watson <mylesgw@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4282 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
It is nearly trivial.
Signed-off-by: Myles Watson<mylesgw@gmail.com>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4279 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Tested to booting linux with qemu.
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Acked-by: Myles Watson<mylesgw@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4276 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
critical, since unless it is fixed this tool creates empty tables that cause
coreboot to (in some cases, e.g. on qemu) triple fault and die.
For the record, an empty option_table is not allowed. The table must,
at least, have 3 32-bit entries in this order:
type -- should be 200, 0r 0xc8, i.e. 0xc8, 0, 0, 0
size of table in LE order, 4 bytes
size of header in LE order, which is always 12,0,0,0
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4264 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Change sizes from unsigned int to int.
Clean up some usage and parameter checking.
Signed-off-by: Myles Watson <mylesgw@gmail.com>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4262 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
src/lib/ code in coreboot. I.e. the tool changes but the coreboot code
does not.
Currently, as cbfstool manages the ROM, there are files and empty
space. To allocate files, the code does, first, a walk of the headers
and, if that fails, does a brute-force search of the rest of the
space.
We all agree that the brute-force search has lots of problems from a
performance and correctness standpoint.
I've made a slight change. Instead of an "empty space" area with no
valid headers, I've made a header for the empty space.
So cbfs creation looks like this:
- set up the boot block
- create a file, of type CBFS_COMPONENT_NULL, that contains the empty
space. CBFS_COMPONENT_NULL was already defined in cbfs.h
Here's an example:
[rminnich@xcpu2 cbfstool]$ ./cbfstool testcbfs create 1048576 2048
(cbfstool) E: Unable to open (null): Bad address
[rminnich@xcpu2 cbfstool]$ ./cbfstool testcbfs print
testcbfs: 1024 kB, bootblocksize 2048, romsize 1048576, offset 0x0
Alignment: 16 bytes
Name Offset Type Size
0x0 0xffffffff 1046456
So how do we create a new file?
It's easy: walk the files and find a file of type CBFS_COMPONENT_NULL,
which is as large
or larger than the file you are trying to create. Then you use that file.
- if the file is the same size as the NULL file, then it's easy: take it
- if the file is smaller than the NULL file, you split the NULL file
into two parts.
note that this works in the base case: the base case is that the whole
storage is CBFS_COMPONENT_NULL.
Here's an example of adding a file.
[rminnich@xcpu2 cbfstool]$ ./cbfstool testcbfs add-stage testfixed t
[rminnich@xcpu2 cbfstool]$ ./cbfstool testcbfs print
testcbfs: 1024 kB, bootblocksize 2048, romsize 1048576, offset 0x0
Alignment: 16 bytes
Name Offset Type Size
t 0x0 stage 23176
0x5ab0 0xffffffff 1023240
Note that the NULL split and got smaller. But the entire ROM is still
contained by the two files. To walk this entire rom will require two
FLASH accesses.
Add another file:
[rminnich@xcpu2 cbfstool]$ ./cbfstool testcbfs add-stage testfixed tt
[rminnich@xcpu2 cbfstool]$ ./cbfstool testcbfs print
testcbfs: 1024 kB, bootblocksize 2048, romsize 1048576, offset 0x0
Alignment: 16 bytes
Name Offset Type Size
t 0x0 stage 23176
tt 0x5ab0 stage 23176
0xb560 0xffffffff 1000024
[rminnich@xcpu2 cbfstool]$
So, taking current ROMs as an example, I can reduce FLASH accesses for
cbfs from (potentially) thousands to (typically) less than 10.
Index: fs.c
Changes for readability and cleanliness. Move common blobs of code to functions.
New function: rom_alloc,which allocates files by finding NULL files and using/splitting.
Other changes as needed to support this usage.
Index: util.c
Creating a cbfs archive now requires creation of a NULL file covering the file system space.
Index: cbfs.h
Add a DELETED file type with value 0. Any file can be marked deleted by zero its type; this is a
FLASH-friendly definition for all known FLASH types.
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
I think it is a step in the right direction. Could you add the
function prototype to cbfstool.h?
Acked-by: Myles Watson <mylesgw@gmail.com>
(I added the prototype)
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4261 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
No datasheet available, chip identified by probing and looking at the PCB.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4255 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Makefile:435: warning: overriding commands for target `src/lib/memset.o'
And replaces these debug messages:
partobj dir 0 parent <__main__.partobj instance at 0x7f1e846a7ab8>
part pci_domain
with:
partobj dir 0 parent northbridge_amd_amdk8_root_complex_dev2 part pci_domain
Signed-off-by: Myles Watson <mylesgw@gmail.com>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4253 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
I didn't try to remove "defined but not used" warnings because there are too
many ifdefs to be sure I wouldn't break something.
For shadowed variable declarations I renamed the inner-most variable.
The one in src/pc80/keyboard.c might need help. I didn't change the
functionality but it looks like a bug.
I boot tested it on s2892 and abuild tested it.
Signed-off-by: Myles Watson <mylesgw@gmail.com>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4240 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Add a note to the coreboot-v2 version of the tree that
contains the new location.
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Patrick Georgi <patrick.georgi@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4215 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Patrick Georgi <patrick.georgi@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4213 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
/dev/null for one compile test.
The old variant of using &>/dev/null works on bash and zsh, but not on
dash and tcsh. dash and tcsh interpret it as "background command and
truncate /dev/null" which is not what we want. >& works on tcsh and
bash, but it is not POSIX compliant.
Since make uses /bin/sh and /bin/sh has to be POSIX compliant, we can
use the POSIX variant of stderr and stdout redirection.
>/dev/null 2>&1
is POSIX compliant. This is specified in SuSv3, Shell Command Language,
sections 2.7.2 and 2.7.6.
Signed-off-by: Stephan Guilloux <stephan.guilloux@free.fr>
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Ward Vandewege <ward@gnu.org>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4211 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
anything that was there. For ck804 or mcp55-based machines that was the
romstrap.
The fix is simple:
1. Put the master cbfs record above the bootblock instead of on it.
Signed-off-by: Myles Watson <mylesgw@gmail.com>
Acked-by: Peter Stuge <peter@stuge.se>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4209 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
supposed to be compressed (with lzma only, as cbfstool lacks
nrv2b compression support for now)
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4208 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
caused a seg fault, sometimes executed somewhere else. Also add an error if
the algorithm is unknown.
Signed-off-by: Myles Watson <mylesgw@gmail.com>
Acked-by: Ward Vandewege <ward@gnu.org>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4198 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
coreboot.romfs file since CBFS will eventually be the standard.
Signed-off-by: Myles Watson <mylesgw@gmail.com>
Acked-by: Patrick Georgi <patrick.georgi@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4197 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
that info. Also, additional small cosmetic fix.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4196 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
coreboot-v2 $ util/abuild/abuild -t kontron/986lcd-m $PWD
you can now also say
coreboot-v2 $ util/abuild/abuild -t kontron/986lcd-m/Config-myconf.lb $PWD
and instead of using Config-abuild.lb or creating a temporary Config-abuild.lb,
abuild will use the existing Config-myconf.lb to build your image.
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4192 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
probe/read/erase/write. That is incorrect.
A bit of confusion comes from how the #defines are named. We call them
TEST_BAD_*, but the message printed by flashrom says:
"This flash part has status NOT WORKING for operations:"
Something that is unimplemented is definitely not working.
Neither of the chip entries mentioned above has erase or write functions
implemented, so erase and write are not working.
Since their size is unknown, we can't read them in. That means read is
not working as well.
Probing is a different matter. If a chip-specific probe function had
matched, we wouldn't have to handle the chip with the "unknown xy SPI
chip" fallback. I'm tempted to call that "not working" as well, but I'm
open to discussion on this point.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4177 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
* Make functions out of the accessor macros in mc146818rtc.c
* don't hide reserved cmos entries from coreboot, only from the user.
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4170 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
helps if the file is generated from patches, esp. if that happens
often (eg. with quilt)
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4165 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Controller. Nothing fancy, does not know any laptops, EC types, or what
the values mean. It just dumps them. For the dump method, have a look at
the ACPI 3.0b spec.
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4163 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
to the specified value.
Only change Config-abuild.lb, as the others are for manual buildtarget
use - adding __LOGLEVEL__ there would kill the build as it isn't
replaced by the actual content.
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4153 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4152 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
With this change, romcc knows -include and the build system uses it.
Also use a full path to settings.h because scan-build has trouble
finding it otherwise.
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Joseph Smith <joe@settoplinux.org>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4151 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
cbfstool extract [FILE] [NAME]
It also factors out the csize calculation in rom_add, and fixes rom_delete so
that it can handle deleting the last entry.
Signed-off-by: Myles Watson <mylesgw@gmail.com>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4144 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
This patch restores the pciid based board matching table. It makes this
table readable and hackable again, and the only disadvantage is that the
right margin is way beyond the rather dogmatic 80. All 0x0000 pci ids have
been string replaced by 0 to more easily spot missing ids, and extra
comments have been added to explain how the various entries are used.
Signed-Off-By: Luc Verhaegen <libv@skynet.be>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4142 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Usage:
include path
path can be relative to the current directory or absolute starting at /src.
I tested it with:
include /config/absolute.lb
include relative.lb
in /src/northbridge/amd/amdk8/Config.lb
which included
/src/northbridge/amd/amdk8/relatvie.lb
/src/config/absolute.lb
Signed-off-by: Myles Watson <mylesgw@gmail.com>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4131 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
pci_rom PATH vendor_id = # device_id = #
to Config.lb files. No more changing the ROM_SIZE to add an option ROM, and no more manual prepending.
Examples:
pci_rom ../ragexl.rom vendor_id = 0x1002 device_id = 0x4752
pci_rom ../nic.rom vendor_id = 0x1100 device_id = 0x4152
Signed-off-by: Myles Watson <mylesgw@gmail.com>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4127 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
after every board build, in order to save disk space if you don't need
the actual output files.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4119 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Signed-off-by: Peter Stuge <peter@stuge.se>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4114 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
This also has the config tool changes in v2/util.
Rename romfs.[ch]->cbfs.[ch] and sed romfs->cbfs romtool->cbfstool ROMFS->CBFS
Signed-off-by: Peter Stuge <peter@stuge.se>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4113 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
I noticed this before sed, but forgot to change it back after sed.
Signed-off-by: Peter Stuge <peter@stuge.se>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4111 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
It's all sed here. romfs->cbfs, ROMFS->CBFS, romtool->cbfstool
Signed-off-by: Peter Stuge <peter@stuge.se>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4110 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
skeleton will have get a cross compiler before it gets the architecture set
to SKIP. Pretty much build system internal, so self-acked.
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4091 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
- Improve description a bit, especially wrt chip packages and
protocols.
- Add some missing parameters to manpage option descriptions.
- Remove long obsolete DoC support note.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4088 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Tested on an iWILL DK8-HTX board.
Signed-off-by: Mondrian nuessle <nuessle@uni-hd.de>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4086 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
romtool by changing the Makefiles to be no longer recursive (once again,
recursive make is to be considered harmful). Tried to (quickly) unify most of
the Makefile code, but medium-term this is going to be worked on for Kconfig
support anyways.
Also fix a sign cast error in rom-mkpayload in case people want to compile this
with -W -Werror
Patch relative to coreboot-v2/util/romtool
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
and
Acked-by: Stefan Reinauer <stepan@coresystems.de>
in order to get the tree working decently asap
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4069 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
(coreboot.org build system internal)
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4066 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
romtool is still built in util/romtool, as happens without this patch.
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4061 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
issues (see buildbot).
The romfs image was always built, and sometimes broke (because of
the different image layouts) for buildrom images. After the patch, these
issues are avoided by not adding payloads to the romfs image (they
wouldn't be read anyway). Both workarounds (in buildrom code for
romfs and vice-versa) aren't very pretty, but that's what our buildsystem
requires.
As I had to create a "communication channel" (via the romfs-support
files), I took the chance to also use it for compression
information, so if you configure lzma support, you'll get lzma
compressed payloads in romfs.
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4054 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
The compile_file calls seem to be in the wrong order, but
romcc actually requires it that (probably some stack-like
file processing)
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Patrick Georgi <patrick.georgi@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4051 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
romfs.
Everything else to make a target romfs aware happens in the targets.
What the patch does:
1. missing romfs.h include
2. special handling while creating coreboot.rom
While the romfs code path in the makefile doesn't actually use the file,
it's possible that the build of coreboot.rom fails in a romfs setup,
because the individual buildrom image is too small to host both coreboot
and payloads (as the payloads aren't supposed to be there). Thus, a
special case to replace the payload with /dev/null in case of a romfs
build.
There would be cleaner ways, but they're not easily encoded in the
Config.lb format.
3. config.g is changed to create rules for a romfs build
Targets should still build (they do for me)
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4049 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
I've attached a patch that removes the 3-mile-long compiler
commandlines, which vim's quickfix doesn't like so much. Instead of
putting all those -DXYZ='bla' on the compiler commandline, they are put
in a file called settings.h (as #define XYZ bla) and only a
--include=settings.h is put on the commandline.
This file is created unconditionally at the same time as when the
CPUFLAGS simply expanded make variable used to be created (not via a
target rule and dependency), so it shouldn't change anything.
Signed-off-by: Ronald Hoogenboom <hoogenboom30@zonnet.nl>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4047 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
There are a few changes. The 20K bootblock size restriction is gone.
ROMFS has been tested and works on v2 with qemu and kontron. Once this
patch is in, those patches will follow.
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Acked-by: Patrick Georgi <patrick.georgi@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4032 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
This is a BCM5785 based machine, WP# and TLB# need to be deasserted using
GPIO 2 and 5 from the PM registers of the southbridge.
This is very similar to the x3455 implementation.
Signed-off-by: Mondrian Nuessle <nuessle@uni-hd.de>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4031 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Thanks to Mart for finding and reporting the problem!
Signed-off-by: Peter Stuge <peter@stuge.se>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4026 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
the struct to the individual struct members to improve readability.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4020 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Uwe Hermann