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
Carl-Daniel Hailfinger