Re: [coreboot] what should CONFIG_HT_CHAIN_UNITID_BASE be in "CPU/1HT device" mode?
The Agesa code goes the branch of Manual BUID assignment. The swap list
is,
{0x0, 0x0, 0xFF, 0x0, 0xFF}. I made a swaplist manually and the ht link
was set up correctly. Now the problem is,
1. If I let AMD_CB_ManualBUIDSwapList give the swap list, it will
provide
{0xFF, CONFIG_HT_CHAIN_UNITID_BASE, CONFIG_HT_CHAIN_END_UNITID_BASE,
0xFF}
It seems that the list is far from we expect.
2. What is the meaning of each entry in the swaplist?
Zheng
-Original Message-
From: Myles Watson [mailto:myle...@gmail.com]
Sent: Thursday, November 05, 2009 6:46 AM
To: 'Marc Jones'
Cc: Bao, Zheng; coreboot@coreboot.org
Subject: RE: [coreboot] what should CONFIG_HT_CHAIN_UNITID_BASE be in
"CPU/1HT device" mode?
> There is just the CPU and 690 or 780. The AMD 600 or 700 is connect
> with Alink, not HT.
You're right. I didn't look closely enough.
> > early_ht.c: Just enumerate the southbridge chain in case that's
needed
> for
> > serial initialization or ROM access.
> >
> > incoherent_ht.c: Enumerate all chains so that they can be optimized
> before
> > the first reset.
> >
> > hypertransport.c: Enumerate the chains according to the device tree.
>
> Is early_ht.c, enumerate_ht_chain(), even needed. The subtractive path
> should work. Maybe depends on the southbridge/configuration.
For K8, early_ht.c doesn't even get compiled in if you set
CONFIG_HT_CHAIN_UNITID_BASE to 0.
It's needed for the case where there is a tunnel, then the southbridge.
Serengeti Cheetah is a good example. You can't get to the southbridge
until
you've moved the 8131 or 8132 out of the way.
> For Fam10, I think that where problems happen is the early_ht.c sets
> values that are found and used by the AGESA based code that has a
> slightly different search algorithm. This happens in ht3init.c,
> process_link(). Failures in process_link() cause the system to halt
> even if it could continue based on the early setup.
I wish I knew more about Fam10, but I don't have a board, so I haven't
been
that motivated to look into it further.
Thanks,
Myles
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [commit] r4945 - trunk/util/msrtool
Author: stuge
Date: 2009-11-16 18:29:22 +0100 (Mon, 16 Nov 2009)
New Revision: 4945
Modified:
trunk/util/msrtool/darwin.c
Log:
msrtool: Add comment with DirectIO URL to the code where it is used.
Signed-off-by: Peter Stuge
Acked-by: Peter Stuge
Modified: trunk/util/msrtool/darwin.c
===
--- trunk/util/msrtool/darwin.c 2009-11-14 19:34:55 UTC (rev 4944)
+++ trunk/util/msrtool/darwin.c 2009-11-16 17:29:22 UTC (rev 4945)
@@ -26,6 +26,10 @@
#include "msrtool.h"
+/* This Darwin support requires DirectIO, which is available at
+ * http://www.coresystems.de/en/directio
+ */
+
int darwin_probe(const struct sysdef *system)
{
#ifdef __DARWIN__
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [v2] r4925 makes my linux hang
> That only happens when the CPU is K8. When the cpu is fam10, VGA runs > ok. > Any advice? I'd be interested in the complete logs, and a log from a successful fam10 boot. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Payload for ASUS A8V-E SE
> what should I use as a payload for ASUS A8V-E SE tried to build one with > buildrom but it no matter what I do it keeps saying that I have no .mk > file for this board. Have you tried SeaBIOS? Just set the mainboard to qemu (or any other) and then get seabios.elf from the deploy/ directory. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Payload for ASUS A8V-E SE
Hi, what should I use as a payload for ASUS A8V-E SE tried to build one with buildrom but it no matter what I do it keeps saying that I have no .mk file for this board. I tried to build a payload with mkelfImage but it creates .elf to big to fit on the chip (4Mb). What should I do? Would a elf from a bootloader like grub be a solution? Does anyone has a payload for this board I could use? thx in advanced. Knut Kujat -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [commit] r4944 - in trunk/targets: arima/hdama emulation/qemu-x86 iei/juki-511p iwill/dk8s2 iwill/dk8x msi/ms7135 tyan/s1846
On 16.11.2009 03:05, Peter Stuge wrote: > s...@coreboot.org wrote: > >> (non-kconfig) build >> > > What remains now, before removing the buildtarget infrastructure? > Boot testing? Fam10 support? Regards, Carl-Daniel -- Developer quote of the week: "We are juggling too many chainsaws and flaming arrows and tigers." -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Multiboot header license change
On Mon, Nov 16, 2009 at 12:44:31AM +0100, Robert Millan wrote: > > Hi, > > This is to announce that, following approval from RMS, the header in > GRUB 2 that contains Multiboot declarations (multiboot.h) is now being > distributed under the X11 license in latest Bazaar trunk of GNU GRUB. > > With this change, we expect make it easier for OS kernel developers > and implementors of Multiboot in general to adopt this specification. Just to be crystal-clear about this, the NetBSD bootblocks and kernel contain a complete Multiboot implementation which has never had any GPL code in it. Thor -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [patch] DIP switch and digital I/O control patch
Hello,
This is a patch for control DIP switch and digital I/O.
Thanks.
Signed-off-by: Libra Li
Index: src/mainboard/technexion/tim5690/cache_as_ram_auto.c
===
--- src/mainboard/technexion/tim5690/cache_as_ram_auto.c (revision 4944)
+++ src/mainboard/technexion/tim5690/cache_as_ram_auto.c (working copy)
@@ -145,6 +145,20 @@
}
#endif/* CONFIG_USE_FALLBACK_IMAGE == 1 */
+/* Early mainboard specific GPIO setup. */
+static void mb_gpio_init(void)
+{
+ /* Init Super I/O GPIOs. Done early. */
+ it8712f_enter_conf();
+ outb(IT8712F_CONFIG_REG_LDN, SIO_INDEX);
+ outb(IT8712F_GPIO, SIO_DATA);
+ outb(0x62, SIO_INDEX); // set Simple I/O Base Address 0x200
+ outb(0x02, SIO_DATA);
+ outb(0x63, SIO_INDEX);
+ outb(0x00, SIO_DATA);
+ it8712f_exit_conf();
+}
+
void real_main(unsigned long bist, unsigned long cpu_init_detectedx);
void cache_as_ram_main(unsigned long bist, unsigned long cpu_init_detectedx)
@@ -177,6 +191,7 @@
/* it8712f_enable_serial does not use its 1st parameter. */
it8712f_enable_serial(0, CONFIG_TTYS0_BASE);
+ mb_gpio_init();
it8712f_kill_watchdog();
uart_init();
console_init();
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Coreboot Support for MSI KT4 Ultra (MS-6590)
Thank you for your important hint. But it seems you are right that the motherboard and VIA chipset is too old for support. Maybe a motherboard like a AM3 board will get supported in future. Greetings Freeman 2009/11/16 Peter Stuge > freeman2411 wrote: > > Ok thank you for the information. I will ask the VIA Support if > > they could release the Programming Documentation. > > Please do that only when you know for sure that someone (yourself, or > someone else) is prepared to follow through and do the actual > implementation work in coreboot. > > (Otherwise, they will just be spending time working on the request > and it will do no good in the end anyway. Also, I guess that chipset > is not a current product, so it may not have much support anyway.) > > Thanks for your consideration! > > > //Peter > > -- > coreboot mailing list: coreboot@coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
