Re: [coreboot] ASUS m5a88-v AGESA port (bulldozer): Linux does not set up SATA drives
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
I did what David suggested and dumped the dsdt data. I then noticed that I had some things wrong in the routing.asl file so I fixed that. I also split the dsdt.asl file like the asrock/e350m1 and others have done. When I did that I took a closer look at some of the changes I've done and changed them to be more in line with what's in the asrock board code. After this the "Bogus APIC", "_OSC" and the routing errors seems to be solved. However I still get the sata error... The "BAR can't assign mem pref" I have yet to solve. But I don't know were I should look for a solution. I've seen some logs from other coreboot boards where is says "BAR 15: assigned [mem 0x....". However the original bios doesn't seem to have any of this. Besides that I've also tried to boot with the kernel parameters: "libata.force=nosrst" and "noapic acpi=off pci=nomsi" When I force no soft reset it errors out with this instead: ata1.00: qc timeout (cmd 0xec) ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4) Paul Menzel writes:
Could you attach a diff of the two `kernel_log.txt` (without the time stamps) please?
Sure, "kernel_v_notime" is the original bios in the attached diff. This diff is after I fixed the above errors.
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. Do you know any dists that comes with serial port support? I tried fedora and ubuntu quickly but when I tried to boot them with the grub2 payload I didn't get any output. I don't have a spare GPU so because I can't get the onboard one working I have to stick to the serial port...
Maybe a newer Linux kernel also helps there. Perhaps. But it should work because it works with vanilla bios, no?
A little more progress today. I noticed that not all init functions for sb800 were called. It seems like they should be be called from: src/northbridge/amd/agesa/family15/northbridge.c because that's where they are called from in f14 code. So I added that and now it seems solve some problems but the SATA softreset problem still remains. I added "pci=nocrs" to the kernel boot option and the BAR errors aren't there anymore. I have attached a new diff and logfile of the kernel output. To me it doesn't seem to be any more obvious errors so I would be really grateful for any help or hints at all. I have managed to boot from usb sticks with both fedora and ubuntu. They seem to be able to mount the usb stick and boot to desktop. However because I'm stuck with serial and they don't seem to have any serial login I can't confirm or dump lspci etc. But I can see that they respond to the power button event and doesn't seem like they hang or crash. Does anybody know a dist where serial console login is on by default?
Dear Sebastian, Am Montag, den 08.07.2013, 20:59 +0200 schrieb darkdefende@gmail.com: […]
Does anybody know a dist where serial console login is on by default?
take a look at the Grml live system [1]. The cheatcodes list a `serial` option you can pass to the Linux kernel by adding it the the Linux kernel command line [2]. Thanks, Paul [1] http://grml.org/ [2] http://git.grml.org/?p=grml-live.git;a=blob_plain;f=templates/GRML/grml-chea...
Paul Menzel writes:
take a look at the Grml live system [1]. The cheatcodes list a `serial` option you can pass to the Linux kernel by adding it the the Linux kernel command line [2].
Thanks,
Paul
[1] http://grml.org/ [2] http://git.grml.org/?p=grml-live.git;a=blob_plain;f=templates/GRML/grml- cheatcodes.txt;hb=HEAD
I managed to boot into grml with serial. I had to hexedit the .iso file to change the isolinux.cfg file to switch on serial output. I have copied the lspci output. The "lspci -tnvv" is the same except 14.2 (HDA) is missing. But that's because I disabled it in devicetree.cb when I tested some other stuff. However the "lspci -vvvxx" out differs somewhat and I wonder if there is anything that I should look into. I have attached three file. lspci-vvvxx.txt for coreboot output and lspci-vvvxx_org.txt for vendor bios output and a diff for them.
Dear Sebastian, Am Montag, den 08.07.2013, 20:59 +0200 schrieb darkdefende@gmail.com: […]
I have attached a new diff and logfile of the kernel output.
as requested in #coreboot on <irc.freenode.org> yesterday, please find the Linux kernel log attached. This is Debian Sid/unstable with a self-built Linux 3.10 and Alex Deuscher’s drm-next-3.11 branch for AMD/ATI DPM (Dynamic Power Management) merged. The following command was used to strip the date and hostname. $ sed -i 's,[^\[]*,,' /tmp/20130708--ASRock-E350M1--kern.log coreboot is built from master 0bd5dff58cb43b307bcb02ac6baa436a525a5025 w83627hf/acpi: Fix type error in floppy drive enumeration code with the following patches applied from Gerrit. $ git log --format=oneline origin/master..HEAD 34c53aa928401a03caac99e1ca8ed2223e424cdd w83627hf/acpi: Move floppy drive enumeration from _INI into _FDE. a4de06ba1694c38b7d00ef7fd0b7e4cedbf14d0b w83627hf/acpi: Fix endianess error in floppy drive enumeration code 605a9419e16d85b64069b195bb1fced029c5b7f1 w83627hf/acpi: Fix logical device power down in ACPI fcb40c4883d507ee51f8ed29843ccb7666b8e7e8 w83627hf/acpi: Fix offset of logical device activation f1531ea02d61ccaed81f4315aa04fc4e28db7092 ASRock E350M1: Include ASL file of Winbond W83627HF in the DSDT 0bfdf248f687827988daf0d43a0896f613a349e3 Winbond W83627HF: ACPI: Make `AddressMax` a multiple of `AddressAlignment` […] […] Thanks, Paul
participants (2)
-
darkdefende＠gmail.com -
Paul Menzel