Re: [coreboot] Kconfig vs. devicetree vs. CMOS policy for options?
Anders Jenbo wrote: ]You could use http://driverpacks.net/ to incorporate the AHCI driveres ]on your cd. Hello Anders, Thanks for the suggestion. I did find that site the other day. At first it looked like what I needed. But when I went to choose a download, I I could find x64 packs only for Vista/7. I use the x64 edition of XP or Server 2003. 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?
Den 17-05-2011 18:17, Scott Duplichan skrev: Idwer Vollering wtote: ]Have you though of using an USB flash drive, to install Windows from? ]http://www.windowsvalley.com/install-windows-2000-xp-2003-using-usb-]storag e-device-pen-drive/ Hello Idwer, Thanks for the suggestion and information. That could be useful in situations where no CD drive is available. I think it does not directly solve the AHCI driver problem though. The Windows XP F6 driver mechanism seems to be completely hard-coded for floppy drive only (tradition or USB). For example, BIOS can make a USB flash drive appear as floppy drive A: to DOS. The Windows XP F6 method is happy with this for the early access where BIOS calls are used to read drive A:. But later in the setup process, execution switches to native mode drivers for floppy access, at which time only a real floppy or a limited number of models of USB floppy will work. Somehow an AHCI driver has to get loaded in order for Windows XP setup to find the hard disk. Probably nliteos could be used in combination with the tool you mention though. Thanks, Scott You could use http://driverpacks.net/ to incorporate the AHCI driveres on your cd. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Kconfig vs. devicetree vs. CMOS policy for options?
Idwer Vollering wtote: ]Have you though of using an USB flash drive, to install Windows from? ]http://www.windowsvalley.com/install-windows-2000-xp-2003-using-usb-]storag e-device-pen-drive/ Hello Idwer, Thanks for the suggestion and information. That could be useful in situations where no CD drive is available. I think it does not directly solve the AHCI driver problem though. The Windows XP F6 driver mechanism seems to be completely hard-coded for floppy drive only (tradition or USB). For example, BIOS can make a USB flash drive appear as floppy drive A: to DOS. The Windows XP F6 method is happy with this for the early access where BIOS calls are used to read drive A:. But later in the setup process, execution switches to native mode drivers for floppy access, at which time only a real floppy or a limited number of models of USB floppy will work. Somehow an AHCI driver has to get loaded in order for Windows XP setup to find the hard disk. Probably nliteos could be used in combination with the tool you mention though. 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?
On Mon, May 16, 2011 at 4:01 PM, Anders jenbo 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" > Dato: man., maj 16, 2011 19:02 > Emne: [coreboot] Kconfig vs. devicetree vs. CMOS policy for options? > Til: > > 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
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" Dato: man., maj 16, 2011 19:02 Emne: [coreboot] Kconfig vs. devicetree vs. CMOS policy for options? Til: 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] Kconfig vs. devicetree vs. CMOS policy for options?
Is there any benefit to actually disabling this stuff? Mvh Anders - Reply message - Fra: "Andrew" Dato: man., maj 16, 2011 19:02 Emne: [coreboot] Kconfig vs. devicetree vs. CMOS policy for options? Til: 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] 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?
On Mon, May 16, 2011 at 11:26 AM, Patrick Georgi 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?
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] Kconfig vs. devicetree vs. CMOS policy for options?
On Mon, May 16, 2011 at 1:18 AM, Patrick Georgi 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?
2011/5/16 Scott Duplichan : > 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
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] Kconfig vs. devicetree vs. CMOS policy for options?
]Peter Stuge wrote: ] ]Reading this I think that there should be a Kconfig option to choose ]if the chipset should be set up as SATA IDE or AHCI. ] ]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? ] ]The purpose is to have a perfectly streamlined user experience across ]all different mainboards. Of course all boards don't support all ]options, but when two different boards *do* support an option, that ]option must be in the same place, working the same way. ] ]The balance between compile time options and NVRAM options is not so ]easy. :\ Hello Peter, Right now, the sata controller is hard-coded to use the AHCI software interface, and the IDE controller is hidden. I think for the most part, AHCI mode should be OK for every use. But certainly at least a compile option for the IDE software interface is needed. Would a kconfig option make sense? I am not familiar with coreboot nvram use. In what situation is AHCI undesirable? For me, the answer is older editions of windows. 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. The ability to disable AHCI is certainly a good feature to have when doing a quick test of an older OS. The OS I use for my own development machine is windows server 2003 x64 edition. This OS has no in-box AHCI driver, so I am familiar with the hassle. Thanks, Scott -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Kconfig vs. devicetree vs. CMOS policy for options?
Hi,
repository service wrote:
> Enable AHCI mode and hide IDE controller
..
> +++ trunk/src/southbridge/amd/cimx_wrapper/sb800/cfg.cSun May 15
> 23:38:08 2011(r6579)
> @@ -83,7 +83,7 @@
> sb_config->SATAMODE.SataMode.SataController = SATA_CONTROLLER;
> sb_config->SATAMODE.SataMode.SataIdeCombMdPriSecOpt = 0; //0 -IDE as
> primary, 1 -IDE as secondary.
> //TODO: set to
> secondary not take effect.
> - sb_config->SATAMODE.SataMode.SataIdeCombinedMode = 0; //IDE controlor
> exposed and combined mode enabled
> + sb_config->SATAMODE.SataMode.SataIdeCombinedMode = 1; //IDE controllor
> is hidden
..
> +++ trunk/src/southbridge/amd/cimx_wrapper/sb800/cfg.hSun May 15
> 23:38:08 2011(r6579)
> @@ -109,7 +109,7 @@
> * NOTE: DO NOT ALLOW SATA & IDE use same mode
> */
> #ifndef SATA_MODE
> - #define SATA_MODE NATIVE_IDE_MODE
> + #define SATA_MODE AHCI_MODE
> #endif
..
> +++ trunk/src/southbridge/amd/cimx_wrapper/sb800/late.c Sun May 15
> 23:38:08 2011(r6579)
> @@ -138,10 +138,9 @@
> static const struct pci_driver sata_driver __pci_driver = {
> .ops = &sata_ops,
> .vendor = PCI_VENDOR_ID_ATI,
> - .device = PCI_DEVICE_ID_ATI_SB800_SATA, //SATA IDE Mode 4390
> + .device = PCI_DEVICE_ID_ATI_SB800_SATA_AHCI,
> };
Reading this I think that there should be a Kconfig option to choose
if the chipset should be set up as SATA IDE or AHCI.
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?
The purpose is to have a perfectly streamlined user experience across
all different mainboards. Of course all boards don't support all
options, but when two different boards *do* support an option, that
option must be in the same place, working the same way.
The balance between compile time options and NVRAM options is not so
easy. :\
//Peter
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
