[commit] r6579 - in trunk/src: include/device southbridge/amd/cimx_wrapper/sb800

[repository service]

Author: mjones
Date: Sun May 15 23:38:08 2011
New Revision: 6579
URL: https://tracker.coreboot.org/trac/coreboot/changeset/6579

Log:
Enable AHCI mode and hide IDE controller to reduce boot time.
Note: enable AHCI in seabios and apply seabios patch:
http://www.mail-archive.com/[e-mail]/msg00437.html

Signed-off-by: Scott Duplichan 
Acked-by: Marc Jones

Modified:
   trunk/src/include/device/pci_ids.h
   trunk/src/southbridge/amd/cimx_wrapper/sb800/cfg.c
   trunk/src/southbridge/amd/cimx_wrapper/sb800/cfg.h
   trunk/src/southbridge/amd/cimx_wrapper/sb800/late.c

Modified: trunk/src/include/device/pci_ids.h
==============================================================================
--- trunk/src/include/device/pci_ids.h	Sun May 15 23:26:04 2011	(r6578)
+++ trunk/src/include/device/pci_ids.h	Sun May 15 23:38:08 2011	(r6579)
@@ -314,6 +314,7 @@

#define PCI_DEVICE_ID_ATI_SB800_LPC             0x439D
 #define PCI_DEVICE_ID_ATI_SB800_SATA            0x4390
+#define PCI_DEVICE_ID_ATI_SB800_SATA_AHCI       0x4391
 #define PCI_DEVICE_ID_ATI_SB800_IDE             0x439C
 #define PCI_DEVICE_ID_ATI_SB800_HDA             0x4383
 #define PCI_DEVICE_ID_ATI_SB800_PCI             0x4384

Modified: trunk/src/southbridge/amd/cimx_wrapper/sb800/cfg.c
==============================================================================
--- trunk/src/southbridge/amd/cimx_wrapper/sb800/cfg.c	Sun May 15 23:26:04 2011	(r6578)
+++ trunk/src/southbridge/amd/cimx_wrapper/sb800/cfg.c	Sun 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
    sb_config->SATAMODE.SataMode.SATARefClkSel = SATA_CLOCK_SOURCE;

/* Azalia HDA */

Modified: trunk/src/southbridge/amd/cimx_wrapper/sb800/cfg.h
==============================================================================
--- trunk/src/southbridge/amd/cimx_wrapper/sb800/cfg.h	Sun May 15 23:26:04 2011	(r6578)
+++ trunk/src/southbridge/amd/cimx_wrapper/sb800/cfg.h	Sun 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

/**

Modified: trunk/src/southbridge/amd/cimx_wrapper/sb800/late.c
==============================================================================
--- trunk/src/southbridge/amd/cimx_wrapper/sb800/late.c	Sun May 15 23:26:04 2011	(r6578)
+++ 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,
 };

-
 #if CONFIG_USBDEBUG
 static void usb_set_resources(struct device *dev)
 {

Kconfig vs. devicetree vs. CMOS policy for options?

[Peter Stuge]

Hi,

repository service wrote:
> Enable AHCI mode and hide IDE controller

..
> +++ trunk/src/southbridge/amd/cimx_wrapper/sb800/cfg.c	Sun 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.h	Sun 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

Kconfig vs. devicetree vs. CMOS policy for options?

[Scott Duplichan]

]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

Kconfig vs. devicetree vs. CMOS policy for options?

[Idwer Vollering]

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-...

Kconfig vs. devicetree vs. CMOS policy for options?

[Scott Duplichan]

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-%5Dstora...
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

Kconfig vs. devicetree vs. CMOS policy for options?

[Anders Jenbo]

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-%5Dstora...
> 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.

Kconfig vs. devicetree vs. CMOS policy for options?

[Scott Duplichan]

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

Kconfig vs. devicetree vs. CMOS policy for options?

[Patrick Georgi]

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

Kconfig vs. devicetree vs. CMOS policy for options?

[Marc Jones]

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

Kconfig vs. devicetree vs. CMOS policy for options?

[Andrew]

16.05.2011 19:31, Marc Jones пишет:
> 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.

Kconfig vs. devicetree vs. CMOS policy for options?

[Patrick Georgi]

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.
> 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.
> 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).
> 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

Kconfig vs. devicetree vs. CMOS policy for options?

[Marc Jones]

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.
> > 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.
> > 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.
> > 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