Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3700 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
- leave a hole for mmapped PCIe config space if CONFIG_PCIE_CONFIGSPACE_HOLE
is set.
- Mask moving bits to 32bit when resources are not supposed above 4G. Linux
does not like this, even though the resource is disabled.
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Myles Watson <mylesgw@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3699 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Martin Stecklum <stecky@gmx.net> (both write and erase).
The tests were done on an MSI MS-7065 board, so that's supported now
too (wiki page will be updated).
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@3697 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Untested, but should work just as well as the other *PIIX* southbridges
according to the datasheets.
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@3696 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
They all use a different init sequence than the more modern ITE Super I/Os.
For now we only use 0x370 as config port, but 0x3f0 or 0x3bd would also be
valid. Contrary to other Super I/Os, the config port for these is _not_
hardcoded via hardware, instead it can be programmed by software, i.e.
you get to choose whether you want to use 0x370, 0x3f0, or 0x3bd.
Tested on IT8671F by Uwe Hermann and on IT8770F by Urja Rannikko.
Signed-off-by: Urja Rannikko <urjaman@gmail.com>
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Urja Rannikko <urjaman@gmail.com>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3692 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Marc Jones <marc.jones@amd.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3691 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
reg much more often. In my case this reduced the time spent in coreboot
by 1.5 sec!
The timeout values of course aren't changed, only the granularity. Also,
I didn't see any udelay() implementation that looked like it couldn't
cope with 10 us delays. (Most are written as for (...) inb(0x80) loops.)
Signed-off-by: Jens Rottmann <JRottmann@LiPPERTEmbedded.de>
Acked-by: Marc Jones <marc.jones@amd.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3690 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
due to integer rounding errors. Previously, the formula was:
speed = 2 * (10000/spd_value)
For spd_value=60 this means speed = 2 * 166 = 332, which is less than
333 and coreboot died saying RAM was incompatible. The new formula is:
speed = 20000 / spd_value
For spd_value=60, speed=333, which is fine.
Signed-off-by: Jens Rottmann <JRottmann@LiPPERTEmbedded.de>
Acked-by: Marc Jones <marc.jones@amd.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3689 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Also use different console messages for copying and uncompressing, like
it's already done in similar code in other places.
Signed-off-by: Jens Rottmann <JRottmann@LiPPERTEmbedded.de>
Acked-by: Marc Jones <marc.jones@amd.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3688 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
'include util/kconfig/Makefile' must come before certain pattern rules
for compilation of kconfig files, otherwise the build would break
in most situations.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Jordan Crouse <jordan.crouse@amd.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3686 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
* allow versions of "install" that don't know -D
* install libpayload .config and config.h to the target.
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Jordan Crouse <jordan.crouse@amd.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3683 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
This has been tested on hardware by me.
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@3682 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Also, use more readable #defines instead of hardcoded config ports for
PM/PM2 related functions, and simplify them a bit.
Build-tested with the AMD dbm690t target.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Marc Jones <marc.jones@amd.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3680 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
replaces it with two queues (input, output) where drivers (serial,
keyboard, video, usb) can attach.
The only things left with #ifdefs are initialization (at some point
the drivers must get a chance to register)
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Jordan Crouse <jordan.crouse@amd.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3679 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
On faster machines, delta might be more then 32 bits
Signed-off-by: Jordan Crouse <jordan.crouse@amd.com>
Acked-by: Patrick Georgi <patrick.georgi@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3677 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Signed-off-by: Jordan Crouse <jordan.crouse@amd.com>
Acked-by: Patrick Georgi <patrick.georgi@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3676 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
If the system in question does not have a superIO, then a read of
0x64 will return 0xFF and we will loop forever.
Signed-off-by: Jordan Crouse <jordan.crouse@amd.com>
Acked-by: Patrick Georgi <patrick.georgi@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3675 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Remove a possiblity for evil recusion and fix the function and slot
definition in the PCI search loop
Signed-off-by: Jordan Crouse <jordan.crouse@amd.com>
Acked-by: Patrick Georgi <patrick.georgi@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3674 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Make libpayload applications multiboot compatible. Add the
multiboot OS table and grok the loader table, especially the
memory map and the command line. This makes libpayload
applications loadable by GRUB.
Signed-off-by: Jordan Crouse <jordan.crouse@amd.com>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3673 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Allow the payload to enable a PCI device as a bus master.
Signed-off-by: Jordan Crouse <jordan.crouse@amd.com>
Acked-by: Patrick Georgi <patrick.georgi@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3672 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Using gcc to compile assembly files lets us use preprocessor
directives.
Signed-off-by: Jordan Crouse <jordan.crouse@amd.com>
Acked-by: Patrick Georgi <patrick.georgi@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3671 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
specification and local testing.
Also tweak a little bit algorithm for (internal) device ID calculation:
Chips from the W83627HF/F/HG/G family have an ID of 0x52 and a multitude of
revisions (0x1x, 0x3a, 0x41, maybe more), chips from the W83627HF/GF family
have the same device ID but revisions 0xfx.
Please note that the last line of the patch simply fixes the comment
about internal device ID composition (upper half of reg 0x21 is used).
I chose the most conservative way of detecting W83627HF - only if reg
0x21 value matches 0xFx we skip the previous logic and keep using it for
all other revisions.
Signed-off-by: Andriy Gapon <avg@icyb.net.ua>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3670 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Based on the 5595 datasheet and uniflash 1.40 sources, only looking for info
about SiS620.
Signed-off-by: Urja Rannikko <urjaman@gmail.com>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3668 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
built in the normal image, not fallback.
Signed-off-by: Corey Osgood <corey.osgood@gmail.com>
Acked-by: Corey Osgood <corey.osgood@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3667 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
build. As far as I know, no C7 boards currently in the tree use SPI
flash.
Signed-off-by: Corey Osgood <corey.osgood@gmail.com>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3665 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
called from one target and that target is compiled with GCC, make the
function dependent on GCC.
ROMCC also chokes on the ULL suffix for integer constants. Change the
affected ones to UL for ROMCC compiled code.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3664 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
dependency bug which hit people running parallel make instances.
With our current makefile architecture, the "right" fix is impossible.
However, we can still kill the race conditions leading to arbitrary
compilation failures. That trick depends on the atomicity of the mv
command.
Extensive comments explain what the workaround does.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3663 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
560bytes/controller)
- no need for the client of libpayload to implement
usbdisk_{create,remove}, just because USB was compiled in.
- usb hub support compiles, and works for some trivial cases (no device
detach, trivial power management)
- usb keyboard support works in qemu, though there are reports that it
doesn't work on real hardware yet.
- usb keyboard is integrated in both libc-getchar() and curses, if
CONFIG_USB_HID is enabled
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Jordan Crouse <jordan.crouse@amd.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3662 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
* Add a function to change the 24/48Mhz clock input selector on the Winbond
W83697 superio to 48Mhz, used by the WinNET P680
Signed-off-by: Alex Mauer <hawke@hawkesnest.net>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3661 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
is also visible to ROMCC and ROMCC doesn't understand that.
The fix is to use __attribute__((packed)) only for gcc compiled code.
This has been unfixed for too long. There are more problems remaining,
but at least this one is solvable easily.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3660 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
enable that area once the register is set so print a warning.
Signed-off-by: Marc Jones <marcj.jones@amd.com>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
Acked-by: Peter Stuge <peter@stuge.se>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3659 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
This is useless, as it changes with each access; it doesn't convey any
useful information at all.
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@3658 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Build-tested with the AMD dbm690t board.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Marc Jones <marc.jones@amd.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3655 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
This is abuild-tested by me.
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@3654 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
lib/debug.c and use that one.
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@3653 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Stefan Reinauer