[coreboot] [commit] r4989 - in trunk: . src/arch/i386 src/arch/i386/init src/arch/i386/lib src/cpu/x86/32bit src/mainboard/emulation/qemu-x86 util/cbfstool
Author: oxygene Date: 2009-12-23 13:52:56 +0100 (Wed, 23 Dec 2009) New Revision: 4989 Added: trunk/src/arch/i386/Makefile.bigbootblock.inc trunk/src/arch/i386/Makefile.tinybootblock.inc trunk/src/arch/i386/init/bootblock.c trunk/src/arch/i386/init/bootblock_prologue.c trunk/src/arch/i386/lib/walkcbfs.S Modified: trunk/Makefile trunk/src/arch/i386/Kconfig trunk/src/arch/i386/Makefile.inc trunk/src/cpu/x86/32bit/entry32.lds trunk/src/mainboard/emulation/qemu-x86/Kconfig trunk/src/mainboard/emulation/qemu-x86/Makefile.inc trunk/util/cbfstool/cbfs-mkstage.c Log: Tiny Bootblock, step 1/n. Introduce the tiny bootblock infrastructure and use it on QEmu. Signed-off-by: Patrick Georgi patrick.geo...@coresystems.de Acked-by: Myles Watson myle...@gmail.com Acked-by: Ronald G. Minnich rminn...@gmail.com Modified: trunk/Makefile === --- trunk/Makefile 2009-12-21 15:09:01 UTC (rev 4988) +++ trunk/Makefile 2009-12-23 12:52:56 UTC (rev 4989) @@ -293,6 +293,7 @@ clean: doxygen-clean rm -f $(allobjs) $(obj)/coreboot* + rm -rf $(obj)/bootblock* $(obj)/romstage* $(obj)/location.* rm -f $(obj)/option_table.* $(obj)/crt0_includes.h $(obj)/ldscript rm -f $(obj)/mainboard/$(MAINBOARDDIR)/static.c $(obj)/mainboard/$(MAINBOARDDIR)/config.py $(obj)/mainboard/$(MAINBOARDDIR)/static.dot rm -f $(obj)/mainboard/$(MAINBOARDDIR)/auto.inc $(obj)/mainboard/$(MAINBOARDDIR)/crt0.s $(obj)/mainboard/$(MAINBOARDDIR)/crt0.disasm Modified: trunk/src/arch/i386/Kconfig === --- trunk/src/arch/i386/Kconfig 2009-12-21 15:09:01 UTC (rev 4988) +++ trunk/src/arch/i386/Kconfig 2009-12-23 12:52:56 UTC (rev 4989) @@ -40,3 +40,6 @@ int default 3 +config TINY_BOOTBLOCK + bool + default n Copied: trunk/src/arch/i386/Makefile.bigbootblock.inc (from rev 4988, trunk/src/arch/i386/Makefile.inc) === --- trunk/src/arch/i386/Makefile.bigbootblock.inc (rev 0) +++ trunk/src/arch/i386/Makefile.bigbootblock.inc 2009-12-23 12:52:56 UTC (rev 4989) @@ -0,0 +1,35 @@ +ifdef POST_EVALUATION + +### +# Build the final rom image + +$(obj)/coreboot.pre: $(obj)/coreboot.bootblock $(CBFSTOOL) + rm -f $@ + $(CBFSTOOL) $@ create $(CONFIG_COREBOOT_ROMSIZE_KB)K $(obj)/coreboot.bootblock + +### +# Build the bootblock + +$(obj)/coreboot.bootblock: $(obj)/coreboot + @printf OBJCOPY$(subst $(obj)/,,$(@))\n + $(OBJCOPY) -O binary $ $@ + +$(obj)/ldscript.ld: $(ldscripts) $(obj)/ldoptions + printf 'INCLUDE ldoptions\n' $@ + printf '$(foreach ldscript,$(ldscripts),INCLUDE $(ldscript:$(obj)/%=%)\n)' $@ + +$(obj)/crt0_includes.h: $(crt0s) + printf '$(foreach crt0,config.h $(crt0s),#include $(crt0:$(obj)/%=%)\n)' $@ + +$(obj)/mainboard/$(MAINBOARDDIR)/crt0.o: $(obj)/mainboard/$(MAINBOARDDIR)/crt0.s + $(CC) -I$(obj) -Wa,-acdlns -c -o $@ $ $(dir $@)/crt0.disasm + +$(obj)/mainboard/$(MAINBOARDDIR)/crt0.s: $(src)/arch/i386/init/crt0.S.lb $(obj)/crt0_includes.h + $(CC) -x assembler-with-cpp -DASSEMBLY -E -I$(src)/include -I$(src)/arch/i386/include -I$(obj) -include $(obj)/config.h -I. -I$(src) $ $...@.new mv $...@.new $@ + +$(obj)/coreboot: $(initobjs) $(obj)/ldscript.ld + @printf LINK $(subst $(obj)/,,$(@))\n + $(CC) -nostdlib -nostartfiles -static -o $@ -L$(obj) -T $(obj)/ldscript.ld $(initobjs) + $(NM) -n $(obj)/coreboot | sort $(obj)/coreboot.map + +endif Modified: trunk/src/arch/i386/Makefile.inc === --- trunk/src/arch/i386/Makefile.inc2009-12-21 15:09:01 UTC (rev 4988) +++ trunk/src/arch/i386/Makefile.inc2009-12-23 12:52:56 UTC (rev 4989) @@ -11,10 +11,8 @@ ### # Build the final rom image - -$(obj)/coreboot.rom: $(obj)/coreboot.bootblock $(obj)/coreboot_ram $(CBFSTOOL) - rm -f $@ - $(CBFSTOOL) $@ create $(CONFIG_COREBOOT_ROMSIZE_KB)K $(obj)/coreboot.bootblock +$(obj)/coreboot.rom: $(obj)/coreboot.pre $(obj)/coreboot_ram $(CBFSTOOL) + cp $(obj)/coreboot.pre $@ if [ -f fallback/coreboot_apc ]; \ then \ $(CBFSTOOL) $@ add-stage fallback/coreboot_apc fallback/coreboot_apc $(CBFS_COMPRESS_FLAG); \ @@ -33,36 +31,10 @@ @printf CBFSPRINT $(subst $(obj)/,,$(@))\n\n $(CBFSTOOL) $(obj)/coreboot.rom print - ### -# Build the bootblock - -$(obj)/coreboot.bootblock: $(obj)/coreboot - @printf OBJCOPY$(subst $(obj)/,,$(@))\n -
Re: [coreboot] [PATCH]tinybootblock
Am 22.12.2009 23:17, schrieb Myles Watson: On Tue, Dec 22, 2009 at 2:27 PM, Patrick Georgi patr...@georgi-clan.de mailto:patr...@georgi-clan.de wrote: - Provide a framework to build image selection logic In newconfig, most boards have their own code to select the image. The goal in this layout is to have generic decision routines to take care of that, and encourage their use. Is it possible to have it be generic? Won't we have to unify CMOS layouts for that to happen? In a way, it's just the do_normal_boot() code in src/pc80/mc146818rtc_early.c. We already have everything in the tree to make it all generic, but we didn't properly use it. Maybe because the generic code came after the copied versions and no-one dared to refactor things. It's not simply a port because of the intrusive change of moving CAR out of the bootblock, and this time, the generic code will be around from the start, so it has a chance to be used. I think it would be a mistake to bring romcc to targets that don't need it now. The alternative at that point is to do that code in assembly, or to move CAR to the bootblock again. romcc works quite fine for small code, and the code in the bootblock is supposed to be small. - Look up fallback/romstage in CBFS (this can be extended with selection logic if desired) (selection logic is C, compiled with romcc, lookup is assembly) It's more important to me to avoid assembly than to have the absolute minimum size bootblock. Especially for K8 Fam10, there's plenty of space to not have to do this. Among the reasons: The way it is done now, it's always exactly one copy of the tree walker. If it's written in C and compiled with romcc, it could end up several times in the bootblock, if there are various calls (fallback, normal, ...), probably giving the register allocator a harder time. Picky detail: Since CONFIG_TINY_BOOTBLOCK is referenced in a Makefile that isn't board specific, the Kconfig entry for it should go there too (with a default n). There should just be a select in qemu-x86/Kconfig Fixed, thanks for the reminder. I wanted to keep things minimal and forgot about it. It's not a big issue, as in Makefiles, missing variables simply expand to the empty string, but it's cleaner the way you proposed. Acked-by: Myles Watson myle...@gmail.com mailto:myle...@gmail.com Thanks, r4989 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [commit] r4990 - in trunk: src/arch/i386/include/arch src/mainboard/technexion/tim5690 util/x86emu
Author: mjones
Date: 2009-12-23 20:16:47 +0100 (Wed, 23 Dec 2009)
New Revision: 4990
Added:
trunk/src/arch/i386/include/arch/interrupt.h
trunk/src/mainboard/technexion/tim5690/vgabios.c
trunk/src/mainboard/technexion/tim5690/vgabios.h
Modified:
trunk/src/mainboard/technexion/tim5690/Makefile.inc
trunk/src/mainboard/technexion/tim5690/cache_as_ram_auto.c
trunk/src/mainboard/technexion/tim5690/mainboard.c
trunk/util/x86emu/x86.c
Log:
Add mainboard x86emu interrupt function support. Add tim5690 VGA BIOS
functions: int15 getting LCD panel ID.
Signed-off-by: Libra Li libra...@technexion.com
Acked-by: Marc Jones marcj...@gmail.com
Added: trunk/src/arch/i386/include/arch/interrupt.h
===
--- trunk/src/arch/i386/include/arch/interrupt.h
(rev 0)
+++ trunk/src/arch/i386/include/arch/interrupt.h2009-12-23 19:16:47 UTC
(rev 4990)
@@ -0,0 +1,25 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2009 coresystems GmbH
+ * Copyright (C) 2009 Libra Li libra...@technexion.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include registers.h
+
+/* setup interrupt handlers for mainboard */
+extern void mainboard_interrupt_handlers(int intXX, void *intXX_func);
Modified: trunk/src/mainboard/technexion/tim5690/Makefile.inc
===
--- trunk/src/mainboard/technexion/tim5690/Makefile.inc 2009-12-23 12:52:56 UTC
(rev 4989)
+++ trunk/src/mainboard/technexion/tim5690/Makefile.inc 2009-12-23 19:16:47 UTC
(rev 4990)
@@ -33,6 +33,7 @@
obj-y += tn_post_code.o
obj-y += speaker.o
+obj-y += vgabios.o
# This is part of the conversion to init-obj and away from included code.
Modified: trunk/src/mainboard/technexion/tim5690/cache_as_ram_auto.c
===
--- trunk/src/mainboard/technexion/tim5690/cache_as_ram_auto.c 2009-12-23
12:52:56 UTC (rev 4989)
+++ trunk/src/mainboard/technexion/tim5690/cache_as_ram_auto.c 2009-12-23
19:16:47 UTC (rev 4990)
@@ -145,20 +145,6 @@
}
#endif /* CONFIG_USE_FALLBACK_IMAGE == 1 */
-/* Early mainboard specific GPIO setup. */
-static void mb_gpio_init(void)
-{
- /* Init Super I/O GPIOs. Done early. */
- it8712f_enter_conf();
- outb(IT8712F_CONFIG_REG_LDN, SIO_INDEX);
- outb(IT8712F_GPIO, SIO_DATA);
- outb(0x62, SIO_INDEX); // set Simple I/O Base Address 0x200
- outb(0x02, SIO_DATA);
- outb(0x63, SIO_INDEX);
- outb(0x00, SIO_DATA);
- it8712f_exit_conf();
-}
-
void real_main(unsigned long bist, unsigned long cpu_init_detectedx);
void cache_as_ram_main(unsigned long bist, unsigned long cpu_init_detectedx)
@@ -191,7 +177,6 @@
/* it8712f_enable_serial does not use its 1st parameter. */
it8712f_enable_serial(0, CONFIG_TTYS0_BASE);
- mb_gpio_init();
it8712f_kill_watchdog();
uart_init();
console_init();
Modified: trunk/src/mainboard/technexion/tim5690/mainboard.c
===
--- trunk/src/mainboard/technexion/tim5690/mainboard.c 2009-12-23 12:52:56 UTC
(rev 4989)
+++ trunk/src/mainboard/technexion/tim5690/mainboard.c 2009-12-23 19:16:47 UTC
(rev 4990)
@@ -26,13 +26,56 @@
#include cpu/amd/mtrr.h
#include device/pci_def.h
#include ../southbridge/amd/sb600/sb600.h
+#include ../superio/ite/it8712f/it8712f.h
#include chip.h
#include tn_post_code.h
+#include vgabios.h
#define ADT7461_ADDRESS 0x4C
#define ARA_ADDRESS 0x0C /* Alert Response Address */
#define SMBUS_IO_BASE 0x1000
+
+/* Video BIOS Function Extensions Specification
+ */
+//Callback Sub-Function 00h - Get LCD Panel ID
+#define LCD_PANEL_ID_NO 0x00 /* No LCD */
+#define LCD_PANEL_ID_01 0x01 /* 1024x768, 24 bits, 1 channel */
+#define LCD_PANEL_ID_02 0x02 /* 1280x1024, 24 bits, 2 channels */
+#define LCD_PANEL_ID_03 0x03 /* 1440x900, 24 bits, 2 channels */
+#define LCD_PANEL_ID_04 0x04 /* 1680x1050, 24 bits, 2 channels */
+#define LCD_PANEL_ID_05 0x05 /* 1920x1200, 24 bits, 2 channels */
+#define LCD_PANEL_ID_06 0x06 /* 1920x1080, 24 bits, 2 channels */
+//Callback Sub-Function 05h
Re: [coreboot] [PATCH] The function int15 working on the Technexion's tim5690.
On Tue, Dec 22, 2009 at 2:38 AM, Libra Li librali1...@gmail.com wrote: Hi Marc Jones, This is a new patch file. I modified mainboard_interrupt_handlers and setup_interrupt_handlers in the util/x86emu/x86.c. Hi Libra, This looks good and passes abuild. Acked-by: Marc Jones marcj...@gmail.com r4990 Marc -- http://marcjonesconsulting.com -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] build service results for r4990
Dear coreboot readers! This is the automatic build system of coreboot. The developer mjones checked in revision 4990 to the coreboot repository. This caused the following changes: Change Log: Add mainboard x86emu interrupt function support. Add tim5690 VGA BIOS functions: int15 getting LCD panel ID. Signed-off-by: Libra Li libra...@technexion.com Acked-by: Marc Jones marcj...@gmail.com Build Log: Compilation of technexion:tim5690 has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4990device=tim5690vendor=technexionnum=2 If something broke during this checkin please be a pain in mjones's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [commit] r4991 - trunk/src/mainboard/technexion/tim5690
Author: stepan Date: 2009-12-23 20:46:36 +0100 (Wed, 23 Dec 2009) New Revision: 4991 Modified: trunk/src/mainboard/technexion/tim5690/Config.lb Log: newconfig compilation failed with (.text+0x4989): undefined reference to `vgabios_init' Signed-off-by: Stefan Reinauer ste...@coresystems.de Acked-by: Stefan Reinauer ste...@coresystems.de Modified: trunk/src/mainboard/technexion/tim5690/Config.lb === --- trunk/src/mainboard/technexion/tim5690/Config.lb2009-12-23 19:16:47 UTC (rev 4990) +++ trunk/src/mainboard/technexion/tim5690/Config.lb2009-12-23 19:46:36 UTC (rev 4991) @@ -30,6 +30,7 @@ ## driver mainboard.o +object vgabios.o object tn_post_code.o object speaker.o -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] fam10/newconfig on supermicro h8dme - early hang
On Tue, Dec 22, 2009 at 04:11:06PM -0700, Myles Watson wrote: This is broken, but I'm not sure if it's the dump or the register value. It shouldn't affect the IO, though. That register looked fine. It seems like IO is broken for you not to be able to start the other processors or complete the mcp55 init. You could print out PCI_DEV(0,0x18,0) @ 0x6C to make sure that the lower bits are what you expect. The ones I'd look at are the default link (bits 11,3,2), disable routing bit (bit 0). The default link should be 2. The disable routing bit can tell you if it's important that the routing registers are messed up. Hrm. If I'm reading that right with this code u32 xxx = pci_read_config32(PCI_DEV(0, 0x18, 0), 0x6c); printk_debug(0x%04x\n,xxx); then what comes out does not look very good: 0xf870 which is 1111 So the default link is 0, and the Routing Table Disable bit is set to zero. You mentioned bit 11 - that seems to be marked as 'reserved' in the BKDG for fam10? Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] build service results for r4991
Dear coreboot readers! This is the automatic build system of coreboot. The developer stepan checked in revision 4991 to the coreboot repository. This caused the following changes: Change Log: newconfig compilation failed with (.text+0x4989): undefined reference to `vgabios_init' Signed-off-by: Stefan Reinauer ste...@coresystems.de Acked-by: Stefan Reinauer ste...@coresystems.de Build Log: Compilation of technexion:tim5690 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4991device=tim5690vendor=technexionnum=2 If something broke during this checkin please be a pain in stepan's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] fam10/newconfig on supermicro h8dme - early hang
This is broken, but I'm not sure if it's the dump or the register value. It shouldn't affect the IO, though. That register looked fine. It seems like IO is broken for you not to be able to start the other processors or complete the mcp55 init. You could print out PCI_DEV(0,0x18,0) @ 0x6C to make sure that the lower bits are what you expect. The ones I'd look at are the default link (bits 11,3,2), disable routing bit (bit 0). The default link should be 2. The disable routing bit can tell you if it's important that the routing registers are messed up. Hrm. If I'm reading that right with this code u32 xxx = pci_read_config32(PCI_DEV(0, 0x18, 0), 0x6c); printk_debug(0x%04x\n,xxx); That looks right. then what comes out does not look very good: 0xf870 which is 1111 That looks pretty broken. Bits 12-15 are reserved according to the BKDG I have. Maybe you should try printing those values earlier? I don't know what's going on to get such strange values. So the default link is 0, and the Routing Table Disable bit is set to zero. You mentioned bit 11 - that seems to be marked as 'reserved' in the BKDG for fam10? In the version I have it's marked as read only. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [commit] r4992 - trunk/src/mainboard/technexion/tim5690
Author: mjones Date: 2009-12-23 23:16:18 +0100 (Wed, 23 Dec 2009) New Revision: 4992 Modified: trunk/src/mainboard/technexion/tim5690/Options.lb Log: Fix technexion tim5690 build failure - REALMODE option required for x86.c mainboard function to be built. Signed-off-by: Marc Jones marcj...@gmail.com Acked-by: Marc Jones marcj...@gmail.com Modified: trunk/src/mainboard/technexion/tim5690/Options.lb === --- trunk/src/mainboard/technexion/tim5690/Options.lb 2009-12-23 19:46:36 UTC (rev 4991) +++ trunk/src/mainboard/technexion/tim5690/Options.lb 2009-12-23 22:16:18 UTC (rev 4992) @@ -73,6 +73,7 @@ uses CONFIG_OBJCOPY uses CONFIG_CONSOLE_VGA uses CONFIG_PCI_ROM_RUN +uses CONFIG_PCI_OPTION_ROM_RUN_REALMODE uses CONFIG_HW_MEM_HOLE_SIZEK uses CONFIG_HT_CHAIN_UNITID_BASE uses CONFIG_HT_CHAIN_END_UNITID_BASE @@ -159,6 +160,7 @@ #VGA Console default CONFIG_CONSOLE_VGA=1 default CONFIG_PCI_ROM_RUN=1 +default CONFIG_PCI_OPTION_ROM_RUN_REALMODE=1 default CONFIG_VGA_ROM_RUN=1 # BTDC: Only one HT device on Herring. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Problems porting H8dmr_fam10 to H8qme-2+
Scan for VGA option rom Got ps2 nak (status=51); continuing ps2_recvbyte timeout I can't see your VGA ROM getting run anywhere. Did I just miss it? Nop, not working anywhere seems like Seabios doesn't find any vga rom. You could try a more verbose setting for SeaBIOS and send the output to Kevin. I'm surprised it doesn't just work. So I tried setting up CONFIG_SB_HT_CHAIN_ON_BUS0 to different values, no luck! Yeah. It doesn't seem like an enumeration problem. The device tree seems like it's getting set up pretty well. You could try having Coreboot run it with vm86 and with CONFIG_CONSOLE_VGA set to see if that works. I'm wondering why SeaBIOS isn't finding it. CONFIG_CONSOLE_VGA was already set to 1. How do I run coreboot with vm86? CONFIG_VGA_ROM_RUN =1 In Kconfig there's a VM86 option, but I don't see it in newconfig. At least now at linux boot up my NICs are found but trying to initialize they got to a Unable to allocate interrupt :( I attach my latest log. Did you change the mptable and irqtables to match the factory assignments? Now, I wishing all of you a merry merry XMAS and have some nice holidays. I hope Santa, or who ever, brings you a whole bunch of new boards ;). Thanks. Merry Christmas to you too. Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Coreboot BSD-style Open Source licence (was: Re: Coreboot or UEFI, who will be the winner.)
Misters, Let me introduce myself : Guillaume FORTAINE, Engineer in Computer Science. I am currently working on a Virtualization Firmware and I would greatly appreciate to go further into the ideas mentioned in the coreboot GSOC project AVATT [1]. I am definitely aware about the UEFI Forum and especially the Hypervista's effort to implement an UEFI Hypervisor [2]. From my analysis, Hypervista is of particular interest as business case for an SMB trying to innovate around UEFI. Their effort has been a failure and I am not surprised, because three years ago (in 2006), I was the first to post on the edk2 website to kindly ask some hardware support from the UEFI Forum [3]. To quote the reply from an Intel engineer [4]: The Edk2 project on www.TianoCore.org does not have silicon enabling code but it does implement UEFI conformant interfaces. It currently builds under Windows, Linux, and Mac OS X. So this code may be helpful to you. The first point is to show you that I followed the UEFI's effort since the beginning and that as a small organization, we tried to contribute to something new. And I didn't receive any support. What is the point of a Platform Initialization software that doesn't provide any hardware ? At least an Intel Customer Reference Board with an initial UEFI port would have been an invaluable help to provide further innovation. Two years later, the situation was the same for Hypervista. To quote [2] : During our recent search for a UEFI compliant PC motherboard, even Intel®, AMI®, and Phoenix® had difficulty identifying PC motherboards that support UEFI 2.x in June 2008. That's why I have chosen coreboot as my hardware initialization firmware. However, to date, there was no case of large scale adoption of coreboot and Intel gave the main reason. To quote [5]: And with the GPL issues around intellectual property, hardware vendors and OEM’s will be unlikely to adopt LinuxBIOS going forward. We can see that the main concern for Hardware Vendors to deploy coreboot is not because it is open source, but, because it is under a GPL License. I believe that it could be valuable to find a compromise for letting the big players use coreboot technology. And my conclusion is that a switch to a BSD-style Open Source licence could be a smart move, thus letting Hardware Vendors (CPU, Chipset, OEMs, IHVs) protect innovation. To prove the business case for a BSD-Licensed coreboot, I contacted two prominent hardware vendors from the UEFI Forum. To quote : a) If you are able to make a clean break with the GPL-based Coreboot for your project to be BSD licensed, there may be elements that we may be interested, or maybe it could be of interest to a special platform. We don't need to open source firmware in that scenario and we can use any of the code for whatever reasons we want to. b) And with the GPL issues around intellectual property, hardware vendors and OEM’s will be unlikely to adopt LinuxBIOS going forward. [5] I think that's nonsense. VIA, AMD et al are quite happily contributing to coreboot. Not as much as we might like, perhaps, but they are doing more than X. That's why despite all the work that X engineers are putting into fast-boot work for Moblin, we still see people out there saying If you want it to boot fast, use AMD or VIA hardware. There is absolutely no reason why a platform firmware couldn't be GPL licensed. There's no real need for people to hide how the memory controller is initialised. It's just baseless paranoia. If there is _anything_ that actually _needs_ to be kept secret, then it'll be crypto (and DRM) stuff -- and if that stuff actually _does_ need to be kept secret then it's a clear indication that the hardware is fundamentally broken anyway. We can see that the main concern for Hardware Vendors to deploy coreboot is not because it is open source, but, because it is under a GPL License. That's why we believe that to switch to a BSD-style Open Source licence could be a smart move, thus letting Hardware Vendors (CPU, Chipset, OEMs, IHVs) protect innovation. This is still a good move anyway, I think. People are too entrenched in the idea that the world will end if they actually tell people how to initialise the hardware, which is insane. We'll never cure that brain damage all in one go and get to a fully open implementation; I think it _has_ to be done piecemeal, which a BSD solution allows. We can start off with some binary-only parts, and then pin the nay-sayers down on one at a time, and make them tell us _precisely_ what form the apocalypse will take if we publish the source code to each one. Our question is fairly simple. Would X consider any interest to coreboot AVATT under a BSD License ? I cannot speak for X on such matters. But there are certainly individuals who would _like_ the company X to be interested, because we believe it's the right approach. My question is fairly simple : Would
Re: [coreboot] Coreboot BSD-style Open Source licence (was: Re: Coreboot or UEFI, who will be the winner.)
On 24.12.2009 00:56, Guillaume FORTAINE wrote: My question is fairly simple : Would people from the coreboot project agree to release the source code under a BSD-style Open Source licence instead of the GPL ? Sorry, I don't see a way of that happening. Some of the code is derived from the GPLv2 Linux kernel, and I don't think you can convince the Linux kernel people to change the license to BSD. Regards, Carl-Daniel -- Developer quote of the year: We are juggling too many chainsaws and flaming arrows and tigers. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
