June 2013 - coreboot - mail.coreboot.org

coreboot build failing
by oneofthem July 8, 2013

July 8, 2013

Hey, I'm following this guide to build coreboot http://www.coreboot.org/Build_HOWTO I've done it all up to just running make. I chose the default mainboard vendor and model because I don't really know and 2MB chip size with SeaBIOS. I'm building for my x60s. So I run make and this is what I get. oneofthem@oneofthem:~/coreboot$ make GEN build.h CC romstage.inc src/mainboard/emulation/qemu-i440fx/romstage.c: In function ‘main’: src/mainboard/emulation/qemu-i440fx/romstage.c:38:6: error: variable ‘cbmem_was_initted’ set but not used [-Werror=unused-but-set-variable] int cbmem_was_initted; ^ cc1: all warnings being treated as errors make: *** [build/mainboard/emulation/qemu-i440fx/romstage.pre.inc] Error 1

3 4

Re: [coreboot] T60 issues
by Gerd Hoffmann July 7, 2013

July 7, 2013

Hi, > $ ./encodeint.py ps2-keyboard-spinup 2000 Thanks, works. Two seconds delay looks excessive, but it seems really be needed, trying only one second gives me a non-working keyboard again. cheers, Gerd

3 2

Re: [coreboot] ASUS m5a88-v AGESA port (bulldozer)
by darkdefende＠gmail.com July 4, 2013

July 4, 2013

Idwer Vollering writes: > Done. Thanks for attaching the log for me. Some recent commits to coreboot master seems to have solved my problem with the pci scan hang. Now I don't have to hack around it any more. However it still freezes after it's done (?) loading seabios. I have uploaded my changes to https://github.com/DarkDefender/coreboot if anyone want's to look at them. I've tried to enable more debugging options in the "OptionsIds.h" for AGESA but it doesn't seem to do anything. The asserts are triggered druing boot are still the same as before. I've tried to look at it but I didn't really understand what I should change to solve them.

2 1

Enabling Dediprog by default in flashrom
by Stefan Tauner July 1, 2013

July 1, 2013

Hi, the release of flashrom 0.9.7 is imminent and I would really like to enable the Dediprog programmer by default. Carl-Daniel informed me that the only problem is that we do not know which opcode is actually used for reading on the SPI bus. It could be that we initiate a fast read (0x0b) instead of a normal read (0x03). This would work with the majority of flash chips but would not with others where flashrom should normally work. Since we are not sure we don't want to enable it without further consideration/testing/warning messages. Furthermore not all chips supporting fast read have this fact noted in their datashets. So testing any apparently non-fast read chip does not suffice. We would rather be able to check the opcode on the SPI bus with a logic analyzer directly. Are there any Dediprog users who can help us with that please? -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 1

Re: [coreboot] Trouble with coreboot for Roda RK9
by Nico Huber July 1, 2013

July 1, 2013

Am 25.06.2013 23:08, schrieb Dmitry Bagryanskiy: Hello Dmitry, > My processor type is Intel Core 2 Duo P8400, socket mFCPGA479M IIRC, I've seen at least one RK9 with this CPU running coreboot. Looking through your log files, I didn't find anything suspicious. I'll try to check if current upstream coreboot really works on our RK9, tomorrow. Meanwhile, could you post your coreboot .config? And when responding, please always cc the coreboot mailing list. Nico

2 1

Re: [coreboot] No VGA output on e350m1 after flashing. what to do?
by Reiner Luett June 30, 2013

June 30, 2013

Hi! On 30.06.2013 22:37, Christian Weinz wrote: > Yepp, seems like without more hardware I can't solve this :( It looks like that. Are you living in Germany? If you are buying a programmed chip on eBay it's about 11 EUR: http://www.ebay.de/itm/200936096032 I only have two of them, but I could send you one for the half with AMI UEFI BIOS or a working coreboot image. Maybe you try first the PCIe videocard. It should be fine. Regards, Reiner --

1 0

Re: [coreboot] No VGA output on e350m1 after flashing. what to do?
by Reiner Luett June 30, 2013

June 30, 2013

Hello Christian, On 30.06.2013 21:41, Christian Weinz wrote: > I simply forgot to extract the vga bios. now I don't know how to fix it > without graphical output from the machine. Really, you've tried it only with the winbond flashchip onboard. :-) Do you have another flashchip? Otherwise it should be possible to boot the OS with a LIVE CD via USB. You need a ssh daemon running. Maybe it's possible to log into it via serial console. You would need a null modem cable and something for the COM port pin header. Regards, Reiner --

2 1

No VGA output on e350m1 after flashing. what to do?
by Christian Weinz June 30, 2013

June 30, 2013

Hello everybody, I just compiled coreboot with seabios as payload for my asrock/e350m1. Compilation and flashing (with flashrom) worked fine. After rebooting the system seems to start fine as all leds are blinking as they do normally. However, as I don't have video output I can't configure the bios nor specify from where to boot. Maybe I didn't include the VGA option in the make menuconfig process. How can I solve this problem? Regards, Christian Weinz

1 0

How to best integrate misspelling script?
by Paul Menzel June 29, 2013

June 29, 2013

Dear coreboot folks, searching for a way to automatically find misspellings I found a post by Jim Meyering on Fedora’s devel list [1], where he suggests to use the project misspellings [2]. Testing this with a simple $ find src/coreboot/ -name '*.c' | ./misspellings -f - it indeed finds a lot of misspelling in our code, but as expected there are also false positives. I am going to send in a patch with the fixes after reviewing the list to omit the false positives. The question is, how to hook this up into our infrastructure. Jim suggests a `make check` rule. The downside is that this would need to be run manually by the user. Running it automatically on every commit by placing a script in `util/lint` to only check changed files would be feasible, but possible false positives are a problem though. Do you have an idea, how to work around this problem? There is the `--no-verify` switch for `git commit` to not run the hooks, but this also ignores the commit-msg hooks, which then is not able to add a Change-Id for Gerrit. Thanks, Paul [1] https://lists.fedoraproject.org/pipermail/devel/2012-June/168159.html [2] http://github.com/lyda/misspell-check

3 7

Re: [coreboot] Change in coreboot[master]: Asus F2A85-M: Activate IOMMU support
by Paul Menzel June 29, 2013

June 29, 2013

Dear coreboot folks, Am Montag, den 24.06.2013, 13:45 -0600 schrieb David Hubbard: > 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 thank you a lot for collecting logs while Rudolf is busy. Also thank for sending the logs with Radeon instead FGLRX. For the archive, I would deem it a good thing to CC the list too. Am Freitag, den 28.06.2013, 19:29 -0600 schrieb David Hubbard: […] > Attached are two logs, the first one is the one you requested (with the > parameter "iommu=pt" removed from the kernel command line). It does look > like there's an interesting line in there for PCI device 1:0.0, the APU > integrated GPU: > > [ 0.525376] AMD-Vi: Using passthrough domain for device 0000:01:00.0 > > The second log is with "iommu=pt" added back. In both cases, I loaded the > radeon open source driver this time, instead of fglrx. 1. Please keep all in mind, that Rudolf tested with Linux 3.10-rc1 and you are using 3.8.11. 2. Looking through the log, the vendor BIOS is not perfect either. ;-) […] [ 0.000000] Checking aperture... [ 0.000000] No AGP bridge found [ 0.000000] Node 0: aperture @ 0 size 32 MB [ 0.000000] Your BIOS doesn't leave a aperture memory hole [ 0.000000] Please enable the IOMMU option in the BIOS setup [ 0.000000] This costs you 64 MB of RAM [ 0.000000] Mapping aperture over 65536 KB of RAM @ 84000000 [ 0.000000] Memory: 15783604k/18071552k available (3442k kernel code, 1869616k absent, 418332k reserved, 3061k data, 516k init) [ 0.000000] SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 […] So back to the problem, the solution to the PAGE_FAULT with coreboot seems “simple”. Using the vendor BIOS the graphics device (1:00.0) is put into passthrough domain automatically while with coreboot it is not. `amd_iommu.c` prints the message. (The line numbers are from Linux 3.10-rc7.) AMD-Vi: Using passthrough domain for device 0000:01:00.0 $ nl -ba drivers/iommu/amd_iommu.c […] 3028 /* 3029 * The function for pre-allocating protection domains. 3030 * 3031 * If the driver core informs the DMA layer if a driver grabs a device 3032 * we don't need to preallocate the protection domains anymore. 3033 * For now we have to. 3034 */ 3035 static void __init prealloc_protection_domains(void) 3036 { 3037 struct iommu_dev_data *dev_data; 3038 struct dma_ops_domain *dma_dom; 3039 struct pci_dev *dev = NULL; 3040 u16 devid; 3041 3042 for_each_pci_dev(dev) { 3043 3044 /* Do we handle this device? */ 3045 if (!check_device(&dev->dev)) 3046 continue; 3047 3048 dev_data = get_dev_data(&dev->dev); 3049 if (!amd_iommu_force_isolation && dev_data->iommu_v2) { 3050 /* Make sure passthrough domain is allocated */ 3051 alloc_passthrough_domain(); 3052 dev_data->passthrough = true; 3053 attach_device(&dev->dev, pt_domain); 3054 pr_info("AMD-Vi: Using passthrough domain for device %s\n", 3055 dev_name(&dev->dev)); 3056 } […] As no options were passed, the variable `dev_data->iommu_v2` seems to make the difference. $ nl -ba drivers/iommu/amd_iommu_init.c […] 1185 if (!(iommu->cap & (1 << IOMMU_CAP_IOTLB))) 1186 amd_iommu_iotlb_sup = false; 1187 1188 /* read extended feature bits */ 1189 low = readl(iommu->mmio_base + MMIO_EXT_FEATURES); 1190 high = readl(iommu->mmio_base + MMIO_EXT_FEATURES + 4); 1191 1192 iommu->features = ((u64)high << 32) | low; […] 1214 if (iommu_feature(iommu, FEATURE_GT) && 1215 iommu_feature(iommu, FEATURE_PPR)) { 1216 iommu->is_iommu_v2 = true; 1217 amd_iommu_v2_present = true; 1218 } […] `iommu_feature()` is implemented as follows. $ nl -ba drivers/iommu/amd_iommu_proto.h […] 72 static inline bool is_rd890_iommu(struct pci_dev *pdev) 73 { 74 return (pdev->vendor == PCI_VENDOR_ID_ATI) && 75 (pdev->device == PCI_DEVICE_ID_RD890_IOMMU); 76 } 77 78 static inline bool iommu_feature(struct amd_iommu *iommu, u64 f) 79 { 80 if (!(iommu->cap & (1 << IOMMU_CAP_EFR))) 81 return false; 82 83 return !!(iommu->features & f); 84 } […] So if the former is correct, for some reason `FEATURE_GT` or `FEATURE_PPR` are not enable when running with coreboot. $ nl -ba drivers/iommu/amd_iommu_types.h […] 83 /* Extended Feature Bits */ 84 #define FEATURE_PREFETCH (1ULL<<0) 85 #define FEATURE_PPR (1ULL<<1) 86 #define FEATURE_X2APIC (1ULL<<2) 87 #define FEATURE_NX (1ULL<<3) 88 #define FEATURE_GT (1ULL<<4) 89 #define FEATURE_IA (1ULL<<6) 90 #define FEATURE_GA (1ULL<<7) 91 #define FEATURE_HE (1ULL<<8) 92 #define FEATURE_PC (1ULL<<9) 93 94 #define FEATURE_PASID_SHIFT 32 95 #define FEATURE_PASID_MASK (0x1fULL << FEATURE_PASID_SHIFT) 96 97 #define FEATURE_GLXVAL_SHIFT 14 98 #define FEATURE_GLXVAL_MASK (0x03ULL << FEATURE_GLXVAL_SHIFT) 99 100 #define PASID_MASK 0x000fffff […] Probably adding some debug output to find out what features are enabled and disabled would be good. But maybe somebody already knows the solution from the above information. Thanks, Paul

1 0