Re: [coreboot] k8 status: it speaks for itself
ron minnich wrote: CPU 804 Mhz Etherboot 5.4.3 (GPL) http://etherboot.org Drivers: VIA-VELOCITY/PCI Images: ELF Protocols: DHCP TFTP Relocating _text from: [000100e0,000349c0) to [0007b720,000a) Boot from (N)etwork or (Q)uit? Probing pci nic... Probing isa nic... I've committed the last set of changes which mainly consist of fixing a null pointer bug that I believe is in v2. Next steps are to better fill out the dts, and start working on the warnings etc. I get. ron Good job Ron! -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] the patches of AMD s1g1 socket
I will check it in and then do a whitespace cleanup checkin today. If someone wants to give me the other copyright holders I can also add that. Marc ron minnich wrote: OK I am acking this patch. What I would request is that in future all the k8 code be processed by: indent -kr -i 8 before a patch is made. But we can clean this up, it is important to get this code in. Acked-by: Ronald G. Minnich <[EMAIL PROTECTED]> -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] the patches of AMD s1g1 socket
ron minnich wrote: I think these are the proper extra copyright holders (from v3) * Copyright (C) 2002 Linux Networx * (Written by Eric Biederman <[EMAIL PROTECTED]> for Linux Networx) * Copyright (C) 2004 YingHai Lu Thanks, I will add that. -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] AMD RS690 and SB600 documents
Hi all, The AMD SB600 public register document was released today! Along with the previously released RS690 and CPU documentation, coreboot should be able to fully support AMD RS690/SB600 platforms. Patches for the DBM690T development platform and RS690, and SB600 chipset will be available early next week. Until then, visit http://www.coreboot.org/AMD_Public_Documents for links to the documents. The direct link to the SB600 register doc is: http://www.coreboot.org/docs/AMD/46155_sb600_rrg_pub_3.03.pdf Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] the patches of AMD s1g1 socket
ron minnich wrote: OK I am acking this patch. What I would request is that in future all the k8 code be processed by: indent -kr -i 8 before a patch is made. But we can clean this up, it is important to get this code in. Acked-by: Ronald G. Minnich <[EMAIL PROTECTED]> Added copyright and fixed some whitespace in the new code. A more complete whitespace cleanup to follow this checkin. r3585 Thanks Michael and Ron. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] the patches of AMD s1g1 socket
Marc Jones wrote: ron minnich wrote: OK I am acking this patch. What I would request is that in future all the k8 code be processed by: indent -kr -i 8 before a patch is made. But we can clean this up, it is important to get this code in. Acked-by: Ronald G. Minnich <[EMAIL PROTECTED]> Added copyright and fixed some whitespace in the new code. A more complete whitespace cleanup to follow this checkin. r3585 Thanks Michael and Ron. Marc Whitespace and style cleanup. r3586 Thanks, Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AMD RS690 and SB600 documents
Carl-Daniel Hailfinger wrote: Hi Marc, a big THANK YOU to AMD and everyone who made this possible! You guys are awesome! Can we make a slashdot/phoronix/lwn/... announcement or will the server be overloaded? I added a link to a cached version of the document just in case we get hit heavily by the slashdot effect. I don't know what the server can handle or what interest there might be... Maybe wait until next week when we release the source to make an announcement. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] rs690, sb600, dbm690t patches
Michael had a slight problem sending the patches. There are only three patches to review, rs690.patch, sb600.patch, and dbm690t.patch. Please ignore the [EMAIL PROTECTED]' emails. Thanks, Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] The patch of AMD DBM690T board
Rudolf Marek wrote: While I fully agree your suggestion is absolutely a good thing, we should get the code in first and then improve it over time. Yes it is. I went through a code to see what it does while traveling in the train. Sometimes the comments are quite funny ;) I think the only review of code which we need now is not the functional one, but mostly check for typos which are real bugs. Unfortunately sometime the code refers to BG (BDG-215SB600-03.pdf) which seem to be under NDA only. Overall quality of codingstyle, comments is I think the best (or nearly the best ;) we have so far. Rudolf The BDG (BIOS Developer Guide) will have a public release in the next few weeks. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] The patch of AMD DBM690T board
Stefan Reinauer wrote: Thank you Michael, Zheng, Marc, Jordan! This is a good day for coreboot! I think I checked in the last patch now. r3590. Let me know if something's missing. Stepan, Thanks, I think that everything is in. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] r3590 build service
Carl-Daniel Hailfinger wrote: Hi, the dbm690t breaks with abuild due to section overlap (0x2600 more room needed). Maybe we need a Config-abuild.lb? On 22.09.2008 17:19, coreboot information wrote: This is the automated build check service of coreboot. The developer "stepan" checked in revision 3590 Change Log: Patch for AMD DBM690T board. Signed-off-by: Michael Xie <[EMAIL PROTECTED]> Reviewed-by: Marc Jones <[EMAIL PROTECTED]> Acked-by: Stefan Reinauer <[EMAIL PROTECTED]> Build Log: Compilation of amd:dbm690t is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3590&device=dbm690t&vendor=amd input/output = 172916/61032 = 2.833 /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: section .id [fffbffd8 -> fffbffef] overlaps section .rom [fffb7e6c -> fffc21cf] /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: coreboot: section .id vma 0xfffbffd8 overlaps previous sections /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: coreboot: section .reset vma 0xfffbfff0 overlaps previous sections collect2: ld returned 1 exit status make[1]: *** [coreboot] Error 1 make: *** [normal/coreboot.rom] Error 1 make: *** Waiting for unfinished jobs input/output = 172916/61034 = 2.833 /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: section .id [ffd8 -> ffef] overlaps section .rom [7e6e -> 0001252f] /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: coreboot: section .id vma 0xffd8 overlaps previous sections /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: coreboot: section .reset vma 0xfff0 overlaps previous sections collect2: ld returned 1 exit status make[1]: *** [coreboot] Error 1 make: *** [fallback/coreboot.rom] Error 1 Regards, Carl-Daniel I am working one up. A bug has snuck in here somewhere. I am investigating. Thanks, Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] dbm690t buildrom patch
Patch attached. Thanks, Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors Add AMD dbm690t mainboard to buildrom. The dbm690t uses an embedded VBIOS which buildrom can attach to the ROM image. Signed-off-by: Marc Jones <[EMAIL PROTECTED]> Signed-off-by: Jordan Crouse <[EMAIL PROTECTED]> Index: buildrom-devel/config/platforms/Config.in === --- buildrom-devel.orig/config/platforms/Config.in 2008-08-11 10:04:01.0 -0600 +++ buildrom-devel/config/platforms/Config.in 2008-09-22 10:23:09.0 -0600 @@ -164,6 +164,12 @@ depends on COREBOOT_V2 select PLATFORM select PLATFORM_SUPPORT_64BIT + +config PLATFORM_DBM690T +bool "AMD dbM690T" +depends on VENDOR_AMD +select PLATFORM +select PLATFORM_SUPPORT_64BIT endchoice choice @@ -208,4 +214,35 @@ Say 'y' here to patch the build to work on an emulated platform in the AMD SimNow (TM) simulator +config AMD_R690_HEADLESS + bool "Build the R690 platform as headless (without VGA)" + depends on ADVANCED && PLATFORM_DBM690T + default n + help + Say 'y' here to build without the VGA BIOS for the + R690 chipset. This will result in no video graphics + for the platform. This is not likely what you want, + so you should say 'n' here unless you are absolutely + sure. + +config AMD_R690_USE_VBIOS + bool + depends on !AMD_R690_HEADLESS + default y + +config AMD_R690_CUSTOM_VBIOS + bool "Specify a custom location for the R690 video BIOS" + depends on AMD_R690_USE_VBIOS + help + Say 'y' here to specify a custom location for the R690 + video BIOS file. Otherwise, it will be looked for in a + default location. + +config AMD_R690_VBIOS + string "Location of the RS690 Video BIOS file" + depends on AMD_R690_CUSTOM_VBIOS + default "" + help + Specify the full pathname for your RS690 video BIOS file + endmenu Index: buildrom-devel/config/platforms/dbm690t.conf === --- /dev/null 1970-01-01 00:00:00.0 + +++ buildrom-devel/config/platforms/dbm690t.conf2008-09-21 15:51:11.0 -0600 @@ -0,0 +1,64 @@ +# Support for the AMD Herring Platform + + Platform configuration + +CC=gcc +STRIP=strip +AS=as + +ifeq ($(CONFIG_TARGET_64BIT),y) +TARGET_ARCH=x86_64 +CFLAGS_platform = +else +TARGET_ARCH=i686 +CFLAGS_platform = +endif + +# Targets + +KERNEL_MK=$(PACKAGE_DIR)/kernel/dbm690t.mk +CBV2_MK=$(PACKAGE_DIR)/coreboot-v2/dbm690t.mk + +# kernel configuration (for LAB) + +ifeq ($(CONFIG_TARGET_64BIT),y) +KERNEL_VERSION=2.6.22.2 +KERNEL_MK=$(PACKAGE_DIR)/kernel/dbm690t-x86_64.mk +KERNEL_CONFIG=$(PACKAGE_DIR)/kernel/conf/defconfig-dbm690t-x86_64 +BUSYBOX_CONFIG=defconfig-dbm690t-x86_64 +UCLIBC_VER=0.9.29 +UCLIBC_CONFIG=defconfig-x86_64 +else +KERNEL_VERSION=2.6.20.2 +KERNEL_CONFIG=$(PACKAGE_DIR)/kernel/conf/defconfig-dbm690t +UCLIBC_VER=0.9.29 +endif + +#UCLIBC_ARCH=$(TARGET_ARCH) + +# Etherboot configuration +ETHERBOOT_ARCH=i386 + +# coreboot configuration + +COREBOOT_VENDOR=amd +CBV2_CONFIG=Config.lb +CBV2_PAYLOAD_FILE_EXT=elf + +CBV3_TAG=HEAD + +COREBOOT_BOARD=dbm690t +CBV2_TDIR=dbm690t +CBV2_TAG=3092 + +# FILO configuration + +FILO_CONFIG=dbm690t-Config + +# VIDEO BIOS configuration + +ifeq ($(CONFIG_AMD_R690_VBIOS),"") +AMD_R690_VBIOS_LOCATION := $(BASE_DIR)/sources/amd_rs690_vbios.bin +else +AMD_R690_VBIOS_LOCATION = $(subst ",,$(CONFIG_AMD_R690_VBIOS)) +endif Index: buildrom-devel/config/platforms/platforms.conf === --- buildrom-devel.orig/config/platforms/platforms.conf 2008-09-11 12:41:29.0 -0600 +++ buildrom-devel/config/platforms/platforms.conf 2008-09-21 19:58:48.0 -0600 @@ -27,6 +27,7 @@ PLATFORM-$(CONFIG_PLATFORM_CHEETAH_FAM10) = serengeti_cheetah.conf PLATFORM-$(CONFIG_PLATFORM_GA_2761GXDK) = ga-2761gxdk.conf PLATFORM-$(CONFIG_PLATFORM_QEMU-X86) = qemu.conf +PLATFORM-$(CONFIG_PLATFORM_DBM690T) = dbm690t.conf include $(CONFIG_DIR)/platforms/$(PLATFORM-y) @@ -35,3 +36,5 @@ # For those platforms that have option roms, add the following line #DEPENDS-$(MYPLATFORM) += roms + +DEPENDS-$(CONFIG_PLATFORM_DBM690T) += roms Index: buildrom-devel/packages/coreboot-v2/dbm690t.mk === --- /dev/null 1970-01-01 00:00:00.0 + +++ buildrom-devel/packages/coreboot-v2/dbm690t.mk 2008-09-21 15:51:11.0 -0600 @@ -0,0 +1,22 @@ +# This is the AMD DBM690T coreboot target + +CBV2_PATCHES= + +# Make sure we have the
[coreboot] it8712f patch
This patch allows the dbm690t SIO to work. The changes affect the Asus
a8n_e. Can someone with a a8n_e test this?
Thanks,
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
The AMD dbm690t mainboard uses the it8712f SIO with the
default 48MHz clock input. The Asus a8n_e uses the it8712f
with a 24MHz clock input. The it8712f early init code was
setting a 24MHz input clock. Since 48Mhz is the default I added
a function to set 24MHz input clock to the a8n_e.
Signed-off-by: Marc Jones <[EMAIL PROTECTED]>
Index: coreboot-v2/src/superio/ite/it8712f/it8712f_early_serial.c
===
--- coreboot-v2.orig/src/superio/ite/it8712f/it8712f_early_serial.c
2008-09-22 08:46:12.0 -0600
+++ coreboot-v2/src/superio/ite/it8712f/it8712f_early_serial.c 2008-09-22
14:17:44.0 -0600
@@ -45,10 +45,10 @@
outb(value, SIO_DATA);
}
-/* Enable the peripheral devices on the IT8712F Super I/O chip. */
-static void it8712f_enable_serial(device_t dev, unsigned iobase)
+
+static void it8712f_enter_conf(void)
{
- /* (1) Enter the configuration state (MB PnP mode). */
+ /* Enter the configuration state (MB PnP mode). */
/* Perform MB PnP setup to put the SIO chip at 0x2e. */
/* Base address 0x2e: 0x87 0x01 0x55 0x55. */
@@ -57,6 +57,32 @@
outb(0x01, IT8712F_CONFIGURATION_PORT);
outb(0x55, IT8712F_CONFIGURATION_PORT);
outb(0x55, IT8712F_CONFIGURATION_PORT);
+}
+
+static void it8712f_exit_conf(void)
+{
+ /* Exit the configuration state (MB PnP mode). */
+ it8712f_sio_write(0x00, IT8712F_CONFIG_REG_CC, 0x02);
+}
+
+
+static void it8712f_24mhz_clkin(void)
+{
+ it8712f_enter_conf();
+
+ /* Select 24MHz CLKIN (48MHZ default)*/
+ it8712f_sio_write(0x00, IT8712F_CONFIG_REG_CLOCKSEL, 0x1);
+
+ it8712f_exit_conf();
+
+}
+
+/* Enable the peripheral devices on the IT8712F Super I/O chip. */
+static void it8712f_enable_serial(device_t dev, unsigned iobase)
+{
+
+ /* (1) Enter the configuration state (MB PnP mode). */
+ it8712f_enter_conf();
/* (2) Modify the data of configuration registers. */
@@ -69,13 +95,9 @@
it8712f_sio_write(IT8712F_SP1, 0x30, 0x1); /* Serial port 1 */
it8712f_sio_write(IT8712F_SP2, 0x30, 0x1); /* Serial port 2 */
- /* Select 24MHz CLKIN (set bit 0). */
- it8712f_sio_write(0x00, IT8712F_CONFIG_REG_CLOCKSEL, 0x01);
-
/* Clear software suspend mode (clear bit 0). TODO: Needed? */
/* it8712f_sio_write(0x00, IT8712F_CONFIG_REG_SWSUSP, 0x00); */
/* (3) Exit the configuration state (MB PnP mode). */
- it8712f_sio_write(0x00, IT8712F_CONFIG_REG_CC, 0x02);
+ it8712f_exit_conf();
}
-
Index: coreboot-v2/src/mainboard/asus/a8n_e/cache_as_ram_auto.c
===
--- coreboot-v2.orig/src/mainboard/asus/a8n_e/cache_as_ram_auto.c
2008-09-22 09:28:13.0 -0600
+++ coreboot-v2/src/mainboard/asus/a8n_e/cache_as_ram_auto.c2008-09-22
14:14:57.0 -0600
@@ -221,6 +221,7 @@
bsp_apicid = init_cpus(cpu_init_detectedx);
}
+ it8712f_24mhz_clkin();
it8712f_enable_serial(SERIAL_DEV, TTYS0_BASE);
uart_init();
console_init();
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] it8712f patch
Andy Jakobs wrote: Dear Marc, I am happy, that there is still work on the A8N-E, as I own such a board. Unfortunately the PS/2 keyboard port is not working yet (see also build tutorial from the wiki). I already applied your patch and it ended in a grub or filo shell. From a second PC I can access the filo shell and type in commands over minicom. For grub2 this does not work. So do you have an instruction for me, how to test that your patch is successfull? Do you need the minicom log? Andy, This patch affected a platform that used the same SIO but at the other input clock rate. If you get the minicom log then the patch is working since the clockrate affects the UART rate. So, Please send your Acked-by: I also see the ps/2 keyboard problem with this SIO. It seems to be something with the linux keyboard init. The keyboard works in filo and then stops when linux loads. I have been able to get it unstuck by reading the input buffer by hand. My guess is there is something left in buffer that linux isn't expecting. Probably a KBC bug. USB keyboards work fine in linux on my platform so this was a lower priority but I will look at this more today. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] The patch of AMD DBM690T board
ron minnich wrote: any suggested boards people can buy to try this out? I need to buy a board anyway as i want to have two for development uses. It will probably require some minor porting but the GA-MA69G-S3H seems popular with some of our marketing people. It is AM2 instead of s1g1 but that should be ok. http://www.gigabyte.com.tw/Products/Motherboard/Products_Overview.aspx?ProductID=2579 You can find more board recommendations here: http://wwwd.amd.com/catalog/salescat.nsf/shop?openform Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] it8712f patch
Rudolf Marek wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, Marc patch solves mine issue with 48MHz too. But mine IT8712F has running watchdog. This patch adds support for watchdog kill and adds it to Asus M2V-MX SE. Signed-off-by: Rudolf Marek <[EMAIL PROTECTED]> Acked-by: Marc Jones <[EMAIL PROTECTED]> -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] it8712f patch
Rudolf Marek wrote: Marc patch solves mine issue with 48MHz too. But mine IT8712F has running watchdog. Does your keyboard work? Is this a problem with linux for this SIO(KBC)? Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] it8712f patch
Rudolf Marek wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Marc, I never acked any patch here, don't know if I can do that. If yes ;) can give you an ack for your patch. It clearly works for Andy. Acked-by: Rudolf Marek <[EMAIL PROTECTED]> r 3594 Thanks, Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] r3591 build service
Rudolf Marek wrote: 2) CPU will run on slowest frequency. I dont have any solution for this so far. It seems there is something wrong with it but I can't get it what it is. It will take some more time. This is the fid/vid setup. The dbm690t has the cleanest example of fid/vid working (see cache_as_ram.c). Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] r3596 - trunk/coreboot-v2/targets/amd/dbm690t
Carl-Daniel Hailfinger wrote: Hi Marc, thanks for the checkin. The situation is now much better, but if fails in another place. I've fixed up the last remaining problem (one missing line in Config-abuild.lb) in r3597. On 24.09.2008 05:21, [EMAIL PROTECTED] wrote: New Revision: 3596 Add abuild support for the dbm690t. (trivial) Signed-off-by: Marc Jones <[EMAIL PROTECTED]> Acked-by: Marc Jones <[EMAIL PROTECTED]> Regards, Carl-Daniel Huh, I'm not sure how I lost that line. Thanks, Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] keyboard init patch
This patch fixes the it8712f keyboard issues and should also fix any
general keyboard init issues with other SIOs.
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
This patch fixes the dbm690t keyboard not working issue. It should also
fix the a8n_e and any other it8712f SIO keyboard issues. The it8712f
requires an archaic PS/2 mode setting to the keyboard controller before
accessing the keyboard. Beyond that, I made the keyboard controller and
keyboard init more robust and added more informative debug output.
Signed-off-by: Marc Jones <[EMAIL PROTECTED]>
Index: coreboot-v2/src/pc80/keyboard.c
===
--- coreboot-v2.orig/src/pc80/keyboard.c2008-09-24 17:46:55.0
-0600
+++ coreboot-v2/src/pc80/keyboard.c 2008-09-26 10:56:55.0 -0600
@@ -1,82 +1,220 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2008 Advanced Micro Devices, Inc.
+ * Copyright (C) [EMAIL PROTECTED]
+ *
+ * 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; version 2 of the License.
+ *
+ * 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
#include
#include
#include
-static int kbd_empty_input_buffer(void)
+static int kbc_input_buffer_empty(void)
{
- unsigned long timeout;
+ u32 timeout;
for(timeout = 100; timeout && (inb(0x64) & 0x02); timeout--) {
- post_code(0);
+ inb(0x80);
+ }
+
+ if (!timeout) {
+ printk_err("Unexpected Keyboard controller input buffer
full\n");
}
return !!timeout;
}
-static int kbd_empty_output_buffer(void)
+
+static int kbc_output_buffer_full(void)
{
- unsigned long timeout;
+ u32 timeout;
for(timeout = 100; timeout && ((inb(0x64) & 0x01) == 0); timeout--)
{
- post_code(0);
+ inb(0x80);
+ }
+
+ if (!timeout) {
+ printk_err("Keyboard controller output buffer result
timeout\n");
}
return !!timeout;
}
-/* much better keyboard init courtesy [EMAIL PROTECTED]
- TODO: Typematic Setting, the keyboard is too slow for me */
-static void pc_keyboard_init(struct pc_keyboard *keyboard)
+
+static int kbc_cleanup_buffers(void)
+{
+ u32 timeout;
+ for(timeout = 100; timeout && (inb(0x64) & 0x03); timeout--) {
+ inb(0x60);
+ }
+
+ if (!timeout) {
+ printk_err("Couldn't cleanup the keyboard controller
buffers\n");
+ printk_err("0x64: 0x%x, 0x60: 0x%x\n", inb(0x64), inb(0x60));
+ }
+ return !!timeout;
+}
+
+
+static u8 send_keyboard(u8 command)
{
- unsigned char regval;
+ u8 regval = 0;
+ u8 resend = 10;
+
+ do {
+ if (!kbc_input_buffer_empty()) return 0;
+ outb(command, 0x60);
+ if (!kbc_output_buffer_full()) return 0;
+ regval = inb(0x60);
+ --resend;
+ } while (regval == 0xFE && resend > 0);
+ return regval;
+}
+
+
+static void pc_keyboard_init(struct pc_keyboard *keyboard)
+{
+ u8 regval;
+ u8 resend;
printk_debug("Keyboard init...\n");
- /* send cmd = 0xAA, self test 8042 */
- outb(0xaa, 0x64);
- /* empty input buffer or any other command/data will be lost */
- if (!kbd_empty_input_buffer()) {
- printk_err("Keyboard input buffer would not empty\n");
+ /* clean up any junk that might have been in the kbc */
+ if (!kbc_cleanup_buffers()) return;
+
+ /* reset/self test 8042 - send cmd 0xAA, */
+ if (!kbc_input_buffer_empty()) return;
+ outb(0xAA, 0x64);
+ if (!kbc_output_buffer_full()) return;
+
+ /* read self-test result, 0x55 is returned in the output buffer (0x60)
*/
+ if ((regval = inb(0x60) != 0x55)) {
+ printk_err("Keyboard Controller selftest failed: 0x%x\n",
regval);
return;
}
- /* empty output buffer or any other command/data will be lost */
- if (!kbd_empty_output_buffer()) {
- printk_err("Keyboard output buffer would not empty\n");
+ /* Enable
[coreboot] [patch] irq12 for dbm690t mainboard
Patch attached. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors Add IRQ12 to the dbm690t mptable for mouse interrupt support. Signed-off-by: Marc Jones <[EMAIL PROTECTED]> Index: coreboot-v2/src/mainboard/amd/dbm690t/mptable.c === --- coreboot-v2.orig/src/mainboard/amd/dbm690t/mptable.c2008-09-26 11:10:34.0 -0600 +++ coreboot-v2/src/mainboard/amd/dbm690t/mptable.c 2008-09-26 10:11:30.0 -0600 @@ -135,6 +135,8 @@ smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE | MP_IRQ_POLARITY_HIGH, bus_isa, 0x7, apicid_sb600, 0x7); smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE | MP_IRQ_POLARITY_HIGH, +bus_isa, 0xc, apicid_sb600, 0xc); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE | MP_IRQ_POLARITY_HIGH, bus_isa, 0xd, apicid_sb600, 0xd); smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE | MP_IRQ_POLARITY_HIGH, bus_isa, 0xe, apicid_sb600, 0xe); -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] keyboard init patch
Carl-Daniel Hailfinger wrote: On 26.09.2008 19:02, Marc Jones wrote: This patch fixes the it8712f keyboard issues and should also fix any general keyboard init issues with other SIOs. Great work spotting this! Can you check whether the patch is needed for v3 as well? Yes, It should be a drop in for v3. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [patch] irq12 for dbm690t mainboard
Carl-Daniel Hailfinger wrote: On 26.09.2008 19:15, Marc Jones wrote: Add IRQ12 to the dbm690t mptable for mouse interrupt support. Signed-off-by: Marc Jones <[EMAIL PROTECTED]> Acked-by: Carl-Daniel Hailfinger <[EMAIL PROTECTED]> r3603 Thanks Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] keyboard init patch
Carl-Daniel Hailfinger wrote: On 26.09.2008 19:39, Marc Jones wrote: Carl-Daniel Hailfinger wrote: On 26.09.2008 19:02, Marc Jones wrote: This patch fixes the it8712f keyboard issues and should also fix any general keyboard init issues with other SIOs. Great work spotting this! Can you check whether the patch is needed for v3 as well? Yes, It should be a drop in for v3. Thanks for the info, I'll take care of this after Oct 2. I'd ack your v2 patch, but my keyboard controller knowledge is not good enough to verify this. Have you checked that this doesn't touch any ROMCC-compiled code (register shortage)? This is all post mem init (romcc and CAR). It uses the device table etc. Don't worry. Rudolf, Stefan, or someone will try it out. :) Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] keyboard init patch
Stefan Reinauer wrote: Marc Jones wrote: This patch fixes the it8712f keyboard issues and should also fix any general keyboard init issues with other SIOs. Marc This patch fixes the dbm690t keyboard not working issue. It should also fix the a8n_e and any other it8712f SIO keyboard issues. The it8712f requires an archaic PS/2 mode setting to the keyboard controller before accessing the keyboard. Beyond that, I made the keyboard controller and keyboard init more robust and added more informative debug output. Signed-off-by: Marc Jones <[EMAIL PROTECTED]> Awesome! I was just today running into weird effects with the current code. Thanks for improving this. I think it makes sense to mention Ollie Lo by name (and maybe his email address ollielo at hotmail dot com rather than his old, non-working SiS address) Acked-by: Stefan Reinauer <[EMAIL PROTECTED]> Changed Ollie's copyright as indicated. r3610 Thanks, Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [pathc] K8 DIMM in channelB slot only
Patch attached
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
This patch for the AMD K8 allows a single DIMM to be populated in the
ChannelB slot. Previously a DIMM could only be populated in ChannelB
if there was a DIMM already in ChannelA. This patch doesn't allow unmatched
DIMMs to be populate in ChannelA and ChannelB. In an A & B configuration
the DIMM must still be matched.
Signed-off-by: Marc Jones <[EMAIL PROTECTED]>
Index: coreboot-v2/src/northbridge/amd/amdk8/amdk8_f.h
===
--- coreboot-v2.orig/src/northbridge/amd/amdk8/amdk8_f.h2008-09-26
13:30:56.0 -0600
+++ coreboot-v2/src/northbridge/amd/amdk8/amdk8_f.h 2008-09-26
13:36:22.0 -0600
@@ -481,8 +481,9 @@
uint8_t is_registered;
uint8_t is_ecc;
uint8_t is_Width128;
+ uint8_t is_64MuxMode;
uint8_t memclk_set; // we need to use this to retrieve the mem param
- uint8_t rsv[3];
+ uint8_t rsv[2];
} __attribute__((packed));
struct link_pair_st {
Index: coreboot-v2/src/northbridge/amd/amdk8/raminit_f.c
===
--- coreboot-v2.orig/src/northbridge/amd/amdk8/raminit_f.c 2008-09-26
13:30:56.0 -0600
+++ coreboot-v2/src/northbridge/amd/amdk8/raminit_f.c 2008-09-26
13:56:53.0 -0600
@@ -849,7 +849,7 @@
static void set_dimm_size(const struct mem_controller *ctrl,
-struct dimm_size *sz, unsigned index, int is_Width128)
+struct dimm_size *sz, unsigned index, struct mem_info
*meminfo)
{
uint32_t base0, base1;
@@ -872,7 +872,7 @@
}
/* Double the size if we are using dual channel memory */
- if (is_Width128) {
+ if (meminfo->is_Width128) {
base0 = (base0 << 1) | (base0 & 1);
base1 = (base1 << 1) | (base1 & 1);
}
@@ -881,15 +881,20 @@
base0 &= ~0xe007fffe;
base1 &= ~0xe007fffe;
- /* Set the appropriate DIMM base address register */
- pci_write_config32(ctrl->f2, DRAM_CSBASE + (((index << 1)+0)<<2),
base0);
- pci_write_config32(ctrl->f2, DRAM_CSBASE + (((index << 1)+1)<<2),
base1);
+ if (!(meminfo->dimm_mask & 0x0F) && (meminfo->dimm_mask & 0xF0)) { /*
channelB only? */
+ pci_write_config32(ctrl->f2, DRAM_CSBASE + (((index << 1) + 4)
<< 2), base0);
+ pci_write_config32(ctrl->f2, DRAM_CSBASE + (((index << 1) + 5)
<< 2), base1);
+ } else {
+ /* Set the appropriate DIMM base address register */
+ pci_write_config32(ctrl->f2, DRAM_CSBASE + (((index << 1) + 0)
<< 2), base0);
+ pci_write_config32(ctrl->f2, DRAM_CSBASE + (((index << 1) + 1)
<< 2), base1);
#if QRANK_DIMM_SUPPORT == 1
- if (sz->rank == 4) {
- pci_write_config32(ctrl->f2, DRAM_CSBASE + (((index <<
1)+4)<<2), base0);
- pci_write_config32(ctrl->f2, DRAM_CSBASE + (((index <<
1)+5)<<2), base1);
- }
+ if (sz->rank == 4) {
+ pci_write_config32(ctrl->f2, DRAM_CSBASE + (((index <<
1) + 4) << 2), base0);
+ pci_write_config32(ctrl->f2, DRAM_CSBASE + (((index <<
1) + 5) << 2), base1);
+ }
#endif
+ }
/* Enable the memory clocks for this DIMM by Clear the MemClkDis bit*/
if (base0) {
@@ -903,24 +908,31 @@
ClkDis0 = DTL_MemClkDis0_S1g1;
#endif
- dword = pci_read_config32(ctrl->f2, DRAM_TIMING_LOW); //Channel
A
- dword &= ~(ClkDis0 >> index);
-#if QRANK_DIMM_SUPPORT == 1
- if (sz->rank == 4) {
- dword &= ~(ClkDis0 >> (index+2));
- }
-#endif
- pci_write_config32(ctrl->f2, DRAM_TIMING_LOW, dword);
-
- if (is_Width128) { //Channel B
+ if (!(meminfo->dimm_mask & 0x0F) && (meminfo->dimm_mask &
0xF0)) { /* channelB only? */
dword = pci_read_config32(ctrl->f2, DRAM_CTRL_MISC);
dword &= ~(ClkDis0 >> index);
+ pci_write_config32(ctrl->f2, DRAM_CTRL_MISC, dword);
+
+ } else {
+ dword = pci_read_config32(ctrl->f2, DRAM_TIMING_LOW);
//Channel A
+ dword &= ~(ClkDis0 >> index);
#if QRANK_DIMM_SUPPORT == 1
if (sz->rank == 4) {
dword &= ~(ClkDis0 >> (index+2));
[coreboot] [buildrom][patch] filo platform config file fix
patch attached Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors FILO wasn't looking in the correct location for the platform config file. Signed-of-by: Marc Jones <[EMAIL PROTECTED]> Index: buildrom/packages/filo/filo.mk === --- buildrom.orig/packages/filo/filo.mk 2008-09-26 16:10:59.0 -0600 +++ buildrom/packages/filo/filo.mk 2008-09-26 15:49:00.0 -0600 @@ -19,7 +19,7 @@ FILO_TARBALL=filo-svn-$(FILO_TAG).tar.gz ifeq ($(shell if [ -f $(PACKAGE_DIR)/filo/conf/customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) ]; then echo 1; fi),1) - FILO_CONFIG = customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) + FILO_CONFIG = $(PACKAGE_DIR)/filo/conf/customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) else FILO_CONFIG = $(FILO_SRC_DIR)/configs/defconfig endif -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] keyboard init patch
Andriy Gapon wrote: on 26/09/2008 20:02 Marc Jones said the following: This patch fixes the it8712f keyboard issues and should also fix any general keyboard init issues with other SIOs. Marc Guys, you might find this useful: http://article.gmane.org/gmane.comp.emulators.bochs.devel/7843 It seems that this was included into bochs code. Maybe this is something that we would qemu to support as well. coreboot is a little better behaved than that. It only writes 0xCA/0xCB for specific SIOs(keyboard controllers). Since coreboot builds for qemu we don't need to make any changes. Thanks, Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [pathc] K8 DIMM in channelB slot only
Stefan Reinauer wrote: Marc Jones wrote: This patch for the AMD K8 allows a single DIMM to be populated in the ChannelB slot. Previously a DIMM could only be populated in ChannelB if there was a DIMM already in ChannelA. This patch doesn't allow unmatched DIMMs to be populate in ChannelA and ChannelB. In an A & B configuration the DIMM must still be matched. Signed-off-by: Marc Jones <[EMAIL PROTECTED]> Acked-by: Stefan Reinauer <[EMAIL PROTECTED]> r3614 Thanks, Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] r3614 build service
coreboot information wrote: Dear coreboot readers! This is the automated build check service of coreboot. The developer "mjones" checked in revision 3614 to the coreboot source repository and caused the following changes: Change Log: This patch for the AMD K8 allows a single DIMM to be populated in the ChannelB slot. Previously a DIMM could only be populated in ChannelB if there was a DIMM already in ChannelA. This patch doesn't allow unmatched DIMMs to be populate in ChannelA and ChannelB. In an A & B configuration the DIMM must still be matched. Signed-off-by: Marc Jones <[EMAIL PROTECTED]> Acked-by: Stefan Reinauer <[EMAIL PROTECTED]> Build Log: Compilation of amd:serengeti_cheetah has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3614&device=serengeti_cheetah&vendor=amd Compilation of asus:m2v-mx_se has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3614&device=m2v-mx_se&vendor=asus Compilation of jetway:j7f24 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3614&device=j7f24&vendor=jetway Compilation of msi:ms9185 has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3614&device=ms9185&vendor=msi Compilation of msi:ms9282 has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3614&device=ms9282&vendor=msi Compilation of supermicro:h8dmr is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3614&device=h8dmr&vendor=supermicro Compilation of via:epia-cn is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3614&device=epia-cn&vendor=via I'm investigating these new breakages. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [patch] K8 platforms should use PRINTK_IN_CAR
This fixes the four platforms that the recent K8 changes broke.
Thanks,
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
AMD K8 platforms must use CAR so it makes sense to use the PRINK_IN_CAR option.
This patch converts the following patches to use PRTINK_IN_CAR
amd/serngeti_cheetah
msi/ms9185
msi/ms9828
supermicro/h8dmr
Signed-off-by: Marc Jones <[EMAIL PROTECTED]>
Index: coreboot-v2/src/mainboard/amd/serengeti_cheetah/Options.lb
===
--- coreboot-v2.orig/src/mainboard/amd/serengeti_cheetah/Options.lb
2008-09-29 16:05:06.0 -0600
+++ coreboot-v2/src/mainboard/amd/serengeti_cheetah/Options.lb 2008-09-29
15:07:22.0 -0600
@@ -286,7 +286,7 @@
##
## The Serial Console
##
-default CONFIG_USE_PRINTK_IN_CAR=0
+default CONFIG_USE_PRINTK_IN_CAR=1
# To Enable the Serial Console
default CONFIG_CONSOLE_SERIAL8250=1
Index: coreboot-v2/src/mainboard/amd/serengeti_cheetah/cache_as_ram_auto.c
===
--- coreboot-v2.orig/src/mainboard/amd/serengeti_cheetah/cache_as_ram_auto.c
2008-09-29 16:09:17.0 -0600
+++ coreboot-v2/src/mainboard/amd/serengeti_cheetah/cache_as_ram_auto.c
2008-09-29 15:15:47.0 -0600
@@ -33,6 +33,7 @@
#include "option_table.h"
#include "pc80/mc146818rtc_early.c"
+
#if 0
static void post_code(uint8_t value) {
#if 1
@@ -64,11 +65,6 @@
#if CONFIG_USE_INIT == 0
#include "lib/memcpy.c"
- #if CONFIG_USE_PRINTK_IN_CAR == 1
- #include "lib/uart8250.c"
- #include "console/vtxprintf.c"
- #include "arch/i386/lib/printk_init.c"
- #endif
#endif
#include "northbridge/amd/amdk8/debug.c"
#include "cpu/amd/mtrr/amd_earlymtrr.c"
Index: coreboot-v2/src/mainboard/amd/serengeti_cheetah/apc_auto.c
===
--- coreboot-v2.orig/src/mainboard/amd/serengeti_cheetah/apc_auto.c
2008-09-29 16:17:07.0 -0600
+++ coreboot-v2/src/mainboard/amd/serengeti_cheetah/apc_auto.c 2008-09-29
15:16:43.0 -0600
@@ -24,11 +24,6 @@
#if CONFIG_USE_INIT == 0
#include "lib/memcpy.c"
- #if CONFIG_USE_PRINTK_IN_CAR == 1
- #include "lib/uart8250.c"
- #include "console/vtxprintf.c"
- #include "arch/i386/lib/printk_init.c"
- #endif
#endif
#include "arch/i386/lib/console.c"
Index: coreboot-v2/src/mainboard/msi/ms9185/Options.lb
===
--- coreboot-v2.orig/src/mainboard/msi/ms9185/Options.lb2008-09-29
16:18:48.0 -0600
+++ coreboot-v2/src/mainboard/msi/ms9185/Options.lb 2008-09-29
15:21:44.0 -0600
@@ -104,7 +104,7 @@
uses CONFIG_PCI_64BIT_PREF_MEM
uses CONFIG_LB_MEM_TOPK
-
+uses CONFIG_USE_PRINTK_IN_CAR
###
### Build options
@@ -222,7 +222,7 @@
default DCACHE_RAM_BASE=0xcc000
default DCACHE_RAM_SIZE=0x04000
default DCACHE_RAM_GLOBAL_VAR_SIZE=0x01000
-default CONFIG_USE_INIT=0
+default CONFIG_USE_INIT=0
##
## Build code to setup a generic IOAPIC
@@ -287,6 +287,7 @@
##
## The Serial Console
##
+default CONFIG_USE_PRINTK_IN_CAR=1
# To Enable the Serial Console
default CONFIG_CONSOLE_SERIAL8250=1
Index: coreboot-v2/src/mainboard/msi/ms9282/Options.lb
===
--- coreboot-v2.orig/src/mainboard/msi/ms9282/Options.lb2008-09-29
16:28:46.0 -0600
+++ coreboot-v2/src/mainboard/msi/ms9282/Options.lb 2008-09-29
15:22:01.0 -0600
@@ -100,6 +100,7 @@
uses CONFIG_COMPRESSED_PAYLOAD_LZMA
uses CONFIG_COMPRESSED_PAYLOAD_NRV2B
uses CONFIG_PRECOMPRESSED_PAYLOAD
+uses CONFIG_USE_PRINTK_IN_CAR
## ROM_SIZE is the size of boot ROM that this board will use.
#512K bytes
@@ -203,7 +204,6 @@
default APIC_ID_OFFSET=0x10
default LIFT_BSP_APIC_ID=0
-
##
## Build code to setup a generic IOAPIC
##
@@ -267,7 +267,8 @@
##
## The Serial Console
##
-
+default CONFIG_USE_PRINTK_IN_CAR=1
+
# To Enable the Serial Console
default CONFIG_CONSOLE_SERIAL8250=1
Index: coreboot-v2/src/mainboard/supermicro/h8dmr/Options.lb
===
--- coreboot-v2.orig/src/mainboard/supermicro/h8dmr/Options.lb 2008-09-29
16:35:16.0 -0600
+++ coreboot-v2/src/mainboard/supermicro/h8dmr/Options.lb 2008-09-29
15:21:14.0 -0600
@@ -236,7 +236,7 @@
default DCACHE_RAM_GLOBAL_VAR_SIZE=0x01000
default CONFIG_USE_INIT=0
-default CONFIG_AP_CODE_IN_CAR=0
+default CONFIG_AP_CODE_IN_CAR=1
default MEM_TRAIN_SEQ=1
default WAIT_BEFORE_CPUS_INIT=1
@@ -305,7 +305,7 @@
##
## The Serial Console
##
-default CONFIG_USE_PRINTK_IN_CAR=0
+default CONFIG_USE_PRINTK_IN_C
[coreboot] [patch] abuild no_stack_protect
This fixes those of us that us the Ubuntu toolchain. Thanks, Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors Add a command line option for -fno-stack-protect for toolchains that might require it. Signed-off-by: Marc Jones <[EMAIL PROTECTED]> Index: coreboot-v2/util/abuild/abuild === --- coreboot-v2.orig/util/abuild/abuild 2008-09-29 16:02:53.0 -0600 +++ coreboot-v2/util/abuild/abuild 2008-09-29 16:03:27.0 -0600 @@ -43,6 +43,9 @@ # this is disabled per default but can be enabled with -s silent= +# stackprotect mode enabled by -ns option. +stackprotect=false + ARCH=`uname -m | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ \ -e s/arm.*/arm/ -e s/sa110/arm/ -e s/x86_64/amd64/ \ -e "s/Power Macintosh/ppc/"` @@ -322,8 +325,13 @@ CC='$(CROSS_COMPILE)gcc' CROSS_COMPILE='' fi - HOSTCC='gcc' + + if [ "$stackprotect" = "true" ]; then + CC="$CC -fno-stack-protector" + fi + HOSTCC='gcc' + printf "Processing mainboard/$VENDOR/$MAINBOARD" xml "" @@ -470,6 +478,8 @@ printf "[-s|--silent] omit compiler calls in logs\n" printf "[lbroot] absolute path to coreboot sources\n" printf " (defaults to $LBROOT)\n\n" + printf "[-ns|--nostackprotect]use gcc -fno-stack-protector +option\n" } function myversion @@ -524,6 +534,7 @@ -T|--test) shift; hwtest=true;; -c|--cpus) shift; cpus="$1"; test "$cpus" == "max" && cpus=""; shift;; -s|--silent)shift; silent="-s";; + -ns|--nostackprotect) shift; stackprotect=true;; --) shift; break;; -*) printf "Invalid option\n\n"; myhelp; exit 1;; *) break;; -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [patch] K8 platforms should use PRINTK_IN_CAR
ron minnich wrote:
Acked-by: Ronald G. Minnich <[EMAIL PROTECTED]>
r3617
Thanks,
Marc
On Mon, Sep 29, 2008 at 3:48 PM, Marc Jones <[EMAIL PROTECTED]> wrote:
This fixes the four platforms that the recent K8 changes broke.
Thanks,
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
AMD K8 platforms must use CAR so it makes sense to use the PRINK_IN_CAR
option.
This patch converts the following patches to use PRTINK_IN_CAR
amd/serngeti_cheetah
msi/ms9185
msi/ms9828
supermicro/h8dmr
Signed-off-by: Marc Jones <[EMAIL PROTECTED]>
Index: coreboot-v2/src/mainboard/amd/serengeti_cheetah/Options.lb
===
--- coreboot-v2.orig/src/mainboard/amd/serengeti_cheetah/Options.lb
2008-09-29 16:05:06.0 -0600
+++ coreboot-v2/src/mainboard/amd/serengeti_cheetah/Options.lb 2008-09-29
15:07:22.0 -0600
@@ -286,7 +286,7 @@
##
## The Serial Console
##
-default CONFIG_USE_PRINTK_IN_CAR=0
+default CONFIG_USE_PRINTK_IN_CAR=1
# To Enable the Serial Console
default CONFIG_CONSOLE_SERIAL8250=1
Index: coreboot-v2/src/mainboard/amd/serengeti_cheetah/cache_as_ram_auto.c
===
--- coreboot-v2.orig/src/mainboard/amd/serengeti_cheetah/cache_as_ram_auto.c
2008-09-29 16:09:17.0 -0600
+++ coreboot-v2/src/mainboard/amd/serengeti_cheetah/cache_as_ram_auto.c
2008-09-29 15:15:47.0 -0600
@@ -33,6 +33,7 @@
#include "option_table.h"
#include "pc80/mc146818rtc_early.c"
+
#if 0
static void post_code(uint8_t value) {
#if 1
@@ -64,11 +65,6 @@
#if CONFIG_USE_INIT == 0
#include "lib/memcpy.c"
- #if CONFIG_USE_PRINTK_IN_CAR == 1
- #include "lib/uart8250.c"
- #include "console/vtxprintf.c"
- #include "arch/i386/lib/printk_init.c"
- #endif
#endif
#include "northbridge/amd/amdk8/debug.c"
#include "cpu/amd/mtrr/amd_earlymtrr.c"
Index: coreboot-v2/src/mainboard/amd/serengeti_cheetah/apc_auto.c
===
--- coreboot-v2.orig/src/mainboard/amd/serengeti_cheetah/apc_auto.c
2008-09-29 16:17:07.0 -0600
+++ coreboot-v2/src/mainboard/amd/serengeti_cheetah/apc_auto.c 2008-09-29
15:16:43.0 -0600
@@ -24,11 +24,6 @@
#if CONFIG_USE_INIT == 0
#include "lib/memcpy.c"
- #if CONFIG_USE_PRINTK_IN_CAR == 1
- #include "lib/uart8250.c"
- #include "console/vtxprintf.c"
- #include "arch/i386/lib/printk_init.c"
- #endif
#endif
#include "arch/i386/lib/console.c"
Index: coreboot-v2/src/mainboard/msi/ms9185/Options.lb
===
--- coreboot-v2.orig/src/mainboard/msi/ms9185/Options.lb2008-09-29
16:18:48.0 -0600
+++ coreboot-v2/src/mainboard/msi/ms9185/Options.lb 2008-09-29
15:21:44.0 -0600
@@ -104,7 +104,7 @@
uses CONFIG_PCI_64BIT_PREF_MEM
uses CONFIG_LB_MEM_TOPK
-
+uses CONFIG_USE_PRINTK_IN_CAR
###
### Build options
@@ -222,7 +222,7 @@
default DCACHE_RAM_BASE=0xcc000
default DCACHE_RAM_SIZE=0x04000
default DCACHE_RAM_GLOBAL_VAR_SIZE=0x01000
-default CONFIG_USE_INIT=0
+default CONFIG_USE_INIT=0
##
## Build code to setup a generic IOAPIC
@@ -287,6 +287,7 @@
##
## The Serial Console
##
+default CONFIG_USE_PRINTK_IN_CAR=1
# To Enable the Serial Console
default CONFIG_CONSOLE_SERIAL8250=1
Index: coreboot-v2/src/mainboard/msi/ms9282/Options.lb
===
--- coreboot-v2.orig/src/mainboard/msi/ms9282/Options.lb2008-09-29
16:28:46.0 -0600
+++ coreboot-v2/src/mainboard/msi/ms9282/Options.lb 2008-09-29
15:22:01.0 -0600
@@ -100,6 +100,7 @@
uses CONFIG_COMPRESSED_PAYLOAD_LZMA
uses CONFIG_COMPRESSED_PAYLOAD_NRV2B
uses CONFIG_PRECOMPRESSED_PAYLOAD
+uses CONFIG_USE_PRINTK_IN_CAR
## ROM_SIZE is the size of boot ROM that this board will use.
#512K bytes
@@ -203,7 +204,6 @@
default APIC_ID_OFFSET=0x10
default LIFT_BSP_APIC_ID=0
-
##
## Build code to setup a generic IOAPIC
##
@@ -267,7 +267,8 @@
##
## The Serial Console
##
-
+default CONFIG_USE_PRINTK_IN_CAR=1
+
# To Enable the Serial Console
default CONFIG_CONSOLE_SERIAL8250=1
Index: coreboot-v2/src/mainboard/supermicro/h8dmr/Options.lb
===
--- coreboot-v2.orig/src/mainboard/supermicro/h8dmr/Options.lb 2008-09-29
16:35:16.0 -0600
+++ coreboot-v2/src/mainboard/supermicro/h8dmr/Options.lb 2008-09-29
15:21:14.0 -0600
@@ -236,7 +236,7 @@
default DCACHE_RAM_GLOBAL_VAR_SIZE=0x01000
default CONFIG_USE_INIT=0
-default CONFIG_AP_CODE_IN_CAR=0
+default CONFIG_AP_CODE_IN_CAR=1
default MEM_TRAIN_SEQ=1
default WAIT_BEFORE_CPUS_INIT=1
Re: [coreboot] [v2][patch] update k8 fid/vid setup
Peter Stuge wrote: Marc Jones wrote: Update K8 FID/VID setup. Add support for 100MHz FIDs (revG). Signed-off-by: Marc Jones <[EMAIL PROTECTED]> Looks good. Acked-by: Peter Stuge <[EMAIL PROTECTED]> Thanks Peter, I was going to repost this with some changes. I think that there is a corner case I didn't correctly account for. :) Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Fam10h support for Tyan S2912-E (1/2)
Peter Stuge wrote: Arne Georg Gleditsch wrote: Create new tyan/s2912_fam10 target as verbatim copy of tyan/s2912. Why? Isn't it better to only have one target that supports both CPU types? The target has different build and cpu init requirements. We want to work towards a combined ROM that supports both CPUs but that doesn't exist yet. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [patch] abuild no_stack_protect
Stefan Reinauer wrote: Marc Jones wrote: This fixes those of us that us the Ubuntu toolchain. Add a command line option for -fno-stack-protect for toolchains that might require it. Signed-off-by: Marc Jones <[EMAIL PROTECTED]> Acked-by: Stefan Reinauer <[EMAIL PROTECTED]> r3623 Thanks, Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH v2] AMD DBM690T IRQ cleanup
Carl-Daniel Hailfinger wrote: Hi, I decided to prepare a patch for the stuff I mentioned in the DBM690T review. Use easily readable macros to setup interrupt routing. Change a few PCI bus/dev/fn to use hexadecimal numbers. Signed-off-by: Carl-Daniel Hailfinger <[EMAIL PROTECTED]> The cleanup is nice but you didn't translate correctly. See below. Index: LinuxBIOSv2-irq_macros/src/mainboard/amd/dbm690t/mptable.c === --- LinuxBIOSv2-irq_macros/src/mainboard/amd/dbm690t/mptable.c (Revision 3624) +++ LinuxBIOSv2-irq_macros/src/mainboard/amd/dbm690t/mptable.c (Arbeitskopie) @@ -122,94 +122,72 @@ smp_write_intsrc(mc, mp_ExtINT, MP_IRQ_TRIGGER_EDGE | MP_IRQ_POLARITY_HIGH, bus_isa, 0x0, apicid_sb600, 0x0); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE | MP_IRQ_POLARITY_HIGH, -bus_isa, 0x1, apicid_sb600, 0x1); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE | MP_IRQ_POLARITY_HIGH, -bus_isa, 0x0, apicid_sb600, 0x2); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE | MP_IRQ_POLARITY_HIGH, -bus_isa, 0x3, apicid_sb600, 0x3); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE | MP_IRQ_POLARITY_HIGH, -bus_isa, 0x4, apicid_sb600, 0x4); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE | MP_IRQ_POLARITY_HIGH, -bus_isa, 0x6, apicid_sb600, 0x6); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE | MP_IRQ_POLARITY_HIGH, -bus_isa, 0x7, apicid_sb600, 0x7); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE | MP_IRQ_POLARITY_HIGH, -bus_isa, 0xc, apicid_sb600, 0xc); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE | MP_IRQ_POLARITY_HIGH, -bus_isa, 0xd, apicid_sb600, 0xd); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE | MP_IRQ_POLARITY_HIGH, -bus_isa, 0xe, apicid_sb600, 0xe); + /* ISA ints are edge-triggered, and usually originate from the ISA bus, +* or its remainings. +*/ +#define ISA_INT(intr, pin) \ + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, bus_isa, (intr), apicid_sb600, (pin)) + + ISA_INT(0x1, 0x1); + ISA_INT(0x0, 0x2); + ISA_INT(0x3, 0x3); + ISA_INT(0x4, 0x4); + ISA_INT(0x6, 0x6); + ISA_INT(0x7, 0x7); + ISA_INT(0xc, 0xc); + ISA_INT(0xd, 0xd); + ISA_INT(0xe, 0xe); + + /* PCI interrupts are level triggered, and are +* associated with a specific bus/device/function tuple. +*/ +#define PCI_INT(bus, dev, fn, pin) \ +smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, (bus), (((dev)<<2)|(fn)), apicid_sb600, (pin)) + /* usb */ - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL | MP_IRQ_POLARITY_LOW, -0, 19 << 2 | 0, apicid_sb600, 0x10); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL | MP_IRQ_POLARITY_LOW, -0, 19 << 2 | 1, apicid_sb600, 0x11); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL | MP_IRQ_POLARITY_LOW, -0, 19 << 2 | 2, apicid_sb600, 0x12); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL | MP_IRQ_POLARITY_LOW, -0, 19 << 2 | 3, apicid_sb600, 0x13); + PCI_INT(0, 0x13, 2, 0); + PCI_INT(0, 0x13, 2, 1); + PCI_INT(0, 0x13, 2, 2); + PCI_INT(0, 0x13, 2, 3); This should be: PCI_INT(0, 0x13, 0, 0x10); PCI_INT(0, 0x13, 1, 0x11); PCI_INT(0, 0x13, 2, 0x12); PCI_INT(0, 0x13, 3, 0x13); I think you put the << 2 in the fn throughout the patch. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [v2][patch] update k8 fid/vid setup
Marc Jones wrote:
Peter Stuge wrote:
Marc Jones wrote:
Update K8 FID/VID setup. Add support for 100MHz FIDs (revG).
Signed-off-by: Marc Jones <[EMAIL PROTECTED]>
Looks good.
Acked-by: Peter Stuge <[EMAIL PROTECTED]>
Thanks Peter, I was going to repost this with some changes. I think that
there is a corner case I didn't correctly account for. :)
Resubmitting this patch. I think I worked out all the corner cases and
made it a little easier to understand.
Thanks,
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
Update K8 FID/VID setup. Add support for 100MHz FIDs (revG).
Signed-off-by: Marc Jones <[EMAIL PROTECTED]>
Index: coreboot-v2/src/cpu/amd/model_fxx/fidvid.c
===
--- coreboot-v2.orig/src/cpu/amd/model_fxx/fidvid.c 2008-09-19
09:34:26.0 -0600
+++ coreboot-v2/src/cpu/amd/model_fxx/fidvid.c 2008-10-01 13:53:22.0
-0600
@@ -97,29 +97,36 @@
}
#endif
-static unsigned set_fidvid(unsigned apicid, unsigned fidvid, int showmessage)
+static u32 set_fidvid(unsigned apicid, unsigned fidvid, int showmessage)
{
- /* for (cur, new) there is one <1600MHz x8 to find out next_fid */
- static const uint8_t next_fid_a[] = {
- /* x4 x5 x6 x7 x8 x9 x10 x11 x12 x13 x14 x15 */
-/* x4 */0, 9, 9, 8, 9, 9, 9, 9, 9, 9, 9, 9,
-/* x5 */9, 0, 11, 11, 9, 9, 10, 11, 11, 11, 11, 11,
-/* x6 */ 11, 11, 0, 13, 11, 11, 11, 11, 12, 13, 13, 13,
-/* x7 */ 13, 13, 13, 0, 13, 13, 13, 13, 13, 13, 14, 15,
-/* x8 */4, 9, 9, 9, 0, 9, 9, 9, 9, 9, 9, 9,
-/* x9 */4, 5, 10, 10, 8, 0, 0, 0, 0, 0, 0, 0,
-/*x10 */9, 5, 11, 11, 9, 0, 0, 0, 0, 0, 0, 0,
-/*x11 */ 10, 5, 6, 12, 10, 0, 0, 0, 0, 0, 0, 0,
-/*x12 */ 11, 11, 6, 13, 11, 0, 0, 0, 0, 0, 0, 0,
-/*x13 */ 12, 12, 6, 7, 12, 0, 0, 0, 0, 0, 0, 0,
-/*x14 */ 13, 13, 13, 7, 13, 0, 0, 0, 0, 0, 0, 0,
-/*x15 */ 14, 14, 14, 7, 14, 0, 0, 0, 0, 0, 0, 0,
-/* 0:x4, 2:x5BASE=4, MIN=4, MAX=25, INC=2 result = (xX-BASE)*INC */
+
+/* CurrentFID--> 4x(00h) 5x(02h) 6x(04h) 7x(06h) ...
+ * --
+ * TargetFID | Next_FID, Next_FID, Next_FID, Next_FID ...
+ * | | Next_FID, Next_FID, Next_FID, Next_FID ...
+ * \|/ | Next_FID, Next_FID, Next_FID, Next_FID ...
+ */
+ static const u8 next_fid_200[] = {
+/* x4 x5 x6 x7 x8 x9 x10 x11 x12 x13 x14 x15 x16 */
+/* x4 */0, -1, -1, -1, 0, 0, 9, 10, 11, 12, 13, 14, 15, /* 800 */
+/* x5 */ -1, 0, -1, -1, -1, 5, 5, 5, 11, 12, 13, 14, 15, /* 1000 */
+/* x6 */ -1, -1, 0, -1, -1, -1, -1, 6, 6, 6, 13, 14, 15, /* 1200 */
+/* x7 */ -1, -1, -1, 0, -1, -1, -1, -1, -1, 7, 7, 7, 15, /* 1400 */
+/* lower table to upper table boarder (table 70 and 71 in BKDG) */
+/* x8 */8, -1, -1, -1, 0, 8, 9, 10, 11, 12, 13, 14, 15, /* 1600 */
+/* x9 */9, 9, -1, -1, 9, 0, 9, 10, 11, 12, 13, 14, 15, /* 1800 */
+/*x10 */9, 10, -1, -1, 9, 10, 0, 10, 11, 12, 13, 14, 15, /* 2000 */
+/*x11 */9, 11, 11, -1, 9, 10, 11, 0, 11, 12, 13, 14, 15, /* 2200 */
+/*x12 */9, 11, 12, -1, 9, 10, 11, 12, 0, 12, 13, 14, 15, /* 2400 */
+/*x13 */9, 11, 13, 13, 9, 10, 11, 12, 13, 0, 13, 14, 15, /* 2600 */
+/*x14 */9, 11, 13, 14, 9, 10, 11, 12, 13, 14, 0, 14, 15, /* 2800 */
+/*x15 */9, 11, 13, 15, 9, 10, 11, 12, 13, 14, 15, 0, 15, /* 3000 */
+/*x15 */9, 11, 13, 15, 9, 10, 11, 12, 13, 14, 15, 16, 0, /* 3200 */
};
msr_t msr;
- uint32_t vid;
- uint32_t fid;
+ uint32_t vid_new;
+ uint32_t fid_new;
uint32_t vid_max;
uint32_t fid_max;
uint32_t vid_cur;
@@ -140,21 +147,22 @@
return fidvid;
}
- fid = (fidvid >> 8) & 0x3f;
- vid = (fidvid >> 16) & 0x3f;
+ fid_new = (fidvid >> 8) & 0x3f;
+ vid_new = (fidvid >> 16) & 0x3f;
msr = rdmsr(0xc0010042);
vid_cur = msr.hi & 0x3f;
fid_cur = msr.lo & 0x3f;
- if ((vid_cur==vid) && (fid_cur==fid))
+ if ((vid_cur == vid_new) && (fid_cur == fid_new))
return fidvid;
- vid_max = (msr.hi>>(48-32)) & 0x3f;
- fid_max = ((msr.lo>>16) & 0x3f); /* max fid */
+ vid_max = (msr.hi >> (48-32)) & 0x3f;
+ fid_max = ((msr.lo >> 16) & 0x3f); /* max fid */
+
#if FX_SUPPORT
- if (fid_max>=((25-4)*2)) { /* FX max fid is 5G */
+ if (fid_max >= ((25 - 4) * 2)) { /* FX max fid is 5G */
fid_max = ((msr.lo >> 8) & 0x3f) + 5 * 2; /* max FID is min fid
+ 1G */
if (fid_max >= ((25-4) * 2)) {
fid_max = (10-4) * 2; /*
Re: [coreboot] [PATCH] Fix ITE IT8712F pnp_dev_info[] items
Uwe Hermann wrote:
See patch. The pnp_dev_info[] was incomplete and partly wrong, due to
me doing blind copy-paste. After checking with the datasheet I _think_
the contents are correct now, but it would be nice if someone could
double-check that.
Various other superios have the same problem I'm afraid, I'll post more
patches later...
For parallel port there are _two_ base addresses (0x60/0x61 and 0x62/0x63),
but most other superios/boards only use the first one (I assume the
second set is only needed for some non-standard parallel port modes?)
Yeah, that is interesting since there is only one IRQ. I have never seen
a second lpt port used. I would ignore it.
Also, I left IT8712F_GPIO "empty" like this
{&ops, IT8712F_GPIO, },
even though it does have 0x60/0x61, 0x62/0x63, and 0x64/0x65 base address
registers, but those are "SMI# Normal Run Access Base Address" and
"Simple I/O Base Address" and "Panel Button De-bounce Base Address",
which I guess we don't need (?)
You could put it in for completeness but I doubt it will ever get used.
Why did the io_info.mask change from 0x7f8 to 0xfff8/c/f? That just
changes the granularity of of the resource? It is not a mask on the
address. Also, what is io_info.set supposed to do? I didn't find any
reference to it in the code. Why is it sometimes set to 0x4? It would be
nice if io_info was documented a little.
The IO/IRQ/DRQ flags for each device look correct.
Explain the io_info.mask then
Acked-by: Marc Jones <[EMAIL PROTECTED]>
Thanks,
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Fix ITE IT8712F pnp_dev_info[] items
Uwe Hermann wrote:
On Thu, Oct 02, 2008 at 02:46:35PM -0600, Marc Jones wrote:
Uwe Hermann wrote:
See patch. The pnp_dev_info[] was incomplete and partly wrong, due to
me doing blind copy-paste. After checking with the datasheet I _think_
the contents are correct now, but it would be nice if someone could
double-check that.
Various other superios have the same problem I'm afraid, I'll post more
patches later...
For parallel port there are _two_ base addresses (0x60/0x61 and 0x62/0x63),
but most other superios/boards only use the first one (I assume the
second set is only needed for some non-standard parallel port modes?)
Yeah, that is interesting since there is only one IRQ. I have never seen
a second lpt port used. I would ignore it.
OK.
Also, I left IT8712F_GPIO "empty" like this
{&ops, IT8712F_GPIO, },
even though it does have 0x60/0x61, 0x62/0x63, and 0x64/0x65 base address
registers, but those are "SMI# Normal Run Access Base Address" and
"Simple I/O Base Address" and "Panel Button De-bounce Base Address",
which I guess we don't need (?)
You could put it in for completeness but I doubt it will ever get used.
Yep, ok.
Why did the io_info.mask change from 0x7f8 to 0xfff8/c/f? That just
changes the granularity of of the resource? It is not a mask on the
address.
This is my biggest concern, I'm really not sure what values to put here.
My assumption was that those values are indeed bitmasks, specifying
which bits of the 0x60/0x61 registers shall be used for the I/O address.
For example: The IT8712F datasheet says for serial port 1:
8.5.2 Serial Port 1 Base Address MSB Register (Index=60h, Default=03h)
BitDescription
7-4Read only as "0h" for Base Address[15:12].
3-0Read/write, mapped as Base Address[11:8].
8.5.3 Serial Port 1 Base Address LSB Register (Index=61h, Default=F8h)
BitDescription
7-3Read/write, mapped as Base Address[7:3].
2-0Read only as "000b."
So bits 11..3 consitute the base address, the rest (15..12 and 2..0 are
zero and unused).
I used this information, the bitmask 0b1000, as the io_info.mask
values for the serial port (that's 0xff8 if converted to hex).
I see, I think that you are correct. The reserved bits indicate the
granularity which is then used in the resource allocation (size, limit,
granularity, and alignment. pnp_get_ioresource() is the function if you
care to look at it.
Acked-by: Marc Jones <[EMAIL PROTECTED]>
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] dbm690t initial attempt which fails; not signed off
ron minnich wrote:
I could use some help here; what am I doing wrong? attached.
ron
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
+/* this code is very mainboard dependent, sadly. */
+/**
+ * call the amd 8111 memreset_setup_amd8111 function to jam the GPIOs to reset memory.
+ */
+static void memreset_setup(void)
+{
+}
fix comment?
static const u16 spd_addr[] = {
+ //first node
+ RC0 | DIMM0, RC0 | DIMM2, 0, 0,
+ RC0 | DIMM1, RC0 | DIMM3, 0, 0,
+#if CONFIG_MAX_PHYSICAL_CPUS > 1
+ //second node
+ RC1 | DIMM0, RC1 | DIMM2, RC1 | DIMM4, RC1 | DIMM6,
+ RC1 | DIMM1, RC1 | DIMM3, RC1 | DIMM5, RC1 | DIMM7,
+#endif
+#if CONFIG_MAX_PHYSICAL_CPUS > 2
+ // third node
+ RC2 | DIMM0, RC2 | DIMM2, 0, 0,
+ RC2 | DIMM1, RC2 | DIMM3, 0, 0,
+ // four node
+ RC3 | DIMM0, RC3 | DIMM2, RC3 | DIMM4, RC3 | DIMM6,
+ RC3 | DIMM1, RC3 | DIMM3, RC3 | DIMM5, RC3 | DIMM7,
+#endif
+
This can be cleaned up for the dbm690. There are only 2 dimms and one
physical CPU.
+#if 0
+ //it your CPU min fid is 1G, you can change HT to 1G and FID to max one
time.
+ needs_reset = optimize_link_coherent_ht();
+ needs_reset |= optimize_link_incoherent_ht(sysinfo);
+#endif
remove this?, it is already in the code below.
static const struct rmap register_values[]
This is large and should be in a .h since it has been moved out of
resourcemap.c?
+void hardware_stage1(void)
+{
+/*
+ void enumerate_ht_chain(void);
+ int max;
+ printk(BIOS_ERR, "Stage1: enable rom ...\n");
+ max = ARRAY_SIZE(register_values);
+ setup_resource_map(register_values, max);
I don't understand setting up the resource map before memory is inited.
All memory and IO should be going to the subtractive port (southbridge).
+ mainboard_name = "Serengeti";
:)
Index: mainboard/amd/dbm690t/cmos.layout
It would be nice if cmos was handled better than the same layout file in
every mainboard. It should be fairly easy to make this better and v3 is
the place to do it.
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] r3630 build service
Ron and Carl-Daniel, How are we fixing this? v2 is broken right now. Marc Carl-Daniel Hailfinger wrote: Hi Ron, you accidentially committed the SB600 v3 stuff into the v2 tree. Do you want to revert or should I take care of that? Regards, Carl-Daniel On 02.10.2008 18:21, coreboot information wrote: The developer "rminnich" checked in revision 3630 to the coreboot source repository and caused the following changes: Change Log: This is so that people can see it. This is the sb600 for v3. It almost certainly won't build -- that comes later. I am hoping to get some eyeballs on it for simple errors. rs690 is next. Signed-off-by: Ronald G. Minnich <[EMAIL PROTECTED]> Acked-by: Ronald G. Minnich <[EMAIL PROTECTED]> Build Log: Compilation of amd:dbm690t has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3630&device=dbm690t&vendor=am -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] r3630 build service
ron minnich wrote: On Fri, Oct 3, 2008 at 3:41 PM, Marc Jones <[EMAIL PROTECTED]> wrote: Ron and Carl-Daniel, How are we fixing this? v2 is broken right now. do you want to pick up my mess? I don't trust myself at present. ron Ok, I'm working on it. I should have it fixed up soon Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] r3630 build service
Carl-Daniel Hailfinger wrote: On 04.10.2008 00:46, ron minnich wrote: On Fri, Oct 3, 2008 at 3:41 PM, Marc Jones <[EMAIL PROTECTED]> wrote: Ron and Carl-Daniel, How are we fixing this? v2 is broken right now. do you want to pick up my mess? I don't trust myself at present. I'd gladly leave that task to someone with better svn skills than mine. Doing a revert in a way that sort of undoes history is rather difficult. I believe you can do it by telling svn to copy from the old pre-change revision of the file. Regards, Carl-Daniel I wasn't going to undo the history. I am not that skilled. I was just going commit on top of that change. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] r3630 build service
ron minnich wrote: On Fri, Oct 3, 2008 at 3:57 PM, Marc Jones <[EMAIL PROTECTED]> wrote: I wasn't going to undo the history. I am not that skilled. I was just going commit on top of that change. commit over the change with the comment "Ron owes me big time" I expect beer next time I see you ;) r3636 Thanks, Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SeaBIOS and the Geode LX framebuffer
Jordan Crouse wrote: On 06/10/08 16:55 +0100, Stephen Crocker wrote: I was under the impression that the Geode display hardware does not provide the standard I/O ports and memory areas exposed by standard VGA hardware (eg. ports 3d4/3d5 and segment A000) and that this was all emulated in the VSA using SMIs. Am I incorrect about this? Oh, I see what you mean - I thought you meant you have no access to the GPU outside of VSA/VGA. Yes, I believe that is correct for VGA users. The released VSA source only supports the PCI header emulation. A native driver is expected to do all the graphics work. > When I attempted to build an image, it defaulted to the CS5530. I did > wonder about fudging the header to use the CS5536 device ID but I also > noticed that the size of my image came to 60,466 bytes whereas the > standard binary image is 57,504 bytes. This would imply a significant > difference in either the source tree, my build environment or both. > I don't understand that it defaulted to 5530. In sysmgr\sysmgr.h SUPPORT_CS5536 is the targeted chipset. It has been a long time, but SUPPORT_CS5535 should also work. I don't know if SUPPORT_CS5530 would work. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] v3 updates
ron minnich wrote: On Mon, Oct 6, 2008 at 11:59 AM, Myles Watson <[EMAIL PROTECTED]> wrote: Could you help me understand how we get from this picture from the 8111 data sheet to the serengeti dts? It looks like to me that the nic and ide portions should be included in the amd8111 dts, not the board dts. I'm also confused why the ide and nic entries seem to be on the same bus. nic and ide are in mainboard dts so we can set control variables. v3 is like v2 in that dts topology reflects mainboard topology but does also show some detailsof chipset topology. nic and ide on same bus? That's my mistake, pure and simple. The mainboard dts is wrong. We're in the learning phase here on dts for boards like this. We understand simple boards like geode boards. This is our first complex hierarchy board. Yes, the mainboard dts is where you want to control this. On many platforms the on silicon devices may not be used and disabled. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SeaBIOS and the Geode LX framebuffer
Stephen Crocker wrote: Marc Jones wrote: I don't understand that it defaulted to 5530. In sysmgr\sysmgr.h SUPPORT_CS5536 is the targeted chipset. It has been a long time, but SUPPORT_CS5535 should also work. I don't know if SUPPORT_CS5530 would work. If you look at the link that I posted, you will see why. Here is the section of sysmgr.asm in question: Start: ; NOTE: The VSA II installer patches a "JMP SysMgr_Entry" over the signature field ddVSM_SIGNATURE; VSM signature dbVSM_SYS_MGR; VSM type db0FFh; Any CPU if SUPPORT_CS5535 dwDEVICE_ID_5535; VSA for CS5535 else dwDEVICE_ID_5530; VSA for CS5530 endif dwVSA_VERSION; System Manager version ddOFFSET edata; Size of System Manager dwOFFSET SysMgr_Entry; EntryPoint ddOFFSET _end; DS Limit dw0007h; Requirements: 4096-byte boundary dwVSA_VERSION; VSA version As you can see, if SUPPORT_CS5535 is not defined, it will use DEVICE_ID_5530. Furthermore, it would appear that there is no way for the field to be DEVICE_ID_5536 without modifying the source code. Admittedly, this is a trivial patch but it strikes me as odd that such an action is required. That is why I was wondering whether a newer version of the source was available. Ah, This is an oversite on our part. I don't think that anyone uses that field in the signature. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SeaBIOS and the Geode LX framebuffer
Stephen, I apologize. The code on the loptop.org git was out of date. The last set of changes had not been posted. I am sorry I didn't realize this sooner. Please get the latest code. http://dev.laptop.org/git?p=geode-vsa;a=summary Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Proposed rom renaming change
Ward Vandewege wrote: On Tue, Oct 07, 2008 at 01:55:14PM -0600, Jordan Crouse wrote: Our current ROM naming scheme in buildrom is -.rom. This is all nice and good, but for archiving (or rom-o-matic) purposes, we need to be more descriptive. Therefore, I propose that we move to the more unwieldly, but also more descriptive: --cbv[23]-.rom Thoughts? Great. I'd be happy to see a date/timestamp in there too. That would make the string really long. I think the revision is more relevant. A build date should follow the file date/time. I know that can get lost but I guess that the reason you want time/date is for builds that use local files and are not a svn co r###. What about replace the cbv[###] with the time/date or other user string on local builds? More thoughts? Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AMD Serengeti Cheetah devices
ron minnich wrote: On Wed, Oct 8, 2008 at 8:54 AM, Myles Watson <[EMAIL PROTECTED]> wrote: This is great! Could we go back one more step to the 8132? It looks like the 8111 hangs off the 8132. it doesn't I think, because the 8132 is a tunnel. So 8111 and 8132 are peers. That was always my understanding. Marc? ht socketF socketF || |ht |ht || AMD8151(AGP) AMD8132 (PCIX tunnel) | |ht | AMD8111 HT IO Hub --- IDE | |-- USB |lpc|-- PCI | LPC SIO -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] AMD64 Embedded Processors and Chipset Linux Support web page
The AMD64 Embedded Processors and Chipset Linux Support web page is open for business. http://www.amd.com/us-en/ConnectivitySolutions/ProductInformation/0,,50_2330_15872,00.html This page has links to AMD supported open source projects like coreboot and it also links to the public documents. I have updated AMD public documents coreboot wiki page with the new links. http://www.coreboot.org/AMD_Public_Documents Please let me know if you have any questions, complaints, etc. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AMD64 Embedded Processors and Chipset Linux Support web page
Peter Stuge wrote: Marc Jones wrote: The AMD64 Embedded Processors and Chipset Linux Support web page is open for business. Nice! Please let me know if you have any questions, complaints, etc. Just a note that the link "Information" under Open Source ATI Graphics points to a wiki page on x.org that doesn't seem to exist. We have passed that on to the web folks to fix. Thanks, Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] corebootV2 Can support IEI lx-800 mainboard?
wangdu2002 wrote: I am a Chinese,I brower your site,I am sorry,my english is poor. I have a mainboard ,IEI lx-800 ,cpu Amd Geode 500HZ,like support mainboard lists IEI pcisa-lx-800,corebootV2 Can support this mainboard? this board datasheet in appendix. http://www.iei.com.tw can fund it. thanks you for free software! It would require a mainboard port. You can get started here: http://www.coreboot.org/AMD_Geode_Porting_Guide -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AMD Serengeti Cheetah devices
ron minnich wrote: On Thu, Oct 9, 2008 at 3:29 PM, Carl-Daniel Hailfinger <[EMAIL PROTECTED]> wrote: That disappearance trick only works only with geode right now and needs disable_vpci or somesuch set in the dts. I had a patch which allowed you to use "hidden" as a property in the dts. I can dig it up if you want. there has been hardware in the past -- in v1 days in particular -- wherein a bit set in function 0 made another function disappear -- not visible in config space. It really happens ... Many chipsets liek the 690.600 can do this as well. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [Fwd: Re: flashrom and the dbm690t]
ron minnich wrote: I can easily read from the chip on the board. But, hot plugging is not working out. The basic part is a 49lf008a; putting in 49lf008 or 49lf080 just gets reads back of ff. Ideas welcome. Do BIos saviours exist any more? But you can read out the original ROM file? If you switch to FWH (49lf008a) you will need to set FakeAsrEn [PM_Reg:8Fh] UseBypassRom[1] and BypassRomSel[3:2]. You can check the range : LPC ROM Address Range 2 (Start Address)- RW - 16 bits - [PCI_Reg: 6Ch] LPC ROM Address Range 2 (End Address) - RW - 16 bits - [PCI_Reg: 6Eh] It should be 0xfff0 meaning 0xfff0-0x Rom Protect 0 - RW - 32 bits - [PCI_Reg: 50h] Should be 0. That is all I can think of at the moment. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [v2][patch] update k8 fid/vid setup
Uwe Hermann wrote:
On Wed, Oct 01, 2008 at 02:57:03PM -0600, Marc Jones wrote:
Resubmitting this patch. I think I worked out all the corner cases and
made it a little easier to understand.
This will probably break the build on some boards, e.g.:
Processing mainboard/asus/a8v-e_se (i386: ok)
Creating config file... ok
Creating builddir...ok
Compiling image on 1 cpu .. FAILED after 4s! Log excerpt:
cache_as_ram_auto.c:(.rom.text+0x3a34): undefined reference to `printk_debug'
collect2: ld returned 1 exit status
make[1]: *** [coreboot] Error 1
I think the reason is this:
+ printk_debug("Current fid_cur: %x\n", fid_cur);
+ printk_debug("Requested fid_new: %x\n", fid_new);
All other printk_*'s in this file are "protected" similar to this:
#if K8_SET_FIDVID_DEBUG == 1
#if CONFIG_USE_PRINTK_IN_CAR
printk_debug("%s%x\r\n", str, val);
#else
print_debug(str); print_debug_hex32(val); print_debug("\r\n");
#endif
#endif
I fixed several platforms that didn't have prink_* support for a
different fix. I would rather fix the platforms since K8 always has CAR.
The print_* PRINTK_IN_CAR is really ugly and would like it to go away
I will run abuild and see what platforms need some printk love.
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SeaBIOS + Windows + Coreboot
Steve Spano wrote: I will keep the list posted with my results and problems, my goal here is to boot Windows 2000/XP/CE on the AMD Geode LX800. The Geode platform is not ideal for this exercise. The VSA used by coreboot doesn't support the VGA BIOS (only the minimal set of pci config space emulation). It is assumed that a native driver would be used. Some folks have discussed developing an open VGA BIOS for Geode but no development has been done yet. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Quick question on vt8237 smbus
Corey Osgood wrote:
I'm working on vt8237 smbus in v3, and I had a quick question, mostly
for Rudolf Marek and Bari, but feel free to jump in with your 2 cents:
u8 smbus_read_byte(u16 dimm, u8 offset, u16 smbus_io_base)
{
u8 val;
printk(BIOS_SPEW, "SMBus Read from DIMM %1x at address 0x%4x\n",
dimm, offset);
smbus_reset(smbus_io_base);
/* Clear host data port. */
outb(0x00, smbus_io_base + SMBHSTDAT0);
//SMBUS_DELAY();
smbus_wait_until_ready(smbus_io_base);
dimm = (dimm << 1) | 1;
outb(dimm, smbus_io_base + SMBXMITADD);
The dimm = (dimm << 1) | 1 is something that came from a via southbridge
porting guide (NOT the one for the vt8237r, I don't have that one). With
it, my spd addresses are 0x50, 0x51, etc, without it, they'd be 0xa1,
0xa3, etc. Which would be preferred? Do you think we'd ever need a 0xa0
or 0xa2 address?
My 2cents.
I have never really cared for the <<1. I prefer the more normal IO
address. Most platform specs I have seen indicate the spd device at
0xA0, 0xA2, etc.
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SeaBIOS + Windows + Coreboot
Steve Spano wrote: Who would I take this up with at AMD - can anyone from AMD chime in? Through the embedded website/developer network is the place to contact AMD about this. http://www.amd.com/us-en/ConnectivitySolutions/ProductInformation/0,,50_2330_3364,00.html If you have a problem or don't get a timely response please let me know. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]: v2: Move AMD RS690/SB600 PCI IDs to pci_ids.h
Move AMD RS690 and SB600 PCI IDs to pci_ids.h where they should be. Build-tested with the AMD dbm690t board. Signed-off-by: Uwe Hermann <[EMAIL PROTECTED]> Acked-by: Marc Jones <[EMAIL PROTECTED]> -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]: v3: Move AMD RS690/SB600 PCI IDs to pci_ids.h
Uwe Hermann wrote: Move AMD RS690 and SB600 PCI IDs to pci_ids.h where they should be. Build-tested with the AMD dbm690t board. Signed-off-by: Uwe Hermann <[EMAIL PROTECTED]> Acked-by: Marc Jones <[EMAIL PROTECTED]> -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]: v2: Move AMD RS690/SB600 PCI IDs to pci_ids.h
Uwe Hermann wrote: On Mon, Oct 13, 2008 at 02:50:05PM -0600, Marc Jones wrote: Move AMD RS690 and SB600 PCI IDs to pci_ids.h where they should be. Build-tested with the AMD dbm690t board. Signed-off-by: Uwe Hermann <[EMAIL PROTECTED]> Acked-by: Marc Jones <[EMAIL PROTECTED]> Thanks, r3655. Btw, should PCI_DEVICE_ID_ATI* be renamed to PCI_DEVICE_ID_AMD* for the RS690 and SB600? Or should we keep the old names? Yes you are correct. We should change that. Thanks, Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] IB520 Embedded MoBo
Davide Visconti wrote: I can following this howto... ? (http://www.coreboot.org/AMD_Geode_Porting_Guide) Yes, That link is the best for getting started on adding a new mainboard. If any parts are confusing please let us know so we can make that page better. Thanks, Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFC] v3: Stack switching abstraction for C7 and later Intel processors
ron minnich wrote: Here is a version I put together yesterday as a straw main. summary: stage1_main is now split into stage0_main and main(). stage0_main runs up to and including initram. It then calls disable_car. disable_car does what it does now: copy CAR stack to ram stack, disable car, BUT: instead of a ret, it does a ljmp to main. Why not ret and do a call (or ljmp) from stage0_main to main(). It would make the code easier to follow and it would be easy to add code if anything were required between disable car and the jmp. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFC] v3: Stack switching abstraction for C7 and later Intel processors
ron minnich wrote: On Tue, Oct 14, 2008 at 9:31 AM, Marc Jones <[EMAIL PROTECTED]> wrote: Why not ret and do a call (or ljmp) from stage0_main to main(). It would make the code easier to follow and it would be easy to add code if anything were required between disable car and the jmp. it's just not doable on some of these hardware implementations. It's desirable but not doable. There are going to be cases where disable_car resumes somewhere else. So we might as well just get it over with and put it in the code ;-) What is the hardware limitation? I don't know gcc that well, but a lcall wouldn't get the correct address on the stack? If not, what about passing the return address(or pushing it on the stack). It is more complicated to do but it makes the code easier to understand. A few other comments from this thread. > + * returns bottom of stack, when passed an on-stack variable such as a > + * parameter or automatic. Stack base must be STACKSIZE aligned > + * and STACKSIZE must be a power of 2 for this to work. > + * Luckily these rules have always been true. > Also, that was a good catch by Carl-Daniel about that cache stack size and alignments. CAR is closely related to MTRRs so I think that the MTRR rules should be used here. Or don't have any rules, it is up to the caller to get it correct for their CPU. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFC] v3: Stack switching abstraction for C7 and later Intel processors
Carl-Daniel Hailfinger wrote: If the stack is > CARBASE, then it is the CARBASE + CARSIZE - 4. If < carbase, it is the RAMBASE + RAMSIZE - 4. Done. But let's make it flexible. Hm yes, something along these lines. Which leads to an interesting question: Where do we want the stack if we have to move it? Top of memory? That should be specific to the CPU or platform but it would be good to be below 1MB. 0x1000 is a normal location. This will allow the stack to be shared if/when coreboot goes to real mode (SeaBIOS integration discussion). Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFC] v3: Stack switching abstraction for C7 and later Intel processors
ron minnich wrote: On Tue, Oct 14, 2008 at 2:16 PM, Carl-Daniel Hailfinger Calling anything after disable_car() returns can only be done reliably if the stack has not moved. You see, gcc is free to reorder stuff as it sees fit and it could insert almost anything between disable_car() and the call to stage1. you're right too. In any event, I have never been comfortable with returning from disable_car(), so away we go. OK, comment below the call that it should never return and/or put a die() there as well to catch it if it did come back. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] flashrom and the dbm690t
ron minnich wrote: [EMAIL PROTECTED] qemu]# /usr/local/bin/flashrom -w /tmp/bios.bin Calibrating delay loop... OK. No coreboot table found. WARNING: No chipset found. Flash detection will most likely fail. Found chip "SST SST49LF004A/B" (512 KB) at physical address 0xfff8. Flash image seems to be a legacy BIOS. Disabling checks. ERASE FAILED! [EMAIL PROTECTED] qemu]# Guess we'll need some chipset support. I am done on this for the day but wanted you all to know. ron The chipset isn't detected but my system can read/write/erase ok. I don't know if your BIOS is write protecting the ROM. Can you dump the lpc bridge registers? $ lspci -s 0:0:14.3 -xxx -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [patch][flashrom] sb600 flashrom
More could be done to open up a larger ROM area etc but this will inform
you of a major problem.
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
SB600 has four write once LPC ROM protect areas. It is not possible to write
enable that area once the register is set so print a warning.
Signed-off-by: Marc Jones <[EMAIL PROTECTED]>
Index: chipset_enable.c
===
--- chipset_enable.c(revision 3658)
+++ chipset_enable.c(working copy)
@@ -571,6 +571,24 @@
return 0;
}
+static int enable_flash_sb600(struct pci_dev *dev, const char *name)
+{
+uint32_t val;
+ uint8_t reg;
+
+/* Clear ROM Protect 0-3 */
+ for (reg = 0x50; reg < 0x60; reg+=4) {
+ val = pci_read_long(dev, reg);
+ if (val & 0x03) {
+ printf("\nLPC ROM Protect 0x%x is set to 0x%x on %s.\n
You will not be able to flash that location. (WARNING ONLY)\n", reg, val, name);
+ }
+ }
+
+return 0;
+
+
+}
+
static int enable_flash_ck804(struct pci_dev *dev, const char *name)
{
uint8_t old, new;
@@ -744,6 +762,7 @@
{0x1039, 0x0008, "SiS5595", enable_flash_sis5595},
{0x1022, 0x2080, "AMD CS5536", enable_flash_cs5536},
{0x1022, 0x7468, "AMD8111", enable_flash_amd8111},
+ {0x1002, 0x438D, "ATI(AMD) SB600", enable_flash_sb600},
{0x10B9, 0x1533, "ALi M1533", enable_flash_ali_m1533},
{0x10de, 0x0050, "NVIDIA CK804",enable_flash_ck804}, /* LPC */
{0x10de, 0x0051, "NVIDIA CK804",enable_flash_ck804}, /* Pro */
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [patch][flashrom] sb600 flashrom
ron minnich wrote: [EMAIL PROTECTED] flashrom]# ./flashrom -w /tmp/bios.bin Calibrating delay loop... OK. No coreboot table found. Found chipset "ATI(AMD) SB600", enabling flash write... OK. Found chip "SST SST49LF004A/B" (512 KB) at physical address 0xfff8. Flash image seems to be a legacy BIOS. Disabling checks. ERASE FAILED! [EMAIL PROTECTED] flashrom]# Marc, you had no trouble right? This is odd. This is with my patch? Please send lspci. The chipset isn't detected but my system can read/write/erase ok. I don't know if your BIOS is write protecting the ROM. Can you dump the lpc bridge registers? $ lspci -s 0:0:14.3 -xxx Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [patch][flashrom] sb600 flashrom
ron minnich wrote: On Wed, Oct 15, 2008 at 8:58 AM, Marc Jones <[EMAIL PROTECTED]> wrote: This is with my patch? yes Please send lspci. 00:14.3 ISA bridge: ATI Technologies Inc SB600 PCI to LPC Bridge 00: 02 10 8d 43 0f 00 20 02 00 00 01 06 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 02 10 8d 43 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40: 04 00 00 00 43 c0 c3 f7 17 ff 42 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 0e 00 00 0e 00 0f 00 f0 ff ff ff 70: 67 45 23 01 00 00 00 00 01 00 00 00 05 00 00 00 80: 08 00 03 a8 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 01 c0 fe 00 00 00 00 00 00 00 00 00 00 00 00 b0: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 That looks identical to my system. There isn't a write protect set and the decode is 1MB. I used a sst49lf080a without issue. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] v3 comments - was Serengeti vga hang
Myles Watson wrote: Here's the latest log. It hangs in the emulator. I've tried both emulators, but to no avail. Nothing jumped out at me why you might be having a problem with VGA. These are some general v3 comments. I have a good feel for the new dts/device scanning so some questions may just be dumb. setting up resource map ex offset (0+0,18+0,1+0,44) & f8f8 | + (0+0,18+0,1+0,4c) & f8f8 | 0001+ ... done. I don't think that resource setup needs to be done this early. There are no resources before HT init. It should go just before: Ram1.0, setting up CPU 0x00 northbridge registers Choosing fallback boot. ... LAR: File not found! LAR: Run file fallback/initram/segment0 failed: No such file. Fallback failed. Try normal boot LAR: Attempting to open 'normal/initram/segment0'. I think that this came up way back when, but why is fallback tried first? Is this a configuration mistake? It is a waste of time which is making SimNow take even longer. prepare to InitDram:000100020003000400050006000700080009 That is some strange output find_device_operations: cons 0x00015260, cons id PCI: 1022:1100 find_device_operations: check all_device_operations[i] 0x00015800 dev_id_string: Unknown device ID type: 0 find_device_operations: cons 0x00015800, cons id Unknown …À‰ÁÆÀ¤ constructor: constructor is 0x No ops found and no constructor called for PNP: . new_device: devcnt 4 find_device_operations: check all_device_operations[i] 0x00015200 This is the CPU HT device. This section loops several times. What is coreboot trying to do? And then some stuff gets setup and it loop some more... Yeah, keep seeing this output come up again and again. PCI: scan devfn 0xc0 to 0xff PCI: devfn 0xc0 What is this for? When scanning PCI stuff PCI: devfn 0xc4 pci_scan_get_dev: list is 0x000cf084, *list is 0x00016680 pci_scan_get_dev: check dev domain_0_pci_1_0 pci_scan_get_dev: check dev domain_0_pci_1_0 it has devfn 0x08 pci_scan_get_dev: check dev domain_0_pci1_18_0 pci_scan_get_dev: check dev domain_0_pci1_18_0 it has devfn 0xc0 pci_scan_get_dev: check dev domain_0_pci2_18_0 pci_scan_get_dev: check dev domain_0_pci2_18_0 it has devfn 0xc0 pci_scan_get_dev: check dev domain_0_ioport_2e pci_scan_get_dev: child domain_0_ioport_2e(IOPORT: 2e) not a pci device: it's type 11 pci_scan_get_dev: check dev dynamic PNP: 002e.0 When scanning for PCI devices PNP IO areas should probably be skipped or I may just misunderstand what it is doing here... Where is phase4_enable_disable? Shouldn't it happen before Phase 4: Reading resources ? There is some 8111/8132 setup that might be causing the VGA issue? Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [patch][flashrom] sb600 flashrom
Peter Stuge wrote: Marc Jones wrote: SB600 has four write once LPC ROM protect areas. It is not possible to write enable that area once the register is set so print a warning. Signed-off-by: Marc Jones <[EMAIL PROTECTED]> Clean up the whitespace before committing please. done Acked-by: Peter Stuge <[EMAIL PROTECTED]> r3659 Thanks, Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] v3 comments - was Serengeti vga hang
ron minnich wrote: On Wed, Oct 15, 2008 at 10:36 AM, Marc Jones <[EMAIL PROTECTED]> wrote: ... Where is phase4_enable_disable? Shouldn't it happen before Phase 4: Reading resources ? It does, for each device, if it is set up for that device. phase4_enable_disable was in v2 in a different name. The problem is that sometimes you have to enable a device to read the resources. phase4_enable_disable looks at dev->enabled and enables "whatever has to be enabled" -- it's device dependent -- so that resources can be read. It's called enable_disable because it can do both, depending on device_enabled, and I was not clever enough to think of a better name :-) For most devices, it's empty. Sorry but I don't see any phase4_enable_disable in the output. It is not being called in device.c dev_phase4(). I think that is a problem. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] v3 comments - was Serengeti vga hang
ron minnich wrote: On Wed, Oct 15, 2008 at 11:02 AM, Marc Jones <[EMAIL PROTECTED]> wrote: ron minnich wrote: Sorry but I don't see any phase4_enable_disable in the output. It is not being called in device.c dev_phase4(). I think that is a problem. see pci_probe_dev. And, hey, if I could get you all to use kscope, you would just ask kscope to show you where it's called :-) I'm not saying it's right but ... it's there. Should it really be a phase3 function? Should it be run after any phase3_enable_scan? Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SimNOW VGA int 1a
Myles Watson wrote: -Original Message- From: Tom Sylla [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 15, 2008 2:04 PM To: Myles Watson Cc: Coreboot; ron minnich Subject: Re: [coreboot] SimNOW VGA int 1a On Wed, Oct 15, 2008 at 3:56 PM, Myles Watson <[EMAIL PROTECTED]> wrote: C000:3241 B802B1 mov ax,b102 C000:3244 CD1A int 1a : FF Yep, "b102" is not a common signature. I'm looking for the place where the interrupt vector was supposed to have been set. I am confused, your coreboot log shows several int1a before the failure: int1a vector at 10ffef dev_find_device: find PCI: 1022:2067 ... int1a vector at 37da2 int1a vector at 37da2 int1a vector at 76682 int1a vector at 76682 int1a vector at 76682 int1a vector at 76682 int1a vector at 76682 int1a vector at 76682 Sorry. I should have sent a new log. It's the same as the old one except at the end. Once I switched to vm86 instead of x86emu, there is no longer any output after "Copying VGA ROM Image ..." Is int1a pci bios calls supported in the emulators? Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SimNOW VGA int 1a
Myles Watson wrote: Here's the next part of the log now that I've enabled setup_realmode_idt (I'm running it right before real_mode_switch_call_vga. Copying VGA ROM image from 0xfe04 to 0xc, 0x8000 bytes BREAK HERE run_bios = 0x944a biosint: INT# 0x18 biosint: eax 0x2e ebx 0x1 ecx 0xfe4 edx 0xcf11c biosint: ebp 0xc000 esp 0xd edi 0x1a esi 0x0 biosint: ip 0x1022 cs 0xf flags 0x2067 BIOSINT: Unsupport int #0x18 That isn't the same emulator that most of v2 uses. setup_realmode_idt is certainly required. 0x18 is a strange INT to see. http://www.ctyme.com/intr/int.htm Can you get back to the calling code and see what it was doing? Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SimNOW VGA int 1a
Myles Watson wrote: -Original Message- From: Marc Jones [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 15, 2008 2:45 PM To: Myles Watson Cc: Tom Sylla; ron minnich; Coreboot Subject: Re: [coreboot] SimNOW VGA int 1a Myles Watson wrote: Here's the next part of the log now that I've enabled setup_realmode_idt (I'm running it right before real_mode_switch_call_vga. Copying VGA ROM image from 0xfe04 to 0xc, 0x8000 bytes BREAK HERE run_bios = 0x944a biosint: INT# 0x18 biosint: eax 0x2e ebx 0x1 ecx 0xfe4 edx 0xcf11c biosint: ebp 0xc000 esp 0xd edi 0x1a esi 0x0 biosint: ip 0x1022 cs 0xf flags 0x2067 BIOSINT: Unsupport int #0x18 That isn't the same emulator that most of v2 uses. setup_realmode_idt is certainly required. 0x18 is a strange INT to see. http://www.ctyme.com/intr/int.htm Can you get back to the calling code and see what it was doing? The VGA BIOS calls 1a, but it looks like too many things get pushed onto the stack, and it thinks it's 18 instead. I'm not an assembly programmer, but it looks like the problem is in callbiosint or handler. It looks like the registers are being pushed onto the stack too many times? E! This looks like a compiler function calling problem. I think that the 0x18 comes from here : "biosprotect: \n" " .code32 \n" " movw$0x18, %ax\n" " mov %ax, %ds\n" " mov %ax, %es\n" " mov %ax, %fs\n" " mov %ax, %gs\n" " mov %ax, %ss\n" " lidtidtarg \n" " call biosint \n" Which means that biosint isn't using variables from the stack but from the register. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] v3 comments - was Serengeti vga hang
ron minnich wrote: there is a phase 3 enable that enables a device (if needed) to appear or disappear in config space. There is a phase 4 enable disable to enable a device's resources to be read. Both of these usages appeared in v2. Sorry, I'm worn out (long day) if this makes no sense let me know. Your explanation of what it is makes sense. What doesn't make sense is that it is never called during phase4. It is no better than v2 if name doesn't tell you when it is used. The only time it is used is in pci device scan which is really phase1. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SimNOW VGA int 1a
Myles Watson wrote: On Thu, Oct 16, 2008 at 9:49 AM, ron minnich <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: On Thu, Oct 16, 2008 at 8:48 AM, Myles Watson <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: >> >> > Check PCI: 1022:2067 >> >> > found >> >> > 0xb102: return 0x120 >> >> the wrong # here? > > Yes. It should be device # 4 as far as I can tell. In the debugger when I > do a config read to bus 1 dev 4 function 0 I get the right data back. When > I do a read to bus 1 dev 2 function 0 I get an error that no device > responded. > > Like I said, I don't know why the reads succeed. > so you need some debug prints in the PCIBIOS support code. Check PCI: 1022:2067 PCI: 01:04.0 found bus->secondary = 0x1 dev->path.pci.devfn = 0x20 0xb102: return 0x120 Now I'm confused. I guess 0x120 was correct (the slot is the upper 5 bits of the byte), so I'm still looking. Now it makes sense why the reads succeed, but the config write failure is puzzling. It's trying to write 0x to the BAR, but that changes the memory map, so after that write there's garbage everywhere. I still haven't found the config register that gets changed, but it's not in the VGA card's space. Which BAR? What is the contents of 0xcf8? Not sure why, but writing 0xFFFF to a BAR is to get the size. It shoudl disable the device before it does that but sometimes they are sloppy and don't. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Fwd: SimNOW VGA int 1a
Myles Watson wrote: On Thu, Oct 16, 2008 at 1:56 PM, ron minnich <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: I did not realize we had gone private. see below. Basically, vga bios tries to size a 16 meg register and at an intermediate point the vga hardware ends up decoding the top 16 mb of memory. I welcome a fix. It's just not obvious to me. But we could just say that VGA ROM init is a black hole, only call functions defined there and hope it works. :) Myles True but this ether means we duplicate code in the emulator or don't get any information out. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] IB520 Embedded MoBo
Davide Visconti wrote: [...] I have econtered an error during the compilation. I have make these step: - svn co svn://coreboot.org/buildrom - svn co svn://coreboot.org/repos/trunk/coreboot-v2 - cd buildrom/buildrom-devel/ - make menuconfig - make When I run "make" I get the attached error. How I make to understand where is the problem? ...and after the succesfull rom compilation? Thank you in advance, Davide The build log is buildrom/buildrom-devel/work/coreboot-v2/logs/build.log That's where the real error is. Thanks, Myles I have see the log file "buildrom/buildrom-devel/work/coreboot/logs/build.log" and the size is too big. [...file cut...] nm -n coreboot | sort > coreboot.map objcopy --gap-fill 0xff -O binary coreboot coreboot.strip gcc -o buildrom /root/buildrom/buildrom-devel/work/coreboot/svn/util/buildrom/buildrom.c cp ../payload.elf payload ./buildrom coreboot.strip coreboot.rom payload 0x1 0x77000 ERROR: payload (1572884) + coreboot (65536) - Size is 1150996 bytes larger than ROM size (487424). make[2]: *** [coreboot.rom] Error 1 make[1]: *** [fallback/coreboot.rom] Error 1 How to set the ROM size? On the IB520 MoBo I have a 512Kb but in the future I can buy a 2Mb. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot The ROM size is set in coreboot/targets/company/mainboard/Config.lb -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Serengeti VGA
Myles Watson wrote: I've been trying to make the configuration spaces match between v2 and v3. The biggest difference left is the disabled/hidden devices which are not hidden in v3. Any chance that's causing the problem? I've also been trying to figure out where the legacy IO space (e.g. 0x3d4) gets routed to the card. Does this happen automatically because the VGA bit is set in the bridge? Yes, The vga bit on the subtractive bridge routes the graphics io. How did you work around the vm86 problem? Did the graphics command register get re-enabled? Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Serengeti VGA
Myles Watson wrote: On Mon, Oct 20, 2008 at 1:48 PM, Marc Jones <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: Myles Watson wrote: I've been trying to make the configuration spaces match between v2 and v3. The biggest difference left is the disabled/hidden devices which are not hidden in v3. Any chance that's causing the problem? I've also been trying to figure out where the legacy IO space (e.g. 0x3d4) gets routed to the card. Does this happen automatically because the VGA bit is set in the bridge? Yes, The vga bit on the subtractive bridge routes the graphics io. How did you work around the vm86 problem? Did the graphics command register get re-enabled? I made the interrupts self contained, with no output. The VGA ROM initialization returns, but there is no output to the screen. At least the screen turns black on an int10 now, though. The only differences between the PCI configuration registers now is that v3 has a little larger space for VGA and SERR is set. Ok, That should be fine. Black usually means all FF in the vga memory. Check A000-B are getting to the controller. VGA enable in the bridge control register (3e) and VGA pallet snoop in the command register (04) should be set in the bridge. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Serengeti VGA
Marc Jones wrote: Myles Watson wrote: On Mon, Oct 20, 2008 at 1:48 PM, Marc Jones <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: Myles Watson wrote: I've been trying to make the configuration spaces match between v2 and v3. The biggest difference left is the disabled/hidden devices which are not hidden in v3. Any chance that's causing the problem? I've also been trying to figure out where the legacy IO space (e.g. 0x3d4) gets routed to the card. Does this happen automatically because the VGA bit is set in the bridge? Yes, The vga bit on the subtractive bridge routes the graphics io. How did you work around the vm86 problem? Did the graphics command register get re-enabled? I made the interrupts self contained, with no output. The VGA ROM initialization returns, but there is no output to the screen. At least the screen turns black on an int10 now, though. The only differences between the PCI configuration registers now is that v3 has a little larger space for VGA and SERR is set. Ok, That should be fine. Black usually means all FF in the vga memory. Check A000-B are getting to the controller. VGA enable in the bridge control register (3e) and VGA pallet snoop in the command register (04) should be set in the bridge. Sorry, I had that backwards FF is blinking white, 00 is black. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Serengeti VGA
Myles Watson wrote: 060 AMD-8111 PCI 74601022023001470604000700014000 4001010002001010 FE00FD00FFE0FFF0 00C0042B00FF ^ ISA isn't set. That might be a problem. -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] filo serial console problems
It looks like filo has some problems with serial console. 1. left arrow: reboots the system 2. tab: carriage return 3. backspace: leaves B characters Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] patch: unshare pci operations
ron minnich wrote: Unshare these, as we can not use them when buggy PCI expansion ROMS are active and are hiding ROM. Acked-by: Marc Jones <[EMAIL PROTECTED]> -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] v2: sb600: Fix I/O port variable size, simplify code
Uwe Hermann wrote: See patch. Uwe. I/O ports are 16bit, so change 'unsigned long port_base' to 'u16 port_base'. Also, use more readable #defines instead of hardcoded config ports for PM/PM2 related functions, and simplify them a bit. Build-tested with the AMD dbm690t target. Signed-off-by: Uwe Hermann <[EMAIL PROTECTED]> Good stuff. Thanks! Acked-by: Marc Jones <[EMAIL PROTECTED]> -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Serengeti VGA
Myles Watson wrote: On Mon, Oct 20, 2008 at 4:10 PM, Marc Jones <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: Myles Watson wrote: 060 AMD-8111 PCI 74601022023001470604000700014000 4001010002001010 FE00FD00FFE0FFF0 00C0042B00FF ^ ISA isn't set. That might be a problem. I can't tell that v2 ever sets it. In the 8111 datasheet it looks like that bit makes it so that bits 8 & 9 of the address get ignored so that only 256B of every 1024 are accessible. I don't think that's what we want. Looking for that I found an interesting couple of defines. include/device/pci_def.h:#define PCI_BRIDGE_CTL_NO_ISA 0x04/* Disable bridging of ISA ports */ include/device/pci_def.h:#define PCI_CB_BRIDGE_CTL_ISA 0x04 I can see that they're used in two different places (one for the hardware, one for the device struct), but it still seems confusing. You are correct. I misunderstood this setting. I don't think that it should be set. I think that the problem is probably in the mmio map that Ron posted yesterday. I'll keep looking at stage2 device init and then I'll check out what is going on with mmio. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SimNOW debugger syntax help
Myles Watson wrote: Marc, Jordan, or another SimNOW user, f[b|w|d|q] [,[l|p]] Fill physical(default) or linear Memory I wanted to fill the VGA RAM with a pattern, but I can't figure out the syntax for an . It keeps freezing the simulator. Could you give me an example for filling 1M of memory in physical address space with some pattern? I would have expected the [,[l|p]] to come after the too. Thanks, Myles fd 10 10001f ,p 5a5a5a5a worked for me. You are right about the ,p. I am not sure why it would be freezing unless the mem map is really screwed up and it is going somewhere bad. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [v2][patch] update k8 fid/vid setup
Uwe Hermann wrote: I've tested the patch on my MSI K9N Neo (MS-7260) but I'm not sure if the changes I've seen in the logs are correct. It seems the CPU frequency changed from 1.8 to 1.0 MHz. See attached logs/diffs for more information. That is bad. Can you set K8_SET_FIDVID_DEBUG and send the new minicom? Thanks, Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]es 7 assorted fixes
Jens,
Thanks for the patches. I have acked and committed some of these. Please
see my comments.
Jens Rottmann wrote:
route_irq15.diff (changes pirq_routing.c):
Fixes a off-by-one error when routing the IRQs. This led to IRQ15 not
getting assigned.
Acked-by: Marc Jones <[EMAIL PROTECTED]>
r3687
autoboot_delay.diff (changes filo.c):
Fixes compile error when AUTOBOOT_DELAY=0.
But this would break if AUTOBOOT_DELAY wasn't defined. Don't set
AUTOBOOT_DELAY to 0 or do a more complete fix.
#if AUTOBOOT_DELAY = 0
#undef AUTOBOOT_DELAY
dword_copy.diff (changes crt0.S.lb, cache_as_ram.inc (Geode LX)):
Speed up copying coreboot to ram by using "movsl" instead of "movsb".
Also use different console messages for copying and uncompressing, like
it's already done in similar code in other places.
Acked-by: Marc Jones <[EMAIL PROTECTED]>
r3688
speed_calc.diff (changes raminit.c (Geode LX)):
Changed RAM speed calculation to fix RAM modules getting rejected only
due to integer rounding errors. Previously, the formula was:
speed = 2 * (1/spd_value)
For spd_value=60 this means speed = 2 * 166 = 332, which is less than
333 and coreboot died saying RAM was incompatible. The new formula is:
speed = 2 / spd_value
For spd_value=60, speed=333, which is fine.
Acked-by: Marc Jones <[EMAIL PROTECTED]>
r3689
await_ide.diff (changes ide.c):
Made await_ide(), which polls for an ide status change, check the status
reg much more often. In my case this reduced the time spent in coreboot
by 1.5 sec!
The timeout values of course aren't changed, only the granularity. Also,
I didn't see any udelay() implementation that looked like it couldn't
cope with 10 us delays. (Most are written as for (...) inb(0x80) loops.)
Acked-by: Marc Jones <[EMAIL PROTECTED]>
r3690
fs_arch.diff (changes ext2fs.c, fat.c):
#if ARCH == 'i386' results in a compile error: character constant too
long (or something alike). Changed it to
#ifdef __i386
I'm unsure if this is correct, though! Why didn't anyone hit this
problem before? Is this some ROMCC-special?
I don't think anyone builds this so we wouldn't see it. We just use
filo. Can you send the build output?
it8712_gpio.diff (changes superio.c (IT8712F)):
Added the missing I/O resources for IT8712F GPIOs. Our boards need these
e.g. to switch the com ports between RS232 and RS485.
{&ops, IT8712F_GPIO, PNP_IO0 | PNP_IO1 | PNP_IO2 | PNP_IRQ0, {0xfff, 0},
{0xff8, 0}, {0xff8, 0},},
I think that PNP_IO1 should be 0xfff
{&ops, IT8712F_GPIO, PNP_IO0 | PNP_IO1 | PNP_IO2 | PNP_IRQ0, {0xfff, 0},
{0xfff, 0}, {0xff8, 0},},
Please send new patches for the ones that need it.
Thanks,
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] filo serial console problems
Patrick Georgi wrote: Jordan Crouse schrieb: On 20/10/08 17:16 -0600, Marc Jones wrote: It looks like filo has some problems with serial console. 1. left arrow: reboots the system Lots of left arrows - presumably any escape related key would be affected. This has been reported before, but it doesn't seem to break in qemu, only on real hardware. The attached patch limits the amount of characters read for escape handling to the size of the buffer. It also changes the recursion to a while loop. A compiler "should" resolve the tail recursion, but I'd rather be sure. Signed-off-by: Patrick Georgi <[EMAIL PROTECTED]> This is a lot better. It doesn't just reboot if I use the left arrow. If hold the back arrow down for a few seconds it will reboot when I on the release. Based on the improvement Acked-by: Marc Jones <[EMAIL PROTECTED]> Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] r83 - in trunk/filo: . configs drivers drivers/newusb fs include/grub main main/grub util
[EMAIL PROTECTED] wrote: Author: stepan Date: 2008-10-22 13:19:52 +0200 (Wed, 22 Oct 2008) New Revision: 83 Modified: trunk/filo/Config.in trunk/filo/Makefile trunk/filo/build.sh trunk/filo/configs/defconfig trunk/filo/drivers/ide.c trunk/filo/drivers/newusb/usb.c trunk/filo/fs/blockdev.c trunk/filo/fs/fsys_ext2fs.c trunk/filo/include/grub/shared.h trunk/filo/main/filo.c trunk/filo/main/grub/builtins.c trunk/filo/main/grub/char_io.c trunk/filo/main/grub/cmdline.c trunk/filo/main/grub/grub.c trunk/filo/util/checksum_elf.c Log: New FILO code drop from coresystems' internal repository: * add "developer commands" to filo (lspci, setpci, io) * use staged libpayload per default now. * use libpayload-config.h where appropriate. * fix an ext3 filesystem issues * use libpayload functions to implement grub_printf instead of the incomplete duplication * fix broken "weak" symbol handling. * fix string issue with boot_devices * fix a couple of problems with colors * fix endless loop in case of file open error I tried this code today with the latest libpayload and it is blowing up. It is stuck looping outputting F to the screen. r81 with the latest libpayload seems to work ok. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] patch: unshare pci operations
Stefan Reinauer wrote: Here's the memory map of the low meg on one of my boxes running coreboot: * 0x - 0x03ff Real Mode IVT * 0x0020 - 0x019c MP Table (XXX conflict?) * 0x0400 - 0x04ff BDA (somewhat unused) * 0x0500 - 0x052f Moved GDT * 0x0530 - 0x0b64 coreboot table * 0x0c00 - 0x0c9f SMI communication * 0x0007c000 - 0x0007dfff OS boot sector (unused?) * 0x0007e000 - 0x0007 free to use * 0x0008 - 0x0009fbff usable ram * 0x0009fc00 - 0x0009 EBDA (unused at the moment?) * 0x000a - 0x000b VGA memory * 0x000c - 0x000c VGA option rom * 0x000d - 0x000d free for other option roms? * 0x000e - 0x000f SeaBIOS? (XXX conflict?) * 0x000f - 0x000f03ff PIRQ table * 0x000f0400 - 0x000f66?? ACPI tables * 0x000f66?? - 0x000f DMI tables Seabios in E is good. Mapping out where everything lives in F is really good. The PIRQ table, DMI table, and the first part of the ACPI tables needs to be in F. A large part of the ACPI tables can be in the top of memory. We would need to add that region to E820 via the coreboot table. Maybe the coreboot table should be in F too. We should still have space left over to use for shared functions. Printk and lar functions might be the best candidates. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] HT devices in v3
Myles Watson wrote:
I'm getting stuck in Hypertransport enumeration. Is there supposed to be a
pci_domain that is the child of a HT link? If so, what device ID would it
have.
I'm thinking specifically about the 8132 and 8111 on the Serengeti board.
The dts currently looks like this (simplified):
[EMAIL PROTECTED] {
/config/("northbridge/amd/k8/domain");
[EMAIL PROTECTED],0{
};
[EMAIL PROTECTED],0 {
/config/("northbridge/amd/k8/pci");
[EMAIL PROTECTED],0 {
/config/("southbridge/amd/amd8111/pci.dts");
[EMAIL PROTECTED],0{
/config/("southbridge/amd/amd8111/nic.dts");
};
[EMAIL PROTECTED],0{
/config/("southbridge/amd/amd8111/usb.dts");
};
};
[EMAIL PROTECTED],0 {
/config/("southbridge/amd/amd8111/lpc.dts");
};
};
I think it should look like this:
[EMAIL PROTECTED] {
/config/("northbridge/amd/k8/domain");
[EMAIL PROTECTED],0 {
/config/("northbridge/amd/k8/pci");
[EMAIL PROTECTED],0 { //Really at 00:6.0
/config/("southbridge/amd/amd8111/pci.dts");
[EMAIL PROTECTED],0{
/config/("southbridge/amd/amd8111/nic.dts");
};
[EMAIL PROTECTED],0{
/config/("southbridge/amd/amd8111/usb.dts");
};
};
[EMAIL PROTECTED],0 { //Really at 00:7.0
/config/("southbridge/amd/amd8111/lpc.dts");
};
[EMAIL PROTECTED],0{ //Really at 00:a.0 and 00:b.0
/config/("southbridge/amd/amd8132/pcix.dts");
};
};
My reasoning is that the 8132 and the 8 should be at the same level.
This doesn't work for me in hypertransport enumeration for various reasons.
Before I do a big rewrite, I'd like a little sanity check.
By the way, "dynamic" in the dtsname is bad when you had the device in the
dts. It means it didn't find your device where you said it was.
Thanks,
Myles
Myles,
You are right that they should be on the same level. I am not an expert
enough on dts but I think you are on the right path. The devices need to
be put in the correct place so we don't get dynamic. I expect that Ron
will have some comment.
Thanks,
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] HT devices in v3
Carl-Daniel Hailfinger wrote: Hypertransport representation in the dts is non-existent. I shall attack this in the next few days. Proposals have already been sent to the list, but the enthusiasm was limited. I'm sorry I don't recall your proposal. The ht isn't really ht. It is really root level pci bus. Everything is a pci bus..... Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
