coreboot May 2014

coreboot@coreboot.org

39 participants
89 discussions

by The Gluglug

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 http://libreboot.org/tutorial/x60_unbrick.html Based on the one at: http://libreboot.org/tutorial/x60_unbrick.html Suggestions are welcome... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTc8i4AAoJEP9Ft0z50c+Umv8H/0DI2a8dnh8LbW3H86gqhhn4 jQb0JioPfXpniFkLikOXi654vQA5j93/ruzgyy4psU9535d3X8hiUrXZKpBlnt1L VlZn8CwKfG5NioO07XmakIqHMFHnsjVwxR/MHbDSUBHx+M18+tfeql2GfcoArGlp s5YlgLSOs95eH4Y52JTLsGt77Wlr5c4CGSJM67HFt/EsxoXMQ6gh1ltO+thfTSxl HCl+e+ThVMXLKH+YndKkptA66ct4GHMqqfA8g5wp1zuJ003PR+pYJ7sQlK4gPB3d dXNAk+dYF8woLr+S55u0+M0MbxpA5ZBc9KJXMgjUWhxE8NFoAo4caMv2YOHOf0Y= =YJuq -----END PGP SIGNATURE-----

6 years, 8 months

Re: [coreboot] Latest coreboot compiling failure on ubuntu 14.04

by Aaron Durbin

On Thu, May 8, 2014 at 3:33 PM, WANG FEI <wangfei.jimei(a)gmail.com> wrote: > Hi, all > > I noticed coreboot compiles failed on my system since the following change > committed. > > Author: Furquan Shaikh <furquan(a)google.com> 2014-04-23 18:18:48 > Committer: Furquan Shaikh <furquan(a)google.com> 2014-05-06 19:23:31 > Parent: fb494d68ff92d036adf10fb7eacf97ed9f1a4391 (baytrail: gpio: Add > support for direct / dedicated IRQs) > Child: 9547f8d799829ddab9196c4e0cad644a06db49e9 (rambi: Add DIRQs for > trackpad and touchscreen) > > The compiling log as below, What's the sha of the coreboot tree you are using? This patch should have fixed it: http://review.coreboot.org/#/c/5701/ > > ubuntu@ubuntu:~/work/coreboot$ make > /bin/sh: 1: Syntax error: redirection unexpected > /bin/sh: 1: -print-libgcc-file-name: not found > /bin/sh: 1: -print-libgcc-file-name: not found > /bin/sh: 1: Syntax error: redirection unexpected > /bin/sh: 1: -print-libgcc-file-name: not found > /bin/sh: 1: -print-libgcc-file-name: not found > /bin/sh: 1: Syntax error: redirection unexpected > /bin/sh: 1: -print-libgcc-file-name: not found > /bin/sh: 1: -print-libgcc-file-name: not found > warning: (BOARD_SPECIFIC_OPTIONS && NORTHBRIDGE_INTEL_NEHALEM && > SOUTHBRIDGE_VIA_K8M890_VGA_EN && DRIVERS_EMULATION_QEMU_BOCHS) selects VGA > which has unmet direct dependencies (VENDOR_INTEL && > BOARD_INTEL_COUGAR_CANYON2) > # > # configuration written to .config > # > warning: (BOARD_SPECIFIC_OPTIONS && NORTHBRIDGE_INTEL_NEHALEM && > SOUTHBRIDGE_VIA_K8M890_VGA_EN && DRIVERS_EMULATION_QEMU_BOCHS) selects VGA > which has unmet direct dependencies (VENDOR_INTEL && > BOARD_INTEL_COUGAR_CANYON2) > warning: (BOARD_SPECIFIC_OPTIONS && NORTHBRIDGE_INTEL_NEHALEM && > SOUTHBRIDGE_VIA_K8M890_VGA_EN && DRIVERS_EMULATION_QEMU_BOCHS) selects VGA > which has unmet direct dependencies (VENDOR_INTEL && > BOARD_INTEL_COUGAR_CANYON2) > HOSTCC nvramtool/cli/nvramtool.o > HOSTCC nvramtool/cli/opts.o > HOSTCC nvramtool/cmos_lowlevel.o > HOSTCC nvramtool/cmos_ops.o > HOSTCC nvramtool/common.o > HOSTCC nvramtool/compute_ip_checksum.o > HOSTCC nvramtool/hexdump.o > HOSTCC nvramtool/input_file.o > HOSTCC nvramtool/layout.o > HOSTCC nvramtool/accessors/layout-common.o > HOSTCC nvramtool/accessors/layout-text.o > HOSTCC nvramtool/accessors/layout-bin.o > HOSTCC nvramtool/lbtable.o > HOSTCC nvramtool/reg_expr.o > HOSTCC nvramtool/cbfs.o > HOSTCC nvramtool/accessors/cmos-mem.o > HOSTCC nvramtool/nvramtool (link) > OPTION option_table.h > GEN build.h > CC romstage.inc > make: MMD: Command not found > POST romstage.inc > sed: can't read build/mainboard/emulation/qemu-i440fx/romstage.pre.inc: No > such file or directory > make: *** [build/mainboard/emulation/qemu-i440fx/romstage.inc] Error 2 > > It looks the bash on my system does not compatible with the new committed > makefile, does anyone get the failure? > > The bash I'm using is, > > ubuntu@ubuntu:~/work/coreboot$ /bin/bash --version > GNU bash, version 4.3.11(1)-release (i686-pc-linux-gnu) > Copyright (C) 2013 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > <http://gnu.org/licenses/gpl.html> > > This is free software; you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > > -Fei > > > > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot

6 years, 8 months

Booting an EFI OS

by Mike Hibbett

Hi all, What would be the recommended payload for booting an EFI OS on a sata drive? Is there an out of the box solution that works now, or is it a "work in progress?" Thanks, Mike.

6 years, 8 months

Re: [coreboot] PIC instead of APIC mode for KolibriOS - mouse fix

by Peter Stuge

ron minnich wrote: > > Why shouldn't coreboot do legacy initialization? What is the reason > > to be *less* compatible than possible? > > The main question I had was whether enabling this set of interrupts > could negatively impact other payloads. That's an important question, but I believe the answer is no. If the answer would be yes, how would all the software which we use as payloads work with a legacy firmware? The ones which aren't *exclusively* payloads (depthcharge comes to mind as an exception) were originally running on top of a legacy firmware instead of after coreboot, and they work. > The goal of linuxbios and coreboot was always to do as little as > possible, not act like a BIOS. I understand your point and I agree with what you mean, but I don't know if I agree that configuring interrupt routers lies squarely in the legacy BIOS domain. But we might decide that indeed it does, in which case we'll have to push PIC configuration into all payloads; ie. SeaBIOS and libpayload at a very minimum. What about APIC config? Why would we do one and not the other? By their very design, they are compatible with each other. This is why Windows XP can be installed in either "Standard PC" or "ACPI PC" mode, and work, on machines with a firmware which configures both PIC and APIC. > Simple example: if we enable all these interrupts, and a non-kolibrios > payload boots, is there a chance that a broadcast packet could be > picked up by the NIC and interrupt the non-kolibrios payload? Hang on - is enabling interrupts equivalent to configuring the interrupt controller? I know that's not the case at least with the PIC. I guess neither with the APIC. > Is there anything in there that is a one-way initialization that > might make it harder for for _MP_, ACPI, MSI, or MSI-X? I don't think we should include a solution which goes in such a direction unless it is only very temporary. The things you mention are all younger than the PIC, so they have already been designed to live alongside the legacy hardware. > I just want to hear that the answer is "no". I have yet to hear it. > It's a pretty simple question. And it's a good one. I do believe that the answer is "no". > And the question remains: why is it kolibrios can't just read the > $PIR and/or _MP_ like everything else has somehow managed to do for 15 > years? It would be interesting to know exactly where it reads the interrupt number. It might e.g. be calling the PCI BIOS services, and SeaBIOS might be reading from a register which hasn't been programmed. (I'm not saying this is the case, it's only one possibility.) > Why are we doing these config writes in coreboot when the OS > should do them? And why are we doing this for *one* OS? I'm not sure that the OS should do them. And maybe more OSes need it, just that they haven't been tested yet. I would certainly welcome research into the matter, which is neccessary to build the required data model for coreboot. > >The NIC bus number is hard-coded at the moment. This needs fixing > >if the NIC bus number can change. > > Are you seriously telling me you want coreboot to hardware the bus > number for a NIC? That's a terrible idea. No, I'm not telling you that I want that. I'm telling you that coreboot needs to model hardware init completely and accurately. It doesn't yet. > In general, we've tended not to set up too much interrupt hardware > for a simple reason: we do have lots of payloads, and the odds are > very good if you do too much setup > - you're wasting time I can't take this too seriously, since it's a matter of a few register writes. > - you're doing the wrong thing for the payload > - it may confuse the payload you eventually boot. These are essentially the same point. I'm not at all sure that configuring the PIC can ever be the wrong thing for any piece of software which runs on a PC derivative. > Finally, we actually always tried from the beginning to no setup up IRQs. And boy how much trouble has been caused by that design decision. :\ > The emphasis was on creating the tables that let the payload do the > right thing. Which might have been fine, except unfortunately the payloads never learned to use the tables, and the system doesn't just work<tm>. > Communicating IRQ info to the kernel is what we've done; We must of course still. > actually configuring the PIC is a violation of the early design goals. I either disagree with it being a violation, or I think the early design goals were broken in this aspect. I'm not sure which it is at this point, it could be either! Thanks //Peter

6 years, 8 months

Re: [coreboot] PIC instead of APIC mode for KolibriOS - mouse fix

by Rudolf Marek

Hi all, 1) we should provide at least the MP-Table. There is a still lot of OS without ACPI support (various homebrew OS, RTOS etc) which don't want to carry the ACPICA just to get idea how to route IRQs... 2) if we want to setup the PCI for PIC we need to do: a) setup the PCI router (just couple of regs in the SB) This is done by: pirq_assign_irqs() b) setup the ELCR (0x4d0/0x4d1) set IRQs to level, this is done by: i8259_configure_irq_trigger() c) setup the 0x3c values in the PCI regs this is done by: pirq_route_irqs() which does the job if CONFIG_PIRQ_ROUTE Oh yes coreboot knows how to do that if PIR table is present in quite generic way. Setting this up should not break things, except that AMD SB700 or similar needs to disable the IRQ routing to PIC in ASL code in _PIC method. I don't know if this necessary. Thanks Rudolf

6 years, 8 months

No graphics with libpayload payloads (Tint, coreinfo) when coreboot is built without serial console

by Paul Menzel

Dear coreboot folks, when building coreboot without serial console for QEMU and when trying to run the payloads Tint [1] (or coreinfo) in it, no graphics comes up and the payloads are not loaded. Just enabling serial console fixes the problem. Tinycurses is used in libpayload as there were problems building Tint with PDCurses. This problem was already present last week and is still with an image built from latest master [2]. commit 216a619a74d61f66e3d3e1d668028d11a8868b4d Author: Kyösti Mälkki <kyosti.malkki(a)gmail.com> Date: Mon May 12 23:16:18 2014 +0300 Rambi: Enable 32k SUSCLK signal Please find the `.config` and the coreboot log captured over QEMU’s debug console attached. $ build/cbfstool build/coreboot.rom print bios.bin: 256 kB, bootblocksize 848, romsize 262144, offset 0x0 alignment: 64 bytes Name Offset Type Size fallback/romstage 0x0 stage 20965 fallback/ramstage 0x5240 stage 55954 fallback/payload 0x12d40 payload 23175 config 0x18800 raw 3299 (empty) 0x19540 null 157464 $ ln -s coreboot.rom build/bios.bin $ qemu-system-i386 -M q35 -bios build/bios.bin -hda /dev/zero -serial stdio -chardev file,id=debugcon,path=/tmp/qemu--dynamic-cbmem--without-serial--tint-lzma.log -device isa-debugcon,iobase=0x402,chardev=debugcon Thanks, Paul [1] http://www.coreboot.org/Tint [2] http://review.coreboot.org/5722

6 years, 8 months

Re: [coreboot] PIC instead of APIC mode for KolibriOS - mouse fix

by Scott Duplichan

ron minnich [mailto:rminnich@gmail.com] wrote: ]Thanks, that's a great explanation. Generally, we've tried to avoid ]too much hardware setup in coreboot; that's the job of the kernel. The PIC mode interrupt routing configuration must be done by BIOS because proprietary southbridge registers are used. The register definitions are not even consistent across different AMD southbridge models. An OEM BIOS does this configuration. ]I'm not really happy that we're doing all this PIC setup for one OS, ]written in assembly. This is needed for all operating systems that support PIC mode. For example, Ubuntu 13.10 with boot option acpi=off fails. With the attached revised patch, it works. ]It's been quite some time since I've had to use PIC mode at all. ] ]Why can't the Kolibrios just use modern standards? And why all this ]effort for an OS written in assembly anyway? ] ]Unix v6 kernels were the same size as Kolibrios. They were written in ]C. That was 40 years ago. It's bizarre, to say the least, to be ]booting a kernel written in assembly from firmware written in C. ] ]Hence, I find it hard to believe that we want this patch. But I'm ]wrong a lot, so if I am here too, just let me know. It is OK with me to take no action on the patch. The reason is that the patch is here in the mailing list archives, and anyone who really wants PIC mode will find it. The patch probably needs sanitization and additional testing anyway. ]ron Patch revisions: 1) With the current code, CONFIG_GENERATE_ACPI_TABLES=1 causes the PCI interrupts to be omitted from the mptable. With the revised patch, the mptable always includes PCI interrupts. This solves the Ubuntu acpi=off problem of "can't find IRQ for PCI INT A; probably buggy MP table". 2) Add PIC mode PCI interrupt values for SATA and IDE devices. Without this, Ubuntu setup cannot read the CD-ROM. 3) Use 00 for unused PIC mode routing entries rather than 1F. This is for consistency with the APIC mode table. Thanks, Scott diff --git a/src/mainboard/asrock/e350m1/mptable.c b/src/mainboard/asrock/e350m1/mptable.c index 6444be5..f45385e 100644 --- a/src/mainboard/asrock/e350m1/mptable.c +++ b/src/mainboard/asrock/e350m1/mptable.c @@ -35,6 +35,7 @@ extern u32 apicid_sb800; extern u32 bus_type[256]; extern u32 sbdn_sb800; +// SB800 interrupt routing register values: APIC mode u8 intr_data[] = { [0x00] = 0x10,0x11,0x12,0x13,0x14,0x15,0x16,0x17, /* INTA# - INTH# */ [0x08] = 0x00,0x00,0x00,0x00,0x1F,0x1F,0x1F,0x1F, /* Misc-nil,0,1,2, INT from Serial irq */ @@ -45,6 +46,20 @@ u8 intr_data[] = { 0x10,0x11,0x12,0x13 }; +// SB800 interrupt routing register values: PIC mode +u8 intr_data_pic[] = { + 0x0B, 0x0A, 0x0B, 0x0A, 0x1F, 0x1F, 0x1F, 0x1F, // 0x00 + 0x00, 0xF1, 0x00, 0x00, 0x1F, 0x1F, 0x1F, 0x1F, // 0x08 + 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x00, // 0x10 + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0x18 + 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x00, 0x00, // 0x20 + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0x28 + 0x0B, 0x0A, 0x0B, 0x0A, 0x0B, 0x0A, 0x0B, 0x00, // 0x30 + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0x38 + 0x0A, 0x0A, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0x40 + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0x48 + 0x0B, 0x0A, 0x0B, 0x0A}; // 0x50 + static void *smp_write_config_table(void *v) { struct mp_config_table *mc; @@ -75,6 +90,12 @@ static void *smp_write_config_table(void *v) outb(intr_data[byte], 0xC01); } + // program the SB800 PIC mode interrupt routing register values + for (byte = 0x0; byte < sizeof(intr_data_pic); byte ++) { + outb(byte, 0xC00); + outb(intr_data_pic[byte], 0xC01); + } + /* I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN# */ #define IO_LOCAL_INT(type, intr, apicid, pin) \ smp_write_lintsrc(mc, (type), MP_IRQ_TRIGGER_EDGE | MP_IRQ_POLARITY_HIGH, bus_isa, (intr), (apicid), (pin)); @@ -84,12 +105,8 @@ static void *smp_write_config_table(void *v) /* PCI interrupts are level triggered, and are * associated with a specific bus/device/function tuple. */ -#if !CONFIG_GENERATE_ACPI_TABLES #define PCI_INT(bus, dev, fn, pin) \ - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, (bus), (((dev)<<2)|(fn)), apicid_sb800, (pin)) -#else -#define PCI_INT(bus, dev, fn, pin) -#endif + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, (bus), (((dev)<<2)|(fn)), apicid_sb800, (pin)) /* APU Internal Graphic Device*/ PCI_INT(0x0, 0x01, 0x0, intr_data[0x02]); @@ -149,6 +166,25 @@ static void *smp_write_config_table(void *v) IO_LOCAL_INT(mp_NMI, 0x0, MP_APIC_ALL, 0x1); /* There is no extension information... */ + // program interrupt line registers for legacy OS use + pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x01, 0)), 0x3C, 0x0B); + pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x01, 1)), 0x3C, 0x0A); + pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x04, 0)), 0x3C, 0x0B); + pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x11, 0)), 0x3C, 0x0A); + pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x12, 0)), 0x3C, 0x0B); + pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x12, 2)), 0x3C, 0x0A); + pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x13, 0)), 0x3C, 0x0B); + pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x13, 2)), 0x3C, 0x0A); + pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x14, 1)), 0x3C, 0x0A); + pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x14, 2)), 0x3C, 0x0B); + pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x14, 5)), 0x3C, 0x0B); + pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x16, 0)), 0x3C, 0x0B); + pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x16, 2)), 0x3C, 0x0A); + pci_write_config32(dev_find_slot(3, PCI_DEVFN(0x00, 0)), 0x3C, 0x0B); + + // program slave PIC edge-level control register + outb (0x0C, 0x4D1); + /* Compute the checksums */ return mptable_finalize(mc); }

6 years, 8 months

Re: [coreboot] PIC instead of APIC mode for KolibriOS - mouse fix

by Scott Duplichan

Scott Duplichan [mailto:scott@notabs.org] wrote: [...] ]As for the mouse problem, I think it may be PIC interrupt ]routing related. I see our PIR table is incomplete and also ]the legacy interrupting route reporting registers in PCI ]config space are not filled in. I will look at that tomorrow. I got the USB mouse working by setting up the PIC interrupt routing and reporting. For now the changes are in mptable.c. They may need to be relocated to a better place. The NIC bus number is hard-coded at the moment. This needs fixing if the NIC bus number can change. KolibriOS reads PCI config offset 3C to find PIC interrupt routing, so these must be filled in. The same values must be programmed into the SB800 PIC mode interrupt routing registers. In addition, a change to the legacy mode edge-level control register setting is needed. An updated archive is here: http://notabs.org/coreboot/e350m1-kolibri-001.7z An mptable.c patch is attached. diff --git a/src/mainboard/asrock/e350m1/mptable.c b/src/mainboard/asrock/e350m1/mptable.c index 6444be5..b6c5b76 100644 --- a/src/mainboard/asrock/e350m1/mptable.c +++ b/src/mainboard/asrock/e350m1/mptable.c @@ -35,6 +35,7 @@ extern u32 apicid_sb800; extern u32 bus_type[256]; extern u32 sbdn_sb800; +// SB800 interrupt routing register values: APIC mode u8 intr_data[] = { [0x00] = 0x10,0x11,0x12,0x13,0x14,0x15,0x16,0x17, /* INTA# - INTH# */ [0x08] = 0x00,0x00,0x00,0x00,0x1F,0x1F,0x1F,0x1F, /* Misc-nil,0,1,2, INT from Serial irq */ @@ -45,6 +46,16 @@ u8 intr_data[] = { 0x10,0x11,0x12,0x13 }; +// SB800 interrupt routing register values: PIC mode +u8 intr_data_pic[] = { + 0x0B, 0x0A, 0x0B, 0x0A, 0x1F, 0x1F, 0x1F, 0x1F, // 0x00 + 0x00, 0xF1, 0x00, 0x00, 0x1F, 0x1F, 0x1F, 0x1F, // 0x08 + 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, // 0x10 + 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, // 0x18 + 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, // 0x20 + 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, // 0x28 + 0x0B, 0x0A, 0x0B, 0x0A, 0x1F, 0x1F, 0x1F, 0x1F}; // 0x30 + static void *smp_write_config_table(void *v) { struct mp_config_table *mc; @@ -75,6 +86,12 @@ static void *smp_write_config_table(void *v) outb(intr_data[byte], 0xC01); } + // progran the SB800 PIC mode interrupt routing register values + for (byte = 0x0; byte < sizeof(intr_data_pic); byte ++) { + outb(byte, 0xC00); + outb(intr_data_pic[byte], 0xC01); + } + /* I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN# */ #define IO_LOCAL_INT(type, intr, apicid, pin) \ smp_write_lintsrc(mc, (type), MP_IRQ_TRIGGER_EDGE | MP_IRQ_POLARITY_HIGH, bus_isa, (intr), (apicid), (pin)); @@ -149,6 +166,25 @@ static void *smp_write_config_table(void *v) IO_LOCAL_INT(mp_NMI, 0x0, MP_APIC_ALL, 0x1); /* There is no extension information... */ + // program interrupt line registers for legacy OS use + pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x01, 0)), 0x3C, 0x0B); + pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x01, 1)), 0x3C, 0x0A); + pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x04, 0)), 0x3C, 0x0B); + pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x11, 0)), 0x3C, 0x0A); + pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x12, 0)), 0x3C, 0x0B); + pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x12, 2)), 0x3C, 0x0A); + pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x13, 0)), 0x3C, 0x0B); + pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x13, 2)), 0x3C, 0x0A); + pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x14, 1)), 0x3C, 0x0A); + pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x14, 2)), 0x3C, 0x0B); + pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x14, 5)), 0x3C, 0x0B); + pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x16, 0)), 0x3C, 0x0B); + pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x16, 2)), 0x3C, 0x0A); + pci_write_config32(dev_find_slot(3, PCI_DEVFN(0x00, 0)), 0x3C, 0x0B); + + // program slave PIC edge-level control register + outb (0x0C, 0x4D1); + /* Compute the checksums */ return mptable_finalize(mc); } Thanks, Scott

6 years, 8 months

Re: [coreboot] HEAD isn't compiling with CONFIG_ANY_TOOLCHAIN

by Sean McNeil

Thanks, that is what I am missing. I have a configuration derived from src/soc/intel/baytrail and didn't notice the new selections. Sean On 05/11/2014 10:52 AM, Furquan Shaikh wrote: > Ah okay! > > 1) What board are you trying this for? Does it use a different cpu / > soc than the ones for which we have support upstream? > > 2) The variables ARCH-*-y depend on the config variables ARCH_*_X86_32 > selected in cpu/soc specific Kconfig files. E.g.: In file > src/cpu/intel/haswell/Kconfig, the options selected are: > select ARCH_BOOTBLOCK_X86_32 > select ARCH_ROMSTAGE_X86_32 > select ARCH_RAMSTAGE_X86_32 > > Make sure that architecture is specified for each of the three stages > i.e. bootblock, romstage and ramstage. > > On Sat, May 10, 2014 at 8:18 PM, Sean McNeil <seanmcneil3(a)gmail.com > <mailto:seanmcneil3@gmail.com>> wrote: > > The below commit has already been merged and does not resolve the > issue. My /bin/sh is also a symlink to bash. > > It appears to be 2 things: > > 1) I don't have the following definitions anywhere > > ARCH-BOOTBLOCK-y := i386 > ARCH-ROMSTAGE-y := i386 > ARCH-RAMSTAGE-y := i386 > > this is what causes the command not found problems. > > 2) target build/cbfs/fallback/bootblock.bin is missing. It looks > the same in the older codebase Makefile.inc and perhaps is a > side-affect of the bootblock class? > > > On 05/11/2014 01:10 AM, Furquan Shaikh wrote: >> This CL has been submitted which should fix the issue: >> >> http://review.coreboot.org/#/c/5701/ >> >> >> On Saturday, May 10, 2014 3:02:44 AM, Sean McNeil >> <seanmcneil3(a)gmail.com <mailto:seanmcneil3@gmail.com>> wrote: >> >> Up until recently, compiling coreboot with the options >> >> CONFIG_COMPILER_GCC=y >> CONFIG_ANY_TOOLCHAIN=y >> >> on a 64-bit linux system worked just fine. Over the last few >> days I now get the errors: >> >> make >> Warning: no suitable GCC for armv7. >> Warning: no suitable GCC for aarch64. >> /bin/sh: -print-libgcc-file-name: command not found >> /bin/sh: -print-libgcc-file-name: command not found >> /bin/sh: -print-libgcc-file-name: command not found >> /bin/sh: -print-libgcc-file-name: command not found >> /bin/sh: -print-libgcc-file-name: command not found >> /bin/sh: -print-libgcc-file-name: command not found >> # >> # configuration written to .config >> # >> make: *** No rule to make target >> `build/cbfs/fallback/bootblock.bin', needed by >> `build/coreboot.pre1'. Stop. >> >> -- >> coreboot mailing list: coreboot@ >> <mailto:coreboot@coreboot.org>coreboot.org >> <mailto:coreboot@coreboot.org> >> http:// >> <http://www.coreboot.org/mailman/listinfo/coreboot>www.coreboot.org >> <http://www.coreboot.org/mailman/listinfo/coreboot>/mailman/ >> <http://www.coreboot.org/mailman/listinfo/coreboot>listinfo >> <http://www.coreboot.org/mailman/listinfo/coreboot>/coreboot >> <http://www.coreboot.org/mailman/listinfo/coreboot> >> >> > >

6 years, 8 months

Re: [coreboot] HEAD isn't compiling with CONFIG_ANY_TOOLCHAIN

by Sean McNeil

The below commit has already been merged and does not resolve the issue. My /bin/sh is also a symlink to bash. It appears to be 2 things: 1) I don't have the following definitions anywhere ARCH-BOOTBLOCK-y := i386 ARCH-ROMSTAGE-y := i386 ARCH-RAMSTAGE-y := i386 this is what causes the command not found problems. 2) target build/cbfs/fallback/bootblock.bin is missing. It looks the same in the older codebase Makefile.inc and perhaps is a side-affect of the bootblock class? On 05/11/2014 01:10 AM, Furquan Shaikh wrote: > This CL has been submitted which should fix the issue: > > http://review.coreboot.org/#/c/5701/ > > > On Saturday, May 10, 2014 3:02:44 AM, Sean McNeil > <seanmcneil3(a)gmail.com <mailto:seanmcneil3@gmail.com>> wrote: > > Up until recently, compiling coreboot with the options > > CONFIG_COMPILER_GCC=y > CONFIG_ANY_TOOLCHAIN=y > > on a 64-bit linux system worked just fine. Over the last few days > I now get the errors: > > make > Warning: no suitable GCC for armv7. > Warning: no suitable GCC for aarch64. > /bin/sh: -print-libgcc-file-name: command not found > /bin/sh: -print-libgcc-file-name: command not found > /bin/sh: -print-libgcc-file-name: command not found > /bin/sh: -print-libgcc-file-name: command not found > /bin/sh: -print-libgcc-file-name: command not found > /bin/sh: -print-libgcc-file-name: command not found > # > # configuration written to .config > # > make: *** No rule to make target > `build/cbfs/fallback/bootblock.bin', needed by > `build/coreboot.pre1'. Stop. > > -- > coreboot mailing list: coreboot@ > <mailto:coreboot@coreboot.org>coreboot.org > <mailto:coreboot@coreboot.org> > http:// > <http://www.coreboot.org/mailman/listinfo/coreboot>www.coreboot.org <http://www.coreboot.org/mailman/listinfo/coreboot>/mailman/ > <http://www.coreboot.org/mailman/listinfo/coreboot>listinfo > <http://www.coreboot.org/mailman/listinfo/coreboot>/coreboot > <http://www.coreboot.org/mailman/listinfo/coreboot> > >

6 years, 8 months

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

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot May 2014