June 2013 - coreboot - mail.coreboot.org

Why is `MMCONF_SUPPORT_DEFAULT` not enabled for more devices?
by Paul Menzel June 29, 2013

June 29, 2013

Dear coreboot folks, looking at the differences of Intel’s SPI drivers, there is $ diff -u src/southbridge/intel/{bd82x6x,lynxpoint}/spi.c --- src/southbridge/intel/bd82x6x/spi.c 2013-06-29 11:54:25.304090457 +0200 +++ src/southbridge/intel/lynxpoint/spi.c 2013-06-29 11:54:25.308090366 +0200 @@ -34,19 +34,18 @@ #define min(a, b) ((a)<(b)?(a):(b)) #ifdef __SMM__ -#include <northbridge/intel/sandybridge/pcie_config.c> #define pci_read_config_byte(dev, reg, targ)\ - *(targ) = pcie_read_config8(dev, reg) + *(targ) = pci_read_config8(dev, reg) #define pci_read_config_word(dev, reg, targ)\ - *(targ) = pcie_read_config16(dev, reg) + *(targ) = pci_read_config16(dev, reg) #define pci_read_config_dword(dev, reg, targ)\ - *(targ) = pcie_read_config32(dev, reg) + *(targ) = pci_read_config32(dev, reg) #define pci_write_config_byte(dev, reg, val)\ - pcie_write_config8(dev, reg, val) + pci_write_config8(dev, reg, val) #define pci_write_config_word(dev, reg, val)\ - pcie_write_config16(dev, reg, val) + pci_write_config16(dev, reg, val) #define pci_write_config_dword(dev, reg, val)\ - pcie_write_config32(dev, reg, val) + pci_write_config32(dev, reg, val) #else /* !__SMM__ */ #include <device/device.h> #include <device/pci.h> […] due to the following commit [1]. commit 89f79a019fd049f26ed7bf40618ff960bd9e095e Author: Aaron Durbin <adurbin(a)chromium.org> Date: Wed Oct 31 23:05:25 2012 -0500 haswell: remove explicit pcie config accesses Now that MMCONF_SUPPORT_DEFAULT is enabled by default remove the pcie explicit accesses. The default config accesses use MMIO. Searching the code for that Kconfig variable, I get the following results $ git grep MMCONF_SUPPORT_DEFAULT src/Kconfig:config MMCONF_SUPPORT_DEFAULT src/arch/x86/include/arch/io.h:#if CONFIG_MMCONF_SUPPORT_DEFAULT src/arch/x86/include/arch/io.h:#if CONFIG_MMCONF_SUPPORT_DEFAULT src/arch/x86/include/arch/io.h:#if CONFIG_MMCONF_SUPPORT_DEFAULT src/arch/x86/include/arch/io.h:#if CONFIG_MMCONF_SUPPORT_DEFAULT src/arch/x86/include/arch/io.h:#if CONFIG_MMCONF_SUPPORT_DEFAULT src/arch/x86/include/arch/io.h:#if CONFIG_MMCONF_SUPPORT_DEFAULT src/cpu/amd/model_10xxx/Kconfig: select MMCONF_SUPPORT_DEFAULT src/mainboard/hp/dl165_g6_fam10/Kconfig:config MMCONF_SUPPORT_DEFAULT src/mainboard/supermicro/h8qgi/Kconfig: #select MMCONF_SUPPORT_DEFAULT #TODO enable it to resolve Multicore IO conflict src/mainboard/tyan/s2912_fam10/Kconfig: select MMCONF_SUPPORT_DEFAULT src/mainboard/tyan/s8226/Kconfig: #select MMCONF_SUPPORT_DEFAULT #TODO enable it to resolve Multicore IO conflict src/northbridge/amd/agesa/family10/northbridge.c:#if CONFIG_MMCONF_SUPPORT_DEFAULT src/northbridge/amd/agesa/family15/northbridge.c:#if CONFIG_MMCONF_SUPPORT_DEFAULT src/northbridge/amd/agesa/family15tn/northbridge.c:#if CONFIG_MMCONF_SUPPORT_DEFAULT src/northbridge/amd/amdfam10/northbridge.c:#if CONFIG_MMCONF_SUPPORT_DEFAULT src/northbridge/intel/gm45/Kconfig: select MMCONF_SUPPORT_DEFAULT src/northbridge/intel/gm45/northbridge.c:#if CONFIG_MMCONF_SUPPORT_DEFAULT src/northbridge/intel/haswell/Kconfig: select MMCONF_SUPPORT_DEFAULT src/northbridge/intel/haswell/bootblock.c: * setup the PCIEXBAR because CONFIG_MMCONF_SUPPORT_DEFAULT is set to src/northbridge/intel/haswell/bootblock.c: * CONFIG_MMCONF_SUPPORT_DEFAULT option to do PCI config acceses. src/northbridge/intel/haswell/northbridge.c:#if CONFIG_MMCONF_SUPPORT_DEFAULT src/northbridge/intel/i5000/northbridge.c:#if CONFIG_MMCONF_SUPPORT_DEFAULT src/northbridge/intel/i945/northbridge.c:#if CONFIG_MMCONF_SUPPORT_DEFAULT src/northbridge/intel/sandybridge/northbridge.c:#if CONFIG_MMCONF_SUPPORT_DEFAULT src/northbridge/intel/sch/northbridge.c:#if CONFIG_MMCONF_SUPPORT_DEFAULT src/northbridge/via/vx900/Kconfig: select MMCONF_SUPPORT_DEFAULT and I wonder why this option is not selected for more platforms or even enabled by default (for systems having `MMCONF_SUPPORT`)? Reading the AMD whitepaper it claims that the Linux kernel can determine if MMIO is there during runtime [3]. Though I have no idea if that is only possible because of the firmware setting things up correctly beforehand. Additionally for Intel systems `MMCONF_SUPPORT` (without `_DEFAULT`) seems to be selected in each mainboard where for AMD systems it is done under `src/cpu`. Thanks, Paul [1] http://review.coreboot.org/2618 [2] http://review.coreboot.org/#/c/3502/4/src/southbridge/intel/bd82x6x/spi.c [3] http://developer.amd.com/wordpress/media/2012/10/pci%20-%20pci%20express%20…

2 1

Should AMD CIMx SB900 work for the A68?
by Corey Osgood June 27, 2013

June 27, 2013

Hi, I'm currently looking into porting coreboot to the Biostar A68I-350, which has the E-350 CPU/NB and A68 southbridge. I'm not very familiar with the AMD end of coreboot or their naming system, but looking at the PCI IDs, it looks like the A68 is an SB900 (lspci -nn attached). I guess my questions boil down to: Is this right? Has the CIMx/SB900 code had any testing? Any problems with it? Is there any A68-specific errata that needs to be applied? Is this there any difference between this E-350 and the one that's supported on the ASRock board, with the A50M, being hudson m1 vs d3? Thanks, Corey

1 0

Re: [coreboot] [x60s] Its alive! Its alive!
by Stefan Tauner June 27, 2013

June 27, 2013

On Wed, 26 Jun 2013 15:59:54 -0700 Aaron Durbin <adurbin(a)chromium.org> wrote: > On Wed, Jun 26, 2013 at 3:58 PM, Stefan Tauner > <stefan.tauner(a)student.tuwien.ac.at> wrote: > > One thing he did not mention is that cbmem seems to not work on his > > device. I don't know anything about cbmem but I looked into it a bit. > > mapping the first address (0) works fine, but cbmem does not find > > anything there and the mapping of the second address (0xf0000) fails > > then with: > > Looking for coreboot table at f0000 > > Mapping 1MB of physical memory at 0xf0000. > > > > any ideas why this could happen? > > Could someone post the full serial log from the boot? I could take a look then. Guess what we tried to gather from cbmem ;) I have not followed the discussion in detail, but IIRC he has no docking station and hence no serial port... and most probably no USB debugging device either. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 1

[x60s] Its alive! Its alive!
by oneofthem June 26, 2013

June 26, 2013

Well, I finally did it. A working coreboot install on my x60s. (model 1702) First I had to find out what chip I had inside my x60s, I opened it (not easy, I can tell you that) and eventually found it next to a large chip with lenovo marking on it and a small toshiba chip on the underside of the pcb. It had a large black plastic sheet over it which I pulled off. The actual chip itself had a little sticker on it with the text "KS2" if I remember correctly. I dabbed a ear cleaning swab into rubbing alcohol. That applied onto the chip with a bit of scratching with a pin got the sticker off. After a lot of looking with a magnifying glass (its so tiny!) I found that it was marked "MX25L1605D". Then I had to grab the flashrom source and edit it accordingly. I actually had to edit ".name = "MX25L1605" instead of ".name = "MX25l1605D" because 605D falls under the 605 family, so 605D does not exist as a stand alone ruleset. I changed probe to "probe_spi_res1" model_id to "0x14" (will be different if you have a different chip of course) write to "spi_chip_write_1" So then I ran make and it turned out that I needed to install pciutils, pciutils-dev and zlib1g-dev. So I did and it worked after that. Next up was making coreboot.rom. I just installed libncurses-dev, iasl and libc6-dev-i386 and cloned the coreboot git repo. Did make menuconfig, chose lenovo as the mobo maker, chose the x60, 2mb chip size (used default payload, seabios), saved settings and ran make. For bucts I just downloaded it and ran make. Now that I had everything I simply did as the wiki page said and surprisingly, everything worked. Well, almost everything. I didn't add in the vga rom so I don't get graphics preboot (which is to be expected) and sometimes the mouse and keyboard works, sometimes it doesn't. Sometimes one works and the other doesn't, I'll have to see if there a pattern sometime but it seems to work more often than not which is good. All in all, with lots of help from the coreboot and flashrom mailing lists + irc I managed to flash coreboot successfully. Thanks everybody who helped me along the way (you know who you are) and I hope this inspires others to flash coreboot too.

3 2

Re: [coreboot] coreboot on x60s
by Denis 'GNUtoo' Carikli June 26, 2013

June 26, 2013

On Mon, 24 Jun 2013 12:55:16 +1000 oneofthem <oneofthem(a)lavabit.com> wrote: > On Sun, Jun 23, 2013 at 02:09:57PM +0200, Denis 'GNUtoo' Carikli > wrote: > > If you're not confident with the instructions provided at > > https://www.coreboot.org/Lenovo_x60x you could try to find someone > > in your area that knows well coreboot and is able to do them for > > you, if there is no one in your area that knows corbeoot, you could > > still go on but you have the risk of bricking your laptop if theses > > instructions are not followed correctly(it happened to several > > people already, many also succedded though), if you brick the > > laptop any hope is not lost though: There is still a way to recover > > but it require to disassemble the laptop, buy a pomona clip and get > > an external programmer(you may already have one without knowing > > it), to connect them together, then to clip the pomona clip to the > > flash chip,to connect the external programmer to another computer > > that can run flashrom,to run flashrom and make it flash the new > > image trough the external programmer (for instance a normal > > coreboot image that is proven to work or the backup of the BIOS you > > have). > > > > Denis. > > Thanks, I see you attended > http://libreplanet.org/wiki/LibrePlanet:Conference/2013/Program/Coreboot_In… > How'd it go? The first laptop was flashed correctly. The user however is not so happy with the state of coreboot on his laptop: he has not the same battery than the person who did the original port and he seem to have some issues related to that, and complained about the heat produced by the X60(however it's not proven that the heat is coreboot's fault: it could well be there with the default BIOS too...). I spent a lot of time on the setup on that laptop(make crossgcc takes ages on the X60, and I had to do all the setup like setting up serial etc...). The second laptop was a laptop belonging to the FSF: I started working on it right after having flashed the first laptop(the one mentioned above) and confirmed that it was working. The setup also took quite some time, and I had to interrupt because I had to do my presentation on Replicant, so took my hardware and went to do the presentation. The coreboot installation room was then used for lightning talks. Then I had to switch to another more general puspose room(There was some mediagoblin developers(including its lead developper) inside that room working on mediagoblin, and also a 3D printer(the LulzBot AO-101 printer which was the first device to have the Respects Your Freedom FSF certification [1] and at least one person working for the company producing that 3D printer). The issue is that I was really short on time: The conference was ending and some rooms were already taken back by the courses: for instance we forgott some tools in the coreboot room(that later became the lightning talk room), and when I went back there after the Replicant talk and the end of the lightning talks to get the tools back, there was a course inside... So I tried flashrom with the modifications that I made on the first laptop I flashed, and it didn't detect the flash chip... So I tried a patch[2] I was given on the #flashrom IRC channel on Freenode to make flashrom work but I was really short on time... So I followed the procedure [3] again with the flashrom patched with the IRC patch. At some point I reached the instruction number 7 which says: " Run flashrom -p internal -w coreboot.rom This will be slow, it will output errors for addresses 0x0 and 0x1f0000 when working with a 2 Mbyte flash chip, and it will say "FAILED!" at the end, see Peter's mail before you panic. " Which resulted in [4]. The log seemed a bit strange but the instructions said that it had to say FAILED. I was also short on time as I mentioned before. so I went on and powered off the computer as the instruction number 8 suggest: " Power cycle the machine (i.e. a cold boot, not just a reboot), now starting with coreboot " Then I powered the machine on again and there was nothing on the serial port, and the display was black: the machine was not booting. Then ward from the FSF ordered a pomona clip, I guess it took quite some time to arrive, he wired it to a bus pirate, disassembled the laptop and reflashed, but there was still nothing on serial. Then I remembered that the BUCTS register was still in the state resulting from bucts 1, and since he flashed an unmodified(all the dd tricks of the howto[3] were not done again). So I told him to remove the CMOS battery(I previously told him not to remove it because it would loose the coreboot settings). Since the CMOS battery was removed, the coreboot settings were lost, and since at that time the patch adding a cmos.default for the X60 was not done yet, it resulted in having nothing on serial(because serial was at a very low speed and no characted would show at 115200 bauds) and nothing on the screen either(because coreboot was too slow, because the serial was at the very low speed, beside at that time there was no native graphics initialization at all, and he didn't use the non-free VGA option rom for obvious reasons(it's non-free)). That is because removing the CMOS battery resulted in corrupt CMOS area, and coreboot used the corrupted values in romstage. So he seem to have rebooted several times and at the end there was something on the serial port: In ramstage(in the mainboard specific code), coreboot was resetting sane default values for the CMOS/nvram parameters... Nowadays the X60, M4A785T-M and Alix.1C have a cmos.default in the coreboot tree, which get included in the coreboot image and used during the romstage to reset sane defaults if coreboot detects that the CMOS area is corrupt... Before it happened way too late, in ramstage... > > >A special image that contains everything on an USB key will have to > >be prepared to make the installation faster. > Did this ever happen? No, Since the number of devices to flash was small I did everything on the target laptops so the user would be sure to have every source. References: ----------- [1] http://www.fsf.org/resources/hw/endorsement/respects-your-freedom [2] http://paste.flashrom.org/view.php?id=1610 [3] https://www.coreboot.org/Lenovo_x60x [4] http://paste.flashrom.org/view.php?id=1609 Denis.

1 0

tianocore state?
by Gerd Hoffmann June 25, 2013

June 25, 2013

Hi, What is the state of the tianocore port for coreboot? Looking at https://github.com/pgeorgi/edk2/commits/coreboot-pkg there has been no activity for a few months ... I've rebased the patches (https://github.com/kraxel/edk2/commits/coreboot) fixed two little isses and played around a bit with it. It doesn't build for X64. Seems some tricks it pulls on 64bit (for communication with 32bit coreboot?) stopped working. IA32 boots fine in qemu, but it looks like it never ran on anything but qemu. No patches showed up on the edk2 mailing list. Hmm, whats up? cheers, Gerd PS: http://www.kraxel.org/repos/ has rpms with fresh qemu firmware builds, coreboot included.

3 6

T60 issues
by Gerd Hoffmann June 25, 2013

June 25, 2013

Hi, Two little issues with T60: First, the keyboard doesn't work on cold boots. Second, the express card slot doesn't work. Coreboot doesn't see the card inserted there, and Linux doesn't either once the system is up. It also doesn't see it when hotplugged. Anyone has a clue what is going on here? cheers, Gerd

2 1

Re: [coreboot] Trouble with coreboot for Roda RK9
by Nico Huber June 25, 2013

June 25, 2013

Am 25.06.2013 14:07, schrieb Dmitry Bagryanskiy: Hello Dmitry, welcome to the coreboot mailing list. > Could you please help me to solve some problems? > Laptop: Roda RK9 > Socket: mPGA479M > > The problem is that when loading coreboot, "Unsupported FSB clock" is > written in the debug and the circuit board is turn off. We knew that the > function MCHBAR32(CLKCFG_MCHBAR) returns 0xffffffff which is cirtanly not > correct. Can this problem be connected with the fact that in this coreboot > version Socket BGA956 is used for Roda RK9 and Socket mPGA479M is on the > circuit board. Within coreboot, the socket option is just used to indirectly select the supported CPUs. When we worked on the RK9 support, we were just lazy and selected SOCKET_BGA956 to actually select MODEL_1067X. This should (hopefully) work with any processor listed in [1]. Just to be sure, which processor is socketed in your RK9? However, the selection of a wrong socket or cpu model shouldn't cause the problem you're describing. Maybe I can identify something that differs from the RK9 we used during development. Please paste the output of the following commands after booting to Linux with the legacy BIOS: dmidecode lspci -nn lspci -xxx -s 0:00.0 Regards, Nico [1] http://download.intel.com/design/mobile/specupdt/320121.pdf

1 0

Trouble with coreboot for Roda RK9
by Dmitry Bagryanskiy June 25, 2013

June 25, 2013

Could you please help me to solve some problems? Laptop: Roda RK9 Socket: mPGA479M The problem is that when loading coreboot, "Unsupported FSB clock" is written in the debug and the circuit board is turn off. We knew that the function MCHBAR32(CLKCFG_MCHBAR) returns 0xffffffff which is cirtanly not correct. Can this problem be connected with the fact that in this coreboot version Socket BGA956 is used for Roda RK9 and Socket mPGA479M is on the circuit board. Best regards, Dmitry Bagryanskiy

1 0

Re: [coreboot] Change in coreboot[master]: Asus F2A85-M: Activate IOMMU support
by David Hubbard June 24, 2013

June 24, 2013

Hi all, To answer http://review.coreboot.org/3517 about what the vendor BIOS does for the IOMMU, here are my kernel logs (with the IOMMU enabled) Please note: Command line: ... iommu=pt I had to do that to work around (more like, bury my head in the sand) the problem with the on-board RTL8111/8168F, which trips over the IOMMU when utilization gets near 100% gigabit speed. I put the details on kernel bugzilla https://bugzilla.kernel.org/show_bug.cgi?id=55841 David

1 0