[coreboot] ASUS m5a88-v AGESA port (bulldozer): Linux does not set up SATA drives

Paul Menzel paulepanter at users.sourceforge.net
Sat Jul 6 12:13:17 CEST 2013


Dear Sebastian,


Am Donnerstag, den 04.07.2013, 23:14 +0200 schrieb Sebastian Parborg:
> I've made some more progress in this matter. I got rid of more coreboot log
> errors and warning messages. I also managed to get rid off most of the
> warnings the linux kernel prints when it boots.

congrats!

> However it seems like the linux kernel can't mount the sata drives. It
> fails with "ata1: softreset failed (1st FIS failed)" please look at the
> attached logs for more info.
> 
> I find it really strange that it fails because I can use grub2 to browse
> the and read the sata drives without any problem.
> 
> It seems like I'm really close in getting this to work so I would be really
> happy if any of you guys could help me out. I don't know what I can do to
> fix this.

There seem to be still some issues reported by Linux before the SATA
error and the Oops afterward.

        [    0.000000] WARNING: Bogus (zero) I/O APIC address found in table, skipping!

No idea.

        [    0.672053]  pci0000:00: Requesting ACPI _OSC control (0x1d)
        [    0.672909]  pci0000:00: ACPI _OSC request failed (AE_NOT_FOUND), returned control mask: 0x1d
        [    0.673907] ACPI _OSC control for PCIe not granted, disabling ASPM

This should have been fixed for the other boards already. Make sure you
have these fixes. Also make sure to set these up as separate commits so
review is easier.

        [    0.759288] pci 0000:00:01.0: BAR 15: can't assign mem pref (size 0x20000000)
        [    0.766428] pci 0000:01:05.0: BAR 0: can't assign mem pref (size 0x20000000)
        [    0.773482] pci 0000:01:05.0: BAR 0: trying firmware assignment [mem 0xc0000000-0xdfffffff pref]
        [    0.782266] pci 0000:01:05.0: BAR 0: [mem 0xc0000000-0xdfffffff pref] conflicts with reserved [mem 0xbffe0000-0xdfffffff]
        [    0.793226] pci 0000:00:01.0: PCI bridge to [bus 01-01]
        [    0.798458] pci 0000:00:01.0:   bridge window [io  0x1000-0x1fff]
        [    0.804556] pci 0000:00:01.0:   bridge window [mem 0xe0100000-0xe02fffff]
        [    0.811357] pci 0000:00:09.0: PCI bridge to [bus 02-02]
        [    0.816586] pci 0000:00:09.0:   bridge window [io  0x2000-0x2fff]
        [    0.822687] pci 0000:00:09.0:   bridge window [mem 0xe0300000-0xe03fffff]
        [    0.829473] pci 0000:00:0a.0: PCI bridge to [bus 03-03]
        [    0.834707] pci 0000:00:0a.0:   bridge window [mem 0xe0400000-0xe04fffff]
        [    0.841495] pci 0000:00:14.4: PCI bridge to [bus 06-06]
        [    0.846736] pci 0000:00:15.0: PCI bridge to [bus 04-04]
        [    0.851969] pci 0000:00:15.1: PCI bridge to [bus 05-05]
        [    0.857197] pci 0000:00:15.1:   bridge window [io  0x3000-0x3fff]
        [    0.863301] pci 0000:00:15.1:   bridge window [mem 0xe0000000-0xe00fffff 64bit pref]
        [    0.871067] pci 0000:00:15.0: can't derive routing for PCI INT A
        [    0.877076] pci 0000:00:15.0: PCI INT A: no GSI
        [    0.881633] pci 0000:00:15.1: can't derive routing for PCI INT A
        [    0.887639] pci 0000:00:15.1: PCI INT A: no GSI

The above might be a problem. As coreboot is responsible for setting PCI
up as far as I know, there might be still a problem.

If I were you, I would try to fix the above errors first. Often solving
these, also fixes errors after it too.

> I've attached three log files coreboot_log.txt is just the coreboot log,
> kernel_log.txt is the what the kernel prints when it boot with my coreboot
> rom and kernel_vanilla.txt is with the original bios image.

Could you attach a diff of the two `kernel_log.txt` (without the time
stamps) please?

Two more ideas coming to my mind. First try to boot from an USB medium
(from SeaBIOS for example) and look how far that goes and if you can
compare lspci output from there. Maybe a newer Linux kernel also helps
there. Try to play with the Linux kernel pata and ahci/libahi. `libahci`
has an option `skip_host_reset` (`/sbin/modinfo libahci`). No idea if
that helps and if there even is an option to avoid setting up the SATA
controller into AHCI mode.


Thanks,

Paul
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20130706/846cca62/attachment.sig>


More information about the coreboot mailing list