coreboot March 2018

coreboot@coreboot.org

62 participants
103 discussions

Gigabyte MB to Test
by Jeff Ausfeld 14 Mar '18

14 Mar '18

Hi Coreboot Team, I have several of the following boards, and it badly needs a Bios overhaul as I'm trying to get a Compex card or pretty much any Qualcomm chip to properly enumerate. # dmidecode 3.0 Getting SMBIOS data from sysfs. SMBIOS 3.0.0 present. Handle 0x0002, DMI type 2, 15 bytes Base Board Information Manufacturer: GIGABYTE Product Name: MDH11HI-SI Version: 1.x Serial Number: Default string Asset Tag: Default string Features: Board is a hosting board Board is replaceable Location In Chassis: Default string Chassis Handle: 0x0003 Type: Motherboard Contained Object Handles: 0 I did upgrade the BIOS from the shipped V5 to V9. It made little difference. I can setup whatever access you need, and nothing to worry about breaking. Let's have some fun. Regards, Jeff.

1 0

Re: [coreboot] [PATCH 0/5] coreboot table bus and framebuffer driver
by Julius Werner 14 Mar '18

14 Mar '18

[resend in plain text] > It would be great to get some of the google developers to ack these, as > this touches their code... From the coreboot point of view I guess we're fine with it since it claims to maintain all of the existing functionality. It's just changing the kernel-level plumbing for these drivers and I don't really have the expertise to comment on whether this is better or worse than the old code (maybe Dmitry or Guenter will?). It seems a little odd to me to call this a "bus", but if we think that's the most fitting abstraction the kernel has for it, I'm okay with that. All I care about is that it will work (in all combinations... e.g. regardless of probe order and even if some parts are compiled as modules and loaded/unloaded at runtime).

1 0

[PATCH 0/5] coreboot table bus and framebuffer driver
by Samuel Holland 14 Mar '18

14 Mar '18

On many systems, coreboot[1] firmware can initialize graphics hardware and set up a high-resolution linear framebuffer. It exports information about this framebuffer, along with various other information, in a table discoverable via ACPI or a device tree. coreboot also supports booting Linux directly from flash as a "payload". Projects such as Heads[2], u-root[3], and petitboot[4] provide a minimal userland that can then be used to chainload (via kexec) into a full Linux system loaded from disk or over the network. Fitting even a minimal Linux system on an SPI flash chip is challenging. Reusing the framebuffer setup from coreboot provides an enormous benefit to these projects by allowing them to omit full graphics drivers from their kernel builds. It also speeds up boot times by avoiding duplicated effort, and because coreboot's graphics initialization is often much faster than the Linux driver. Patch 1 of this series expands coreboot table support into an enumerable bus that devices can hang off of. Patches 2-3 convert the existing drivers to use the new bus structure instead of ad-hoc platform devices, and patch 4 removes the old coreboot_table_find function. Finally, patch 5 adds a new driver for the coreboot-initialized framebuffer. It improves on earlier work[5] by being architecture- independent and not needing to scan through low memory. This patchset has been tested on a Lenovo ThinkPad X220, and earlier versions of these patches have been tested by various members of the coreboot community on other hardware. [1]: https://www.coreboot.org/Welcome_to_coreboot [2]: https://github.com/osresearch/heads [3]: https://github.com/u-root/u-root [4]: https://www.kernel.org/pub/linux/kernel/people/geoff/petitboot/petitboot.ht… [5]: https://mail.coreboot.org/pipermail/coreboot/2014-September/078551.html Samuel Holland (5): firmware: coreboot: Expose the coreboot table as a bus firmware: memconsole: Probe via coreboot bus firmware: vpd: Probe via coreboot bus firmware: coreboot: Remove unused coreboot_table_find firmware: coreboot: Add coreboot framebuffer driver drivers/firmware/google/Kconfig | 8 ++ drivers/firmware/google/Makefile | 1 + drivers/firmware/google/coreboot_table-acpi.c | 2 +- drivers/firmware/google/coreboot_table-of.c | 2 +- drivers/firmware/google/coreboot_table.c | 130 ++++++++++++++++++------- drivers/firmware/google/coreboot_table.h | 72 +++++++++++--- drivers/firmware/google/framebuffer-coreboot.c | 115 ++++++++++++++++++++++ drivers/firmware/google/memconsole-coreboot.c | 49 ++++------ drivers/firmware/google/vpd.c | 43 +++----- 9 files changed, 313 insertions(+), 109 deletions(-) create mode 100644 drivers/firmware/google/framebuffer-coreboot.c -- 2.13.6

3 7

Re: [coreboot] Intel Reference Board doesn't work after inserting INT 15h/86h into Flat32.asm
by Igor Skochinsky 14 Mar '18

14 Mar '18

Hello Toan, Wednesday, March 14, 2018, 10:13:13 AM, you wrote: TLm> I'm so sorry if this question does not really relate to TLm> Coreboot. But I'm facing a serious problem and trying to get help TLm> from you who have excellent knowledge about BIOS and HW. I'll answer just this one time. Please use your Intel support options for non-coreboot related issues. TLm> I have an Intel Reference Board. I was trying to force BIOS to wait 1 second in SEC phase. TLm> I inserted these assemble code (BIOS wait function) into very TLm> first of ProtectedModeEntryPoint in Flat32.asm file: TLm> MOV CX, 0FH TLm> MOV DX, 4240H TLm> MOV AH, 86H TLm> INT 15H TLm> Then, the board stopped working. Status code showed "00". TLm> Even when I re-flashed its original BIOS, it's still not worked. TLm> Could anyone please help me to figure out what's happen here? TLm> I appreciate your helps. The SEC phase is the earliest stage of the firmware init. The CPU has been just reset; there are no BIOS services available and the interrupt table has not even been set up yet (no RAM either), so the CPU hangs when you try to invoke an interrupt with a non-existing handler. The best you can do in this situation is probably a counted loop (with a big counter because the modern CPUs are very fast), maybe with some "out" instructions to an unused port (or even 80h) to slow it down a little. I don't know why original BIOS did not work, maybe verify that you flashed the correct binary. -- WBR, Igor mailto:skochinsky@mail.ru

1 0

"pci=nomsi" parameter for PCIe devices
by Аладышев Константин 14 Mar '18

14 Mar '18

Hello! I use PCIe device xr17v358 to make UARTs on my motherboard (https://www.exar.com/product/interface/uarts/pcie-uarts/xr17v358). But UARTs work correctly only if I boot Linux kernel with "pci=nomsi" parameter. I can always see and operate with PCIe configuration space correctly, but normally (without "pci=nomsi" parameter) xr17v358 driver never enters its interrupt routine, that is used for transmit/receive characters. Can this somehow be a BIOS issue or it is more likely a xr17v358 driver issue? Best Regards, Aladyshev Konstantin

1 0

Intel Reference Board doesn't work after inserting INT 15h/86h into Flat32.asm
by Toan Le manh 14 Mar '18

14 Mar '18

Hello everyone, I'm so sorry if this question does not really relate to Coreboot. But I'm facing a serious problem and trying to get help from you who have excellent knowledge about BIOS and HW. I have an Intel Reference Board. I was trying to force BIOS to wait 1 second in SEC phase. I inserted these assemble code (BIOS wait function) into very first of ProtectedModeEntryPoint in Flat32.asm file: MOV CX, 0FH MOV DX, 4240H MOV AH, 86H INT 15H Then, the board stopped working. Status code showed "00". Even when I re-flashed its original BIOS, it's still not worked. Could anyone please help me to figure out what's happen here? I appreciate your helps. Thanks & BRs, Toan

1 0

Re: [coreboot] Coreboot + Depthcharge
by Peter Stuge 13 Mar '18

13 Mar '18

Marshall Dawson wrote: > 1. You can skip this step in your instructions. Instead, when running > make menuconfig, look in Chipset / ChromeOS and select "Build for > ChromeOS". This should cause Depthcharge to appear as a payload option. I think this is a design issue in coreboot that ought to be fixed. Depthcharge can be useful on its own, it should not be artificially tied down. //Peter

2 1

ASUS PIKE (LSI SAS 2008) are for sale on fleabay for $30/ea (for the KGPE-D6/KCMA-D8)
by Taiidan＠gmx.com 13 Mar '18

13 Mar '18

They are for the silly ASUS PIKE slot at the end of the board - this seems to be a good deal for a LSI SAS 2008 chipset and probably avoids the counterfeits that plague the used market as this is an obscure part. LSI SAS 2008 Features: IT Mode. SR-IOV with ARI (if coreboot ever supports it) 16 VF functions. FLR (function level reset) for pain free IOMMU VM assignment Works without Option ROM loading Notes: I thought the SAS 2308 was the first with SR-IOV but this one apparently has it too according to LSPCI, I have never used SR-IOV with a HBA/RAID card but the idea seems to be that you can assign RAID arrays or individual drives to a VF then assign the VF to a VM. You screw in one end of the massive heatsink via the motherboard screw in that location and the other end clips on to the PCI-e slot (make sure it properly clips and is properly seated, I had a difficult time with this and had to remove and re-attach one of the clip screws to get it to seat) I advise re-flashing this in a VM on a PC without option ROM support, as all the sellers are chinese. Offical firmware (hard to find this link) https://docs.broadcom.com/docs/9211_8i_Package_P20_IR_IT_FW_BIOS_for_MSDOS_… Unfortunately they have proprietary firmware like all SAS cards but at least as they are used you aren't supporting further non-free development.

2 1

Problems with PCEngines Alix 2C3 with HEAD
by Duncan 13 Mar '18

13 Mar '18

Hi all, I've been testing the PCEngines Alix 2C3 board with Coreboot bcf9a0a7ab337f9361d58f88ca7510fa42f8aaf5. I've come across a couple of problems though. 1. Coreboot compiles with no problems for the board, configuration file attached [i]. 2. Flashrom pretty much works for probe, erase, read, and write operations internally (unfortunately, I forgot to save a log). 3. However, Coreboot appears to not really work, log attached. [ii]. However, I'm not sure to what extent it is working. I only get serial output from Coreboot to that point. There's no evidence SeaBIOS started. I'm not sure if SeaBIOS is configured to use serial console automatically, but my understanding is that the options I selected in menuconfig there should be sufficient to configure it to do so anyway; however, if this is an incorrect understanding please correct me. All the best, Duncan i. file coreboot.alix2c3.config ii. file coreboot.alix2c3.log

2 1

Re: [coreboot] Has anyone built the memtest86+ payload recently?
by Jay Talbott 12 Mar '18

12 Mar '18

Hi Martin, He was following the instructions on the coreboot website: https://www.coreboot.org/Memtest86%2B Obviously that must be completely out of date if there’s now a version available from the coreboot site. Let me see what he can do with that. We just want to build it as an elf and use it as the primary payload for some validation checks on the memory – the normal/production payload is a Linux kernel. Thanks, - Jay From: coreboot [mailto:coreboot-bounces@coreboot.org] On Behalf Of Martin Roth Sent: Monday, March 12, 2018 10:18 AM To: Jay Talbott Cc: coreboot Subject: Re: [coreboot] Has anyone built the memtest86+ payload recently? Hi Jay, Are they using the coreboot version of memtest86plus? What commit is being built? What version of GCC? Building with GCC 7.3.0 from the latest commit at review.coreboot.org/memtest86plus, I do get one warning that should be cleaned up, but it builds fine. The errors you posted look to me like it's being built from the default memtest86+ zipfile. We also have the Kconfig option in coreboot to build memtest86+ as a secondary payload. That works with no issue. Below is my build output from the coreboot memtest86plus repo. Hope this helps. Martin ~/work/git/memtest86plus ((5ca4eb9...))% make rm -f *.o *.pre.s *.iso memtest.bin memtest memtest_shared \ memtest_shared.bin memtest.iso cc -E -traditional head.S -o head.pre.s as -32 -o head.pre.o head.pre.s cc -c -Wall -march=i486 -m32 -O0 -fomit-frame-pointer -fno-builtin -ffreestanding -fPIC -fno-stack-protector -fgnu89-inline -fno-strict-aliasing reloc.c cc -Wall -march=i486 -m32 -O0 -fomit-frame-pointer -fno-builtin -ffreestanding -fPIC -fno-stack-protector -fgnu89-inline -c -o main.o main.c cc -c -Wall -march=i486 -m32 -O0 -fomit-frame-pointer -fno-builtin -ffreestanding test.c cc -Wall -march=i486 -m32 -O0 -fomit-frame-pointer -fno-builtin -ffreestanding -fPIC -fno-stack-protector -fgnu89-inline -c -o init.o init.c cc -Wall -march=i486 -m32 -O0 -fomit-frame-pointer -fno-builtin -ffreestanding -fPIC -fno-stack-protector -fgnu89-inline -c -o lib.o lib.c cc -Wall -march=i486 -m32 -O0 -fomit-frame-pointer -fno-builtin -ffreestanding -fPIC -fno-stack-protector -fgnu89-inline -c -o patn.o patn.c cc -Wall -march=i486 -m32 -O0 -fomit-frame-pointer -fno-builtin -ffreestanding -fPIC -fno-stack-protector -fgnu89-inline -c -o screen_buffer.o screen_buffer.c cc -Wall -march=i486 -m32 -O0 -fomit-frame-pointer -fno-builtin -ffreestanding -fPIC -fno-stack-protector -fgnu89-inline -c -o config.o config.c cc -Wall -march=i486 -m32 -O0 -fomit-frame-pointer -fno-builtin -ffreestanding -fPIC -fno-stack-protector -fgnu89-inline -c -o cpuid.o cpuid.c cc -Wall -march=i486 -m32 -O0 -fomit-frame-pointer -fno-builtin -ffreestanding -fPIC -fno-stack-protector -fgnu89-inline -c -o coreboot.o coreboot.c cc -Wall -march=i486 -m32 -O0 -fomit-frame-pointer -fno-builtin -ffreestanding -fPIC -fno-stack-protector -fgnu89-inline -c -o pci.o pci.c cc -Wall -march=i486 -m32 -O0 -fomit-frame-pointer -fno-builtin -ffreestanding -fPIC -fno-stack-protector -fgnu89-inline -c -o memsize.o memsize.c cc -Wall -march=i486 -m32 -O0 -fomit-frame-pointer -fno-builtin -ffreestanding -fPIC -fno-stack-protector -fgnu89-inline -c -o spd.o spd.c spd.c: In function ‘sb800_get_smb’: spd.c:58:20: warning: variable ‘result’ set but not used [-Wunused-but-set-variable] int lbyte, hbyte, result; ^~~~~~ cc -Wall -march=i486 -m32 -O0 -fomit-frame-pointer -fno-builtin -ffreestanding -fPIC -fno-stack-protector -fgnu89-inline -c -o error.o error.c cc -Wall -march=i486 -m32 -O0 -fomit-frame-pointer -fno-builtin -ffreestanding -fPIC -fno-stack-protector -fgnu89-inline -c -o dmi.o dmi.c cc -Wall -march=i486 -m32 -O0 -fomit-frame-pointer -fno-builtin -ffreestanding -fPIC -fno-stack-protector -fgnu89-inline -c -o controller.o controller.c cc -Wall -march=i486 -m32 -O0 -fomit-frame-pointer -fno-builtin -ffreestanding -fPIC -fno-stack-protector -fgnu89-inline -c -o smp.o smp.c cc -Wall -march=i486 -m32 -O0 -fomit-frame-pointer -fno-builtin -ffreestanding -fPIC -fno-stack-protector -fgnu89-inline -c -o vmem.o vmem.c cc -c -Wall -march=i486 -m32 -O3 -fomit-frame-pointer -fno-builtin -ffreestanding random.c cc -Wall -march=i486 -m32 -O0 -fomit-frame-pointer -fno-builtin -ffreestanding -fPIC -fno-stack-protector -fgnu89-inline -c -o multiboot.o multiboot.c ld -z max-page-size=0x1000 --warn-constructors --warn-common -static -T memtest_shared.lds \ -o memtest_shared head.pre.o reloc.o main.o test.o init.o lib.o patn.o screen_buffer.o config.o cpuid.o coreboot.o pci.o memsize.o spd.o error.o dmi.o controller.o smp.o vmem.o random.o multiboot.o && \ ld -z max-page-size=0x1000 -shared -Bsymbolic -T memtest_shared.lds -o memtest_shared head.pre.o reloc.o main.o test.o init.o lib.o patn.o screen_buffer.o config.o cpuid.o coreboot.o pci.o memsize.o spd.o error.o dmi.o controller.o smp.o vmem.o random.o multiboot.o objcopy -O binary memtest_shared memtest_shared.bin cc -E -traditional bootsect.S -o bootsect.pre.s as -32 -o bootsect.pre.o bootsect.pre.s cc -E -traditional setup.S -o setup.pre.s as -32 -o setup.pre.o setup.pre.s ld -z max-page-size=0x1000 -T memtest.bin.lds bootsect.pre.o setup.pre.o -b binary \ memtest_shared.bin -o memtest.bin ld -z max-page-size=0x1000 -s -T memtest.lds -b binary memtest_shared.bin -o memtest On Mon, Mar 12, 2018 at 10:41 AM, Jay Talbott <JayTalbott(a)sysproconsulting.com> wrote: > > One of my colleagues is trying to build the memtest86+ payload, and is running into build problems. > > > > Build environment is Ubuntu 16.0.4 LTS. > > > > Has anybody else run into this? Any guidance on how to resolve it? > > > > I’m hoping it’s just something simple that needs to be changed in the build environment that I can pass along to him. > > > > Thanks, > > > > - Jay > > > > $ make clean > > rm -f *.o *.s *.iso memtest.bin memtest memtest_shared \ > > memtest_shared.bin memtest.iso > > $ make > > rm -f *.o *.s *.iso memtest.bin memtest memtest_shared \ > > memtest_shared.bin memtest.iso > > gcc -E -traditional head.S -o head.s > > as -32 -o head.o head.s > > gcc -c -Wall -march=i486 -m32 -O1 -fomit-frame-pointer -fno-builtin -ffreestanding -fPIC -fno-stack-protector -fno-strict-aliasing reloc.c > > gcc -Wall -march=i486 -m32 -O1 -fomit-frame-pointer -fno-builtin -ffreestanding -fPIC -fno-stack-protector -c -o main.o main.c > > gcc -c -Wall -march=i486 -m32 -O0 -fomit-frame-pointer -fno-builtin -ffreestanding test.c > > gcc -Wall -march=i486 -m32 -O1 -fomit-frame-pointer -fno-builtin -ffreestanding -fPIC -fno-stack-protector -c -o init.o init.c > > gcc -Wall -march=i486 -m32 -O1 -fomit-frame-pointer -fno-builtin -ffreestanding -fPIC -fno-stack-protector -c -o lib.o lib.c > > lib.c: In function ‘serial_echo_init’: > > lib.c:807:19: warning: variable ‘lo’ set but not used [-Wunused-but-set-variable] > > int comstat, hi, lo, serial_div; > > ^ > > lib.c:807:15: warning: variable ‘hi’ set but not used [-Wunused-but-set-variable] > > int comstat, hi, lo, serial_div; > > ^ > > gcc -Wall -march=i486 -m32 -O1 -fomit-frame-pointer -fno-builtin -ffreestanding -fPIC -fno-stack-protector -c -o patn.o patn.c > > gcc -Wall -march=i486 -m32 -O1 -fomit-frame-pointer -fno-builtin -ffreestanding -fPIC -fno-stack-protector -c -o screen_buffer.o screen_buffer.c > > gcc -Wall -march=i486 -m32 -O1 -fomit-frame-pointer -fno-builtin -ffreestanding -fPIC -fno-stack-protector -c -o config.o config.c > > gcc -Wall -march=i486 -m32 -O1 -fomit-frame-pointer -fno-builtin -ffreestanding -fPIC -fno-stack-protector -c -o cpuid.o cpuid.c > > gcc -Wall -march=i486 -m32 -O1 -fomit-frame-pointer -fno-builtin -ffreestanding -fPIC -fno-stack-protector -c -o linuxbios.o linuxbios.c > > gcc -Wall -march=i486 -m32 -O1 -fomit-frame-pointer -fno-builtin -ffreestanding -fPIC -fno-stack-protector -c -o pci.o pci.c > > gcc -Wall -march=i486 -m32 -O1 -fomit-frame-pointer -fno-builtin -ffreestanding -fPIC -fno-stack-protector -c -o memsize.o memsize.c > > gcc -Wall -march=i486 -m32 -O1 -fomit-frame-pointer -fno-builtin -ffreestanding -fPIC -fno-stack-protector -c -o spd.o spd.c > > gcc -Wall -march=i486 -m32 -O1 -fomit-frame-pointer -fno-builtin -ffreestanding -fPIC -fno-stack-protector -c -o error.o error.c > > gcc -Wall -march=i486 -m32 -O1 -fomit-frame-pointer -fno-builtin -ffreestanding -fPIC -fno-stack-protector -c -o dmi.o dmi.c > > gcc -Wall -march=i486 -m32 -O1 -fomit-frame-pointer -fno-builtin -ffreestanding -fPIC -fno-stack-protector -c -o controller.o controller.c > > controller.c: In function ‘poll_timings_k16’: > > controller.c:3683:20: warning: variable ‘rc’ set but not used [-Wunused-but-set-variable] > > int cas, rcd, rp, rc, ras; > > ^ > > controller.c: In function ‘setup_nhm32’: > > controller.c:331:34: warning: iteration 3u invokes undefined behavior [-Waggressive-loop-optimizations] > > pci_conf_read( possible_nhm_bus[i], 3, 4, 0x00, 2, &vid); > > ^ > > controller.c:330:2: note: containing loop > > for(i = 0; i < sizeof(possible_nhm_bus); i++) { > > ^ > > controller.c: In function ‘setup_nhm’: > > controller.c:296:34: warning: iteration 3u invokes undefined behavior [-Waggressive-loop-optimizations] > > pci_conf_read( possible_nhm_bus[i], 3, 4, 0x00, 2, &vid); > > ^ > > controller.c:295:2: note: containing loop > > for(i = 0; i < sizeof(possible_nhm_bus); i++) { > > ^ > > gcc -Wall -march=i486 -m32 -O1 -fomit-frame-pointer -fno-builtin -ffreestanding -fPIC -fno-stack-protector -c -o smp.o smp.c > > smp.c: In function ‘smp_find_cpus’: > > smp.c:513:11: warning: passing argument 1 of ‘memset’ discards ‘volatile’ qualifier from pointer target type [-Wdiscarded-array-qualifiers] > > memset(&AP, 0, sizeof AP); > > ^ > > smp.c:170:1: note: expected ‘void *’ but argument is of type ‘volatile ap_info_t (*)[32] {aka volatile struct <anonymous> (*)[32]}’ > > memset (void *dst, > > ^ > > gcc -Wall -march=i486 -m32 -O1 -fomit-frame-pointer -fno-builtin -ffreestanding -fPIC -fno-stack-protector -c -o vmem.o vmem.c > > gcc -c -Wall -march=i486 -m32 -O3 -fomit-frame-pointer -fno-builtin -ffreestanding random.c > > ld --warn-constructors --warn-common -static -T memtest_shared.lds \ > > -o memtest_shared head.o reloc.o main.o test.o init.o lib.o patn.o screen_buffer.o config.o cpuid.o linuxbios.o pci.o memsize.o spd.o error.o dmi.o controller.o smp.o vmem.o random.o && \ > > ld -shared -Bsymbolic -T memtest_shared.lds -o memtest_shared head.o reloc.o main.o test.o init.o lib.o patn.o screen_buffer.o config.o cpuid.o linuxbios.o pci.o memsize.o spd.o error.o dmi.o controller.o smp.o vmem.o random.o > > lib.o: In function `__inb': > > lib.c:(.text+0x0): multiple definition of `__inb' > > init.o:init.c:(.text+0x0): first defined here > > lib.o: In function `__inbc': > > lib.c:(.text+0x6): multiple definition of `__inbc' > > init.o:init.c:(.text+0x6): first defined here > > lib.o: In function `__inb_p': > > lib.c:(.text+0xc): multiple definition of `__inb_p' > > init.o:init.c:(.text+0xc): first defined here > > lib.o: In function `__inbc_p': > > lib.c:(.text+0x14): multiple definition of `__inbc_p' > > init.o:init.c:(.text+0x14): first defined here > > lib.o: In function `__inw': > > lib.c:(.text+0x1c): multiple definition of `__inw' > > init.o:init.c:(.text+0x1c): first defined here > > lib.o: In function `__inwc': > > lib.c:(.text+0x23): multiple definition of `__inwc' > > init.o:init.c:(.text+0x23): first defined here > > lib.o: In function `__inw_p': > > lib.c:(.text+0x2a): multiple definition of `__inw_p' > > init.o:init.c:(.text+0x2a): first defined here > > lib.o: In function `__inwc_p': > > lib.c:(.text+0x33): multiple definition of `__inwc_p' > > init.o:init.c:(.text+0x33): first defined here > > lib.o: In function `__inl': > > lib.c:(.text+0x3c): multiple definition of `__inl' > > init.o:init.c:(.text+0x3c): first defined here > > lib.o: In function `__inlc': > > lib.c:(.text+0x42): multiple definition of `__inlc' > > init.o:init.c:(.text+0x42): first defined here > > lib.o: In function `__inl_p': > > lib.c:(.text+0x48): multiple definition of `__inl_p' > > init.o:init.c:(.text+0x48): first defined here > > lib.o: In function `__inlc_p': > > lib.c:(.text+0x50): multiple definition of `__inlc_p' > > init.o:init.c:(.text+0x50): first defined here > > lib.o: In function `__outb': > > lib.c:(.text+0x58): multiple definition of `__outb' > > init.o:init.c:(.text+0x58): first defined here > > lib.o: In function `__outbc': > > lib.c:(.text+0x62): multiple definition of `__outbc' > > init.o:init.c:(.text+0x62): first defined here > > lib.o: In function `__outb_p': > > lib.c:(.text+0x6c): multiple definition of `__outb_p' > > init.o:init.c:(.text+0x6c): first defined here > > lib.o: In function `__outbc_p': > > lib.c:(.text+0x78): multiple definition of `__outbc_p' > > init.o:init.c:(.text+0x78): first defined here > > lib.o: In function `__outw': > > lib.c:(.text+0x84): multiple definition of `__outw' > > init.o:init.c:(.text+0x84): first defined here > > lib.o: In function `__outwc': > > lib.c:(.text+0x8f): multiple definition of `__outwc' > > init.o:init.c:(.text+0x8f): first defined here > > lib.o: In function `__outw_p': > > lib.c:(.text+0x9a): multiple definition of `__outw_p' > > init.o:init.c:(.text+0x9a): first defined here > > lib.o: In function `__outwc_p': > > lib.c:(.text+0xa7): multiple definition of `__outwc_p' > > init.o:init.c:(.text+0xa7): first defined here > > lib.o: In function `__outl': > > lib.c:(.text+0xb4): multiple definition of `__outl' > > init.o:init.c:(.text+0xb4): first defined here > > lib.o: In function `__outlc': > > lib.c:(.text+0xbe): multiple definition of `__outlc' > > init.o:init.c:(.text+0xbe): first defined here > > lib.o: In function `__outl_p': > > lib.c:(.text+0xc8): multiple definition of `__outl_p' > > init.o:init.c:(.text+0xc8): first defined here > > lib.o: In function `__outlc_p': > > lib.c:(.text+0xd4): multiple definition of `__outlc_p' > > init.o:init.c:(.text+0xd4): first defined here > > lib.o: In function `outsb': > > lib.c:(.text+0xe0): multiple definition of `outsb' > > init.o:init.c:(.text+0xe0): first defined here > > lib.o: In function `outsw': > > lib.c:(.text+0xf2): multiple definition of `outsw' > > init.o:init.c:(.text+0xf2): first defined here > > lib.o: In function `outsl': > > lib.c:(.text+0x105): multiple definition of `outsl' > > init.o:init.c:(.text+0x105): first defined here > > pci.o: In function `__inb': > > pci.c:(.text+0x0): multiple definition of `__inb' > > init.o:init.c:(.text+0x0): first defined here > > pci.o: In function `__inbc': > > pci.c:(.text+0x6): multiple definition of `__inbc' > > init.o:init.c:(.text+0x6): first defined here > > pci.o: In function `__inb_p': > > pci.c:(.text+0xc): multiple definition of `__inb_p' > > init.o:init.c:(.text+0xc): first defined here > > pci.o: In function `__inbc_p': > > pci.c:(.text+0x14): multiple definition of `__inbc_p' > > init.o:init.c:(.text+0x14): first defined here > > pci.o: In function `__inw': > > pci.c:(.text+0x1c): multiple definition of `__inw' > > init.o:init.c:(.text+0x1c): first defined here > > pci.o: In function `__inwc': > > pci.c:(.text+0x23): multiple definition of `__inwc' > > init.o:init.c:(.text+0x23): first defined here > > pci.o: In function `__inw_p': > > pci.c:(.text+0x2a): multiple definition of `__inw_p' > > init.o:init.c:(.text+0x2a): first defined here > > pci.o: In function `__inwc_p': > > pci.c:(.text+0x33): multiple definition of `__inwc_p' > > init.o:init.c:(.text+0x33): first defined here > > pci.o: In function `__inl': > > pci.c:(.text+0x3c): multiple definition of `__inl' > > init.o:init.c:(.text+0x3c): first defined here > > pci.o: In function `__inlc': > > pci.c:(.text+0x42): multiple definition of `__inlc' > > init.o:init.c:(.text+0x42): first defined here > > pci.o: In function `__inl_p': > > pci.c:(.text+0x48): multiple definition of `__inl_p' > > init.o:init.c:(.text+0x48): first defined here > > pci.o: In function `__inlc_p': > > pci.c:(.text+0x50): multiple definition of `__inlc_p' > > init.o:init.c:(.text+0x50): first defined here > > pci.o: In function `__outb': > > pci.c:(.text+0x58): multiple definition of `__outb' > > init.o:init.c:(.text+0x58): first defined here > > pci.o: In function `__outbc': > > pci.c:(.text+0x62): multiple definition of `__outbc' > > init.o:init.c:(.text+0x62): first defined here > > pci.o: In function `__outb_p': > > pci.c:(.text+0x6c): multiple definition of `__outb_p' > > init.o:init.c:(.text+0x6c): first defined here > > pci.o: In function `__outbc_p': > > pci.c:(.text+0x78): multiple definition of `__outbc_p' > > init.o:init.c:(.text+0x78): first defined here > > pci.o: In function `__outw': > > pci.c:(.text+0x84): multiple definition of `__outw' > > init.o:init.c:(.text+0x84): first defined here > > pci.o: In function `__outwc': > > pci.c:(.text+0x8f): multiple definition of `__outwc' > > init.o:init.c:(.text+0x8f): first defined here > > pci.o: In function `__outw_p': > > pci.c:(.text+0x9a): multiple definition of `__outw_p' > > init.o:init.c:(.text+0x9a): first defined here > > pci.o: In function `__outwc_p': > > pci.c:(.text+0xa7): multiple definition of `__outwc_p' > > init.o:init.c:(.text+0xa7): first defined here > > pci.o: In function `__outl': > > pci.c:(.text+0xb4): multiple definition of `__outl' > > init.o:init.c:(.text+0xb4): first defined here > > pci.o: In function `__outlc': > > pci.c:(.text+0xbe): multiple definition of `__outlc' > > init.o:init.c:(.text+0xbe): first defined here > > pci.o: In function `__outl_p': > > pci.c:(.text+0xc8): multiple definition of `__outl_p' > > init.o:init.c:(.text+0xc8): first defined here > > pci.o: In function `__outlc_p': > > pci.c:(.text+0xd4): multiple definition of `__outlc_p' > > init.o:init.c:(.text+0xd4): first defined here > > pci.o: In function `outsb': > > pci.c:(.text+0xe0): multiple definition of `outsb' > > init.o:init.c:(.text+0xe0): first defined here > > pci.o: In function `outsw': > > pci.c:(.text+0xf2): multiple definition of `outsw' > > init.o:init.c:(.text+0xf2): first defined here > > pci.o: In function `outsl': > > pci.c:(.text+0x105): multiple definition of `outsl' > > init.o:init.c:(.text+0x105): first defined here > > spd.o: In function `__inb': > > spd.c:(.text+0x162): multiple definition of `__inb' > > init.o:init.c:(.text+0x0): first defined here > > spd.o: In function `__inbc': > > spd.c:(.text+0x168): multiple definition of `__inbc' > > init.o:init.c:(.text+0x6): first defined here > > spd.o: In function `__inb_p': > > spd.c:(.text+0x16e): multiple definition of `__inb_p' > > init.o:init.c:(.text+0xc): first defined here > > spd.o: In function `__inbc_p': > > spd.c:(.text+0x176): multiple definition of `__inbc_p' > > init.o:init.c:(.text+0x14): first defined here > > spd.o: In function `__inw': > > spd.c:(.text+0x17e): multiple definition of `__inw' > > init.o:init.c:(.text+0x1c): first defined here > > spd.o: In function `__inwc': > > spd.c:(.text+0x185): multiple definition of `__inwc' > > init.o:init.c:(.text+0x23): first defined here > > spd.o: In function `__inw_p': > > spd.c:(.text+0x18c): multiple definition of `__inw_p' > > init.o:init.c:(.text+0x2a): first defined here > > spd.o: In function `__inwc_p': > > spd.c:(.text+0x195): multiple definition of `__inwc_p' > > init.o:init.c:(.text+0x33): first defined here > > spd.o: In function `__inl': > > spd.c:(.text+0x19e): multiple definition of `__inl' > > init.o:init.c:(.text+0x3c): first defined here > > spd.o: In function `__inlc': > > spd.c:(.text+0x1a4): multiple definition of `__inlc' > > init.o:init.c:(.text+0x42): first defined here > > spd.o: In function `__inl_p': > > spd.c:(.text+0x1aa): multiple definition of `__inl_p' > > init.o:init.c:(.text+0x48): first defined here > > spd.o: In function `__inlc_p': > > spd.c:(.text+0x1b2): multiple definition of `__inlc_p' > > init.o:init.c:(.text+0x50): first defined here > > spd.o: In function `__outb': > > spd.c:(.text+0x1ba): multiple definition of `__outb' > > init.o:init.c:(.text+0x58): first defined here > > spd.o: In function `__outbc': > > spd.c:(.text+0x1c4): multiple definition of `__outbc' > > init.o:init.c:(.text+0x62): first defined here > > spd.o: In function `__outb_p': > > spd.c:(.text+0x1ce): multiple definition of `__outb_p' > > init.o:init.c:(.text+0x6c): first defined here > > spd.o: In function `__outbc_p': > > spd.c:(.text+0x1da): multiple definition of `__outbc_p' > > init.o:init.c:(.text+0x78): first defined here > > spd.o: In function `__outw': > > spd.c:(.text+0x1e6): multiple definition of `__outw' > > init.o:init.c:(.text+0x84): first defined here > > spd.o: In function `__outwc': > > spd.c:(.text+0x1f1): multiple definition of `__outwc' > > init.o:init.c:(.text+0x8f): first defined here > > spd.o: In function `__outw_p': > > spd.c:(.text+0x1fc): multiple definition of `__outw_p' > > init.o:init.c:(.text+0x9a): first defined here > > spd.o: In function `__outwc_p': > > spd.c:(.text+0x209): multiple definition of `__outwc_p' > > init.o:init.c:(.text+0xa7): first defined here > > spd.o: In function `__outl': > > spd.c:(.text+0x216): multiple definition of `__outl' > > init.o:init.c:(.text+0xb4): first defined here > > spd.o: In function `__outlc': > > spd.c:(.text+0x220): multiple definition of `__outlc' > > init.o:init.c:(.text+0xbe): first defined here > > spd.o: In function `__outl_p': > > spd.c:(.text+0x22a): multiple definition of `__outl_p' > > init.o:init.c:(.text+0xc8): first defined here > > spd.o: In function `__outlc_p': > > spd.c:(.text+0x236): multiple definition of `__outlc_p' > > init.o:init.c:(.text+0xd4): first defined here > > spd.o: In function `outsb': > > spd.c:(.text+0x242): multiple definition of `outsb' > > init.o:init.c:(.text+0xe0): first defined here > > spd.o: In function `outsw': > > spd.c:(.text+0x254): multiple definition of `outsw' > > init.o:init.c:(.text+0xf2): first defined here > > spd.o: In function `outsl': > > spd.c:(.text+0x267): multiple definition of `outsl' > > init.o:init.c:(.text+0x105): first defined here > > main.o: In function `test_start': > > main.c:(.text+0x2143): undefined reference to `reboot' > > Makefile:30: recipe for target 'memtest_shared' failed > > make: *** [memtest_shared] Error 1 > > > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

2 1

← Newer
1
2
3
4
5
6
7
8
9
10
11
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot March 2018