Re: [coreboot] AMD Persimmon update
Marc Jones wrote: ]Hi Scott, ] ]I'm acking and committing all except the LTO patch, which should wait ]for the crossgcc changes for gcc4.6. i only made a minor tweak to the ]AHCI patch to add a #define for the PCI DID. Thanks Marc. I noticed the PCI ID also, how embarrassing! I will test everything and try to make some of the changes suggested by Peter and Stefan. After that, I need to do the same for asrock e350m1. Thanks, Scott -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Kconfig vs. devicetree vs. CMOS policy for options?
Am 16.05.2011 01:42, schrieb Peter Stuge: Talking to a lot of visitors at LinuxTag it is absolutely clear that this is an example of what should actually be an NVRAM option. Do we have some policy for where to place an option? I don't think we do. Do we want to create one? My idea for a long term plan: - move most stuff to NVRAM - allow defaults in NVRAM config (per chip component) - allow boards to override these defaults - allow boards to lock down options (so they're compiled out in our code and present as hard coded values in cbtable) - probably/eventually: allow user to change defaults/lock them down in Kconfig That way we can make everything flexible, yet lock down options that make no sense (eg. disable IDE/SATA option on boards with IDE function on chip but no connector on board). The hard part will be (again) how to extend Kconfig, and I guess this will require automatic Kconfig file creation (ie. Makefile magic). But since this is the last step (right after Infrastructure Projects/CMOS), this can wait. Patrick -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Win7 on Intel Eagle Heights
Hi Le vendredi 13 mai 2011 à 18:21 -0700, Stefan Reinauer a écrit : On 5/13/11 8:57 AM, Thomas JOURDAN wrote: I'm trying to get Windows 7 booting on my Intel Eagle Heights evaluation board. I tried to follow all the ACPI tips to get Window$ to boot but I can't figure out the bug I'm facing. I'm using a checked build version of Win 7 64-bits. When I start the installer, the first text screen is ok (windows is copying files...) then it switches to graphics mode (green progress bar with logo). Less than a second after switching from text to graphics mode : BSOD. Hi Thomas, Looks like Windows 7 crashes in the Windows Driver Foundation with an illegal memory access. Possibly this is due to an incomplete ACPI implementation for the board. Yes that what I suspect too but so far I can't figure out which ACPI part could be missing. According to my probe, after the page translation, the guilty address seems to point to valid memory area (DDR). Please have a look at the kontron/986lcd-m ACPI code for a modular sample implementation that can boot Windows 7 and http://www.coreboot.org/ACPI for more information on ACPI and ACPI debugging. When I said I followed ACPI tips I mean I refered to kontron/986lcd-m, the coreboot acpi page, and also some tricks disccussed on the mailing list (64-bits alignment, fadt correct size according to version...). I was hoping someone already met this issue and could give me a clue. Regards, Thomas -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Alternate for serial port debug messages
Vikram Narayanan wrote: On Sat, May 14, 2011 at 8:35 AM, Gregg Levine gregg.drw...@gmail.com wrote: On Thu, May 12, 2011 at 6:28 AM, Andrew Goodbody andrew.goodb...@tadpole.com wrote: Vikram Narayanan wrote: ok. I am planning to buy one. Please share your thoughs on which one to buy. NET20DC, it is the simplest, the cheapest by far and will work. In the links(in wiki page), it is mentioned that, === from the link (http://www.ajaystech.com/net20dc.htm) System Requirements Target Computer: Windows Vista and later OS Host Computer: Windows 2000 and later OS === Does this mean anything? or this stuff can also be used for boot time debugging (coreboot) ? It is only relevant for debugging Windows using the kernel debugger, as that is not what you are doing you can ignore those requirements. As for debugging coreboot I believe that it is supposed to work but I have not tried it myself so cannot tell you how functional the support actually is. Andrew -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Kconfig vs. devicetree vs. CMOS policy for options?
2011/5/16 Scott Duplichan sc...@notabs.org: If you happen to want to test windows xp setup using a standard setup CD, windows will not find the drives because it has no AHCI support. The standard solution is the F6 floppy method of adding an AHCI driver, but lack of floppy support on new boards makes this method difficult. I use the http://www.nliteos.com/ tool to make a custom setup CD. But this method requires a new custom CD for each chipset. Have you though of using an USB flash drive, to install Windows from? http://www.windowsvalley.com/install-windows-2000-xp-2003-using-usb-storage-device-pen-drive/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Trac reminder: list of new ticket(s)
Ticket Owner Status Description #176 ste...@coresystems.de new inteltool: added PCI_DEVICE_ID_INTEL_X44 0x29e0 #174 ste...@coresystems.de new Unable to boot from qemu-kvm -- seems to be a cbfs problem #170 ste...@coresystems.de new Need coreboot for ASUS P4PE_X/SE #169 ste...@coresystems.de new ASUS P4PE-X/SE. #168 ste...@coresystems.de new USBDEBUG might slow down coreboot #162 oxygene new Move SYSTEM_TYPE to Kconfig #160 oxygene new Build system: There's no convincing CFLAGS management for util/* #158 w...@gnu.org new buildrom svn error #156 hailfinger new Add Layout File capability to v3 and LAR tool #154 hailfinger new Flashing BIOSes from Fujitsu/Siemens is not supported #150 somebody new AMD DB800 dev board PLL strapping leaves CPU and GLIU in non-optimal clock #147 somebody new Linux kernel halts when scanning the PCI bus below 0:14.4 on RS690 #145 somebody new Fix CMOS handling #143 oxygene new unify intel car for model_6[ef]x #135 ward new Flashrom deletes MAC addresses on Tyan Tomcat n3400B (S2925-E) #129 stepan new etherboot payload does not work with HIGH_TABLES #128 somebody new Improve email user interface for trac #125 somebody new BCM5785 / HT1000 reset functions #111 somebody new Add i18n support for translating strings e.g. for bayou / coreinfo #110 somebody new Allow for per-device subsystem IDs #77 somebody new hang on the "Jumping to coreboot" step on via epia-m with 4-chip 128Mbyte DDR module #76 rminnich new coreboot messages should be accessible in dmesg #18 oxygene new autoprobe apic cluster and application processors on K8 systems #17 stepan new clean up coreboot table handling #16 ollie new I2C driver and mainboard Config.lb #11 yhlu new pirq table automation #5 uwe new Add license header to all source files #2 somebody new Complete tables of supported motherboards -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [commit] r6582 - trunk/src/mainboard/amd/persimmon
On Sun, May 15, 2011 at 4:54 PM, Peter Stuge pe...@stuge.se wrote: repository service wrote: +++ trunk/src/mainboard/amd/persimmon/romstage.c Sun May 15 23:48:22 2011 (r6582) .. + volatile u32 *spiBase = (void *) 0xa000; + u32 save; + __outdword (0xcf8, 0x8000a3a0); + save = __indword (0xcfc); + __outdword (0xcfc, (u32) spiBase | 2); // set temp MMIO base + spiBase [3] = (spiBase [3] ~(3 14)) | (1 14); + spiBase [0] |= 1 18; // fast read enable + __outdword (0xcfc, save); // clear temp base Are there some PCI access functions available also in romstage? Yes indeed there are. We will fix these up. Marc -- http://se-eng.com -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Issue #16: I2C driver and mainboard Config.lb
Hi, Can any one share the latest info on this ticket? While discussing this with Stefan Reinauer, he shared me some info on this. I am also adding this here. From Ollie Lho: There are a lot of mainboards using driver/generic/generic as the i2c driver of their HW monitor. They should be changed to driver/i2c/*. Stefan Reinauer: And it seems drivers/generic/generic does not exist anymore or potentially never existed. Rename driver/i2c/i2cmux to driver/i2c/pca9556 Stefan Reinauer: I think the problem was that i2cmux was not a generic i2cmux driver but instead a driver for the pca9556 but i am not sure anymore. it would take someone to look into that. - Thanks, Vikram -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [commit] r6599 - trunk
Author: oxygene
Date: Mon May 16 17:32:28 2011
New Revision: 6599
URL: https://tracker.coreboot.org/trac/coreboot/changeset/6599
Log:
Move crossgcc rules to coreboot specific Makefile
Toplevel Makefile should (as far as possible) be coreboot-agnostic,
we have Makefile.inc for that.
Signed-off-by: Patrick Georgi patr...@georgi-clan.de
Acked-by: Patrick Georgi patr...@georgi-clan.de
Modified:
trunk/Makefile
trunk/Makefile.inc
Modified: trunk/Makefile
==
--- trunk/Makefile Mon May 16 03:35:03 2011(r6598)
+++ trunk/Makefile Mon May 16 17:32:28 2011(r6599)
@@ -242,12 +242,6 @@
cscope:
cscope -bR
-crossgcc: clean-for-update
- $(MAKE) -C util/crossgcc build
-
-crossgcc-clean: clean-for-update
- $(MAKE) -C util/crossgcc clean
-
doxy: doxygen
doxygen:
$(DOXYGEN) documentation/Doxyfile.coreboot
Modified: trunk/Makefile.inc
==
--- trunk/Makefile.inc Mon May 16 03:35:03 2011(r6598)
+++ trunk/Makefile.inc Mon May 16 17:32:28 2011(r6599)
@@ -230,3 +230,10 @@
done; \
test $$FAILED -eq 0 || { echo ERROR: $$FAILED test(s) failed.
exit 1; }; \
rm -f $$LINTLOG
+
+crossgcc: clean-for-update
+ $(MAKE) -C util/crossgcc build
+
+crossgcc-clean: clean-for-update
+ $(MAKE) -C util/crossgcc clean
+
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Win7 on Intel Eagle Heights
On Mon, May 16, 2011 at 1:54 AM, Thomas Jourdan tjour...@interfaceconcept.com wrote: Hi Le vendredi 13 mai 2011 à 18:21 -0700, Stefan Reinauer a écrit : On 5/13/11 8:57 AM, Thomas JOURDAN wrote: I'm trying to get Windows 7 booting on my Intel Eagle Heights evaluation board. I tried to follow all the ACPI tips to get Window$ to boot but I can't figure out the bug I'm facing. I'm using a checked build version of Win 7 64-bits. When I start the installer, the first text screen is ok (windows is copying files...) then it switches to graphics mode (green progress bar with logo). Less than a second after switching from text to graphics mode : BSOD. Hi Thomas, Looks like Windows 7 crashes in the Windows Driver Foundation with an illegal memory access. Possibly this is due to an incomplete ACPI implementation for the board. Yes that what I suspect too but so far I can't figure out which ACPI part could be missing. According to my probe, after the page translation, the guilty address seems to point to valid memory area (DDR). Please have a look at the kontron/986lcd-m ACPI code for a modular sample implementation that can boot Windows 7 and http://www.coreboot.org/ACPI for more information on ACPI and ACPI debugging. When I said I followed ACPI tips I mean I refered to kontron/986lcd-m, the coreboot acpi page, and also some tricks disccussed on the mailing list (64-bits alignment, fadt correct size according to version...). I was hoping someone already met this issue and could give me a clue. Regards, Thomas Hi Thomas, ScottD had a FADT fix for checked build on Persimmon that might be related to your issue. http://www.coreboot.org/pipermail/coreboot/2011-May/065115.html Marc -- http://se-eng.com -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Kconfig vs. devicetree vs. CMOS policy for options?
On Mon, May 16, 2011 at 1:18 AM, Patrick Georgi patr...@georgi-clan.de wrote: Am 16.05.2011 01:42, schrieb Peter Stuge: Talking to a lot of visitors at LinuxTag it is absolutely clear that this is an example of what should actually be an NVRAM option. Do we have some policy for where to place an option? I don't think we do. Do we want to create one? My idea for a long term plan: - move most stuff to NVRAM - allow defaults in NVRAM config (per chip component) - allow boards to override these defaults - allow boards to lock down options (so they're compiled out in our code and present as hard coded values in cbtable) - probably/eventually: allow user to change defaults/lock them down in Kconfig That way we can make everything flexible, yet lock down options that make no sense (eg. disable IDE/SATA option on boards with IDE function on chip but no connector on board). The hard part will be (again) how to extend Kconfig, and I guess this will require automatic Kconfig file creation (ie. Makefile magic). But since this is the last step (right after Infrastructure Projects/CMOS), this can wait. These are hard problems and I don't know that there is a good answer. Each option seems like a good place to configure the platform, but all have drawbacks. 1. Kconfig is a poor place for device and platform configuration options. Kconfig is the right place for coreboot build options and standard features. The advantage of Kconfig is that the options are available in romstage. 2. CMOS is not a good place for platform options either. It is good for runtime options, but I don't think that there are many options for users to change. What options users would change and how will they change them? CMOS options could even go into the device tree. 3. Devicetree is a good place for platform configuration, but the allocator is complicated and not documented. Options are not available in the romstage. We should come up with some guidelines on what types of coreboot configuration belongs where. Each developer guesses each time or does what is easy for them at the time. Marc -- http://se-eng.com -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Kconfig vs. devicetree vs. CMOS policy for options?
Am 16.05.2011 18:31, schrieb Marc Jones: These are hard problems and I don't know that there is a good answer. Each option seems like a good place to configure the platform, but all have drawbacks. Right now CMOS is somewhat unpopular because it's strictly per-board. Once we're able to move definitions for options to chipsets (if they belong there), they're actually useful. 1. Kconfig is a poor place for device and platform configuration options. Kconfig is the right place for coreboot build options and standard features. The advantage of Kconfig is that the options are available in romstage. Kconfig would be proper for user overrides of options. Definitely a nicer way than requiring users to manage custom Kconfig _and_ custom $whatever files. Hence Kconfig, but that should come last, once everything else works properly. 2. CMOS is not a good place for platform options either. It is good for runtime options, but I don't think that there are many options for users to change. What options users would change and how will they change them? CMOS options could even go into the device tree. The problem is that these overlap. See the example IDE/SATA. They ought to be user configurable (so users can disable IDE on boards that provide both), but they're also platform options, in case the board has no connector (in which case it's useless to provide such an option). So chipset defines that IDE and SATA (and their config options exist), board overrides that and disables IDE (because no IDE exists). 3. Devicetree is a good place for platform configuration, but the allocator is complicated and not documented. Options are not available in the romstage. For some things, yes. Others not so. This is really hard, but I'll concentrate on getting CMOS handling in shape so we can actually make use of it, instead of the poor job we're doing now. We should come up with some guidelines on what types of coreboot configuration belongs where. Each developer guesses each time or does what is easy for them at the time. Because our tools suck. IMHO Guidelines are useless at this point. Patrick -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Ok, let's move on. What shold we do to CBFS?
Hi Hamo, On Fri, May 13, 2011 at 11:07 PM, Hamo hamo...@gmail.com wrote: Ping... On Wed, May 11, 2011 at 8:51 PM, Hamo hamo...@gmail.com wrote: Dear lists, I have got the idea on how to deal with xcompile script for ARM. Now, let's move on to CBFS. It is one of the most difficult part since CBFS is almost hard-coded to X86 architecture. On ARM, we need CBFS like this: /---\ -- Start of ROM | /---\ | | | Reset | | - 0x0 | |---| | | |IVs | | | |---| | | |Boot | | | |Block | | | \---/ | | | | /---\ | --| | | Header| | | | |---| | | | | Name | | | | |---| | |-- Component | |Data | | | | |.. | | | | \---/ | --| | | | ... | | /---\ | --| | | Header| | | | |---| | | | | Name | | | | |---| | |-- Component | |Data | | | | |.. | | | | \---/ | --| \---/ Where should we put the CBFS master header and the pointer to it? I have no idea of how to implement it and not break it on X86 architecture. Any comment or suggestion is very welcome. It is good that you are starting to plan this. I think that the main thing is to get an entrypoint that works for ARM. I would try to leave the cbfs architecture in place and just add another entrypoint. The x86 entrypoint starts at the top and jumps down, the ARM entrypoint cold be located at 0x0 and jump to the same location that x86 entrypoint uses. I don't know if there is a problem with that. What are your ideas about this? Stefan and Patrick might have some thoughts on this too. Marc -- http://se-eng.com -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Kconfig vs. devicetree vs. CMOS policy for options?
On Mon, May 16, 2011 at 11:26 AM, Patrick Georgi patr...@georgi-clan.de wrote: Am 16.05.2011 18:31, schrieb Marc Jones: These are hard problems and I don't know that there is a good answer. Each option seems like a good place to configure the platform, but all have drawbacks. Right now CMOS is somewhat unpopular because it's strictly per-board. Once we're able to move definitions for options to chipsets (if they belong there), they're actually useful. 1. Kconfig is a poor place for device and platform configuration options. Kconfig is the right place for coreboot build options and standard features. The advantage of Kconfig is that the options are available in romstage. Kconfig would be proper for user overrides of options. Definitely a nicer way than requiring users to manage custom Kconfig _and_ custom $whatever files. Hence Kconfig, but that should come last, once everything else works properly. I think that Kconfig should be about building the platform (make). We have overloaded it with platform configurations that I feel don't really belong there. There are a few items for where the make needs to understand the the code size requirement etc, but options about memory types, and CPU or slot numbers etc, don't belong there. 2. CMOS is not a good place for platform options either. It is good for runtime options, but I don't think that there are many options for users to change. What options users would change and how will they change them? CMOS options could even go into the device tree. The problem is that these overlap. See the example IDE/SATA. They ought to be user configurable (so users can disable IDE on boards that provide both), but they're also platform options, in case the board has no connector (in which case it's useless to provide such an option). So chipset defines that IDE and SATA (and their config options exist), board overrides that and disables IDE (because no IDE exists). I agree, but I think that there are few options that might be useful for an end user to change, but there are many platform config that are not appropriate CMOS options. 3. Devicetree is a good place for platform configuration, but the allocator is complicated and not documented. Options are not available in the romstage. For some things, yes. Others not so. This is really hard, but I'll concentrate on getting CMOS handling in shape so we can actually make use of it, instead of the poor job we're doing now. CMOS options should only be for runtime options. I think that there are far more build time and platform configurations than there are runtime. But, I'll be interested to see what your thoughts are. We should come up with some guidelines on what types of coreboot configuration belongs where. Each developer guesses each time or does what is easy for them at the time. Because our tools suck. IMHO Guidelines are useless at this point. Patrick I think that any guidance we could provide would be an improvement. Marc -- http://se-eng.com -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Kconfig vs. devicetree vs. CMOS policy for options?
16.05.2011 19:31, Marc Jones пишет: 2. CMOS is not a good place for platform options either. It is good for runtime options, but I don't think that there are many options for users to change. What options users would change and how will they change them? CMOS options could even go into the device tree. IMHO device operation modes (for ex., AHCI/legacy IDE for SATA, LPT port modes, etc) should be in CMOS. Also switches for enabling/disabling devices (LPT, FDD, IDE/SATA, etc) should be in CMOS. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Kconfig vs. devicetree vs. CMOS policy for options?
Is there any benefit to actually disabling this stuff? Mvh Anders - Reply message - Fra: Andrew ni...@seti.kr.ua Dato: man., maj 16, 2011 19:02 Emne: [coreboot] Kconfig vs. devicetree vs. CMOS policy for options? Til: coreboot@coreboot.org 16.05.2011 19:31, Marc Jones пишет: 2. CMOS is not a good place for platform options either. It is good for runtime options, but I don't think that there are many options for users to change. What options users would change and how will they change them? CMOS options could even go into the device tree. IMHO device operation modes (for ex., AHCI/legacy IDE for SATA, LPT port modes, etc) should be in CMOS. Also switches for enabling/disabling devices (LPT, FDD, IDE/SATA, etc) should be in CMOS. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [commit] r6592 - in trunk/src: mainboard/amd/persimmon southbridge/amd/cimx_wrapper/sb800
On Sun, May 15, 2011 at 5:57 PM, Peter Stuge pe...@stuge.se wrote:
repository service wrote:
+++ trunk/src/southbridge/amd/cimx_wrapper/sb800/late.c Mon May 16
00:07:56 2011 (r6592)
..
@@ -414,15 +413,16 @@
break;
case (0x15 3) | 0: /* 0:15:0 PCIe PortA */
+ sb_config-PORTCONFIG[0].PortCfg.PortPresent = dev-enabled;
+ return;
case (0x15 3) | 1: /* 0:15:1 PCIe PortB */
+ sb_config-PORTCONFIG[1].PortCfg.PortPresent = dev-enabled;
+ return;
case (0x15 3) | 2: /* 0:15:2 PCIe PortC */
+ sb_config-PORTCONFIG[2].PortCfg.PortPresent = dev-enabled;
+ return;
coreboot uses tab indent, right?
That said, this reading of devicetree is a great improvement!
Thanks for the tab fix.
case (0x15 3) | 3: /* 0:15:3 PCIe PortD */
- gpp_port = (dev-path.pci.devfn) 0x03;
- if (dev-enabled) {
- sb_config-PORTCONFIG[gpp_port].PortCfg.PortPresent =
ENABLED;
- } else {
- sb_config-PORTCONFIG[gpp_port].PortCfg.PortPresent =
DISABLED;
- }
+ sb_config-PORTCONFIG[3].PortCfg.PortPresent = dev-enabled;
Is it guaranteed that ENABLED == dev-enabled and DISABLED == !dev-enabled?
Yes, it is an enable bit in the register and POR defaults to disabled.
--
http://se-eng.com
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [commit] r6585 - trunk/src/mainboard/amd/persimmon
On Sun, May 15, 2011 at 6:52 PM, Peter Stuge pe...@stuge.se wrote:
repository service wrote:
Log:
Enable SPI cacheline prefetch early to reduce boot time.
This is the same commit message as the previous commit, r6584.
..
+++ trunk/src/mainboard/amd/persimmon/romstage.c Sun May 15 23:56:03
2011 (r6585)
@@ -50,6 +50,21 @@
// all cores: set pstate 0 (1600 MHz) early to save a few ms of boot time
__writemsr (0xc0010062, 0);
+ if (boot_cpu())
+ {
+ u8 reg8;
+ // SB800: program AcpiMmioEn to enable MMIO access to MiscCntrl register
+ outb(0x24, 0xCD6);
+ reg8 = inb(0xCD7);
+ reg8 |= 1;
+ reg8 = ~(1 1);
+ outb(reg8, 0xCD7);
+
+ // program SB800 MiscCntrl
+ *(volatile u32 *)(0xFED8+0xE00+0x40) = ~((1 0) | (1 2)); /*
48Mhz */
+ *(volatile u32 *)(0xFED8+0xE00+0x40) |= 1 1; /* 48Mhz */
+ }
..but the code does something else?
Ugh, Sorry, I put the wrong commit message. It should be the following.
Move SB800 clock init earlier to fix problem where initial serial port
output is garbled.
Signed-off-by: Scott Duplichan sc...@notabs.org
Does anyone have a recommendation to update,fix, or otherwise improve
the svn history?
Thanks,
Marc
--
http://se-eng.com
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Kconfig vs. devicetree vs. CMOS policy for options?
On Mon, May 16, 2011 at 4:01 PM, Anders jenbo and...@jenbo.dk wrote: Is there any benefit to actually disabling this stuff? Mvh Anders Sometimes it's necessary, like in the case of disabling integrated graphics to allow a PCI/AGP/PCIe card to work. Other times, like disabling ps2 and floppy devices, it shaves a little time off bootup, because neither coreboot nor the guest OS have to do init for non-existent devices. Still others it's just convenient, like disabling a problematic or slow onboard NIC or poor quality audio device, again in favor of another board. -Corey - Reply message - Fra: Andrew ni...@seti.kr.ua Dato: man., maj 16, 2011 19:02 Emne: [coreboot] Kconfig vs. devicetree vs. CMOS policy for options? Til: coreboot@coreboot.org 16.05.2011 19:31, Marc Jones пишет: 2. CMOS is not a good place for platform options either. It is good for runtime options, but I don't think that there are many options for users to change. What options users would change and how will they change them? CMOS options could even go into the device tree. IMHO device operation modes (for ex., AHCI/legacy IDE for SATA, LPT port modes, etc) should be in CMOS. Also switches for enabling/disabling devices (LPT, FDD, IDE/SATA, etc) should be in CMOS. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
