Stefan Reinauer [EMAIL PROTECTED] writes:
Segher Boessenkool wrote:
In practice the subsystem vendor IDs are quite arbitrary and definitely not
the same for all PCI devices per mainboard
They aren't even allowed to be the same for all devices on a mainboard:
the subsystem IDs should
Section 6.2.4 of the PCI specification states:
These registers are used to uniquely identify the add-in card or
subsystem
where the PCI device resides. The provide a mechanism for add-in
card vendors to
distinguish their add-in cards from one another even though the
add-in cards may
have the
In practice the subsystem vendor IDs are quite arbitrary and
definitely not the same for all PCI devices per mainboard
They aren't even allowed to be the same for all devices on a
mainboard:
the subsystem IDs should uniquely identify the device, without having
to look at the regular IDs as
Segher Boessenkool wrote:
In any case, I hope we can all agree that certainly nothing in the PCI
spec requires all devices on a mainboard to have the same subsystem
(vendor) ID (some might not even have that register implmented!)
Some, like PCIe bridges, have a BAR at that place. The subsystem
Original Message
From: [EMAIL PROTECTED]
To: coreboot@coreboot.org, [EMAIL PROTECTED],
[EMAIL PROTECTED]
Subject: RE: how could i get the hexadecimal content in memory at
address -FFF0?
Date: Mon, 14 Jul 2008 16:02:42 +0800
I know from cpu manual that when machine starts,
Segher Boessenkool [EMAIL PROTECTED] writes:
In practice the subsystem vendor IDs are quite arbitrary and definitely not
the same for all PCI devices per mainboard
They aren't even allowed to be the same for all devices on a mainboard:
the subsystem IDs should uniquely identify the device,
hi all,
currently i am working as developer on linux plateform in a mnc in india.
recently i have been asked to install coreboot in our machine and make
necessary test.
i have navigated the coreboot.org site but do not find any satisfactory
document to start with. i have not enough knowledge of
2008/7/16, Kevin O'Connor [EMAIL PROTECTED]:
and added this at the end of post_coreboot() function:
asm(
movl %esi, %esp\n
retl
);
That's dangerous because the compiler might use %esi in the
post_coreboot() function. If you really want to do this, you should
move
Here is a dump for the wiki:
superiotool r3361
Found NSC PC87427 (sid=0xf2, srid=0x04) at 0x2e
Register dump:
idx 10 12 13 1d 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
val 00 00 00 00 f2 19 a0 40 20 00 02 04 00 14 00 04 12 00 00 00
def 00 00 00 00 f2 11 a0 MM MM MM 02 NA 00 MM 00 00
Segher Boessenkool [EMAIL PROTECTED] writes:
In any case, I hope we can all agree that certainly nothing in the PCI
spec requires all devices on a mainboard to have the same subsystem
(vendor) ID (some might not even have that register implmented!)
Yes it is an optional field.
Since
On Fri, Jul 11, 2008 at 12:51 PM, Kevin O'Connor [EMAIL PROTECTED] wrote:
On Fri, Jul 11, 2008 at 07:58:35PM +0200, Carl-Daniel Hailfinger wrote:
Can seabios somehow complement x86emu as a way to let certain
problematic VBIOS images run?
If you mean run seabios under x86emu - I'm not sure.
Myles Watson wrote:
On Fri, Jul 11, 2008 at 02:51:12PM -0400, Kevin O'Connor wrote:
If you mean using seabios to implement the option rom scan
..
maybe it would work.
Yes, I think it would work very well.
SeaBIOS has no way of knowing where onboard ROMs
On 16/07/08 12:43 -0600, Myles Watson wrote:
On Fri, Jul 11, 2008 at 12:51 PM, Kevin O'Connor [EMAIL PROTECTED] wrote:
On Fri, Jul 11, 2008 at 07:58:35PM +0200, Carl-Daniel Hailfinger wrote:
Can seabios somehow complement x86emu as a way to let certain
problematic VBIOS images run?
If
Kevin,
I'm still groping around in the dark here, but...
When I leave the mouse enabled, I get no handle_74 messages, even when I
wiggle the mouse. I get handle_09 (keyboard) messages, and it fails earlier
when I press lots of keys. When that happens I get a buffer full in inhibit
instead of
Author: mjones
Date: 2008-07-16 23:09:31 +0200 (Wed, 16 Jul 2008)
New Revision: 3423
Modified:
trunk/coreboot-v2/src/northbridge/amd/amdht/h3ffeat.h
trunk/coreboot-v2/src/northbridge/amd/amdht/h3finit.c
trunk/coreboot-v2/src/northbridge/amd/amdht/h3ncmn.c
Log:
Clean up comments,
Some HT cleanup. Shouldn't be anything major.
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
Clean up AMD FAM10 HT variable initialization. The structure init is cleaner,
avoid compiler warnings,
and matches the AMD
This fixes a non-coherent link speed setting.
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
Add manual HT BUID fixup to detect previously set BUIDs in early init. This
fixes the coherent link running at default
On 11.07.2008 20:51, Kevin O'Connor wrote:
On Fri, Jul 11, 2008 at 07:58:35PM +0200, Carl-Daniel Hailfinger wrote:
Can seabios somehow complement x86emu as a way to let certain
problematic VBIOS images run?
If you mean run seabios under x86emu - I'm not sure. Seabios
currently
On Wed, Jul 16, 2008 at 04:06:52PM -0600, Marc Jones wrote:
Clean up AMD FAM10 HT variable initialization. The structure init
is cleaner, avoid compiler warnings, and matches the AMD example
code more closely.
Signed-off-by: Marc Jones [EMAIL PROTECTED]
It bothers me a bit that there are so
On 17.07.2008 00:00, Marc Jones wrote:
GART table walk enable set.
Add Fam10 Gart table walk enable recomended by the BKDG.
Signed-off-by: Marc Jones [EMAIL PROTECTED]
Index: coreboot-v2/src/cpu/amd/model_10xxx/defaults.h
===
On 17.07.2008 00:10, Marc Jones wrote:
This fixes a non-coherent link speed setting.
Add manual HT BUID fixup to detect previously set BUIDs in early init. This
fixes the coherent link running at default speed.
Fix HT event notify to output useful information.
Signed-off-by: Marc Jones
On 17/07/08 01:30 +0200, Carl-Daniel Hailfinger wrote:
On 17.07.2008 00:06, Marc Jones wrote:
Some HT cleanup. Shouldn't be anything major.
Clean up AMD FAM10 HT variable initialization. The structure init is
cleaner,
avoid compiler warnings,
and matches the AMD example code more
On 16.07.2008 19:35, Segher Boessenkool wrote:
When the field is implemented the question
is what should it be.
Yes.
The wording is pretty clear elsewhere that the subsystem vendor id
should equal your normal pci vendor id of the manufacturer.
The ID of the manufacturer of the subsystem,
Carl-Daniel Hailfinger wrote:
On 17.07.2008 00:06, Marc Jones wrote:
Some HT cleanup. Shouldn't be anything major.
Clean up AMD FAM10 HT variable initialization. The structure init is cleaner,
avoid compiler warnings,
and matches the AMD example code more closely.
Signed-off-by: Marc Jones
On 17.07.2008 01:48, Marc Jones wrote:
Carl-Daniel Hailfinger wrote:
My Fam 10h BKDG 31116 Rev 3.06 - March 26, 2008 does not contain that
recommendation or I'm misreading it. Can you please point to the page
where this is mentioned?
Thanks.
Huh, You are correct. There is no
Carl-Daniel Hailfinger wrote:
On 17.07.2008 00:10, Marc Jones wrote:
This fixes a non-coherent link speed setting.
Add manual HT BUID fixup to detect previously set BUIDs in early init. This
fixes the coherent link running at default speed.
Fix HT event notify to output useful information.
On 16.07.2008 20:12, Eric W. Biederman wrote:
Segher Boessenkool [EMAIL PROTECTED] writes:
I just figure the default should be the current behavior.
Remind me, what _is_ the current behaviour?
Have one default SSVID/SSDID per motherboard, if that default
value is not set I
On Wed, Jul 16, 2008 at 08:57:15PM +0200, Stefan Reinauer wrote:
Myles Watson wrote:
SeaBIOS has no way of knowing where onboard ROMs are stored. That
seems like a problem that needs to be solved.
Finding the option roms is easy - they are located between 0xc and
0xe and are 2KiB
Kevin,
-Original Message-
From: Kevin O'Connor [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 16, 2008 7:20 PM
To: Stefan Reinauer
Cc: Myles Watson; Jordan Crouse; Carl-Daniel Hailfinger; Coreboot
Subject: Re: [coreboot] SeaBIOS debug output
On Wed, Jul 16, 2008 at 08:57:15PM
On Wed, Jul 16, 2008 at 12:43:31PM -0600, Myles Watson wrote:
I for one don't understand what needs to be done in coreboot after the
option ROM scans. It seems like it would help us discuss the possible
solutions if we could enumerate that.
I agree.
It seems like Coreboot can
load whatever
Hi Myles,
On Wed, Jul 16, 2008 at 07:29:29PM -0600, Myles Watson wrote:
Finding the option roms is easy - they are located between 0xc and
0xe and are 2KiB aligned.
That can be true after Coreboot copies them there. Devices which have
option ROMs on the card are located somewhere
2008/7/16 Stefan Reinauer [EMAIL PROTECTED]:
Zhang Rui wrote:
Hello Kevin,
I can use SeaBIOS to initialize vga and return to coreboot now.
But when I returned to coreboot and call int19, nothing happens.
It can boot correctly when call int19 in SeaBIOS.
Maybe it has something to do with
On Wed, Jul 16, 2008 at 09:36:16PM -0400, Kevin O'Connor wrote:
stomping on the second payload.
Could be avoided by having seabios load payloads and maybe even ROMs
from the larball that is the flash chip.
//Peter
--
coreboot mailing list
coreboot@coreboot.org
Patch attached.
//Peter
flashrom: Winbond W39V040C and MSI K8T Neo2-F
W39V040C does standard JEDEC commands except chip erase so add a small driver.
probe_w39v040c() prints the block lock pin status when a chip is found.
The Neo2 board enable matches on 8237-internal IDE and onboard NIC PCI
Hi,
On Wed, Jul 16, 2008 at 03:07:30PM -0600, Myles Watson wrote:
Kevin,
I'm still groping around in the dark here, but...
I wish I could help you more. Unfortunately I'm not an expert on the
PS/2 port hardware. I can say it seems to work fine on the epia-m,
but who knows.
When I leave
2008/7/16 Kevin O'Connor [EMAIL PROTECTED]:
On Tue, Jul 15, 2008 at 11:21:38PM +0800, Zhang Rui wrote:
But when I returned to coreboot and call int19, nothing happens.
It can boot correctly when call int19 in SeaBIOS.
Maybe it has something to do with the stack?
How can I call the interrupt
On Thu, Jul 17, 2008 at 09:58:59AM +0800, Zhang Rui wrote:
I wrote a function in SeaBIOS:
void VISIBLE32 boot_coreboot()
[...]
and then use run_address() to execute this boot_coreboot() function in
coreboot.
If you want to return to seabios to invoke int19, then you'll need to
load
Hi Myles,
On Wed, Jul 16, 2008 at 01:49:09PM -0600, Myles Watson wrote:
* The mouse code may not be that flexible. You could try disabling
CONFIG_PS2_MOUSE and see if that helps.
It gets farther. It loads drivers off the CD, then blue screens with
STOP: 0x007B (0xF78D2524,
On 17.07.2008 03:53, Peter Stuge wrote:
On Wed, Jul 16, 2008 at 09:36:16PM -0400, Kevin O'Connor wrote:
stomping on the second payload.
Could be avoided by having seabios load payloads and maybe even ROMs
from the larball that is the flash chip.
The stomping problem is still
You guys will have to forgive my tardyness. I barely keep up with my
mail load at OLPC so the coreboot list tends to get neglected. I'm a
good month or 2 behind on reading the list.
As OLPC's EC guy I feel I should probably comment on this thread. :)
OpenEC progress: OpenEC has stalled
40 matches
Mail list logo
