On Sun, Feb 27, 2011 at 11:41:11PM +0000, Jonathan A. Kollasch wrote:
On Thu, Feb 24, 2011 at 02:14:07AM +0000, Jonathan A. Kollasch wrote:
Hi,
I've attempted to use the rs780 and sb800 code on a AM3 870 + SB850 board. Raminit seems to go okay, as does the first bits of ramstage. However, ramstage fails after the first two passes through rs780_enable(). It stalls in get_vid_did() reading PCI config space of device 2 (or 4). Also, the rs780 HT init code thinks the link should run at 200MHz, maybe that's related.
This turned out to be GLOBAL_RESET_GFX and GLOBAL_RESET_GPPSB being set. I now get to the payload, but no SATA drives are detected, also, some of the PCIe x1 ports (onboard and slots) aren't quite right yet ...
Well seen.
In fact I was having the same exact symptoms as you, and your solution has helped me, thank you all. With Scott Duplichan's patch I got HT3, and with the attached patch (to rev.6458) I can get FILO to load linux. (but linux won't boot). But this patch can't be checked in, it's just an experiment. In fact I'm not sure of how to do it properly.
Funny enough I don't have a rs870 or sb850 . I have a sb710 and a rx780/rx790 on an ASUS M4A77TD-PRO . But the same solution works as with rs870. Maybe my rx780 was a rs870 that didn't pass QC and had its GPU disabled ?
Anyway, apparently Jonathan board and mine need to clear the GLOBAL_RESET_GFX and GLOBAL_RESET_GPPSB (which are 1 on boot). In my case I need to do this before any pci_locate_device call is made. Otherwise it hangs. I was using a patch[1] that eliminated all early pci_locate_device calls and hardcoded bus,device,function and that got me past romstage, but it still hanged in ramstage in pci enable, and clearing the resets fixes it, so it's better to clear them soon and not hardcode bdf. This means I need it in the bootblock, between the FAM10 northbridge bootblock code and the SB700 southbridge code. But I guess it would be good to do it in any rs780 family southbridge, whatever the sb. So what would be the proper way ?
1- change src/arch/x86/init/bootblock_simple.c so that it calls a "middlebridge_init" between bootblock_northbridge_init(); and bootblock_southbridge_init(); and have it empty always except for rs780 ? Too invasive ?
2- put a function in rs780/early_init.c to clear the resets and call it from the beginning of roomstage.c for boards which need it ? Then I would have to hardcode bdf in sb700/bootblock.c to avoid pci_locate_device before romstage.
3.- add a call to sb700/bootblock.c to a function that is empty for all but rs780 family chips ?
4.- call some form of weak function from src/arch/x86/init/bootblock_simple.c that does nothing by default but any board can override ? (in a specific C file, I guess, since it'll have to be linked to the bootblock).
5.- have some kconfig magic replace src/arch/x86/init/bootblock_simple.c with some board or southbridge or something specific code ?
6+ .- ... others ?
in any case, if the rs780 reset bits are cleared in bootblock (i.e. we don't choose option 2), I'd need to add some code for set_nbmisc_enable_bits which I think is not in the bootblock now (this code is in bootblock.c in the illustrative patch I'm attaching). This code is already duplicated in southbridge/amd/rs780/cmn.c and southbridge/amd/rs780/early_setup.c so I hesitate to make a third copy in the bootblock.
1.- should it be separated into a link file to have it in one place and include or link it in the three places where it is needed ?
2.- should the entire rs780/early_setup.c be linked in the bootblock (does it need to be tiny?).
In any case, does anyone have any idea on what to do to get linux to boot ?. I've tried to initialise the sb710 in AHCI mode but then filo won't find the disk (might have been done it wrong, I don't have the patch here). I've tried to fix a little sata.c and pcie.c (see patch) but I'm not sure it helps.
The kernel hangs after the message pci 0000:00:11.0: set SATA to AHCI mode With the original BIOS it continues with pci 0000:00:12.0: reg 10: [mem 0xf7ffe000-0xf7ffefff] (12 is USB) With the original BIOS and passing acpi=off to the kernel, linux boots but 2 USB ports don't work (the kernel complains of the loading ehci too late). So maybe it's something in OHCI initialization ? Or maybe I need to look into ACPI (I thought it wasn't needed, so I left the tilapia code).
I'm attaching the patch, also a patch for the mainboard (copied from tilapia_fam10, I never looked into acpi and the mptable utility complains of extended table hosed, so I left the mptable.c identical to tilapia or other boards), the boot log and an lspci output, and a dmesg with the original BIOS and acpi=off in the kernel command line. Maybe somebody has any idea... I may have even less spare time from now until august to look at this...
Thank you.
[1] http://www.coreboot.org/pipermail/coreboot/2010-August/059899.html