From yinghailu at gmail.com  Fri Jul  1 00:55:58 2005
From: yinghailu at gmail.com (yhlu)
Date: Thu, 30 Jun 2005 15:55:58 -0700
Subject: [LinuxBIOS] Re: floating irq_table
In-Reply-To: <Pine.LNX.4.58.0506292143040.15717@enigma.lanl.gov>
References: <2ea3fae105062919015d66a219@mail.gmail.com>
	<Pine.LNX.4.58.0506292143040.15717@enigma.lanl.gov>
Message-ID: <2ea3fae10506301555a2e4566@mail.gmail.com>

just committed the write_pirq_routing_table for s2882 and s2895.

for s2882 also move pci_assign_irq from mptable to irq_table.c

other x86 irq_table.c all added

unsigned long write_pirq_routing_table(unsigned long addr)
{
        return copy_pirq_routing_table(addr);
}

and table.c will call write_pirq_routing_table instead of
copy_pirq_routing_table.

YH

On 6/29/05, Ronald G. Minnich <rminnich at lanl.gov> wrote:
> 
> 
> On Wed, 29 Jun 2005, yhlu wrote:
> 
> > 2. create irq_table while creating the mptable...
> 
> this is better.
> 
> ron
>



From okajima at digitalinfra.co.jp  Fri Jul  1 01:15:02 2005
From: okajima at digitalinfra.co.jp (Jun OKAJIMA)
Date: Fri, 01 Jul 2005 08:15:02 +0900
Subject: [LinuxBIOS] EPIA/EPIA-M Status?
Message-ID: <200506302315.AA00164@bbb-jz5c7z9hn9y.digitalinfra.co.jp>


Hello guys and I hope you tell me what is going on.
It worked finally?
The snapshot version still has compile error.

                --- Okajima, Jun. Tokyo, Japan.



From rminnich at lanl.gov  Fri Jul  1 01:20:27 2005
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Thu, 30 Jun 2005 17:20:27 -0600 (MDT)
Subject: [LinuxBIOS] EPIA/EPIA-M Status?
In-Reply-To: <200506302315.AA00164@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
References: <200506302315.AA00164@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
Message-ID: <Pine.LNX.4.58.0506301720130.17913@enigma.lanl.gov>

I guess we'll look at this next week. 

ron




From sc at drccomputer.com  Fri Jul  1 06:11:38 2005
From: sc at drccomputer.com (Steve Casselman)
Date: Thu, 30 Jun 2005 21:11:38 -0700 (PDT)
Subject: [LinuxBIOS] Simple complie question
Message-ID: <20050701041138.11011.qmail@web304.biz.mail.mud.yahoo.com>

I'm adding print_debug statements to tyan/s2891 and
now I get some code overlap messages

/usr/bin/ld: section .reset [00000000fffffff0 ->
00000000ffffffff] overlaps section .rom
[00000000ffff6770 -> 000000010000014f]
/usr/bin/ld: section .id [00000000ffffff69 ->
00000000ffffff7f] overlaps section .rom
[00000000ffff6770 -> 000000010000014f]
/usr/bin/ld: section .romstrap [00000000ffffffa0 ->
00000000ffffffef] overlaps section .rom
[00000000ffff6770 -> 000000010000014f]

I'm not quite sure where this comes from. I've
compiled this many times and it works great. Where
(options config) are the setting for this? 

A document pointer or a quick explaination would be
great

Thanks

Steve



From steve at digidescorp.com  Fri Jul  1 06:36:45 2005
From: steve at digidescorp.com (Steve Magnani)
Date: Thu, 30 Jun 2005 23:36:45 -0500
Subject: [LinuxBIOS] Local APIC IDs for dual Xeons
In-Reply-To: <Pine.LNX.4.58.0506300656100.17007@enigma.lanl.gov>
References: <WorldClient-F200506292152.AA52150020@digidescorp.com>
	<Pine.LNX.4.58.0506300656100.17007@enigma.lanl.gov>
Message-ID: <WorldClient-F200506302336.AA36450024@digidescorp.com>

I haven't completely unraveled this yet, but I'm pretty sure that one
reason my second Xeon chip won't start is due to a nested spin_lock within
the 2nd chip's execution path.

Since my board is similar to the Tyan s2735 I use the same setting,
CONFIG_MAX_CPUS = 4. If I am tracing the code correctly, I believe that
results in the following sequence of calls to bring up the CPUs. The "CPU
#x" header shows which logical CPU executes each set of calls.

CPU #0 (APIC ID 0, Xeon Chip 0, Logical processor 0):
northbridge.c:      cpu_bus_init
lapic_cpu_init.c:    initialize_cpus
cpu.c:                cpu_initialize
model_f2x_init.c:      model_f2x_init
intel_sibling.c:        intel_sibling_init
lapic_cpu_init.c:        start_cpu (APIC ID 1)
                          spin_lock(&start_cpu_lock)
lapic_cpu_init.c:         lapic_start_cpu
                          spin_unlock(&start_cpu_lock)
lapic_cpu_init.c:     initialize_other_cpus
lapic_cpu_init.c:      start_cpu(APIC ID 6)
                        spin_lock(&start_cpu_lock)
lapic_cpu_init.c:       lapic_start_cpu
                        spin_unlock(&start_cpu_lock)


CPU #1 (APIC ID 1, Xeon Chip 0, Logical processor 1):
lapic_cpu_init.c:   secondary_cpu_init
                     spin_lock(&start_cpu_lock)
cpu.c:               cpu_initialize
model_f2x_init.c:      model_f2x_init
intel_sibling.c:        intel_sibling_init (no-op)
                     spin_unlock(&start_cpu_lock)
lapic.h:             stop_this_cpu


CPU #2 (APIC ID 6, Xeon Chip 1, Logical processor 0):
lapic_cpu_init.c:   secondary_cpu_init
                     spin_lock(&start_cpu_lock)
cpu.c:               cpu_initialize
model_f2x_init.c:      model_f2x_init
intel_sibling.c:        intel_sibling_init
lapic_cpu_init.c:        start_cpu (APIC ID 7)
                          spin_lock(&start_cpu_lock)
lapic_cpu_init.c:         lapic_start_cpu
                          spin_unlock(&start_cpu_lock)
                     spin_unlock(&start_cpu_lock)
lapic.h:             stop_this_cpu
                       
                          
CPU #3 (APIC ID 7, Xeon Chip 1, Logical processor 1):
lapic_cpu_init.c:   secondary_cpu_init
                     spin_lock(&start_cpu_lock)
cpu.c:               cpu_initialize
model_f2x_init.c:      model_f2x_init
intel_sibling.c:        intel_sibling_init (no-op)
                     spin_unlock(&start_cpu_lock)
lapic.h:             stop_this_cpu


It sure looks to me like the CPU #2 call sequence tries to grab the
start_cpu_lock twice. 

Steve





From yinghailu at gmail.com  Fri Jul  1 07:23:14 2005
From: yinghailu at gmail.com (yhlu)
Date: Thu, 30 Jun 2005 22:23:14 -0700
Subject: [LinuxBIOS] Simple complie question
In-Reply-To: <20050701041138.11011.qmail@web304.biz.mail.mud.yahoo.com>
References: <20050701041138.11011.qmail@web304.biz.mail.mud.yahoo.com>
Message-ID: <2ea3fae10506302223252e51a5@mail.gmail.com>

you need to increase ROM_IMAGE_SIZE in targets/tyan/s2891/Config.lb a
little bit.


YH

On 6/30/05, Steve Casselman <sc at drccomputer.com> wrote:
> I'm adding print_debug statements to tyan/s2891 and
> now I get some code overlap messages
> 
> /usr/bin/ld: section .reset [00000000fffffff0 ->
> 00000000ffffffff] overlaps section .rom
> [00000000ffff6770 -> 000000010000014f]
> /usr/bin/ld: section .id [00000000ffffff69 ->
> 00000000ffffff7f] overlaps section .rom
> [00000000ffff6770 -> 000000010000014f]
> /usr/bin/ld: section .romstrap [00000000ffffffa0 ->
> 00000000ffffffef] overlaps section .rom
> [00000000ffff6770 -> 000000010000014f]
> 
> I'm not quite sure where this comes from. I've
> compiled this many times and it works great. Where
> (options config) are the setting for this?
> 
> A document pointer or a quick explaination would be
> great
> 
> Thanks
> 
> Steve
> 
> _______________________________________________
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>



From ollie at lanl.gov  Fri Jul  1 16:43:39 2005
From: ollie at lanl.gov (Li-Ta Lo)
Date: Fri, 01 Jul 2005 08:43:39 -0600
Subject: [LinuxBIOS] EPIA/EPIA-M Status?
In-Reply-To: <200506302315.AA00164@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
References: <200506302315.AA00164@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
Message-ID: <1120229019.21213.101.camel@exponential.lanl.gov>

On Fri, 2005-07-01 at 08:15 +0900, Jun OKAJIMA wrote:
> Hello guys and I hope you tell me what is going on.
> It worked finally?
> The snapshot version still has compile error.
> 

Which snapshot are you talking about? The patch-60 in the TLA repository
should work for EPIA. EPIA-M is not working still.

-- 
Li-Ta Lo <ollie at lanl.gov>
Los Alamos National Lab




From noodles at earth.li  Fri Jul  1 16:48:50 2005
From: noodles at earth.li (Jonathan McDowell)
Date: Fri, 1 Jul 2005 15:48:50 +0100
Subject: [LinuxBIOS] EPIA/EPIA-M Status?
In-Reply-To: <200506302315.AA00164@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
References: <200506302315.AA00164@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
Message-ID: <20050701144850.GS26687@earth.li>

On Fri, Jul 01, 2005 at 08:15:02AM +0900, Jun OKAJIMA wrote:
> Hello guys and I hope you tell me what is going on.
> It worked finally?
> The snapshot version still has compile error.

My tree compiles, but still doesn't work; I do however have the
appropriate bits to test it myself now, so I'm hoping to make some
progress in the next week. Search the list archives for details of my
arch tree.

J.

-- 
                                            jid: noodles at jabber.earth.li
A bug in the hand is better than one as
                                            yet undetected.



From jorgeecardona at gmail.com  Fri Jul  1 18:29:47 2005
From: jorgeecardona at gmail.com (Jorge Cardona)
Date: Fri, 1 Jul 2005 11:29:47 -0500
Subject: [LinuxBIOS] First instruction in linuxbios
Message-ID: <51d803a905070109295701268d@mail.gmail.com>

Hi.
I'm new in this, and i'm reading the source and i have a question, which one 
it's exactly the first instruction that the processor execute when the pc is 
booting?, in which file is it?

I don't complete understand the relationship between a normal bios and the 
kernel, i think that the bios it's has to pass some data to the kernel, if 
that's true ?how exactly is that data passed to the kernel?

In linuxbios, how it's this issue handle?

PD: sorry for my english
Thanks
-- 
Jorge Eduardo Cardona
jorgeecardona at gmail.com
------------------------------------------------
Linux registered user #391186
Registered machine #291871
------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20050701/52fb46d4/attachment.html>

From yinghailu at gmail.com  Fri Jul  1 19:16:49 2005
From: yinghailu at gmail.com (yhlu)
Date: Fri, 1 Jul 2005 10:16:49 -0700
Subject: [LinuxBIOS] First instruction in linuxbios
In-Reply-To: <51d803a905070109295701268d@mail.gmail.com>
References: <51d803a905070109295701268d@mail.gmail.com>
Message-ID: <2ea3fae105070110162ac13994@mail.gmail.com>

reset16.inc--->entry16.inc--->entry32.inc--->cache_as_ram.inc--->cache_as_ram_auto.c(include
mem init and ht init, and copy or unzip linuxbios_ram to ram and jmp
it)---->hardwaremain.c( dev init and resource allocation) --->elfload(
to load payload)

from hardwaremain to elfload is linked and compressed in linuxbios_ram.rom
and togther with others is linked into linuxbios.rom

YH

On 7/1/05, Jorge Cardona <jorgeecardona at gmail.com> wrote:
> Hi.
> I'm new in this, and i'm reading the source and  i have a question, which
> one it's exactly the first instruction that the processor execute when the
> pc is booting?, in which file is it?
> 
> I don't complete understand the relationship between a normal bios and the
> kernel, i think that the bios it's has to pass some data to the kernel, if
> that's true ?how exactly is that data passed to the kernel?
> 
> In linuxbios, how it's this issue handle?
> 
> PD: sorry for my english
> Thanks
> -- 
> Jorge Eduardo Cardona
> jorgeecardona at gmail.com
> ------------------------------------------------
> Linux registered user #391186
> Registered machine    #291871 
> ------------------------------------------------ 
> _______________________________________________
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
> 
>



From noodles at earth.li  Sun Jul  3 22:52:48 2005
From: noodles at earth.li (Jonathan McDowell)
Date: Sun, 3 Jul 2005 21:52:48 +0100
Subject: [LinuxBIOS] EPIA/EPIA-M sort of success.
In-Reply-To: <20050701144850.GS26687@earth.li>
References: <200506302315.AA00164@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
	<20050701144850.GS26687@earth.li>
Message-ID: <20050703205248.GH26687@earth.li>

On Fri, Jul 01, 2005 at 03:48:50PM +0100, Jonathan McDowell wrote:
> On Fri, Jul 01, 2005 at 08:15:02AM +0900, Jun OKAJIMA wrote:
> > Hello guys and I hope you tell me what is going on.
> > It worked finally?
> > The snapshot version still has compile error.
> My tree compiles, but still doesn't work; I do however have the
> appropriate bits to test it myself now, so I'm hoping to make some
> progress in the next week. Search the list archives for details of my
> arch tree.

And now it seems to compile and boot, though very very slowly.

Boot log at:

http://the.earth.li/~noodles/lb2.boot

(this took nearly half an hour to complete)

Patch against me current arch tree:

http://the.earth.li/~noodles/epia-m-crud.diff

(this is code I'm not prepared to check in even to my own tree yet as
it's lots of fiddling.)

It appears the changes to pci_moving_config are causing problems again;
I stopped using these for the pci_bridge scanning bits and that made it
stop hanging when trying to read the resources for the AGP bridge. I'm
not sure what the right way to fix this is.

J.

-- 
                 "Reality Or Nothing!" -- Cold Lazarus
[ Black Cat Networks ] [ 0845 PAYG dialup ] [ ADSL from ?20+VAT/month ]
                [ http://www.blackcatnetworks.co.uk/ ]



From liutao1980 at gmail.com  Mon Jul  4 05:11:47 2005
From: liutao1980 at gmail.com (Tao Liu)
Date: Mon, 4 Jul 2005 11:11:47 +0800
Subject: [LinuxBIOS] Re: Linuxbios is always 421bytes larger than allowed
In-Reply-To: <2ea3fae105062810017aafc743@mail.gmail.com>
References: <8eca059b0506262047248353e4@mail.gmail.com>
	<2ea3fae105062621014a394ee@mail.gmail.com>
	<8eca059b05062621117551c588@mail.gmail.com>
	<8eca059b050626235431cd0cfc@mail.gmail.com>
	<2ea3fae105062710122079bd56@mail.gmail.com>
	<8eca059b05062721133d9a92e1@mail.gmail.com>
	<2ea3fae105062810017aafc743@mail.gmail.com>
Message-ID: <8eca059b05070320116529cd1f@mail.gmail.com>

On 6/29/05, yhlu <yinghailu at gmail.com> wrote:
> Please check your MB Config.lb
> 
> there should be no "section .rodata.str1.32" section because it is
> already be change to .init.rodata....
> 
> YH

After add "--rename-section .rodata.str1.32=.init.rodata.str1.32" in
init.o makerule
the make process succeed.  The rodata.str1.32 section should be
created by compiler,
my gcc version is 3.3.3(Debian 20040417) 

-- 
Regards,
Liu Tao



From yinghailu at gmail.com  Mon Jul  4 05:27:36 2005
From: yinghailu at gmail.com (yhlu)
Date: Sun, 3 Jul 2005 20:27:36 -0700
Subject: [LinuxBIOS] Re: Linuxbios is always 421bytes larger than allowed
In-Reply-To: <8eca059b05070320116529cd1f@mail.gmail.com>
References: <8eca059b0506262047248353e4@mail.gmail.com>
	<2ea3fae105062621014a394ee@mail.gmail.com>
	<8eca059b05062621117551c588@mail.gmail.com>
	<8eca059b050626235431cd0cfc@mail.gmail.com>
	<2ea3fae105062710122079bd56@mail.gmail.com>
	<8eca059b05062721133d9a92e1@mail.gmail.com>
	<2ea3fae105062810017aafc743@mail.gmail.com>
	<8eca059b05070320116529cd1f@mail.gmail.com>
Message-ID: <2ea3fae10507032027583789ab@mail.gmail.com>

in RH gcc3.4.3
in Suse gcc.3.3.3
only have .rodata.str1.1...

can you update to gcc 3.4.3 have a try....

YH

On 7/3/05, Tao Liu <liutao1980 at gmail.com> wrote:
> On 6/29/05, yhlu <yinghailu at gmail.com> wrote:
> > Please check your MB Config.lb
> >
> > there should be no "section .rodata.str1.32" section because it is
> > already be change to .init.rodata....
> >
> > YH
> 
> After add "--rename-section .rodata.str1.32=.init.rodata.str1.32" in
> init.o makerule
> the make process succeed.  The rodata.str1.32 section should be
> created by compiler,
> my gcc version is 3.3.3(Debian 20040417)
> 
> --
> Regards,
> Liu Tao
>



From yinghailu at gmail.com  Mon Jul  4 05:28:18 2005
From: yinghailu at gmail.com (yhlu)
Date: Sun, 3 Jul 2005 20:28:18 -0700
Subject: [LinuxBIOS] Re: Linuxbios is always 421bytes larger than allowed
In-Reply-To: <2ea3fae10507032027583789ab@mail.gmail.com>
References: <8eca059b0506262047248353e4@mail.gmail.com>
	<2ea3fae105062621014a394ee@mail.gmail.com>
	<8eca059b05062621117551c588@mail.gmail.com>
	<8eca059b050626235431cd0cfc@mail.gmail.com>
	<2ea3fae105062710122079bd56@mail.gmail.com>
	<8eca059b05062721133d9a92e1@mail.gmail.com>
	<2ea3fae105062810017aafc743@mail.gmail.com>
	<8eca059b05070320116529cd1f@mail.gmail.com>
	<2ea3fae10507032027583789ab@mail.gmail.com>
Message-ID: <2ea3fae105070320287b9b5ba4@mail.gmail.com>

or you can disable CONFIG_USE_INIT

YH

On 7/3/05, yhlu <yinghailu at gmail.com> wrote:
> in RH gcc3.4.3
> in Suse gcc.3.3.3
> only have .rodata.str1.1...
> 
> can you update to gcc 3.4.3 have a try....
> 
> YH
> 
> On 7/3/05, Tao Liu <liutao1980 at gmail.com> wrote:
> > On 6/29/05, yhlu <yinghailu at gmail.com> wrote:
> > > Please check your MB Config.lb
> > >
> > > there should be no "section .rodata.str1.32" section because it is
> > > already be change to .init.rodata....
> > >
> > > YH
> >
> > After add "--rename-section .rodata.str1.32=.init.rodata.str1.32" in
> > init.o makerule
> > the make process succeed.  The rodata.str1.32 section should be
> > created by compiler,
> > my gcc version is 3.3.3(Debian 20040417)
> >
> > --
> > Regards,
> > Liu Tao
> >
>



From talbotx at comcast.net  Mon Jul  4 08:45:43 2005
From: talbotx at comcast.net (Adam Talbot)
Date: Sun, 3 Jul 2005 23:45:43 -0700
Subject: [LinuxBIOS] ECC, A function of Hard ware or BIOS
References: <200506302315.AA00164@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
	<Pine.LNX.4.58.0506301720130.17913@enigma.lanl.gov>
Message-ID: <001401c58064$00913b50$c501a8c0@newflame>

Is ECC memory support a function of BIOS or hard ware?
-Adam




From liutao1980 at gmail.com  Mon Jul  4 09:49:37 2005
From: liutao1980 at gmail.com (Tao Liu)
Date: Mon, 4 Jul 2005 15:49:37 +0800
Subject: [LinuxBIOS] Re: Linuxbios is always 421bytes larger than allowed
In-Reply-To: <2ea3fae10507032027583789ab@mail.gmail.com>
References: <8eca059b0506262047248353e4@mail.gmail.com>
	<2ea3fae105062621014a394ee@mail.gmail.com>
	<8eca059b05062621117551c588@mail.gmail.com>
	<8eca059b050626235431cd0cfc@mail.gmail.com>
	<2ea3fae105062710122079bd56@mail.gmail.com>
	<8eca059b05062721133d9a92e1@mail.gmail.com>
	<2ea3fae105062810017aafc743@mail.gmail.com>
	<8eca059b05070320116529cd1f@mail.gmail.com>
	<2ea3fae10507032027583789ab@mail.gmail.com>
Message-ID: <8eca059b050704004969450d51@mail.gmail.com>

On 7/4/05, yhlu <yinghailu at gmail.com> wrote:
> in RH gcc3.4.3
> in Suse gcc.3.3.3
> only have .rodata.str1.1...
> 
> can you update to gcc 3.4.3 have a try....
> 
> YH

I tried gcc3.3.6 with debian and it still have .rodata.str1.32 section,
the following mail explains the strM.N section, It's better to rename all these
sections to .init.rodata.strM.N, but I can't find how to do this job.

http://mail.freestandards.org/pipermail/lsb-spec/2001-November/001794.html
-- 
Regards,
Liu Tao



From steve at digidescorp.com  Mon Jul  4 14:07:52 2005
From: steve at digidescorp.com (Steve Magnani)
Date: Mon, 04 Jul 2005 07:07:52 -0500
Subject: [LinuxBIOS] RE: ECC, A function of Hard ware or BIOS
Message-ID: <WorldClient-F200507040707.AA07520029@digidescorp.com>

> Adam Talbot <talbotx at comcast.net> writes:
> Is ECC memory support a function of BIOS or hard ware?

Both. The memory controller and the DIMMs have to support it, and the BIOS
has to configure the memory controller to enable it.

Steve Magnani
www.digidescorp.com





From yinghailu at gmail.com  Mon Jul  4 17:38:07 2005
From: yinghailu at gmail.com (yhlu)
Date: Mon, 4 Jul 2005 08:38:07 -0700
Subject: [LinuxBIOS] Re: Linuxbios is always 421bytes larger than allowed
In-Reply-To: <8eca059b050704004969450d51@mail.gmail.com>
References: <8eca059b0506262047248353e4@mail.gmail.com>
	<2ea3fae105062621014a394ee@mail.gmail.com>
	<8eca059b05062621117551c588@mail.gmail.com>
	<8eca059b050626235431cd0cfc@mail.gmail.com>
	<2ea3fae105062710122079bd56@mail.gmail.com>
	<8eca059b05062721133d9a92e1@mail.gmail.com>
	<2ea3fae105062810017aafc743@mail.gmail.com>
	<8eca059b05070320116529cd1f@mail.gmail.com>
	<2ea3fae10507032027583789ab@mail.gmail.com>
	<8eca059b050704004969450d51@mail.gmail.com>
Message-ID: <2ea3fae105070408387b1edf9e@mail.gmail.com>

so bytes alignment is different...

YH

On 7/4/05, Tao Liu <liutao1980 at gmail.com> wrote:
> On 7/4/05, yhlu <yinghailu at gmail.com> wrote:
> > in RH gcc3.4.3
> > in Suse gcc.3.3.3
> > only have .rodata.str1.1...
> >
> > can you update to gcc 3.4.3 have a try....
> >
> > YH
> 
> I tried gcc3.3.6 with debian and it still have .rodata.str1.32 section,
> the following mail explains the strM.N section, It's better to rename all these
> sections to .init.rodata.strM.N, but I can't find how to do this job.
> 
> http://mail.freestandards.org/pipermail/lsb-spec/2001-November/001794.html
> --
> Regards,
> Liu Tao
>



From talbotx at comcast.net  Mon Jul  4 20:14:23 2005
From: talbotx at comcast.net (Adam Talbot)
Date: Mon, 4 Jul 2005 11:14:23 -0700
Subject: [LinuxBIOS] RE: ECC, A function of Hard ware or BIOS
References: <WorldClient-F200507040707.AA07520029@digidescorp.com>
Message-ID: <003101c580c4$3516f710$c501a8c0@newflame>

I have a 1GB sticks of HP SDRAM PC133 SDRAM ECC.  The system is a Netgear 
ND520 Network Disk Drive.  The BIOS does not support ECC.  How would I find 
out if the memory controller supports ECC? All my googling says no.

I found the ND520 at a garage sale for $20.  Currently it only supports up 
to 128MB ram and nothing bigger then a 36GB hard drive (IDE); and the real 
fun part... No console connection any wear that I can find. Netgear stopped 
supporting these a few years ago. I was able to quickly rebuild the system 
running Gentoo Linux, I now moves VERY fast, for what it is.

Do we have support for Linux BIOS on this chip set VT82C585VP?

Here is the information I get from lspci -vv
nd520 ~ # lspci -vv
0000:00:00.0 Host bridge: VIA Technologies, Inc. VT82C585VP [Apollo VP1/VPX] 
(rev 23)
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
        Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort- >SERR- <PERR+
        Latency: 32

0000:00:07.0 ISA bridge: VIA Technologies, Inc. VT82C586/A/B PCI-to-ISA 
[Apollo VP] (rev 47)
        Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- 
Stepping+ SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0

0000:00:07.1 IDE interface: VIA Technologies, Inc. 
VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) (prog-if 8a 
[Master SecP PriP])
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 32
        Region 4: I/O ports at e000 [size=16]

0000:00:07.3 Host bridge: VIA Technologies, Inc. VT82C586B ACPI (rev 10)
        Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-

nd520 ~ #



----- Original Message ----- 
From: "Steve Magnani" <steve at digidescorp.com>
To: <linuxbios at openbios.org>
Sent: Monday, July 04, 2005 5:07 AM
Subject: [LinuxBIOS] RE: ECC, A function of Hard ware or BIOS


>> Adam Talbot <talbotx at comcast.net> writes:
>> Is ECC memory support a function of BIOS or hard ware?
>
> Both. The memory controller and the DIMMs have to support it, and the BIOS
> has to configure the memory controller to enable it.
>
> Steve Magnani
> www.digidescorp.com
>
>
>
> _______________________________________________
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
> 





From rminnich at lanl.gov  Tue Jul  5 16:40:39 2005
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Tue, 5 Jul 2005 08:40:39 -0600 (MDT)
Subject: [LinuxBIOS] Re: ECC, A function of Hard ware or BIOS
In-Reply-To: <001401c58064$00913b50$c501a8c0@newflame>
References: <200506302315.AA00164@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
	<Pine.LNX.4.58.0506301720130.17913@enigma.lanl.gov>
	<001401c58064$00913b50$c501a8c0@newflame>
Message-ID: <Pine.LNX.4.58.0507050840280.30613@enigma.lanl.gov>



On Sun, 3 Jul 2005, Adam Talbot wrote:

> Is ECC memory support a function of BIOS or hard ware?

both, which is what makes it so much fun.

ron



From rminnich at lanl.gov  Tue Jul  5 16:41:27 2005
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Tue, 5 Jul 2005 08:41:27 -0600 (MDT)
Subject: [LinuxBIOS] Re: Linuxbios is always 421bytes larger than allowed
In-Reply-To: <8eca059b050704004969450d51@mail.gmail.com>
References: <8eca059b0506262047248353e4@mail.gmail.com>
	<2ea3fae105062621014a394ee@mail.gmail.com>
	<8eca059b05062621117551c588@mail.gmail.com>
	<8eca059b050626235431cd0cfc@mail.gmail.com>
	<2ea3fae105062710122079bd56@mail.gmail.com>
	<8eca059b05062721133d9a92e1@mail.gmail.com>
	<2ea3fae105062810017aafc743@mail.gmail.com>
	<8eca059b05070320116529cd1f@mail.gmail.com>
	<2ea3fae10507032027583789ab@mail.gmail.com>
	<8eca059b050704004969450d51@mail.gmail.com>
Message-ID: <Pine.LNX.4.58.0507050840570.30613@enigma.lanl.gov>



On Mon, 4 Jul 2005, Tao Liu wrote:

> I tried gcc3.3.6 with debian and it still have .rodata.str1.32 section,
> the following mail explains the strM.N section, It's better to rename
> all these sections to .init.rodata.strM.N, but I can't find how to do
> this job.

no, we need to fix the ldscripts, we had this problem once before in a 
slightly different situation. I'll try to fix this when I get back. It's 
an easy fix.

ron



From yinghailu at gmail.com  Wed Jul  6 00:14:28 2005
From: yinghailu at gmail.com (yhlu)
Date: Tue, 5 Jul 2005 15:14:28 -0700
Subject: [LinuxBIOS] dead loop in compute_allocate_resource
Message-ID: <2ea3fae105070515146f94f01d@mail.gmail.com>

Eric,

for s2735, I add enable some print out, it turns out it get not get out from 
Root Device compute_allocate_io

it will get into the dead loop around 2e.0 2e.2, 2e.3, 2e.b

YH



Allocating resources...
Reading resources...
Root Device compute_allocate_io: base: 00000400 size: 00000000 align: 0 gran: 0
Root Device read_resources bus 0 link: 0
PCI_DOMAIN: 0000 read_resources bus 0 link: 0
PCI: 00:02.0 compute_allocate_io: base: 00000000 size: 00000000 align:
12 gran: 12
PCI: 00:02.0 read_resources bus 1 link: 0
PCI: 01:1d.0 compute_allocate_io: base: 00000000 size: 00000000 align:
12 gran: 12
PCI: 01:1d.0 read_resources bus 2 link: 0
PCI: 01:1d.0 read_resources bus 2 link: 0 done
        1: PCI: 02:01.0 20 *  [0x00000000 - 0x0000003f] io
        2:PCI: 02:01.0 20 *  [0x00000000 - 0x0000003f] io
PCI: 02:01.0 20 *  [0x00000000 - 0x0000003f] io
        1: PCI: 02:01.1 20 *  [0x00000000 - 0x0000003f] io
        2:PCI: 02:01.1 20 *  [0x00000000 - 0x0000003f] io
PCI: 02:01.1 20 *  [0x00000040 - 0x0000007f] io
PCI: 01:1d.0 compute_allocate_io: base: 00000080 size: 00001000 align:
12 gran: 12 done
PCI: 01:1d.0 compute_allocate_prefmem: base: 00000000 size: 00000000
align: 20 gran: 20
PCI: 01:1d.0 read_resources bus 2 link: 0
PCI: 01:1d.0 read_resources bus 2 link: 0 done
PCI: 01:1d.0 compute_allocate_prefmem: base: 00000000 size: 00000000
align: 20 gran: 20 done
PCI: 01:1d.0 compute_allocate_prefmem: base: fffffffffff00000 size:
00000000 align: 20 gran: 20
PCI: 01:1d.0 read_resources bus 2 link: 0
PCI: 01:1d.0 read_resources bus 2 link: 0 done
PCI: 01:1d.0 compute_allocate_prefmem: base: fffffffffff00000 size:
00000000 align: 20 gran: 20 done
PCI: 01:1d.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 2 prefmem
PCI: 01:1d.0 compute_allocate_mem: base: 00000000 size: 00000000
align: 20 gran: 20
PCI: 01:1d.0 read_resources bus 2 link: 0
PCI: 01:1d.0 read_resources bus 2 link: 0 done
        1: PCI: 02:01.0 10 *  [0x00000000 - 0x0001ffff] mem
        2:PCI: 02:01.0 10 *  [0x00000000 - 0x0001ffff] mem
PCI: 02:01.0 10 *  [0x00000000 - 0x0001ffff] mem
        1: PCI: 02:01.1 10 *  [0x00000000 - 0x0001ffff] mem
        2:PCI: 02:01.1 10 *  [0x00000000 - 0x0001ffff] mem
PCI: 02:01.1 10 *  [0x00020000 - 0x0003ffff] mem
PCI: 01:1d.0 compute_allocate_mem: base: 00040000 size: 00100000
align: 20 gran: 20 done
PCI: 01:1f.0 compute_allocate_io: base: 00000000 size: 00000000 align:
12 gran: 12
PCI: 01:1f.0 read_resources bus 3 link: 0
PCI: 01:1f.0 read_resources bus 3 link: 0 done
PCI: 01:1f.0 compute_allocate_io: base: 00000000 size: 00000000 align:
12 gran: 12 done
PCI: 01:1f.0 compute_allocate_io: base: 0000f000 size: 00000000 align:
12 gran: 12
PCI: 01:1f.0 read_resources bus 3 link: 0
PCI: 01:1f.0 read_resources bus 3 link: 0 done
PCI: 01:1f.0 compute_allocate_io: base: 0000f000 size: 00000000 align:
12 gran: 12 done
PCI: 01:1f.0 1c <- [0x000000f000 - 0x000000efff] bus 3 io
PCI: 01:1f.0 compute_allocate_prefmem: base: 00000000 size: 00000000
align: 20 gran: 20
PCI: 01:1f.0 read_resources bus 3 link: 0
PCI: 01:1f.0 read_resources bus 3 link: 0 done
PCI: 01:1f.0 compute_allocate_prefmem: base: 00000000 size: 00000000
align: 20 gran: 20 done
PCI: 01:1f.0 compute_allocate_prefmem: base: fffffffffff00000 size:
00000000 align: 20 gran: 20
PCI: 01:1f.0 read_resources bus 3 link: 0
PCI: 01:1f.0 read_resources bus 3 link: 0 done
PCI: 01:1f.0 compute_allocate_prefmem: base: fffffffffff00000 size:
00000000 align: 20 gran: 20 done
PCI: 01:1f.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 3 prefmem
PCI: 01:1f.0 compute_allocate_mem: base: 00000000 size: 00000000
align: 20 gran: 20
PCI: 01:1f.0 read_resources bus 3 link: 0
PCI: 01:1f.0 read_resources bus 3 link: 0 done
PCI: 01:1f.0 compute_allocate_mem: base: 00000000 size: 00000000
align: 20 gran: 20 done
PCI: 01:1f.0 compute_allocate_mem: base: fff00000 size: 00000000
align: 20 gran: 20
PCI: 01:1f.0 read_resources bus 3 link: 0
PCI: 01:1f.0 read_resources bus 3 link: 0 done
PCI: 01:1f.0 compute_allocate_mem: base: fff00000 size: 00000000
align: 20 gran: 20 done
PCI: 01:1f.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 3 mem
PCI: 00:02.0 read_resources bus 1 link: 0 done
        1: PCI: 01:1d.0 1c *  [0x00000000 - 0x00000fff] io
        2:PCI: 01:1d.0 1c *  [0x00000000 - 0x00000fff] io
PCI: 01:1d.0 1c *  [0x00000000 - 0x00000fff] io
PCI: 00:02.0 compute_allocate_io: base: 00001000 size: 00001000 align:
12 gran: 12 done
PCI: 00:02.0 compute_allocate_prefmem: base: 00000000 size: 00000000
align: 20 gran: 20
PCI: 00:02.0 read_resources bus 1 link: 0
PCI: 00:02.0 read_resources bus 1 link: 0 done
PCI: 00:02.0 compute_allocate_prefmem: base: 00000000 size: 00000000
align: 20 gran: 20 done
PCI: 00:02.0 compute_allocate_prefmem: base: fff00000 size: 00000000
align: 20 gran: 20
PCI: 00:02.0 read_resources bus 1 link: 0
PCI: 00:02.0 read_resources bus 1 link: 0 done
PCI: 00:02.0 compute_allocate_prefmem: base: fff00000 size: 00000000
align: 20 gran: 20 done
PCI: 00:02.0 24 <- [0x00fff00000 - 0x00ffefffff] bus 1 prefmem
PCI: 00:02.0 compute_allocate_mem: base: 00000000 size: 00000000
align: 20 gran: 20
PCI: 00:02.0 read_resources bus 1 link: 0
PCI: 00:02.0 read_resources bus 1 link: 0 done
        1: PCI: 01:1d.0 20 *  [0x00000000 - 0x000fffff] mem
        2:PCI: 01:1d.0 20 *  [0x00000000 - 0x000fffff] mem
PCI: 01:1d.0 20 *  [0x00000000 - 0x000fffff] mem
        1: PCI: 01:1c.0 10 *  [0x00000000 - 0x00000fff] mem
        2:PCI: 01:1c.0 10 *  [0x00000000 - 0x00000fff] mem
PCI: 01:1c.0 10 *  [0x00100000 - 0x00100fff] mem
        1: PCI: 01:1e.0 10 *  [0x00000000 - 0x00000fff] mem
        2:PCI: 01:1e.0 10 *  [0x00000000 - 0x00000fff] mem
PCI: 01:1e.0 10 *  [0x00101000 - 0x00101fff] mem
PCI: 00:02.0 compute_allocate_mem: base: 00102000 size: 00200000
align: 20 gran: 20 done
PCI: 00:1e.0 compute_allocate_io: base: 00000000 size: 00000000 align:
12 gran: 12
PCI: 00:1e.0 read_resources bus 4 link: 0
PCI: 00:1e.0 read_resources bus 4 link: 0 done
        1: PCI: 04:02.0 14 *  [0x00000000 - 0x000000ff] io
        2:PCI: 04:02.0 14 *  [0x00000000 - 0x000000ff] io
PCI: 04:02.0 14 *  [0x00000000 - 0x000000ff] io
        1: PCI: 04:01.0 14 *  [0x00000000 - 0x0000003f] io
        2:PCI: 04:01.0 14 *  [0x00000000 - 0x0000003f] io
PCI: 04:01.0 14 *  [0x00000400 - 0x0000043f] io
PCI: 00:1e.0 compute_allocate_io: base: 00000440 size: 00001000 align:
12 gran: 12 done
PCI: 00:1e.0 compute_allocate_prefmem: base: 00000000 size: 00000000
align: 20 gran: 20
PCI: 00:1e.0 read_resources bus 4 link: 0
PCI: 00:1e.0 read_resources bus 4 link: 0 done
PCI: 00:1e.0 compute_allocate_prefmem: base: 00000000 size: 00000000
align: 20 gran: 20 done
PCI: 00:1e.0 compute_allocate_prefmem: base: fff00000 size: 00000000
align: 20 gran: 20
PCI: 00:1e.0 read_resources bus 4 link: 0
PCI: 00:1e.0 read_resources bus 4 link: 0 done
PCI: 00:1e.0 compute_allocate_prefmem: base: fff00000 size: 00000000
align: 20 gran: 20 done
PCI: 00:1e.0 24 <- [0x00fff00000 - 0x00ffefffff] bus 4 prefmem
PCI: 00:1e.0 compute_allocate_mem: base: 00000000 size: 00000000
align: 20 gran: 20
PCI: 00:1e.0 read_resources bus 4 link: 0
PCI: 00:1e.0 read_resources bus 4 link: 0 done
        1: PCI: 04:02.0 10 *  [0x00000000 - 0x00ffffff] mem
        2:PCI: 04:02.0 10 *  [0x00000000 - 0x00ffffff] mem
PCI: 04:02.0 10 *  [0x00000000 - 0x00ffffff] mem
        1: PCI: 04:01.0 18 *  [0x00000000 - 0x0001ffff] mem
        2:PCI: 04:01.0 18 *  [0x00000000 - 0x0001ffff] mem
PCI: 04:01.0 18 *  [0x01000000 - 0x0101ffff] mem
        1: PCI: 04:01.0 10 *  [0x00000000 - 0x00000fff] mem
        2:PCI: 04:01.0 10 *  [0x00000000 - 0x00000fff] mem
PCI: 04:01.0 10 *  [0x01020000 - 0x01020fff] mem
        1: PCI: 04:02.0 18 *  [0x00000000 - 0x00000fff] mem
        2:PCI: 04:02.0 18 *  [0x00000000 - 0x00000fff] mem
PCI: 04:02.0 18 *  [0x01021000 - 0x01021fff] mem
PCI: 00:1e.0 compute_allocate_mem: base: 01022000 size: 01100000
align: 24 gran: 20 done
PCI: 00:1f.0 read_resources bus 0 link: 0
PCI: 00:1f.0 read_resources bus 0 link: 0 done
PCI_DOMAIN: 0000 read_resources bus 0 link: 0 done
Root Device read_resources bus 0 link: 0 done
        1: PCI: 00:02.0 1c *  [0x00000000 - 0x00000fff] io
        2:PCI: 00:02.0 1c *  [0x00000000 - 0x00000fff] io
PCI: 00:02.0 1c *  [0x00001000 - 0x00001fff] io
        1: PCI: 00:1e.0 1c *  [0x00000000 - 0x00000fff] io
        2:PCI: 00:1e.0 1c *  [0x00000000 - 0x00000fff] io
PCI: 00:1e.0 1c *  [0x00002000 - 0x00002fff] io
        1: PCI: 00:1d.0 20 *  [0x00000000 - 0x0000001f] io
        2:PCI: 00:1d.0 20 *  [0x00000000 - 0x0000001f] io
PCI: 00:1d.0 20 *  [0x00003000 - 0x0000301f] io
        1: PCI: 00:1d.1 20 *  [0x00000000 - 0x0000001f] io
        2:PCI: 00:1d.1 20 *  [0x00000000 - 0x0000001f] io
PCI: 00:1d.1 20 *  [0x00003020 - 0x0000303f] io
        1: PCI: 00:1d.2 20 *  [0x00000000 - 0x0000001f] io
        2:PCI: 00:1d.2 20 *  [0x00000000 - 0x0000001f] io
PCI: 00:1d.2 20 *  [0x00003040 - 0x0000305f] io
        1: PCI: 00:1d.3 20 *  [0x00000000 - 0x0000001f] io
        2:PCI: 00:1d.3 20 *  [0x00000000 - 0x0000001f] io
PCI: 00:1d.3 20 *  [0x00003060 - 0x0000307f] io
        1: PCI: 00:1f.3 20 *  [0x00000000 - 0x0000001f] io
        2:PCI: 00:1f.3 20 *  [0x00000000 - 0x0000001f] io
PCI: 00:1f.3 20 *  [0x00003080 - 0x0000309f] io
        1: PCI: 00:1f.2 20 *  [0x00000000 - 0x0000000f] io
        2:PCI: 00:1f.2 20 *  [0x00000000 - 0x0000000f] io
PCI: 00:1f.2 20 *  [0x000030a0 - 0x000030af] io
        1: PNP: 002e.0 60 *  [0x000003f0 - 0x000003f7] io
        1: PNP: 002e.2 60 *  [0x000003f8 - 0x000003ff] io
        1: PNP: 002e.3 60 *  [0x000002f8 - 0x000002ff] io
        1: PNP: 002e.b 60 *  [0x00000290 - 0x00000297] io
        1: PNP: 002e.0 60 *  [0x000003f0 - 0x000003f7] io
        1: PNP: 002e.2 60 *  [0x000003f8 - 0x000003ff] io
        1: PNP: 002e.3 60 *  [0x000002f8 - 0x000002ff] io
        1: PNP: 002e.b 60 *  [0x00000290 - 0x00000297] io
        1: PNP: 002e.0 60 *  [0x000003f0 - 0x000003f7] io
        1: PNP: 002e.2 60 *  [0x000003f8 - 0x000003ff] io
        1: PNP: 002e.3 60 *  [0x000002f8 - 0x000002ff] io
        1: PNP: 002e.b 60 *  [0x00000290 - 0x00000297] io
        1: PNP: 002e.0 60 *  [0x000003f0 - 0x000003f7] io
        1: PNP: 002e.2 60 *  [0x000003f8 - 0x000003ff] io
        1: PNP: 002e.3 60 *  [0x000002f8 - 0x000002ff] io
        1: PNP: 002e.b 60 *  [0x00000290 - 0x00000297] io
        1: PNP: 002e.0 60 *  [0x000003f0 - 0x000003f7] io
        1: PNP: 002e.2 60 *  [0x000003f8 - 0x000003ff] io
        1: PNP: 002e.3 60 *  [0x000002f8 - 0x000002ff] io
        1: PNP: 002e.b 60 *  [0x00000290 - 0x00000297] io
        1: PNP: 002e.0 60 *  [0x000003f0 - 0x000003f7] io
        1: PNP: 002e.2 60 *  [0x000003f8 - 0x000003ff] io
        1: PNP: 002e.3 60 *  [0x000002f8 - 0x000002ff] io
        1: PNP: 002e.b 60 *  [0x00000290 - 0x00000297] io
        1: PNP: 002e.0 60 *  [0x000003f0 - 0x000003f7] io
        1: PNP: 002e.2 60 *  [0x000003f8 - 0x000003ff] io



From yinghailu at gmail.com  Wed Jul  6 00:29:22 2005
From: yinghailu at gmail.com (yhlu)
Date: Tue, 5 Jul 2005 15:29:22 -0700
Subject: [LinuxBIOS] Re: dead loop in compute_allocate_resource
In-Reply-To: <2ea3fae105070515146f94f01d@mail.gmail.com>
References: <2ea3fae105070515146f94f01d@mail.gmail.com>
Message-ID: <2ea3fae10507051529308e2eac@mail.gmail.com>

in s2895 it show


PCI: pci_scan_bus returning with max=08
PCI: pci_scan_bus returning with max=08
done
Allocating resources...
Reading resources...
Root Device compute_allocate_io: base: 00000400 size: 00000000 align: 0 gran: 0
Root Device read_resources bus 0 link: 0
PCI_DOMAIN: 0000 read_resources bus 0 link: 0
PCI: 00:18.0 compute_allocate_io: base: 00000000 size: 00000000 align:
12 gran: 12
PCI: 00:18.0 read_resources bus 1 link: 0
PCI: 01:02.0 read_resources bus 0 link: 0
PCI: 01:02.0 read_resources bus 0 link: 0 done
PCI: 01:0a.0 compute_allocate_io: base: 00000000 size: 00000000 align:
12 gran: 12
PCI: 01:0a.0 read_resources bus 2 link: 0
PCI: 01:0a.0 read_resources bus 2 link: 0 done
PCI: 01:0a.0 compute_allocate_io: base: 00000000 size: 00000000 align:
12 gran: 12 done
PCI: 01:0a.0 compute_allocate_io: base: 0000f000 size: 00000000 align:
12 gran: 12
PCI: 01:0a.0 read_resources bus 2 link: 0
PCI: 01:0a.0 read_resources bus 2 link: 0 done
PCI: 01:0a.0 compute_allocate_io: base: 0000f000 size: 00000000 align:
12 gran: 12 done
PCI: 01:0a.0 1c <- [0x000000f000 - 0x000000efff] bus 2 io
PCI: 01:0a.0 compute_allocate_prefmem: base: 00000000 size: 00000000
align: 20 gran: 20
PCI: 01:0a.0 read_resources bus 2 link: 0
PCI: 01:0a.0 read_resources bus 2 link: 0 done
PCI: 01:0a.0 compute_allocate_prefmem: base: 00000000 size: 00000000
align: 20 gran: 20 done
PCI: 01:0a.0 compute_allocate_prefmem: base: fff00000 size: 00000000
align: 20 gran: 20
PCI: 01:0a.0 read_resources bus 2 link: 0
PCI: 01:0a.0 read_resources bus 2 link: 0 done
PCI: 01:0a.0 compute_allocate_prefmem: base: fff00000 size: 00000000
align: 20 gran: 20 done
PCI: 01:0a.0 24 <- [0x00fff00000 - 0x00ffefffff] bus 2 prefmem
PCI: 01:0a.0 compute_allocate_mem: base: 00000000 size: 00000000
align: 20 gran: 20
PCI: 01:0a.0 read_resources bus 2 link: 0
PCI: 01:0a.0 read_resources bus 2 link: 0 done
        1: PCI: 02:05.0 14 *  [0x00000000 - 0x00003fff] mem
        2: PCI: 02:05.0 14 *  [0x00000000 - 0x00003fff] mem
PCI: 02:05.0 14 *  [0x00000000 - 0x00003fff] mem
        1: PCI: 02:05.0 10 *  [0x00000000 - 0x000007ff] mem
        2: PCI: 02:05.0 10 *  [0x00000000 - 0x000007ff] mem
PCI: 02:05.0 10 *  [0x00004000 - 0x000047ff] mem
PCI: 01:0a.0 compute_allocate_mem: base: 00004800 size: 00100000
align: 20 gran: 20 done
PCI: 01:0f.0 compute_allocate_io: base: 00000000 size: 00000000 align:
12 gran: 12
PCI: 01:0f.0 read_resources bus 3 link: 0
PCI: 01:0f.0 read_resources bus 3 link: 0 done
PCI: 01:0f.0 compute_allocate_io: base: 00000000 size: 00000000 align:
12 gran: 12 done
PCI: 01:0f.0 compute_allocate_io: base: fffff000 size: 00000000 align:
12 gran: 12
PCI: 01:0f.0 read_resources bus 3 link: 0
PCI: 01:0f.0 read_resources bus 3 link: 0 done
PCI: 01:0f.0 compute_allocate_io: base: fffff000 size: 00000000 align:
12 gran: 12 done
PCI: 01:0f.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 3 io
PCI: 01:0f.0 compute_allocate_prefmem: base: 00000000 size: 00000000
align: 20 gran: 20
PCI: 01:0f.0 read_resources bus 3 link: 0
PCI: 01:0f.0 read_resources bus 3 link: 0 done
PCI: 01:0f.0 compute_allocate_prefmem: base: 00000000 size: 00000000
align: 20 gran: 20 done
PCI: 01:0f.0 compute_allocate_prefmem: base: fffffffffff00000 size:
00000000 align: 20 gran: 20
PCI: 01:0f.0 read_resources bus 3 link: 0
PCI: 01:0f.0 read_resources bus 3 link: 0 done
PCI: 01:0f.0 compute_allocate_prefmem: base: fffffffffff00000 size:
00000000 align: 20 gran: 20 done
PCI: 01:0f.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 3 prefmem
PCI: 01:0f.0 compute_allocate_mem: base: 00000000 size: 00000000
align: 20 gran: 20
PCI: 01:0f.0 read_resources bus 3 link: 0
PCI: 01:0f.0 read_resources bus 3 link: 0 done
PCI: 01:0f.0 compute_allocate_mem: base: 00000000 size: 00000000
align: 20 gran: 20 done
PCI: 01:0f.0 compute_allocate_mem: base: fff00000 size: 00000000
align: 20 gran: 20
PCI: 01:0f.0 read_resources bus 3 link: 0
PCI: 01:0f.0 read_resources bus 3 link: 0 done
PCI: 01:0f.0 compute_allocate_mem: base: fff00000 size: 00000000
align: 20 gran: 20 done
PCI: 01:0f.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 3 mem
PCI: 00:18.0 read_resources bus 1 link: 0 done
        1: PCI: 01:02.0 60 *  [0x00000000 - 0x000000ff] io
        2: PCI: 01:02.0 60 *  [0x00000000 - 0x000000ff] io
PCI: 01:02.0 60 *  [0x00000000 - 0x000000ff] io
        1: PCI: 01:02.0 64 *  [0x00000000 - 0x000000ff] io
        2: PCI: 01:02.0 64 *  [0x00000000 - 0x000000ff] io
PCI: 01:02.0 64 *  [0x00000400 - 0x000004ff] io
        1: PCI: 01:02.0 68 *  [0x00000000 - 0x000000ff] io
        2: PCI: 01:02.0 68 *  [0x00000000 - 0x000000ff] io
PCI: 01:02.0 68 *  [0x00000800 - 0x000008ff] io
        1: PCI: 01:05.0 10 *  [0x00000000 - 0x000000ff] io
        2: PCI: 01:05.0 10 *  [0x00000000 - 0x000000ff] io
PCI: 01:05.0 10 *  [0x00000c00 - 0x00000cff] io
        1: PCI: 01:05.0 14 *  [0x00000000 - 0x000000ff] io
        2: PCI: 01:05.0 14 *  [0x00000000 - 0x000000ff] io
PCI: 01:05.0 14 *  [0x00001000 - 0x000010ff] io
        1: PCI: 01:02.0 10 *  [0x00000000 - 0x0000007f] io
        2: PCI: 01:02.0 10 *  [0x00000000 - 0x0000007f] io
PCI: 01:02.0 10 *  [0x00001400 - 0x0000147f] io
        1: PNP: 002e.a 60 *  [0x00000400 - 0x0000047f] io
        1: PCI: 01:02.1 20 *  [0x00000000 - 0x0000003f] io
        2: PCI: 01:02.1 20 *  [0x00000000 - 0x0000003f] io
PCI: 01:02.1 20 *  [0x00001480 - 0x000014bf] io
        1: PCI: 01:02.1 24 *  [0x00000000 - 0x0000003f] io
        2: PCI: 01:02.1 24 *  [0x00000000 - 0x0000003f] io
PCI: 01:02.1 24 *  [0x000014c0 - 0x000014ff] io
        1: PCI: 01:02.1 10 *  [0x00000000 - 0x0000001f] io
        2: PCI: 01:02.1 10 *  [0x00000000 - 0x0000001f] io
PCI: 01:02.1 10 *  [0x00001800 - 0x0000181f] io
        1: PNP: 002e.8 60 *  [0x00000290 - 0x0000029f] io
        1: PCI: 01:07.0 20 *  [0x00000000 - 0x0000000f] io
        2: PCI: 01:07.0 20 *  [0x00000000 - 0x0000000f] io
PCI: 01:07.0 20 *  [0x00001820 - 0x0000182f] io
        1: PCI: 01:08.0 20 *  [0x00000000 - 0x0000000f] io
        2: PCI: 01:08.0 20 *  [0x00000000 - 0x0000000f] io
PCI: 01:08.0 20 *  [0x00001830 - 0x0000183f] io
        1: PCI: 01:09.0 20 *  [0x00000000 - 0x0000000f] io
        2: PCI: 01:09.0 20 *  [0x00000000 - 0x0000000f] io
PCI: 01:09.0 20 *  [0x00001840 - 0x0000184f] io
        1: PNP: 002e.0 60 *  [0x000003f0 - 0x000003f7] io
        1: PNP: 002e.4 60 *  [0x000003f8 - 0x000003ff] io
        1: PCI: 01:08.0 10 *  [0x00000000 - 0x00000007] io
        2: PCI: 01:08.0 10 *  [0x00000000 - 0x00000007] io
PCI: 01:08.0 10 *  [0x00001850 - 0x00001857] io
        1: PCI: 01:08.0 18 *  [0x00000000 - 0x00000007] io
        2: PCI: 01:08.0 18 *  [0x00000000 - 0x00000007] io
PCI: 01:08.0 18 *  [0x00001860 - 0x00001867] io
        1: PCI: 01:09.0 10 *  [0x00000000 - 0x00000007] io
        2: PCI: 01:09.0 10 *  [0x00000000 - 0x00000007] io
PCI: 01:09.0 10 *  [0x00001870 - 0x00001877] io
        1: PCI: 01:09.0 18 *  [0x00000000 - 0x00000007] io
        2: PCI: 01:09.0 18 *  [0x00000000 - 0x00000007] io
PCI: 01:09.0 18 *  [0x00001880 - 0x00001887] io
        1: PCI: 01:0b.0 14 *  [0x00000000 - 0x00000007] io
        2: PCI: 01:0b.0 14 *  [0x00000000 - 0x00000007] io
PCI: 01:0b.0 14 *  [0x00001890 - 0x00001897] io
        1: PCI: 01:08.0 14 *  [0x00000000 - 0x00000003] io
        2: PCI: 01:08.0 14 *  [0x00000000 - 0x00000003] io
PCI: 01:08.0 14 *  [0x000018a0 - 0x000018a3] io
        1: PCI: 01:08.0 1c *  [0x00000000 - 0x00000003] io
        2: PCI: 01:08.0 1c *  [0x00000000 - 0x00000003] io
PCI: 01:08.0 1c *  [0x000018b0 - 0x000018b3] io
        1: PCI: 01:09.0 14 *  [0x00000000 - 0x00000003] io
        2: PCI: 01:09.0 14 *  [0x00000000 - 0x00000003] io
PCI: 01:09.0 14 *  [0x000018c0 - 0x000018c3] io
        1: PCI: 01:09.0 1c *  [0x00000000 - 0x00000003] io
        2: PCI: 01:09.0 1c *  [0x00000000 - 0x00000003] io
PCI: 01:09.0 1c *  [0x000018d0 - 0x000018d3] io
        1: PNP: 002e.7 60 *  [0x00000060 - 0x00000060] io
        1: PNP: 002e.7 62 *  [0x00000064 - 0x00000064] io
PCI: 00:18.0 compute_allocate_io: base: 000018d4 size: 00002000 align:
12 gran: 12 done
PCI: 00:18.0 compute_allocate_prefmem: base: 00000000 size: 00000000
align: 20 gran: 20
PCI: 00:18.0 read_resources bus 1 link: 0
PCI: 00:18.0 read_resources bus 1 link: 0 done
PCI: 00:18.0 compute_allocate_prefmem: base: 00000000 size: 00000000
align: 20 gran: 20 done
PCI: 00:18.0 compute_allocate_mem: base: 00000000 size: 00000000
align: 20 gran: 20
PCI: 00:18.0 read_resources bus 1 link: 0
PCI: 00:18.0 read_resources bus 1 link: 0 done
        1: PCI: 01:0a.0 20 *  [0x00000000 - 0x000fffff] mem
        2: PCI: 01:0a.0 20 *  [0x00000000 - 0x000fffff] mem
PCI: 01:0a.0 20 *  [0x00000000 - 0x000fffff] mem
        1: PCI: 01:02.0 14 *  [0x00000000 - 0x00000fff] mem
        2: PCI: 01:02.0 14 *  [0x00000000 - 0x00000fff] mem
PCI: 01:02.0 14 *  [0x00100000 - 0x00100fff] mem
        1: PCI: 01:03.0 10 *  [0x00000000 - 0x00000fff] mem
        2: PCI: 01:03.0 10 *  [0x00000000 - 0x00000fff] mem
PCI: 01:03.0 10 *  [0x00101000 - 0x00101fff] mem
        1: PCI: 01:05.0 18 *  [0x00000000 - 0x00000fff] mem
        2: PCI: 01:05.0 18 *  [0x00000000 - 0x00000fff] mem
PCI: 01:05.0 18 *  [0x00102000 - 0x00102fff] mem
        1: PCI: 01:08.0 24 *  [0x00000000 - 0x00000fff] mem
        2: PCI: 01:08.0 24 *  [0x00000000 - 0x00000fff] mem
PCI: 01:08.0 24 *  [0x00103000 - 0x00103fff] mem
        1: PCI: 01:09.0 24 *  [0x00000000 - 0x00000fff] mem
        2: PCI: 01:09.0 24 *  [0x00000000 - 0x00000fff] mem
PCI: 01:09.0 24 *  [0x00104000 - 0x00104fff] mem
        1: PCI: 01:0b.0 10 *  [0x00000000 - 0x00000fff] mem
        2: PCI: 01:0b.0 10 *  [0x00000000 - 0x00000fff] mem
PCI: 01:0b.0 10 *  [0x00105000 - 0x00105fff] mem
        1: PCI: 01:03.1 10 *  [0x00000000 - 0x000000ff] mem
        2: PCI: 01:03.1 10 *  [0x00000000 - 0x000000ff] mem
PCI: 01:03.1 10 *  [0x00106000 - 0x001060ff] mem
PCI: 00:18.0 compute_allocate_mem: base: 00106100 size: 00200000
align: 20 gran: 20 done
PCI: 00:18.0 compute_allocate_io: base: 00000000 size: 00000000 align:
12 gran: 12
PCI: 00:18.0 read_resources bus 4 link: 2
PCI: 04:02.0 compute_allocate_io: base: 00000000 size: 00000000 align:
12 gran: 12
PCI: 04:02.0 read_resources bus 6 link: 0
PCI: 04:02.0 read_resources bus 6 link: 0 done
        1: PCI: 06:06.0 10 *  [0x00000000 - 0x000000ff] io
        2: PCI: 06:06.0 10 *  [0x00000000 - 0x000000ff] io
PCI: 06:06.0 10 *  [0x00000000 - 0x000000ff] io
        1: PCI: 06:06.1 10 *  [0x00000000 - 0x000000ff] io
        2: PCI: 06:06.1 10 *  [0x00000000 - 0x000000ff] io
PCI: 06:06.1 10 *  [0x00000400 - 0x000004ff] io
PCI: 04:02.0 compute_allocate_io: base: 00000500 size: 00001000 align:
12 gran: 12 done
PCI: 04:02.0 compute_allocate_prefmem: base: 00000000 size: 00000000
align: 20 gran: 20
PCI: 04:02.0 read_resources bus 6 link: 0
PCI: 04:02.0 read_resources bus 6 link: 0 done
PCI: 04:02.0 compute_allocate_prefmem: base: 00000000 size: 00000000
align: 20 gran: 20 done
PCI: 04:02.0 compute_allocate_prefmem: base: fffffffffff00000 size:
00000000 align: 20 gran: 20
PCI: 04:02.0 read_resources bus 6 link: 0
PCI: 04:02.0 read_resources bus 6 link: 0 done
PCI: 04:02.0 compute_allocate_prefmem: base: fffffffffff00000 size:
00000000 align: 20 gran: 20 done
PCI: 04:02.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 6 prefmem
PCI: 04:02.0 compute_allocate_mem: base: 00000000 size: 00000000
align: 20 gran: 20
PCI: 04:02.0 read_resources bus 6 link: 0
PCI: 04:02.0 read_resources bus 6 link: 0 done
        1: PCI: 06:06.0 14 *  [0x00000000 - 0x000fffff] mem
        2: PCI: 06:06.0 14 *  [0x00000000 - 0x000fffff] mem
PCI: 06:06.0 14 *  [0x00000000 - 0x000fffff] mem
        1: PCI: 06:06.0 1c *  [0x00000000 - 0x000fffff] mem
        2: PCI: 06:06.0 1c *  [0x00000000 - 0x000fffff] mem
PCI: 06:06.0 1c *  [0x00100000 - 0x001fffff] mem
        1: PCI: 06:06.1 14 *  [0x00000000 - 0x000fffff] mem
        2: PCI: 06:06.1 14 *  [0x00000000 - 0x000fffff] mem
PCI: 06:06.1 14 *  [0x00200000 - 0x002fffff] mem
        1: PCI: 06:06.1 1c *  [0x00000000 - 0x000fffff] mem
        2: PCI: 06:06.1 1c *  [0x00000000 - 0x000fffff] mem
PCI: 06:06.1 1c *  [0x00300000 - 0x003fffff] mem
PCI: 04:02.0 compute_allocate_mem: base: 00400000 size: 00400000
align: 20 gran: 20 done
PCI: 00:18.0 read_resources bus 4 link: 2 done
        1: PCI: 04:02.0 1c *  [0x00000000 - 0x00000fff] io
        2: PCI: 04:02.0 1c *  [0x00000000 - 0x00000fff] io
PCI: 04:02.0 1c *  [0x00000000 - 0x00000fff] io
PCI: 00:18.0 compute_allocate_io: base: 00001000 size: 00001000 align:
12 gran: 12 done
PCI: 00:18.0 compute_allocate_prefmem: base: 00000000 size: 00000000
align: 20 gran: 20
PCI: 00:18.0 read_resources bus 4 link: 2
PCI: 00:18.0 read_resources bus 4 link: 2 done
PCI: 00:18.0 compute_allocate_prefmem: base: 00000000 size: 00000000
align: 20 gran: 20 done
PCI: 00:18.0 compute_allocate_mem: base: 00000000 size: 00000000
align: 20 gran: 20
PCI: 00:18.0 read_resources bus 4 link: 2
PCI: 00:18.0 read_resources bus 4 link: 2 done
        1: PCI: 04:02.0 20 *  [0x00000000 - 0x003fffff] mem
        2: PCI: 04:02.0 20 *  [0x00000000 - 0x003fffff] mem
PCI: 04:02.0 20 *  [0x00000000 - 0x003fffff] mem
        1: PCI: 04:01.1 10 *  [0x00000000 - 0x00000fff] mem
        2: PCI: 04:01.1 10 *  [0x00000000 - 0x00000fff] mem
PCI: 04:01.1 10 *  [0x00400000 - 0x00400fff] mem
        1: PCI: 04:02.1 10 *  [0x00000000 - 0x00000fff] mem
        2: PCI: 04:02.1 10 *  [0x00000000 - 0x00000fff] mem
PCI: 04:02.1 10 *  [0x00401000 - 0x00401fff] mem
PCI: 00:18.0 compute_allocate_mem: base: 00402000 size: 00500000
align: 20 gran: 20 done
PCI: 00:19.0 compute_allocate_io: base: 00000000 size: 00000000 align:
12 gran: 12
PCI: 00:19.0 read_resources bus 7 link: 0
<null> read_resources bus 0 link: 0
<null> read_resources bus 0 link: 0 done
PCI: 07:0f.0 compute_allocate_io: base: 00000000 size: 00000000 align:
12 gran: 12
PCI: 07:0f.0 read_resources bus 8 link: 0
PCI: 07:0f.0 read_resources bus 8 link: 0 done
PCI: 07:0f.0 compute_allocate_io: base: 00000000 size: 00000000 align:
12 gran: 12 done
PCI: 07:0f.0 compute_allocate_io: base: fffff000 size: 00000000 align:
12 gran: 12
PCI: 07:0f.0 read_resources bus 8 link: 0
PCI: 07:0f.0 read_resources bus 8 link: 0 done
PCI: 07:0f.0 compute_allocate_io: base: fffff000 size: 00000000 align:
12 gran: 12 done
PCI: 07:0f.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 8 io
PCI: 07:0f.0 compute_allocate_prefmem: base: 00000000 size: 00000000
align: 20 gran: 20
PCI: 07:0f.0 read_resources bus 8 link: 0
PCI: 07:0f.0 read_resources bus 8 link: 0 done
PCI: 07:0f.0 compute_allocate_prefmem: base: 00000000 size: 00000000
align: 20 gran: 20 done
PCI: 07:0f.0 compute_allocate_prefmem: base: fffffffffff00000 size:
00000000 align: 20 gran: 20
PCI: 07:0f.0 read_resources bus 8 link: 0
PCI: 07:0f.0 read_resources bus 8 link: 0 done
PCI: 07:0f.0 compute_allocate_prefmem: base: fffffffffff00000 size:
00000000 align: 20 gran: 20 done
PCI: 07:0f.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 8 prefmem
PCI: 07:0f.0 compute_allocate_mem: base: 00000000 size: 00000000
align: 20 gran: 20
PCI: 07:0f.0 read_resources bus 8 link: 0
PCI: 07:0f.0 read_resources bus 8 link: 0 done
PCI: 07:0f.0 compute_allocate_mem: base: 00000000 size: 00000000
align: 20 gran: 20 done
PCI: 07:0f.0 compute_allocate_mem: base: fff00000 size: 00000000
align: 20 gran: 20
PCI: 07:0f.0 read_resources bus 8 link: 0
PCI: 07:0f.0 read_resources bus 8 link: 0 done
PCI: 07:0f.0 compute_allocate_mem: base: fff00000 size: 00000000
align: 20 gran: 20 done
PCI: 07:0f.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 8 mem
PCI: 00:19.0 read_resources bus 7 link: 0 done
        1: PCI: 07:02.0 60 *  [0x00000000 - 0x000000ff] io
        2: PCI: 07:02.0 60 *  [0x00000000 - 0x000000ff] io
PCI: 07:02.0 60 *  [0x00000000 - 0x000000ff] io
        1: PCI: 07:02.0 64 *  [0x00000000 - 0x000000ff] io
        2: PCI: 07:02.0 64 *  [0x00000000 - 0x000000ff] io
PCI: 07:02.0 64 *  [0x00000400 - 0x000004ff] io
        1: PCI: 07:02.0 68 *  [0x00000000 - 0x000000ff] io
        2: PCI: 07:02.0 68 *  [0x00000000 - 0x000000ff] io
PCI: 07:02.0 68 *  [0x00000800 - 0x000008ff] io
        1: PCI: 07:02.0 10 *  [0x00000000 - 0x0000007f] io
        2: PCI: 07:02.0 10 *  [0x00000000 - 0x0000007f] io
PCI: 07:02.0 10 *  [0x00000c00 - 0x00000c7f] io
        1: PCI: 07:0b.0 14 *  [0x00000000 - 0x00000007] io
        2: PCI: 07:0b.0 14 *  [0x00000000 - 0x00000007] io
PCI: 07:0b.0 14 *  [0x00000c80 - 0x00000c87] io
PCI: 00:19.0 compute_allocate_io: base: 00000c88 size: 00001000 align:
12 gran: 12 done
PCI: 00:19.0 compute_allocate_prefmem: base: 00000000 size: 00000000
align: 20 gran: 20
PCI: 00:19.0 read_resources bus 7 link: 0
PCI: 00:19.0 read_resources bus 7 link: 0 done
PCI: 00:19.0 compute_allocate_prefmem: base: 00000000 size: 00000000
align: 20 gran: 20 done
PCI: 00:19.0 compute_allocate_mem: base: 00000000 size: 00000000
align: 20 gran: 20
PCI: 00:19.0 read_resources bus 7 link: 0
PCI: 00:19.0 read_resources bus 7 link: 0 done
        1: PCI: 07:02.0 14 *  [0x00000000 - 0x00000fff] mem
        2: PCI: 07:02.0 14 *  [0x00000000 - 0x00000fff] mem
PCI: 07:02.0 14 *  [0x00000000 - 0x00000fff] mem
        1: PCI: 07:0b.0 10 *  [0x00000000 - 0x00000fff] mem
        2: PCI: 07:0b.0 10 *  [0x00000000 - 0x00000fff] mem
PCI: 07:0b.0 10 *  [0x00001000 - 0x00001fff] mem
PCI: 00:19.0 compute_allocate_mem: base: 00002000 size: 00100000
align: 20 gran: 20 done
PCI_DOMAIN: 0000 read_resources bus 0 link: 0 done
Root Device read_resources bus 0 link: 0 done
        1: PCI: 00:18.0 1c0 *  [0x00000000 - 0x00001fff] io
        2: PCI: 00:18.0 1c0 *  [0x00000000 - 0x00001fff] io
PCI: 00:18.0 1c0 *  [0x00001000 - 0x00002fff] io
        1: PCI: 00:18.0 1ca *  [0x00000000 - 0x00000fff] io
        2: PCI: 00:18.0 1ca *  [0x00000000 - 0x00000fff] io
PCI: 00:18.0 1ca *  [0x00003000 - 0x00003fff] io
        1: PCI: 00:19.0 1d0 *  [0x00000000 - 0x00000fff] io
        2: PCI: 00:19.0 1d0 *  [0x00000000 - 0x00000fff] io
PCI: 00:19.0 1d0 *  [0x00004000 - 0x00004fff] io
Root Device compute_allocate_io: base: 00005000 size: 00004c00 align:
12 gran: 0 done
Root Device compute_allocate_mem: base: 00000000 size: 00000000 align: 0 gran: 0
Root Device read_resources bus 0 link: 0
Root Device read_resources bus 0 link: 0 done
        1: PCI: 00:18.3 94 *  [0x00000000 - 0x03ffffff] mem
        2: PCI: 00:18.3 94 *  [0x00000000 - 0x03ffffff] mem
PCI: 00:18.3 94 *  [0x00000000 - 0x03ffffff] mem
        1: PCI: 00:18.0 1a2 *  [0x00000000 - 0x004fffff] mem
        2: PCI: 00:18.0 1a2 *  [0x00000000 - 0x004fffff] mem
PCI: 00:18.0 1a2 *  [0x04000000 - 0x044fffff] mem
        1: PCI: 00:18.0 1b0 *  [0x00000000 - 0x001fffff] mem
        2: PCI: 00:18.0 1b0 *  [0x00000000 - 0x001fffff] mem
PCI: 00:18.0 1b0 *  [0x04500000 - 0x046fffff] mem
        1: PCI: 00:19.0 190 *  [0x00000000 - 0x000fffff] mem
        2: PCI: 00:19.0 190 *  [0x00000000 - 0x000fffff] mem
PCI: 00:19.0 190 *  [0x04700000 - 0x047fffff] mem
        1: PCI: 00:18.0 1b8 *  [0x00000000 - 0xffffffffffffffff] prefmem
        2: PCI: 00:18.0 1b8 *  [0x00000000 - 0xffffffffffffffff] prefmem
PCI: 00:18.0 1b8 *  [0x04800000 - 0x047fffff] prefmem
        1: PCI: 00:18.0 1aa *  [0x00000000 - 0xffffffffffffffff] prefmem
        2: PCI: 00:18.0 1aa *  [0x00000000 - 0xffffffffffffffff] prefmem
PCI: 00:18.0 1aa *  [0x04800000 - 0x047fffff] prefmem
        1: PCI: 00:19.0 198 *  [0x00000000 - 0xffffffffffffffff] prefmem
        2: PCI: 00:19.0 198 *  [0x00000000 - 0xffffffffffffffff] prefmem
PCI: 00:19.0 198 *  [0x04800000 - 0x047fffff] prefmem
Root Device compute_allocate_mem: base: 04800000 size: 04800000 align:
26 gran: 0 done
Done reading resources.
Setting resources...
Root Device compute_allocate_io: base: 00001000 size: 00004c00 align: 12 gran: 0
Root Device read_resources bus 0 link: 0
Root Device read_resources bus 0 link: 0 done
        1: PCI: 00:18.0 1c0 *  [0x00001000 - 0x00002fff] io
        2: PCI: 00:18.0 1c0 *  [0x00001000 - 0x00002fff] io
PCI: 00:18.0 1c0 *  [0x00001000 - 0x00002fff] io
        1: PCI: 00:18.0 1ca *  [0x00003000 - 0x00003fff] io
        2: PCI: 00:18.0 1ca *  [0x00003000 - 0x00003fff] io
PCI: 00:18.0 1ca *  [0x00003000 - 0x00003fff] io
        1: PCI: 00:19.0 1d0 *  [0x00004000 - 0x00004fff] io
        2: PCI: 00:19.0 1d0 *  [0x00004000 - 0x00004fff] io
PCI: 00:19.0 1d0 *  [0x00004000 - 0x00004fff] io
Root Device compute_allocate_io: base: 00005000 size: 00004000 align:
12 gran: 0 done



From steve at digidescorp.com  Wed Jul  6 01:04:38 2005
From: steve at digidescorp.com (Steve Magnani)
Date: Tue, 05 Jul 2005 18:04:38 -0500
Subject: [LinuxBIOS] Re: dead loop in compute_allocate_resource
Message-ID: <WorldClient-F200507051804.AA04380031@digidescorp.com>

I ran into something similar over the weekend, with a s2735 variant (Intel
7501 Xeon development kit) I'm working on. I had assumed it was something
I did wrong in Config.lb - I set the USB and IDE devices "on" even though
my southbridge LPC setup disables them. When I set the USB and IDE devices
"off" in Config.lb my problem went away. Not a solution, I know, but it
might help track down the problem.

Steve





From steve at digidescorp.com  Wed Jul  6 01:07:35 2005
From: steve at digidescorp.com (Steve Magnani)
Date: Tue, 05 Jul 2005 18:07:35 -0500
Subject: [LinuxBIOS] Re: dead loop in compute_allocate_resource
In-Reply-To: <WorldClient-F200507051804.AA04380031@digidescorp.com>
References: <WorldClient-F200507051804.AA04380031@digidescorp.com>
Message-ID: <WorldClient-F200507051807.AA07350032@digidescorp.com>

Might be the keyboard or floppy, too - I turned those off as well.

Steve
-----Original Message-----
From: "Steve Magnani" <steve at digidescorp.com>
To: linuxbios at openbios.org, yinghailu at gmail.com, ebiederman at lnxi.com
Date: Tue, 05 Jul 2005 18:04:38 -0500
Subject: Re: dead loop in compute_allocate_resource

> I ran into something similar over the weekend, with a s2735 variant
> (Intel
> 7501 Xeon development kit) I'm working on. I had assumed it was
> something
> I did wrong in Config.lb - I set the USB and IDE devices "on" even
> though
> my southbridge LPC setup disables them. When I set the USB and IDE
> devices
> "off" in Config.lb my problem went away. Not a solution, I know, but it
> might help track down the problem.
> 
> Steve





From yinghailu at gmail.com  Wed Jul  6 02:31:01 2005
From: yinghailu at gmail.com (yhlu)
Date: Tue, 5 Jul 2005 17:31:01 -0700
Subject: [LinuxBIOS] Re: dead loop in compute_allocate_resource
In-Reply-To: <WorldClient-F200507051807.AA07350032@digidescorp.com>
References: <WorldClient-F200507051804.AA04380031@digidescorp.com>
	<WorldClient-F200507051807.AA07350032@digidescorp.com>
Message-ID: <2ea3fae10507051731c5dd0bf@mail.gmail.com>

I enable enable com1 get it through. ....

YH

PCI: 00:1f.2 20 *  [0x000030a0 - 0x000030af] io
        1: PNP: 002e.2 60 *  [0x000003f8 - 0x000003ff] io
        1: PCI: 00:1f.2 10 *  [0x000030b0 - 0x000030b7] io
        2: PCI: 00:1f.2 10 *  [0x000030b0 - 0x000030b7] io

On 7/5/05, Steve Magnani <steve at digidescorp.com> wrote:
> Might be the keyboard or floppy, too - I turned those off as well.
> 
> Steve
> -----Original Message-----
> From: "Steve Magnani" <steve at digidescorp.com>
> To: linuxbios at openbios.org, yinghailu at gmail.com, ebiederman at lnxi.com
> Date: Tue, 05 Jul 2005 18:04:38 -0500
> Subject: Re: dead loop in compute_allocate_resource
> 
> > I ran into something similar over the weekend, with a s2735 variant
> > (Intel
> > 7501 Xeon development kit) I'm working on. I had assumed it was
> > something
> > I did wrong in Config.lb - I set the USB and IDE devices "on" even
> > though
> > my southbridge LPC setup disables them. When I set the USB and IDE
> > devices
> > "off" in Config.lb my problem went away. Not a solution, I know, but it
> > might help track down the problem.
> >
> > Steve
> 
> 
>



From yinghailu at gmail.com  Wed Jul  6 03:54:08 2005
From: yinghailu at gmail.com (yhlu)
Date: Tue, 5 Jul 2005 18:54:08 -0700
Subject: [LinuxBIOS] Re: dead loop in compute_allocate_resource
In-Reply-To: <2ea3fae10507051731c5dd0bf@mail.gmail.com>
References: <WorldClient-F200507051804.AA04380031@digidescorp.com>
	<WorldClient-F200507051807.AA07350032@digidescorp.com>
	<2ea3fae10507051731c5dd0bf@mail.gmail.com>
Message-ID: <2ea3fae1050705185461bd62c7@mail.gmail.com>

solution will be add
if (resource->flags & IORESOURCE_FIXED)  return 
in pick_largest_resource.

YH


--- device.c.orig       2005-06-22 12:54:44.000000000 -0700
+++ device.c    2005-07-05 19:32:20.000000000 -0700
@@ -180,6 +180,7 @@
                state->seen_last = 1;
                return;
        }
+       if (resource->flags & IORESOURCE_FIXED ) return; //skip it 
        if (last && (
                    (last->align < resource->align) ||
                    ((last->align == resource->align) &&



From ebiederman at lnxi.com  Wed Jul  6 05:09:56 2005
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue, 05 Jul 2005 21:09:56 -0600
Subject: [LinuxBIOS] Re: dead loop in compute_allocate_resource
In-Reply-To: <2ea3fae1050705185461bd62c7@mail.gmail.com> (yinghailu@gmail.com's
	message of "Tue, 5 Jul 2005 18:54:08 -0700")
References: <WorldClient-F200507051804.AA04380031@digidescorp.com>
	<WorldClient-F200507051807.AA07350032@digidescorp.com>
	<2ea3fae10507051731c5dd0bf@mail.gmail.com>
	<2ea3fae1050705185461bd62c7@mail.gmail.com>
Message-ID: <m3r7ecvddn.fsf@maxwell.lnxi.com>

yhlu <yinghailu at gmail.com> writes:

> solution will be add
> if (resource->flags & IORESOURCE_FIXED)  return 
> in pick_largest_resource.

This solution seems suspicious.  I would expect this to have
triggered before if a proper fix was as simple as that.

Eric



From yinghailu at gmail.com  Wed Jul  6 07:11:56 2005
From: yinghailu at gmail.com (yhlu)
Date: Tue, 5 Jul 2005 22:11:56 -0700
Subject: [LinuxBIOS] Re: dead loop in compute_allocate_resource
In-Reply-To: <m3r7ecvddn.fsf@maxwell.lnxi.com>
References: <WorldClient-F200507051804.AA04380031@digidescorp.com>
	<WorldClient-F200507051807.AA07350032@digidescorp.com>
	<2ea3fae10507051731c5dd0bf@mail.gmail.com>
	<2ea3fae1050705185461bd62c7@mail.gmail.com>
	<m3r7ecvddn.fsf@maxwell.lnxi.com>
Message-ID: <2ea3fae105070522119ea0905@mail.gmail.com>

actually you are using 

if (resource->flags & IORESOURCE_FIXED) {
         continue;
}

in the main loop

YH

On 7/5/05, Eric W. Biederman <ebiederman at lnxi.com> wrote:
> yhlu <yinghailu at gmail.com> writes:
> 
> > solution will be add
> > if (resource->flags & IORESOURCE_FIXED)  return
> > in pick_largest_resource.
> 
> This solution seems suspicious.  I would expect this to have
> triggered before if a proper fix was as simple as that.
> 
> Eric
>



From kfuchs at winternet.com  Sat Jul  9 01:08:02 2005
From: kfuchs at winternet.com (Ken Fuchs)
Date: Fri, 8 Jul 2005 18:08:02 -0500 (CDT)
Subject: [LinuxBIOS] LinuxBIOS article in the August Linux Journal
Message-ID: <200507082308.j68N82fI011139@tundra.winternet.com>

Congratulations, Ron!  "Porting LinuxBIOS to the AMD SC520" is a
wonderful article.  It describes very well the basics required by a
LinuxBIOS newbie to understand LinuxBIOS and potentially do his own
port to a new motherboard.  It also had enough detail to make it
interesting to those of us who have been using and developing
LinuxBIOS for months or even years.

The article is on-line at:
http://www.linuxjournal.com/article/8120

Thank you Linux Journal for publishing and especially publishing it
immediately on-line.  (Linux Journal plans to use LinuxBIOS in next
year's Ultimate Linux Box.)

I hope Ron's article inspires scores of developers to join the
LinuxBIOS project and enable us to port LinuxBIOS to all the high
volume server/desktop/laptop/embedded mainboards plus all the lower
volume mainboards that are particularly suited to all project member's
applications.

Sincerely,

Ken Fuchs <kfuchs at winternet.com>



From rminnich at lanl.gov  Sat Jul  9 03:08:28 2005
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Fri, 8 Jul 2005 19:08:28 -0600 (MDT)
Subject: [LinuxBIOS] LinuxBIOS article in the August Linux Journal
In-Reply-To: <200507082308.j68N82fI011139@tundra.winternet.com>
References: <200507082308.j68N82fI011139@tundra.winternet.com>
Message-ID: <Pine.LNX.4.58.0507081907470.7123@enigma.lanl.gov>

thanks, Ken. There is a soon-to-be published article on "getting it done" 
on the web site. I just have to get it going first :-)

this has been a hard chip, it's amazing how much "it must be a 586 or 
later" chip is in all our code nowadays, such as FILO, ...

ron




From cro_marmot at comcast.net  Sun Jul 10 04:11:30 2005
From: cro_marmot at comcast.net (David Hendricks)
Date: Sat, 9 Jul 2005 19:11:30 -0700
Subject: [LinuxBIOS] Winbond w39v040a support for flash_rom
Message-ID: <20050709191130.2a78aa53@sunder>

First attempt at adding support for this chip in flash_rom. It's
basically the same as a W49F002U, only different total and page sizes.
Attached are my tla file-diffs for flash.h and flash_rom.c and also .c
and .h files for the chip itself.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: flash.h.diff
Type: text/x-patch
Size: 456 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20050709/fd8d9a9b/attachment.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: flash_rom.c.diff
Type: text/x-patch
Size: 735 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20050709/fd8d9a9b/attachment-0001.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: w39v040a.c
Type: text/x-csrc
Size: 1637 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20050709/fd8d9a9b/attachment.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: w39v040a.h
Type: text/x-chdr
Size: 153 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20050709/fd8d9a9b/attachment.h>

From cro_marmot at comcast.net  Sun Jul 10 04:22:57 2005
From: cro_marmot at comcast.net (David Hendricks)
Date: Sat, 9 Jul 2005 19:22:57 -0700
Subject: [LinuxBIOS] LinuxBIOS article in the August Linux Journal
In-Reply-To: <200507082308.j68N82fI011139@tundra.winternet.com>
References: <200507082308.j68N82fI011139@tundra.winternet.com>
Message-ID: <20050709192257.2c486f7f@sunder>

Yeah, great article indeed! It was pointed out to me a few days ago by
one of the students working with the Portland State Aerospace Society.
Hopefully the article has rekindled their interest in using LinuxBIOS, I
think they're even using an SC520.

On Fri, 8 Jul 2005 18:08:02 -0500 (CDT)
Ken Fuchs <kfuchs at winternet.com> wrote:

> Congratulations, Ron!  "Porting LinuxBIOS to the AMD SC520" is a
> wonderful article.  It describes very well the basics required by a
> LinuxBIOS newbie to understand LinuxBIOS and potentially do his own
> port to a new motherboard.  It also had enough detail to make it
> interesting to those of us who have been using and developing
> LinuxBIOS for months or even years.
> 
> The article is on-line at:
> http://www.linuxjournal.com/article/8120
> 
> Thank you Linux Journal for publishing and especially publishing it
> immediately on-line.  (Linux Journal plans to use LinuxBIOS in next
> year's Ultimate Linux Box.)
> 
> I hope Ron's article inspires scores of developers to join the
> LinuxBIOS project and enable us to port LinuxBIOS to all the high
> volume server/desktop/laptop/embedded mainboards plus all the lower
> volume mainboards that are particularly suited to all project member's
> applications.
> 
> Sincerely,
> 
> Ken Fuchs <kfuchs at winternet.com>
> 
> _______________________________________________
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios



From hemksu at yahoo.co.in  Tue Jul 12 08:46:52 2005
From: hemksu at yahoo.co.in (hema ku)
Date: Tue, 12 Jul 2005 07:46:52 +0100 (BST)
Subject: [LinuxBIOS] sa1100
Message-ID: <20050712064652.70780.qmail@web8407.mail.in.yahoo.com>



hello
     i am new to linuxbios,
     
     i have p4-2.4GHz , and 256MB RAM,
   linux-2.4.20-8(redhat) and linux-2.6-12
   gcc-3.2 
    
   i want try on this board
   
   later i want to try on SA1100 
    does SA1100 is supported

   and where can iget doc for linuxbios

thanking u
hemanth
 


		
__________________________________________________________
How much free photo storage do you get? Store your friends 'n family snaps for FREE with Yahoo! Photos http://in.photos.yahoo.com



From kfuchs at winternet.com  Tue Jul 12 16:38:07 2005
From: kfuchs at winternet.com (Ken Fuchs)
Date: Tue, 12 Jul 2005 09:38:07 -0500 (CDT)
Subject: [LinuxBIOS] sa1100
Message-ID: <200507121438.j6CEc7eu005965@tundra.winternet.com>

Hemanth wrote:

>     i have p4-2.4GHz , and 256MB RAM,
>   linux-2.4.20-8(redhat) and linux-2.6-12
>   gcc-3.2 
    
>   i want try on this board
   
>   later i want to try on SA1100 
>   does SA1100 is supported

Boot Linux on both mainboards (if possible) with the original BIOS
installed and run lspci.  lspci will display all PCI devices.
Post your question again with the lspci output.

More detailed comments:

There are very few Pentium 4 mainboards supported by LinuxBIOS.
Support for Opteron and AMD64 mainboards is much better.

The SA1100 is a StrongARM processor.  Is that what you meant?
Or, is SA1100 also the name of a mainboard and you want to know if the
mainboard SA1100 is supported?

Please provide more information like a URL to the products you are
interested in having LinuxBIOS support for.  Or, as mentioned above,
just provide the Linux lspci output.

Sincerely,

Ken Fuchs <kfuchs at winternet.com>



From huangjen.wang at gmail.com  Wed Jul 13 03:53:50 2005
From: huangjen.wang at gmail.com (Huang-Jen Wang)
Date: Wed, 13 Jul 2005 09:53:50 +0800
Subject: [LinuxBIOS] Missing read_resources
Message-ID: <4325815c05071218533f06e35e@mail.gmail.com>

Dear all,
my pci device got a "missing read_resource" from serial console,
why this happens and how to solve it...Thanks....



From keven at insomniatechnology.com  Wed Jul 13 19:13:56 2005
From: keven at insomniatechnology.com (Keven Tipping)
Date: Wed, 13 Jul 2005 11:13:56 -0600
Subject: [LinuxBIOS] Linux BIOS on Embedded board
Message-ID: <42D54BD4.4050808@insomniatechnology.com>

Greetings to all!

I hope this is the correct address to use when posting- I'm somewhat new 
to the whole mailing list thing.

Anyways. I recently picked up a nice PCM-5820 Rev. B2 Board, made by 
Advantech. It runs a GX1 300mhz Processor, 256mb PC100 Ram (SODIMM), and 
2 40gb Samsung IDE Drives.

The unit also has 2 USB 1.1 ports, AC97 Audio, Realtek RL8139 10/10 
Ethernet.

I'm planning on running Linux, probably Fedora Core 3/4 on the machine, 
as a VPN endpoint and network server serving up SMB/NFS. It might 
eventually be used as a MP3 player for my home theater system, so I do 
need audio capabilities. The two USB ports are being dedicated to a 
Crystalfontz 635 and 634 displays, which will be used to monitor and 
control the system heedlessly.

I'm wondering- will LinuxBIOS run on this machine properly? It has no 
expansion so-to-say, just PC104 which will remain unused. I've heard 
things about the Audio and Graphics for the unit, but nothing definite. 
Will this board run LinuxBIOS, with Video and Audio capabilities?

If I have to, I'll grab one of those nifty swap-a-bios chips that lets 
me select between the Advantech Phoenix BIOS and the Linux BIOS. This 
system will be encased in a acrylic case (custom made, laser cut), so 
this is more of a hobby then anything else, but I'd like to have a 
system running Linux that boots Linux BIOS for the kick of it.

Cheers!
Keven Tipping



From rminnich at lanl.gov  Wed Jul 13 21:15:24 2005
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Wed, 13 Jul 2005 13:15:24 -0600 (MDT)
Subject: [LinuxBIOS] Linux BIOS on Embedded board
In-Reply-To: <42D54BD4.4050808@insomniatechnology.com>
References: <42D54BD4.4050808@insomniatechnology.com>
Message-ID: <Pine.LNX.4.58.0507131315150.17718@enigma.lanl.gov>

let's hope Hamish posts, he is our GX1 expert.

ron




From hamish at prodigi.ch  Wed Jul 13 19:33:40 2005
From: hamish at prodigi.ch (Hamish Guthrie)
Date: Wed, 13 Jul 2005 19:33:40 +0200
Subject: [LinuxBIOS] Linux BIOS on Embedded board
In-Reply-To: <42D54BD4.4050808@insomniatechnology.com>
Message-ID: <42CB976B00309D24@mta-fs-be-01.sunrise.ch> (added by
	postmaster@sunrise.ch)

Sorry if this is posted twice, but am having problems with mail clients!

There is GX1 support in LinuxBIOS - Graphics and Audio are a little tricky
with the Geode processors, but we are working on implementing the VSA
firmware into LinuxBIOS at the moment. I have a workaround running for this
at the moment, so it is doable, but a proper implementation will be
following in the not too distant future once I have a pressing project out
of the way in the next week or so.

Essentially, you will be good to go with this, but there may be a bit of
work involved!

Hamish

-----Original Message-----
From: linuxbios-bounces at openbios.org [mailto:linuxbios-bounces at openbios.org]
On Behalf Of Keven Tipping
Sent: Wednesday, July 13, 2005 7:14 PM
To: linuxbios at openbios.org
Subject: [LinuxBIOS] Linux BIOS on Embedded board

Greetings to all!

I hope this is the correct address to use when posting- I'm somewhat new 
to the whole mailing list thing.

Anyways. I recently picked up a nice PCM-5820 Rev. B2 Board, made by 
Advantech. It runs a GX1 300mhz Processor, 256mb PC100 Ram (SODIMM), and 
2 40gb Samsung IDE Drives.

The unit also has 2 USB 1.1 ports, AC97 Audio, Realtek RL8139 10/10 
Ethernet.

I'm planning on running Linux, probably Fedora Core 3/4 on the machine, 
as a VPN endpoint and network server serving up SMB/NFS. It might 
eventually be used as a MP3 player for my home theater system, so I do 
need audio capabilities. The two USB ports are being dedicated to a 
Crystalfontz 635 and 634 displays, which will be used to monitor and 
control the system heedlessly.

I'm wondering- will LinuxBIOS run on this machine properly? It has no 
expansion so-to-say, just PC104 which will remain unused. I've heard 
things about the Audio and Graphics for the unit, but nothing definite. 
Will this board run LinuxBIOS, with Video and Audio capabilities?

If I have to, I'll grab one of those nifty swap-a-bios chips that lets 
me select between the Advantech Phoenix BIOS and the Linux BIOS. This 
system will be encased in a acrylic case (custom made, laser cut), so 
this is more of a hobby then anything else, but I'd like to have a 
system running Linux that boots Linux BIOS for the kick of it.

Cheers!
Keven Tipping

_______________________________________________
LinuxBIOS mailing list
LinuxBIOS at openbios.org
http://www.openbios.org/mailman/listinfo/linuxbios




From steve at digidescorp.com  Thu Jul 14 12:38:59 2005
From: steve at digidescorp.com (Steve Magnani)
Date: Thu, 14 Jul 2005 05:38:59 -0500
Subject: [LinuxBIOS] etherboot with LinuxBIOS
Message-ID: <WorldClient-F200507140538.AA38590034@digidescorp.com>

On Wed May 25 14:13:05 2005, Stephen.Kimball at bench.com  wrote:
> Does anyone know how to build etherboot with a current version of gcc?
> I am using gcc version 3.4.3 and binutils 2.15.
> I've tried several etherboot versions up to 5.4.0.
> I know etherboot 5.2.6 with gcc 3.2.2 works, but that's an old version
of > gcc.  Thanks.

Steve - Did you ever find a resolution to this? I didn't see any followups
on the mailing list. I have the same toolchain as you, so if there's a way
to avoid building another one just for Etherboot I'd like to know!

Thanks,
Steve Magnani





From hemksu at yahoo.co.in  Thu Jul 14 13:57:47 2005
From: hemksu at yahoo.co.in (hema ku)
Date: Thu, 14 Jul 2005 12:57:47 +0100 (BST)
Subject: [LinuxBIOS] SA1100
Message-ID: <20050714115747.2313.qmail@web8406.mail.in.yahoo.com>



hello 

  i have bought new AMD machine , SA1100 SBC

on AMD i did lspci

00:00.0 Host bridge: nVidia Corporation: Unknown
device 00e1 (rev a1)
00:01.0 ISA bridge: nVidia Corporation: Unknown device
00e0 (rev a2)
00:01.1 SMBus: nVidia Corporation: Unknown device 00e4
(rev a1)
00:02.0 USB Controller: nVidia Corporation: Unknown
device 00e7 (rev a1)
00:02.1 USB Controller: nVidia Corporation: Unknown
device 00e7 (rev a1)
00:02.2 USB Controller: nVidia Corporation: Unknown
device 00e8 (rev a2)
00:06.0 Multimedia audio controller: nVidia
Corporation: Unknown device 00ea (rev a1)
00:08.0 IDE interface: nVidia Corporation: Unknown
device 00e5 (rev a2)
00:0a.0 IDE interface: nVidia Corporation: Unknown
device 00e3 (rev a2)
00:0b.0 PCI bridge: nVidia Corporation: Unknown device
00e2 (rev a2)
00:0e.0 PCI bridge: nVidia Corporation: Unknown device
00ed (rev a2)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8
NorthBridge
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8
NorthBridge
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8
NorthBridge
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8
NorthBridge
01:00.0 VGA compatible controller: nVidia Corporation
NV34 [GeForce FX 5200] (rev a1)
02:08.0 Ethernet controller: Compex ReadyLink 2000
(rev 0a)

runing on linux-2.4.21 (RHEL WS)
i have 2.6.12 also on that

how do i go from here , how i install linux bios

i dont have command on lspci on sa1100
i trying to cross compiling for lspci

how do i start


thanking in advance
hemanth






		
_______________________________________________________
Too much spam in your inbox? Yahoo! Mail gives you the best spam protection for FREE! http://in.mail.yahoo.com



From Stephen.Kimball at bench.com  Thu Jul 14 14:39:19 2005
From: Stephen.Kimball at bench.com (Stephen.Kimball at bench.com)
Date: Thu, 14 Jul 2005 08:39:19 -0400
Subject: [LinuxBIOS] etherboot with LinuxBIOS
Message-ID: <0924961839F8364D9097FC8FFA43400C19BB52@nh-ex03.bench.com>

The easiest way to build Etherboot 5.2.6 is to use gcc 3.2.2.
I found another machine and built an old gcc and etherboot compiled.

I got errors with the new gcc, tried to fix them, but could never get it
to compile.  It would be good, if someone knowledgeable could make
etherboot work on the current gcc.

Steve

-----Original Message-----
From: Steve Magnani [mailto:steve at digidescorp.com] 
Sent: Thursday, July 14, 2005 6:39 AM
To: Kimball, Stephen; linuxbios at openbios.org
Subject: RE: [LinuxBIOS] etherboot with LinuxBIOS

On Wed May 25 14:13:05 2005, Stephen.Kimball at bench.com  wrote:
> Does anyone know how to build etherboot with a current version of gcc?
> I am using gcc version 3.4.3 and binutils 2.15.
> I've tried several etherboot versions up to 5.4.0.
> I know etherboot 5.2.6 with gcc 3.2.2 works, but that's an old version
of > gcc.  Thanks.

Steve - Did you ever find a resolution to this? I didn't see any
followups
on the mailing list. I have the same toolchain as you, so if there's a
way
to avoid building another one just for Etherboot I'd like to know!

Thanks,
Steve Magnani





From steve at digidescorp.com  Thu Jul 14 16:58:50 2005
From: steve at digidescorp.com (Steven J. Magnani)
Date: Thu, 14 Jul 2005 09:58:50 -0500
Subject: [LinuxBIOS] etherboot with LinuxBIOS
In-Reply-To: <0924961839F8364D9097FC8FFA43400C19BB52@nh-ex03.bench.com>
Message-ID: <000001c58884$8eae5ee0$6ffea8c0@banana>

Etherboot 5.4.0 seems to compile with gcc-3.4.3 if, in addition to the
config changes spelled out on the Wiki, you also comment out PXE support
in src/Config:

# Etherboot as a PXE network protocol ROM
#CFLAGS+=	-DPXE_IMAGE -DPXE_EXPORT

Seems to run, but I haven't reached a point where I can boot something
over the network yet.

Steve
www.digidescorp.com






From yinghailu at gmail.com  Thu Jul 14 17:07:50 2005
From: yinghailu at gmail.com (yhlu)
Date: Thu, 14 Jul 2005 08:07:50 -0700
Subject: [LinuxBIOS] SA1100
In-Reply-To: <20050714115747.2313.qmail@web8406.mail.in.yahoo.com>
References: <20050714115747.2313.qmail@web8406.mail.in.yahoo.com>
Message-ID: <2ea3fae10507140807354c48f@mail.gmail.com>

It looks like a Nvidia ck8s or NForce3 chipset with Opteron or athlon 64.

Current We only support Nvidia CK804 or NForce4 Chipset.

actually If someone can get Nvidia authentication from Nvidia, I could
make ck8s support for LinuxBIOS.

It seems Nvidia C51G is CK804+IGP (NV...), that one should be more
easier to be supported.

I guess the Laptop with c51g would be first Laptop that support
LinuxBIOS. but I can not wait to long, and I will use ATI xpress 200m
at first.

YH

On 7/14/05, hema ku <hemksu at yahoo.co.in> wrote:
> 
> 
> hello
> 
>  i have bought new AMD machine , SA1100 SBC
> 
> on AMD i did lspci
> 
> 00:00.0 Host bridge: nVidia Corporation: Unknown
> device 00e1 (rev a1)
> 00:01.0 ISA bridge: nVidia Corporation: Unknown device
> 00e0 (rev a2)
> 00:01.1 SMBus: nVidia Corporation: Unknown device 00e4
> (rev a1)
> 00:02.0 USB Controller: nVidia Corporation: Unknown
> device 00e7 (rev a1)
> 00:02.1 USB Controller: nVidia Corporation: Unknown
> device 00e7 (rev a1)
> 00:02.2 USB Controller: nVidia Corporation: Unknown
> device 00e8 (rev a2)
> 00:06.0 Multimedia audio controller: nVidia
> Corporation: Unknown device 00ea (rev a1)
> 00:08.0 IDE interface: nVidia Corporation: Unknown
> device 00e5 (rev a2)
> 00:0a.0 IDE interface: nVidia Corporation: Unknown
> device 00e3 (rev a2)
> 00:0b.0 PCI bridge: nVidia Corporation: Unknown device
> 00e2 (rev a2)
> 00:0e.0 PCI bridge: nVidia Corporation: Unknown device
> 00ed (rev a2)
> 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8
> NorthBridge
> 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8
> NorthBridge
> 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8
> NorthBridge
> 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8
> NorthBridge
> 01:00.0 VGA compatible controller: nVidia Corporation
> NV34 [GeForce FX 5200] (rev a1)
> 02:08.0 Ethernet controller: Compex ReadyLink 2000
> (rev 0a)
> 
> runing on linux-2.4.21 (RHEL WS)
> i have 2.6.12 also on that
> 
> how do i go from here , how i install linux bios
> 
> i dont have command on lspci on sa1100
> i trying to cross compiling for lspci
> 
> how do i start
> 
> 
> thanking in advance
> hemanth
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________________
> Too much spam in your inbox? Yahoo! Mail gives you the best spam protection for FREE! http://in.mail.yahoo.com
> 
> _______________________________________________
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>



From yinghailu at gmail.com  Thu Jul 14 17:10:03 2005
From: yinghailu at gmail.com (yhlu)
Date: Thu, 14 Jul 2005 08:10:03 -0700
Subject: [LinuxBIOS] etherboot with LinuxBIOS
In-Reply-To: <000001c58884$8eae5ee0$6ffea8c0@banana>
References: <0924961839F8364D9097FC8FFA43400C19BB52@nh-ex03.bench.com>
	<000001c58884$8eae5ee0$6ffea8c0@banana>
Message-ID: <2ea3fae105071408101e90b823@mail.gmail.com>

do not use 5.4 at this time, because the memtest can not be loaded by
Etherboot 5.4 correctly.

YH

On 7/14/05, Steven J. Magnani <steve at digidescorp.com> wrote:
> Etherboot 5.4.0 seems to compile with gcc-3.4.3 if, in addition to the
> config changes spelled out on the Wiki, you also comment out PXE support
> in src/Config:
> 
> # Etherboot as a PXE network protocol ROM
> #CFLAGS+=       -DPXE_IMAGE -DPXE_EXPORT
> 
> Seems to run, but I haven't reached a point where I can boot something
> over the network yet.
> 
> Steve
> www.digidescorp.com
> 
> 
> 
> 
> _______________________________________________
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>



From yinghailu at gmail.com  Thu Jul 14 19:58:16 2005
From: yinghailu at gmail.com (yhlu)
Date: Thu, 14 Jul 2005 10:58:16 -0700
Subject: [LinuxBIOS] NUMA support for dual core Opteron
Message-ID: <2ea3fae10507141058c476927@mail.gmail.com>

Someone mentioned that NUMA support for dual core opteron need acpi
support in LinuxBIOS.

there may be some other solution for that.
1. PowerPC already support dual core and it should support NUMA, So
the Open Firmware must have some NUMA entry definition.
Can we make x86-64 kernel support OpenFirmware interface so we can use
OpenBIOS as payload of LinuxBIOS.
2. enable acpi and add the NUMA entries into it, the Linux Kernel will be happy.
3. If we are trying to use ADLO to load Windows/Solaris/FreeBSD, We
need to pass related acpi info to ADLO....

Solution 1 will be ideal one, and can make Solaris for X86-64 use
OpenFirmware interface too.....

which one is better?

YH



From ollie at lanl.gov  Thu Jul 14 20:29:46 2005
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu, 14 Jul 2005 12:29:46 -0600
Subject: [LinuxBIOS] NUMA support for dual core Opteron
In-Reply-To: <2ea3fae10507141058c476927@mail.gmail.com>
References: <2ea3fae10507141058c476927@mail.gmail.com>
Message-ID: <1121365786.3317.6.camel@logarithm.lanl.gov>

On Thu, 2005-07-14 at 10:58 -0700, yhlu wrote:
> Someone mentioned that NUMA support for dual core opteron need acpi
> support in LinuxBIOS.
> 
> there may be some other solution for that.
> 1. PowerPC already support dual core and it should support NUMA, So
> the Open Firmware must have some NUMA entry definition.
> Can we make x86-64 kernel support OpenFirmware interface so we can use
> OpenBIOS as payload of LinuxBIOS.
> 2. enable acpi and add the NUMA entries into it, the Linux Kernel will be happy.
> 3. If we are trying to use ADLO to load Windows/Solaris/FreeBSD, We
> need to pass related acpi info to ADLO....
> 
> Solution 1 will be ideal one, and can make Solaris for X86-64 use
> OpenFirmware interface too.....
> 
> which one is better?
> 


AFIAK, for x86_64 kernel, it will try to read NUMA configuration from
HW directory. We don't have to export any ACPI table.

-- 
Li-Ta Lo <ollie at lanl.gov>
Los Alamos National Lab




From yinghailu at gmail.com  Thu Jul 14 20:48:47 2005
From: yinghailu at gmail.com (yhlu)
Date: Thu, 14 Jul 2005 11:48:47 -0700
Subject: [LinuxBIOS] NUMA support for dual core Opteron
In-Reply-To: <1121365786.3317.6.camel@logarithm.lanl.gov>
References: <2ea3fae10507141058c476927@mail.gmail.com>
	<1121365786.3317.6.camel@logarithm.lanl.gov>
Message-ID: <2ea3fae10507141148203bd32c@mail.gmail.com>

For S2895, with 1Gx8 Installed and E stepping dual core opteron with
1G mem hole emable, got

Bootdata ok (command line is apic=debug ramdisk_size=65536
root=/dev/ram0 rw console=tty0 console=ttyS0,115200n8 )
Linux version 2.6.12-rc5 (root at tst288xsuse9) (gcc version 3.3.3 (SuSE
Linux)) #26 SMP Thu Jun 2 18:15:44 PDT 2005
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 0000000000000dd0 (reserved)
 BIOS-e820: 0000000000000dd0 - 00000000000a0000 (usable)
 BIOS-e820: 00000000000f0000 - 00000000000f0400 (reserved)
 BIOS-e820: 0000000000100000 - 00000000c0000000 (usable)
 BIOS-e820: 0000000100000000 - 0000000240000000 (usable)
ACPI: Unable to locate RSDP
Scanning NUMA topology in Northbridge 24
Number of nodes 2
Node 0 MemBase 0000000000000000 Limit 000000013fffffff
Node 1 MemBase 0000000140000000 Limit 000000023fffffff
node 1 shift 24 addr 140000000 conflict 0
node 1 shift 25 addr 1fe000000 conflict 0
Using node hash shift of 26
Bootmem setup node 0 0000000000000000-000000013fffffff
Bootmem setup node 1 0000000140000000-000000023fffffff


~ # cat /proc/mt~ # cat /proc/mtrr 
reg00: base=0x00000000 (   0MB), size=8192MB: write-back, count=1
reg01: base=0x200000000 (8192MB), size=1024MB: write-back, count=1
reg02: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1

with suse kernel and LinuxBIOS + S2882 I can get

linux:~ # cat /proc/meminfo 
        total:    used:    free:  shared: buffers:  cached:
Mem:  8131170304 145051648 7986118656        0 15220736 66543616
Swap: 2154979328        0 2154979328
MemTotal:      7940596 kB
MemFree:       7798944 kB
MemShared:           0 kB
Buffers:         14864 kB
Cached:          64984 kB
SwapCached:          0 kB
Active:          39056 kB
Inactive:        40844 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:      7940596 kB
LowFree:       7798944 kB
SwapTotal:     2104472 kB
SwapFree:      2104472 kB
BigFree:             0 kB

Node 0 MemTotal:      4194300 kB
Node 0 MemFree:      3793788 kB
Node 0 MemUsed:       400512 kB
Node 0 HighTotal:           0 kB
Node 0 HighFree:            0 kB
Node 0 LowTotal:      4194300 kB
Node 0 LowFree:       3793788 kB

Node 1 MemTotal:      4194300 kB
Node 1 MemFree:      4005156 kB
Node 1 MemUsed:       189144 kB
Node 1 HighTotal:           0 kB
Node 1 HighFree:            0 kB
Node 1 LowTotal:      4194300 kB
Node 1 LowFree:       4005156 kB

I wonder if suse kernel have some special code to show that. in
Kernel.org, I can not Node0....Node 1...

YH

On 7/14/05, Li-Ta Lo <ollie at lanl.gov> wrote:
> On Thu, 2005-07-14 at 10:58 -0700, yhlu wrote:
> > Someone mentioned that NUMA support for dual core opteron need acpi
> > support in LinuxBIOS.
> >
> > there may be some other solution for that.
> > 1. PowerPC already support dual core and it should support NUMA, So
> > the Open Firmware must have some NUMA entry definition.
> > Can we make x86-64 kernel support OpenFirmware interface so we can use
> > OpenBIOS as payload of LinuxBIOS.
> > 2. enable acpi and add the NUMA entries into it, the Linux Kernel will be happy.
> > 3. If we are trying to use ADLO to load Windows/Solaris/FreeBSD, We
> > need to pass related acpi info to ADLO....
> >
> > Solution 1 will be ideal one, and can make Solaris for X86-64 use
> > OpenFirmware interface too.....
> >
> > which one is better?
> >
> 
> 
> AFIAK, for x86_64 kernel, it will try to read NUMA configuration from
> HW directory. We don't have to export any ACPI table.
> 
> --
> Li-Ta Lo <ollie at lanl.gov>
> Los Alamos National Lab
> 
>



From ak at suse.de  Thu Jul 14 20:48:21 2005
From: ak at suse.de (Andi Kleen)
Date: Thu, 14 Jul 2005 20:48:21 +0200
Subject: [discuss] Re: [LinuxBIOS] NUMA support for dual core Opteron
In-Reply-To: <1121365786.3317.6.camel@logarithm.lanl.gov>
References: <2ea3fae10507141058c476927@mail.gmail.com>
	<1121365786.3317.6.camel@logarithm.lanl.gov>
Message-ID: <20050714184821.GJ23619@wotan.suse.de>

> AFIAK, for x86_64 kernel, it will try to read NUMA configuration from
> HW directory. We don't have to export any ACPI table.

It doesn't work for dual core or 8 sockets for some reason. Since the SRAT
code works fine and is in general more future proof we never tracked down 
why. Patches welcome. 

However you'll likely need ACPI for other reasons anyways, e.g. for
better power saving.

-Andi




From ak at suse.de  Thu Jul 14 20:52:24 2005
From: ak at suse.de (Andi Kleen)
Date: Thu, 14 Jul 2005 20:52:24 +0200
Subject: [discuss] Re: [LinuxBIOS] NUMA support for dual core Opteron
In-Reply-To: <1121365786.3317.6.camel@logarithm.lanl.gov>
References: <2ea3fae10507141058c476927@mail.gmail.com>
	<1121365786.3317.6.camel@logarithm.lanl.gov>
Message-ID: <20050714185224.GK23619@wotan.suse.de>


P.S.: It is very nasty to cc closed mailing lists when posting
to open ones. Please don't do that in the future.

-Andi



From yinghailu at gmail.com  Thu Jul 14 20:58:40 2005
From: yinghailu at gmail.com (yhlu)
Date: Thu, 14 Jul 2005 11:58:40 -0700
Subject: [discuss] Re: [LinuxBIOS] NUMA support for dual core Opteron
In-Reply-To: <20050714184821.GJ23619@wotan.suse.de>
References: <2ea3fae10507141058c476927@mail.gmail.com>
	<1121365786.3317.6.camel@logarithm.lanl.gov>
	<20050714184821.GJ23619@wotan.suse.de>
Message-ID: <2ea3fae1050714115867e042a8@mail.gmail.com>

FYI in Tyan S4881 (8 ways dual core 875 cpu ) with LinuxBIOS I got
also the 1G mem hole is enabled.

So the kernel should be OK with read NUMA directly from HW.

YH

Firmware type: LinuxBIOS
old bootloader convention, maybe loadlin?
Bootdata ok (command line is apic=debug ramdisk_size=65536
root=/dev/ram0 rw console=tty0 console=ttyS0,115200n8 )
Linux version 2.6.12 (root at tst288xsuse9) (gcc version 3.3.3 (SuSE
Linux)) #8 SMP Fri Jun 24 12:41:43 PDT 2005
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 0000000000000e48 (reserved)
 BIOS-e820: 0000000000000e48 - 00000000000a0000 (usable)
 BIOS-e820: 00000000000f0000 - 00000000000f0400 (reserved)
 BIOS-e820: 0000000000100000 - 00000000c0000000 (usable)
 BIOS-e820: 0000000100000000 - 0000000840000000 (usable)
Scanning NUMA topology in Northbridge 24
Number of nodes 8
Node 0 MemBase 0000000000000000 Limit 000000013fffffff
Node 1 MemBase 0000000140000000 Limit 000000023fffffff
Node 2 MemBase 0000000240000000 Limit 000000033fffffff
Node 3 MemBase 0000000340000000 Limit 000000043fffffff
Node 4 MemBase 0000000440000000 Limit 000000053fffffff
Node 5 MemBase 0000000540000000 Limit 000000063fffffff
Node 6 MemBase 0000000640000000 Limit 000000073fffffff
Node 7 MemBase 0000000740000000 Limit 000000083fffffff
node 1 shift 24 addr 140000000 conflict 0
node 1 shift 25 addr 1fe000000 conflict 0
node 3 shift 26 addr 3fc000000 conflict 0
node 7 shift 27 addr 7f8000000 conflict 0
Using node hash shift of 28
Bootmem setup node 0 0000000000000000-000000013fffffff
Bootmem setup node 1 0000000140000000-000000023fffffff
Bootmem setup node 2 0000000240000000-000000033fffffff
Bootmem setup node 3 0000000340000000-000000043fffffff
Bootmem setup node 4 0000000440000000-000000053fffffff
Bootmem setup node 5 0000000540000000-000000063fffffff
Bootmem setup node 6 0000000640000000-000000073fffffff
Bootmem setup node 7 0000000740000000-000000083fffffff

in LB
Setting variable MTRR 0, base:    0MB, range: 32768MB, type WB
Setting variable MTRR 1, base: 32768MB, range: 1024MB, type WB
Setting variable MTRR 2, base: 3072MB, range: 1024MB, type UC


On 7/14/05, Andi Kleen <ak at suse.de> wrote:
> > AFIAK, for x86_64 kernel, it will try to read NUMA configuration from
> > HW directory. We don't have to export any ACPI table.
> 
> It doesn't work for dual core or 8 sockets for some reason. Since the SRAT
> code works fine and is in general more future proof we never tracked down
> why. Patches welcome.
> 
> However you'll likely need ACPI for other reasons anyways, e.g. for
> better power saving.
> 
> -Andi
> 
>



From rminnich at lanl.gov  Thu Jul 14 21:00:01 2005
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Thu, 14 Jul 2005 13:00:01 -0600 (MDT)
Subject: [LinuxBIOS] Re: NUMA support for dual core Opteron
In-Reply-To: <2ea3fae10507141058c476927@mail.gmail.com>
References: <2ea3fae10507141058c476927@mail.gmail.com>
Message-ID: <Pine.LNX.4.58.0507141259170.22630@enigma.lanl.gov>

if there is any chance of getting along without ACPI entries that is best.  
Linux did do this once already, for SMP K8: K8 can boot and run NUMA
without an SRAT table. What more is needed for dual core, and could Linux
support in this area be extended?

ron




From rminnich at lanl.gov  Thu Jul 14 21:04:26 2005
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Thu, 14 Jul 2005 13:04:26 -0600 (MDT)
Subject: [discuss] Re: [LinuxBIOS] NUMA support for dual core Opteron
In-Reply-To: <20050714184821.GJ23619@wotan.suse.de>
References: <2ea3fae10507141058c476927@mail.gmail.com>
	<1121365786.3317.6.camel@logarithm.lanl.gov>
	<20050714184821.GJ23619@wotan.suse.de>
Message-ID: <Pine.LNX.4.58.0507141303210.22630@enigma.lanl.gov>



On Thu, 14 Jul 2005, Andi Kleen wrote:

> However you'll likely need ACPI for other reasons anyways, e.g. for
> better power saving.

bummer. What the BIOS vendors are doing (to lock in proprietary BIOS, some
say)  is making ACPI tables copyright the BIOS vendor, not the motherboard 
vendor. So LinuxBIOS will have to reverse engineer their own, somehow. 

Shame we can't free ourselves of ACIP a bit. Oh well.

ron



From ollie at lanl.gov  Thu Jul 14 21:05:02 2005
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu, 14 Jul 2005 13:05:02 -0600
Subject: [discuss] Re: [LinuxBIOS] NUMA support for dual core Opteron
In-Reply-To: <20050714184821.GJ23619@wotan.suse.de>
References: <2ea3fae10507141058c476927@mail.gmail.com>
	<1121365786.3317.6.camel@logarithm.lanl.gov>
	<20050714184821.GJ23619@wotan.suse.de>
Message-ID: <1121367902.3317.9.camel@logarithm.lanl.gov>

On Thu, 2005-07-14 at 20:48 +0200, Andi Kleen wrote:
> > AFIAK, for x86_64 kernel, it will try to read NUMA configuration from
> > HW directory. We don't have to export any ACPI table.
> 
> It doesn't work for dual core or 8 sockets for some reason. Since the SRAT
> code works fine and is in general more future proof we never tracked down 
> why. Patches welcome. 
> 

Does each core has its own memory controller?

> However you'll likely need ACPI for other reasons anyways, e.g. for
> better power saving.
> 
> -Andi
> 
-- 
Li-Ta Lo <ollie at lanl.gov>
Los Alamos National Lab




From ak at suse.de  Thu Jul 14 21:54:23 2005
From: ak at suse.de (Andi Kleen)
Date: Thu, 14 Jul 2005 21:54:23 +0200
Subject: [discuss] Re: [LinuxBIOS] NUMA support for dual core Opteron
In-Reply-To: <Pine.LNX.4.58.0507141303210.22630@enigma.lanl.gov>
References: <2ea3fae10507141058c476927@mail.gmail.com>
	<1121365786.3317.6.camel@logarithm.lanl.gov>
	<20050714184821.GJ23619@wotan.suse.de>
	<Pine.LNX.4.58.0507141303210.22630@enigma.lanl.gov>
Message-ID: <20050714195422.GJ23737@wotan.suse.de>

On Thu, Jul 14, 2005 at 01:04:26PM -0600, Ronald G. Minnich wrote:
> 
> 
> On Thu, 14 Jul 2005, Andi Kleen wrote:
> 
> > However you'll likely need ACPI for other reasons anyways, e.g. for
> > better power saving.
> 
> bummer. What the BIOS vendors are doing (to lock in proprietary BIOS, some
> say)  is making ACPI tables copyright the BIOS vendor, not the motherboard 
> vendor. So LinuxBIOS will have to reverse engineer their own, somehow. 

You don't need full support, many of it is optional and will
fall back to the old methods if not available. e.g. you can
probably leave out most of the PCI support if you don't want to support
PCI hotplug. Longer term it might be needed again for power management
though.

Doing PST objects for power saving shouldn't be that difficult, but you
need knowledge of the CPUs from their data sheet (and some testing 
if the power regulators on the mobo can take all the transitions) 
But it shouldn't be very motherboard specific.

However that said there is a lot of useful information
in the FADT and some other tables and I definitely plan to use more of it 
in the future.

-Andi




From mark.langsdorf at amd.com  Thu Jul 14 21:14:23 2005
From: mark.langsdorf at amd.com (Langsdorf, Mark)
Date: Thu, 14 Jul 2005 14:14:23 -0500
Subject: [discuss] Re: [LinuxBIOS] NUMA support for dual core
 Opteron
Message-ID: <84EA05E2CA77634C82730353CBE3A84301CFC28A@SAUSEXMB1.amd.com>


> On Thu, 2005-07-14 at 20:48 +0200, Andi Kleen wrote:
> > > AFIAK, for x86_64 kernel, it will try to read NUMA configuration 
> > > from HW directory. We don't have to export any ACPI table.
> > 
> > It doesn't work for dual core or 8 sockets for some reason. 
> Since the 
> > SRAT code works fine and is in general more future proof we never 
> > tracked down why. Patches welcome.
> > 
> 
> Does each core has its own memory controller?

No.  Each processor has its own memory controller.  A processor
may have 1 or more cores.  (A processor is a physical package.
A core is a complete logic execution unit).  All cores in a processor
have equivalent access to the processor's memory controller.

-Mark Langsdorf
AMD, Inc.




From ollie at lanl.gov  Thu Jul 14 23:42:10 2005
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu, 14 Jul 2005 15:42:10 -0600
Subject: [LinuxBIOS] APIC_CLUSTER and PCI 19.x?
Message-ID: <1121377330.3317.16.camel@logarithm.lanl.gov>

YhLu,

Could you tell me why by moving apci_cluster in front of other 
devices, we only need one chip cpu/x/y/z? And why we don't have
to list 19.x neither?

-- 
Li-Ta Lo <ollie at lanl.gov>
Los Alamos National Lab




From ollie at lanl.gov  Thu Jul 14 23:44:25 2005
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu, 14 Jul 2005 15:44:25 -0600
Subject: [LinuxBIOS] APIC_CLUSTER and PCI 19.x?
In-Reply-To: <1121377330.3317.16.camel@logarithm.lanl.gov>
References: <1121377330.3317.16.camel@logarithm.lanl.gov>
Message-ID: <1121377465.3317.17.camel@logarithm.lanl.gov>

On Thu, 2005-07-14 at 15:42 -0600, Li-Ta Lo wrote:
> YhLu,
> 
> Could you tell me why by moving apci_cluster in front of other 
> devices, we only need one chip cpu/x/y/z? And why we don't have
> to list 19.x neither?
> 

BTW, how about dual core? Do I have to list every core in chip 
apic_cluster and chip northbirdge?

-- 
Li-Ta Lo <ollie at lanl.gov>
Los Alamos National Lab




From yinghailu at gmail.com  Fri Jul 15 03:53:16 2005
From: yinghailu at gmail.com (yhlu)
Date: Thu, 14 Jul 2005 18:53:16 -0700
Subject: [LinuxBIOS] Re: APIC_CLUSTER and PCI 19.x?
In-Reply-To: <1121377330.3317.16.camel@logarithm.lanl.gov>
References: <1121377330.3317.16.camel@logarithm.lanl.gov>
Message-ID: <2ea3fae105071418536a639c9b@mail.gmail.com>

1. I want cpu (ecc....mtrr ) is initialized before all pci device.
otherwise the onboard vga can not initialized properly with your VGA
option rom and emulator.
2. The Northbridge will create the corresponding entries include
apic_cluster and 19.x.... , so if sth is not installed, there is warning....

YH



On 7/14/05, Li-Ta Lo <ollie at lanl.gov> wrote:
> YhLu,
> 
> Could you tell me why by moving apci_cluster in front of other
> devices, we only need one chip cpu/x/y/z? And why we don't have
> to list 19.x neither?
> 
> --
> Li-Ta Lo <ollie at lanl.gov>
> Los Alamos National Lab
> 
>



From yinghailu at gmail.com  Fri Jul 15 03:54:55 2005
From: yinghailu at gmail.com (yhlu)
Date: Thu, 14 Jul 2005 18:54:55 -0700
Subject: [LinuxBIOS] APIC_CLUSTER and PCI 19.x?
In-Reply-To: <1121377465.3317.17.camel@logarithm.lanl.gov>
References: <1121377330.3317.16.camel@logarithm.lanl.gov>
	<1121377465.3317.17.camel@logarithm.lanl.gov>
Message-ID: <2ea3fae1050714185431efce58@mail.gmail.com>

No.

For dual core, the second cores entries is created automatically.

So you can use one image to support dual core and single .....

YH

On 7/14/05, Li-Ta Lo <ollie at lanl.gov> wrote:
> On Thu, 2005-07-14 at 15:42 -0600, Li-Ta Lo wrote:
> > YhLu,
> >
> > Could you tell me why by moving apci_cluster in front of other
> > devices, we only need one chip cpu/x/y/z? And why we don't have
> > to list 19.x neither?
> >
> 
> BTW, how about dual core? Do I have to list every core in chip
> apic_cluster and chip northbirdge?
> 
> --
> Li-Ta Lo <ollie at lanl.gov>
> Los Alamos National Lab
> 
>



From art.fore at comcast.net  Fri Jul 15 05:17:28 2005
From: art.fore at comcast.net (Art Fore)
Date: Thu, 14 Jul 2005 20:17:28 -0700
Subject: [LinuxBIOS] Bios & PCI
Message-ID: <42D72AC8.70702@comcast.net>

Apparently, the PCI bus is setup during booth with the bios. We have a 
problem with this. We have a system, dual booth Suse Linux and WinXP. It 
is connected via a "Stargen" chip which is actually a serial PCI bridge. 
This controls an external instrument where each card is a PCI instrument 
connected via andother "Stargen" chip.  If we shut down the instrument 
system, and change a card, and turn it back on, we then have to rebooth 
the computer to get it to re-instanciate the PCI bus and recognize the 
new card.

Is it possible with OpenBios or LinuxBios to be able to perform this 
function from the operating system without having to do a reboot?

Please note I am not a bios guru.

Art



From art.fore at comcast.net  Fri Jul 15 05:29:15 2005
From: art.fore at comcast.net (Art Fore)
Date: Thu, 14 Jul 2005 20:29:15 -0700
Subject: [LinuxBIOS] Unable to determine if motherboard is supported.
Message-ID: <42D72D8B.3070606@comcast.net>

Have an Asus K8V SE Delux motherboard with an Athelon 64 socket 754 
processor with the following information from the manual

Chipset	VIA K8T800
	VIA VT8237
1 Gig RAM

Southbridge & Promise PDC20378 Raid Controller

Serial ATA drive, IDE drive, IDE DVD ROM drive.

Boots from ATA serial drive.

Audio	ADI AD1980

Marvell 88E8001 Gigabit LAN ontroller

It is a tripple booth system with Suse Linux, and WinXP on the SATA 
serial drive, and DOS on the IDE drive. (The DOS drive is not a 
necessity for the final configuration of the system that will be used)

Can anyone tell me if it is possible for the OpenBios or Linux Bios be 
used to replace ASUS AI Bios?


TIA

Art



From yinghailu at gmail.com  Fri Jul 15 05:57:10 2005
From: yinghailu at gmail.com (yhlu)
Date: Thu, 14 Jul 2005 20:57:10 -0700
Subject: [LinuxBIOS] Unable to determine if motherboard is supported.
In-Reply-To: <42D72D8B.3070606@comcast.net>
References: <42D72D8B.3070606@comcast.net>
Message-ID: <2ea3fae1050714205761420afc@mail.gmail.com>

It seems there is VT8237 support in LinuxBIOS. but the K8T800 is not there.

So it need some time to make K8T800 to support LinuxBIOS. After that
the MB can support LinuxBIOS.

YH

On 7/14/05, Art Fore <art.fore at comcast.net> wrote:
> Have an Asus K8V SE Delux motherboard with an Athelon 64 socket 754
> processor with the following information from the manual
> 
> Chipset VIA K8T800
>        VIA VT8237
> 1 Gig RAM
> 
> Southbridge & Promise PDC20378 Raid Controller
> 
> Serial ATA drive, IDE drive, IDE DVD ROM drive.
> 
> Boots from ATA serial drive.
> 
> Audio   ADI AD1980
> 
> Marvell 88E8001 Gigabit LAN ontroller
> 
> It is a tripple booth system with Suse Linux, and WinXP on the SATA
> serial drive, and DOS on the IDE drive. (The DOS drive is not a
> necessity for the final configuration of the system that will be used)
> 
> Can anyone tell me if it is possible for the OpenBios or Linux Bios be
> used to replace ASUS AI Bios?
> 
> 
> TIA
> 
> Art
> 
> _______________________________________________
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>



From yinghailu at gmail.com  Fri Jul 15 05:58:56 2005
From: yinghailu at gmail.com (yhlu)
Date: Thu, 14 Jul 2005 20:58:56 -0700
Subject: [LinuxBIOS] Bios & PCI
In-Reply-To: <42D72AC8.70702@comcast.net>
References: <42D72AC8.70702@comcast.net>
Message-ID: <2ea3fae105071420582c28b59e@mail.gmail.com>

Did you try the latest kernel with hot plug pci support?

YH

On 7/14/05, Art Fore <art.fore at comcast.net> wrote:
> Apparently, the PCI bus is setup during booth with the bios. We have a
> problem with this. We have a system, dual booth Suse Linux and WinXP. It
> is connected via a "Stargen" chip which is actually a serial PCI bridge.
> This controls an external instrument where each card is a PCI instrument
> connected via andother "Stargen" chip.  If we shut down the instrument
> system, and change a card, and turn it back on, we then have to rebooth
> the computer to get it to re-instanciate the PCI bus and recognize the
> new card.
> 
> Is it possible with OpenBios or LinuxBios to be able to perform this
> function from the operating system without having to do a reboot?
> 
> Please note I am not a bios guru.
> 
> Art
> 
> _______________________________________________
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>



From liutao1980 at gmail.com  Fri Jul 15 12:17:13 2005
From: liutao1980 at gmail.com (Tao Liu)
Date: Fri, 15 Jul 2005 18:17:13 +0800
Subject: [LinuxBIOS] pci_rom_load() bug for non-VGA ROM
Message-ID: <8eca059b05071503175eee0aa4@mail.gmail.com>

Hello,

pci_rom_load() returns wrong rom_header for non-VGA ROM case ?


--- orig/src/devices/pci_rom.c
+++ mod/src/devices/pci_rom.c
@@ -95,11 +95,11 @@
 		return (struct rom_header *) (PCI_VGA_RAM_IMAGE_START);
 #endif
 	} else {
-		printk_spew("%s, copying non-VGA ROM Image from %x to %x, %x bytes\n",
-			    __func__, rom_header, pci_ram_image_start, rom_size);
+		printk_debug("copying non-VGA ROM Image from %x to %x, %x bytes\n",
+			    rom_header, pci_ram_image_start, rom_size);
 		memcpy(pci_ram_image_start, rom_header, rom_size);
 		pci_ram_image_start += rom_size;
-		return (struct rom_header *) pci_ram_image_start;
+		return (struct rom_header *) (pci_ram_image_start - rom_size);
 	}
 	/* disable expansion ROM address decoding */
 	pci_write_config32(dev, PCI_ROM_ADDRESS, rom_address &
~PCI_ROM_ADDRESS_ENABLE);


-- 
Regards,
Liu Tao



From rminnich at lanl.gov  Fri Jul 15 16:38:18 2005
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Fri, 15 Jul 2005 08:38:18 -0600 (MDT)
Subject: [LinuxBIOS] Bios & PCI
In-Reply-To: <42D72AC8.70702@comcast.net>
References: <42D72AC8.70702@comcast.net>
Message-ID: <Pine.LNX.4.58.0507150837470.7348@enigma.lanl.gov>

I think, as Yh Lu mentioned, the OS should be doing that job, not the 
BIOS. Have you looked at hot plug support at this point?


thanks

ron




From yinghailu at gmail.com  Fri Jul 15 16:52:09 2005
From: yinghailu at gmail.com (yhlu)
Date: Fri, 15 Jul 2005 07:52:09 -0700
Subject: [LinuxBIOS] pci_rom_load() bug for non-VGA ROM
In-Reply-To: <8eca059b05071503175eee0aa4@mail.gmail.com>
References: <8eca059b05071503175eee0aa4@mail.gmail.com>
Message-ID: <2ea3fae105071507526cd05e7f@mail.gmail.com>

ollie,

can you look at that?

Also 
static void *pci_ram_image_start = PCI_RAM_IMAGE_START;

should be changed to 
static void *pci_ram_image_start = PCI_RAM_IMAGE_START + 0x10000;//
leave first 64k for VGA

YH



On 7/15/05, Tao Liu <liutao1980 at gmail.com> wrote:
> Hello,
> 
> pci_rom_load() returns wrong rom_header for non-VGA ROM case ?
> 
> 
> --- orig/src/devices/pci_rom.c
> +++ mod/src/devices/pci_rom.c
> @@ -95,11 +95,11 @@
>                return (struct rom_header *) (PCI_VGA_RAM_IMAGE_START);
>  #endif
>        } else {
> -               printk_spew("%s, copying non-VGA ROM Image from %x to %x, %x bytes\n",
> -                           __func__, rom_header, pci_ram_image_start, rom_size);
> +               printk_debug("copying non-VGA ROM Image from %x to %x, %x bytes\n",
> +                           rom_header, pci_ram_image_start, rom_size);
>                memcpy(pci_ram_image_start, rom_header, rom_size);
>                pci_ram_image_start += rom_size;
> -               return (struct rom_header *) pci_ram_image_start;
> +               return (struct rom_header *) (pci_ram_image_start - rom_size);
>        }
>        /* disable expansion ROM address decoding */
>        pci_write_config32(dev, PCI_ROM_ADDRESS, rom_address &
> ~PCI_ROM_ADDRESS_ENABLE);
> 
> 
> --
> Regards,
> Liu Tao
> 
> _______________________________________________
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>



From art.fore at comcast.net  Fri Jul 15 17:29:10 2005
From: art.fore at comcast.net (Art Fore)
Date: Fri, 15 Jul 2005 08:29:10 -0700
Subject: [LinuxBIOS] Bios & PCI
In-Reply-To: <2ea3fae105071420582c28b59e@mail.gmail.com>
References: <42D72AC8.70702@comcast.net>
	<2ea3fae105071420582c28b59e@mail.gmail.com>
Message-ID: <42D7D646.9090906@comcast.net>

Have not tried that yet. Will try it. Hopefully it works. Will be good 
excuse not to use Windows for the system, altlhough the application is 
written in .net so we can use in in Llnux with Mono.

Art


yhlu wrote:
> Did you try the latest kernel with hot plug pci support?
> 
> YH
> 
> On 7/14/05, Art Fore <art.fore at comcast.net> wrote:
> 
>>Apparently, the PCI bus is setup during booth with the bios. We have a
>>problem with this. We have a system, dual booth Suse Linux and WinXP. It
>>is connected via a "Stargen" chip which is actually a serial PCI bridge.
>>This controls an external instrument where each card is a PCI instrument
>>connected via andother "Stargen" chip.  If we shut down the instrument
>>system, and change a card, and turn it back on, we then have to rebooth
>>the computer to get it to re-instanciate the PCI bus and recognize the
>>new card.
>>
>>Is it possible with OpenBios or LinuxBios to be able to perform this
>>function from the operating system without having to do a reboot?
>>
>>Please note I am not a bios guru.
>>
>>Art
>>
>>_______________________________________________
>>LinuxBIOS mailing list
>>LinuxBIOS at openbios.org
>>http://www.openbios.org/mailman/listinfo/linuxbios
>>
> 
> 
> _______________________________________________
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
> 



From art.fore at comcast.net  Fri Jul 15 17:30:40 2005
From: art.fore at comcast.net (Art Fore)
Date: Fri, 15 Jul 2005 08:30:40 -0700
Subject: [LinuxBIOS] Unable to determine if motherboard is supported.
In-Reply-To: <2ea3fae1050714205761420afc@mail.gmail.com>
References: <42D72D8B.3070606@comcast.net>
	<2ea3fae1050714205761420afc@mail.gmail.com>
Message-ID: <42D7D6A0.20508@comcast.net>

Thanks for the info. Will be looking forward to the K8T800 support.

Art

yhlu wrote:
> It seems there is VT8237 support in LinuxBIOS. but the K8T800 is not there.
> 
> So it need some time to make K8T800 to support LinuxBIOS. After that
> the MB can support LinuxBIOS.
> 
> YH
> 
> On 7/14/05, Art Fore <art.fore at comcast.net> wrote:
> 
>>Have an Asus K8V SE Delux motherboard with an Athelon 64 socket 754
>>processor with the following information from the manual
>>
>>Chipset VIA K8T800
>>       VIA VT8237
>>1 Gig RAM
>>
>>Southbridge & Promise PDC20378 Raid Controller
>>
>>Serial ATA drive, IDE drive, IDE DVD ROM drive.
>>
>>Boots from ATA serial drive.
>>
>>Audio   ADI AD1980
>>
>>Marvell 88E8001 Gigabit LAN ontroller
>>
>>It is a tripple booth system with Suse Linux, and WinXP on the SATA
>>serial drive, and DOS on the IDE drive. (The DOS drive is not a
>>necessity for the final configuration of the system that will be used)
>>
>>Can anyone tell me if it is possible for the OpenBios or Linux Bios be
>>used to replace ASUS AI Bios?
>>
>>
>>TIA
>>
>>Art
>>
>>_______________________________________________
>>LinuxBIOS mailing list
>>LinuxBIOS at openbios.org
>>http://www.openbios.org/mailman/listinfo/linuxbios
>>
> 
> 
> _______________________________________________
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
> 



From ollie at lanl.gov  Fri Jul 15 19:32:37 2005
From: ollie at lanl.gov (Li-Ta Lo)
Date: Fri, 15 Jul 2005 11:32:37 -0600
Subject: [LinuxBIOS] Re: APIC_CLUSTER and PCI 19.x?
In-Reply-To: <2ea3fae105071418536a639c9b@mail.gmail.com>
References: <1121377330.3317.16.camel@logarithm.lanl.gov>
	<2ea3fae105071418536a639c9b@mail.gmail.com>
Message-ID: <1121448758.3317.21.camel@logarithm.lanl.gov>

On Thu, 2005-07-14 at 18:53 -0700, yhlu wrote:
> 1. I want cpu (ecc....mtrr ) is initialized before all pci device.
> otherwise the onboard vga can not initialized properly with your VGA
> option rom and emulator.

I know. But my question is why we now only have to list one apic
cluster and 19.x in the Config.lb? 

> 2. The Northbridge will create the corresponding entries include
> apic_cluster and 19.x.... , so if sth is not installed, there is warning....
> 

Do you mean the northbridge on 18.x will create the device structures
for apci 1 and 19.x ? Where in the code is this done?

-- 
Li-Ta Lo <ollie at lanl.gov>
Los Alamos National Lab




From ollie at lanl.gov  Fri Jul 15 19:41:48 2005
From: ollie at lanl.gov (Li-Ta Lo)
Date: Fri, 15 Jul 2005 11:41:48 -0600
Subject: [LinuxBIOS] pci_rom_load() bug for non-VGA ROM
In-Reply-To: <2ea3fae105071507526cd05e7f@mail.gmail.com>
References: <8eca059b05071503175eee0aa4@mail.gmail.com>
	<2ea3fae105071507526cd05e7f@mail.gmail.com>
Message-ID: <1121449308.18329.2.camel@logarithm.lanl.gov>

On Fri, 2005-07-15 at 07:52 -0700, yhlu wrote:
> ollie,
> 
> can you look at that?
> 

I will check this one later.

> Also 
> static void *pci_ram_image_start = PCI_RAM_IMAGE_START;
> 
> should be changed to 
> static void *pci_ram_image_start = PCI_RAM_IMAGE_START + 0x10000;//
> leave first 64k for VGA
> 

No. There are to #define constants:

#define PCI_RAM_IMAGE_START 0xD0000
#define PCI_VGA_RAM_IMAGE_START 0xC0000

I already reserved 64KB for VGA BIOS.

> YH
> 
> 
> 
> On 7/15/05, Tao Liu <liutao1980 at gmail.com> wrote:
> > Hello,
> > 
> > pci_rom_load() returns wrong rom_header for non-VGA ROM case ?
> > 
> > 
> > --- orig/src/devices/pci_rom.c
> > +++ mod/src/devices/pci_rom.c
> > @@ -95,11 +95,11 @@
> >                return (struct rom_header *) (PCI_VGA_RAM_IMAGE_START);
> >  #endif
> >        } else {
> > -               printk_spew("%s, copying non-VGA ROM Image from %x to %x, %x bytes\n",
> > -                           __func__, rom_header, pci_ram_image_start, rom_size);
> > +               printk_debug("copying non-VGA ROM Image from %x to %x, %x bytes\n",
> > +                           rom_header, pci_ram_image_start, rom_size);
> >                memcpy(pci_ram_image_start, rom_header, rom_size);
> >                pci_ram_image_start += rom_size;
> > -               return (struct rom_header *) pci_ram_image_start;
> > +               return (struct rom_header *) (pci_ram_image_start - rom_size);
> >        }
> >        /* disable expansion ROM address decoding */
> >        pci_write_config32(dev, PCI_ROM_ADDRESS, rom_address &
> > ~PCI_ROM_ADDRESS_ENABLE);
> > 
> > 
> > --
> > Regards,
> > Liu Tao
> > 
> > _______________________________________________
> > LinuxBIOS mailing list
> > LinuxBIOS at openbios.org
> > http://www.openbios.org/mailman/listinfo/linuxbios
> >
> 
> _______________________________________________
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
-- 
Li-Ta Lo <ollie at lanl.gov>
Los Alamos National Lab




From yinghailu at gmail.com  Fri Jul 15 20:27:00 2005
From: yinghailu at gmail.com (yhlu)
Date: Fri, 15 Jul 2005 11:27:00 -0700
Subject: [LinuxBIOS] Re: APIC_CLUSTER and PCI 19.x?
In-Reply-To: <1121448758.3317.21.camel@logarithm.lanl.gov>
References: <1121377330.3317.16.camel@logarithm.lanl.gov>
	<2ea3fae105071418536a639c9b@mail.gmail.com>
	<1121448758.3317.21.camel@logarithm.lanl.gov>
Message-ID: <2ea3fae10507151127be804c7@mail.gmail.com>

src/northbridge/amd/amdk8/northbridge.c
YH

On 7/15/05, Li-Ta Lo <ollie at lanl.gov> wrote:
> On Thu, 2005-07-14 at 18:53 -0700, yhlu wrote:
> > 1. I want cpu (ecc....mtrr ) is initialized before all pci device.
> > otherwise the onboard vga can not initialized properly with your VGA
> > option rom and emulator.
> 
> I know. But my question is why we now only have to list one apic
> cluster and 19.x in the Config.lb?
> 
> > 2. The Northbridge will create the corresponding entries include
> > apic_cluster and 19.x.... , so if sth is not installed, there is warning....
> >
> 
> Do you mean the northbridge on 18.x will create the device structures
> for apci 1 and 19.x ? Where in the code is this done?
> 
> --
> Li-Ta Lo <ollie at lanl.gov>
> Los Alamos National Lab
> 
>



From yinghailu at gmail.com  Fri Jul 15 20:27:27 2005
From: yinghailu at gmail.com (yhlu)
Date: Fri, 15 Jul 2005 11:27:27 -0700
Subject: [LinuxBIOS] pci_rom_load() bug for non-VGA ROM
In-Reply-To: <1121449308.18329.2.camel@logarithm.lanl.gov>
References: <8eca059b05071503175eee0aa4@mail.gmail.com>
	<2ea3fae105071507526cd05e7f@mail.gmail.com>
	<1121449308.18329.2.camel@logarithm.lanl.gov>
Message-ID: <2ea3fae105071511275a667d47@mail.gmail.com>

good.

On 7/15/05, Li-Ta Lo <ollie at lanl.gov> wrote:
> On Fri, 2005-07-15 at 07:52 -0700, yhlu wrote:
> > ollie,
> >
> > can you look at that?
> >
> 
> I will check this one later.
> 
> > Also
> > static void *pci_ram_image_start = PCI_RAM_IMAGE_START;
> >
> > should be changed to
> > static void *pci_ram_image_start = PCI_RAM_IMAGE_START + 0x10000;//
> > leave first 64k for VGA
> >
> 
> No. There are to #define constants:
> 
> #define PCI_RAM_IMAGE_START 0xD0000
> #define PCI_VGA_RAM_IMAGE_START 0xC0000
> 
> I already reserved 64KB for VGA BIOS.
> 
> > YH
> >
> >
> >
> > On 7/15/05, Tao Liu <liutao1980 at gmail.com> wrote:
> > > Hello,
> > >
> > > pci_rom_load() returns wrong rom_header for non-VGA ROM case ?
> > >
> > >
> > > --- orig/src/devices/pci_rom.c
> > > +++ mod/src/devices/pci_rom.c
> > > @@ -95,11 +95,11 @@
> > >                return (struct rom_header *) (PCI_VGA_RAM_IMAGE_START);
> > >  #endif
> > >        } else {
> > > -               printk_spew("%s, copying non-VGA ROM Image from %x to %x, %x bytes\n",
> > > -                           __func__, rom_header, pci_ram_image_start, rom_size);
> > > +               printk_debug("copying non-VGA ROM Image from %x to %x, %x bytes\n",
> > > +                           rom_header, pci_ram_image_start, rom_size);
> > >                memcpy(pci_ram_image_start, rom_header, rom_size);
> > >                pci_ram_image_start += rom_size;
> > > -               return (struct rom_header *) pci_ram_image_start;
> > > +               return (struct rom_header *) (pci_ram_image_start - rom_size);
> > >        }
> > >        /* disable expansion ROM address decoding */
> > >        pci_write_config32(dev, PCI_ROM_ADDRESS, rom_address &
> > > ~PCI_ROM_ADDRESS_ENABLE);
> > >
> > >
> > > --
> > > Regards,
> > > Liu Tao
> > >
> > > _______________________________________________
> > > LinuxBIOS mailing list
> > > LinuxBIOS at openbios.org
> > > http://www.openbios.org/mailman/listinfo/linuxbios
> > >
> >
> > _______________________________________________
> > LinuxBIOS mailing list
> > LinuxBIOS at openbios.org
> > http://www.openbios.org/mailman/listinfo/linuxbios
> --
> Li-Ta Lo <ollie at lanl.gov>
> Los Alamos National Lab
> 
>



From ollie at lanl.gov  Fri Jul 15 20:31:42 2005
From: ollie at lanl.gov (Li-Ta Lo)
Date: Fri, 15 Jul 2005 12:31:42 -0600
Subject: [LinuxBIOS] Re: APIC_CLUSTER and PCI 19.x?
In-Reply-To: <2ea3fae10507151127be804c7@mail.gmail.com>
References: <1121377330.3317.16.camel@logarithm.lanl.gov>
	<2ea3fae105071418536a639c9b@mail.gmail.com>
	<1121448758.3317.21.camel@logarithm.lanl.gov>
	<2ea3fae10507151127be804c7@mail.gmail.com>
Message-ID: <1121452302.18329.19.camel@logarithm.lanl.gov>

On Fri, 2005-07-15 at 11:27 -0700, yhlu wrote:
> src/northbridge/amd/amdk8/northbridge.c
> YH
> 

So is it safe to move apci_cluster to the front of devices and
remove pci 19.x in every K8 mainboard config.lb ?

-- 
Li-Ta Lo <ollie at lanl.gov>
Los Alamos National Lab




From yinghailu at gmail.com  Fri Jul 15 21:20:33 2005
From: yinghailu at gmail.com (yhlu)
Date: Fri, 15 Jul 2005 12:20:33 -0700
Subject: [LinuxBIOS] Re: APIC_CLUSTER and PCI 19.x?
In-Reply-To: <1121452302.18329.19.camel@logarithm.lanl.gov>
References: <1121377330.3317.16.camel@logarithm.lanl.gov>
	<2ea3fae105071418536a639c9b@mail.gmail.com>
	<1121448758.3317.21.camel@logarithm.lanl.gov>
	<2ea3fae10507151127be804c7@mail.gmail.com>
	<1121452302.18329.19.camel@logarithm.lanl.gov>
Message-ID: <2ea3fae1050715122023c4e764@mail.gmail.com>

YES, and if you want to enable onboard vga, you must do that.

YH

On 7/15/05, Li-Ta Lo <ollie at lanl.gov> wrote:
> On Fri, 2005-07-15 at 11:27 -0700, yhlu wrote:
> > src/northbridge/amd/amdk8/northbridge.c
> > YH
> >
> 
> So is it safe to move apci_cluster to the front of devices and
> remove pci 19.x in every K8 mainboard config.lb ?
> 
> --
> Li-Ta Lo <ollie at lanl.gov>
> Los Alamos National Lab
> 
>



From steve at digidescorp.com  Fri Jul 15 21:27:47 2005
From: steve at digidescorp.com (Steven J. Magnani)
Date: Fri, 15 Jul 2005 14:27:47 -0500
Subject: [LinuxBIOS] etherboot with LinuxBIOS
In-Reply-To: <2ea3fae105071408101e90b823@mail.gmail.com>
Message-ID: <000001c58973$4b7a0760$6ffea8c0@banana>

I think this patch fixes the bug.

--- etherboot-5.4.0/src/core/osloader.c.orig	2005-02-15
19:46:56.000000000 -0600
+++ etherboot-5.4.0/src/core/osloader.c	2005-07-15 14:13:39.234375000
-0500
@@ -350,10 +350,11 @@
 	else {
 		len -= (skip_sectors << 9) + skip_bytes;
 		data += (skip_sectors << 9) + skip_bytes;
+		skip_sectors = os_download(data, len, eof);
+		skip_bytes = 0;
+
 	}
-	skip_sectors = os_download(data, len, eof);
-	skip_bytes = 0;
-	
+
 	return 1;
 }
 
Steve Magnani
www.digidescorp.com

-----Original Message-----
From: yhlu [mailto:yinghailu at gmail.com] 
Sent: Thursday, July 14, 2005 9:10 AM
To: Steven J. Magnani
Cc: Stephen.Kimball at bench.com; linuxbios at openbios.org
Subject: Re: [LinuxBIOS] etherboot with LinuxBIOS


do not use 5.4 at this time, because the memtest can not be loaded by
Etherboot 5.4 correctly.

YH

On 7/14/05, Steven J. Magnani <steve at digidescorp.com> wrote:
> Etherboot 5.4.0 seems to compile with gcc-3.4.3 if, in addition to the

> config changes spelled out on the Wiki, you also comment out PXE 
> support in src/Config:
> 
> # Etherboot as a PXE network protocol ROM
> #CFLAGS+=       -DPXE_IMAGE -DPXE_EXPORT
> 
> Seems to run, but I haven't reached a point where I can boot something

> over the network yet.
> 
> Steve
> www.digidescorp.com
> 
> 
> 
> 
> _______________________________________________
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org 
> http://www.openbios.org/mailman/listinfo/linuxbios
>






From yinghailu at gmail.com  Fri Jul 15 21:33:50 2005
From: yinghailu at gmail.com (yhlu)
Date: Fri, 15 Jul 2005 12:33:50 -0700
Subject: [LinuxBIOS] etherboot with LinuxBIOS
In-Reply-To: <000001c58973$4b7a0760$6ffea8c0@banana>
References: <2ea3fae105071408101e90b823@mail.gmail.com>
	<000001c58973$4b7a0760$6ffea8c0@banana>
Message-ID: <2ea3fae10507151233721c9f0d@mail.gmail.com>

Great,

Tim, Can you verify that?

YH

On 7/15/05, Steven J. Magnani <steve at digidescorp.com> wrote:
> I think this patch fixes the bug.
> 
> --- etherboot-5.4.0/src/core/osloader.c.orig    2005-02-15
> 19:46:56.000000000 -0600
> +++ etherboot-5.4.0/src/core/osloader.c 2005-07-15 14:13:39.234375000
> -0500
> @@ -350,10 +350,11 @@
>        else {
>                len -= (skip_sectors << 9) + skip_bytes;
>                data += (skip_sectors << 9) + skip_bytes;
> +               skip_sectors = os_download(data, len, eof);
> +               skip_bytes = 0;
> +
>        }
> -       skip_sectors = os_download(data, len, eof);
> -       skip_bytes = 0;
> -
> +
>        return 1;
>  }
> 
> Steve Magnani
> www.digidescorp.com
> 
> -----Original Message-----
> From: yhlu [mailto:yinghailu at gmail.com]
> Sent: Thursday, July 14, 2005 9:10 AM
> To: Steven J. Magnani
> Cc: Stephen.Kimball at bench.com; linuxbios at openbios.org
> Subject: Re: [LinuxBIOS] etherboot with LinuxBIOS
> 
> 
> do not use 5.4 at this time, because the memtest can not be loaded by
> Etherboot 5.4 correctly.
> 
> YH
> 
> On 7/14/05, Steven J. Magnani <steve at digidescorp.com> wrote:
> > Etherboot 5.4.0 seems to compile with gcc-3.4.3 if, in addition to the
> 
> > config changes spelled out on the Wiki, you also comment out PXE
> > support in src/Config:
> >
> > # Etherboot as a PXE network protocol ROM
> > #CFLAGS+=       -DPXE_IMAGE -DPXE_EXPORT
> >
> > Seems to run, but I haven't reached a point where I can boot something
> 
> > over the network yet.
> >
> > Steve
> > www.digidescorp.com
> >
> >
> >
> >
> > _______________________________________________
> > LinuxBIOS mailing list
> > LinuxBIOS at openbios.org
> > http://www.openbios.org/mailman/listinfo/linuxbios
> >
> 
> 
> 
>



From yinghailu at gmail.com  Fri Jul 15 23:15:31 2005
From: yinghailu at gmail.com (yhlu)
Date: Fri, 15 Jul 2005 22:15:31 +0100
Subject: [Etherboot-users] Re: [LinuxBIOS] etherboot with LinuxBIOS
In-Reply-To: <000001c58973$4b7a0760$6ffea8c0@banana>
References: <2ea3fae105071408101e90b823@mail.gmail.com>
	<000001c58973$4b7a0760$6ffea8c0@banana>
Message-ID: <000001c58982$54f14920$0200a8c0@lawry.local>

Great,

Tim, Can you verify that?

YH

On 7/15/05, Steven J. Magnani <steve at digidescorp.com> wrote:
> I think this patch fixes the bug.
> 
> --- etherboot-5.4.0/src/core/osloader.c.orig    2005-02-15
> 19:46:56.000000000 -0600
> +++ etherboot-5.4.0/src/core/osloader.c 2005-07-15 14:13:39.234375000
> -0500
> @@ -350,10 +350,11 @@
>        else {
>                len -= (skip_sectors << 9) + skip_bytes;
>                data += (skip_sectors << 9) + skip_bytes;
> +               skip_sectors = os_download(data, len, eof);
> +               skip_bytes = 0;
> +
>        }
> -       skip_sectors = os_download(data, len, eof);
> -       skip_bytes = 0;
> -
> +
>        return 1;
>  }
> 
> Steve Magnani
> www.digidescorp.com
> 
> -----Original Message-----
> From: yhlu [mailto:yinghailu at gmail.com]
> Sent: Thursday, July 14, 2005 9:10 AM
> To: Steven J. Magnani
> Cc: Stephen.Kimball at bench.com; linuxbios at openbios.org
> Subject: Re: [LinuxBIOS] etherboot with LinuxBIOS
> 
> 
> do not use 5.4 at this time, because the memtest can not be loaded by
> Etherboot 5.4 correctly.
> 
> YH
> 
> On 7/14/05, Steven J. Magnani <steve at digidescorp.com> wrote:
> > Etherboot 5.4.0 seems to compile with gcc-3.4.3 if, in addition to the
> 
> > config changes spelled out on the Wiki, you also comment out PXE
> > support in src/Config:
> >
> > # Etherboot as a PXE network protocol ROM
> > #CFLAGS+=       -DPXE_IMAGE -DPXE_EXPORT
> >
> > Seems to run, but I haven't reached a point where I can boot something
> 
> > over the network yet.
> >
> > Steve
> > www.digidescorp.com
> >
> >
> >
> >
> > _______________________________________________
> > LinuxBIOS mailing list
> > LinuxBIOS at openbios.org
> > http://www.openbios.org/mailman/listinfo/linuxbios
> >
> 
> 
> 
>


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
_______________________________________________
Etherboot-users mailing list
Etherboot-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/etherboot-users






From stepan at openbios.org  Sat Jul 16 01:41:54 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Sat, 16 Jul 2005 01:41:54 +0200
Subject: [LinuxBIOS] Moving forward: Subversion
Message-ID: <20050715234154.GA27293@openbios.org>

Dear LinuxBIOS community,

most of you might not have noticed, but we've had quite adventurous
times during the last five months. The whole story started around
February, when LinuxBIOS decided to go away from Sourceforge's CVS
repository. CVS does not support restructuring code very well, and 
Sourceforge sometimes had delays of a week before changes would be
visible to the world. That's why we moved on to a more modern version
control system: GNU arch.

While conceptionally very advanced, GNU arch also brought some issues
and required hefty efforts. While concepts and architecture are
important, usability and maturity is still a major concern with GNU
arch. 

Since the Open Source/Free Software Firmware community wins nothing
when we all advance to version control experts but stick with
administrative issues, we decided to go to a mature system that
combines modern version control techniques with a steep learning
curve, making it a lot easier for everyone to have a look at LinuxBIOS
development, or contribute: Subversion

I've been migrating the LinuxBIOS repository to Subversion now.
We have been testing it for the the last month now and it has been a
good deal more reliable and usable than GNU arch.

By tonight the GNU arch repository is read only and will not accept
new checkins.

Here's a quick introduction how the LinuxBIOS repository can be
accessed from now on:

Anonymous access 
----------------

You can check it out as follows: 
 $ svn co svn://openbios.org/repos/trunk/LinuxBIOSv2
or 
 $ svn co svn://openbios.org/repos/trunk/LinuxBIOSv1


Developer Access 
----------------

Access for developers is very similar to anonymous access. Just add
your Subversion username as follows when checking out the repository: 

 $ svn co svn://<username>@openbios.org/repos/trunk/LinuxBIOSv2

All people with checkin permission to the GNU arch repository will be
contacted shortly to move their accounts over to Subversion (Many of
them are already). If you are a LinuxBIOS developer and don't hear
from me, please contact me.


Source code browsing 
--------------------

You can also browse the LinuxBIOS Subversion repository online:

         http://www.openbios.org/viewcvs/trunk/


Snapshots 
---------

If you don't want to use Subversion, or can't use it, you can also
download a tar ball of the latest repository at

    http://www.openbios.org/viewcvs/trunk/LinuxBIOSv2.tar.gz?view=tar


More information on Subversion
------------------------------

Subversion is available as a package in all major Linux distributions.
It can also be compiled from source code on most available systems.

See the Subversion homepage http://subversion.tigris.org/ for more
information on Subversion, including a description of available commands
and the source code.

There's also a very detailed online book available on Subversion: 
Version Control with Subversion - http://svnbook.red-bean.com/

The Subversion user interface is very similar to the CVS one, so
if you have used CVS before, it will be easy for you to use it and
participate in the LinuxBIOS project.


Comments, flames, questions are very welcome.


Best regards,
   Stefan Reinauer

-- 
OpenBIOS - free your system.



From yinghailu at gmail.com  Mon Jul 18 05:12:29 2005
From: yinghailu at gmail.com (yhlu)
Date: Sun, 17 Jul 2005 20:12:29 -0700
Subject: [Etherboot-users] Re: [LinuxBIOS] etherboot with LinuxBIOS
In-Reply-To: <42DB039B.7020905@rogers.com>
References: <2ea3fae105071408101e90b823@mail.gmail.com>
	<000001c58973$4b7a0760$6ffea8c0@banana>
	<2ea3fae10507151233721c9f0d@mail.gmail.com>
	<42DB039B.7020905@rogers.com>
Message-ID: <2ea3fae10507172012790da7ed@mail.gmail.com>

Good.

I may switch to 5.4 from now on...

YH

On 7/17/05, Timothy Legge <tlegge at rogers.com> wrote:
> I made the original change that caused this:
> 
> http://cvs.sourceforge.net/viewcvs.py/etherboot/etherboot/etherboot-5.3/src/core/Attic/osloader.c?r1=1.5&r2=1.6&diff_format=u
> 
> At the time the change was made to fix an issue that was reported to
> cause Etherboot to fail to boot some kernels.  IIRC, EB failed to
> recognize that the kernel download was complete.  However, the fix seems
> to have broken memtest and FreeBSD.
> 
>  From my point of view the this patch should be accepted to revert to
> the original functionality.  I think this may cause the original problem
> that I tried to correct to reappear but that may help someone fix the
> real problem correctly this time.
> 
> Regards
> 
> Tim
> 
> yhlu wrote:
> > Great,
> >
> > Tim, Can you verify that?
> >
> > YH
> >
> > On 7/15/05, Steven J. Magnani <steve at digidescorp.com> wrote:
> >
> >>I think this patch fixes the bug.
> >>
> >>--- etherboot-5.4.0/src/core/osloader.c.orig    2005-02-15
> >>19:46:56.000000000 -0600
> >>+++ etherboot-5.4.0/src/core/osloader.c 2005-07-15 14:13:39.234375000
> >>-0500
> >>@@ -350,10 +350,11 @@
> >>       else {
> >>               len -= (skip_sectors << 9) + skip_bytes;
> >>               data += (skip_sectors << 9) + skip_bytes;
> >>+               skip_sectors = os_download(data, len, eof);
> >>+               skip_bytes = 0;
> >>+
> >>       }
> >>-       skip_sectors = os_download(data, len, eof);
> >>-       skip_bytes = 0;
> >>-
> >>+
> >>       return 1;
> >> }
> >>
> >>Steve Magnani
> >>www.digidescorp.com
> >>
> >>-----Original Message-----
> >>From: yhlu [mailto:yinghailu at gmail.com]
> >>Sent: Thursday, July 14, 2005 9:10 AM
> >>To: Steven J. Magnani
> >>Cc: Stephen.Kimball at bench.com; linuxbios at openbios.org
> >>Subject: Re: [LinuxBIOS] etherboot with LinuxBIOS
> >>
> >>
> >>do not use 5.4 at this time, because the memtest can not be loaded by
> >>Etherboot 5.4 correctly.
> >>
> >>YH
> >>
> >>On 7/14/05, Steven J. Magnani <steve at digidescorp.com> wrote:
> >>
> >>>Etherboot 5.4.0 seems to compile with gcc-3.4.3 if, in addition to the
> >>
> >>>config changes spelled out on the Wiki, you also comment out PXE
> >>>support in src/Config:
> >>>
> >>># Etherboot as a PXE network protocol ROM
> >>>#CFLAGS+=       -DPXE_IMAGE -DPXE_EXPORT
> >>>
> >>>Seems to run, but I haven't reached a point where I can boot something
> >>
> >>>over the network yet.
> >>>
> >>>Steve
> >>>www.digidescorp.com
> >>>
> >>>
> >>>
> >>>
> >>>_______________________________________________
> >>>LinuxBIOS mailing list
> >>>LinuxBIOS at openbios.org
> >>>http://www.openbios.org/mailman/listinfo/linuxbios
> >>>
> >>
> >>
> >>
> >>
> >
> >
> > -------------------------------------------------------
> > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> > from IBM. Find simple to follow Roadmaps, straightforward articles,
> > informative Webcasts and more! Get everything you need to get up to
> > speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
> > _______________________________________________
> > Etherboot-users mailing list
> > Etherboot-users at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/etherboot-users
> >
> 
>



From tlegge at rogers.com  Mon Jul 18 03:19:23 2005
From: tlegge at rogers.com (Timothy Legge)
Date: Sun, 17 Jul 2005 22:19:23 -0300
Subject: [Etherboot-users] Re: [LinuxBIOS] etherboot with LinuxBIOS
In-Reply-To: <2ea3fae10507151233721c9f0d@mail.gmail.com>
References: <2ea3fae105071408101e90b823@mail.gmail.com>	
	<000001c58973$4b7a0760$6ffea8c0@banana>
	<2ea3fae10507151233721c9f0d@mail.gmail.com>
Message-ID: <42DB039B.7020905@rogers.com>

I made the original change that caused this:
 
http://cvs.sourceforge.net/viewcvs.py/etherboot/etherboot/etherboot-5.3/src/core/Attic/osloader.c?r1=1.5&r2=1.6&diff_format=u

At the time the change was made to fix an issue that was reported to 
cause Etherboot to fail to boot some kernels.  IIRC, EB failed to 
recognize that the kernel download was complete.  However, the fix seems 
to have broken memtest and FreeBSD.

 From my point of view the this patch should be accepted to revert to 
the original functionality.  I think this may cause the original problem 
that I tried to correct to reappear but that may help someone fix the 
real problem correctly this time.

Regards

Tim

yhlu wrote:
> Great,
> 
> Tim, Can you verify that?
> 
> YH
> 
> On 7/15/05, Steven J. Magnani <steve at digidescorp.com> wrote:
> 
>>I think this patch fixes the bug.
>>
>>--- etherboot-5.4.0/src/core/osloader.c.orig    2005-02-15
>>19:46:56.000000000 -0600
>>+++ etherboot-5.4.0/src/core/osloader.c 2005-07-15 14:13:39.234375000
>>-0500
>>@@ -350,10 +350,11 @@
>>       else {
>>               len -= (skip_sectors << 9) + skip_bytes;
>>               data += (skip_sectors << 9) + skip_bytes;
>>+               skip_sectors = os_download(data, len, eof);
>>+               skip_bytes = 0;
>>+
>>       }
>>-       skip_sectors = os_download(data, len, eof);
>>-       skip_bytes = 0;
>>-
>>+
>>       return 1;
>> }
>>
>>Steve Magnani
>>www.digidescorp.com
>>
>>-----Original Message-----
>>From: yhlu [mailto:yinghailu at gmail.com]
>>Sent: Thursday, July 14, 2005 9:10 AM
>>To: Steven J. Magnani
>>Cc: Stephen.Kimball at bench.com; linuxbios at openbios.org
>>Subject: Re: [LinuxBIOS] etherboot with LinuxBIOS
>>
>>
>>do not use 5.4 at this time, because the memtest can not be loaded by
>>Etherboot 5.4 correctly.
>>
>>YH
>>
>>On 7/14/05, Steven J. Magnani <steve at digidescorp.com> wrote:
>>
>>>Etherboot 5.4.0 seems to compile with gcc-3.4.3 if, in addition to the
>>
>>>config changes spelled out on the Wiki, you also comment out PXE
>>>support in src/Config:
>>>
>>># Etherboot as a PXE network protocol ROM
>>>#CFLAGS+=       -DPXE_IMAGE -DPXE_EXPORT
>>>
>>>Seems to run, but I haven't reached a point where I can boot something
>>
>>>over the network yet.
>>>
>>>Steve
>>>www.digidescorp.com
>>>
>>>
>>>
>>>
>>>_______________________________________________
>>>LinuxBIOS mailing list
>>>LinuxBIOS at openbios.org
>>>http://www.openbios.org/mailman/listinfo/linuxbios
>>>
>>
>>
>>
>>
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
> _______________________________________________
> Etherboot-users mailing list
> Etherboot-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/etherboot-users
> 




From tlegge at rogers.com  Mon Jul 18 03:30:23 2005
From: tlegge at rogers.com (Timothy Legge)
Date: Mon, 18 Jul 2005 02:30:23 +0100
Subject: [Etherboot-users] Re: [LinuxBIOS] etherboot with LinuxBIOS
In-Reply-To: <2ea3fae10507151233721c9f0d@mail.gmail.com>
References: <2ea3fae105071408101e90b823@mail.gmail.com>	
	<000001c58973$4b7a0760$6ffea8c0@banana>
	<2ea3fae10507151233721c9f0d@mail.gmail.com>
Message-ID: <000501c58b38$44527050$0200a8c0@lawry.local>

I made the original change that caused this:
 
http://cvs.sourceforge.net/viewcvs.py/etherboot/etherboot/etherboot-5.3/src/core/Attic/osloader.c?r1=1.5&r2=1.6&diff_format=u

At the time the change was made to fix an issue that was reported to 
cause Etherboot to fail to boot some kernels.  IIRC, EB failed to 
recognize that the kernel download was complete.  However, the fix seems 
to have broken memtest and FreeBSD.

 From my point of view the this patch should be accepted to revert to 
the original functionality.  I think this may cause the original problem 
that I tried to correct to reappear but that may help someone fix the 
real problem correctly this time.

Regards

Tim

yhlu wrote:
> Great,
> 
> Tim, Can you verify that?
> 
> YH
> 
> On 7/15/05, Steven J. Magnani <steve at digidescorp.com> wrote:
> 
>>I think this patch fixes the bug.
>>
>>--- etherboot-5.4.0/src/core/osloader.c.orig    2005-02-15
>>19:46:56.000000000 -0600
>>+++ etherboot-5.4.0/src/core/osloader.c 2005-07-15 14:13:39.234375000
>>-0500
>>@@ -350,10 +350,11 @@
>>       else {
>>               len -= (skip_sectors << 9) + skip_bytes;
>>               data += (skip_sectors << 9) + skip_bytes;
>>+               skip_sectors = os_download(data, len, eof);
>>+               skip_bytes = 0;
>>+
>>       }
>>-       skip_sectors = os_download(data, len, eof);
>>-       skip_bytes = 0;
>>-
>>+
>>       return 1;
>> }
>>
>>Steve Magnani
>>www.digidescorp.com
>>
>>-----Original Message-----
>>From: yhlu [mailto:yinghailu at gmail.com]
>>Sent: Thursday, July 14, 2005 9:10 AM
>>To: Steven J. Magnani
>>Cc: Stephen.Kimball at bench.com; linuxbios at openbios.org
>>Subject: Re: [LinuxBIOS] etherboot with LinuxBIOS
>>
>>
>>do not use 5.4 at this time, because the memtest can not be loaded by
>>Etherboot 5.4 correctly.
>>
>>YH
>>
>>On 7/14/05, Steven J. Magnani <steve at digidescorp.com> wrote:
>>
>>>Etherboot 5.4.0 seems to compile with gcc-3.4.3 if, in addition to the
>>
>>>config changes spelled out on the Wiki, you also comment out PXE
>>>support in src/Config:
>>>
>>># Etherboot as a PXE network protocol ROM
>>>#CFLAGS+=       -DPXE_IMAGE -DPXE_EXPORT
>>>
>>>Seems to run, but I haven't reached a point where I can boot something
>>
>>>over the network yet.
>>>
>>>Steve
>>>www.digidescorp.com
>>>
>>>
>>>
>>>
>>>_______________________________________________
>>>LinuxBIOS mailing list
>>>LinuxBIOS at openbios.org
>>>http://www.openbios.org/mailman/listinfo/linuxbios
>>>
>>
>>
>>
>>
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
> _______________________________________________
> Etherboot-users mailing list
> Etherboot-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/etherboot-users
> 



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Etherboot-users mailing list
Etherboot-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/etherboot-users






From yinghailu at gmail.com  Mon Jul 18 12:30:15 2005
From: yinghailu at gmail.com (yhlu)
Date: Mon, 18 Jul 2005 11:30:15 +0100
Subject: [Etherboot-users] Re: [LinuxBIOS] etherboot with LinuxBIOS
In-Reply-To: <42DB039B.7020905@rogers.com>
References: <2ea3fae105071408101e90b823@mail.gmail.com>
	<000001c58973$4b7a0760$6ffea8c0@banana>
	<2ea3fae10507151233721c9f0d@mail.gmail.com>
	<42DB039B.7020905@rogers.com>
Message-ID: <000001c58b83$aff25c80$0200a8c0@lawry.local>

Good.

I may switch to 5.4 from now on...

YH

On 7/17/05, Timothy Legge <tlegge at rogers.com> wrote:
> I made the original change that caused this:
> 
> http://cvs.sourceforge.net/viewcvs.py/etherboot/etherboot/etherboot-5.3/src/core/Attic/osloader.c?r1=1.5&r2=1.6&diff_format=u
> 
> At the time the change was made to fix an issue that was reported to
> cause Etherboot to fail to boot some kernels.  IIRC, EB failed to
> recognize that the kernel download was complete.  However, the fix seems
> to have broken memtest and FreeBSD.
> 
>  From my point of view the this patch should be accepted to revert to
> the original functionality.  I think this may cause the original problem
> that I tried to correct to reappear but that may help someone fix the
> real problem correctly this time.
> 
> Regards
> 
> Tim
> 
> yhlu wrote:
> > Great,
> >
> > Tim, Can you verify that?
> >
> > YH
> >
> > On 7/15/05, Steven J. Magnani <steve at digidescorp.com> wrote:
> >
> >>I think this patch fixes the bug.
> >>
> >>--- etherboot-5.4.0/src/core/osloader.c.orig    2005-02-15
> >>19:46:56.000000000 -0600
> >>+++ etherboot-5.4.0/src/core/osloader.c 2005-07-15 14:13:39.234375000
> >>-0500
> >>@@ -350,10 +350,11 @@
> >>       else {
> >>               len -= (skip_sectors << 9) + skip_bytes;
> >>               data += (skip_sectors << 9) + skip_bytes;
> >>+               skip_sectors = os_download(data, len, eof);
> >>+               skip_bytes = 0;
> >>+
> >>       }
> >>-       skip_sectors = os_download(data, len, eof);
> >>-       skip_bytes = 0;
> >>-
> >>+
> >>       return 1;
> >> }
> >>
> >>Steve Magnani
> >>www.digidescorp.com
> >>
> >>-----Original Message-----
> >>From: yhlu [mailto:yinghailu at gmail.com]
> >>Sent: Thursday, July 14, 2005 9:10 AM
> >>To: Steven J. Magnani
> >>Cc: Stephen.Kimball at bench.com; linuxbios at openbios.org
> >>Subject: Re: [LinuxBIOS] etherboot with LinuxBIOS
> >>
> >>
> >>do not use 5.4 at this time, because the memtest can not be loaded by
> >>Etherboot 5.4 correctly.
> >>
> >>YH
> >>
> >>On 7/14/05, Steven J. Magnani <steve at digidescorp.com> wrote:
> >>
> >>>Etherboot 5.4.0 seems to compile with gcc-3.4.3 if, in addition to the
> >>
> >>>config changes spelled out on the Wiki, you also comment out PXE
> >>>support in src/Config:
> >>>
> >>># Etherboot as a PXE network protocol ROM
> >>>#CFLAGS+=       -DPXE_IMAGE -DPXE_EXPORT
> >>>
> >>>Seems to run, but I haven't reached a point where I can boot something
> >>
> >>>over the network yet.
> >>>
> >>>Steve
> >>>www.digidescorp.com
> >>>
> >>>
> >>>
> >>>
> >>>_______________________________________________
> >>>LinuxBIOS mailing list
> >>>LinuxBIOS at openbios.org
> >>>http://www.openbios.org/mailman/listinfo/linuxbios
> >>>
> >>
> >>
> >>
> >>
> >
> >
> > -------------------------------------------------------
> > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> > from IBM. Find simple to follow Roadmaps, straightforward articles,
> > informative Webcasts and more! Get everything you need to get up to
> > speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
> > _______________________________________________
> > Etherboot-users mailing list
> > Etherboot-users at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/etherboot-users
> >
> 
>


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
_______________________________________________
Etherboot-users mailing list
Etherboot-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/etherboot-users






From gwatson at lanl.gov  Tue Jul 19 23:26:39 2005
From: gwatson at lanl.gov (Greg Watson)
Date: Tue, 19 Jul 2005 15:26:39 -0600
Subject: [LinuxBIOS] x86 cache-as-ram has broken ppc
In-Reply-To: <3174569B9743D511922F00A0C943142307291661@TYANWEB>
References: <3174569B9743D511922F00A0C943142307291661@TYANWEB>
Message-ID: <91887F0F-121E-4FD2-9B8E-EB408828F810@lanl.gov>

Hi,

Someone (YhLu I think) has added x86 specific commands to config/ 
Config.lb using the CONFIG_USE_INIT option. This option is used by  
the PPC port, which is now broken because of these changes. Also, lib/ 
Config.lb was changed to comment out some initobject lines that were  
also used by PPC.

As a rule, I don't believe there should be any architecture specifics  
in config/Config.lb. These really belong in the arch tree somewhere.

Greg



From yinghailu at gmail.com  Tue Jul 19 23:40:03 2005
From: yinghailu at gmail.com (yhlu)
Date: Tue, 19 Jul 2005 14:40:03 -0700
Subject: [LinuxBIOS] x86 cache-as-ram has broken ppc
In-Reply-To: <91887F0F-121E-4FD2-9B8E-EB408828F810@lanl.gov>
References: <3174569B9743D511922F00A0C943142307291661@TYANWEB>
	<91887F0F-121E-4FD2-9B8E-EB408828F810@lanl.gov>
Message-ID: <2ea3fae10507191440223363f5@mail.gmail.com>

I will look at later this week.

YH

On 7/19/05, Greg Watson <gwatson at lanl.gov> wrote:
> Hi,
> 
> Someone (YhLu I think) has added x86 specific commands to config/
> Config.lb using the CONFIG_USE_INIT option. This option is used by
> the PPC port, which is now broken because of these changes. Also, lib/
> Config.lb was changed to comment out some initobject lines that were
> also used by PPC.
> 
> As a rule, I don't believe there should be any architecture specifics
> in config/Config.lb. These really belong in the arch tree somewhere.
> 
> Greg
> 
> _______________________________________________
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>



From jschildt at lnxi.com  Wed Jul 20 19:06:30 2005
From: jschildt at lnxi.com (Jason Schildt)
Date: Wed, 20 Jul 2005 11:06:30 -0600
Subject: [LinuxBIOS] The Eric B. Mega-patch
Message-ID: <20050720170630.GD5709@zoot.lnxi.com>

Stefan, Ollie, and Ron,

Has Eric's Mega-patch been incorporated into the public tree?  I've just
created the LNXI mirror of the freebios2 tree and want to make sure that
I'm starting with the tip.
Thanks,

--jason--

-- 

Jason W. Schildt	
LinuxBIOS Software Engineer   
Linux Networx      



From yinghailu at gmail.com  Wed Jul 20 19:19:00 2005
From: yinghailu at gmail.com (yhlu)
Date: Wed, 20 Jul 2005 10:19:00 -0700
Subject: [LinuxBIOS] The Eric B. Mega-patch
In-Reply-To: <20050720170630.GD5709@zoot.lnxi.com>
References: <20050720170630.GD5709@zoot.lnxi.com>
Message-ID: <2ea3fae105072010191c591b2c@mail.gmail.com>

YES, in the svn.

YH

On 7/20/05, Jason Schildt <jschildt at lnxi.com> wrote:
> Stefan, Ollie, and Ron,
> 
> Has Eric's Mega-patch been incorporated into the public tree?  I've just
> created the LNXI mirror of the freebios2 tree and want to make sure that
> I'm starting with the tip.
> Thanks,
> 
> --jason--
> 
> --
> 
> Jason W. Schildt
> LinuxBIOS Software Engineer
> Linux Networx
> 
> _______________________________________________
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>



From ollie at lanl.gov  Wed Jul 20 20:13:49 2005
From: ollie at lanl.gov (Li-Ta Lo)
Date: Wed, 20 Jul 2005 12:13:49 -0600
Subject: [LinuxBIOS] The Eric B. Mega-patch
In-Reply-To: <20050720170630.GD5709@zoot.lnxi.com>
References: <20050720170630.GD5709@zoot.lnxi.com>
Message-ID: <1121883229.5202.37.camel@logarithm.lanl.gov>

On Wed, 2005-07-20 at 11:06 -0600, Jason Schildt wrote:
> Stefan, Ollie, and Ron,
> 
> Has Eric's Mega-patch been incorporated into the public tree?  I've just
> created the LNXI mirror of the freebios2 tree and want to make sure that
> I'm starting with the tip.
> Thanks,
> 

Yes. The new SVN tree has all the goodies. There are Cache as RAM for 
both AMD and Intel processors and most of the Eric's mega patch.

Please be aware that there are some mistakes in Eric's mega patch. He 
put some obsoleted files in his tree and he also removed FILO which is
required on PPC. 

-- 
Li-Ta Lo <ollie at lanl.gov>
Los Alamos National Lab




From jschildt at lnxi.com  Wed Jul 20 21:17:46 2005
From: jschildt at lnxi.com (Jason Schildt)
Date: Wed, 20 Jul 2005 13:17:46 -0600
Subject: [LinuxBIOS] The Eric B. Mega-patch
In-Reply-To: <1121883229.5202.37.camel@logarithm.lanl.gov>
References: <20050720170630.GD5709@zoot.lnxi.com>
	<1121883229.5202.37.camel@logarithm.lanl.gov>
Message-ID: <20050720191745.GC5914@zoot.lnxi.com>

On Wed, Jul 20, 2005 at 12:13:49PM -0600, Li-Ta Lo wrote:
> On Wed, 2005-07-20 at 11:06 -0600, Jason Schildt wrote:
> > Stefan, Ollie, and Ron,
> > 
> > Has Eric's Mega-patch been incorporated into the public tree?  I've just
> > created the LNXI mirror of the freebios2 tree and want to make sure that
> > I'm starting with the tip.
> > Thanks,
> > 
> 
> Yes. The new SVN tree has all the goodies. There are Cache as RAM for 
> both AMD and Intel processors and most of the Eric's mega patch.
> 
> Please be aware that there are some mistakes in Eric's mega patch. He 
> put some obsoleted files in his tree and he also removed FILO which is
> required on PPC. 

So are the obsolete files you mentioned the parts that have not been
committed?  Also, do you have plans to re-commit the FILO support that
he removed?

--jason--

-- 

Jason W. Schildt	
LinuxBIOS Software Engineer   
Linux Networx      



From ollie at lanl.gov  Wed Jul 20 23:06:54 2005
From: ollie at lanl.gov (Li-Ta Lo)
Date: Wed, 20 Jul 2005 15:06:54 -0600
Subject: [LinuxBIOS] The Eric B. Mega-patch
In-Reply-To: <20050720191745.GC5914@zoot.lnxi.com>
References: <20050720170630.GD5709@zoot.lnxi.com>
	<1121883229.5202.37.camel@logarithm.lanl.gov>
	<20050720191745.GC5914@zoot.lnxi.com>
Message-ID: <1121893614.5202.43.camel@logarithm.lanl.gov>

On Wed, 2005-07-20 at 13:17 -0600, Jason Schildt wrote:
> On Wed, Jul 20, 2005 at 12:13:49PM -0600, Li-Ta Lo wrote:
> > On Wed, 2005-07-20 at 11:06 -0600, Jason Schildt wrote:
> > > Stefan, Ollie, and Ron,
> > > 
> > > Has Eric's Mega-patch been incorporated into the public tree?  I've just
> > > created the LNXI mirror of the freebios2 tree and want to make sure that
> > > I'm starting with the tip.
> > > Thanks,
> > > 
> > 
> > Yes. The new SVN tree has all the goodies. There are Cache as RAM for 
> > both AMD and Intel processors and most of the Eric's mega patch.
> > 
> > Please be aware that there are some mistakes in Eric's mega patch. He 
> > put some obsoleted files in his tree and he also removed FILO which is
> > required on PPC. 
> 
> So are the obsolete files you mentioned the parts that have not been
> committed?  Also, do you have plans to re-commit the FILO support that
> he removed?
> 


In the current SVN these issues are solved. The obsolete files were not 
committed and FILO was not removed.
 
-- 
Li-Ta Lo <ollie at lanl.gov>
Los Alamos National Lab




From keven.tipping at realitydi.com  Fri Jul 22 22:35:10 2005
From: keven.tipping at realitydi.com (Keven Tipping)
Date: Fri, 22 Jul 2005 14:35:10 -0600
Subject: [LinuxBIOS] Qemu target broken?
Message-ID: <42E1587E.9050003@realitydi.com>

Greetings to all!

I was recently attempting to build Linuxbios primarily to see how it 
works and what OpenBIOS is all about.

Therefore, I'm building LB under a Debian 3.1 machine. OpenBIOS has been 
compiled as the payload and set under 
targets/emulation/qemu-i386/config.lb. LinuxBIOS compiles fine (the 
latest snapshot, SVN complains that some udelay is undefined). Qemu 
preforms the following double-backflip and dies:

PCI_DOMAIN: 0000 enabled
PCI_DOMAIN: 0000 scanning...
PCI: pci_scan_bus for bus 0
PCI: 00:00.0 Cannot find pci bus operations

It halts there till the end of time. Any ideas? Is Qemu support 
currently broken? (I'm waiting to build my geode based LinuxBIOS box 
until I can test it out somewhere else).

Thanks!
Keven Tipping



From smithbone at gmail.com  Fri Jul 22 22:58:18 2005
From: smithbone at gmail.com (Richard Smith)
Date: Fri, 22 Jul 2005 15:58:18 -0500
Subject: [LinuxBIOS] Qemu target broken?
In-Reply-To: <42E1587E.9050003@realitydi.com>
References: <42E1587E.9050003@realitydi.com>
Message-ID: <8a0c367805072213584bd3e75@mail.gmail.com>

> It halts there till the end of time. Any ideas? Is Qemu support
> currently broken? (I'm waiting to build my geode based LinuxBIOS box
> until I can test it out somewhere else).

I don't think Qemu has been worked on much.  I bet some of the arch
changes broke things.

What kide of Geode system are you looking at.  We've reciently been
looking at some geode stuff and I was considering working on some
linuxbios support.

-- 
Richard A. Smith



From yinghailu at gmail.com  Sun Jul 24 00:32:44 2005
From: yinghailu at gmail.com (yhlu)
Date: Sat, 23 Jul 2005 15:32:44 -0700
Subject: [LinuxBIOS] ABout pref_mem allocation
Message-ID: <2ea3fae10507231532b4e5d63@mail.gmail.com>

Eirc,

I met one system: 4 way and every node has one ck804.

because current mem and pref-mem allocation will make every node two
mem range ( not together), So PCI_DEV(0, 0x18,1) 0x80-0xbf regs that
record mmio range will be used up.

So they there is some problem to enable VGA console, because vga
console need [0xa0000, 0xc0000) to be set as mmio too.

I remember that very beginning the PCI resource treat pref-mem io as
memio, and at last when setting that just make the upper 32 base and
limit to 0....

If you agree, I will put the old code back and add one CONFIG_NO_PREF_MEM....

YH



From okajima at digitalinfra.co.jp  Sun Jul 24 05:33:53 2005
From: okajima at digitalinfra.co.jp (Jun OKAJIMA)
Date: Sun, 24 Jul 2005 12:33:53 +0900
Subject: [LinuxBIOS] YEAH! EPIA WORKS!
Message-ID: <200507240333.AA00192@bbb-jz5c7z9hn9y.digitalinfra.co.jp>


Hello all guys here.

Finally, the very foolish guy in Tokyo has succeeded to run
LX2 on my EPIA M/B. Thank you all. Thanks for all helps. Thank you!!!.

But, of course, there are problems and questions.

---------------
first, the biggest issue is, DIMMs are really picky. The M/B
is natively picky, I mean, even with Award BIOS, it is picky.
but the problem is much more serious with LX2.
I tested with two EPIA M/B and 5 DIMMs which all
are confirmed to work well with Award BIOS. And the result
is too much great. Only one combination worked in these
10 combinations. Guys, can you help?

I think that one solution is hard coding the params of mem
in a BIOS image. But, how?

--------------
The second issue is, booting time. It is very fast before
a kernel loaded, but after this, there are three glitches.
I know at least two of them are not LX2 issue, but I hope any advice.

1. Just after "Jumping to entry point...".
Probably this waiting is caused by "Uncompressing Linux kernel",
but it is much slower than normal booting. Takes about 2 sec.

2. 
   "Console: colour dummy device 80x25
         <---- here.
    Memory: 128128k/131072k available"
This comes from memory checking? It takes about 1 sec.

3. IDE recognizing.
   I added "ide0=0x1f0,0x3f6,14 ide1=noprobe", but it takes about 2 secs.


---------------
The third issue is, VGA.
I read the FreeVGA paper. Yes, it seems great.
But such complicated technology is really necessary?
For example, this guy succeeded to use normal VGA bios, although I failed.
http://www.carbotpc.com/linux/index.html
Or, just using Xfree86 driver doesnt work?



                              --- Okajima, Jun. Tokyo, Japan.







From ollie at lanl.gov  Sun Jul 24 07:42:51 2005
From: ollie at lanl.gov (Li-Ta Lo)
Date: Sat, 23 Jul 2005 23:42:51 -0600
Subject: [LinuxBIOS] YEAH! EPIA WORKS!
In-Reply-To: <200507240333.AA00192@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
References: <200507240333.AA00192@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
Message-ID: <1122183773.5753.27.camel@logarithm.lanl.gov>

On Sun, 2005-07-24 at 12:33 +0900, Jun OKAJIMA wrote:
> Hello all guys here.
> 
> Finally, the very foolish guy in Tokyo has succeeded to run
> LX2 on my EPIA M/B. Thank you all. Thanks for all helps. Thank you!!!.
> 
> But, of course, there are problems and questions.
> 
> ---------------
> first, the biggest issue is, DIMMs are really picky. The M/B
> is natively picky, I mean, even with Award BIOS, it is picky.
> but the problem is much more serious with LX2.
> I tested with two EPIA M/B and 5 DIMMs which all
> are confirmed to work well with Award BIOS. And the result
> is too much great. Only one combination worked in these
> 10 combinations. Guys, can you help?
> 
> I think that one solution is hard coding the params of mem
> in a BIOS image. But, how?
> 

The documentation from VIA is simply crap. Nobody actually really
know the correct value to program to the memory controller. 


> --------------
> The second issue is, booting time. It is very fast before
> a kernel loaded, but after this, there are three glitches.
> I know at least two of them are not LX2 issue, but I hope any advice.
> 
> 1. Just after "Jumping to entry point...".
> Probably this waiting is caused by "Uncompressing Linux kernel",
> but it is much slower than normal booting. Takes about 2 sec.
> 
> 2. 
>    "Console: colour dummy device 80x25
>          <---- here.
>     Memory: 128128k/131072k available"
> This comes from memory checking? It takes about 1 sec.
> 

The cache is not enable at all due to some mistake in the mainboard
Config.lb. I think I have a correct one but I was busy doing porting
to some other mainboard and didn't have time to test it. I will try
to do it next week.

> 3. IDE recognizing.
>    I added "ide0=0x1f0,0x3f6,14 ide1=noprobe", but it takes about 2 secs.
> 
> 
> ---------------
> The third issue is, VGA.
> I read the FreeVGA paper. Yes, it seems great.
> But such complicated technology is really necessary?

I am afraid we have to do it this way. It is probably the only way
we can get VGA working without any vendor support.

> For example, this guy succeeded to use normal VGA bios, although I failed.
> http://www.carbotpc.com/linux/index.html

I think this one uses the old "switch back to 16-bit mode and back"
technology. It is actually much more complicated than an emulator.

You can try to add VGA support by yourself. Please take a look at
arima/hdama and tyan/*. There is one problem you have to solve,
the VGA BIOS on EPIA makes some BIOS call back to the system BIOS,
you have to emulate this in the emulator (see pcibios.c).

> Or, just using Xfree86 driver doesnt work?
> 

No. The Xfree86 driver is too stupid to do a full hardware 
initialization.

-- 
Li-Ta Lo <ollie at lanl.gov>
Los Alamos National Lab




From okajima at digitalinfra.co.jp  Sun Jul 24 16:52:21 2005
From: okajima at digitalinfra.co.jp (Jun OKAJIMA)
Date: Sun, 24 Jul 2005 23:52:21 +0900
Subject: [LinuxBIOS] YEAH! EPIA WORKS!
In-Reply-To: <1122183773.5753.27.camel@logarithm.lanl.gov>
References: <1122183773.5753.27.camel@logarithm.lanl.gov>
Message-ID: <200507241452.AA00193@bbb-jz5c7z9hn9y.digitalinfra.co.jp>

>> 
>> I think that one solution is hard coding the params of mem
>> in a BIOS image. But, how?
>> 
>
>The documentation from VIA is simply crap. Nobody actually really
>know the correct value to program to the memory controller. 
>
>

Sorry, My explanation was wrong. I tested many combination 
of M/B and DIMMs. And found most of then dont work at all, but
a little of them work rarelly. I mean, some combination work
but VERY unstable. For example, work once in 100 times reset.

So, My idea is, for this kind of very unstable combination, do like this.
1. add a func outputting params to console.
2. try, try, try. push reset, push reset and hope to run.
3. If it works as it happens, hard code this param to the src.
4. hope runs stably.

How about this way?


>> ---------------
>> The third issue is, VGA.
>> I read the FreeVGA paper. Yes, it seems great.
>> But such complicated technology is really necessary?
>
>I am afraid we have to do it this way. It is probably the only way
>we can get VGA working without any vendor support.
>
>> For example, this guy succeeded to use normal VGA bios, although I failed.
>> http://www.carbotpc.com/linux/index.html
>
>I think this one uses the old "switch back to 16-bit mode and back"
>technology. It is actually much more complicated than an emulator.
>
>You can try to add VGA support by yourself. Please take a look at
>arima/hdama and tyan/*. There is one problem you have to solve,
>the VGA BIOS on EPIA makes some BIOS call back to the system BIOS,
>you have to emulate this in the emulator (see pcibios.c).
>

Umm.. Then, how about porting LX1 VGA code to LX2?
In my EPIA M/B, LX1 VGA init seems to work.

                --- Okajima, Jun. Tokyo, Japan.



From ollie at lanl.gov  Sun Jul 24 19:05:20 2005
From: ollie at lanl.gov (Li-Ta Lo)
Date: Sun, 24 Jul 2005 11:05:20 -0600
Subject: [LinuxBIOS] YEAH! EPIA WORKS!
In-Reply-To: <200507241452.AA00193@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
References: <1122183773.5753.27.camel@logarithm.lanl.gov>
	<200507241452.AA00193@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
Message-ID: <1122224720.5393.18.camel@logarithm.lanl.gov>

On Sun, 2005-07-24 at 23:52 +0900, Jun OKAJIMA wrote:
> >> 
> >> I think that one solution is hard coding the params of mem
> >> in a BIOS image. But, how?
> >> 
> >
> >The documentation from VIA is simply crap. Nobody actually really
> >know the correct value to program to the memory controller. 
> >
> >
> 
> Sorry, My explanation was wrong. I tested many combination 
> of M/B and DIMMs. And found most of then dont work at all, but
> a little of them work rarelly. I mean, some combination work
> but VERY unstable. For example, work once in 100 times reset.
> 
> So, My idea is, for this kind of very unstable combination, do like this.
> 1. add a func outputting params to console.
> 2. try, try, try. push reset, push reset and hope to run.
> 3. If it works as it happens, hard code this param to the src.
> 4. hope runs stably.
> 
> How about this way?
> 

You can try it but the current implementation in the SVN tree is 
probably the best thing we can get.

The chipset is really a headache, even adding some console output in
the DRAM init phase will crash the system.

If you do have a lot of time and MB/DIMM, you can try to boot with
factory BIOS and compare the northbridge register value to figure
out any relation between these values and the DIMM configuration.

> 
> >> ---------------
> >> The third issue is, VGA.
> >> I read the FreeVGA paper. Yes, it seems great.
> >> But such complicated technology is really necessary?
> >
> >I am afraid we have to do it this way. It is probably the only way
> >we can get VGA working without any vendor support.
> >
> >> For example, this guy succeeded to use normal VGA bios, although I failed.
> >> http://www.carbotpc.com/linux/index.html
> >
> >I think this one uses the old "switch back to 16-bit mode and back"
> >technology. It is actually much more complicated than an emulator.
> >
> >You can try to add VGA support by yourself. Please take a look at
> >arima/hdama and tyan/*. There is one problem you have to solve,
> >the VGA BIOS on EPIA makes some BIOS call back to the system BIOS,
> >you have to emulate this in the emulator (see pcibios.c).
> >
> 
> Umm.. Then, how about porting LX1 VGA code to LX2?
> In my EPIA M/B, LX1 VGA init seems to work.
> 

I don't think we are going to do that. The reason we are using the 
emulator is to eliminate the mode switch inside LB.

>                 --- Okajima, Jun. Tokyo, Japan.
-- 
Li-Ta Lo <ollie at lanl.gov>
Los Alamos National Lab




From bari at onelabs.com  Sun Jul 24 19:40:00 2005
From: bari at onelabs.com (Bari Ari)
Date: Sun, 24 Jul 2005 12:40:00 -0500
Subject: [LinuxBIOS] YEAH! EPIA WORKS!
In-Reply-To: <1122183773.5753.27.camel@logarithm.lanl.gov>
References: <200507240333.AA00192@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
	<1122183773.5753.27.camel@logarithm.lanl.gov>
Message-ID: <42E3D270.30000@onelabs.com>

Li-Ta Lo wrote:

> The documentation from VIA is simply crap. Nobody actually really
> know the correct value to program to the memory controller. 

Are you referring to the VIA doc's here:
http://www.via.com.tw/en/resources/download-center/chipsets/

or the NDA versions?

Ask VIA for the NDA versions, they are quite detailed in memory 
controller operation and setup. VIA has been very open with data sheets, 
they have even released all the specs. for the 3D graphics controllers 
and libraries.

-Bari




From rminnich at lanl.gov  Sun Jul 24 22:22:18 2005
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Sun, 24 Jul 2005 14:22:18 -0600 (MDT)
Subject: [LinuxBIOS] YEAH! EPIA WORKS!
In-Reply-To: <1122224720.5393.18.camel@logarithm.lanl.gov>
References: <1122183773.5753.27.camel@logarithm.lanl.gov>
	<200507241452.AA00193@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
	<1122224720.5393.18.camel@logarithm.lanl.gov>
Message-ID: <Pine.LNX.4.58.0507241421250.683@enigma.lanl.gov>



On Sun, 24 Jul 2005, Li-Ta Lo wrote:

> I don't think we are going to do that. The reason we are using the 
> emulator is to eliminate the mode switch inside LB.

the mode switch is DANGEROUS. Yes, maybe you can get one or two cards to 
work, but you are counting on all card BIOSes doing sane things, and many 
of them do not. The emulator approach is the only really safe way to bring 
up VGA. 

Besides, it's usually much faster ...

ron



From ollie at lanl.gov  Mon Jul 25 02:56:17 2005
From: ollie at lanl.gov (Li-Ta Lo)
Date: Sun, 24 Jul 2005 18:56:17 -0600
Subject: [LinuxBIOS] YEAH! EPIA WORKS!
In-Reply-To: <42E3D270.30000@onelabs.com>
References: <200507240333.AA00192@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
	<1122183773.5753.27.camel@logarithm.lanl.gov>
	<42E3D270.30000@onelabs.com>
Message-ID: <1122252977.5393.23.camel@logarithm.lanl.gov>

On Sun, 2005-07-24 at 12:40 -0500, Bari Ari wrote:
> Li-Ta Lo wrote:
> 
> > The documentation from VIA is simply crap. Nobody actually really
> > know the correct value to program to the memory controller. 
> 
> Are you referring to the VIA doc's here:
> http://www.via.com.tw/en/resources/download-center/chipsets/
> 
> or the NDA versions?
> 

I think we got the NDA version (that's before I became part of the we).
The documentation related to DRAM init is totally nonsense from my point
of view, it just doesn't work if you program according to the spec.

> Ask VIA for the NDA versions, they are quite detailed in memory 
> controller operation and setup. VIA has been very open with data sheets, 
> they have even released all the specs. for the 3D graphics controllers 
> and libraries.
-- 
Li-Ta Lo <ollie at lanl.gov>
Los Alamos National Lab




From rminnich at lanl.gov  Mon Jul 25 05:06:35 2005
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Sun, 24 Jul 2005 21:06:35 -0600 (MDT)
Subject: [LinuxBIOS] YEAH! EPIA WORKS!
In-Reply-To: <1122252977.5393.23.camel@logarithm.lanl.gov>
References: <200507240333.AA00192@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
	<1122183773.5753.27.camel@logarithm.lanl.gov>
	<42E3D270.30000@onelabs.com>
	<1122252977.5393.23.camel@logarithm.lanl.gov>
Message-ID: <Pine.LNX.4.58.0507242106080.1280@enigma.lanl.gov>



On Sun, 24 Jul 2005, Li-Ta Lo wrote:

> I think we got the NDA version (that's before I became part of the we).
> The documentation related to DRAM init is totally nonsense from my point
> of view, it just doesn't work if you program according to the spec.

The docs I have for the 8601 were nda, are now the open docs. If you 
follow the docs, the chip will lock up. 

ron



From GBu at lem.com  Tue Jul 26 15:15:57 2005
From: GBu at lem.com (Gernot Butschek)
Date: Tue, 26 Jul 2005 15:15:57 +0200
Subject: [LinuxBIOS] LinuxBIOS support for Kontron ETX board
Message-ID: <OF363CE383.FD34F093-ONC125704A.00472E47-C125704A.0048E140@lem.com>

Hi everybody,

I'm working on an embedded project and am using a Kontron embedded board 
(see details below).
I'm wondering if LinuxBIOS supports this board in order to get rid of the 
last piece of proprietary software.

Thanks for your help.
Gernot Butschek

Board specifications:

0 Brief description
  Kontron ETX industrial PC board: ETX-P3T 4000
  Processor: Intel Celeron Processor (0.13 ?) in Micro-FCBGA (?BGA479) 
400MHz
  Bus: 100MHz CPU bus, 100MHz memory bus
  Chipset: Intel 815 (north bridge)
           Intel 82801DB (south bridge)
  Super I/O: Winbond W83627HF connected by using an LPC interface
  Cache: On-die Second level 256k
  Memory: One 144-pin SO-DIMM 3.3V PC-PC-133 or PC-100 unbuffered SDRAM, 
up to 512MB
  Enhanced Intelligent Drive Electronics (EIDE): Two Peripheral Component 
  Interconnect (PCI) Bus Master IDE ports (up to four devices) support:
     - Ultra 33 Direct Memory Access (DMA) mode
     - Programmed Input/Output (PIO) modes up to Mode 4 timing
     - Multiword DMA Mode 0,1,2 with independent timing
  Universal Serial Bus (USB): Four USB 1.1/2.0 ports (UHCI and EHCI)
  Integrated Ethernet: Intel 82562 10/100 Mbps Fast Ethernet controller
  Onboard video graphics array (VGA): Integrated in Intel? 815:
     - Graphics memory controller hub
     - Up to 1MB Video RAM (UMA)
  Audio: Integrated in Intel 82801DB southbridge
     - SoundBlaster? AC97, Windows Sound System? compatible
  BIOS: Phoenix, 512k Flash-BIOS
     - NV-EEPROM for CMOS-setup retention without battery
  BIOS support for additional super I/O devices (COM3, COM4, LPT, and 
Floppy)

1 LSPCI output
0000:00:00.0 Host bridge: Intel Corp. 82815 815 Chipset Host Bridge and 
Memory Controller Hub (rev 04)
0000:00:02.0 VGA compatible controller: Intel Corp. 82815 CGC [Chipset 
Graphics Controller] (rev 04)
0000:00:1d.0 USB Controller: Intel Corp. 82801DB/DBL/DBM 
(ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 02)
0000:00:1d.1 USB Controller: Intel Corp. 82801DB/DBL/DBM 
(ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 02)
0000:00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev 82)
0000:00:1f.0 ISA bridge: Intel Corp. 82801DB/DBL (ICH4/ICH4-L) LPC Bridge 
(rev 02)
0000:00:1f.1 IDE interface: Intel Corp. 82801DB/DBL (ICH4/ICH4-L) 
UltraATA-100 IDE Controller (rev 02)
0000:00:1f.3 SMBus: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus 
Controller (rev 02)
0000:00:1f.5 Multimedia audio controller: Intel Corp. 82801DB/DBL/DBM 
(ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 02)
0000:01:08.0 Ethernet controller: Intel Corp. 82801BD PRO/100 VE (CNR) 
Ethernet Controller (rev 82)

2 Super IO chip
  Winbond W83627HF connected by using an LPC interface
 
3 Type of BIOS device
  Flash Memory 8 Mbit (1M x8, Uniform Block), 3V Supply Firmware Hub Flash 
Memory
  ST Microelectronic M50FW080 (Package TSOP 40)
 
4 URL to Mainboard specifications
  http://www.kontron-em.com/product/we_docs/etx.php?lang=e
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20050726/c7d1c6f0/attachment.html>

From rminnich at lanl.gov  Tue Jul 26 17:52:23 2005
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Tue, 26 Jul 2005 09:52:23 -0600 (MDT)
Subject: [LinuxBIOS] LinuxBIOS support for Kontron ETX board
In-Reply-To: <OF363CE383.FD34F093-ONC125704A.00472E47-C125704A.0048E140@lem.com>
References: <OF363CE383.FD34F093-ONC125704A.00472E47-C125704A.0048E140@lem.com>
Message-ID: <Pine.LNX.4.58.0507260952040.5910@enigma.lanl.gov>



On Tue, 26 Jul 2005, Gernot Butschek wrote:

> I'm working on an embedded project and am using a Kontron embedded board
> (see details below). I'm wondering if LinuxBIOS supports this board in
> order to get rid of the last piece of proprietary software.

we have never had an 815 ported to linuxbios, but if you can get docs, it 
should not be hard.

ron



From huangjen.wang at gmail.com  Wed Jul 27 03:13:50 2005
From: huangjen.wang at gmail.com (Huang-Jen Wang)
Date: Wed, 27 Jul 2005 09:13:50 +0800
Subject: [LinuxBIOS] A boot problem....
Message-ID: <4325815c05072618137ccace3d@mail.gmail.com>

Dear all,
My linuxbios tried to boot the linux...but has a problem..hope you can
give me some advice...thanks....the message is follow:
.....
ollect_sys_info: 00000000000c0000-00000                                       
pci_init: 01:02.0 1166:0130 0604 00                                   
pci_init: 01:03.0 1166:0132 0604 00nt addr 0x1258e0 size 0x48 offset 0
pci_init: 01:04.0 1166:0132 0604 00                                   
pci_init: 01:05.0 1166:0132 0604 00n PT_LOAD segment                  
pci_init: 01:06.0 1166:0132 0604 000000000000100000 memsz: 0x000000000
pci_init: 01:07.0 1166:0036 0604 00                                   
pci_init: 01:09.0 1166:0223 0c03 10                                   
pci_init: 01:09.1 1166:0223 0c03 10       
00000000000048             
pci_init: 01:09.2 1166:0223 0c03 20                              
FILO
pci_init: 02:06.0 1000:0030 0100 00domain) Fri Jul 22 19:47:38 CST 200
pci_init: 03:04.0 14e4:1668 0200 00                                   
pci_init: 03:04.1 14e4:1668 0200 000xe1fb007                          
pci_init: 08:0d.0 1166:0104 0604 00ebx = 0x1ffe9420                   
Press <Enter> for default boot, or <Esc> for boot prompt... timed out
collect_linuxbios_info: Searching for L
boot: hda1:/vmlinuz-2.4.20-8 root=/dev/hda2 console=tty0
console=ttyS0,115200nd_lb_table: Found canidate at: 00000500
collect_linuxbios_info: Found LinuxBIOS tabl
find_ide_controller: cmd_base=0x1f0 ctrl_base=0x3f4                    
convert_memmap: 0x000000000000
ide_software_reset: Waiting for ide0 to become ready for reset... ok     
convert_memmap: 0x00000000000de0 0x0000000009f220 1           
init_drive: Testing for hda            
convert_memmap
init_drive: Probing for hda0030000 1                  
init_drive: LBA mode, sectors=12672450rt_memmap: 0x000000000f0000 0x00000000
init_drive: Init device params... ok                        
init_drive: Probing for hdb
print_status: IDE: status=0x0, err=0x0
Mounted ext2fs
Found Linux version 2.4.20-8 (bhcompile at stripples.devel.redhat.com) #1 Thu Mar 1
3 17:18:24 EST 2003 bzImage.
Loading kernel... ok
Jumping to entry point...
Linux version 2.4.20-8 (bhcompile at stripples.devel.redhat.com) (gcc version 3.2.2
 20030222 (Red Hat Linux 3.2.2-5)) #1 Thu Mar 13 17:18:24 EST 2003
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000de0 - 00000000000a0000 (usable)
 BIOS-e820: 0000000000100000 - 0000000020000000 (usable)
0MB HIGHMEM available.
512MB LOWMEM available.
hm, page 00000000 reserved twice.
On node 0 totalpages: 131072
zone(0): 4096 pages.
zone(1): 126976 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/hda2 console=tty0 console=ttyS0,115200
Initializing CPU#0
Detected 1995.061 MHz processor.
Console: colour dummy device 80x25
Calibrating delay loop...



From yinghailu at gmail.com  Wed Jul 27 04:41:11 2005
From: yinghailu at gmail.com (yhlu)
Date: Tue, 26 Jul 2005 19:41:11 -0700
Subject: [LinuxBIOS] A boot problem....
In-Reply-To: <4325815c05072618137ccace3d@mail.gmail.com>
References: <4325815c05072618137ccace3d@mail.gmail.com>
Message-ID: <2ea3fae1050726194116bbfced@mail.gmail.com>

1. use latest kernel.
2. problem could be still with LinuxBIOS stage.

YH

On 7/26/05, Huang-Jen Wang <huangjen.wang at gmail.com> wrote:
> Dear all,
> My linuxbios tried to boot the linux...but has a problem..hope you can
> give me some advice...thanks....the message is follow:
> .....
> ollect_sys_info: 00000000000c0000-00000
> pci_init: 01:02.0 1166:0130 0604 00
> pci_init: 01:03.0 1166:0132 0604 00nt addr 0x1258e0 size 0x48 offset 0
> pci_init: 01:04.0 1166:0132 0604 00
> pci_init: 01:05.0 1166:0132 0604 00n PT_LOAD segment
> pci_init: 01:06.0 1166:0132 0604 000000000000100000 memsz: 0x000000000
> pci_init: 01:07.0 1166:0036 0604 00
> pci_init: 01:09.0 1166:0223 0c03 10
> pci_init: 01:09.1 1166:0223 0c03 10
> 00000000000048
> pci_init: 01:09.2 1166:0223 0c03 20
> FILO
> pci_init: 02:06.0 1000:0030 0100 00domain) Fri Jul 22 19:47:38 CST 200
> pci_init: 03:04.0 14e4:1668 0200 00
> pci_init: 03:04.1 14e4:1668 0200 000xe1fb007
> pci_init: 08:0d.0 1166:0104 0604 00ebx = 0x1ffe9420
> Press <Enter> for default boot, or <Esc> for boot prompt... timed out
> collect_linuxbios_info: Searching for L
> boot: hda1:/vmlinuz-2.4.20-8 root=/dev/hda2 console=tty0
> console=ttyS0,115200nd_lb_table: Found canidate at: 00000500
> collect_linuxbios_info: Found LinuxBIOS tabl
> find_ide_controller: cmd_base=0x1f0 ctrl_base=0x3f4
> convert_memmap: 0x000000000000
> ide_software_reset: Waiting for ide0 to become ready for reset... ok
> convert_memmap: 0x00000000000de0 0x0000000009f220 1
> init_drive: Testing for hda
> convert_memmap
> init_drive: Probing for hda0030000 1
> init_drive: LBA mode, sectors=12672450rt_memmap: 0x000000000f0000 0x00000000
> init_drive: Init device params... ok
> init_drive: Probing for hdb
> print_status: IDE: status=0x0, err=0x0
> Mounted ext2fs
> Found Linux version 2.4.20-8 (bhcompile at stripples.devel.redhat.com) #1 Thu Mar 1
> 3 17:18:24 EST 2003 bzImage.
> Loading kernel... ok
> Jumping to entry point...
> Linux version 2.4.20-8 (bhcompile at stripples.devel.redhat.com) (gcc version 3.2.2
>  20030222 (Red Hat Linux 3.2.2-5)) #1 Thu Mar 13 17:18:24 EST 2003
> BIOS-provided physical RAM map:
>  BIOS-e820: 0000000000000de0 - 00000000000a0000 (usable)
>  BIOS-e820: 0000000000100000 - 0000000020000000 (usable)
> 0MB HIGHMEM available.
> 512MB LOWMEM available.
> hm, page 00000000 reserved twice.
> On node 0 totalpages: 131072
> zone(0): 4096 pages.
> zone(1): 126976 pages.
> zone(2): 0 pages.
> Kernel command line: root=/dev/hda2 console=tty0 console=ttyS0,115200
> Initializing CPU#0
> Detected 1995.061 MHz processor.
> Console: colour dummy device 80x25
> Calibrating delay loop...
> 
> _______________________________________________
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>



From rvpatil at gmail.com  Wed Jul 27 04:50:19 2005
From: rvpatil at gmail.com (Rohit Patil)
Date: Tue, 26 Jul 2005 19:50:19 -0700
Subject: [LinuxBIOS] LinuxBIOS support for Kontron ETX board
In-Reply-To: <Pine.LNX.4.58.0507260952040.5910@enigma.lanl.gov>
References: <OF363CE383.FD34F093-ONC125704A.00472E47-C125704A.0048E140@lem.com>
	<Pine.LNX.4.58.0507260952040.5910@enigma.lanl.gov>
Message-ID: <8ed6e0b305072619507149f455@mail.gmail.com>

On 7/26/05, Ronald G. Minnich <rminnich at lanl.gov> wrote:
> 
> On Tue, 26 Jul 2005, Gernot Butschek wrote:
> 
> > I'm working on an embedded project and am using a Kontron embedded board
> > (see details below). I'm wondering if LinuxBIOS supports this board in
> > order to get rid of the last piece of proprietary software.
> 
> we have never had an 815 ported to linuxbios, but if you can get docs, it
> should not be hard.
> 
> ron

Hi! I'm new to this place.

There's a boatload of documentation here for anyone that maybe
interested: http://www.intel.com/design/chipsets/embedded/docs/815.htm.

A lot of it ought to be relevant, I think :)

-Rohit.
-- 
"Nature and nature's laws lay hid by night. God said 'Let Tesla be'
and all was light."



From rminnich at lanl.gov  Wed Jul 27 07:35:24 2005
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Tue, 26 Jul 2005 23:35:24 -0600 (MDT)
Subject: [LinuxBIOS] A boot problem....
In-Reply-To: <4325815c05072618137ccace3d@mail.gmail.com>
References: <4325815c05072618137ccace3d@mail.gmail.com>
Message-ID: <Pine.LNX.4.58.0507262334540.8194@enigma.lanl.gov>



On Wed, 27 Jul 2005, Huang-Jen Wang wrote:

> Calibrating delay loop...

A hang right here means you are not getting clock interrupts.

ron



From rminnich at lanl.gov  Wed Jul 27 18:30:22 2005
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Wed, 27 Jul 2005 10:30:22 -0600 (MDT)
Subject: [LinuxBIOS] A boot problem....
In-Reply-To: <4325815c0507270327474c9ae@mail.gmail.com>
References: <4325815c05072618137ccace3d@mail.gmail.com> 
	<Pine.LNX.4.58.0507262334540.8194@enigma.lanl.gov>
	<4325815c0507270327474c9ae@mail.gmail.com>
Message-ID: <Pine.LNX.4.58.0507271029410.9619@enigma.lanl.gov>



On Wed, 27 Jul 2005, Huang-Jen Wang wrote:

> Ron, 
> Excuse me , this is my first time porting....do you tell me more detail..
> like need what information or which file need to modify...

you're not getting clock IRQ, which is usually IRQ 0. you need to see how 
your interrupt hardware and/or clock is working to create interrupts.

ron



From steve at digidescorp.com  Wed Jul 27 20:29:55 2005
From: steve at digidescorp.com (Steven J. Magnani)
Date: Wed, 27 Jul 2005 13:29:55 -0500
Subject: [LinuxBIOS] Thermal monitoring of Pentium 4s
Message-ID: <001601c592d9$32b071f0$6ffea8c0@banana>

I have been looking into some thermal shutdown issues with our board,
and discovered that LinuxBIOS is not enabling the P4's ability to
throttle back when the internal sensors indicate that the processor is
getting too hot.

According to the System Programming Guide, Vol. 3 of the IA-32 Intel
Architecture Software Developer's Manual (p. 13-24):

"BIOS is required to enable only one automatic thermal monitoring modes
(sic). Operating systems and applications must not disable the operation
of these mechanisms."

Has this been considered for LB? I didn't see any discussions in the
mailing list archives.

It would be relatively easy to implement support for "TM1" thermal
control, since that's just setting a MSR bit if the proper CPUID flag is
set. "TM2" control would be a little more complicated, since there is
the added ability to control the operating frequency and voltage when
the processor trips into thermal management mode.

Steve
www.digidescorp.com






From kfuchs at winternet.com  Wed Jul 27 20:51:06 2005
From: kfuchs at winternet.com (Ken Fuchs)
Date: Wed, 27 Jul 2005 13:51:06 -0500 (CDT)
Subject: [LinuxBIOS] A boot problem....
Message-ID: <200507271851.j6RIp6kH002470@tundra.winternet.com>

Yh Lu wrote:

> 1. use latest kernel.

2.4.20-8 is a very old Red Hat patched kernel.

I'd strongly advise using at least 2.6.9.  Maybe use Fedora Core 4's
default 2.6.x kernel would be good enough.

The current stable Linux kernel at kernel.org is 2.6.12.3.
This would also be a good choice and probably the one that YH is
suggesting.  If possible, use 2.6.12.3.

> 2. problem could be still with LinuxBIOS stage.

Perhaps, LinuxBIOS is using an incorrect IRQ routing table?

If you have a commercial BIOS, please try that and maybe try
running getpir in the util directory of LinuxBIOS.  Compare
the code it generates with the irq_table.c your LinuBIOS kernel
used when it generated the output appended below.  (The output
of getpir may need to be hand edited to get things just right.)

Hope this helps.

Sincerely,

Ken Fuchs <kfuchs at winternet.com>

------

> On 7/26/05, Huang-Jen Wang <huangjen.wang at gmail.com> wrote:
> > Dear all,
> > My linuxbios tried to boot the linux...but has a 
> problem..hope you can
> > give me some advice...thanks....the message is follow:
> > .....
> > ollect_sys_info: 00000000000c0000-00000
> > pci_init: 01:02.0 1166:0130 0604 00
> > pci_init: 01:03.0 1166:0132 0604 00nt addr 0x1258e0 size 
> 0x48 offset 0
> > pci_init: 01:04.0 1166:0132 0604 00
> > pci_init: 01:05.0 1166:0132 0604 00n PT_LOAD segment
> > pci_init: 01:06.0 1166:0132 0604 000000000000100000 memsz: 
> 0x000000000
> > pci_init: 01:07.0 1166:0036 0604 00
> > pci_init: 01:09.0 1166:0223 0c03 10
> > pci_init: 01:09.1 1166:0223 0c03 10
> > 00000000000048
> > pci_init: 01:09.2 1166:0223 0c03 20
> > FILO
> > pci_init: 02:06.0 1000:0030 0100 00domain) Fri Jul 22 
> 19:47:38 CST 200
> > pci_init: 03:04.0 14e4:1668 0200 00
> > pci_init: 03:04.1 14e4:1668 0200 000xe1fb007
> > pci_init: 08:0d.0 1166:0104 0604 00ebx = 0x1ffe9420
> > Press <Enter> for default boot, or <Esc> for boot prompt... 
> timed out
> > collect_linuxbios_info: Searching for L
> > boot: hda1:/vmlinuz-2.4.20-8 root=/dev/hda2 console=tty0
> > console=ttyS0,115200nd_lb_table: Found canidate at: 00000500
> > collect_linuxbios_info: Found LinuxBIOS tabl
> > find_ide_controller: cmd_base=0x1f0 ctrl_base=0x3f4
> > convert_memmap: 0x000000000000
> > ide_software_reset: Waiting for ide0 to become ready for reset... ok
> > convert_memmap: 0x00000000000de0 0x0000000009f220 1
> > init_drive: Testing for hda
> > convert_memmap
> > init_drive: Probing for hda0030000 1
> > init_drive: LBA mode, sectors=12672450rt_memmap: 
> 0x000000000f0000 0x00000000
> > init_drive: Init device params... ok
> > init_drive: Probing for hdb
> > print_status: IDE: status=0x0, err=0x0
> > Mounted ext2fs
> > Found Linux version 2.4.20-8 
> (bhcompile at stripples.devel.redhat.com) #1 Thu Mar 1
> > 3 17:18:24 EST 2003 bzImage.
> > Loading kernel... ok
> > Jumping to entry point...
> > Linux version 2.4.20-8 
> (bhcompile at stripples.devel.redhat.com) (gcc version 3.2.2
> >  20030222 (Red Hat Linux 3.2.2-5)) #1 Thu Mar 13 17:18:24 EST 2003
> > BIOS-provided physical RAM map:
> >  BIOS-e820: 0000000000000de0 - 00000000000a0000 (usable)
> >  BIOS-e820: 0000000000100000 - 0000000020000000 (usable)
> > 0MB HIGHMEM available.
> > 512MB LOWMEM available.
> > hm, page 00000000 reserved twice.
> > On node 0 totalpages: 131072
> > zone(0): 4096 pages.
> > zone(1): 126976 pages.
> > zone(2): 0 pages.
> > Kernel command line: root=/dev/hda2 console=tty0 
> console=ttyS0,115200
> > Initializing CPU#0
> > Detected 1995.061 MHz processor.
> > Console: colour dummy device 80x25
> > Calibrating delay loop...



From stepan at openbios.org  Wed Jul 27 20:51:21 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Wed, 27 Jul 2005 20:51:21 +0200
Subject: [LinuxBIOS] A boot problem....
In-Reply-To: <Pine.LNX.4.58.0507271029410.9619@enigma.lanl.gov>
References: <4325815c05072618137ccace3d@mail.gmail.com>
	<Pine.LNX.4.58.0507262334540.8194@enigma.lanl.gov>
	<4325815c0507270327474c9ae@mail.gmail.com>
	<Pine.LNX.4.58.0507271029410.9619@enigma.lanl.gov>
Message-ID: <20050727185121.GA13595@openbios.org>

* Ronald G. Minnich <rminnich at lanl.gov> [050727 18:30]:
> On Wed, 27 Jul 2005, Huang-Jen Wang wrote:
> 
> > Ron, 
> > Excuse me , this is my first time porting....do you tell me more detail..
> > like need what information or which file need to modify...
> 
> you're not getting clock IRQ, which is usually IRQ 0. you need to see how 
> your interrupt hardware and/or clock is working to create interrupts.
 
Usually you have to correct your pirq and mptable (or ACPI tables, if
available) (Check the APIC entries in your mptable, as a first try)

Stefan




From rminnich at lanl.gov  Wed Jul 27 21:11:06 2005
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Wed, 27 Jul 2005 13:11:06 -0600 (MDT)
Subject: [LinuxBIOS] Thermal monitoring of Pentium 4s
In-Reply-To: <001601c592d9$32b071f0$6ffea8c0@banana>
References: <001601c592d9$32b071f0$6ffea8c0@banana>
Message-ID: <Pine.LNX.4.58.0507271309430.9619@enigma.lanl.gov>



On Wed, 27 Jul 2005, Steven J. Magnani wrote:

> I have been looking into some thermal shutdown issues with our board,
> and discovered that LinuxBIOS is not enabling the P4's ability to
> throttle back when the internal sensors indicate that the processor is
> getting too hot.

yes, this is purposeful. We let linux do that here. It is a bad deal if 1 
node of 1022 decides to slow down. 

We do this type of thing in Linux. See the LLNL p4therm module for a piece 
of kernel code that can let you talk to the hardware. 

I think Intel's emphasis on having the BIOS do this kind of thing is a 
real mistake.

> It would be relatively easy to implement support for "TM1" thermal
> control, since that's just setting a MSR bit if the proper CPUID flag is
> set. "TM2" control would be a little more complicated, since there is
> the added ability to control the operating frequency and voltage when
> the processor trips into thermal management mode.

It's easy, and the kernel (directed by a user-mode program) should do it.

ron



From steve at digidescorp.com  Wed Jul 27 21:23:46 2005
From: steve at digidescorp.com (Steven J. Magnani)
Date: Wed, 27 Jul 2005 14:23:46 -0500
Subject: [LinuxBIOS] Thermal monitoring of Pentium 4s
In-Reply-To: <Pine.LNX.4.58.0507271309430.9619@enigma.lanl.gov>
Message-ID: <001701c592e0$ba0f9480$6ffea8c0@banana>

Ronald G. Minnich writes:
> the kernel (directed by a user-mode program) should do it.

Ahh, but if the payload is memtest86, there IS no kernel. And that's
where we're having serious shutdown issues.

> See the LLNL p4therm module for a piece of kernel code that can let
you talk to the hardware.

All I can determine from the internet is that this magical piece of
software handles Xeon thermal management. I can't see any links to
source code.

I would argue that since this is a lurking "feature" of LinuxBIOS (you
have to know about it to avoid being bitten, and have to actively do
something in the kernel to avoid thermal issues) that having LB enable
thermal monitoring should be configurable. That would solve both our
issues.

Steve

-----Original Message-----
From: Ronald G. Minnich [mailto:rminnich at lanl.gov] 
Sent: Wednesday, July 27, 2005 1:11 PM
To: Steven J. Magnani
Cc: linuxbios at openbios.org
Subject: Re: [LinuxBIOS] Thermal monitoring of Pentium 4s




On Wed, 27 Jul 2005, Steven J. Magnani wrote:

> I have been looking into some thermal shutdown issues with our board, 
> and discovered that LinuxBIOS is not enabling the P4's ability to 
> throttle back when the internal sensors indicate that the processor is

> getting too hot.

yes, this is purposeful. We let linux do that here. It is a bad deal if
1 
node of 1022 decides to slow down. 

We do this type of thing in Linux. See the LLNL p4therm module for a
piece 
of kernel code that can let you talk to the hardware. 

I think Intel's emphasis on having the BIOS do this kind of thing is a 
real mistake.

> It would be relatively easy to implement support for "TM1" thermal 
> control, since that's just setting a MSR bit if the proper CPUID flag 
> is set. "TM2" control would be a little more complicated, since there 
> is the added ability to control the operating frequency and voltage 
> when the processor trips into thermal management mode.

It's easy, and the kernel (directed by a user-mode program) should do
it.

ron






From rminnich at lanl.gov  Thu Jul 28 01:27:02 2005
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Wed, 27 Jul 2005 17:27:02 -0600 (MDT)
Subject: [LinuxBIOS] Thermal monitoring of Pentium 4s
In-Reply-To: <001701c592e0$ba0f9480$6ffea8c0@banana>
References: <001701c592e0$ba0f9480$6ffea8c0@banana>
Message-ID: <Pine.LNX.4.58.0507271725540.10289@enigma.lanl.gov>



On Wed, 27 Jul 2005, Steven J. Magnani wrote:

> Ronald G. Minnich writes:
> > the kernel (directed by a user-mode program) should do it.
> 
> Ahh, but if the payload is memtest86, there IS no kernel. And that's
> where we're having serious shutdown issues.

ah, ok. 

> I would argue that since this is a lurking "feature" of LinuxBIOS (you
> have to know about it to avoid being bitten, and have to actively do
> something in the kernel to avoid thermal issues) that having LB enable
> thermal monitoring should be configurable. That would solve both our
> issues.

you are right. We'll need to set up an enable method for the p4 cpu 
resource, and then allow you to set "registers" commands to turn on t1, 
etc. 

Um, volunteers :-)

ron



From huangjen.wang at gmail.com  Thu Jul 28 05:36:19 2005
From: huangjen.wang at gmail.com (Huang-Jen Wang)
Date: Thu, 28 Jul 2005 11:36:19 +0800
Subject: [LinuxBIOS] A boot problem....
In-Reply-To: <20050727185121.GA13595@openbios.org>
References: <4325815c05072618137ccace3d@mail.gmail.com>
	<Pine.LNX.4.58.0507262334540.8194@enigma.lanl.gov>
	<4325815c0507270327474c9ae@mail.gmail.com>
	<Pine.LNX.4.58.0507271029410.9619@enigma.lanl.gov>
	<20050727185121.GA13595@openbios.org>
Message-ID: <4325815c05072720367810b826@mail.gmail.com>

Thanks for your advice , I will make a try ....

On 7/28/05, Stefan Reinauer <stepan at openbios.org> wrote:
> * Ronald G. Minnich <rminnich at lanl.gov> [050727 18:30]:
> > On Wed, 27 Jul 2005, Huang-Jen Wang wrote:
> >
> > > Ron,
> > > Excuse me , this is my first time porting....do you tell me more detail..
> > > like need what information or which file need to modify...
> >
> > you're not getting clock IRQ, which is usually IRQ 0. you need to see how
> > your interrupt hardware and/or clock is working to create interrupts.
> 
> Usually you have to correct your pirq and mptable (or ACPI tables, if
> available) (Check the APIC entries in your mptable, as a first try)
> 
> Stefan
> 
>



From justin at street-vision.com  Thu Jul 28 20:04:29 2005
From: justin at street-vision.com (Justin Cormack)
Date: 28 Jul 2005 18:04:29 +0000
Subject: [LinuxBIOS] AMD board support
Message-ID: <1122573869.13409.10.camel@scrod>


What has to be done to port to a new AMD board now? Its Nforce 4. Havent
used linuxbios for a while as had to use Intel boards.

Its Tyan S2865 http://www.tyan.com/products/html/tomcatk8e.html

lspci is
00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller
(rev a3)
00:01.0 ISA bridge: nVidia Corporation: Unknown device 0050 (rev a3)
00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2)
00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2)
00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3)
00:04.0 Multimedia audio controller: nVidia Corporation CK804 AC'97
Audio Controller (rev a2)
00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev a2)
00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller
(rev a3)
00:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller
(rev a3)
00:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev a2)
00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3)
00:0b.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
00:0c.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
00:0d.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
00:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
Miscellaneous Control
01:05.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27)
01:06.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host
Controller (rev 80)
04:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5721
Gigabit Ethernet PCI Express (rev 11)





From kfuchs at winternet.com  Thu Jul 28 18:50:20 2005
From: kfuchs at winternet.com (Ken Fuchs)
Date: Thu, 28 Jul 2005 11:50:20 -0500 (CDT)
Subject: [LinuxBIOS] A boot problem....
Message-ID: <200507281650.j6SGoK59007691@tundra.winternet.com>

> > On Wed, 27 Jul 2005, Huang-Jen Wang wrote:

> > > Excuse me , this is my first time porting....do you tell me more
> > > detail..
> > > like need what information or which file need to modify...

> * Ronald G. Minnich <rminnich at lanl.gov> [050727 18:30]:

> > you're not getting clock IRQ, which is usually IRQ 0. you need to
> > see how your interrupt hardware and/or clock is working to create
> > interrupts.

On 7/28/05, Stefan Reinauer <stepan at openbios.org> wrote:

> Usually you have to correct your pirq and mptable (or ACPI tables, if
> available) (Check the APIC entries in your mptable, as a first try)

In my previous post, I mentioned a good way to proceed is booting from
the commercial BIOS and running LB util/getpir to view the PIRQ table
and compare it to the irq_table.c of the LinuxBIOS being booted.

To check the MP table, boot the COTS BIOS & Linux and run LinuxBIOS
util/mptable which will generate an mptable.c file on stdout.  Compare
this code to the actual mptable.c code in the LinuxBIOS that caused
the boot problem.  (The code that util/mptable generates must be hand
edited to work under LinuxBIOS v2, so some differences should exist.)

Please note that some people consider running either util/getpir or
util/mptable to be a waste of time.  (I agree; Maybe these utilities
could be fixed so they would be more useful on LinuxBIOS v2.)

Hope this helps.

Sincerely,

Ken Fuchs <kfuchs at winternet.com>



From yinghailu at gmail.com  Thu Jul 28 19:43:54 2005
From: yinghailu at gmail.com (yhlu)
Date: Thu, 28 Jul 2005 10:43:54 -0700
Subject: [LinuxBIOS] AMD board support
In-Reply-To: <1122573869.13409.10.camel@scrod>
References: <1122573869.13409.10.camel@scrod>
Message-ID: <2ea3fae1050728104365b12269@mail.gmail.com>

S2865 support athlon64 instead of Opteron.

athlon64 doesn't support ECC.

I have tried to comment out lines in raminit.c and could boot the
system with LinuxBIOS.

the problem are
1. it only supports one DIMM ...?
2. Etherboot support 5721 may still have problem, Tim already put sth
to support 5721 in Etherboot but have no time to verify that.

YH

On 28 Jul 2005 18:04:29 +0000, Justin Cormack <justin at street-vision.com> wrote:
> 
> What has to be done to port to a new AMD board now? Its Nforce 4. Havent
> used linuxbios for a while as had to use Intel boards.
> 
> Its Tyan S2865 http://www.tyan.com/products/html/tomcatk8e.html
> 
> lspci is
> 00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller
> (rev a3)
> 00:01.0 ISA bridge: nVidia Corporation: Unknown device 0050 (rev a3)
> 00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2)
> 00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2)
> 00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3)
> 00:04.0 Multimedia audio controller: nVidia Corporation CK804 AC'97
> Audio Controller (rev a2)
> 00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev a2)
> 00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller
> (rev a3)
> 00:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller
> (rev a3)
> 00:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev a2)
> 00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3)
> 00:0b.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
> 00:0c.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
> 00:0d.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
> 00:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
> 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
> HyperTransport Technology Configuration
> 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
> Address Map
> 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
> DRAM Controller
> 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
> Miscellaneous Control
> 01:05.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27)
> 01:06.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host
> Controller (rev 80)
> 04:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5721
> Gigabit Ethernet PCI Express (rev 11)
> 
> 
> 
> _______________________________________________
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>



From rminnich at lanl.gov  Thu Jul 28 22:09:50 2005
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Thu, 28 Jul 2005 14:09:50 -0600 (MDT)
Subject: [LinuxBIOS] A boot problem....
In-Reply-To: <200507281650.j6SGoK59007691@tundra.winternet.com>
References: <200507281650.j6SGoK59007691@tundra.winternet.com>
Message-ID: <Pine.LNX.4.58.0507281409430.12404@enigma.lanl.gov>



On Thu, 28 Jul 2005, Ken Fuchs wrote:

> Please note that some people consider running either util/getpir or
> util/mptable to be a waste of time.  (I agree; Maybe these utilities
> could be fixed so they would be more useful on LinuxBIOS v2.)

??

ron



From kfuchs at winternet.com  Thu Jul 28 22:53:02 2005
From: kfuchs at winternet.com (Ken Fuchs)
Date: Thu, 28 Jul 2005 15:53:02 -0500 (CDT)
Subject: [LinuxBIOS] util/getpir & util/mptable [Was "A boot problem...."]
Message-ID: <200507282053.j6SKr2Kt008798@tundra.winternet.com>

> On Thu, 28 Jul 2005, Ken Fuchs wrote:

> > Please note that some people consider running either util/getpir or
> > util/mptable to be a waste of time.  (I agree; Maybe these utilities
> > could be fixed so they would be more useful on LinuxBIOS v2.)

Ron Minnich wrote:

> ??

Sorry, I worded the above paragraph far too strongly.  I meant to say
that booting a COTS BIOS & Linux and running util/getpir and
util/mptable can be very useful in LinuxBIOS v2, but hand editing the
results may be required.  It would be nice, if util/getpir and
util/mptable could be modified so hand editing the resultant
irq_table.c and mptable.c would not be needed.  This may not be very
useful for experienced LinuxBIOS developers, but can save a lot of
porting time for people who don't have as much LinuxBIOS or other BIOS
experience.

Sincerely,

Ken Fuchs <kfuchs at winternet.com>



From rminnich at lanl.gov  Thu Jul 28 22:59:26 2005
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Thu, 28 Jul 2005 14:59:26 -0600 (MDT)
Subject: [LinuxBIOS] util/getpir & util/mptable [Was "A boot problem...."]
In-Reply-To: <200507282053.j6SKr2Kt008798@tundra.winternet.com>
References: <200507282053.j6SKr2Kt008798@tundra.winternet.com>
Message-ID: <Pine.LNX.4.58.0507281459060.12404@enigma.lanl.gov>



On Thu, 28 Jul 2005, Ken Fuchs wrote:

> Sorry, I worded the above paragraph far too strongly.  I meant to say
> that booting a COTS BIOS & Linux and running util/getpir and
> util/mptable can be very useful in LinuxBIOS v2, but hand editing the
> results may be required.  It would be nice, if util/getpir and
> util/mptable could be modified so hand editing the resultant irq_table.c
> and mptable.c would not be needed.  This may not be very useful for
> experienced LinuxBIOS developers, but can save a lot of porting time for
> people who don't have as much LinuxBIOS or other BIOS experience.

ah! tell me how it needs to change. I just used getpir recently and did no 
hand editing.

ron



From kfuchs at winternet.com  Thu Jul 28 23:04:27 2005
From: kfuchs at winternet.com (Ken Fuchs)
Date: Thu, 28 Jul 2005 16:04:27 -0500 (CDT)
Subject: [LinuxBIOS] Potential copyright issues with decompiling ACPI tables?
Message-ID: <200507282104.j6SL4RC7008842@tundra.winternet.com>

I haven't spend much time working with ACPI tables, but there may be
copyright issues with decompiling these on a COTS BIOS and using the
result in LinuxBIOS.  Does anyone agree there may be a copyright
concern here?  I don't think there is, but I'm not a copyright lawyer.

Sincerely,

Ken Fuchs <kfuchs at winternet.com>



From yinghailu at gmail.com  Thu Jul 28 23:13:57 2005
From: yinghailu at gmail.com (yhlu)
Date: Thu, 28 Jul 2005 14:13:57 -0700
Subject: [LinuxBIOS] util/getpir & util/mptable [Was "A boot problem...."]
In-Reply-To: <Pine.LNX.4.58.0507281459060.12404@enigma.lanl.gov>
References: <200507282053.j6SKr2Kt008798@tundra.winternet.com>
	<Pine.LNX.4.58.0507281459060.12404@enigma.lanl.gov>
Message-ID: <2ea3fae105072814135e75b162@mail.gmail.com>

If there are several peer root bus, the irq_table.c must be modified maually.

Please refer to src/mainboard/tyan/s2895/irq_table.c

YH

On 7/28/05, Ronald G. Minnich <rminnich at lanl.gov> wrote:
> 
> 
> On Thu, 28 Jul 2005, Ken Fuchs wrote:
> 
> > Sorry, I worded the above paragraph far too strongly.  I meant to say
> > that booting a COTS BIOS & Linux and running util/getpir and
> > util/mptable can be very useful in LinuxBIOS v2, but hand editing the
> > results may be required.  It would be nice, if util/getpir and
> > util/mptable could be modified so hand editing the resultant irq_table.c
> > and mptable.c would not be needed.  This may not be very useful for
> > experienced LinuxBIOS developers, but can save a lot of porting time for
> > people who don't have as much LinuxBIOS or other BIOS experience.
> 
> ah! tell me how it needs to change. I just used getpir recently and did no
> hand editing.
> 
> ron
> 
> _______________________________________________
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>



From rminnich at lanl.gov  Thu Jul 28 23:23:47 2005
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Thu, 28 Jul 2005 15:23:47 -0600 (MDT)
Subject: [LinuxBIOS] Potential copyright issues with decompiling ACPI
	tables?
In-Reply-To: <200507282104.j6SL4RC7008842@tundra.winternet.com>
References: <200507282104.j6SL4RC7008842@tundra.winternet.com>
Message-ID: <Pine.LNX.4.58.0507281522540.12404@enigma.lanl.gov>



On Thu, 28 Jul 2005, Ken Fuchs wrote:

> I haven't spend much time working with ACPI tables, but there may be
> copyright issues with decompiling these on a COTS BIOS and using the
> result in LinuxBIOS.  Does anyone agree there may be a copyright
> concern here?  I don't think there is, but I'm not a copyright lawyer.

that's a good question. we don't know. On the one hand, ACPI describes 
hardware, and the OSes read it all the time. Seems like public info. 

OTOH, there's a copyright notice in there. 

I don't know the answer.

ron



From josiah at lanl.gov  Thu Jul 28 23:29:54 2005
From: josiah at lanl.gov (Josiah England)
Date: Thu, 28 Jul 2005 15:29:54 -0600
Subject: [LinuxBIOS] Potential copyright issues with decompiling ACPI
	tables?
In-Reply-To: <Pine.LNX.4.58.0507281522540.12404@enigma.lanl.gov>
References: <200507282104.j6SL4RC7008842@tundra.winternet.com>
	<Pine.LNX.4.58.0507281522540.12404@enigma.lanl.gov>
Message-ID: <1122586194.8576.23.camel@plipper.ccstar>

On Thu, 2005-07-28 at 15:23 -0600, Ronald G. Minnich wrote:
> 
> On Thu, 28 Jul 2005, Ken Fuchs wrote:
> 
> > I haven't spend much time working with ACPI tables, but there may be
> > copyright issues with decompiling these on a COTS BIOS and using the
> > result in LinuxBIOS.  Does anyone agree there may be a copyright
> > concern here?  I don't think there is, but I'm not a copyright lawyer.
> 
> that's a good question. we don't know. On the one hand, ACPI describes 
> hardware, and the OSes read it all the time. Seems like public info. 
> 
> OTOH, there's a copyright notice in there. 
> 
> I don't know the answer.
> 
> ron
> 
> _______________________________________________
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios

Since there's a copyright notice in it, we would be safer off by
duplicating that copyright notice if at all possible and putting it in
our code.
Since there is no (direct) financial gain from us not selling the
software, there is little chance of repercussions.

Josiah




From rminnich at lanl.gov  Thu Jul 28 23:35:06 2005
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Thu, 28 Jul 2005 15:35:06 -0600 (MDT)
Subject: [LinuxBIOS] Potential copyright issues with decompiling ACPI
	tables?
In-Reply-To: <1122586194.8576.23.camel@plipper.ccstar>
References: <200507282104.j6SL4RC7008842@tundra.winternet.com> 
	<Pine.LNX.4.58.0507281522540.12404@enigma.lanl.gov>
	<1122586194.8576.23.camel@plipper.ccstar>
Message-ID: <Pine.LNX.4.58.0507281534490.12404@enigma.lanl.gov>



On Thu, 28 Jul 2005, Josiah England wrote:

> Since there is no (direct) financial gain from us not selling the
> software, there is little chance of repercussions.

I don't think that will work, 
All Rights Reserved

ron



From russ at ashlandhome.net  Fri Jul 29 00:59:26 2005
From: russ at ashlandhome.net (Russell Whitaker)
Date: Thu, 28 Jul 2005 15:59:26 -0700 (PDT)
Subject: [LinuxBIOS] Potential copyright issues with decompiling ACPI
	tables?
In-Reply-To: <Pine.LNX.4.58.0507281534490.12404@enigma.lanl.gov>
References: <200507282104.j6SL4RC7008842@tundra.winternet.com> 
	<Pine.LNX.4.58.0507281522540.12404@enigma.lanl.gov>
	<1122586194.8576.23.camel@plipper.ccstar>
	<Pine.LNX.4.58.0507281534490.12404@enigma.lanl.gov>
Message-ID: <Pine.LNX.4.62.0507281543001.3066@bigred.russwhit.org>



On Thu, 28 Jul 2005, Ronald G. Minnich wrote:

>
>
> On Thu, 28 Jul 2005, Josiah England wrote:
>
>> Since there is no (direct) financial gain from us not selling the
>> software, there is little chance of repercussions.
>
> I don't think that will work,
> All Rights Reserved

Try google using the words "copyright fair use"

While you might be able to claim "fair use" the safest way is to
get permission from the copyright holder.

   Russ



From rminnich at lanl.gov  Fri Jul 29 01:26:45 2005
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Thu, 28 Jul 2005 17:26:45 -0600 (MDT)
Subject: [LinuxBIOS] Potential copyright issues with decompiling ACPI
	tables?
In-Reply-To: <Pine.LNX.4.62.0507281543001.3066@bigred.russwhit.org>
References: <200507282104.j6SL4RC7008842@tundra.winternet.com> 
	<Pine.LNX.4.58.0507281522540.12404@enigma.lanl.gov>
	<1122586194.8576.23.camel@plipper.ccstar>
	<Pine.LNX.4.58.0507281534490.12404@enigma.lanl.gov>
	<Pine.LNX.4.62.0507281543001.3066@bigred.russwhit.org>
Message-ID: <Pine.LNX.4.58.0507281726210.12404@enigma.lanl.gov>



On Thu, 28 Jul 2005, Russell Whitaker wrote:

> While you might be able to claim "fair use" the safest way is to
> get permission from the copyright holder.

yeah, I doubt that putting a copyright item in the linuxbios tree on an 
svn server would qualify for fair use.

ron



From justin at street-vision.com  Fri Jul 29 01:42:15 2005
From: justin at street-vision.com (Justin Cormack)
Date: Fri, 29 Jul 2005 00:42:15 +0100
Subject: [LinuxBIOS] AMD board support
In-Reply-To: <2ea3fae1050728104365b12269@mail.gmail.com>
References: <1122573869.13409.10.camel@scrod>
	<2ea3fae1050728104365b12269@mail.gmail.com>
Message-ID: <0E7A59F5-0496-4CDE-B638-F2E4EDBE53B7@street-vision.com>


On 28 Jul 2005, at 18:43, yhlu wrote:

> S2865 support athlon64 instead of Opteron.
>
> athlon64 doesn't support ECC.
>
> I have tried to comment out lines in raminit.c and could boot the
> system with LinuxBIOS.
>
> the problem are
> 1. it only supports one DIMM ...?
> 2. Etherboot support 5721 may still have problem, Tim already put sth
> to support 5721 in Etherboot but have no time to verify that.

http://www.tyan.com/support/html/memory_s2865.html

It supports ECC. It seems to me that S394 and S340 are pretty much   
the same.

I have it running with ECC RAM now (as far as I remember - I am at  
home now)

It is dual channel with 4 DIMM sockets.

It doesnt support buufered RAM but does support ECC (not sure why...)




From stepan at openbios.org  Fri Jul 29 10:57:17 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Fri, 29 Jul 2005 10:57:17 +0200
Subject: [LinuxBIOS] util/getpir & util/mptable [Was "A boot problem...."]
In-Reply-To: <2ea3fae105072814135e75b162@mail.gmail.com>
References: <200507282053.j6SKr2Kt008798@tundra.winternet.com>
	<Pine.LNX.4.58.0507281459060.12404@enigma.lanl.gov>
	<2ea3fae105072814135e75b162@mail.gmail.com>
Message-ID: <20050729085717.GC14972@openbios.org>

* yhlu <yinghailu at gmail.com> [050728 23:13]:
> If there are several peer root bus, the irq_table.c must be modified maually.
> 
> Please refer to src/mainboard/tyan/s2895/irq_table.c

Also, on AMD K8 CPUs it needs to be modified due to the difference in
breadth-first vs depth-first bus enumeration, resulting in different bus
numbers.

Stefan





From marko.makela at hut.fi  Fri Jul 29 11:08:01 2005
From: marko.makela at hut.fi (Marko =?iso-8859-1?B?TeRrZWzk?=)
Date: Fri, 29 Jul 2005 12:08:01 +0300
Subject: [LinuxBIOS] Is the MSI 694T Pro MS-6309 (v5.0) ATX mainboard
	supported?
Message-ID: <20050729090801.GG3339@localhost.localdomain>

Hi all,

I have built a personal video recorder using VDR and vdr-softdevice
plugin on a MSI 694T mainboard running a 900 MHz Celeron.  I would
like to speed up the boot process: the BIOS needs over 10 seconds
before starting LILO.

I need the following features:

- ATX wakeup timer
  - nvram-wakeup needs a reboot for the changes to take effect
- wake-on-LAN (for starting the computer by the remote control unit
  bundled with the DVB-T tuner card; see my hardware hack at
  http://www.iki.fi/~msmakela/electronics/worc5/)
- PCI, AGP and IDE (USB is not needed)

Here's the lspci output:

0000:00:00.0 Host bridge: VIA Technologies, Inc. VT82C693A/694x
[Apollo PRO133x] (rev c4)
0000:00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598/694x
[Apollo MVP3/Pro133x AGP]
0000:00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686
[Apollo Super South] (rev 40)
0000:00:07.1 IDE interface: VIA Technologies, Inc.
VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
0000:00:07.2 USB Controller: VIA Technologies, Inc. VT82xxxxx
UHCI USB 1.1 Controller (rev 1a)
0000:00:07.3 USB Controller: VIA Technologies, Inc. VT82xxxxx
UHCI USB 1.1 Controller (rev 1a)
0000:00:07.4 Bridge: VIA Technologies, Inc. VT82C686
[Apollo Super ACPI] (rev 40)
0000:00:07.5 Multimedia audio controller: VIA Technologies, Inc.
VT82C686 AC97 Audio Controller (rev 50)
0000:00:0e.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M
[Tornado] (rev 74)
0000:00:10.0 Multimedia video controller: Conexant Winfast TV2000 XP (rev 05)
0000:00:10.2 Multimedia controller: Conexant: Unknown device 8802 (rev 05)
0000:00:10.4 Multimedia controller: Conexant: Unknown device 8804 (rev 05)
0000:01:00.0 VGA compatible controller: Matrox Graphics, Inc.
MGA G400 AGP (rev 82)

The superio chip is a VIA 686, identified by Linux as

VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on pci0000:00:07.1
    ide0: BM-DMA at 0xff00-0xff07, BIOS settings: hda:DMA, hdb:DMA
    ide1: BM-DMA at 0xff08-0xff0f, BIOS settings: hdc:DMA, hdd:pio

and

ALSA device list:
  #0: VIA 82C686A/B rev50 with ICE1232 at 0xdc00, irq 18

The markings on the chip are VIA VT82C686B 0130CD TAIWAN 13C002600.

The south bridge (next to the processor, I hope this is the correct
terminology) is a VIA VT82C694T 0130CD TAIWAN 2IB0004361.

The BIOS device is a PLCC chip with 9 pins on the long side and 7 pins
on the short side.  I can peel off the AMIBIOS label if needed.

Here is some more information on this motherboard:

http://www.msicomputer.com/product/detail_spec/694T_Pro.htm
http://www.mainboard.cz/mb/msi/694TPRO.htm

If you need any more information, please let me know.

	Marko



From paul at astro.gla.ac.uk  Fri Jul 29 13:11:20 2005
From: paul at astro.gla.ac.uk (Paul Millar)
Date: Fri, 29 Jul 2005 12:11:20 +0100
Subject: Fwd: Re: [LinuxBIOS] Potential copyright issues with decompiling ACPI
	tables?
Message-ID: <200507291211.26147.paul@astro.gla.ac.uk>

I guess we can all claim that IANAL, but I've seen similar arguments with
 wine that might be useful.

Reading the copyright section on wikipedia:
  http://en.wikipedia.org/wiki/Copyright
there's a mention of the "idea-expression dichotomy".  From wikipedia:

"a copyright covers the expression of an idea, not the idea itself [...]"

For this reason, simple header files (*.h) are normally not considered
copyrightable.  See, for example:
  http://www.kerneltraffic.org/wine/wn20010219_83.html
which links to the Sega case:
  http://www.eff.org/pub/Legal/Cases/sega_v_accolade_977f2d1510_decision.html

If the copyright notice is in the BIOS binary, it applies to that
instantiation of the code.  Simply copying the ACPI tables verbatim may be
legal (c.f. Sega case summary above about "purely functional" code), but
parsing the in-memory tables and writing them out to disk (which is what's
happening here, right?) is legal.

(IMHO, IANAL, ...)

Cheers,

Paul.

On Thursday 28 Jul 2005 22:23, Ronald G. Minnich wrote:
> On Thu, 28 Jul 2005, Ken Fuchs wrote:
> > I haven't spend much time working with ACPI tables, but there may be
> > copyright issues with decompiling these on a COTS BIOS and using the
> > result in LinuxBIOS.  Does anyone agree there may be a copyright
> > concern here?  I don't think there is, but I'm not a copyright lawyer.
>
> that's a good question. we don't know. On the one hand, ACPI describes
> hardware, and the OSes read it all the time. Seems like public info.
>
> OTOH, there's a copyright notice in there.
>
> I don't know the answer.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20050729/b3c2fee5/attachment.sig>

From rminnich at lanl.gov  Fri Jul 29 16:46:29 2005
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Fri, 29 Jul 2005 08:46:29 -0600 (MDT)
Subject: [LinuxBIOS] util/getpir & util/mptable [Was "A boot problem...."]
In-Reply-To: <20050729085717.GC14972@openbios.org>
References: <200507282053.j6SKr2Kt008798@tundra.winternet.com>
	<Pine.LNX.4.58.0507281459060.12404@enigma.lanl.gov>
	<2ea3fae105072814135e75b162@mail.gmail.com>
	<20050729085717.GC14972@openbios.org>
Message-ID: <Pine.LNX.4.58.0507290846170.15329@enigma.lanl.gov>



On Fri, 29 Jul 2005, Stefan Reinauer wrote:

> Also, on AMD K8 CPUs it needs to be modified due to the difference in
> breadth-first vs depth-first bus enumeration, resulting in different bus
> numbers.

ah, somebody fix it please :-)

ron



From rminnich at lanl.gov  Fri Jul 29 16:47:16 2005
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Fri, 29 Jul 2005 08:47:16 -0600 (MDT)
Subject: [LinuxBIOS] Is the MSI 694T Pro MS-6309 (v5.0) ATX mainboard
	supported?
In-Reply-To: <20050729090801.GG3339@localhost.localdomain>
References: <20050729090801.GG3339@localhost.localdomain>
Message-ID: <Pine.LNX.4.58.0507290846590.15329@enigma.lanl.gov>

wow, that's an old bridge! I think it is very similar to 8601, so it might 
be made to work.

ron




From yinghailu at gmail.com  Fri Jul 29 18:24:30 2005
From: yinghailu at gmail.com (yhlu)
Date: Fri, 29 Jul 2005 09:24:30 -0700
Subject: [LinuxBIOS] util/getpir & util/mptable [Was "A boot problem...."]
In-Reply-To: <Pine.LNX.4.58.0507290846170.15329@enigma.lanl.gov>
References: <200507282053.j6SKr2Kt008798@tundra.winternet.com>
	<Pine.LNX.4.58.0507281459060.12404@enigma.lanl.gov>
	<2ea3fae105072814135e75b162@mail.gmail.com>
	<20050729085717.GC14972@openbios.org>
	<Pine.LNX.4.58.0507290846170.15329@enigma.lanl.gov>
Message-ID: <2ea3fae1050729092411abce5f@mail.gmail.com>

No, the irq table can be produced dynmaically as mptable.c

the developer must change irqtable.c mptable.c manually to make it dynamically.

YH

On 7/29/05, Ronald G. Minnich <rminnich at lanl.gov> wrote:
> 
> 
> On Fri, 29 Jul 2005, Stefan Reinauer wrote:
> 
> > Also, on AMD K8 CPUs it needs to be modified due to the difference in
> > breadth-first vs depth-first bus enumeration, resulting in different bus
> > numbers.
> 
> ah, somebody fix it please :-)
> 
> ron
>



From marko.makela at hut.fi  Fri Jul 29 19:38:40 2005
From: marko.makela at hut.fi (Marko =?iso-8859-1?B?TeRrZWzk?=)
Date: Fri, 29 Jul 2005 20:38:40 +0300
Subject: [LinuxBIOS] Is the MSI 694T Pro MS-6309 (v5.0) ATX mainboard
	supported?
In-Reply-To: <Pine.LNX.4.58.0507290846590.15329@enigma.lanl.gov>
References: <20050729090801.GG3339@localhost.localdomain>
	<Pine.LNX.4.58.0507290846590.15329@enigma.lanl.gov>
Message-ID: <20050729173840.GA3381@localhost.localdomain>

On Fri, Jul 29, 2005 at 08:47:16AM -0600, Ronald G. Minnich wrote:
> wow, that's an old bridge! I think it is very similar to 8601, so it might 
> be made to work.

Well, based on some further Googling, I don't have high hopes on the
availability or quality of VIA documentation.

I guess I'll have to acquire a spare flash chip, so that my "production"
system won't become unusable.

What would you advise as the next step?  Or should I try to get an
Intel-based system instead?  I might get an Asus P2B 99 (sp?) board
that has a 900 MHz Slot 1 Pentium III processor.

With best regards,

	Marko M?kel?



From rminnich at lanl.gov  Fri Jul 29 19:52:36 2005
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Fri, 29 Jul 2005 11:52:36 -0600 (MDT)
Subject: [LinuxBIOS] Is the MSI 694T Pro MS-6309 (v5.0) ATX mainboard
	supported?
In-Reply-To: <20050729173840.GA3381@localhost.localdomain>
References: <20050729090801.GG3339@localhost.localdomain>
	<Pine.LNX.4.58.0507290846590.15329@enigma.lanl.gov>
	<20050729173840.GA3381@localhost.localdomain>
Message-ID: <Pine.LNX.4.58.0507291152290.15596@enigma.lanl.gov>

look for chips you know we support, is your best bet.

ron




From Stephen.Kimball at bench.com  Fri Jul 29 22:23:36 2005
From: Stephen.Kimball at bench.com (Stephen.Kimball at bench.com)
Date: Fri, 29 Jul 2005 16:23:36 -0400
Subject: [LinuxBIOS] util/getpir & util/mptable [Was "A boot problem...."]
Message-ID: <30ADB28314F8B744AB478FB5EDA044B30D3C05@nh-ex01.bench.com>

I think the words "make it dynamically" could be causing some confusion.
I suspect YH doesn't mean you could run a getpir or mptable utility on
Linux and get a good IRQ or MP table.  I think YH means the mptable.c
file will programtically build the mptable by looking for secondary
busses.

My experience has been that running utilities on Linux booted with a
commercial BIOS does no good at all, because most BIOS's use ACPI
tables.
When ACPI tables are used, the get_pir utility will return an empty IRQ
table, because all the IRQ table stuff is in the ACPI tables.  You may
be able to dump an mptable but it may also rely on ACPI stuff.  So the
best way to do it is manually like YH says.  The IRQ table just needs
the peer bus information and the MP table needs to match the bus
configuration.

Steve

-----Original Message-----
From: linuxbios-bounces at openbios.org
[mailto:linuxbios-bounces at openbios.org] On Behalf Of yhlu
Sent: Friday, July 29, 2005 12:25 PM
To: Ronald G. Minnich
Cc: Ken Fuchs; LinuxBIOS at openbios.org
Subject: Re: [LinuxBIOS] util/getpir & util/mptable [Was "A boot
problem...."]

No, the irq table can be produced dynmaically as mptable.c

the developer must change irqtable.c mptable.c manually to make it
dynamically.

YH

On 7/29/05, Ronald G. Minnich <rminnich at lanl.gov> wrote:
> 
> 
> On Fri, 29 Jul 2005, Stefan Reinauer wrote:
> 
> > Also, on AMD K8 CPUs it needs to be modified due to the difference
in
> > breadth-first vs depth-first bus enumeration, resulting in different
bus
> > numbers.
> 
> ah, somebody fix it please :-)
> 
> ron
>

_______________________________________________
LinuxBIOS mailing list
LinuxBIOS at openbios.org
http://www.openbios.org/mailman/listinfo/linuxbios



From rminnich at lanl.gov  Fri Jul 29 22:28:39 2005
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Fri, 29 Jul 2005 14:28:39 -0600 (MDT)
Subject: [LinuxBIOS] util/getpir & util/mptable [Was "A boot problem...."]
In-Reply-To: <30ADB28314F8B744AB478FB5EDA044B30D3C05@nh-ex01.bench.com>
References: <30ADB28314F8B744AB478FB5EDA044B30D3C05@nh-ex01.bench.com>
Message-ID: <Pine.LNX.4.58.0507291427510.15596@enigma.lanl.gov>



On Fri, 29 Jul 2005 Stephen.Kimball at bench.com wrote:

> My experience has been that running utilities on Linux booted with a
> commercial BIOS does no good at all, because most BIOS's use ACPI
> tables.

umm, depends. I see a lot of variation. I do agree that for many new 
platforms for desktops and laptops, this is true. 


ron



From dbell at nxtv.com  Sat Jul 30 00:04:33 2005
From: dbell at nxtv.com (Doug Bell)
Date: Fri, 29 Jul 2005 15:04:33 -0700
Subject: [LinuxBIOS] Re: EPIA-M status
Message-ID: <42EAA7F1.1080906@nxtv.com>

I'm new to LinuxBIOS.
I seem to have problems out of the box (code from this week):

./buildtarget via/epia-m
build_dir=via/epia-m/epia-m
Trying to find one of TARGET on line 4:
 >  loadoptions
 >  ^
List of nearby tokens:
===> ERROR: Could not parse file
via/epia-m/Config.lb:0

Suggestions?

Thanks, dB




From rminnich at lanl.gov  Sat Jul 30 00:18:05 2005
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Fri, 29 Jul 2005 16:18:05 -0600 (MDT)
Subject: [LinuxBIOS] Re: EPIA-M status
In-Reply-To: <42EAA7F1.1080906@nxtv.com>
References: <42EAA7F1.1080906@nxtv.com>
Message-ID: <Pine.LNX.4.58.0507291617570.15596@enigma.lanl.gov>

HMM> 

Is this from svn?

ron




From rminnich at lanl.gov  Sat Jul 30 01:14:32 2005
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Fri, 29 Jul 2005 17:14:32 -0600 (MDT)
Subject: [LinuxBIOS] Re: EPIA-M status
In-Reply-To: <1122675650.28259.0.camel@Doug>
References: <42EAA7F1.1080906@nxtv.com>
	<Pine.LNX.4.58.0507291617570.15596@enigma.lanl.gov>
	<1122675650.28259.0.camel@Doug>
Message-ID: <Pine.LNX.4.58.0507291714040.15596@enigma.lanl.gov>



On Fri, 29 Jul 2005, Doug Bell wrote:

> yes, I did svn co ....

I just realized ... epia-m is still not a working target!

I thought someone got it close, but I have not looked lately.

ron



From noodles at earth.li  Sat Jul 30 01:16:31 2005
From: noodles at earth.li (Jonathan McDowell)
Date: Sat, 30 Jul 2005 00:16:31 +0100
Subject: [LinuxBIOS] Re: EPIA-M status
In-Reply-To: <42EAA7F1.1080906@nxtv.com>
References: <42EAA7F1.1080906@nxtv.com>
Message-ID: <20050729231631.GA12895@earth.li>

On Fri, Jul 29, 2005 at 03:04:33PM -0700, Doug Bell wrote:
> I'm new to LinuxBIOS.
> I seem to have problems out of the box (code from this week):
> 
> ./buildtarget via/epia-m
> build_dir=via/epia-m/epia-m
> Trying to find one of TARGET on line 4:
> >  loadoptions
> >  ^
> List of nearby tokens:
> ===> ERROR: Could not parse file
> via/epia-m/Config.lb:0
> 
> Suggestions?

I haven't got round to porting my semi-working EPIA-M support to the SVN
tree. If you search the list archives you should find the details of my
arch tree however, which has some more luck. I simply haven't had the
time to look at it since the move to SVN, but hopefully next week.

J.

-- 
noodles is criminal



From lindahl at pathscale.com  Sun Jul 31 03:46:47 2005
From: lindahl at pathscale.com (Greg Lindahl)
Date: Sat, 30 Jul 2005 18:46:47 -0700
Subject: [LinuxBIOS] Potential copyright issues with decompiling ACPI
	tables?
In-Reply-To: <1122586194.8576.23.camel@plipper.ccstar>
References: <200507282104.j6SL4RC7008842@tundra.winternet.com>
	<Pine.LNX.4.58.0507281522540.12404@enigma.lanl.gov>
	<1122586194.8576.23.camel@plipper.ccstar>
Message-ID: <20050731014647.GB1777@greglaptop.hsd1.ca.comcast.net>

On Thu, Jul 28, 2005 at 03:29:54PM -0600, Josiah England wrote:

> Since there is no (direct) financial gain from us not selling the
> software, there is little chance of repercussions.

It is commonly believed that non-commercial use of copyrighted
material is safer, but this isn't true. You're still liable for $$
penalties.

Facts can't be copyrighted. But it's not easy to use that to convince
someone to stop labeling a fact as being copyrighted.

-- greg





From janek_listy at wp.pl  Sun Jul 31 09:46:23 2005
From: janek_listy at wp.pl (Janek Kozicki)
Date: Sun, 31 Jul 2005 09:46:23 +0200
Subject: [LinuxBIOS] Potential copyright issues with decompiling ACPI
	tables?
In-Reply-To: <20050731014647.GB1777@greglaptop.hsd1.ca.comcast.net>
References: <200507282104.j6SL4RC7008842@tundra.winternet.com>
	<Pine.LNX.4.58.0507281522540.12404@enigma.lanl.gov>
	<1122586194.8576.23.camel@plipper.ccstar>
	<20050731014647.GB1777@greglaptop.hsd1.ca.comcast.net>
Message-ID: <20050731094623.61e7600d@absurd>

> Facts can't be copyrighted. But it's not easy to use that to convince
> someone to stop labeling a fact as being copyrighted.

but current linux kernel has to decompile ACPI tables too, right? and BSD also?

or am I wrong?

-- 
Janek Kozicki                                                         |



From stepan at openbios.org  Sun Jul 31 10:51:15 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Sun, 31 Jul 2005 10:51:15 +0200
Subject: [LinuxBIOS] Potential copyright issues with decompiling ACPI
	tables?
In-Reply-To: <20050731094623.61e7600d@absurd>
References: <200507282104.j6SL4RC7008842@tundra.winternet.com>
	<Pine.LNX.4.58.0507281522540.12404@enigma.lanl.gov>
	<1122586194.8576.23.camel@plipper.ccstar>
	<20050731014647.GB1777@greglaptop.hsd1.ca.comcast.net>
	<20050731094623.61e7600d@absurd>
Message-ID: <20050731085115.GA27637@openbios.org>

* Janek Kozicki <janek_listy at wp.pl> [050731 09:46]:
> > Facts can't be copyrighted. But it's not easy to use that to convince
> > someone to stop labeling a fact as being copyrighted.
> 
> but current linux kernel has to decompile ACPI tables too, right? and
> BSD also?

But the ACPI tables don't have to be part of Linux for the whole thing
to work. If you flash LinuxBIOS, you _include_ a set of ACPI tables, or
no ACPI tables are available..

Stefan