Am 23.10.2008 23:28, Carl-Daniel Hailfinger schrieb:
Thanks for the patch. IIRC various qemu versions have different bugs in
that area, so I'd appreciate to know on which version the code was tested.
The last fix in that area in Qemu is about 4Gbyte RAM scenarios, from
2008-04. It also
+movb%cl, %al
+shrl$2, %ecx
+andb$3, %al
+rep movsl
+movb%al, %cl
rep movsb
I guess we don't care that this movs 256 bytes extra when al 3 = 0.
No, it doesn't. rep movs doesn't do anything if (e)cx = 0.
Regards,
Jens
--
coreboot mailing
Jens Rottmann wrote:
I guess we don't care that this movs 256 bytes extra when al 3 = 0.
No, it doesn't. rep movs doesn't do anything if (e)cx = 0.
Nice!
//Peter
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
+--18.0(Link n where n in [0,1,2])--+--19.0--(CPU)-(2nd HT link)
| |\|
\--(3rd HT link)
| | | +--19.1
| | | +--19.2
| | | +--19.3
| | |
| |
Marc Jones [EMAIL PROTECTED] writes:
Arne Georg Gleditsch wrote:
Marc Jones [EMAIL PROTECTED] writes:
This was my fault. I missed reviewing the abuild config.
This is now the same as serengeti_cheetah_fam10.
A little background information. The fam10 initialization is a bit
larger than the
On 24.10.2008 17:13, Carl-Daniel Hailfinger wrote:
Hi,
I'm getting the following message from lspci on my K8 machine:
00:18.0 Host bridge [0600]: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] HyperTransport Technology Configuration [1022:1100]
Control: I/O- Mem- BusMaster-
Was the following a revelation only to me or is it a generally obscure
knowledge?
PIIX4 documentation says that bit 2 of PCI config register 0xCB (of
function 0) enables access to CMOS memory bank2 via IO ports 0x72 and
0x73 similarly to regular CMOS memory access via 0x70/0x71.
I tested this
Is this defined because of broken hardware? I'm surprised that we need
this.
Thanks,
Myles
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
On Fri, Oct 24, 2008 at 10:10 AM, Myles Watson [EMAIL PROTECTED] wrote:
Is this defined because of broken hardware? I'm surprised that we need
this.
Sorry that wasn't probably specific enough. Here are some of the defines.
They complicate the code quite a bit.
Carl-Daniel Hailfinger wrote:
On 24.10.2008 00:59, Marc Jones wrote:
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
On Fri, Oct 24, 2008 at 11:13 AM, Carl-Daniel Hailfinger
[EMAIL PROTECTED] wrote:
Note the warning about Possibly incomplete decoding which stems from
the fact that the processor mentions HT revision 1.02 which is the last
non-public revision. Every revision from 1.03 and beyond seems to be
ron minnich wrote:
On Thu, Oct 23, 2008 at 5:30 PM, Corey Osgood [EMAIL PROTECTED] wrote:
I've got a few more questions that I could probably figure out answers to by
testing, but hopefully it's easier just to ask:
* If a device is defined in the dts, but disabled during
phase4_enable_disable
The HT topology is not really directly reflected in PCI config space.
They are obviously linked, but there is not really a way to map a HT
topology of Opteron nodes to a graphical view of config space, it just
doesn't exist. The Opterons just are where they are.
All of the processor PCI devices
Author: myles
Date: 2008-10-24 19:53:03 +0200 (Fri, 24 Oct 2008)
New Revision: 952
Modified:
coreboot-v3/northbridge/amd/k8/common.c
coreboot-v3/northbridge/amd/k8/domain.c
Log:
This patch fixes whitespace so that my next patch is easier to read.
Signed-off-by: Myles Watson [EMAIL
get_fx_devs() was called very few places, and it wasn't needed except the
first call. I combined them.
Signed-off-by: Myles Watson [EMAIL PROTECTED]
Thanks,
Myles
Index: northbridge/amd/k8/common.c
===
---
Carl-Daniel Hailfinger wrote:
Hi,
I'm trying to understand how HT is modeled into PCI space so that I can
propose the right way to handle it in the dts.
Depending on whether I run lspci -t under coreboot or factory BIOS,
different topologies will be displayed. That means looking at lspci is
not
Something I noticed after I sent the patch is that this code (with or
without my patch) depends on the pointers being initialized to zero. Is
that a valid assumption with gcc?
Thanks,
Myles
On Fri, Oct 24, 2008 at 12:08 PM, Myles Watson [EMAIL PROTECTED] wrote:
get_fx_devs() was called very
On Fri, Oct 24, 2008 at 6:10 AM, ron minnich [EMAIL PROTECTED] wrote:
+--18.0(Link n where n in [0,1,2])--+--19.0--(CPU)-(2nd HT link)
| |\|
\--(3rd HT link)
| | | +--19.1
| | | +--19.2
| | |
Why do we call the constructor function of a new device? I can't see where
we ever set it.
Thanks,
Myles
From device/device.c:
memset(dev, 0, sizeof(*dev));
dev-path = *path;
dev-id = *devid;
/* Initialize the back pointers in the link fields. */
for (link = 0; link
Author: myles
Date: 2008-10-24 21:26:34 +0200 (Fri, 24 Oct 2008)
New Revision: 953
Modified:
coreboot-v3/northbridge/amd/k8/pci.c
Log:
This patch fixes whitespace so that a future patch is easier to read.
Signed-off-by: Myles Watson [EMAIL PROTECTED]
Acked-by: Myles Watson [EMAIL PROTECTED]
Ultimately I want a KVM/libvirt guest booting using the
Coreboot/LinuxBIOS code to be able to figure out something unique
about it's host (like hostname) to script inventory management type
stuff (like iClassify).
I was perusing the rombios32.c [1] in the kvm-72+dfsg/bios folder of
the Ubuntu kvm
On 24.10.2008 15:10, ron minnich wrote:
+--18.0(Link n [0,1,2])--+--19.0--(CPU)-(2nd HT link)
| |\ |\--(3rd HT link)
| | |+--19.1
| | |+--19.2
| | |+--19.3
| | |
| |
On 24.10.2008 20:51, yhlu wrote:
On Fri, Oct 24, 2008 at 6:10 AM, ron minnich [EMAIL PROTECTED] wrote:
+--18.0(Link n where n in [0,1,2])--+--19.0--(CPU)-(2nd HT link)
| |\|
\--(3rd HT link)
| | | +--19.1
| | |
On 24.10.2008 19:50, Tom Sylla wrote:
The HT topology is not really directly reflected in PCI config space.
They are obviously linked, but there is not really a way to map a HT
topology of Opteron nodes to a graphical view of config space, it just
doesn't exist. The Opterons just are where
Carl-Daniel Hailfinger wrote:
On 24.10.2008 20:14, Marc Jones wrote:
Carl-Daniel Hailfinger wrote:
Hi,
I'm trying to understand how HT is modeled into PCI space so that I can
propose the right way to handle it in the dts.
Depending on whether I run lspci -t under coreboot or factory BIOS,
I was digging around KVM trunk before leaving the office and it looked like the
old vmport code (couldn't see anyone having used this with open-vm-tools
though) has been scratched for some kind of qemu fw_cfg framework. Trunk does
have a --uuid option, and it looks like with libvirt integration
On 25.10.2008 02:33, Marc Jones wrote:
Carl-Daniel Hailfinger wrote:
On 24.10.2008 20:14, Marc Jones wrote:
Carl-Daniel Hailfinger wrote:
Hi,
I'm trying to understand how HT is modeled into PCI space so that I
can
propose the right way to handle it in the dts.
Depending on whether I run
27 matches
Mail list logo
