- Whitespace fixes, remove trailing whitespace, use TABs for identation
(except in Kconfig "help" lines, which start with one TAB and two spaces
as per Linux kernel style)
- Kconfig: Standardize on 'bool' (not 'boolean').
- s/lar/cbfs/ in one Kconfig help string.
- Reword various Kconfig menu entries for a more usable and consistent menu.
- Fix incorrect comment of NO_RUN in devices/Kconfig.
- superio/serverengines/Kconfig: Incorrect config name.
- superio/Makefile.inc: s/serverengine/serverengines/.
- superio/intel/Kconfig: s/SUPERIO_FINTEK_I3100/SUPERIO_INTEL_I3100/.
- mainboard/via/vt8454c/Kconfig: Fix copy-paste error in help string.
- mainboard/via/epia-n/Kconfig: Fix "bool" menu text.
- console/Kconfig: Don't mention defaults in the menu string, kconfig
already displays them anyway.
- Kill "Drivers" menu for now, it only confuses users as long as it's emtpy.
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@4567 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
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@4537 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
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@4535 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Works on Kontron, qemu, and serengeti.
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
tested on abuild only.
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4534 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
single core.
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4415 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Major changes:
1. Separate resource allocation into:
A. Read Resources
B. Avoid fixed resources (constrain limits)
C. Allocate resources
D. Set resources
Usage notes:
Resources which have IORESOURCE_FIXED set in the flags constrain the placement
of other resources. All fixed resources will end up outside (above or below)
the allocated resources.
Domains usually start with base = 0 and limit = 2^address_bits - 1.
I've added an IOAPIC to all platforms so that the old limit of 0xfec00000 is
still there for resources. Some platforms may want to change that, but I didn't
want to break anyone's board.
Resources are allocated in a single block for memory and another for I/O.
Currently the resource allocator doesn't support holes.
Signed-off-by: Myles Watson <mylesgw@gmail.com>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
Acked-by: Patrick Georgi <patrick.georgi@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4394 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
It's basically done with the following script and some manual fixup:
VARS=`grep ^define src/config/Options.lb | cut -f2 -d\ | grep -v ^CONFIG | grep -v ^COREBOOT |grep -v ^CC`
for VAR in $VARS; do
find . -name .svn -prune -o -type f -exec perl -pi -e "s/(^|[^0-9a-zA-Z_]+)$VAR($|[^0-9a-zA-Z_]+)/\1CONFIG_$VAR\2/g" {} \;
done
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@4381 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
starts to play its role. Then the system hangs at HDA init. I dont know what the
VC1 is. The RPR says "Optional Features (only needed if CMOS option is enabled)"
in 5.10.2. Before I know what it is, I think it is better to skip it.
Tested on dbm690t.
Add comment from Rudolf,
"
VC is virtual channel. Its used for isochronous transfer of data to sound card.
The virtual channel guarantee "on time" delivery. In other words it sets up a
channel for data to sound card, which means that that arrivs in time and there will
be no interuptions in audio stream.
http://www.microsoft.com/whdc/connect/pci/wlp_interrupt.mspx
"
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4339 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
1. In rs690_cmn.c, mask the lower 4 bits of the BAR3. No doubt, right?
2. In rs690_pcie.c,
(1) Obviously, the mask should be 0xF, and bit 19 should be set to 1 (in comment).
In rpr 5.10.2, step 2, step 2.1 & step 2.6
(2) The dynamic buffer allocation is enabled by setting bit 11 of PCIEIND: 0x20,
instead of PCIEIND_P: 0x20.
In rpr 5.10.2, step 5. Dynamic Slave CPL Buffer Allocation
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4336 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
a long time ago. This will make it easier to port v2 boards forward to v3 at
some point (and other things)
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@3964 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
- make uma_memory_base and uma_memory_size uint64_t as they may be 64bit BARs
on some platforms.
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3949 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Reorder HDA (HD Audio) init:
The reordering was based on what order things happen in the BIOS
Developers guide, RPR, and SATA driver. I fixed the order of the devices
that didn't matter to clean up the change log.
1. Enable the Chip
2. Setup the SMBus registers
3. Setup the Device Registers
4. Look for Codec
5. Init Codec
The codec init was changed to match the description in the RRG pg 235.
Mem Reg: Base + 08h Bit 0. There were unneeded things happening.
Added 1ms delay to match the BKDG while waiting for BAR+0xe to set its
bits.
Signed-off-by: Dan Lykowski <lykowdk@gmail.com>
Tested on AMD DBM690T and AMD Pistachio by Maggie Li. Works.
Tested on Asus M2A-VM by Carl-Daniel Hailfinger. Improves the situation,
but some warnings remain.
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3930 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Signed-off-by: Maggie Li <maggie.li@amd.com>
Reviewed-by: Zheng Bao <Zheng.bao@amd.com>
Acked-by: Marc Jones <marcj303@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3891 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
SATA port status kept returning 0x1: BAR5+po+28h
1h = Device presence detected but Phy communication not established
This patch adds logic to force 1.5g if the drive fails to communicate at 3.0g.
Signed-off-by: Dan Lykowski <lykowdk@gmail.com>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3864 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
is no longer 0xA0 or 0xB0. It simply assumes that will never happen.
My 500 GB Seagate Barracuda ST3500820AS triggers that corner case on the
first init after poweron.
The current code hangs forever with my drive. Fix this by rerunning the
init sequence after SATA_BAR0+6 is no longer 0xA0 or 0xB0.
Add support for SATA port 2-4 (Primary Slave, Secondary Master,
Secondary Slave).
If only the 2nd SATA port is connected and the hardware acts strangely
(contrary to documentation), it will print the error message below and
continue anyway. The official AMD asm code behaves the same way.
SATA port 0 status = 0
No Primary Master SATA drive on Slot0
SATA port 1 status = 23
0x6=7f, 0x7=7f
drive no longer selected after 0 ms, retrying init
[8 repetitions]
0x6=7f, 0x7=7f
drive no longer selected after 0 ms, retrying init
Primary Slave device is not ready after 10 tries
Activate and improve debug messages for SPEW log level.
Fix some comments.
New log messages look like this:
PCI: 00:12.0 init
sata_bar0=3020
sata_bar1=3060
sata_bar2=3030
sata_bar3=3070
sata_bar4=3000
sata_bar5=fc309000
SATA port 0 status = 23
0x6=a0, 0x7=80
drive detection not yet completed, waiting...
0x6=a0, 0x7=80
drive detection not yet completed, waiting...
[... 281 repetitions ...]
0x6=0, 0x7=50
drive no longer selected after 2820 ms, retrying init
drive detection done after 0 ms
Primary Master device is ready after 2 tries
SATA port 1 status = 23
drive detection done after 0 ms
Primary Slave device is ready after 1 tries
SATA port 2 status = 0
No Secondary Master SATA drive on Slot2
SATA port 3 status = 0
No Secondary Slave SATA drive on Slot3
With this patch, my Asus M2A-VM boots into Linux without problems.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Zheng Bao <zheng.bao@amd.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3845 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
The RS690 chipset has a problem where it will not work with 1 GHz HT
speed unless NB_CFG_Q_F1000_800 bit 0 is set.
Tested, works on my Asus M2A-VM with an 1 GHz HT capable processor.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Bao, Zheng says:
As a matter of fact, both 600Mhz and 1Ghz have their own specific
setting.
This patch has been tested on dbm690t which HT link works on 800Mhz.
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3839 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
The device ID of 690G is 0x791E, while the ID of 690M and 690T is 0x791F
This fixes booting on 690G.
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3816 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
mainboard specific code. (And add a hook to allow other mainboards do
a similar thing if required)
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@3812 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
document verification against the data sheets.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Maggie Li <maggie.li@amd.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3811 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Signed-off-by: Joe Bao <zheng.bao@amd.com>
Reviewed-by: Maggie Li <maggie.li@amd.com>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
Acked-by: Marc Jones <marcj303@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3786 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Signed-off-by: Joe Bao <zheng.bao@amd.com>
Reviewed-by: Maggie Li <maggie.li@amd.com>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
Acked-by: Marc Jones <marcj303@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3785 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
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
Signed-off-by: Marc Jones <marcj.jones@amd.com>
Acked-by: Marc Jones <marcj.jones@amd.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3643 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
We shouldn't assume the presence of a working HDA codec, so put in
a reasonable timeout of 50usecs (timeout value borrowed from the kernel).
This makes SimNow work, since apparently though the codec is
present in Simnow, it is non functional.
Signed-off-by: Jordan Crouse <jordan.crouse@amd.com>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3640 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Signed-off-by: Marc Jones <marc.jones@amd.com>
Acked-by: Marc Jones <marc.jones@amd.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3636 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
certainly won't build -- that comes later. I am hoping to get some
eyeballs on it for simple errors.
rs690 is next.
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@3630 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
code to use it. That makes the code more readable and also less
error-prone.
Abuild tested.
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@3624 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Most of the functions in SB600 are enabled except power management.
Signed-off-by: Michael Xie <Michael.Xie@amd.com>
Reviewed-by: Marc Jones <marc.jones@amd.com>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3589 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
All the PCIe slots are enabled in this patch except power management.
Signed-off-by: Michael Xie <Michael.Xie@amd.com>
Reviewed-by: Marc Jones <marc.jones@amd.com>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3588 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
pci_write_config8.
Signed-off-by: Marc Jones <marc.jones@amd.com>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3282 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
You can see this by executing commands like this:
grep -r pci_assign_irqs coreboot/src/*
This basically AMD/LX based boards: pcengines/alix1c,
digitallogic/msm800sev, artecgroup/dbe61, amd/norwich, amd/db800.
Also for AMD/GX1 based boards need a patch
[http://www.pengutronix.de/software/ptxdist/temporary-src/references/geode-5530.patch]
for the right IRQ setup.
AMD/GX1 based boards is: advantech/pcm-5820, asi/mb_5blmp, axus/tc320,
bcom/winnet100, eaglelion/5bcm, iei/nova4899r, iei/juki-511p.
I have two ideas.
1. Delete duplicate code from AMD/LX based boards.
2. Add IRQ routing for AMD/GX1 boards in coreboot.
The pirq.patch for IRQ routing logically consist from of two parts:
First part of pirq.patch independent from type chipsets and assign IRQ for
ever PCI device. It part based on AMD/LX write_pirq_routing_table() function.
Second part of pirq.patch depends of type chipset and set PIRQx lines
in interrupt router. This part supports only CS5530/5536 interrupt routers.
IRQ routing functionality is included through PIRQ_ROUTE in Config.lb.
Tested on iei/juki-511p(cs5530a), iei/pcisa-lx(cs5536) and also on
TeleVideo TC7020, see
http://www.coreboot.org/pipermail/coreboot/2007-December/027973.html.
Signed-off-by: Nikolay Petukhov <nikolay.petukhov@gmail.com>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3196 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Due to the automatic nature of this update, I am self-acking. It worked in
abuild.
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3053 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
code is changed.
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3052 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Check that the SMBus controller is found and stop on an error.
Clean up and add additional path through the 8111 reset functions.
Signed-off-by: Marc Jones <marc.jones@amd.com>
Reviewed-by: Jordan Crouse <jordan.crouse@amd.com>
Acked-by: Myles Watson <myles@pel.cs.byu.edu>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3015 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
rodata.pci_driver" warnings are coming from? We were packing those
structures into a read-only segment, but forgot to mark them const.
Despite its size, this is a fairly trivial patch created by a simple
search/replace
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@2891 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Painting the splash graphic is now ifdef'ed.
Signed-off-by: Juergen Beisert <juergen127@kreuzholzen.de>
Acked-by: Peter Stuge <peter@stuge.se>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@2836 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
to set up one of five screen resolutions (sorry no autodetection at runtime,
resolution is selected at buildtime) and displays a graphic in the right
bottom corner (splash screen).
Signed-off-by: Juergen Beisert <juergen127@kreuzholzen.de>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@2827 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
