Hi all,
Based on Idwer's RFC I tried adding ACPI to P2B-LS plus completing the
rest of the PIIX4 function 3 initialization.
This is a summary of what I did:
* I used the DSDT table from the final vendor BIOS. Not provided here
for obvious reasons, but I can tell you how to extract it.
* I also replicated the content of the PIIX4 function 3 config space
after booting with vendor BIOS, as below:
00:04.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 02)
00: 86 80 13 71 03 00 80 02 02 00 80 06 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 01 e4 00 00 00 00 00 20 1e 30 00 01 00 00 00 00
50: 00 58 19 00 c0 c8 3b 02 37 40 40 03 00 00 00 00
60: 90 02 e7 00 00 00 00 10 04 e4 11 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 01 e8 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 30 0f 00 00 00 00 00 00
One exception is 0x90-0x91 which has the SMBus host base address. I
kept it as 0x0f00.
* Idwer is trying to build ACPI 4.0 (!) tables. Since P2B-LS is
shipped when ACPI was still at 1.0, that's what I did. For booting XP,
even ACPI 2.0 compliance is sufficient.
This is a summary of what happens:
* I can no longer get POST codes on the PCI bus. POST codes still
appear on the ISA bus. Glad I picked a POST card that works on both
buses.
* Power off does not work. The last POST code to show before complete
kernel shutdown and hard drive spinning down is 0xF5.
* I don't how how to enter soft suspend in Linux (silly me -_-! ), so
I have not tested it.
* the sensor appears on ISA bus port 0x290, just like vendor BIOS.
* My SB AWE64 ISA card still got initialized and driver loaded, but no
sound. In fact ALSA can't even do I/O to the card. That apparently is
because PIIX4 needs to be configured to forward certain I/O port
ranges to ISA, and some of those port ranges can be further
configured. This would require detecting in runtime what ISA cards are
installed, what are they, and what I/O port ranges they would use.
Where in the source tree should I place such code? Southbridge?
The changes I made are described in two attached patches, one to
southbridge/intel/i82371eb, one to mainboard/asus/p2bls. My coreboot
and linux boot log is also attached.
This is also RFC and is not signed off at this point, but comments are welcome.
Regards
Keith
This applies to 2.6.31 & 2.6.32 kernels for certain, but probably other newer
kernels as well.
I'm a user of mkelfImage; I am currently unable to get an .ebi generated by
mkelfImage to boot properly - I can't load it directly, or via a mechanism
like kexec.
The moment the command (be it etherboot/gpxe, or kexec) tries to load the
kernel, the system immediately reboots.
If I directly kexec a kernel (minus mkelfImage), the kernel loads correctly,
so it appears the problem is in mkelfImage.
Unfortunately, I don't know how to fix it, and I _have_ to use mkelfImage to
generate .ebi images for my systems.
I've tried 2.6.27, 2.6.31, 2.6.32; of those, 2.6.27 (and older kernels, work
fine. 2.6.31 & 32 results in an .ebi that causes the system to reboot.
Any help!?
Thanks,
Troy Telford
#163: Board still requires RAMBASE <1MB
-------------------------+--------------------------------------------------
Reporter: oxygene | Owner: stepan@…
Type: defect | Status: new
Priority: minor | Milestone:
Component: coreboot | Keywords:
Dependencies: | Patchstatus: there is no patch
-------------------------+--------------------------------------------------
Some boards have RAMBASE at 0x4000.
For some, it's probably a left-over from old times, but others actually
require it. Update the former, and fix the latter.
Wyse/s50 requires 0x4000, see
http://www.coreboot.org/pipermail/coreboot/2010-May/058080.html (and the
log file therein)
--
Ticket URL: <https://tracker.coreboot.org/trac/coreboot/ticket/163>
coreboot <http://www.coreboot.org/>
Hi,
attached patch moves several config flags that, for historical reasons,
were put in romstage.c into Kconfig.
This ensures that all parts of the coreboot build on affected boards
have a chance to use these flags, which will be useful when removing
.c-includes in romstage.c
It's also a first step towards removing yet another config system
(manual #defines) from the tree.
Maybe these flags could be done away with somehow, maybe they should be
declared in other parts of the tree (eg. chipset). This is a first safe
step, so I didn't think too much about moving them elsewhere.
Signed-off-by: Patrick Georgi <patrick.georgi(a)coresystems.de>
#110: Allow for per-device subsystem IDs
---------------------------------+------------------------------------------
Reporter: uwe | Owner: somebody
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: coreboot | Version: v3
Keywords: | Dependencies:
Patchstatus: there is no patch |
---------------------------------+------------------------------------------
Currently both v2 and v3 only allow us to use one global set of PCI
subsystem IDs, which is too simplistic. In theory (and often in practice)
each PCI device has (or can have) its own subsystem ID.
We should fix this, at least in v3, possibly also in v2.
See also http://www.coreboot.org/pipermail/coreboot/2008-July/036514.html
--
Ticket URL: <http://tracker.coreboot.org/trac/coreboot/ticket/110>
coreboot <http://www.coreboot.org/>
#152: v3 Geode cs5536 UART2 wrongly configured
-------------------------------------------+--------------------------------
Reporter: edwin_beasant@… | Owner: somebody
Type: defect | Status: new
Priority: major | Milestone: Going mainstream
Component: coreboot | Version: v3
Keywords: serial com2 geode cs5536 | Dependencies:
Patchstatus: patch needs review |
-------------------------------------------+--------------------------------
The UART2 on the AMD cs5536 is incorrectly configured in two places in v3
code and also in v2.
GPIO lines 4 and 3 are swapped and also incorrectly put in IR mode receive
(compound fault).
This patch corrects the v3 late configuration and the v3 and v2 early
(stage1/cache as ram) mis-configuration of UART2 to addres 0x3f8 not the
standard 0x2f8 for COM2.
--
Ticket URL: <http://tracker.coreboot.org/trac/coreboot/ticket/152>
coreboot <http://www.coreboot.org/>