On Fri, 22 Oct 2004, Eric W. Biederman wrote:
Ron that joke is getting real old. Especially when I am working hard to
get all of the pieces sorted out.
sorry! your efforts are always appreciated.
If time were not a finite resource I could do more...
Hmm Ron do you know if any of
'
Subject: RE: FYI: Merge in progress...S2735
Eric,
About S2735, in auto.c
How to change
#include cpu/p6/apic_timer.c
Amd version is
#include cpu/amd/model_fxx/apic_timer.c
I can not find other apic_timer.c in src/cpu
Regards
YH
___
Linuxbios mailing
Eric,
I copy some line from amd k8 to intel e7501 northbridge.c.
Can you check that for me?
Regards
YH
-Original Message-
From: YhLu
Sent: Friday, October 22, 2004 11:53 AM
To: [EMAIL PROTECTED]; Ronald G. Minnich
Cc: Li-Ta Lo; 'LinuxBIOS'
Subject: RE: FYI: Merge in progress...S2735
YhLu [EMAIL PROTECTED] writes:
Eric,
I copy some line from amd k8 to intel e7501 northbridge.c.
Can you check that for me?
I have just checked it and cleaned it up.
It makes a much simpler example than the k8 northbridge.
Eric
___
Linuxbios
On Thu, 2004-10-21 at 12:00, Eric W. Biederman wrote:
At this point we should be able to look at the device tree and
see if we need to use and io range register or the RdRam WrDram bits.
Are you talking somthing in my mind ? I hope in the mtrr.c for K8
instead of hack with the mem_map we
: YhLu; 'Ronald G. Minnich'; 'LinuxBIOS'
Subject: Re: FYI: Merge in progress...
On Thu, 2004-10-21 at 12:00, Eric W. Biederman wrote:
At this point we should be able to look at the device tree and
see if we need to use and io range register or the RdRam WrDram bits.
Are you talking somthing in my
: Merge in progress...
On Thu, 2004-10-21 at 12:00, Eric W. Biederman wrote:
At this point we should be able to look at the device tree and
see if we need to use and io range register or the RdRam WrDram bits.
Are you talking somthing in my mind ? I hope in the mtrr.c for K8
instead
Li-Ta Lo [EMAIL PROTECTED] writes:
On Thu, 2004-10-21 at 12:00, Eric W. Biederman wrote:
At this point we should be able to look at the device tree and
see if we need to use and io range register or the RdRam WrDram bits.
Are you talking somthing in my mind ? I hope in the mtrr.c for
Li-Ta Lo [EMAIL PROTECTED] writes:
On Thu, 2004-10-21 at 12:00, Eric W. Biederman wrote:
At this point we should be able to look at the device tree and
see if we need to use and io range register or the RdRam WrDram bits.
Are you talking somthing in my mind ? I hope in the mtrr.c for
On Thu, 21 Oct 2004, Eric W. Biederman wrote:
It looks like it would be profitable for me to look through
the old cpu directories and see what code changes I have
missed.
and, ah, cough, commit more often.
Be more committed :-)
ron
___
Done.
-Original Message-
From: Stefan Reinauer [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 20, 2004 5:58 AM
To: YhLu
Cc: [EMAIL PROTECTED]; Li-Ta Lo; 'Ronald G. Minnich'; 'LinuxBIOS'
Subject: Re: FYI: Merge in progress...
* YhLu [EMAIL PROTECTED] [041020 07:13]:
Just check
#endif
548c553
print_debug(done\r\n);
---
print_spew(done\r\n);
-Original Message-
From: YhLu
Sent: Wednesday, October 20, 2004 11:00 AM
To: 'Stefan Reinauer'
Cc: [EMAIL PROTECTED]; 'Li-Ta Lo'; 'Ronald G. Minnich'; 'LinuxBIOS'
Subject: RE: FYI: Merge in progress...
Done
YhLu [EMAIL PROTECTED] writes:
Why enable cache in amd_early_mtrr_init?
Usually that is a speed up. I think all I changed was using the C implementation.
Previously the assembly was called from Config.lb.
That causes CPU sleep 5s again.
That is peculiar.
After get rid of that, the new
, 2004 12:50 PM
To: YhLu
Cc: Li-Ta Lo; 'Ronald G. Minnich'; 'LinuxBIOS'
Subject: Re: FYI: Merge in progress...
YhLu [EMAIL PROTECTED] writes:
Why enable cache in amd_early_mtrr_init?
Usually that is a speed up. I think all I changed was using the C
implementation.
Previously the assembly
YhLu [EMAIL PROTECTED] writes:
Comment out disable_cache and enabe_cache in amd_early_mtrr_init you will
get 5s speed up.
I checked old amd_early_mtrr.inc, it seems it only has enable cache, but no
wbinvd.
Right. At the time I had no clue invalidates were a problem.
I have just removed
: Li-Ta Lo; 'Ronald G. Minnich'; 'LinuxBIOS'
Subject: Re: FYI: Merge in progress...
YhLu [EMAIL PROTECTED] writes:
Comment out disable_cache and enabe_cache in amd_early_mtrr_init you will
get 5s speed up.
I checked old amd_early_mtrr.inc, it seems it only has enable cache, but
no
wbinvd
Amd_early_mtrr.c
#ifndef AMD_EARLYMTRR_C
#define AMD_EARLYMTRR_C
#include cpu/x86/mtrr.h
#include cpu/amd/mtrr.h
#include cpu/x86/mtrr/earlymtrr.c
static void amd_early_mtrr_init(void)
{
static const unsigned long mtrr_msrs[] = {
/* fixed mtrr */
0x250,
* YhLu [EMAIL PROTECTED] [041020 20:20]:
I want to do some change to coherent_ht.c, otherwise s2885 can not be
compiled under Loglevel = 8
print_debug_hex8(result.cpus);
print_debug( nodes initialized.\r\n);
---
print_spew_hex8(result.cpus);
print_spew( nodes
'
Subject: Re: FYI: Merge in progress...
* YhLu [EMAIL PROTECTED] [041020 20:20]:
I want to do some change to coherent_ht.c, otherwise s2885 can not be
compiled under Loglevel = 8
print_debug_hex8(result.cpus);
print_debug( nodes initialized.\r\n);
---
print_spew_hex8
On Wed, 20 Oct 2004, YhLu wrote:
If the romcc support the function instead using of all inline. It will be
very small.
that's why we need cache-as-ram :-)
ron
___
Linuxbios mailing list
[EMAIL PROTECTED]
On Wed, 20 Oct 2004, Stefan Reinauer wrote:
Time to look at CAR again? ;-) (don't hit me) - Last state was that it
worked fine on UP systems but did not on SMP. Did anybody analyze this
with a HDT?
Ollie is discussing it with some people.
ron
___
On Wed, 2004-10-20 at 16:35, Ronald G. Minnich wrote:
On Wed, 20 Oct 2004, Stefan Reinauer wrote:
Time to look at CAR again? ;-) (don't hit me) - Last state was that it
worked fine on UP systems but did not on SMP. Did anybody analyze this
with a HDT?
Ollie is discussing it with some
Li-Ta Lo wrote:
The HDT I used can't do that. Actually, the HDT lost track of everything
after the ht_reset in auto.c.
We purchased a hardware debugger from American Arium but we never have
time to setup.
Dude, send that puppy to me then. I'll use it. *grin*
--
Richard A. Smith
YhLu [EMAIL PROTECTED] writes:
Amd_early_mtrr.c
Ok. I will agree that disable_cache in amd_early_mtrr is overkill
and remove that. Since the wbinvd seems to be necessary in the
general disable_cache case.
I am leery about not reusing code between the various versions
of mtrr setup because
Stefan Reinauer [EMAIL PROTECTED] writes:
* YhLu [EMAIL PROTECTED] [041020 20:20]:
I want to do some change to coherent_ht.c, otherwise s2885 can not be
compiled under Loglevel = 8
print_debug_hex8(result.cpus);
print_debug( nodes initialized.\r\n);
---
Ronald G. Minnich wrote:
Try the port for the digitallogic adl855pc or whatever it is. modulo
Intel's unwillingness to tell us how the chips actually work I think the
structure is close to right.
The Arima HDAMA is still the gold standard, but it is really way more
complex than a simple 440bx
On Tue, 19 Oct 2004, Richard Smith wrote:
I've been going over the various ports trying to get a feel for whats needed.
What I think I may do is take a stab at creating a generic port. Some
fictious motherboard that has the minimum structure necessary as a search and
replace starting
Ronald G. Minnich wrote:
replace starting point. Does that sound useful? If so what should I name
it?
I'm not sure it's less work than a full one, although you could set up
'user mode linuxbios' for educational purposes.
I'm not doing it because its less work. *grin*
I'm thinking about those
On Tue, 19 Oct 2004, Richard Smith wrote:
I've been going over the various ports trying to get a feel for whats
needed. What I think I may do is take a stab at creating a generic
port. Some fictious motherboard that has the minimum structure
necessary as a search and replace starting point.
* Richard Smith [EMAIL PROTECTED] [041019 18:30]:
I'm not doing it because its less work. *grin*
I'm thinking about those who come after me. With the purpose of
creating a well documented starting structure at the same time teaching
me how v2 goes together.
Then next guy then has a
* Ronald G. Minnich [EMAIL PROTECTED] [041019 17:55]:
I've been going over the various ports trying to get a feel for
whats needed. What I think I may do is take a stab at creating a
generic port. Some fictious motherboard that has the minimum
structure necessary as a search and replace
* Adam Sulmicki [EMAIL PROTECTED] [041019 19:28]:
it has a name. the name is bochs.
more seriously if we could do it one way and move bochs bios to real
hardware, we could go other way and move LB to bochs hardware (which is
something like intel 440BX IIRC).
The emulation/qemu-i386 target
: Merge in progress...
YhLu [EMAIL PROTECTED] writes:
Get more worse.
Ouch. If you can boot the board in linux please give me an lspci -vvv
I don't have enough information to even guess what is going on.
I need to know what the size and limit of the resources are,
so I can walk through the code
Stefan Reinauer wrote:
actually a real problem. I have not been able without hacks to find out
the memory layout in qemu except the old read,write,read method of
scanning through memory. Emulating enough of a northbridge would allow
holes in memory and such, too.
Otoh, bochs and qemu (which per
: RE: FYI: Merge in progress...
Eric,
The PCI_DOMAIN has two mem resource, root calculate the mem base correctly.
But PCI_DOMAIN get the wrong base.
root mem limit=0x00febf, size=0x002270, align=28, base=0x00d000
Allocating VGA resource PCI: 03:00.0
PCI_DOMAIN: 00 - [0x001000
, 2004 12:31 PM
To: YhLu; [EMAIL PROTECTED]
Cc: Ronald G. Minnich; Li-Ta Lo; 'LinuxBIOS'
Subject: RE: FYI: Merge in progress...
strange size for prefmem of PCI_DOMAIN
root mem limit=0x00febf, size=0x002270, align=28, base=0x00d000
Allocating VGA resource PCI: 03:00.0
base1: 0xf800
-
From: YhLu
Sent: Tuesday, October 19, 2004 12:31 PM
To: YhLu; [EMAIL PROTECTED]
Cc: Ronald G. Minnich; Li-Ta Lo; 'LinuxBIOS'
Subject: RE: FYI: Merge in progress...
strange size for prefmem of PCI_DOMAIN
root mem limit=0x00febf, size=0x002270, align=28, base=0x00d000
I will try s2885.
-Original Message-
From: Li-Ta Lo [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 19, 2004 1:04 PM
To: YhLu
Cc: '[EMAIL PROTECTED]'; 'Ronald G. Minnich'; 'LinuxBIOS'
Subject: RE: FYI: Merge in progress...
On Tue, 2004-10-19 at 14:02, YhLu wrote:
YhLu,
Which
Message-
From: Li-Ta Lo [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 19, 2004 1:04 PM
To: YhLu
Cc: '[EMAIL PROTECTED]'; 'Ronald G. Minnich'; 'LinuxBIOS'
Subject: RE: FYI: Merge in progress...
On Tue, 2004-10-19 at 14:02, YhLu wrote:
YhLu,
Which mainboard are you working on ? Is it some board
Eric,
The mail server bounce back my email
Regards
Yinghai Lu
-Original Message-
From: YhLu
Sent: Tuesday, October 19, 2004 2:00 PM
To: 'Li-Ta Lo'
Cc: '[EMAIL PROTECTED]'; 'Ronald G. Minnich'; 'LinuxBIOS'
Subject: RE: FYI: Merge in progress...
Eric,
after comment out something
YhLu [EMAIL PROTECTED] writes:
Find out the problem, should be typo error.
/* Now place the memory as high up as it will go */
mem2-base = resource_max(mem2);
mem1-limit = mem2-base - 1;
mem1-base = resource_max(mem2);
--
PROTECTED]'; 'Ronald G. Minnich'; 'LinuxBIOS'
Subject: Re: FYI: Merge in progress...
YhLu [EMAIL PROTECTED] writes:
Find out the problem, should be typo error.
/* Now place the memory as high up as it will go */
mem2-base = resource_max(mem2
Just check in Tyan update to support new config.
CVS: --
CVS: Enter Log. Lines beginning with `CVS:' are removed automatically
CVS:
CVS: Committing in .
CVS:
CVS: Modified Files:
CVS:src/include/device/device.h
Yeah, well, how about this: here's how target config files look now:
# Sample config file for Motorola Sandpoint X3 Demo Board with
# the Arima HDAMA
# This will make a target directory of ./hdama
target hdama
mainboard arima/hdama
# Arima hdama
romimage normal
option
I ought to mention:
last week's efforts which result in this week's improvements were a joint
project of Eric, Tom, and Jason (LNXI) and Ollie and me (LANL).
So thanks to them if you like what happened :-)
ron
___
Linuxbios mailing list
[EMAIL
On Sat, 2004-10-16 at 11:03, Yinghai Lu wrote:
So chip tree is merged into device tree.
I'm eager to convert my MB to use that.
Is there any problem for different inherent links in second K8?
I am a little bit confused with that too. I think now the 'link' keyword
is not used anymore,
Werid, it should look for 1:0.0 instead of 1:1.0 before unit id is updated
in hypertransport_scan_chain.
YH
-Original Message-
From: YhLu
Sent: Monday, October 18, 2004 10:36 AM
To: [EMAIL PROTECTED]; Li-Ta Lo
Cc: 'Ronald G. Minnich'; 'LinuxBIOS'
Subject: RE: FYI: Merge in progress
Li-Ta Lo [EMAIL PROTECTED] writes:
I think YHLu's question is that the CPU0 and CPU1 are connected by LDT1
one each side. So how do we say
northbridge_18_0.link[0].something = northbridge_19_0
and
northbridge_19_0.link[0].something = northbridge_18_0
in the config file ?
Or
On Mon, 2004-10-18 at 13:08, Eric W. Biederman wrote:
An interesting static is that static.c compiles to 35K but compresses
to about 500 bytes. :)
This is exactly why I was proposing this change. We also got rid of
a lot of static - dynamice code.
Ollie
On Mon, 18 Oct 2004, Li-Ta Lo wrote:
This is exactly why I was proposing this change. We also got rid of
a lot of static - dynamice code.
even cooler: there is no static code structure any more. What the config
tool creates is a statically allocated set of device structs. The
enumeration
:[EMAIL PROTECTED]
Sent: Monday, October 18, 2004 1:36 PM
To: Li-Ta Lo
Cc: Eric W. Biederman; YhLu; 'LinuxBIOS'
Subject: Re: FYI: Merge in progress...
On Mon, 18 Oct 2004, Li-Ta Lo wrote:
This is exactly why I was proposing this change. We also got rid of
a lot of static - dynamice code.
even
On Mon, 18 Oct 2004, YhLu wrote:
It should config.g bug, there is some un consistent.
For dev33 and it sibling
should be .bus = _dev4.link[2],
config.g bug.
Basically when we wrote that code last week we always set to .link[0].
So we have to fix it.
My brain is too tired to try that
On Mon, 2004-10-18 at 14:54, Ronald G. Minnich wrote:
On Mon, 18 Oct 2004, YhLu wrote:
It should config.g bug, there is some un consistent.
For dev33 and it sibling
should be .bus = _dev4.link[2],
config.g bug.
Basically when we wrote that code last week we always set to .link[0].
YhLu [EMAIL PROTECTED] writes:
It should config.g bug, there is some un consistent.
It could be. I should have fixed this Saturday, but...
Looking Hmm...
For dev33 and it sibling
should be .bus = _dev4.link[2],
instead of
.bus = _dev4.link[0],
Good catch. We do not yet have the
);
return;
}
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Monday, October 18, 2004 2:22 PM
To: YhLu
Cc: Ronald G. Minnich; Li-Ta Lo; 'LinuxBIOS'
Subject: Re: FYI: Merge in progress...
YhLu [EMAIL PROTECTED] writes:
It should
- [0x00fe50 - 0x00fe6f] mem node 1 link 0
-Original Message-
From: YhLu
Sent: Monday, October 18, 2004 2:29 PM
To: '[EMAIL PROTECTED]'
Cc: Ronald G. Minnich; Li-Ta Lo; 'LinuxBIOS'
Subject: RE: FYI: Merge in progress...
self.firstparentdevicelink()
How about IORESOURCE_FIXED
On Mon, 18 Oct 2004, YhLu wrote:
There is overlapping between prefmem and mem.
Dr. Lu, we could not ask for a better tester than you!
Thanks for your patience ... I realize we did break things a bit last
week!
Thanks
ron
___
Linuxbios mailing
-
From: Ronald G. Minnich [mailto:[EMAIL PROTECTED]
Sent: Monday, October 18, 2004 4:00 PM
To: YhLu
Cc: [EMAIL PROTECTED]; Li-Ta Lo; 'LinuxBIOS'
Subject: RE: FYI: Merge in progress...
On Mon, 18 Oct 2004, YhLu wrote:
There is overlapping between prefmem and mem.
Dr. Lu, we could not ask
On Mon, 18 Oct 2004, Eric W. Biederman wrote:
Ok the fix looks easy, committed.
well, eric, you are rewarding my laziness. :-)
ron
___
Linuxbios mailing list
[EMAIL PROTECTED]
http://www.clustermatic.org/mailman/listinfo/linuxbios
Richard Smith [EMAIL PROTECTED] writes:
I've been reading this new v2 stuff with some interest. I may be able to finde
time to move the 440bx stuff over into v2. We've hired a big gun PCI guru to
help find our problems that have been keeping me from getting video to work.
While he's
Ronald G. Minnich [EMAIL PROTECTED] writes:
On Mon, 18 Oct 2004, Eric W. Biederman wrote:
Ok the fix looks easy, committed.
well, eric, you are rewarding my laziness. :-)
Then this would be a bad time to mention Thayne looked at the supermon
kernel code and ran away screaming?
Eric
The pci_device is using PCI 64, how to disable it and let it use 32 bit
premem?
Regards
YH
-Original Message-
From: YhLu
Sent: Monday, October 18, 2004 5:14 PM
To: [EMAIL PROTECTED]
Cc: Ronald G. Minnich; Li-Ta Lo; 'LinuxBIOS'
Subject: RE: FYI: Merge in progress...
I'm using Mallanox
Eric W. Biederman wrote:
Hmm. I suspect your configuration would look something like:
chip northbridge/intel/440bx
device pci_domain 0 on
Ok so I guess I'll start asking questions. pci_domain this is the
top level I guess? Where are all the different device types listed at?
The use
YhLu [EMAIL PROTECTED] writes:
The pci_device is using PCI 64, how to disable it and let it use 32 bit
premem?
I still need to make it an option so we can boot 32bit kernels.
All you should need to do is to set the resource limits to 4G.
See below for the function to modify to set it.
The
Get more worse.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Monday, October 18, 2004 7:04 PM
To: YhLu
Cc: Ronald G. Minnich; Li-Ta Lo; 'LinuxBIOS'
Subject: Re: FYI: Merge in progress...
YhLu [EMAIL PROTECTED] writes:
The pci_device is using PCI 64, how
YhLu [EMAIL PROTECTED] writes:
Get more worse.
Ouch. If you can boot the board in linux please give me an lspci -vvv
I don't have enough information to even guess what is going on.
I need to know what the size and limit of the resources are,
so I can walk through the code and see what it
The ARIMA HDAMA now boots, and everything looks like it is working properly.
Converting everything else still remains but we now have a working example
to look at.
We are down to one device tree instead of two.
And hardwaremain has been reduced to:
void hardwaremain(int boot_complete)
{
, 2004 2:20 AM
To: Ronald G. Minnich
Cc: YhLu; LinuxBIOS
Subject: Re: FYI: Merge in progress...
The ARIMA HDAMA now boots, and everything looks like it is working properly.
Converting everything else still remains but we now have a working example
to look at.
We are down to one device tree instead
Yinghai Lu [EMAIL PROTECTED] writes:
So chip tree is merged into device tree.
Yep.
I'm eager to convert my MB to use that.
Is there any problem for different inherent links in second K8?
Not in theory. In practice I think this is the one case that has not yet
been fixed in config.g for
'; 'LinuxBIOS'
Subject: Re: FYI: Merge in progress...
[EMAIL PROTECTED] (Eric W. Biederman) writes:
Yinghai Lu [EMAIL PROTECTED] writes:
So chip tree is merged into device tree.
Yep.
I'm eager to convert my MB to use that.
Is there any problem for different inherent links in second K8
[EMAIL PROTECTED] (Eric W. Biederman) writes:
Yinghai Lu [EMAIL PROTECTED] writes:
So chip tree is merged into device tree.
Yep.
I'm eager to convert my MB to use that.
Is there any problem for different inherent links in second K8?
Not anymore. I just worked through that case
on #
northbridge
print HI MOM!\n
end
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ronald G. Minnich
Sent: Thursday, October 14, 2004 1:13 PM
To: Eric W. Biederman
Cc: LinuxBIOS
Subject: Re: FYI: Merge in progress...
On Thu, 14 Oct 2004
On Fri, 15 Oct 2004, Yinghai Lu wrote:
Also after buildtarget, make failed.
don't worry, it won't work for a while.
ron
___
Linuxbios mailing list
[EMAIL PROTECTED]
http://www.clustermatic.org/mailman/listinfo/linuxbios
YhLu [EMAIL PROTECTED] writes:
Config.g still miss to add
crt0.S: $(CRT0)
cp $ $@
linuxbios.rom: linuxbios.strip buildrom
./buildrom $ $@ $(PAYLOAD) $(ROM_IMAGE_SIZE) $(ROM_SECTION_SIZE)
to the fallback/Makfile
Yep. That is now fixed.
I am working through the changes
Ron and I are in the middle of a major merge. So the CVS tree is likely to be in flux
for a bit.
Eric
___
Linuxbios mailing list
[EMAIL PROTECTED]
http://www.clustermatic.org/mailman/listinfo/linuxbios
On Thu, 14 Oct 2004, Eric W. Biederman wrote:
Ron and I are in the middle of a major merge. So the CVS tree is likely
to be in flux for a bit.
Eric, you are so polite.
Ollie and I are at LNXI in Utah visting Eric, and Jason Schildt of LNXI
just joined on as a new committer (HI JASON :-).
76 matches
Mail list logo
