From rsmith at bitworks.com  Fri Oct  1 11:31:01 2004
From: rsmith at bitworks.com (Richard Smith)
Date: Fri Oct  1 11:31:01 2004
Subject: PCI guru consultant needed
In-Reply-To: <E8F8DBCB0468204E856114A2CD20741F2C1611@mail.local.ActualitySystems.com>
References: <E8F8DBCB0468204E856114A2CD20741F2C1611@mail.local.ActualitySystems.com>
Message-ID: <415D8A38.7040202@bitworks.com>

Bitworks needs help.

We currently Intel Celeron 440bx design that has ATI M1 video chips on 
board.  Off and on for the past 6 months or so I've been working to make 
them work under Linuxbios, ADLO, or testbios, etc.

I've have finally managed to show that the problem is hardware related 
to our design.  As I can make a PCI eval card from ATI work on a Asus 
P2B motherboard and linuxbios using X to softboot the card.  The same 
setup on our board fails to work.

Somehow the SDRAM inside the M1 chip is failing to initialize properly. 
  The video output has all the right VSYNC and HSYNC for the 800x600 
mode I setup but a black screen and a large square block for the cursor. 
  If I exit X and try to write/read a value into video ram I get garbage 
back.  This works on the Ausu P2B.

Things with our customer have gone critical. I've got to have something 
working by the end of October.

So I'm in search of people who really understand PCI and video stuff and 
are available for consulting either on site here or I can come to thier 
site.

Also any one have on know of place I can go to get a PCI complience test 
done?  Or hardware I can rent?  We reciently borrowed a HP 16500B logic 
analyzer with a Future+Systems passive PCI hookup but it dosn't do 
complience testing.  We need an additional card for that.

-- 
Richard A. Smith




From bari at onelabs.com  Fri Oct  1 12:37:00 2004
From: bari at onelabs.com (Bari Ari)
Date: Fri Oct  1 12:37:00 2004
Subject: PCI guru consultant needed
In-Reply-To: <415D8A38.7040202@bitworks.com>
References: <E8F8DBCB0468204E856114A2CD20741F2C1611@mail.local.ActualitySystems.com> <415D8A38.7040202@bitworks.com>
Message-ID: <415D99B5.2060706@onelabs.com>

Richard Smith wrote:
> Somehow the SDRAM inside the M1 chip is failing to initialize properly. 
>  The video output has all the right VSYNC and HSYNC for the 800x600 mode 
> I setup but a black screen and a large square block for the cursor.  If 
> I exit X and try to write/read a value into video ram I get garbage 
> back.  This works on the Ausu P2B.

Are you testing this on more than one proto?

Can you repeatedly read and write successfully to registers in the M1? 
Is sounds like you are having some success, since you have some display 
output.

Is there a PCI slot on the board or at least PCI test headers for all 
signals?

How do you know that the SDRAM is good inside the M1? I don't have the 
M1 data sheet, but I bet the SDRAM and the GPU are separate die mounted 
in the same package.

-Bari


From stepan at openbios.org  Fri Oct  1 12:43:00 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Fri Oct  1 12:43:00 2004
Subject: PCI guru consultant needed
In-Reply-To: <415D8A38.7040202@bitworks.com>
References: <E8F8DBCB0468204E856114A2CD20741F2C1611@mail.local.ActualitySystems.com> <415D8A38.7040202@bitworks.com>
Message-ID: <20041001175920.GA12199@openbios.org>

* Richard Smith <rsmith at bitworks.com> [041001 18:47]:
> Somehow the SDRAM inside the M1 chip is failing to initialize properly. 
>  The video output has all the right VSYNC and HSYNC for the 800x600 
> mode I setup but a black screen and a large square block for the cursor. 
>  If I exit X and try to write/read a value into video ram I get garbage 
> back.  This works on the Ausu P2B.

Wild guess: 
 - Timing issues?
 - missing bridge initialization?

Stefan




From YhLu at tyan.com  Fri Oct  1 12:59:00 2004
From: YhLu at tyan.com (YhLu)
Date: Fri Oct  1 12:59:00 2004
Subject: changes today. 
Message-ID: <3174569B9743D511922F00A0C94314230624C6A5@TYANWEB>

Please respond. Otherwise I will commit it today.

-----Original Message-----
From: YhLu 
Sent: Thursday, September 30, 2004 12:01 PM
To: Ronald G. Minnich; ebiederman at lnxi.com; Stefan Reinauer; Li-Ta Lo
Cc: linuxbios at clustermatic.org
Subject: RE: changes today. 

Ron/Eric/Stephan/Ollie,

Please check the patch.

1. some tyan volatile messing because of ROMCC changes.
2. S2882 interrupt line assignment in mptable.c
3. exclude range for flash_rom.
4. better ht_setup_chainx() in incoherent_ht.c ---> change share bus 0 to
different bus for different incoherent HT link.
5. fix one bug about io and mem allocation for multi ht links. --- in
northbridge.c
	Mark it if used before assign final value.
6. enable amd/quartet to init multi incoherent HT link in auto.c --- not
test, no MB on hand.
7. enable S2885 to init multi incoherent HT link in auto.c


Regards


YH



From YhLu at tyan.com  Fri Oct  1 13:17:00 2004
From: YhLu at tyan.com (YhLu)
Date: Fri Oct  1 13:17:00 2004
Subject: PCI guru consultant needed
Message-ID: <3174569B9743D511922F00A0C94314230624C6AD@TYANWEB>

On board and add-on card, there is some difference.

I just noticed
Ati ragexl init in LinuxBIOS only support Onboard device. And does not
support addon card.

But the ragexl init in Kernel can support both.

Regards

YH

-----Original Message-----
From: Stefan Reinauer [mailto:stepan at openbios.org] 
Sent: Friday, October 01, 2004 10:59 AM
To: Richard Smith
Cc: linuxbios at clustermatic.org
Subject: Re: PCI guru consultant needed

* Richard Smith <rsmith at bitworks.com> [041001 18:47]:
> Somehow the SDRAM inside the M1 chip is failing to initialize properly. 
>  The video output has all the right VSYNC and HSYNC for the 800x600 
> mode I setup but a black screen and a large square block for the cursor. 
>  If I exit X and try to write/read a value into video ram I get garbage 
> back.  This works on the Ausu P2B.

Wild guess: 
 - Timing issues?
 - missing bridge initialization?

Stefan


_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From rsmith at bitworks.com  Fri Oct  1 14:26:01 2004
From: rsmith at bitworks.com (Richard Smith)
Date: Fri Oct  1 14:26:01 2004
Subject: PCI guru consultant needed
In-Reply-To: <415D99B5.2060706@onelabs.com>
References: <E8F8DBCB0468204E856114A2CD20741F2C1611@mail.local.ActualitySystems.com> <415D8A38.7040202@bitworks.com> <415D99B5.2060706@onelabs.com>
Message-ID: <415DB320.5040909@bitworks.com>

Bari Ari wrote:

> 
> Are you testing this on more than one proto?
> 

No. Unfortunaly I don't have but one proto.

> Can you repeatedly read and write successfully to registers in the M1? 
> Is sounds like you are having some success, since you have some display 
> output.

Yes.  From a software point.  Things appear to be ok.  I've also enabled 
all the IO output from testbios.  I can take testbios and run it on a 
different motherboard and with the PCI eval card I have and get a signon 
screen.  If I then duplicate this test on our board I get almost an 
identical log up until the point it starts testing 0xA0000 which fails 
and the logs then take different paths.

I've looked at the differences betwen the logs and they seem proper.

I've can also boot general software's bios on this board and the ATI 
card eval card does not work.  BUT I have other PCI video cards that DO 
work. Except they come up in monochrome mode.

I have an assiliant, nvidia, S3, matrox and a no name, PCI video cards 
that boot using general software's bios. Although they come up in 
monochrome mode.

But I also have 2 ATI (M1 and Rage pro), and a different S3 card that do 
not work.

> Is there a PCI slot on the board or at least PCI test headers for all 
> signals?

There is a single PCI slot on the board for testing.

> How do you know that the SDRAM is good inside the M1? I don't have the 
> M1 data sheet, but I bet the SDRAM and the GPU are separate die mounted 
> in the same package.

We have replaced the M1 chips on this boad once already.

I can plug the PCI eval card into any other PC and it works fine.

-- 
Richard A. Smith




From stepan at openbios.org  Fri Oct  1 17:36:01 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Fri Oct  1 17:36:01 2004
Subject: changes today.
In-Reply-To: <3174569B9743D511922F00A0C94314230624C5E1@TYANWEB>
References: <3174569B9743D511922F00A0C94314230624C5E1@TYANWEB>
Message-ID: <20041001225218.GA16512@openbios.org>

Hi Yinghai,

> 2. S2882 interrupt line assignment in mptable.c
> 3. exclude range for flash_rom.
> 4. better ht_setup_chainx() in incoherent_ht.c ---> change share bus 0 to
> different bus for different incoherent HT link.
> 5. fix one bug about io and mem allocation for multi ht links. --- in
> northbridge.c
> 	Mark it if used before assign final value.
> 6. enable amd/quartet to init multi incoherent HT link in auto.c --- not
> test, no MB on hand.
> 7. enable S2885 to init multi incoherent HT link in auto.c

> diff -uNr ./freebios2/src/mainboard/amd/quartet/auto.c ../freebios2/src/mainboard/amd/quartet/auto.c
> --- ./freebios2/src/mainboard/amd/quartet/auto.c	2004-04-28 01:08:06.000000000 -0700
> +++ ../freebios2/src/mainboard/amd/quartet/auto.c	2004-09-29 09:30:57.000000000 -0700
> @@ -100,11 +100,12 @@
>  	 */
>  
>  	uint32_t ret = 0x00010101;	/* default row entry */
> -
> +/*
>  	static const unsigned int rows_2p[2][2] = {
>  		{0x00030101, 0x00010202},
>  		{0x00010202, 0x00030101}
>  	};
> +*/
>  
>  	static const unsigned int rows_4p[4][4] = {
>  		{0x00070101, 0x00010202, 0x00030404, 0x00010204},
> @@ -114,9 +115,11 @@
>  	};
>  
>  	if (!(node >= maxnodes || row >= maxnodes)) {
> +/*
>  		if (maxnodes == 2)
>  			ret = rows_2p[node][row];
>  		if (maxnodes == 4)
> +*/
>  			ret = rows_4p[node][row];
>  	}
 
I am in doubt this is a good idea. It will likely break 4p systems with
only 2 cpus installed. The better idea might be to mask the according
links decently.

Which reminds me that we could do this a lot nicer dynamically with a
little more stack depth available (ie with working CAR)

> @@ -199,6 +203,20 @@
>  	};
> +
> +        static const struct ht_chain ht_c[] = {
> +                {  /* Link 2 of CPU0 */
> +                        .udev = PCI_DEV(0, 0x18, 0),
> +                        .upos = 0xc0,
> +                        .devreg = 0xe0,  /* Preset bus num in resource map */
> +                }, 
> +                {  /* Link 1 of CPU1 */
> +                        .udev = PCI_DEV(0, 0x19, 0),
> +                        .upos = 0xa0,  
> +                        .devreg = 0xe4,  /* Preset bus num in resource map */
> +                },
> +        };  
> +
>  	int needs_reset;
>  
>  	enable_lapic();

Can we generate above struct from the information we have in the config
tool? at least the cpu link should be there. What's the bus num again? 

> -	asm("jmp __normal_image" 
> +	asm volatile ("jmp __normal_image" 

Can't this be fixed in romcc instead? If we have to put an asm volatile
statement instead of every asm, we could as well just do
#define asm asm volatile 
or the adequate change in the romcc code

> diff -uNr ./freebios2/src/mainboard/tyan/s2882/irq_tables.c ../freebios2/src/mainboard/tyan/s2882/irq_tables.c
> --- ./freebios2/src/mainboard/tyan/s2882/irq_tables.c	2004-03-12 07:13:31.000000000 -0800
> +++ ../freebios2/src/mainboard/tyan/s2882/irq_tables.c	2004-07-02 10:01:48.000000000 -0700
> @@ -18,7 +18,7 @@
>  	0x746b,         /* Device */
>  	0,         /* Crap (miniport) */
>  	{ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, /* u8 rfu[11] */
> -	0x8d,         /*  u8 checksum , this hase to set to some value that would give 0 after the sum of all bytes for this structure (including checksum) */
> +	0xff,         /*  u8 checksum , this hase to set to some value that would give 0 after the sum of all bytes for this structure (including checksum) */
>  	{
>  		{1,(4<<3)|0, {{0x1, 0xdef8}, {0x2, 0xdef8}, {0x3, 0xdef8}, {0x4, 0xdef8}}, 0, 0},
>  		{0x4,0, {{0, 0}, {0, 0}, {0, 0}, {0x4, 0xdef8}}, 0, 0},

To get this right, does Linux expect the PIRQ table to be in ROM in any
condition? The code will correct the table's checksum in RAM, and the
goal should definitely be to create all the table in ram during bootup.
I saw phoenix bios almost writes a nice dynamic device tree into the 
pirq table, including CPUs and busses, instead of just putting the most 
necessary lines for the pci slots in. This sounds like a way to go.

> mptable.c

> +#if ASSIGN_IRQ 
>  	smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, 0x1, (4<<2)|3, 0x2, 0x13);
> +
> +	{
> +		device_t dev;
> +        	dev = dev_find_device(PCI_VENDOR_ID_AMD, 0x746b, 0);
> +        	if (dev) {
> +                	/* initialize PCI interupts - these assignments depend
> +                   	on the PCB routing of PINTA-D 
> +
> +                   	PINTA = IRQ5
> +                   	PINTB = IRQ9
> +                   	PINTC = IRQ11
> +                   	PINTD = IRQ10
> +                	*/
> +                	pci_write_config16(dev, 0x56, 0xab95);
> +		}
> +        }
> +#endif
> +
> +#if ASSIGN_IRQ
> +        printk_info("setting Onboard AMD Southbridge \n");
> +        static const unsigned char slotIrqs_1_4[4] = { 5, 9, 11, 10 };
> +        pci_assign_irqs(1, 4, slotIrqs_1_4);
> +#endif

Does this belong into the mptable generation? I would assume it better
fits into the "driver" code pieces

Otherwise I see that we have to shift all motherboards to use the above
mechanism, ending up with dozens of half broken mp tables (worse than it
is now already) 
 	
> diff -uNr ./freebios2/src/mainboard/tyan/s2885/resourcemap.c ../freebios2/src/mainboard/tyan/s2885/resourcemap.c
> --- ./freebios2/src/mainboard/tyan/s2885/resourcemap.c	2004-03-26 13:34:04.000000000 -0800
> +++ ../freebios2/src/mainboard/tyan/s2885/resourcemap.c	2004-09-20 11:00:09.000000000 -0700
> @@ -252,8 +252,8 @@
>  		 * [31:24] Bus Number Limit i
>  		 *	   This field defines the highest bus number in configuration regin i
>  		 */
> -		PCI_ADDR(0, 0x18, 1, 0xE0), 0x0000FC88, 0x06010207,
> -		PCI_ADDR(0, 0x18, 1, 0xE4), 0x0000FC88, 0x00000007,
> +		PCI_ADDR(0, 0x18, 1, 0xE0), 0x0000FC88, 0x06000203, // AMD 8111 on link2 of CPU 0
> +		PCI_ADDR(0, 0x18, 1, 0xE4), 0x0000FC88, 0x08070003, // AMD 8151 on link0 of CPU 0
>  		PCI_ADDR(0, 0x18, 1, 0xE8), 0x0000FC88, 0x00000000,
>  		PCI_ADDR(0, 0x18, 1, 0xEC), 0x0000FC88, 0x00000000,
>  	};

I remember I commited some code a long time ago that detected the
southbridge link and set it correctly. Looks like it got dumped by
accident. We should do this again, and the same for the 8151.


> diff -uNr ./freebios2/src/mainboard/tyan/s4880/auto.c ../freebios2/src/mainboard/tyan/s4880/auto.c
> --- ./freebios2/src/mainboard/tyan/s4880/auto.c	2004-04-24 16:01:19.000000000 -0700
> +++ ../freebios2/src/mainboard/tyan/s4880/auto.c	2004-08-31 18:57:46.000000000 -0700
> @@ -28,7 +28,7 @@
>          set_bios_reset();
>  
>          /* enable cf9 */
> -        pci_write_config8(PCI_DEV(1, 0x04, 3), 0x41, 0xf1);
> +        pci_write_config8(PCI_DEV(0, 0x04, 3), 0x41, 0xf1);

Is this not configurable in the config file, as well, by now, in some
places? We need to factorize this kind of code a lot more.. Every change
hurts, because the opteron board support code is drifting in many
directions

> @@ -214,7 +214,7 @@
>          console_init();
>          setup_s4880_resource_map();
>          needs_reset = setup_coherent_ht_domain();
> -        needs_reset |= ht_setup_chain(PCI_DEV(0, 0x18, 0), 0x80);
> +        needs_reset |= ht_setup_chain(PCI_DEV(0, 0x18, 0), 0xc0);

Why are you not using the same struct as above for the s27xx?

> diff -uNr ./freebios2/src/northbridge/amd/amdk8/incoherent_ht.c ../freebios2/src/northbridge/amd/amdk8/incoherent_ht.c
> --- ./freebios2/src/northbridge/amd/amdk8/incoherent_ht.c	2004-04-15 10:33:21.000000000 -0700
> +++ ../freebios2/src/northbridge/amd/amdk8/incoherent_ht.c	2004-08-24 12:03:10.000000000 -0700
> @@ -247,19 +263,21 @@
>  	unsigned upos;
>  	unsigned devreg; 
>  };
> -
> -static int ht_setup_chainx(device_t udev, unsigned upos, unsigned next_unitid)
> +static int ht_setup_chainx(device_t udev, unsigned upos, unsigned bus)
>  {
> -	unsigned last_unitid;
> +	unsigned next_unitid, last_unitid;
>  	unsigned uoffs;
>  	int reset_needed=0;
>  
>  	uoffs = PCI_HT_HOST_OFFS;
> +	next_unitid = 1;
> +
>  	do {
>  		uint32_t id;
>  		uint8_t pos;
>  		unsigned flags, count;
> -		device_t dev = PCI_DEV(0, 0, 0);
> +		
> +		device_t dev = PCI_DEV(bus, 0, 0);
>  		last_unitid = next_unitid;
>  
>  		id = pci_read_config32(dev, PCI_VENDOR_ID);
> @@ -293,8 +328,7 @@
>  		next_unitid += count;
>  
>  	} while((last_unitid != next_unitid) && (next_unitid <= 0x1f));
> -	if(reset_needed!=0) next_unitid |= 0xffff0000;
> -	return next_unitid;
> +	return reset_needed;
>  }
 
Did we not support icht chains hanging off any bus other than 0 before?!
Can you add some comments to the changes you made to incoherent_ht.c ?

This is some very fundamental piece of code that should be well
understood.
Same for the northbridge.c code.

Stefan




From adam at cfar.umd.edu  Fri Oct  1 18:09:00 2004
From: adam at cfar.umd.edu (Adam Sulmicki)
Date: Fri Oct  1 18:09:00 2004
Subject: PCI guru consultant needed
In-Reply-To: <415D8A38.7040202@bitworks.com>
Message-ID: <20041001192438.L38051-100000@www.missl.cs.umd.edu>

have you tried    pci-sig at znyx.com ? It has people who works on designing
PCI buses as their day to day job.

I think you send email to pci-sig-request at znyx.com with subject
'subscribe'.

On Fri, 1 Oct 2004, Richard Smith wrote:

> Bitworks needs help.
>
> We currently Intel Celeron 440bx design that has ATI M1 video chips on
> board.  Off and on for the past 6 months or so I've been working to make
> them work under Linuxbios, ADLO, or testbios, etc.
>
> I've have finally managed to show that the problem is hardware related
> to our design.  As I can make a PCI eval card from ATI work on a Asus
> P2B motherboard and linuxbios using X to softboot the card.  The same
> setup on our board fails to work.
>
> Somehow the SDRAM inside the M1 chip is failing to initialize properly.
>   The video output has all the right VSYNC and HSYNC for the 800x600
> mode I setup but a black screen and a large square block for the cursor.
>   If I exit X and try to write/read a value into video ram I get garbage
> back.  This works on the Ausu P2B.
>
> Things with our customer have gone critical. I've got to have something
> working by the end of October.
>
> So I'm in search of people who really understand PCI and video stuff and
> are available for consulting either on site here or I can come to thier
> site.
>
> Also any one have on know of place I can go to get a PCI complience test
> done?  Or hardware I can rent?  We reciently borrowed a HP 16500B logic
> analyzer with a Future+Systems passive PCI hookup but it dosn't do
> complience testing.  We need an additional card for that.
>
>




From ebiederman at lnxi.com  Fri Oct  1 18:29:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Oct  1 18:29:01 2004
Subject: [BULK] Re: changes today.
In-Reply-To: <20041001225218.GA16512@openbios.org>
References: <3174569B9743D511922F00A0C94314230624C5E1@TYANWEB>
	<20041001225218.GA16512@openbios.org>
Message-ID: <m3y8iqj94c.fsf@maxwell.lnxi.com>

Right now I feel like taffy, stretched thin and pulled in all directions.
My apologies for not responding sooner.


Stefan Reinauer <stepan at openbios.org> writes:

> Hi Yinghai,
> 
> > 2. S2882 interrupt line assignment in mptable.c
> > 3. exclude range for flash_rom.
> > 4. better ht_setup_chainx() in incoherent_ht.c ---> change share bus 0 to
> > different bus for different incoherent HT link.
> > 5. fix one bug about io and mem allocation for multi ht links. --- in
> > northbridge.c
> > 	Mark it if used before assign final value.
> > 6. enable amd/quartet to init multi incoherent HT link in auto.c --- not
> > test, no MB on hand.
> > 7. enable S2885 to init multi incoherent HT link in auto.c
> 
> > diff -uNr ./freebios2/src/mainboard/amd/quartet/auto.c
> ../freebios2/src/mainboard/amd/quartet/auto.c
> 
> > --- ./freebios2/src/mainboard/amd/quartet/auto.c 2004-04-28 01:08:06.000000000
> -0700
> 
> > +++ ../freebios2/src/mainboard/amd/quartet/auto.c 2004-09-29
> 09:30:57.000000000 -0700
> 
> > @@ -100,11 +100,12 @@
> >  	 */
> >  
> >  	uint32_t ret = 0x00010101;	/* default row entry */
> > -
> > +/*
> >  	static const unsigned int rows_2p[2][2] = {
> >  		{0x00030101, 0x00010202},
> >  		{0x00010202, 0x00030101}
> >  	};
> > +*/
> >  
> >  	static const unsigned int rows_4p[4][4] = {
> >  		{0x00070101, 0x00010202, 0x00030404, 0x00010204},
> > @@ -114,9 +115,11 @@
> >  	};
> >  
> >  	if (!(node >= maxnodes || row >= maxnodes)) {
> > +/*
> >  		if (maxnodes == 2)
> >  			ret = rows_2p[node][row];
> >  		if (maxnodes == 4)
> > +*/
> >  			ret = rows_4p[node][row];
> >  	}
>  
> I am in doubt this is a good idea. It will likely break 4p systems with
> only 2 cpus installed. The better idea might be to mask the according
> links decently.

Which reminds me I need to push my patch that properly handles the case
of not having all of your cpus plugged in.

> Which reminds me that we could do this a lot nicer dynamically with a
> little more stack depth available (ie with working CAR)

Quite possibly.  I'm not holding my breath on this one.

> 
> > @@ -199,6 +203,20 @@
> >  	};
> > +
> > +        static const struct ht_chain ht_c[] = {
> > +                {  /* Link 2 of CPU0 */
> > +                        .udev = PCI_DEV(0, 0x18, 0),
> > +                        .upos = 0xc0,
> > + .devreg = 0xe0, /* Preset bus num in resource map */
> 
> > +                }, 
> > +                {  /* Link 1 of CPU1 */
> > +                        .udev = PCI_DEV(0, 0x19, 0),
> > +                        .upos = 0xa0,  
> > + .devreg = 0xe4, /* Preset bus num in resource map */
> 
> > +                },
> > +        };  
> > +
> >  	int needs_reset;
> >  
> >  	enable_lapic();
> 
> Can we generate above struct from the information we have in the config
> tool? at least the cpu link should be there. What's the bus num again? 

Ideally we could just put a loop through the HT links on the cpus
and if the link is up and not coherent enumerate it.  I suspect that
would be simples.
 
> > -	asm("jmp __normal_image" 
> > +	asm volatile ("jmp __normal_image" 
> 
> Can't this be fixed in romcc instead? If we have to put an asm volatile
> statement instead of every asm, we could as well just do
> #define asm asm volatile 
> or the adequate change in the romcc code

The rules with romcc are exactly the same as the rules in gcc.

The rdtsc case I'm not certain about.  But for the rest romcc
will optimize out a non-volatile asm that has neither inputs
or outputs.   If romcc knew the jumps affected control flow
there would not be a problem.  Since it does not those statements
need to be volatile.


> > diff -uNr ./freebios2/src/mainboard/tyan/s2882/irq_tables.c
> ../freebios2/src/mainboard/tyan/s2882/irq_tables.c
> 
> > --- ./freebios2/src/mainboard/tyan/s2882/irq_tables.c 2004-03-12
> 07:13:31.000000000 -0800
> 
> > +++ ../freebios2/src/mainboard/tyan/s2882/irq_tables.c 2004-07-02
> 10:01:48.000000000 -0700
> 
> > @@ -18,7 +18,7 @@
> >  	0x746b,         /* Device */
> >  	0,         /* Crap (miniport) */
> >  	{ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, /* u8 rfu[11] */
> > - 0x8d, /* u8 checksum , this hase to set to some value that would give 0
> after the sum of all bytes for this structure (including checksum) */
> 
> > + 0xff, /* u8 checksum , this hase to set to some value that would give 0
> after the sum of all bytes for this structure (including checksum) */
> 
> >  	{
> > {1,(4<<3)|0, {{0x1, 0xdef8}, {0x2, 0xdef8}, {0x3, 0xdef8}, {0x4, 0xdef8}}, 0,
> 0},
> 
> >  		{0x4,0, {{0, 0}, {0, 0}, {0, 0}, {0x4, 0xdef8}}, 0, 0},
> 
> To get this right, does Linux expect the PIRQ table to be in ROM in any
> condition? The code will correct the table's checksum in RAM, and the
> goal should definitely be to create all the table in ram during bootup.
> I saw phoenix bios almost writes a nice dynamic device tree into the 
> pirq table, including CPUs and busses, instead of just putting the most 
> necessary lines for the pci slots in. This sounds like a way to go.

Linux looks at 0xf00000 which is either ROM or RAM.  I'm looking at finding
the time to do a complete rewrite based on our dynamic device tree.  What
exists currently is a major pain.

> > mptable.c
> 
> > +#if ASSIGN_IRQ 
> > smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, 0x1,
> (4<<2)|3, 0x2, 0x13);
> 
> > +
> > +	{
> > +		device_t dev;
> > +        	dev = dev_find_device(PCI_VENDOR_ID_AMD, 0x746b, 0);
> > +        	if (dev) {
> > +                	/* initialize PCI interupts - these assignments depend
> > +                   	on the PCB routing of PINTA-D 
> > +
> > +                   	PINTA = IRQ5
> > +                   	PINTB = IRQ9
> > +                   	PINTC = IRQ11
> > +                   	PINTD = IRQ10
> > +                	*/
> > +                	pci_write_config16(dev, 0x56, 0xab95);
> > +		}
> > +        }
> > +#endif
> > +
> > +#if ASSIGN_IRQ
> > +        printk_info("setting Onboard AMD Southbridge \n");
> > +        static const unsigned char slotIrqs_1_4[4] = { 5, 9, 11, 10 };
> > +        pci_assign_irqs(1, 4, slotIrqs_1_4);
> > +#endif
> 
> Does this belong into the mptable generation? I would assume it better
> fits into the "driver" code pieces
> 
> Otherwise I see that we have to shift all motherboards to use the above
> mechanism, ending up with dozens of half broken mp tables (worse than it
> is now already) 

True but at least at the moment it is motherboard specific code.  So
it is ``only'' a bad example.  This is equally doable with just
the pirq table, but the result (setting the interrupt line register
is desirable.

> I remember I commited some code a long time ago that detected the
> southbridge link and set it correctly. Looks like it got dumped by
> accident. We should do this again, and the same for the 8151.

Hmm.  Something like that surely.
 
> 
> > diff -uNr ./freebios2/src/mainboard/tyan/s4880/auto.c
> ../freebios2/src/mainboard/tyan/s4880/auto.c
> 
> > --- ./freebios2/src/mainboard/tyan/s4880/auto.c 2004-04-24 16:01:19.000000000
> -0700
> 
> > +++ ../freebios2/src/mainboard/tyan/s4880/auto.c 2004-08-31 18:57:46.000000000
> -0700
> 
> > @@ -28,7 +28,7 @@
> >          set_bios_reset();
> >  
> >          /* enable cf9 */
> > -        pci_write_config8(PCI_DEV(1, 0x04, 3), 0x41, 0xf1);
> > +        pci_write_config8(PCI_DEV(0, 0x04, 3), 0x41, 0xf1);
> 
> Is this not configurable in the config file, as well, by now, in some
> places? We need to factorize this kind of code a lot more.. Every change
> hurts, because the opteron board support code is drifting in many
> directions

Something things we do need to setup early, and resets look like one
of them.

> > +static int ht_setup_chainx(device_t udev, unsigned upos, unsigned bus)
> >  {
> > -	unsigned last_unitid;
> > +	unsigned next_unitid, last_unitid;
> >  	unsigned uoffs;
> >  	int reset_needed=0;
> >  
> >  	uoffs = PCI_HT_HOST_OFFS;
> > +	next_unitid = 1;
> > +
> >  	do {
> >  		uint32_t id;
> >  		uint8_t pos;
> >  		unsigned flags, count;
> > -		device_t dev = PCI_DEV(0, 0, 0);
> > +		
> > +		device_t dev = PCI_DEV(bus, 0, 0);
> >  		last_unitid = next_unitid;
> >  
> >  		id = pci_read_config32(dev, PCI_VENDOR_ID);
> > @@ -293,8 +328,7 @@
> >  		next_unitid += count;
> >  
> >  	} while((last_unitid != next_unitid) && (next_unitid <= 0x1f));
> > -	if(reset_needed!=0) next_unitid |= 0xffff0000;
> > -	return next_unitid;
> > +	return reset_needed;
> >  }
>  
> Did we not support icht chains hanging off any bus other than 0 before?!
> Can you add some comments to the changes you made to incoherent_ht.c ?

Stefan it is not devices hanging of bus 0.  It is what bus number the chain
will be assigned.  For the same reason the generic code does not use
bus 0, this code is simplest if we use another bus number as well.
 
> This is some very fundamental piece of code that should be well
> understood. Same for the northbridge.c code.

What is happening in northbridge.c is a legitimate bug fix.  Because
we may not set the resource for a while.  I would prefer
not to use the pci configuration registers as scratch registers, but
that may be the simplest way to do things.

Eric


From rminnich at lanl.gov  Fri Oct  1 18:36:50 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Fri Oct  1 18:36:50 2004
Subject: changes today. 
In-Reply-To: <3174569B9743D511922F00A0C94314230624C6A5@TYANWEB>
References: <3174569B9743D511922F00A0C94314230624C6A5@TYANWEB>
Message-ID: <Pine.LNX.4.58.0410011549270.14151@linux.site>


On Fri, 1 Oct 2004, YhLu wrote:

> Please respond. Otherwise I will commit it today.

I will try to look at it but can you hold off until monday. I've been in 
too many meetings. 

ron


From YhLu at tyan.com  Fri Oct  1 18:57:00 2004
From: YhLu at tyan.com (YhLu)
Date: Fri Oct  1 18:57:00 2004
Subject: [BULK] Re: changes today.
Message-ID: <3174569B9743D511922F00A0C94314230624C6E4@TYANWEB>

> 4. better ht_setup_chainx() in incoherent_ht.c ---> change share bus 0 to
 different bus for different incoherent HT link.
For s2885 there are two incoherent links in CPU0, one for 8151 and one for
8131/8111.
For AMD/quartet are incoherent link in CPU0, and another link in CPU1
For S2895 there are two incoherent links in CPU0 and another link in CPU1.
 
For S2885, in old ht_setup_chains, I let the two links share bus 0, 
So 
         PCI_ADDR(0, 0x18, 1, 0xE0), 0x0000FC88, 0x06010207,
         PCI_ADDR(0, 0x18, 1, 0xE4), 0x0000FC88, 0x00000007,
But if there is too much link, will used the device num.
 
So update the ht_setup_chains
 
 
static int ht_setup_chains(const struct ht_chain *ht_c, int ht_c_num)
{
        /* Assumption the HT chain that is bus 0 has the HT I/O Hub on it. 
         * On most boards this just happens.  If a cpu has multiple
         * non Coherent links the appropriate bus registers for the
         * links needs to be programed to point at bus 0.
         */
        int reset_needed;
        unsigned upos;
        device_t udev;
        int i;
 
        reset_needed = 0;
 
        for (i = 0; i < ht_c_num; i++) {
                uint32_t reg;
                unsigned devpos;
                unsigned regpos;
                uint32_t dword;
                unsigned busn;
 
                reg = pci_read_config32(PCI_DEV(0,0x18,1), ht_c[i].devreg);
 
                //We need setup 0x94, 0xb4, and 0xd4 according to the reg
                devpos = ((reg & 0xf0)>>4)+0x18; // nodeid; it will decide
0x18 or 0x19
                regpos = ((reg & 0xf00)>>8) * 0x20 + 0x94; // link n; it
will decide 0x94 or 0xb4, 0x0xd4;
                busn = (reg & 0xff0000)>>16;
 
                dword = pci_read_config32( PCI_DEV(0, devpos, 0), regpos) ;
                dword &= ~(0xffff<<8);
                dword |= (reg & 0xffff0000)>>8;
                pci_write_config32( PCI_DEV(0, devpos,0), regpos , dword);
 
                /* Make certain the HT bus is not enumerated */
                ht_collapse_previous_enumeration(busn);
 
                upos = ht_c[i].upos;
                udev = ht_c[i].udev;
               reset_needed |= ht_setup_chainx(udev,upos,busn );
 
        }
 
        return reset_needed;
}
 
 
> 5. fix one bug about io and mem allocation for multi ht links. --- in
> northbridge.c
Should mark some reg to prevent the overlap.
Because amdk8_find_mempair and amdk8_find_iopair are called several times
(for the incoherent links), before the registers are set.
So same reg will be assigned to different link. That is bug, So add some
thing in the PCI reg.
 
        /* Mark reg has been used now */
        base = f1_read_config32(reg);
        if( (base & 3) != 3 ) {
                base |= 0x01fff000;
                f1_write_config32(reg, base);
        }
 
        /* Mark reg has been used now */
        base = f1_read_config32(reg);
        if( (base & 3) != 3 ) {
                base |= 0xffffff00;
                f1_write_config32(reg, base);
        }
 
Regards
 
YH
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20041001/64e6b76a/attachment.html>

From rsmith at bitworks.com  Fri Oct  1 19:02:03 2004
From: rsmith at bitworks.com (Richard Smith)
Date: Fri Oct  1 19:02:03 2004
Subject: [BULK] Re: changes today.
In-Reply-To: <m3y8iqj94c.fsf@maxwell.lnxi.com>
References: <3174569B9743D511922F00A0C94314230624C5E1@TYANWEB>	<20041001225218.GA16512@openbios.org> <m3y8iqj94c.fsf@maxwell.lnxi.com>
Message-ID: <415DF2FD.5080405@bitworks.com>

Eric W. Biederman wrote:

> Right now I feel like taffy, stretched thin and pulled in all directions.
> My apologies for not responding sooner.
> 

Amen. I'm with you.

-- 
Richard A. Smith




From rminnich at lanl.gov  Fri Oct  1 19:07:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Fri Oct  1 19:07:00 2004
Subject: changes today.
In-Reply-To: <20041001225218.GA16512@openbios.org>
References: <3174569B9743D511922F00A0C94314230624C5E1@TYANWEB>
 <20041001225218.GA16512@openbios.org>
Message-ID: <Pine.LNX.4.58.0410011723450.14151@linux.site>


On Sat, 2 Oct 2004, Stefan Reinauer wrote:

> Hi Yinghai,

Yinghai, there seem to be a few questions on this patch, can you let Ollie 
and me go over it next week? He is back then. Please don't commit yet.

thanks

ron


From YhLu at tyan.com  Fri Oct  1 19:11:05 2004
From: YhLu at tyan.com (YhLu)
Date: Fri Oct  1 19:11:05 2004
Subject: changes today.
Message-ID: <3174569B9743D511922F00A0C94314230624C6E6@TYANWEB>

I see. I don't want to mess the CVS tree.

-----Original Message-----
From: Ronald G. Minnich [mailto:rminnich at lanl.gov] 
Sent: Friday, October 01, 2004 4:24 PM
To: Stefan Reinauer
Cc: YhLu; ebiederman at lnxi.com; Li-Ta Lo; linuxbios at clustermatic.org
Subject: Re: changes today.



On Sat, 2 Oct 2004, Stefan Reinauer wrote:

> Hi Yinghai,

Yinghai, there seem to be a few questions on this patch, can you let Ollie 
and me go over it next week? He is back then. Please don't commit yet.

thanks

ron


From YhLu at tyan.com  Fri Oct  1 21:00:01 2004
From: YhLu at tyan.com (YhLu)
Date: Fri Oct  1 21:00:01 2004
Subject: [BULK] Re: changes today.
Message-ID: <3174569B9743D511922F00A0C94314230665AAEC@TYANWEB>

Eric,

        if (cpu_init_detected()) {
                asm volatile ("jmp __cpu_reset");
        }

The cpu_init seems reset the memcontroller with opteron. (all HT links
configuration are still there).  So you can not just 
jmp to __cpu_reset.

There are two solution for it
1. init ram and then jump to __cpu_reset
	But the smbus_io_base may already changed by last normal boot. So
should use assigned smbus_io_base, that need to change amd8111_early_smbus.c
structure.

2. just issue another soft reset, --- amd8111 is in bus 1 now.

        if (cpu_init_detected()) {
#if 0
                asm volatile ("jmp __cpu_reset");
#else 
                /* cpu reset also reset the memtroller ????
            need soft_reset to reset all except keep HT link freq and width
*/
                distinguish_cpu_resets();
                soft2_reset();
#endif
        }

Which one do you prefer to?

Regards

YH


From dhsmith at gmail.com  Sat Oct  2 16:39:00 2004
From: dhsmith at gmail.com (David Smith)
Date: Sat Oct  2 16:39:00 2004
Subject: IBM Netvista 8363 (again)
Message-ID: <34f8553004100214551c7ec1c7@mail.gmail.com>

I was searching the archive and saw that zac luzader has managed to
get the Netvista to boot to 'something sane' of his own making.  I
came into posession of a couple of these Netvistas and I want to
figure out what I can do with them.  Zac, or anyone else who has these
working in a standalone mode, please drop me a line.

Thanks

David


From rminnich at lanl.gov  Mon Oct  4 11:15:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Oct  4 11:15:01 2004
Subject: e7500 code
Message-ID: <Pine.LNX.4.58.0410041031280.22531@linux.site>

it hardwires CASL to a pre-defined value: 

#define MRS_VALUE (MODE_NORM | CAS_LATENCY | BURST_TYPE | BURST_LENGTH)

which is going to be trouble if the SPD value is different. e75xx 
maintainers: did you really want to do this?

ron


From YhLu at tyan.com  Mon Oct  4 11:37:00 2004
From: YhLu at tyan.com (YhLu)
Date: Mon Oct  4 11:37:00 2004
Subject: e7500 code
Message-ID: <3174569B9743D511922F00A0C94314230665AB0C@TYANWEB>

That seems not be used. Please search it.

Regards

YH

-----Original Message-----
From: Ronald G. Minnich [mailto:rminnich at lanl.gov] 
Sent: Monday, October 04, 2004 9:32 AM
To: linuxbios at clustermatic.org
Subject: e7500 code


it hardwires CASL to a pre-defined value: 

#define MRS_VALUE (MODE_NORM | CAS_LATENCY | BURST_TYPE | BURST_LENGTH)

which is going to be trouble if the SPD value is different. e75xx 
maintainers: did you really want to do this?

ron
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From rminnich at lanl.gov  Mon Oct  4 12:23:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Oct  4 12:23:00 2004
Subject: e7500 code
In-Reply-To: <3174569B9743D511922F00A0C94314230665AB0C@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665AB0C@TYANWEB>
Message-ID: <Pine.LNX.4.58.0410041139380.22531@linux.site>


On Mon, 4 Oct 2004, YhLu wrote:

> That seems not be used. Please search it.

it ought to be removed then?

ron


From YhLu at tyan.com  Mon Oct  4 12:34:00 2004
From: YhLu at tyan.com (YhLu)
Date: Mon Oct  4 12:34:00 2004
Subject: e7500 code
Message-ID: <3174569B9743D511922F00A0C94314230665AB1E@TYANWEB>

I keep that in V2 to let others to check if the converting to C is right.

YH

-----Original Message-----
From: Ronald G. Minnich [mailto:rminnich at lanl.gov] 
Sent: Monday, October 04, 2004 10:40 AM
To: YhLu
Cc: linuxbios at clustermatic.org
Subject: RE: e7500 code



On Mon, 4 Oct 2004, YhLu wrote:

> That seems not be used. Please search it.

it ought to be removed then?

ron


From nick.barker9 at btinternet.com  Tue Oct  5 08:41:01 2004
From: nick.barker9 at btinternet.com (Nick Barker)
Date: Tue Oct  5 08:41:01 2004
Subject: Freebios2 on EPIA-M / MII - a large patch
Message-ID: <NEBBKHMFNKMOMMPGLHKPOEKFCKAA.nick.barker9@btinternet.com>

I've been working on freebios2 for the EPIA-MII for the last couple of
months as a way of getting to know freebios2.

I've got to the stage where I have a lot of things working, and would like
to contribute them back to the project. These include:

- ACPI power management and interrupt routing (could be applicable to other
platforms as well)
- Boot off onboard Compact Flash on the MII
- Legacy VGA BIOS working
- Mtrr's set up correctly for VGA and framebuffer
- AGP and GART working
- set up vt1211 as new device for enabling COM,LPT,FDC and H/W monitoring
- 1/2 speed serial baud rate fix.

The memory initialisation code is the static code borrowed from V1, and
setup for 256Mb only at the moment.

I have a source code patch made up which is approximately 200K big
uncompressed (64K bzipped), and I think some may object if I post something
of that size on the mailing list. Who should I direct this to so that it can
get reviewed/incorporated?

Nick Barker




From daubin at actuality-systems.com  Tue Oct  5 08:45:00 2004
From: daubin at actuality-systems.com (Dave Aubin)
Date: Tue Oct  5 08:45:00 2004
Subject: Testbios help with nvidia 6800Gt and simple how to
Message-ID: <E8F8DBCB0468204E856114A2CD20741F2C16F7@mail.local.ActualitySystems.com>

Hello,
 
  I'm trying to get an nvidia 6800 Gt video card to work with linuxbios,
but
I am coming up short.  Below is a mini how to with test bios and I did
follow
the steps, but it still doesn't work.  Can someone please help me?  
  I did the exact same steps with an nvidia5950 and it worked great.  
Is there something I am missing?
 
Simple Test Bios How to.
 
Purpose:  Testbios provides an i386 emulator for programming the video
bios.
 
How to:  First you need to retrieve the video bios from a machine booted
up
with a commercial bios running linux.  Then once that is done you can 
execute the bios by using testbios.  
 
How to retrieve video bios
1.  Boot up machine with commercial bios in to a linux environment
2.  dd if=/dev/mem of=vgabios.bin skip=1536 count=128 from a terminal
window
    A.  This copies the video bios out of /dev/mem and places it in
vgabios.bin
 
How to execute testbios
1.  Boot up machine with Linuxbios in to a linux environment
2.  run testbios --abseg /dev/mem -s 65536 /root/vgabios.bin
    A.  If working you should see the video bios welcome message on the
screen
 
 
Thanks,
Dave:)


From rminnich at lanl.gov  Tue Oct  5 09:07:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Tue Oct  5 09:07:01 2004
Subject: Freebios2 on EPIA-M / MII - a large patch
In-Reply-To: <NEBBKHMFNKMOMMPGLHKPOEKFCKAA.nick.barker9@btinternet.com>
References: <NEBBKHMFNKMOMMPGLHKPOEKFCKAA.nick.barker9@btinternet.com>
Message-ID: <Pine.LNX.4.58.0410050824440.25356@linux.site>

nick, I'll take it

ron



From rminnich at lanl.gov  Tue Oct  5 09:10:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Tue Oct  5 09:10:01 2004
Subject: Freebios2 on EPIA-M / MII - a large patch
In-Reply-To: <NEBBKHMFNKMOMMPGLHKPOEKFCKAA.nick.barker9@btinternet.com>
References: <NEBBKHMFNKMOMMPGLHKPOEKFCKAA.nick.barker9@btinternet.com>
Message-ID: <Pine.LNX.4.58.0410050825000.25356@linux.site>


On Tue, 5 Oct 2004, Nick Barker wrote:

> The memory initialisation code is the static code borrowed from V1, and
> setup for 256Mb only at the moment.

C or not?

thanks

ron


From daubin at actuality-systems.com  Tue Oct  5 11:51:01 2004
From: daubin at actuality-systems.com (Dave Aubin)
Date: Tue Oct  5 11:51:01 2004
Subject: Testbios help with nvidia 6800Gt and simple how to
Message-ID: <E8F8DBCB0468204E856114A2CD20741F2C1712@mail.local.ActualitySystems.com>

Found the answer.

It seems my dd returned an unusable binary.  I found a good binary for
The nvidia card from here:
http://whitebunny.demon.nl/hardware/chipset_nvidia.html

Seems they use a windows tool to retrieve the rom.  Perhaps with this
Card being so new this was the problem I was having.  In any even
My GeForce 6800GT now works under Linux bios:)

Hope this helps someone.

-----Original Message-----
From: linuxbios-admin at clustermatic.org
[mailto:linuxbios-admin at clustermatic.org] On Behalf Of Dave Aubin
Sent: Tuesday, October 05, 2004 10:01 AM
To: linuxbios at clustermatic.org
Subject: Testbios help with nvidia 6800Gt and simple how to

Hello,
 
  I'm trying to get an nvidia 6800 Gt video card to work with linuxbios,
but I am coming up short.  Below is a mini how to with test bios and I
did follow the steps, but it still doesn't work.  Can someone please
help me?  
  I did the exact same steps with an nvidia5950 and it worked great.  
Is there something I am missing?
 
Simple Test Bios How to.
 
Purpose:  Testbios provides an i386 emulator for programming the video
bios.
 
How to:  First you need to retrieve the video bios from a machine booted
up with a commercial bios running linux.  Then once that is done you can
execute the bios by using testbios.  
 
How to retrieve video bios
1.  Boot up machine with commercial bios in to a linux environment 2.
dd if=/dev/mem of=vgabios.bin skip=1536 count=128 from a terminal window
    A.  This copies the video bios out of /dev/mem and places it in
vgabios.bin
 
How to execute testbios
1.  Boot up machine with Linuxbios in to a linux environment 2.  run
testbios --abseg /dev/mem -s 65536 /root/vgabios.bin
    A.  If working you should see the video bios welcome message on the
screen
 
 
Thanks,
Dave:)
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From rsmith at bitworks.com  Tue Oct  5 12:58:01 2004
From: rsmith at bitworks.com (Richard Smith)
Date: Tue Oct  5 12:58:01 2004
Subject: Testbios help with nvidia 6800Gt and simple how to
In-Reply-To: <E8F8DBCB0468204E856114A2CD20741F2C1712@mail.local.ActualitySystems.com>
References: <E8F8DBCB0468204E856114A2CD20741F2C1712@mail.local.ActualitySystems.com>
Message-ID: <4162E4C6.5040306@bitworks.com>

Dave Aubin wrote:

> It seems my dd returned an unusable binary.  I found a good binary for
> The nvidia card from here:
> http://whitebunny.demon.nl/hardware/chipset_nvidia.html
> 

I was wondering about your dd command that but I had not had a chance to 
respond yet.

This is what I use:

dd if=/dev/mem of=vbios.bin bs=1k count=64 skip=786432

That will rip the bios from 0x0c0000.  You can verify that you actually 
have bios there with

  'hd -s 0x0c0000 -n 256 /dev/mem'

in some cases it may be located at 0x0e0000 rather than 0x0c0000.

It should start with the 0x55aa (Little endian) or 0xaa55 (big endian) 
and futher on you should see some text identifying the bios.


-- 
Richard A. Smith




From daubin at actuality-systems.com  Tue Oct  5 13:04:00 2004
From: daubin at actuality-systems.com (Dave Aubin)
Date: Tue Oct  5 13:04:00 2004
Subject: Testbios help with nvidia 6800Gt and simple how to
Message-ID: <E8F8DBCB0468204E856114A2CD20741F2C1719@mail.local.ActualitySystems.com>

Hi,

  Thank you:)  Yes, it was at 0xc0000-0xc7fff, which is only 32k.
But the image I got from the windows tool was 64k (double 8000).
Weird.  I would like to stay away from window tools.
  The info you provided is nice.  I wish there was a way for us
To make a faq and we could add this to the testbios faq.  There
Is a lot of good info on the clustermatic list, but it is all
Dispersed.  
  Ron if I write a simple faq can you provide some mechanism to 
Allow updates to it?

Thanks,
Dave 

-----Original Message-----
From: Richard Smith [mailto:rsmith at bitworks.com] 
Sent: Tuesday, October 05, 2004 2:16 PM
To: Dave Aubin
Cc: linuxbios at clustermatic.org
Subject: Re: Testbios help with nvidia 6800Gt and simple how to

Dave Aubin wrote:

> It seems my dd returned an unusable binary.  I found a good binary for

> The nvidia card from here:
> http://whitebunny.demon.nl/hardware/chipset_nvidia.html
> 

I was wondering about your dd command that but I had not had a chance to
respond yet.

This is what I use:

dd if=/dev/mem of=vbios.bin bs=1k count=64 skip=786432

That will rip the bios from 0x0c0000.  You can verify that you actually
have bios there with

  'hd -s 0x0c0000 -n 256 /dev/mem'

in some cases it may be located at 0x0e0000 rather than 0x0c0000.

It should start with the 0x55aa (Little endian) or 0xaa55 (big endian)
and futher on you should see some text identifying the bios.


-- 
Richard A. Smith




From jmiller at actuality-systems.com  Tue Oct  5 13:22:00 2004
From: jmiller at actuality-systems.com (Jay Miller)
Date: Tue Oct  5 13:22:00 2004
Subject: Adding a PCI device that doesn't exist (yet)
Message-ID: <E8F8DBCB0468204E856114A2CD20741F2C171C@mail.local.ActualitySystems.com>

Hi All,

The PCI interface to our "special sauce" is an FPGA that we're
programming after the OS boots.  The hardware doesn't have PCI hot-plug
support, which means we're forced to reboot after programming in order
to re-enumerate the bus in BIOS.  Or are we?

I was thinking of replacing the default scan_bus method with one that
calls the default method for most devices and inserts the non-existent
device information into the table at the appropriate time.

Has anyone been successful at this sort of thing?

Cheers,

Jay Miller
781-229-7812x117
Actuality Systems, Inc.
jmiller at actuality-systems.com




From Trellix78 at aol.com  Tue Oct  5 13:27:01 2004
From: Trellix78 at aol.com (Trellix78 at aol.com)
Date: Tue Oct  5 13:27:01 2004
Subject: ebox-II SiS 550 flash_rom
Message-ID: <0C6C9FDF.133DD5DD.029B16BB@aol.com>

I've been trying to get freebios V1 to work with an
ebox-II board that I have have.  It has the SiS 550 northsouthbridge
and some other cool stuff.  However, flash_rom refuses to recognize
the ROM chip or write to it.  Is there a flash_rom version that'll work
or do I have to modify the version that I currently have?

Thanks...
David


From YhLu at tyan.com  Tue Oct  5 13:57:01 2004
From: YhLu at tyan.com (YhLu)
Date: Tue Oct  5 13:57:01 2004
Subject: Adding a PCI device that doesn't exist (yet)
Message-ID: <3174569B9743D511922F00A0C94314230665AC25@TYANWEB>

Can you for the FPGA programming in the auto.c and issue an soft_reset in
auto.c?

YH

-----Original Message-----
From: Jay Miller [mailto:jmiller at actuality-systems.com] 
Sent: Tuesday, October 05, 2004 11:39 AM
To: linuxbios at clustermatic.org
Subject: Adding a PCI device that doesn't exist (yet)


Hi All,

The PCI interface to our "special sauce" is an FPGA that we're
programming after the OS boots.  The hardware doesn't have PCI hot-plug
support, which means we're forced to reboot after programming in order
to re-enumerate the bus in BIOS.  Or are we?

I was thinking of replacing the default scan_bus method with one that
calls the default method for most devices and inserts the non-existent
device information into the table at the appropriate time.

Has anyone been successful at this sort of thing?

Cheers,

Jay Miller
781-229-7812x117
Actuality Systems, Inc.
jmiller at actuality-systems.com


_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From daubin at actuality-systems.com  Tue Oct  5 14:02:01 2004
From: daubin at actuality-systems.com (Dave Aubin)
Date: Tue Oct  5 14:02:01 2004
Subject: Testbios help with nvidia 6800Gt and simple how to
Message-ID: <E8F8DBCB0468204E856114A2CD20741F2C1723@mail.local.ActualitySystems.com>

I've taken the time to put together a simple testbios faq.
I hope it is helpful.  Feedback and additions are welcome.

Thanks,
Dave

Testbios (vgabios) Faq

Date: 10/5/2004
Author(s): David Aubin 	daubin at actuality-systems.com

Purpose:  Testbios is an i386 emulator that sits on top of user
space linux.  It's primary purpose is to provide program video rom's in
to
the cached memory area.

Faq Contents:
1.  Where to obtain testbios
2.  Prerequisites
3.  How to build testbios
4.  How to retrieve a good video bios
5.  How to use testbios

1.  Where to obtain testbios
	A. Testbios(vgabios) can be retrieved from the
linuxbios/freebios source tree:
http://www.linuxbios.org/developer/download/index.html

2.  Prerequisites
	A. You must have installed pci-utils
		i.  Get
http://atrey.karlin.mff.cuni.cz/~mj/pciutils.shtml

3.  How to build testbios:
	A.  cd freebios/util/vgabios
	B.  Edit ./Makefile and fill in the correct values for your
environment
	    I build on a 64 AMD so my makefile looks like this

--Being ./Makefile for x64--
CC       =  gcc
ARCH     := $(shell uname -m | sed -e s,i[3456789]86,i386,)
INCLUDE  =  -I ../pciutils-2.1.11
CFLAGS   =  -Wall -Ix86emu/include -O2 -g $(INCLUDE)

INTOBJS  =  int10.o int15.o int16.o int1a.o inte6.o
OBJECTS  =  testbios.o helper_exec.o helper_mem.o $(INTOBJS)
LDFLAGS  =  -static-libgcc -static

LIBS     =  x86emu/src/x86emu/libx86emu.a
../pciutils-2.1.11/lib/libpci.a

# user space pci is the only option right now.
OBJECTS += pci-userspace.o

ifeq ($(shell if test "$(ARCH)" == "x86_64" ; then echo 1; fi), 1)
        CFLAGS +=-m32 -march=i386
	endif

	all: testbios

	testbios: $(OBJECTS) $(LIBS)
	        $(CC) $(CFLAGS) -o testbios $(OBJECTS) $(LDFLAGS)
$(LIBS)

helper_exec.o: helper_exec.c test.h

x86emu/src/x86emu/libx86emu.a:
        $(MAKE) -C x86emu/src/x86emu/ -f makefile.linux

	clean:
	        $(MAKE) -C x86emu/src/x86emu/ -f makefile.linux clean
	        rm -f *.o *~ testbios

	distclean: clean
	        $(MAKE) -C x86emu/src/x86emu/ -f makefile.linux clean

--End ./Makefile--

	C.  Edit ~vgabios/x86emu/src/x86emu/makefile.linux and fill in
the correct values for your environment
	    I build on a 64 AMD so my makefile looks like this

--Begin ~vgabios/x86emu/src/x86emu/makefile.linux--
########################################################################
#####
#
#						Realmode X86 Emulator
Library
#
#            	Copyright (C) 1996-1999 SciTech Software, Inc.
#
#
========================================================================
#
#  Permission to use, copy, modify, distribute, and sell this software
and
#  its documentation for any purpose is hereby granted without fee,
#  provided that the above copyright notice appear in all copies and
that
#  both that copyright notice and this permission notice appear in
#  supporting documentation, and that the name of the authors not be
used
#  in advertising or publicity pertaining to distribution of the
software
#  without specific, written prior permission.  The authors makes no
#  representations about the suitability of this software for any
purpose.
#  It is provided "as is" without express or implied warranty.
#
#  THE AUTHORS DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
#  INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN
NO
#  EVENT SHALL THE AUTHORS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
#  CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS
OF
#  USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR
#  OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE
OR
#  PERFORMANCE OF THIS SOFTWARE.
#
#
========================================================================
#
# Descripton:   Linux specific makefile for the x86emu library.
#
########################################################################
#####

TARGETLIB = libx86emu.a


OBJS=\
debug.o \
decode.o \
fpu.o \
ops.o \
ops2.o \
prim_ops.o \
sys.o

$(TARGETLIB): $(OBJS)
	ar rv $(TARGETLIB) $(OBJS)

	INCS   = -I. -Ix86emu -I../../include
	CFLAGS += -D__DRIVER__ -DFORCE_POST -D_CEXPORT= -DNO_LONG_LONG
-DDEBUG
	ARCH   := $(shell uname -m | sed -e s,i[3456789]86,i386,)
	ifeq ($(shell if test "$(ARCH)" == "x86_64" ; then echo 1; fi),
1)
	        CFLAGS +=-m32 -march=i386
		endif


.c.o:
#	gcc -m32 -march=i386 -g -O -Wall -c $(CFLAGS) $(INCS) $*.c
	gcc -g -O -Wall -c $(CFLAGS) $(INCS) $*.c

.cpp.o:
#	gcc -m32 -march=i386 -c $(CFLAGS) $(INCS) $*.cpp
	gcc -c $(CFLAGS) $(INCS) $*.cpp

clean:
	rm -f *.a *.o

validate:	validate.o libx86emu.a
	gcc -o validate validate.o -lx86emu -L.

--End ~vgabios/x86emu/src/x86emu/makefile.linux--

	D.  Once built you could have a 32bit testbios executable made.
Depending on your embedded environment you might want to have it built
shared as the above example makes it static.  Just remove -static-libgcc
-static from the LDFLAGS on ./Makefile if you wish to have it built
shared.

4.  How to retrieve a good video bios
	A.  There are sites that have video bios roms on their website.
	    I know of this one for nvidia cards:
	    http://whitebunny.demon.nl/hardware/chipset_nvidia.html
	B.  However you should be able to retrieve your own video bios
as well
	    with linux.
	    i.  Boot up a machine with a commercial bios (not linux
bios) with
	    	the video card you wish to work under linux bios.
	    ii. From the command line enter:
	        dd if=/dev/mem of=vgabios.bin skip=1536 count=128 or 
		dd if=/dev/mem of=vgabios.bin bs=1k count=64 skip=786432

		This assumes you card's bios is cached in 0xc0000.  You
		can see where and how much your card's bios is using by
		doing a cat iomem | grep "Video ROM"

		a.  dd Explained (man dd to learn more):
			1.  if is the location to retrieve from.
			2.  of is the output file (your rom image)
			3.  skip jumps n blocks where the default n is
512 bytes
			4.  count is how many blocks you wish to read
			5.  bs is the block size
	C.  You now have a video bios image

5.  How to use testbios
	A.  Currently testbios only works from user space linux
(10/4/04)
	B.  Example from a linux command line or script enter the
following to
	    get your video bios programmed:
	    ./testbios -s 65536 --abseg /dev/mem ./vgabios.bin
	    i. Testbios explained
	    	a.  -s <size> how much of the video bios is there
		b.  --abseg where would you like to write this (/dev/mem
default)
		c.  filename of video bios
		d.  -d diag mode <pci busdevfn>
			1.  How to get pci busdevfn
				A.  lspci
				B.  look for your video card
					Example:
					2:00:00
					2 (00 << 3) | 00 = 0x200
					Example:
					00:12.0:
					0 (12 << 3) | 0 = 0x90
		e. -t dump 
		f. -c codesegment Where do you want to start, default is
0xc0000
		g. -b base  Where do you want base to be default is
0xc000
		h. -i instruction pointer usually left off as the
default



-----Original Message-----
From: linuxbios-admin at clustermatic.org
[mailto:linuxbios-admin at clustermatic.org] On Behalf Of Dave Aubin
Sent: Tuesday, October 05, 2004 2:22 PM
To: Richard Smith
Cc: linuxbios at clustermatic.org
Subject: RE: Testbios help with nvidia 6800Gt and simple how to

Hi,

  Thank you:)  Yes, it was at 0xc0000-0xc7fff, which is only 32k.
But the image I got from the windows tool was 64k (double 8000).
Weird.  I would like to stay away from window tools.
  The info you provided is nice.  I wish there was a way for us To make
a faq and we could add this to the testbios faq.  There Is a lot of good
info on the clustermatic list, but it is all Dispersed.  
  Ron if I write a simple faq can you provide some mechanism to Allow
updates to it?

Thanks,
Dave 

-----Original Message-----
From: Richard Smith [mailto:rsmith at bitworks.com]
Sent: Tuesday, October 05, 2004 2:16 PM
To: Dave Aubin
Cc: linuxbios at clustermatic.org
Subject: Re: Testbios help with nvidia 6800Gt and simple how to

Dave Aubin wrote:

> It seems my dd returned an unusable binary.  I found a good binary for

> The nvidia card from here:
> http://whitebunny.demon.nl/hardware/chipset_nvidia.html
> 

I was wondering about your dd command that but I had not had a chance to
respond yet.

This is what I use:

dd if=/dev/mem of=vbios.bin bs=1k count=64 skip=786432

That will rip the bios from 0x0c0000.  You can verify that you actually
have bios there with

  'hd -s 0x0c0000 -n 256 /dev/mem'

in some cases it may be located at 0x0e0000 rather than 0x0c0000.

It should start with the 0x55aa (Little endian) or 0xaa55 (big endian)
and futher on you should see some text identifying the bios.


--
Richard A. Smith


_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From rsmith at bitworks.com  Tue Oct  5 14:44:01 2004
From: rsmith at bitworks.com (Richard Smith)
Date: Tue Oct  5 14:44:01 2004
Subject: Testbios help with nvidia 6800Gt and simple how to
In-Reply-To: <E8F8DBCB0468204E856114A2CD20741F2C1723@mail.local.ActualitySystems.com>
References: <E8F8DBCB0468204E856114A2CD20741F2C1723@mail.local.ActualitySystems.com>
Message-ID: <4162FD79.50501@bitworks.com>

Dave Aubin wrote:

> 	    	the video card you wish to work under linux bios.
> 	    ii. From the command line enter:
> 	        dd if=/dev/mem of=vgabios.bin skip=1536 count=128 or 
> 		dd if=/dev/mem of=vgabios.bin bs=1k count=64 skip=786432
> 

Oop. Thinko. My line is jacked up. should be for bs=1k skip=768. 
skip=786432 is for a block size of 1 byte.


-- 
Richard A. Smith




From daubin at actuality-systems.com  Tue Oct  5 14:49:00 2004
From: daubin at actuality-systems.com (Dave Aubin)
Date: Tue Oct  5 14:49:00 2004
Subject: Testbios help with nvidia 6800Gt and simple how to
Message-ID: <E8F8DBCB0468204E856114A2CD20741F2C172D@mail.local.ActualitySystems.com>

Ron,

  Please change my second example in the testbios faq to
Reflect Richard's change please.

Thanks,
Dave:) 

-----Original Message-----
From: Richard Smith [mailto:rsmith at bitworks.com] 
Sent: Tuesday, October 05, 2004 4:01 PM
To: Dave Aubin
Cc: linuxbios at clustermatic.org
Subject: Re: Testbios help with nvidia 6800Gt and simple how to

Dave Aubin wrote:

> 	    	the video card you wish to work under linux bios.
> 	    ii. From the command line enter:
> 	        dd if=/dev/mem of=vgabios.bin skip=1536 count=128 or 
> 		dd if=/dev/mem of=vgabios.bin bs=1k count=64 skip=786432
> 

Oop. Thinko. My line is jacked up. should be for bs=1k skip=768. 
skip=786432 is for a block size of 1 byte.


--
Richard A. Smith




From rminnich at lanl.gov  Tue Oct  5 14:55:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Tue Oct  5 14:55:01 2004
Subject: 2 questions
Message-ID: <Pine.LNX.4.58.0410051411030.25356@linux.site>

i855GM/GMCH. I set up the registers, set up the MODE for a NOP, and on the 
first read, the whole thing hangs. Suggestions for what to do next, anyone 
:-0)


Anybody seen good PC/104 or biscuit format Power PC systems? I'm getting a 
little tired of dealing with the intel side of the house, because the docs 
are so sparse nowadays. Pointers welcome. PPC 405 is no good: no floating 
point.

thanks

ron


From gwatson at lanl.gov  Wed Oct  6 09:07:00 2004
From: gwatson at lanl.gov (Greg Watson)
Date: Wed Oct  6 09:07:00 2004
Subject: 2 questions
In-Reply-To: <Pine.LNX.4.58.0410051411030.25356@linux.site>
References: <Pine.LNX.4.58.0410051411030.25356@linux.site>
Message-ID: <68DCFF9C-17A3-11D9-98DC-000D932F4B4A@lanl.gov>

On Oct 5, 2004, at 2:12 PM, Ronald G. Minnich wrote:

>
> i855GM/GMCH. I set up the registers, set up the MODE for a NOP, and on 
> the
> first read, the whole thing hangs. Suggestions for what to do next, 
> anyone
> :-0)
>
>
> Anybody seen good PC/104 or biscuit format Power PC systems? I'm 
> getting a
> little tired of dealing with the intel side of the house, because the 
> docs
> are so sparse nowadays. Pointers welcome. PPC 405 is no good: no 
> floating
> point.

http://www.cowboyindustries.com is supposed to have done a PC104+ board 
with the G4 (MPC7400) and G3(MPC750) processors, but I can't find 
anything useful on their web site. It might be worth an email. See here 
also: http://linuxdevices.com/news/NS9893837137.html

Greg



From linuxbios at xdr.com  Wed Oct  6 09:19:01 2004
From: linuxbios at xdr.com (Dave Ashley)
Date: Wed Oct  6 09:19:01 2004
Subject: NXTV job posting
Message-ID: <200410061436.i96Eas3G030659@xdr.com>

Sorry about posting this here but I think it might make sense seeing as NXTV
is a linuxbios friendly company.

http://www.xdr.com/nxtv-job.html

-Dave
PS The site + emails really represent nxtv.com, it is just easier to use
my personal website for this.


From rminnich at lanl.gov  Wed Oct  6 10:59:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Wed Oct  6 10:59:00 2004
Subject: Testbios help with nvidia 6800Gt and simple how to
In-Reply-To: <E8F8DBCB0468204E856114A2CD20741F2C1719@mail.local.ActualitySystems.com>
References: <E8F8DBCB0468204E856114A2CD20741F2C1719@mail.local.ActualitySystems.com>
Message-ID: <Pine.LNX.4.58.0410061015570.28652@linux.site>


On Tue, 5 Oct 2004, Dave Aubin wrote:

>   Ron if I write a simple faq can you provide some mechanism to 
> Allow updates to it?

if you can help stefan and me set up twiki at openbios.org, that's one 
choice; else I will put your faq on the current linuxbios web page.

ron


From rminnich at lanl.gov  Wed Oct  6 11:04:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Wed Oct  6 11:04:00 2004
Subject: NXTV job posting [PMX:#]
In-Reply-To: <200410061436.i96Eas3G030659@xdr.com>
References: <200410061436.i96Eas3G030659@xdr.com>
Message-ID: <Pine.LNX.4.58.0410061021030.28652@linux.site>


On Wed, 6 Oct 2004, Dave Ashley wrote:

> Sorry about posting this here but I think it might make sense seeing as NXTV
> is a linuxbios friendly company.
> 
> http://www.xdr.com/nxtv-job.html
> 
> -Dave

speaking as the owner of the list, I think this is fine. People ask me all 
the time about such positions.

ron


From rminnich at lanl.gov  Wed Oct  6 11:06:09 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Wed Oct  6 11:06:09 2004
Subject: ebox-II SiS 550 flash_rom
In-Reply-To: <0C6C9FDF.133DD5DD.029B16BB@aol.com>
References: <0C6C9FDF.133DD5DD.029B16BB@aol.com>
Message-ID: <Pine.LNX.4.58.0410061021340.28652@linux.site>


On Tue, 5 Oct 2004 Trellix78 at aol.com wrote:

> I've been trying to get freebios V1 to work with an
> ebox-II board that I have have.  It has the SiS 550 northsouthbridge
> and some other cool stuff.  However, flash_rom refuses to recognize
> the ROM chip or write to it.  Is there a flash_rom version that'll work
> or do I have to modify the version that I currently have?

what chip is it?

ron


From rminnich at lanl.gov  Wed Oct  6 11:32:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Wed Oct  6 11:32:00 2004
Subject: Testbios help with nvidia 6800Gt and simple how to
In-Reply-To: <E8F8DBCB0468204E856114A2CD20741F2C1723@mail.local.ActualitySystems.com>
References: <E8F8DBCB0468204E856114A2CD20741F2C1723@mail.local.ActualitySystems.com>
Message-ID: <Pine.LNX.4.58.0410061049440.28652@linux.site>

Dave, your faq is now featured on linuxbios.org

ron
p.s. I screwed up the news page somehow, don't worry about it.



From jmiller at actuality-systems.com  Wed Oct  6 11:54:00 2004
From: jmiller at actuality-systems.com (Jay Miller)
Date: Wed Oct  6 11:54:00 2004
Subject: Adding a PCI device that doesn't exist (yet)
Message-ID: <E8F8DBCB0468204E856114A2CD20741F2C1769@mail.local.ActualitySystems.com>

Thanks for your help.  Certainly that's not ideal, but it may turn out
to be our only option.

Currently I'm investigating using proc_pci_attach_device() at the kernel
level to add the device from the driver module init(post-program), but
it's not looking promising.

Thanks,

Jay Miller
781-229-7812x117
Actuality Systems, Inc.
jmiller at actuality-systems.com


-----Original Message-----
From: Ronald G. Minnich [mailto:rminnich at lanl.gov] 
Sent: Wednesday, October 06, 2004 12:23 PM
To: YhLu
Cc: Jay Miller; linuxbios at clustermatic.org
Subject: RE: Adding a PCI device that doesn't exist (yet)



On Tue, 5 Oct 2004, YhLu wrote:

> Can you for the FPGA programming in the auto.c and issue an soft_reset
in
> auto.c?

I think this can work with the current mechanisms. You need to have your

chip programmed pre-pci-scan, and the current config mechanism supports 
that fine. 


Is this V1 or V2, I forget.

ron


From rminnich at lanl.gov  Wed Oct  6 12:03:03 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Wed Oct  6 12:03:03 2004
Subject: Adding a PCI device that doesn't exist (yet)
In-Reply-To: <3174569B9743D511922F00A0C94314230665AC25@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665AC25@TYANWEB>
Message-ID: <Pine.LNX.4.58.0410061022020.28652@linux.site>


On Tue, 5 Oct 2004, YhLu wrote:

> Can you for the FPGA programming in the auto.c and issue an soft_reset in
> auto.c?

I think this can work with the current mechanisms. You need to have your 
chip programmed pre-pci-scan, and the current config mechanism supports 
that fine. 


Is this V1 or V2, I forget.

ron


From rminnich at lanl.gov  Wed Oct  6 12:06:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Wed Oct  6 12:06:01 2004
Subject: Adding a PCI device that doesn't exist (yet)
In-Reply-To: <E8F8DBCB0468204E856114A2CD20741F2C1769@mail.local.ActualitySystems.com>
References: <E8F8DBCB0468204E856114A2CD20741F2C1769@mail.local.ActualitySystems.com>
Message-ID: <Pine.LNX.4.58.0410061122200.28652@linux.site>


On Wed, 6 Oct 2004, Jay Miller wrote:

> Thanks for your help.  Certainly that's not ideal, but it may turn out
> to be our only option.


the reason being you don't want to embed the bitstream in linuxbios, 
right? 

Are you sure that you can't take advantage of the hotplug stuff in 2.6 for 
your device? Is your device a bridge or ...

ron


From jmiller at actuality-systems.com  Wed Oct  6 12:15:00 2004
From: jmiller at actuality-systems.com (Jay Miller)
Date: Wed Oct  6 12:15:00 2004
Subject: Adding a PCI device that doesn't exist (yet)
Message-ID: <E8F8DBCB0468204E856114A2CD20741F2C176D@mail.local.ActualitySystems.com>

Exactly!

No, it's not a bridge.  It's just a card, but I was under the impression
that you needed hardware support for hotplug?

Dave Aubin had been looking at this and he concluded that without
hardware support there needed to be some enumeration present at the time
the Linux kernel loads.  Presumably this would be provided by the BIOS.

This is why I was looking at some way to force an entry into the bus
scan of LinuxBIOS, thus providing the enumeration that the hotplug
kernel would need.

Jay Miller
781-229-7812x117
Actuality Systems, Inc.
jmiller at actuality-systems.com


-----Original Message-----
From: Ronald G. Minnich [mailto:rminnich at lanl.gov] 
Sent: Wednesday, October 06, 2004 1:23 PM
To: Jay Miller
Cc: YhLu; linuxbios at clustermatic.org
Subject: RE: Adding a PCI device that doesn't exist (yet)



On Wed, 6 Oct 2004, Jay Miller wrote:

> Thanks for your help.  Certainly that's not ideal, but it may turn out
> to be our only option.


the reason being you don't want to embed the bitstream in linuxbios, 
right? 

Are you sure that you can't take advantage of the hotplug stuff in 2.6
for 
your device? Is your device a bridge or ...

ron


From daubin at actuality-systems.com  Wed Oct  6 12:25:01 2004
From: daubin at actuality-systems.com (Dave Aubin)
Date: Wed Oct  6 12:25:01 2004
Subject: Adding a PCI device that doesn't exist (yet)
Message-ID: <E8F8DBCB0468204E856114A2CD20741F2C176E@mail.local.ActualitySystems.com>

Yes, hotplug in 2.6 would be excellent, but in order to
Make the device hotplug it needs to show up the /sys/bus/pci...
Power entry.  I'm not sure how to make that happen.
If it did then all things would be great.  

Thanks,
Dave 

-----Original Message-----
From: linuxbios-admin at clustermatic.org
[mailto:linuxbios-admin at clustermatic.org] On Behalf Of Ronald G. Minnich
Sent: Wednesday, October 06, 2004 1:23 PM
To: Jay Miller
Cc: YhLu; linuxbios at clustermatic.org
Subject: RE: Adding a PCI device that doesn't exist (yet)



On Wed, 6 Oct 2004, Jay Miller wrote:

> Thanks for your help.  Certainly that's not ideal, but it may turn out

> to be our only option.


the reason being you don't want to embed the bitstream in linuxbios,
right? 

Are you sure that you can't take advantage of the hotplug stuff in 2.6
for your device? Is your device a bridge or ...

ron
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From tyson at irobot.com  Wed Oct  6 12:34:00 2004
From: tyson at irobot.com (tyson at irobot.com)
Date: Wed Oct  6 12:34:00 2004
Subject: Adding a PCI device that doesn't exist (yet)
In-Reply-To: <E8F8DBCB0468204E856114A2CD20741F2C1769@mail.local.ActualitySystems.com>
References: <E8F8DBCB0468204E856114A2CD20741F2C1769@mail.local.ActualitySystems.com>
Message-ID: <416430C1.7050508@irobot.com>

Hopping in mid-thread here so I may have the context wrong:

I have succeeded at programming the FPGA to create a PCI device after 
the boot process.  I was then able to have the device driver add the 
device to the pci device table and get resources allocated for it and 
get it paired up with the alread loaded device driver.

I did not figure out how to de-allocate/de-register such that I could 
cleanely re-program the FPGA without a re-boot.

Is this relevant?

Cheers!
Ty


Jay Miller wrote:
> Thanks for your help.  Certainly that's not ideal, but it may turn out
> to be our only option.
> 
> Currently I'm investigating using proc_pci_attach_device() at the kernel
> level to add the device from the driver module init(post-program), but
> it's not looking promising.
> 
> Thanks,
> 
> Jay Miller
> 781-229-7812x117
> Actuality Systems, Inc.
> jmiller at actuality-systems.com
> 
> 
> -----Original Message-----
> From: Ronald G. Minnich [mailto:rminnich at lanl.gov] 
> Sent: Wednesday, October 06, 2004 12:23 PM
> To: YhLu
> Cc: Jay Miller; linuxbios at clustermatic.org
> Subject: RE: Adding a PCI device that doesn't exist (yet)
> 
> 
> 
> On Tue, 5 Oct 2004, YhLu wrote:
> 
> 
>>Can you for the FPGA programming in the auto.c and issue an soft_reset
> 
> in
> 
>>auto.c?
> 
> 
> I think this can work with the current mechanisms. You need to have your
> 
> chip programmed pre-pci-scan, and the current config mechanism supports 
> that fine. 
> 
> 
> Is this V1 or V2, I forget.
> 
> ron
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios


-- 
Tyson D Sawyer                     iRobot Corporation
Lead Systems Engineer              Government & Industrial Robotics
tsawyer at irobot.com                 Robots for the Real World
781-345-0200 ext 3329              http://www.irobot.com



From daubin at actuality-systems.com  Wed Oct  6 12:51:01 2004
From: daubin at actuality-systems.com (Dave Aubin)
Date: Wed Oct  6 12:51:01 2004
Subject: Adding a PCI device that doesn't exist (yet)
Message-ID: <E8F8DBCB0468204E856114A2CD20741F2C1772@mail.local.ActualitySystems.com>

Hi Ty,

  Please tell:)  What approach did you use to create the pci 
Device after boot?  

Thanks,
Dave:) 

-----Original Message-----
From: linuxbios-admin at clustermatic.org
[mailto:linuxbios-admin at clustermatic.org] On Behalf Of tyson at irobot.com
Sent: Wednesday, October 06, 2004 1:52 PM
To: Jay Miller
Cc: Ronald G. Minnich; YhLu; linuxbios at clustermatic.org
Subject: Re: Adding a PCI device that doesn't exist (yet)

Hopping in mid-thread here so I may have the context wrong:

I have succeeded at programming the FPGA to create a PCI device after
the boot process.  I was then able to have the device driver add the
device to the pci device table and get resources allocated for it and
get it paired up with the alread loaded device driver.

I did not figure out how to de-allocate/de-register such that I could
cleanely re-program the FPGA without a re-boot.

Is this relevant?

Cheers!
Ty


Jay Miller wrote:
> Thanks for your help.  Certainly that's not ideal, but it may turn out

> to be our only option.
> 
> Currently I'm investigating using proc_pci_attach_device() at the 
> kernel level to add the device from the driver module 
> init(post-program), but it's not looking promising.
> 
> Thanks,
> 
> Jay Miller
> 781-229-7812x117
> Actuality Systems, Inc.
> jmiller at actuality-systems.com
> 
> 
> -----Original Message-----
> From: Ronald G. Minnich [mailto:rminnich at lanl.gov]
> Sent: Wednesday, October 06, 2004 12:23 PM
> To: YhLu
> Cc: Jay Miller; linuxbios at clustermatic.org
> Subject: RE: Adding a PCI device that doesn't exist (yet)
> 
> 
> 
> On Tue, 5 Oct 2004, YhLu wrote:
> 
> 
>>Can you for the FPGA programming in the auto.c and issue an soft_reset
> 
> in
> 
>>auto.c?
> 
> 
> I think this can work with the current mechanisms. You need to have 
> your
> 
> chip programmed pre-pci-scan, and the current config mechanism 
> supports that fine.
> 
> 
> Is this V1 or V2, I forget.
> 
> ron
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios


-- 
Tyson D Sawyer                     iRobot Corporation
Lead Systems Engineer              Government & Industrial Robotics
tsawyer at irobot.com                 Robots for the Real World
781-345-0200 ext 3329              http://www.irobot.com

_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From jmiller at actuality-systems.com  Wed Oct  6 12:56:01 2004
From: jmiller at actuality-systems.com (Jay Miller)
Date: Wed Oct  6 12:56:01 2004
Subject: Adding a PCI device that doesn't exist (yet)
Message-ID: <E8F8DBCB0468204E856114A2CD20741F2C1773@mail.local.ActualitySystems.com>

Thanks Ty, that's exactly what we're looking for.  The de-allocation
wouldn't be an issue as we would be re-programming on the reboot anyway.

Did you use the proc_pci_attach_device() mechanism?

Cheers,

Jay Miller
781-229-7812x117
Actuality Systems, Inc.
jmiller at actuality-systems.com


-----Original Message-----
From: tyson at irobot.com [mailto:tyson at irobot.com] 
Sent: Wednesday, October 06, 2004 1:52 PM
To: Jay Miller
Cc: Ronald G. Minnich; YhLu; linuxbios at clustermatic.org
Subject: Re: Adding a PCI device that doesn't exist (yet)

Hopping in mid-thread here so I may have the context wrong:

I have succeeded at programming the FPGA to create a PCI device after 
the boot process.  I was then able to have the device driver add the 
device to the pci device table and get resources allocated for it and 
get it paired up with the alread loaded device driver.

I did not figure out how to de-allocate/de-register such that I could 
cleanely re-program the FPGA without a re-boot.

Is this relevant?

Cheers!
Ty


Jay Miller wrote:
> Thanks for your help.  Certainly that's not ideal, but it may turn out
> to be our only option.
> 
> Currently I'm investigating using proc_pci_attach_device() at the
kernel
> level to add the device from the driver module init(post-program), but
> it's not looking promising.
> 
> Thanks,
> 
> Jay Miller
> 781-229-7812x117
> Actuality Systems, Inc.
> jmiller at actuality-systems.com
> 
> 
> -----Original Message-----
> From: Ronald G. Minnich [mailto:rminnich at lanl.gov] 
> Sent: Wednesday, October 06, 2004 12:23 PM
> To: YhLu
> Cc: Jay Miller; linuxbios at clustermatic.org
> Subject: RE: Adding a PCI device that doesn't exist (yet)
> 
> 
> 
> On Tue, 5 Oct 2004, YhLu wrote:
> 
> 
>>Can you for the FPGA programming in the auto.c and issue an soft_reset
> 
> in
> 
>>auto.c?
> 
> 
> I think this can work with the current mechanisms. You need to have
your
> 
> chip programmed pre-pci-scan, and the current config mechanism
supports 
> that fine. 
> 
> 
> Is this V1 or V2, I forget.
> 
> ron
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios


-- 
Tyson D Sawyer                     iRobot Corporation
Lead Systems Engineer              Government & Industrial Robotics
tsawyer at irobot.com                 Robots for the Real World
781-345-0200 ext 3329              http://www.irobot.com



From tyson at irobot.com  Wed Oct  6 13:17:01 2004
From: tyson at irobot.com (tyson at irobot.com)
Date: Wed Oct  6 13:17:01 2004
Subject: Adding a PCI device that doesn't exist (yet)
In-Reply-To: <E8F8DBCB0468204E856114A2CD20741F2C1773@mail.local.ActualitySystems.com>
References: <E8F8DBCB0468204E856114A2CD20741F2C1773@mail.local.ActualitySystems.com>
Message-ID: <41643AC5.4010700@irobot.com>

Jay Miller wrote:
> Thanks Ty, that's exactly what we're looking for.  The de-allocation
> wouldn't be an issue as we would be re-programming on the reboot anyway.
> 
> Did you use the proc_pci_attach_device() mechanism?
> 
> Cheers,
> 
> Jay Miller
> 781-229-7812x117
> Actuality Systems, Inc.
> jmiller at actuality-systems.com
> 
> 
> -----Original Message-----
> From: tyson at irobot.com [mailto:tyson at irobot.com] 
> Sent: Wednesday, October 06, 2004 1:52 PM
> To: Jay Miller
> Cc: Ronald G. Minnich; YhLu; linuxbios at clustermatic.org
> Subject: Re: Adding a PCI device that doesn't exist (yet)
> 
> Hopping in mid-thread here so I may have the context wrong:
> 
> I have succeeded at programming the FPGA to create a PCI device after 
> the boot process.  I was then able to have the device driver add the 
> device to the pci device table and get resources allocated for it and 
> get it paired up with the alread loaded device driver.
> 
> I did not figure out how to de-allocate/de-register such that I could 
> cleanely re-program the FPGA without a re-boot.
> 
> Is this relevant?
> 
> Cheers!
> Ty

It is only a specific variation of this device that needed this code so 
it is hacked in by conditionally including the header file below into a 
.c file.  Crufty code organization, but now you know.

This was made to work by having user level initialization scripts 
program the FPGA before loading the device driver.  The first thing that 
the device driver did in its init function was call the function below. 
  This is working code as it sits.  The things like 
"PCI_VENDOR_ID_IROBOT" are our own local hacks and defines.  Things like 
"list_for_each_safe() come from the kernel headers.  I think that 
<linux/pci.h> was all I needed for this part of the code but it might be 
dependent on others as well.

I'd be happy to attempt to answer specific questions, but I think 
everything needed is here.  I figured this out thought a lot of grepping 
and "use the source Luke!".

Cheers!
Ty

===================================================================
/*
  * neolink2.h
  */

#define PCI_FNBUS   0
#define PCI_FNSLOT 16
#define PCI_FNFUNC  0

static int __init neolink2_init(void)
{
   struct list_head *list, *list_tmp;
   struct pci_bus *bus;
   struct pci_dev dev, *dev1;

   if (pci_find_device(PCI_VENDOR_ID_IROBOT, PCI_DEVICE_ID_IROBOT_FN2A, 
NULL)) {
     printk("%6d:%s:%s() - Device is already initialized\n",
            __LINE__, __FILE__, __FUNCTION__);
     return 0;
   }

   list_for_each_safe(list, list_tmp, &pci_root_buses) {
     bus = pci_bus_b(list);
     if (bus->number == PCI_FNBUS) {
       memset(&dev, 0, sizeof(dev));
       dev.bus = bus;
       dev.sysdata = bus->sysdata;
       dev.devfn = PCI_DEVFN(PCI_FNSLOT, PCI_FNFUNC);
       dev1 = pci_scan_slot(&dev);
       if (!dev1) {
         printk("%6d:%s:%s() - No device found\n",
                __LINE__, __FILE__, __FUNCTION__);
         return -ENODEV;
       }
       else {
         printk("%6d:%s:%s() - Found device %s\n",
                __LINE__, __FILE__, __FUNCTION__, dev1->name);

         pci_set_power_state(dev1, 0);
         pci_assign_resource(dev1, 0);
         pci_enable_device(dev1);
         // pci_announce_device_to_drivers(dev1);
         return 0;
       }
       break;
     }
   }

   printk("%6d:%s:%s() - Bus %d found\n",
          __LINE__, __FILE__, __FUNCTION__, PCI_FNBUS);

   return -ENODEV;
}
=====================================================================


-- 
Tyson D Sawyer                     iRobot Corporation
Lead Systems Engineer              Government & Industrial Robotics
tsawyer at irobot.com                 Robots for the Real World
781-345-0200 ext 3329              http://www.irobot.com



From jmiller at actuality-systems.com  Wed Oct  6 13:22:00 2004
From: jmiller at actuality-systems.com (Jay Miller)
Date: Wed Oct  6 13:22:00 2004
Subject: Adding a PCI device that doesn't exist (yet)
Message-ID: <E8F8DBCB0468204E856114A2CD20741F2C1776@mail.local.ActualitySystems.com>

That's it, thanks so much.  

Guess I'll have to go buy a Roomba now. ;-)

Cheers,

Jay Miller
781-229-7812x117
Actuality Systems, Inc.
jmiller at actuality-systems.com


-----Original Message-----
From: tyson at irobot.com [mailto:tyson at irobot.com] 
Sent: Wednesday, October 06, 2004 2:35 PM
To: Jay Miller
Cc: Ronald G. Minnich; YhLu; linuxbios at clustermatic.org
Subject: Re: Adding a PCI device that doesn't exist (yet)

Jay Miller wrote:
> Thanks Ty, that's exactly what we're looking for.  The de-allocation
> wouldn't be an issue as we would be re-programming on the reboot
anyway.
> 
> Did you use the proc_pci_attach_device() mechanism?
> 
> Cheers,
> 
> Jay Miller
> 781-229-7812x117
> Actuality Systems, Inc.
> jmiller at actuality-systems.com
> 
> 
> -----Original Message-----
> From: tyson at irobot.com [mailto:tyson at irobot.com] 
> Sent: Wednesday, October 06, 2004 1:52 PM
> To: Jay Miller
> Cc: Ronald G. Minnich; YhLu; linuxbios at clustermatic.org
> Subject: Re: Adding a PCI device that doesn't exist (yet)
> 
> Hopping in mid-thread here so I may have the context wrong:
> 
> I have succeeded at programming the FPGA to create a PCI device after 
> the boot process.  I was then able to have the device driver add the 
> device to the pci device table and get resources allocated for it and 
> get it paired up with the alread loaded device driver.
> 
> I did not figure out how to de-allocate/de-register such that I could 
> cleanely re-program the FPGA without a re-boot.
> 
> Is this relevant?
> 
> Cheers!
> Ty

It is only a specific variation of this device that needed this code so 
it is hacked in by conditionally including the header file below into a 
.c file.  Crufty code organization, but now you know.

This was made to work by having user level initialization scripts 
program the FPGA before loading the device driver.  The first thing that

the device driver did in its init function was call the function below. 
  This is working code as it sits.  The things like 
"PCI_VENDOR_ID_IROBOT" are our own local hacks and defines.  Things like

"list_for_each_safe() come from the kernel headers.  I think that 
<linux/pci.h> was all I needed for this part of the code but it might be

dependent on others as well.

I'd be happy to attempt to answer specific questions, but I think 
everything needed is here.  I figured this out thought a lot of grepping

and "use the source Luke!".

Cheers!
Ty

===================================================================
/*
  * neolink2.h
  */

#define PCI_FNBUS   0
#define PCI_FNSLOT 16
#define PCI_FNFUNC  0

static int __init neolink2_init(void)
{
   struct list_head *list, *list_tmp;
   struct pci_bus *bus;
   struct pci_dev dev, *dev1;

   if (pci_find_device(PCI_VENDOR_ID_IROBOT, PCI_DEVICE_ID_IROBOT_FN2A, 
NULL)) {
     printk("%6d:%s:%s() - Device is already initialized\n",
            __LINE__, __FILE__, __FUNCTION__);
     return 0;
   }

   list_for_each_safe(list, list_tmp, &pci_root_buses) {
     bus = pci_bus_b(list);
     if (bus->number == PCI_FNBUS) {
       memset(&dev, 0, sizeof(dev));
       dev.bus = bus;
       dev.sysdata = bus->sysdata;
       dev.devfn = PCI_DEVFN(PCI_FNSLOT, PCI_FNFUNC);
       dev1 = pci_scan_slot(&dev);
       if (!dev1) {
         printk("%6d:%s:%s() - No device found\n",
                __LINE__, __FILE__, __FUNCTION__);
         return -ENODEV;
       }
       else {
         printk("%6d:%s:%s() - Found device %s\n",
                __LINE__, __FILE__, __FUNCTION__, dev1->name);

         pci_set_power_state(dev1, 0);
         pci_assign_resource(dev1, 0);
         pci_enable_device(dev1);
         // pci_announce_device_to_drivers(dev1);
         return 0;
       }
       break;
     }
   }

   printk("%6d:%s:%s() - Bus %d found\n",
          __LINE__, __FILE__, __FUNCTION__, PCI_FNBUS);

   return -ENODEV;
}
=====================================================================


-- 
Tyson D Sawyer                     iRobot Corporation
Lead Systems Engineer              Government & Industrial Robotics
tsawyer at irobot.com                 Robots for the Real World
781-345-0200 ext 3329              http://www.irobot.com



From tyson at irobot.com  Wed Oct  6 13:48:01 2004
From: tyson at irobot.com (tyson at irobot.com)
Date: Wed Oct  6 13:48:01 2004
Subject: Adding a PCI device that doesn't exist (yet)
In-Reply-To: <E8F8DBCB0468204E856114A2CD20741F2C1776@mail.local.ActualitySystems.com>
References: <E8F8DBCB0468204E856114A2CD20741F2C1776@mail.local.ActualitySystems.com>
Message-ID: <4164421B.7020804@irobot.com>

Jay Miller wrote:
> That's it, thanks so much.  
> 
> Guess I'll have to go buy a Roomba now. ;-)

It'll take more than that!  I work on the PackBot systems. :-)

Cheers!
Ty

-- 
Tyson D Sawyer                     iRobot Corporation
Lead Systems Engineer              Government & Industrial Robotics
tsawyer at irobot.com                 Robots for the Real World
781-345-0200 ext 3329              http://www.irobot.com



From tyson at irobot.com  Wed Oct  6 14:14:01 2004
From: tyson at irobot.com (tyson at irobot.com)
Date: Wed Oct  6 14:14:01 2004
Subject: Adding a PCI device that doesn't exist (yet)
In-Reply-To: <4164421B.7020804@irobot.com>
References: <E8F8DBCB0468204E856114A2CD20741F2C1776@mail.local.ActualitySystems.com> <4164421B.7020804@irobot.com>
Message-ID: <4164480F.8010004@irobot.com>

tyson at irobot.com wrote:
> Jay Miller wrote:
> 
>> That's it, thanks so much. 
>> Guess I'll have to go buy a Roomba now. ;-)
> 
> 
> It'll take more than that!  I work on the PackBot systems. :-)
> 
> Cheers!
> Ty
> 

Oh, since I never actually said it, this was on a 2.4 kernel.

Ty

-- 
Tyson D Sawyer                     iRobot Corporation
Lead Systems Engineer              Government & Industrial Robotics
tsawyer at irobot.com                 Robots for the Real World
781-345-0200 ext 3329              http://www.irobot.com



From Trellix78 at aol.com  Wed Oct  6 14:20:00 2004
From: Trellix78 at aol.com (Trellix78 at aol.com)
Date: Wed Oct  6 14:20:00 2004
Subject: ebox-II SiS 550 flash_rom
Message-ID: <148.356ae661.2e95a2fd@aol.com>

chip is a PLCC   Winbond W29C020CP90B
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20041006/961965c8/attachment.html>

From rminnich at lanl.gov  Wed Oct  6 14:22:19 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Wed Oct  6 14:22:19 2004
Subject: Adding a PCI device that doesn't exist (yet)
In-Reply-To: <E8F8DBCB0468204E856114A2CD20741F2C176D@mail.local.ActualitySystems.com>
References: <E8F8DBCB0468204E856114A2CD20741F2C176D@mail.local.ActualitySystems.com>
Message-ID: <Pine.LNX.4.58.0410061336270.28652@linux.site>


On Wed, 6 Oct 2004, Jay Miller wrote:

> No, it's not a bridge.  It's just a card, but I was under the impression
> that you needed hardware support for hotplug?

I've got more reading to do on hotplug, but it seems to me that if you 
have (e.g.) and empty bus slot, and a device appears there, then the 
daemon has to pick up the interrupt for that and start the hotplug 
sequence. In your case, it seems to me a program could run and "make the 
card exist" and then start the hotplug sequence. But I doubt I know what 
I'm talking about.

ron


From rminnich at lanl.gov  Wed Oct  6 14:29:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Wed Oct  6 14:29:00 2004
Subject: ebox-II SiS 550 flash_rom
In-Reply-To: <148.356ae661.2e95a2fd@aol.com>
References: <148.356ae661.2e95a2fd@aol.com>
Message-ID: <Pine.LNX.4.58.0410061346160.28652@linux.site>


On Wed, 6 Oct 2004 Trellix78 at aol.com wrote:

> chip is a PLCC   Winbond W29C020CP90B


I thought that was supported, send me the output of running flash_rom

ron


From daubin at actuality-systems.com  Wed Oct  6 14:39:01 2004
From: daubin at actuality-systems.com (Dave Aubin)
Date: Wed Oct  6 14:39:01 2004
Subject: Adding a PCI device that doesn't exist (yet)
Message-ID: <E8F8DBCB0468204E856114A2CD20741F2C177F@mail.local.ActualitySystems.com>

Very nice:)

Thanks you:):):) 

-----Original Message-----
From: linuxbios-admin at clustermatic.org
[mailto:linuxbios-admin at clustermatic.org] On Behalf Of tyson at irobot.com
Sent: Wednesday, October 06, 2004 2:35 PM
To: Jay Miller
Cc: Ronald G. Minnich; YhLu; linuxbios at clustermatic.org
Subject: Re: Adding a PCI device that doesn't exist (yet)

Jay Miller wrote:
> Thanks Ty, that's exactly what we're looking for.  The de-allocation 
> wouldn't be an issue as we would be re-programming on the reboot
anyway.
> 
> Did you use the proc_pci_attach_device() mechanism?
> 
> Cheers,
> 
> Jay Miller
> 781-229-7812x117
> Actuality Systems, Inc.
> jmiller at actuality-systems.com
> 
> 
> -----Original Message-----
> From: tyson at irobot.com [mailto:tyson at irobot.com]
> Sent: Wednesday, October 06, 2004 1:52 PM
> To: Jay Miller
> Cc: Ronald G. Minnich; YhLu; linuxbios at clustermatic.org
> Subject: Re: Adding a PCI device that doesn't exist (yet)
> 
> Hopping in mid-thread here so I may have the context wrong:
> 
> I have succeeded at programming the FPGA to create a PCI device after 
> the boot process.  I was then able to have the device driver add the 
> device to the pci device table and get resources allocated for it and 
> get it paired up with the alread loaded device driver.
> 
> I did not figure out how to de-allocate/de-register such that I could 
> cleanely re-program the FPGA without a re-boot.
> 
> Is this relevant?
> 
> Cheers!
> Ty

It is only a specific variation of this device that needed this code so
it is hacked in by conditionally including the header file below into a
.c file.  Crufty code organization, but now you know.

This was made to work by having user level initialization scripts
program the FPGA before loading the device driver.  The first thing that
the device driver did in its init function was call the function below. 
  This is working code as it sits.  The things like
"PCI_VENDOR_ID_IROBOT" are our own local hacks and defines.  Things like
"list_for_each_safe() come from the kernel headers.  I think that
<linux/pci.h> was all I needed for this part of the code but it might be
dependent on others as well.

I'd be happy to attempt to answer specific questions, but I think
everything needed is here.  I figured this out thought a lot of grepping
and "use the source Luke!".

Cheers!
Ty

===================================================================
/*
  * neolink2.h
  */

#define PCI_FNBUS   0
#define PCI_FNSLOT 16
#define PCI_FNFUNC  0

static int __init neolink2_init(void)
{
   struct list_head *list, *list_tmp;
   struct pci_bus *bus;
   struct pci_dev dev, *dev1;

   if (pci_find_device(PCI_VENDOR_ID_IROBOT, PCI_DEVICE_ID_IROBOT_FN2A,
NULL)) {
     printk("%6d:%s:%s() - Device is already initialized\n",
            __LINE__, __FILE__, __FUNCTION__);
     return 0;
   }

   list_for_each_safe(list, list_tmp, &pci_root_buses) {
     bus = pci_bus_b(list);
     if (bus->number == PCI_FNBUS) {
       memset(&dev, 0, sizeof(dev));
       dev.bus = bus;
       dev.sysdata = bus->sysdata;
       dev.devfn = PCI_DEVFN(PCI_FNSLOT, PCI_FNFUNC);
       dev1 = pci_scan_slot(&dev);
       if (!dev1) {
         printk("%6d:%s:%s() - No device found\n",
                __LINE__, __FILE__, __FUNCTION__);
         return -ENODEV;
       }
       else {
         printk("%6d:%s:%s() - Found device %s\n",
                __LINE__, __FILE__, __FUNCTION__, dev1->name);

         pci_set_power_state(dev1, 0);
         pci_assign_resource(dev1, 0);
         pci_enable_device(dev1);
         // pci_announce_device_to_drivers(dev1);
         return 0;
       }
       break;
     }
   }

   printk("%6d:%s:%s() - Bus %d found\n",
          __LINE__, __FILE__, __FUNCTION__, PCI_FNBUS);

   return -ENODEV;
}
=====================================================================


-- 
Tyson D Sawyer                     iRobot Corporation
Lead Systems Engineer              Government & Industrial Robotics
tsawyer at irobot.com                 Robots for the Real World
781-345-0200 ext 3329              http://www.irobot.com

_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From daubin at actuality-systems.com  Fri Oct  8 09:17:01 2004
From: daubin at actuality-systems.com (Dave Aubin)
Date: Fri Oct  8 09:17:01 2004
Subject: testbios loops?
Message-ID: <E8F8DBCB0468204E856114A2CD20741F2C1801@mail.local.ActualitySystems.com>

Hi,
 
  I went back to trying to get the Nvida 6800gt card's bios, but still
even with dd -if=/dev/mem of=vgabios.rom skip=786432 bs=1 count=32768
I get the same binary as dd -if=/dev/mem of=vgabios.rom skip=1536
count=64.
I used dhex (free util) to verify they are the same.
  What happens when I run them trough testbios is that once it is done
programming
0xc7fff it jump to 0x9 something or other and the video bios isn't
programmed correctly.
My iomem looks like this:
 

00000000-0009fbff : System RAM
0009fc00-0009ffff : reserved
000a0000-000bffff : Video RAM area
000c0000-000c7fff : Video ROM
000f0000-000fffff : System ROM
00100000-1ffeffff : System RAM
  00100000-002b00be : Kernel code
  002b00bf-003d78bf : Kernel data
1fff0000-1fffefff : ACPI Tables
1ffff000-1fffffff : ACPI Non-volatile Storage
c9f00000-c9ffffff : PCI Bus #01
ca000000-ca0fffff : PCI Bus #02
ca100000-ca1fffff : PCI Bus #03


  Any ideas as to what is wrong?

 

Thanks,

Dave:)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20041008/4b0b70c4/attachment.html>

From stepan at openbios.org  Fri Oct  8 09:31:01 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Fri Oct  8 09:31:01 2004
Subject: testbios loops?
In-Reply-To: <E8F8DBCB0468204E856114A2CD20741F2C1801@mail.local.ActualitySystems.com>
References: <E8F8DBCB0468204E856114A2CD20741F2C1801@mail.local.ActualitySystems.com>
Message-ID: <20041008144914.GB21886@openbios.org>

* Dave Aubin <daubin at actuality-systems.com> [041008 16:35]:
> Hi,
>  
>   I went back to trying to get the Nvida 6800gt card's bios, but still
> even with dd -if=/dev/mem of=vgabios.rom skip=786432 bs=1 count=32768
> I get the same binary as dd -if=/dev/mem of=vgabios.rom skip=1536
> count=64.

Does the bios have a valid pci option rom signature? (55aa plus the
other stuff, see romheaders utility in the openbios tree)

Stefan



From ollie at lanl.gov  Fri Oct  8 09:36:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Fri Oct  8 09:36:00 2004
Subject: testbios loops?
In-Reply-To: <E8F8DBCB0468204E856114A2CD20741F2C1801@mail.local.ActualitySystems.com>
References: 	 <E8F8DBCB0468204E856114A2CD20741F2C1801@mail.local.ActualitySystems.com>
Message-ID: <1097247197.3526.25.camel@exponential.lanl.gov>

On Fri, 2004-10-08 at 08:35, Dave Aubin wrote:
> Hi,
>  
>   I went back to trying to get the Nvida 6800gt card's bios, but still
> even with dd -if=/dev/mem of=vgabios.rom skip=786432 bs=1 count=32768
> I get the same binary as dd -if=/dev/mem of=vgabios.rom skip=1536
> count=64.
> I used dhex (free util) to verify they are the same.
>   What happens when I run them trough testbios is that once it is done
> programming
> 0xc7fff it jump to 0x9 something or other and the video bios isn't
> programmed correctly.


What do you mean by 'programming oxc7ff it jump to 0x9' ?

Ollie




From daubin at actuality-systems.com  Fri Oct  8 09:40:01 2004
From: daubin at actuality-systems.com (Dave Aubin)
Date: Fri Oct  8 09:40:01 2004
Subject: testbios loops?
Message-ID: <E8F8DBCB0468204E856114A2CD20741F2C1803@mail.local.ActualitySystems.com>

Hi,

It will first do this (I'm using the testbios -t option)
c000:fffd 0000                ADD       [BX+SI],AL
        AX=0200  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000  SI=0000
DI=0000
        DS=0040  ES=0000  SS=0030  CS=c000  IP=0002   NV UP DI PL ZR NA
PE NC 
c000:ffff 000000              ADD       -86[DI],DL
        AX=0200  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000  SI=0000
DI=0000
        DS=0040  ES=0000  SS=0030  CS=c000  IP=0004   NV UP DI NG NZ NA
PO NC 
c000:0002 74eb                JZ        ffef
        AX=0200  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000  SI=0000
DI=0000
        DS=0040  ES=0000  SS=0030  CS=c000  IP=0005   NV UP DI NG NZ NA
PO NC 
c000:0004 4b                  DEC       BX
        AX=0200  BX=ffff  CX=0000  DX=0080  SP=fff8  BP=0000  SI=0000
DI=0000
        DS=0040  ES=0000  SS=0030  CS=c000  IP=0006   NV UP DI NG NZ AC
PE NC 
c000:0005 37                  AAA
        AX=0306  BX=ffff  CX=0000  DX=0080  SP=fff8  BP=0000  SI=0000
DI=0000
        DS=0040  ES=0000  SS=0030  CS=c000  IP=0008   NV UP DI PL NZ AC
PE CY

Then it will do this:
c000:0137 0d0a00              OR        AX,a
        AX=debf  BX=ffff  CX=0335  DX=0080  SP=ffef  BP=0000  SI=0004
DI=0002
        DS=0040  ES=0000  SS=0030  CS=c000  IP=013c   NV UP DI NG NZ NA
PO NC 
c000:013a 0000                ADD       [BX+SI],AL
        AX=debf  BX=ffff  CX=0335  DX=0080  SP=ffef  BP=0000  SI=0004
DI=0002
        DS=0040  ES=0000  SS=0030  CS=c000  IP=013f   NV UP DI NG NZ AC
PO CY 
c000:013c ba9198              MOV       DX,9891
        AX=debf  BX=ffff  CX=0335  DX=9891  SP=ffef  BP=0000  SI=0004
DI=0002
        DS=0040  ES=0000  SS=0030  CS=c000  IP=0140   NV UP DI NG NZ AC
PO CY 
c000:013f 96                  XCHG      AX,SI
        AX=0004  BX=ffff  CX=0335  DX=9891  SP=ffef  BP=0000  SI=debf
DI=0002
        DS=0040  ES=0000  SS=0030  CS=c000  IP=0141   NV UP DI NG NZ AC
PO CY 
c000:0140 91                  XCHG      AX,CX
        AX=0335  BX=ffff  CX=0004  DX=9891  SP=ffef  BP=0000  SI=debf
DI=0002
        DS=0040  ES=0000  SS=0030  CS=c000  IP=0146   NV UP DI NG NZ AC
PO CY 
c000:0141 9a9a8d9691          CALL      9196:8d9a
        AX=0335  BX=ffff  CX=0004  DX=9891  SP=ffeb  BP=0000  SI=debf
DI=0002
        DS=0040  ES=0000  SS=0030  CS=9196  IP=8d9c   NV UP DI NG NZ AC
PO CY 
9196:8d9a 0000                ADD       [BX+SI],AL
        AX=0335  BX=ffff  CX=0004  DX=9891  SP=ffeb  BP=0000  SI=debf
DI=0002
        DS=0040  ES=0000  SS=0030  CS=9196  IP=8d9e   NV UP DI PL NZ NA
PE NC 
9196:8d9c 0000                ADD       [BX+SI],AL
        AX=0335  BX=ffff  CX=0004  DX=9891  SP=ffeb  BP=0000  SI=debf
DI=0002
        DS=0040  ES=0000  SS=0030  CS=9196  IP=8da0   NV UP DI PL NZ NA
PE NC

I'm still looking for the openbios utility.  So far found broken links:(
I can get some other bios to work, but they appear to be flacky.  I
really think
I should be using the one that came programmed on the board.

Thanks,
Dave 

-----Original Message-----
From: Li-Ta Lo [mailto:ollie at lanl.gov] 
Sent: Friday, October 08, 2004 10:53 AM
To: Dave Aubin
Cc: LinuxBIOS
Subject: Re: testbios loops?

On Fri, 2004-10-08 at 08:35, Dave Aubin wrote:
> Hi,
>  
>   I went back to trying to get the Nvida 6800gt card's bios, but still

> even with dd -if=/dev/mem of=vgabios.rom skip=786432 bs=1 count=32768 
> I get the same binary as dd -if=/dev/mem of=vgabios.rom skip=1536 
> count=64.
> I used dhex (free util) to verify they are the same.
>   What happens when I run them trough testbios is that once it is done

> programming 0xc7fff it jump to 0x9 something or other and the video 
> bios isn't programmed correctly.


What do you mean by 'programming oxc7ff it jump to 0x9' ?

Ollie




From daubin at actuality-systems.com  Fri Oct  8 09:43:01 2004
From: daubin at actuality-systems.com (Dave Aubin)
Date: Fri Oct  8 09:43:01 2004
Subject: testbios loops?
Message-ID: <E8F8DBCB0468204E856114A2CD20741F2C1804@mail.local.ActualitySystems.com>

I got it and here are the results:
daubin at buildserver1:~/tmp/utils> ./romheaders
/common/home/daubin/vgabios-1.rom  
Image 1:
PCI Expansion ROM Header:
  Signature: 0x55aa (Ok)
  CPU unique data: 0x74 0xeb 0x4b 0x37 0x34 0x30 0x30 0xe9
                   0x4c 0x19 0x77 0xcc 0x56 0x49 0x44 0x45
  Pointer to PCI Data Structure: 0x0090

PCI Data Structure:
  Signature: 'PCIR' (Ok)
  Vendor ID: 0x10de
  Device ID: 0x0045
  Reserved: 0x0000
  PCI Data Structure Length: 0x0018 (24 bytes)
  PCI Data Structure Revision: 0x00
  Class Code: 0x000300 (VGA Display)
  Image Length: 0x0074 blocks (59392 bytes)
  Revision Level of Code/Data: 0x0001
  Code Type: 0x00 (Intel x86)
  Indicator: 0x80 (last image in rom)
  Reserved: 0x0000

Platform specific data for x86 compliant option rom:
  Initialization Size: 0x74 (59392 bytes)
  Entry point for INIT function: 0x50

Can you please help explain this to me:)

Thanks,
Dave:) 

-----Original Message-----
From: Stefan Reinauer [mailto:stepan at openbios.org] 
Sent: Friday, October 08, 2004 10:49 AM
To: Dave Aubin
Cc: linuxbios at clustermatic.org
Subject: Re: testbios loops?

* Dave Aubin <daubin at actuality-systems.com> [041008 16:35]:
> Hi,
>  
>   I went back to trying to get the Nvida 6800gt card's bios, but still

> even with dd -if=/dev/mem of=vgabios.rom skip=786432 bs=1 count=32768 
> I get the same binary as dd -if=/dev/mem of=vgabios.rom skip=1536 
> count=64.

Does the bios have a valid pci option rom signature? (55aa plus the
other stuff, see romheaders utility in the openbios tree)

Stefan



From ollie at lanl.gov  Fri Oct  8 09:46:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Fri Oct  8 09:46:00 2004
Subject: testbios loops?
In-Reply-To: <E8F8DBCB0468204E856114A2CD20741F2C1803@mail.local.ActualitySystems.com>
References: 	 <E8F8DBCB0468204E856114A2CD20741F2C1803@mail.local.ActualitySystems.com>
Message-ID: <1097247738.3526.27.camel@exponential.lanl.gov>

On Fri, 2004-10-08 at 08:58, Dave Aubin wrote:
> Hi,

Why it starts from c000:fffd ? It should starts from c000:0003

Ollie

> 
> It will first do this (I'm using the testbios -t option)
> c000:fffd 0000                ADD       [BX+SI],AL
>         AX=0200  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000  SI=0000
> DI=0000
>         DS=0040  ES=0000  SS=0030  CS=c000  IP=0002   NV UP DI PL ZR NA
> PE NC 
> c000:ffff 000000              ADD       -86[DI],DL
>         AX=0200  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000  SI=0000
> DI=0000
>         DS=0040  ES=0000  SS=0030  CS=c000  IP=0004   NV UP DI NG NZ NA
> PO NC 
> c000:0002 74eb                JZ        ffef
>         AX=0200  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000  SI=0000
> DI=0000
>         DS=0040  ES=0000  SS=0030  CS=c000  IP=0005   NV UP DI NG NZ NA
> PO NC 
> c000:0004 4b                  DEC       BX
>         AX=0200  BX=ffff  CX=0000  DX=0080  SP=fff8  BP=0000  SI=0000
> DI=0000
>         DS=0040  ES=0000  SS=0030  CS=c000  IP=0006   NV UP DI NG NZ AC
> PE NC 
> c000:0005 37                  AAA
>         AX=0306  BX=ffff  CX=0000  DX=0080  SP=fff8  BP=0000  SI=0000
> DI=0000
>         DS=0040  ES=0000  SS=0030  CS=c000  IP=0008   NV UP DI PL NZ AC
> PE CY
> 
> Then it will do this:
> c000:0137 0d0a00              OR        AX,a
>         AX=debf  BX=ffff  CX=0335  DX=0080  SP=ffef  BP=0000  SI=0004
> DI=0002
>         DS=0040  ES=0000  SS=0030  CS=c000  IP=013c   NV UP DI NG NZ NA
> PO NC 
> c000:013a 0000                ADD       [BX+SI],AL
>         AX=debf  BX=ffff  CX=0335  DX=0080  SP=ffef  BP=0000  SI=0004
> DI=0002
>         DS=0040  ES=0000  SS=0030  CS=c000  IP=013f   NV UP DI NG NZ AC
> PO CY 
> c000:013c ba9198              MOV       DX,9891
>         AX=debf  BX=ffff  CX=0335  DX=9891  SP=ffef  BP=0000  SI=0004
> DI=0002
>         DS=0040  ES=0000  SS=0030  CS=c000  IP=0140   NV UP DI NG NZ AC
> PO CY 
> c000:013f 96                  XCHG      AX,SI
>         AX=0004  BX=ffff  CX=0335  DX=9891  SP=ffef  BP=0000  SI=debf
> DI=0002
>         DS=0040  ES=0000  SS=0030  CS=c000  IP=0141   NV UP DI NG NZ AC
> PO CY 
> c000:0140 91                  XCHG      AX,CX
>         AX=0335  BX=ffff  CX=0004  DX=9891  SP=ffef  BP=0000  SI=debf
> DI=0002
>         DS=0040  ES=0000  SS=0030  CS=c000  IP=0146   NV UP DI NG NZ AC
> PO CY 
> c000:0141 9a9a8d9691          CALL      9196:8d9a
>         AX=0335  BX=ffff  CX=0004  DX=9891  SP=ffeb  BP=0000  SI=debf
> DI=0002
>         DS=0040  ES=0000  SS=0030  CS=9196  IP=8d9c   NV UP DI NG NZ AC
> PO CY 
> 9196:8d9a 0000                ADD       [BX+SI],AL
>         AX=0335  BX=ffff  CX=0004  DX=9891  SP=ffeb  BP=0000  SI=debf
> DI=0002
>         DS=0040  ES=0000  SS=0030  CS=9196  IP=8d9e   NV UP DI PL NZ NA
> PE NC 
> 9196:8d9c 0000                ADD       [BX+SI],AL
>         AX=0335  BX=ffff  CX=0004  DX=9891  SP=ffeb  BP=0000  SI=debf
> DI=0002
>         DS=0040  ES=0000  SS=0030  CS=9196  IP=8da0   NV UP DI PL NZ NA
> PE NC
> 
> I'm still looking for the openbios utility.  So far found broken links:(
> I can get some other bios to work, but they appear to be flacky.  I
> really think
> I should be using the one that came programmed on the board.
> 
> Thanks,
> Dave 
> 
> -----Original Message-----
> From: Li-Ta Lo [mailto:ollie at lanl.gov] 
> Sent: Friday, October 08, 2004 10:53 AM
> To: Dave Aubin
> Cc: LinuxBIOS
> Subject: Re: testbios loops?
> 
> On Fri, 2004-10-08 at 08:35, Dave Aubin wrote:
> > Hi,
> >  
> >   I went back to trying to get the Nvida 6800gt card's bios, but still
> 
> > even with dd -if=/dev/mem of=vgabios.rom skip=786432 bs=1 count=32768 
> > I get the same binary as dd -if=/dev/mem of=vgabios.rom skip=1536 
> > count=64.
> > I used dhex (free util) to verify they are the same.
> >   What happens when I run them trough testbios is that once it is done
> 
> > programming 0xc7fff it jump to 0x9 something or other and the video 
> > bios isn't programmed correctly.
> 
> 
> What do you mean by 'programming oxc7ff it jump to 0x9' ?
> 
> Ollie
> 
> 
> 



From daubin at actuality-systems.com  Fri Oct  8 09:48:07 2004
From: daubin at actuality-systems.com (Dave Aubin)
Date: Fri Oct  8 09:48:07 2004
Subject: testbios loops?
Message-ID: <E8F8DBCB0468204E856114A2CD20741F2C1805@mail.local.ActualitySystems.com>

Hi,

  Oh it does.  I just left that snippet out.  It starts at the correct
place:) 

-----Original Message-----
From: Li-Ta Lo [mailto:ollie at lanl.gov] 
Sent: Friday, October 08, 2004 11:02 AM
To: Dave Aubin
Cc: LinuxBIOS
Subject: RE: testbios loops?

On Fri, 2004-10-08 at 08:58, Dave Aubin wrote:
> Hi,

Why it starts from c000:fffd ? It should starts from c000:0003

Ollie

> 
> It will first do this (I'm using the testbios -t option)
> c000:fffd 0000                ADD       [BX+SI],AL
>         AX=0200  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000  SI=0000 
> DI=0000
>         DS=0040  ES=0000  SS=0030  CS=c000  IP=0002   NV UP DI PL ZR
NA
> PE NC 
> c000:ffff 000000              ADD       -86[DI],DL
>         AX=0200  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000  SI=0000 
> DI=0000
>         DS=0040  ES=0000  SS=0030  CS=c000  IP=0004   NV UP DI NG NZ
NA
> PO NC 
> c000:0002 74eb                JZ        ffef
>         AX=0200  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000  SI=0000 
> DI=0000
>         DS=0040  ES=0000  SS=0030  CS=c000  IP=0005   NV UP DI NG NZ
NA
> PO NC 
> c000:0004 4b                  DEC       BX
>         AX=0200  BX=ffff  CX=0000  DX=0080  SP=fff8  BP=0000  SI=0000 
> DI=0000
>         DS=0040  ES=0000  SS=0030  CS=c000  IP=0006   NV UP DI NG NZ
AC
> PE NC 
> c000:0005 37                  AAA
>         AX=0306  BX=ffff  CX=0000  DX=0080  SP=fff8  BP=0000  SI=0000 
> DI=0000
>         DS=0040  ES=0000  SS=0030  CS=c000  IP=0008   NV UP DI PL NZ
AC
> PE CY
> 
> Then it will do this:
> c000:0137 0d0a00              OR        AX,a
>         AX=debf  BX=ffff  CX=0335  DX=0080  SP=ffef  BP=0000  SI=0004
> DI=0002
>         DS=0040  ES=0000  SS=0030  CS=c000  IP=013c   NV UP DI NG NZ
NA
> PO NC 
> c000:013a 0000                ADD       [BX+SI],AL
>         AX=debf  BX=ffff  CX=0335  DX=0080  SP=ffef  BP=0000  SI=0004
> DI=0002
>         DS=0040  ES=0000  SS=0030  CS=c000  IP=013f   NV UP DI NG NZ
AC
> PO CY 
> c000:013c ba9198              MOV       DX,9891
>         AX=debf  BX=ffff  CX=0335  DX=9891  SP=ffef  BP=0000  SI=0004
> DI=0002
>         DS=0040  ES=0000  SS=0030  CS=c000  IP=0140   NV UP DI NG NZ
AC
> PO CY 
> c000:013f 96                  XCHG      AX,SI
>         AX=0004  BX=ffff  CX=0335  DX=9891  SP=ffef  BP=0000  SI=debf
> DI=0002
>         DS=0040  ES=0000  SS=0030  CS=c000  IP=0141   NV UP DI NG NZ
AC
> PO CY 
> c000:0140 91                  XCHG      AX,CX
>         AX=0335  BX=ffff  CX=0004  DX=9891  SP=ffef  BP=0000  SI=debf
> DI=0002
>         DS=0040  ES=0000  SS=0030  CS=c000  IP=0146   NV UP DI NG NZ
AC
> PO CY 
> c000:0141 9a9a8d9691          CALL      9196:8d9a
>         AX=0335  BX=ffff  CX=0004  DX=9891  SP=ffeb  BP=0000  SI=debf
> DI=0002
>         DS=0040  ES=0000  SS=0030  CS=9196  IP=8d9c   NV UP DI NG NZ
AC
> PO CY 
> 9196:8d9a 0000                ADD       [BX+SI],AL
>         AX=0335  BX=ffff  CX=0004  DX=9891  SP=ffeb  BP=0000  SI=debf
> DI=0002
>         DS=0040  ES=0000  SS=0030  CS=9196  IP=8d9e   NV UP DI PL NZ
NA
> PE NC 
> 9196:8d9c 0000                ADD       [BX+SI],AL
>         AX=0335  BX=ffff  CX=0004  DX=9891  SP=ffeb  BP=0000  SI=debf
> DI=0002
>         DS=0040  ES=0000  SS=0030  CS=9196  IP=8da0   NV UP DI PL NZ
NA
> PE NC
> 
> I'm still looking for the openbios utility.  So far found broken 
> links:( I can get some other bios to work, but they appear to be 
> flacky.  I really think I should be using the one that came programmed

> on the board.
> 
> Thanks,
> Dave
> 
> -----Original Message-----
> From: Li-Ta Lo [mailto:ollie at lanl.gov]
> Sent: Friday, October 08, 2004 10:53 AM
> To: Dave Aubin
> Cc: LinuxBIOS
> Subject: Re: testbios loops?
> 
> On Fri, 2004-10-08 at 08:35, Dave Aubin wrote:
> > Hi,
> >  
> >   I went back to trying to get the Nvida 6800gt card's bios, but 
> > still
> 
> > even with dd -if=/dev/mem of=vgabios.rom skip=786432 bs=1 
> > count=32768 I get the same binary as dd -if=/dev/mem of=vgabios.rom 
> > skip=1536 count=64.
> > I used dhex (free util) to verify they are the same.
> >   What happens when I run them trough testbios is that once it is 
> > done
> 
> > programming 0xc7fff it jump to 0x9 something or other and the video 
> > bios isn't programmed correctly.
> 
> 
> What do you mean by 'programming oxc7ff it jump to 0x9' ?
> 
> Ollie
> 
> 
> 



From rminnich at lanl.gov  Fri Oct  8 09:55:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Fri Oct  8 09:55:01 2004
Subject: testbios loops?
In-Reply-To: <1097247738.3526.27.camel@exponential.lanl.gov>
References: <E8F8DBCB0468204E856114A2CD20741F2C1803@mail.local.ActualitySystems.com>
 <1097247738.3526.27.camel@exponential.lanl.gov>
Message-ID: <Pine.LNX.4.58.0410080912500.9700@linux.site>


On Fri, 8 Oct 2004, Li-Ta Lo wrote:

> On Fri, 2004-10-08 at 08:58, Dave Aubin wrote:
> > Hi,
> 
> Why it starts from c000:fffd ? It should starts from c000:0003

this is interesting since 0xfffd is the same as (0-3)

bug somewhere?

ron


From ollie at lanl.gov  Fri Oct  8 09:58:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Fri Oct  8 09:58:01 2004
Subject: testbios loops?
In-Reply-To: <E8F8DBCB0468204E856114A2CD20741F2C1805@mail.local.ActualitySystems.com>
References: 	 <E8F8DBCB0468204E856114A2CD20741F2C1805@mail.local.ActualitySystems.com>
Message-ID: <1097248466.3526.31.camel@exponential.lanl.gov>

On Fri, 2004-10-08 at 09:04, Dave Aubin wrote:
> Hi,
> 
>   Oh it does.  I just left that snippet out.  It starts at the correct
> place:) 
> 

Then there is a big problem. The code just to somewhere that is not
code (0000). Can you send more messages ?

Ollie

> -----Original Message-----
> From: Li-Ta Lo [mailto:ollie at lanl.gov] 
> Sent: Friday, October 08, 2004 11:02 AM
> To: Dave Aubin
> Cc: LinuxBIOS
> Subject: RE: testbios loops?
> 
> On Fri, 2004-10-08 at 08:58, Dave Aubin wrote:
> > Hi,
> 
> Why it starts from c000:fffd ? It should starts from c000:0003
> 
> Ollie
> 
> > 
> > It will first do this (I'm using the testbios -t option)
> > c000:fffd 0000                ADD       [BX+SI],AL
> >         AX=0200  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000  SI=0000 
> > DI=0000
> >         DS=0040  ES=0000  SS=0030  CS=c000  IP=0002   NV UP DI PL ZR
> NA
> > PE NC 
> > c000:ffff 000000              ADD       -86[DI],DL
> >         AX=0200  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000  SI=0000 
> > DI=0000
> >         DS=0040  ES=0000  SS=0030  CS=c000  IP=0004   NV UP DI NG NZ
> NA
> > PO NC 
> > c000:0002 74eb                JZ        ffef
> >         AX=0200  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000  SI=0000 
> > DI=0000
> >         DS=0040  ES=0000  SS=0030  CS=c000  IP=0005   NV UP DI NG NZ
> NA
> > PO NC 
> > c000:0004 4b                  DEC       BX
> >         AX=0200  BX=ffff  CX=0000  DX=0080  SP=fff8  BP=0000  SI=0000 
> > DI=0000
> >         DS=0040  ES=0000  SS=0030  CS=c000  IP=0006   NV UP DI NG NZ
> AC
> > PE NC 
> > c000:0005 37                  AAA
> >         AX=0306  BX=ffff  CX=0000  DX=0080  SP=fff8  BP=0000  SI=0000 
> > DI=0000
> >         DS=0040  ES=0000  SS=0030  CS=c000  IP=0008   NV UP DI PL NZ
> AC
> > PE CY
> > 
> > Then it will do this:
> > c000:0137 0d0a00              OR        AX,a
> >         AX=debf  BX=ffff  CX=0335  DX=0080  SP=ffef  BP=0000  SI=0004
> > DI=0002
> >         DS=0040  ES=0000  SS=0030  CS=c000  IP=013c   NV UP DI NG NZ
> NA
> > PO NC 
> > c000:013a 0000                ADD       [BX+SI],AL
> >         AX=debf  BX=ffff  CX=0335  DX=0080  SP=ffef  BP=0000  SI=0004
> > DI=0002
> >         DS=0040  ES=0000  SS=0030  CS=c000  IP=013f   NV UP DI NG NZ
> AC
> > PO CY 
> > c000:013c ba9198              MOV       DX,9891
> >         AX=debf  BX=ffff  CX=0335  DX=9891  SP=ffef  BP=0000  SI=0004
> > DI=0002
> >         DS=0040  ES=0000  SS=0030  CS=c000  IP=0140   NV UP DI NG NZ
> AC
> > PO CY 
> > c000:013f 96                  XCHG      AX,SI
> >         AX=0004  BX=ffff  CX=0335  DX=9891  SP=ffef  BP=0000  SI=debf
> > DI=0002
> >         DS=0040  ES=0000  SS=0030  CS=c000  IP=0141   NV UP DI NG NZ
> AC
> > PO CY 
> > c000:0140 91                  XCHG      AX,CX
> >         AX=0335  BX=ffff  CX=0004  DX=9891  SP=ffef  BP=0000  SI=debf
> > DI=0002
> >         DS=0040  ES=0000  SS=0030  CS=c000  IP=0146   NV UP DI NG NZ
> AC
> > PO CY 
> > c000:0141 9a9a8d9691          CALL      9196:8d9a
> >         AX=0335  BX=ffff  CX=0004  DX=9891  SP=ffeb  BP=0000  SI=debf
> > DI=0002
> >         DS=0040  ES=0000  SS=0030  CS=9196  IP=8d9c   NV UP DI NG NZ
> AC
> > PO CY 
> > 9196:8d9a 0000                ADD       [BX+SI],AL
> >         AX=0335  BX=ffff  CX=0004  DX=9891  SP=ffeb  BP=0000  SI=debf
> > DI=0002
> >         DS=0040  ES=0000  SS=0030  CS=9196  IP=8d9e   NV UP DI PL NZ
> NA
> > PE NC 
> > 9196:8d9c 0000                ADD       [BX+SI],AL
> >         AX=0335  BX=ffff  CX=0004  DX=9891  SP=ffeb  BP=0000  SI=debf
> > DI=0002
> >         DS=0040  ES=0000  SS=0030  CS=9196  IP=8da0   NV UP DI PL NZ
> NA
> > PE NC
> > 
> > I'm still looking for the openbios utility.  So far found broken 
> > links:( I can get some other bios to work, but they appear to be 
> > flacky.  I really think I should be using the one that came programmed
> 
> > on the board.
> > 
> > Thanks,
> > Dave
> > 
> > -----Original Message-----
> > From: Li-Ta Lo [mailto:ollie at lanl.gov]
> > Sent: Friday, October 08, 2004 10:53 AM
> > To: Dave Aubin
> > Cc: LinuxBIOS
> > Subject: Re: testbios loops?
> > 
> > On Fri, 2004-10-08 at 08:35, Dave Aubin wrote:
> > > Hi,
> > >  
> > >   I went back to trying to get the Nvida 6800gt card's bios, but 
> > > still
> > 
> > > even with dd -if=/dev/mem of=vgabios.rom skip=786432 bs=1 
> > > count=32768 I get the same binary as dd -if=/dev/mem of=vgabios.rom 
> > > skip=1536 count=64.
> > > I used dhex (free util) to verify they are the same.
> > >   What happens when I run them trough testbios is that once it is 
> > > done
> > 
> > > programming 0xc7fff it jump to 0x9 something or other and the video 
> > > bios isn't programmed correctly.
> > 
> > 
> > What do you mean by 'programming oxc7ff it jump to 0x9' ?
> > 
> > Ollie
> > 
> > 
> > 
> 
> 



From rsmith at bitworks.com  Fri Oct  8 10:00:07 2004
From: rsmith at bitworks.com (Richard Smith)
Date: Fri Oct  8 10:00:07 2004
Subject: testbios loops?
In-Reply-To: <20041008144914.GB21886@openbios.org>
References: <E8F8DBCB0468204E856114A2CD20741F2C1801@mail.local.ActualitySystems.com> <20041008144914.GB21886@openbios.org>
Message-ID: <4166AF02.9000102@bitworks.com>

Stefan Reinauer wrote:

> * Dave Aubin <daubin at actuality-systems.com> [041008 16:35]:

>>  I went back to trying to get the Nvida 6800gt card's bios, but still
>>even with dd -if=/dev/mem of=vgabios.rom skip=786432 bs=1 count=32768
>>I get the same binary as dd -if=/dev/mem of=vgabios.rom skip=1536
>>count=64.
> 
> Does the bios have a valid pci option rom signature? (55aa plus the
> other stuff, see romheaders utility in the openbios tree)

Or use hd and see whats at 0xc0000.  Also fire up X and look at your 
log.  It outputs a lot of good info.

-- 
Richard A. Smith




From daubin at actuality-systems.com  Fri Oct  8 10:03:39 2004
From: daubin at actuality-systems.com (Dave Aubin)
Date: Fri Oct  8 10:03:39 2004
Subject: testbios loops?
Message-ID: <E8F8DBCB0468204E856114A2CD20741F2C1808@mail.local.ActualitySystems.com>

Starting up X causes bad things, ie hang!

I'm building the log now and will send in separate message.

Thanks,
Dave 

-----Original Message-----
From: Richard Smith [mailto:rsmith at bitworks.com] 
Sent: Friday, October 08, 2004 11:15 AM
To: stepan at openbios.org; Dave Aubin
Cc: linuxbios at clustermatic.org
Subject: Re: testbios loops?

Stefan Reinauer wrote:

> * Dave Aubin <daubin at actuality-systems.com> [041008 16:35]:

>>  I went back to trying to get the Nvida 6800gt card's bios, but still

>>even with dd -if=/dev/mem of=vgabios.rom skip=786432 bs=1 count=32768 
>>I get the same binary as dd -if=/dev/mem of=vgabios.rom skip=1536 
>>count=64.
> 
> Does the bios have a valid pci option rom signature? (55aa plus the 
> other stuff, see romheaders utility in the openbios tree)

Or use hd and see whats at 0xc0000.  Also fire up X and look at your
log.  It outputs a lot of good info.

--
Richard A. Smith




From daubin at actuality-systems.com  Fri Oct  8 10:22:00 2004
From: daubin at actuality-systems.com (Dave Aubin)
Date: Fri Oct  8 10:22:00 2004
Subject: testbios loops?
Message-ID: <E8F8DBCB0468204E856114A2CD20741F2C180C@mail.local.ActualitySystems.com>

Here is a dump of the following:
/usr/bin/testbios -s 65536 -d 0x200 --abseg /dev/mem
/usr/bin/nv6800gt.bin -t

I slightly different behavior with this incantation.  Normally I leave
off
The -d 0x200.  My device is located off of 2:0:0.

running file /usr/bin/nv6800gt.bin
No base specified. defaulting to 0xc0000
No initial code segment specified. defaulting to 0xc000
No initial instruction pointer specified. defaulting to 0x0003
Switching to single step mode.
	AX=0200  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=0005   NV UP DI PL NZ NA
PO NC 
c000:0003 eb4b                JMP	50
	AX=0200  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=0053   NV UP DI PL NZ NA
PO NC 
c000:0050 e99cd4              JMP	d4ef
	AX=0200  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=d4f0   NV UP DI PL NZ NA
PO NC 
c000:d4ef 2e                  CS:
	AX=0200  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=d4f5   NV UP DI PL NZ NA
PO NC 
c000:d4f0 f606480001          TEST	BYTE PTR [0048],01
	AX=0200  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=d4f7   NV UP DI PL ZR NA
PE NC 
c000:d4f5 742d                JZ	d524
	AX=0200  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=d525   NV UP DI PL ZR NA
PE NC 
c000:d524 55                  PUSH	BP
	AX=0200  BX=0000  CX=0000  DX=0080  SP=fff6  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=d526   NV UP DI PL ZR NA
PE NC 
c000:d525 50                  PUSH	AX
	AX=0200  BX=0000  CX=0000  DX=0080  SP=fff4  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=d529   NV UP DI PL ZR NA
PE NC 
c000:d526 e85afa              CALL	cf83
	AX=0200  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=cf84   NV UP DI PL ZR NA
PE NC 
c000:cf83 60                  PUSHA
	AX=0200  BX=0000  CX=0000  DX=0080  SP=ffe2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=cf87   NV UP DI PL ZR NA
PE NC 
c000:cf84 bac303              MOV	DX,3c3
	AX=0200  BX=0000  CX=0000  DX=03c3  SP=ffe2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=cf89   NV UP DI PL ZR NA
PE NC 
c000:cf87 b001                MOV	AL,1
	AX=0201  BX=0000  CX=0000  DX=03c3  SP=ffe2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=cf8a   NV UP DI PL ZR NA
PE NC 
c000:cf89 ee                  OUT	DX,AL
	AX=0201  BX=0000  CX=0000  DX=03c3  SP=ffe2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=cf8b   NV UP DI PL ZR NA
PE NC 
c000:cf8a ed                  IN	AX,DX
	AX=0001  BX=0000  CX=0000  DX=03c3  SP=ffe2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=cf8e   NV UP DI PL ZR NA
PE NC 
c000:cf8b bacc03              MOV	DX,3cc
	AX=0001  BX=0000  CX=0000  DX=03cc  SP=ffe2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=cf8f   NV UP DI PL ZR NA
PE NC 
c000:cf8e ec                  IN	AL,DX
	AX=0000  BX=0000  CX=0000  DX=03cc  SP=ffe2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=cf91   NV UP DI PL ZR NA
PE NC 
c000:cf8f 0c01                OR	AL,1
	AX=0001  BX=0000  CX=0000  DX=03cc  SP=ffe2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=cf94   NV UP DI PL NZ NA
PO NC 
c000:cf91 bac203              MOV	DX,3c2
	AX=0001  BX=0000  CX=0000  DX=03c2  SP=ffe2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=cf95   NV UP DI PL NZ NA
PO NC 
c000:cf94 ee                  OUT	DX,AL
	AX=0001  BX=0000  CX=0000  DX=03c2  SP=ffe2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=cf98   NV UP DI PL NZ NA
PO NC 
c000:cf95 bac303              MOV	DX,3c3
	AX=0001  BX=0000  CX=0000  DX=03c3  SP=ffe2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=cf99   NV UP DI PL NZ NA
PO NC 
c000:cf98 ec                  IN	AL,DX
	AX=0001  BX=0000  CX=0000  DX=03c3  SP=ffe2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=cf9c   NV UP DI PL NZ NA
PO NC 
c000:cf99 e82675              CALL	44c2
	AX=0001  BX=0000  CX=0000  DX=03c3  SP=ffe0  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=44c3   NV UP DI PL NZ NA
PO NC 
c000:44c2 50                  PUSH	AX
	AX=0001  BX=0000  CX=0000  DX=03c3  SP=ffde  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=44c4   NV UP DI PL NZ NA
PO NC 
c000:44c3 52                  PUSH	DX
	AX=0001  BX=0000  CX=0000  DX=03c3  SP=ffdc  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=44c7   NV UP DI PL NZ NA
PO NC 
c000:44c4 e833d3              CALL	17fa
	AX=0001  BX=0000  CX=0000  DX=03c3  SP=ffda  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=17fb   NV UP DI PL NZ NA
PO NC 
c000:17fa 50                  PUSH	AX
	AX=0001  BX=0000  CX=0000  DX=03c3  SP=ffd8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=17fe   NV UP DI PL NZ NA
PO NC 
c000:17fb bacc03              MOV	DX,3cc
	AX=0001  BX=0000  CX=0000  DX=03cc  SP=ffd8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=17ff   NV UP DI PL NZ NA
PO NC 
c000:17fe ec                  IN	AL,DX
	AX=0001  BX=0000  CX=0000  DX=03cc  SP=ffd8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=1802   NV UP DI PL NZ NA
PO NC 
c000:17ff bab403              MOV	DX,3b4
	AX=0001  BX=0000  CX=0000  DX=03b4  SP=ffd8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=1804   NV UP DI PL NZ NA
PO NC 
c000:1802 a801                TEST	AL,0001
	AX=0001  BX=0000  CX=0000  DX=03b4  SP=ffd8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=1806   NV UP DI PL NZ NA
PO NC 
c000:1804 7402                JZ	1808
	AX=0001  BX=0000  CX=0000  DX=03b4  SP=ffd8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=1808   NV UP DI PL NZ NA
PO NC 
c000:1806 b2d4                MOV	DL,d4
	AX=0001  BX=0000  CX=0000  DX=03d4  SP=ffd8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=1809   NV UP DI PL NZ NA
PO NC 
c000:1808 58                  POP	AX
	AX=0001  BX=0000  CX=0000  DX=03d4  SP=ffda  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=180a   NV UP DI PL NZ NA
PO NC 
c000:1809 c3                  RET
	AX=0001  BX=0000  CX=0000  DX=03d4  SP=ffdc  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=44c8   NV UP DI PL NZ NA
PO NC 
c000:44c7 ec                  IN	AL,DX
	AX=0000  BX=0000  CX=0000  DX=03d4  SP=ffdc  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=44c9   NV UP DI PL NZ NA
PO NC 
c000:44c8 50                  PUSH	AX
	AX=0000  BX=0000  CX=0000  DX=03d4  SP=ffda  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=44ca   NV UP DI PL NZ NA
PO NC 
c000:44c9 53                  PUSH	BX
	AX=0000  BX=0000  CX=0000  DX=03d4  SP=ffd8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=44cc   NV UP DI PL NZ NA
PO NC 
c000:44ca b01f                MOV	AL,1f
	AX=001f  BX=0000  CX=0000  DX=03d4  SP=ffd8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=44cf   NV UP DI PL NZ NA
PO NC 
c000:44cc e8f8d0              CALL	15c7
	AX=001f  BX=0000  CX=0000  DX=03d4  SP=ffd6  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=15ca   NV UP DI PL NZ NA
PO NC 
c000:15c7 e83002              CALL	17fa
	AX=001f  BX=0000  CX=0000  DX=03d4  SP=ffd4  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=17fb   NV UP DI PL NZ NA
PO NC 
c000:17fa 50                  PUSH	AX
	AX=001f  BX=0000  CX=0000  DX=03d4  SP=ffd2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=17fe   NV UP DI PL NZ NA
PO NC 
c000:17fb bacc03              MOV	DX,3cc
	AX=001f  BX=0000  CX=0000  DX=03cc  SP=ffd2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=17ff   NV UP DI PL NZ NA
PO NC 
c000:17fe ec                  IN	AL,DX
	AX=0001  BX=0000  CX=0000  DX=03cc  SP=ffd2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=1802   NV UP DI PL NZ NA
PO NC 
c000:17ff bab403              MOV	DX,3b4
	AX=0001  BX=0000  CX=0000  DX=03b4  SP=ffd2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=1804   NV UP DI PL NZ NA
PO NC 
c000:1802 a801                TEST	AL,0001
	AX=0001  BX=0000  CX=0000  DX=03b4  SP=ffd2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=1806   NV UP DI PL NZ NA
PO NC 
c000:1804 7402                JZ	1808
	AX=0001  BX=0000  CX=0000  DX=03b4  SP=ffd2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=1808   NV UP DI PL NZ NA
PO NC 
c000:1806 b2d4                MOV	DL,d4
	AX=0001  BX=0000  CX=0000  DX=03d4  SP=ffd2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=1809   NV UP DI PL NZ NA
PO NC 
c000:1808 58                  POP	AX
	AX=001f  BX=0000  CX=0000  DX=03d4  SP=ffd4  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=180a   NV UP DI PL NZ NA
PO NC 
c000:1809 c3                  RET
	AX=001f  BX=0000  CX=0000  DX=03d4  SP=ffd6  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=15cb   NV UP DI PL NZ NA
PO NC 
c000:15ca ee                  OUT	DX,AL
	AX=001f  BX=0000  CX=0000  DX=03d4  SP=ffd6  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=15cc   NV UP DI PL NZ NA
PO NC 
c000:15cb ed                  IN	AX,DX
	AX=001f  BX=0000  CX=0000  DX=03d4  SP=ffd6  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=15cd   NV UP DI PL NZ NA
PO NC 
c000:15cc c3                  RET
	AX=001f  BX=0000  CX=0000  DX=03d4  SP=ffd8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=44d2   NV UP DI PL NZ NA
PO NC 
c000:44cf 80e401              AND	AH,1
	AX=001f  BX=0000  CX=0000  DX=03d4  SP=ffd8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=44d4   NV UP DI PL ZR NA
PE NC 
c000:44d2 8afc                MOV	BH,AH
	AX=001f  BX=0000  CX=0000  DX=03d4  SP=ffd8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=44d7   NV UP DI PL ZR NA
PE NC 
c000:44d4 b82c01              MOV	AX,12c
	AX=012c  BX=0000  CX=0000  DX=03d4  SP=ffd8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=44d9   NV UP DI PL ZR NA
PE NC 
c000:44d7 0aff                OR	BH,BH
	AX=012c  BX=0000  CX=0000  DX=03d4  SP=ffd8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=44db   NV UP DI PL ZR NA
PE NC 
c000:44d9 7405                JZ	44e0
	AX=012c  BX=0000  CX=0000  DX=03d4  SP=ffd8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=44e3   NV UP DI PL ZR NA
PE NC 
c000:44e0 e8350d              CALL	5218
	AX=012c  BX=0000  CX=0000  DX=03d4  SP=ffd6  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=521a   NV UP DI PL ZR NA
PE NC 
c000:5218 f6d4                NOT	AH
	AX=fe2c  BX=0000  CX=0000  DX=03d4  SP=ffd6  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=521b   NV UP DI PL ZR NA
PE NC 
c000:521a 52                  PUSH	DX
	AX=fe2c  BX=0000  CX=0000  DX=03d4  SP=ffd4  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=521c   NV UP DI PL ZR NA
PE NC 
c000:521b 50                  PUSH	AX
	AX=fe2c  BX=0000  CX=0000  DX=03d4  SP=ffd2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=521f   NV UP DI PL ZR NA
PE NC 
c000:521c e890ff              CALL	51af
	AX=fe2c  BX=0000  CX=0000  DX=03d4  SP=ffd0  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=51b0   NV UP DI PL ZR NA
PE NC 
c000:51af 53                  PUSH	BX
	AX=fe2c  BX=0000  CX=0000  DX=03d4  SP=ffce  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=51b1   NV UP DI PL ZR NA
PE NC 
c000:51b0 93                  XCHG	AX,BX
	AX=0000  BX=fe2c  CX=0000  DX=03d4  SP=ffce  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=51b4   NV UP DI PL ZR NA
PE NC 
c000:51b1 e8e3ff              CALL	5197
	AX=0000  BX=fe2c  CX=0000  DX=03d4  SP=ffcc  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=5199   NV UP DI PL ZR NA
PE NC 
c000:5197 32e4                XOR	AH,AH
	AX=0000  BX=fe2c  CX=0000  DX=03d4  SP=ffcc  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=519c   NV UP DI PL ZR NA
PE NC 
c000:5199 e8deff              CALL	517a
	AX=0000  BX=fe2c  CX=0000  DX=03d4  SP=ffca  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=517b   NV UP DI PL ZR NA
PE NC 
c000:517a 9c                  PUSHF
	AX=0000  BX=fe2c  CX=0000  DX=03d4  SP=ffc8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=517c   NV UP DI PL ZR NA
PE NC 
c000:517b 52                  PUSH	DX
	AX=0000  BX=fe2c  CX=0000  DX=03d4  SP=ffc6  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=517d   NV UP DI PL ZR NA
PE NC 
c000:517c 53                  PUSH	BX
	AX=0000  BX=fe2c  CX=0000  DX=03d4  SP=ffc4  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=517f   NV UP DI PL ZR NA
PE NC 
c000:517d 8bd8                MOV	BX,AX
	AX=0000  BX=0000  CX=0000  DX=03d4  SP=ffc4  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=5181   NV UP DI PL ZR NA
PE NC 
c000:517f b044                MOV	AL,44
	AX=0044  BX=0000  CX=0000  DX=03d4  SP=ffc4  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=5184   NV UP DI PL ZR NA
PE NC 
c000:5181 e843c4              CALL	15c7
	AX=0044  BX=0000  CX=0000  DX=03d4  SP=ffc2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=15ca   NV UP DI PL ZR NA
PE NC 
c000:15c7 e83002              CALL	17fa
	AX=0044  BX=0000  CX=0000  DX=03d4  SP=ffc0  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=17fb   NV UP DI PL ZR NA
PE NC 
c000:17fa 50                  PUSH	AX
	AX=0044  BX=0000  CX=0000  DX=03d4  SP=ffbe  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=17fe   NV UP DI PL ZR NA
PE NC 
c000:17fb bacc03              MOV	DX,3cc
	AX=0044  BX=0000  CX=0000  DX=03cc  SP=ffbe  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=17ff   NV UP DI PL ZR NA
PE NC 
c000:17fe ec                  IN	AL,DX
	AX=0001  BX=0000  CX=0000  DX=03cc  SP=ffbe  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=1802   NV UP DI PL ZR NA
PE NC 
c000:17ff bab403              MOV	DX,3b4
	AX=0001  BX=0000  CX=0000  DX=03b4  SP=ffbe  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=1804   NV UP DI PL ZR NA
PE NC 
c000:1802 a801                TEST	AL,0001
	AX=0001  BX=0000  CX=0000  DX=03b4  SP=ffbe  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=1806   NV UP DI PL NZ NA
PO NC 
c000:1804 7402                JZ	1808
	AX=0001  BX=0000  CX=0000  DX=03b4  SP=ffbe  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=1808   NV UP DI PL NZ NA
PO NC 
c000:1806 b2d4                MOV	DL,d4
	AX=0001  BX=0000  CX=0000  DX=03d4  SP=ffbe  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=1809   NV UP DI PL NZ NA
PO NC 
c000:1808 58                  POP	AX
	AX=0044  BX=0000  CX=0000  DX=03d4  SP=ffc0  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=180a   NV UP DI PL NZ NA
PO NC 
c000:1809 c3                  RET
	AX=0044  BX=0000  CX=0000  DX=03d4  SP=ffc2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=15cb   NV UP DI PL NZ NA
PO NC 
c000:15ca ee                  OUT	DX,AL
	AX=0044  BX=0000  CX=0000  DX=03d4  SP=ffc2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=15cc   NV UP DI PL NZ NA
PO NC 
c000:15cb ed                  IN	AX,DX
	AX=0044  BX=0000  CX=0000  DX=03d4  SP=ffc2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=15cd   NV UP DI PL NZ NA
PO NC 
c000:15cc c3                  RET
	AX=0044  BX=0000  CX=0000  DX=03d4  SP=ffc4  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=5185   NV UP DI PL NZ NA
PO NC 
c000:5184 50                  PUSH	AX
	AX=0044  BX=0000  CX=0000  DX=03d4  SP=ffc2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=5187   NV UP DI PL NZ NA
PO NC 
c000:5185 8ae7                MOV	AH,BH
	AX=0044  BX=0000  CX=0000  DX=03d4  SP=ffc2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=5188   NV UP DI PL NZ NA
PO NC 
c000:5187 ef                  OUT	DX,AX
	AX=0044  BX=0000  CX=0000  DX=03d4  SP=ffc2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=5189   NV UP DI PL NZ NA
PO NC 
c000:5188 58                  POP	AX
	AX=0044  BX=0000  CX=0000  DX=03d4  SP=ffc4  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=518a   NV UP DI PL NZ NA
PO NC 
c000:5189 5b                  POP	BX
	AX=0044  BX=fe2c  CX=0000  DX=03d4  SP=ffc6  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=518b   NV UP DI PL NZ NA
PO NC 
c000:518a 5a                  POP	DX
	AX=0044  BX=fe2c  CX=0000  DX=03d4  SP=ffc8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=518c   NV UP DI PL NZ NA
PO NC 
c000:518b 9d                  POPF
	AX=0044  BX=fe2c  CX=0000  DX=03d4  SP=ffca  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=518d   NV UP DI PL ZR NA
PE NC 
c000:518c c3                  RET
	AX=0044  BX=fe2c  CX=0000  DX=03d4  SP=ffcc  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=519d   NV UP DI PL ZR NA
PE NC 
c000:519c c3                  RET
	AX=0044  BX=fe2c  CX=0000  DX=03d4  SP=ffce  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=51b5   NV UP DI PL ZR NA
PE NC 
c000:51b4 50                  PUSH	AX
	AX=0044  BX=fe2c  CX=0000  DX=03d4  SP=ffcc  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=51b6   NV UP DI PL ZR NA
PE NC 
c000:51b5 93                  XCHG	AX,BX
	AX=fe2c  BX=0044  CX=0000  DX=03d4  SP=ffcc  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=51b9   NV UP DI PL ZR NA
PE NC 
c000:51b6 e80ec4              CALL	15c7
	AX=fe2c  BX=0044  CX=0000  DX=03d4  SP=ffca  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=15ca   NV UP DI PL ZR NA
PE NC 
c000:15c7 e83002              CALL	17fa
	AX=fe2c  BX=0044  CX=0000  DX=03d4  SP=ffc8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=17fb   NV UP DI PL ZR NA
PE NC 
c000:17fa 50                  PUSH	AX
	AX=fe2c  BX=0044  CX=0000  DX=03d4  SP=ffc6  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=17fe   NV UP DI PL ZR NA
PE NC 
 

-----Original Message-----
From: Li-Ta Lo [mailto:ollie at lanl.gov] 
Sent: Friday, October 08, 2004 11:14 AM
To: Dave Aubin
Cc: LinuxBIOS
Subject: RE: testbios loops?

On Fri, 2004-10-08 at 09:04, Dave Aubin wrote:
> Hi,
> 
>   Oh it does.  I just left that snippet out.  It starts at the correct
> place:)
> 

Then there is a big problem. The code just to somewhere that is not
code (0000). Can you send more messages ?

Ollie

> -----Original Message-----
> From: Li-Ta Lo [mailto:ollie at lanl.gov] 
> Sent: Friday, October 08, 2004 11:02 AM
> To: Dave Aubin
> Cc: LinuxBIOS
> Subject: RE: testbios loops?
> 
> On Fri, 2004-10-08 at 08:58, Dave Aubin wrote:
> > Hi,
> 
> Why it starts from c000:fffd ? It should starts from c000:0003
> 
> Ollie
> 
> > 
> > It will first do this (I'm using the testbios -t option)
> > c000:fffd 0000                ADD       [BX+SI],AL
> >         AX=0200  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000
SI=0000 
> > DI=0000
> >         DS=0040  ES=0000  SS=0030  CS=c000  IP=0002   NV UP DI PL ZR
> NA
> > PE NC 
> > c000:ffff 000000              ADD       -86[DI],DL
> >         AX=0200  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000
SI=0000 
> > DI=0000
> >         DS=0040  ES=0000  SS=0030  CS=c000  IP=0004   NV UP DI NG NZ
> NA
> > PO NC 
> > c000:0002 74eb                JZ        ffef
> >         AX=0200  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000
SI=0000 
> > DI=0000
> >         DS=0040  ES=0000  SS=0030  CS=c000  IP=0005   NV UP DI NG NZ
> NA
> > PO NC 
> > c000:0004 4b                  DEC       BX
> >         AX=0200  BX=ffff  CX=0000  DX=0080  SP=fff8  BP=0000
SI=0000 
> > DI=0000
> >         DS=0040  ES=0000  SS=0030  CS=c000  IP=0006   NV UP DI NG NZ
> AC
> > PE NC 
> > c000:0005 37                  AAA
> >         AX=0306  BX=ffff  CX=0000  DX=0080  SP=fff8  BP=0000
SI=0000 
> > DI=0000
> >         DS=0040  ES=0000  SS=0030  CS=c000  IP=0008   NV UP DI PL NZ
> AC
> > PE CY
> > 
> > Then it will do this:
> > c000:0137 0d0a00              OR        AX,a
> >         AX=debf  BX=ffff  CX=0335  DX=0080  SP=ffef  BP=0000
SI=0004
> > DI=0002
> >         DS=0040  ES=0000  SS=0030  CS=c000  IP=013c   NV UP DI NG NZ
> NA
> > PO NC 
> > c000:013a 0000                ADD       [BX+SI],AL
> >         AX=debf  BX=ffff  CX=0335  DX=0080  SP=ffef  BP=0000
SI=0004
> > DI=0002
> >         DS=0040  ES=0000  SS=0030  CS=c000  IP=013f   NV UP DI NG NZ
> AC
> > PO CY 
> > c000:013c ba9198              MOV       DX,9891
> >         AX=debf  BX=ffff  CX=0335  DX=9891  SP=ffef  BP=0000
SI=0004
> > DI=0002
> >         DS=0040  ES=0000  SS=0030  CS=c000  IP=0140   NV UP DI NG NZ
> AC
> > PO CY 
> > c000:013f 96                  XCHG      AX,SI
> >         AX=0004  BX=ffff  CX=0335  DX=9891  SP=ffef  BP=0000
SI=debf
> > DI=0002
> >         DS=0040  ES=0000  SS=0030  CS=c000  IP=0141   NV UP DI NG NZ
> AC
> > PO CY 
> > c000:0140 91                  XCHG      AX,CX
> >         AX=0335  BX=ffff  CX=0004  DX=9891  SP=ffef  BP=0000
SI=debf
> > DI=0002
> >         DS=0040  ES=0000  SS=0030  CS=c000  IP=0146   NV UP DI NG NZ
> AC
> > PO CY 
> > c000:0141 9a9a8d9691          CALL      9196:8d9a
> >         AX=0335  BX=ffff  CX=0004  DX=9891  SP=ffeb  BP=0000
SI=debf
> > DI=0002
> >         DS=0040  ES=0000  SS=0030  CS=9196  IP=8d9c   NV UP DI NG NZ
> AC
> > PO CY 
> > 9196:8d9a 0000                ADD       [BX+SI],AL
> >         AX=0335  BX=ffff  CX=0004  DX=9891  SP=ffeb  BP=0000
SI=debf
> > DI=0002
> >         DS=0040  ES=0000  SS=0030  CS=9196  IP=8d9e   NV UP DI PL NZ
> NA
> > PE NC 
> > 9196:8d9c 0000                ADD       [BX+SI],AL
> >         AX=0335  BX=ffff  CX=0004  DX=9891  SP=ffeb  BP=0000
SI=debf
> > DI=0002
> >         DS=0040  ES=0000  SS=0030  CS=9196  IP=8da0   NV UP DI PL NZ
> NA
> > PE NC
> > 
> > I'm still looking for the openbios utility.  So far found broken 
> > links:( I can get some other bios to work, but they appear to be 
> > flacky.  I really think I should be using the one that came
programmed
> 
> > on the board.
> > 
> > Thanks,
> > Dave
> > 
> > -----Original Message-----
> > From: Li-Ta Lo [mailto:ollie at lanl.gov]
> > Sent: Friday, October 08, 2004 10:53 AM
> > To: Dave Aubin
> > Cc: LinuxBIOS
> > Subject: Re: testbios loops?
> > 
> > On Fri, 2004-10-08 at 08:35, Dave Aubin wrote:
> > > Hi,
> > >  
> > >   I went back to trying to get the Nvida 6800gt card's bios, but 
> > > still
> > 
> > > even with dd -if=/dev/mem of=vgabios.rom skip=786432 bs=1 
> > > count=32768 I get the same binary as dd -if=/dev/mem
of=vgabios.rom 
> > > skip=1536 count=64.
> > > I used dhex (free util) to verify they are the same.
> > >   What happens when I run them trough testbios is that once it is 
> > > done
> > 
> > > programming 0xc7fff it jump to 0x9 something or other and the
video 
> > > bios isn't programmed correctly.
> > 
> > 
> > What do you mean by 'programming oxc7ff it jump to 0x9' ?
> > 
> > Ollie
> > 
> > 
> > 
> 
> 



From stepan at openbios.org  Fri Oct  8 10:53:01 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Fri Oct  8 10:53:01 2004
Subject: testbios loops?
In-Reply-To: <E8F8DBCB0468204E856114A2CD20741F2C1803@mail.local.ActualitySystems.com>
References: <E8F8DBCB0468204E856114A2CD20741F2C1803@mail.local.ActualitySystems.com>
Message-ID: <20041008161055.GA23637@openbios.org>

* Dave Aubin <daubin at actuality-systems.com> [041008 16:58]:
> I'm still looking for the openbios utility.  So far found broken links:(

Ups.. I'm sorry. I am in the middle of fixing all this.. But it will
take some more days.

Get the latest snapshot at http://www.openbios.org/snapshots/
Then unpack it, go to utils/romheaders and do "make".

Stefan



From daubin at actuality-systems.com  Fri Oct  8 12:18:00 2004
From: daubin at actuality-systems.com (Dave Aubin)
Date: Fri Oct  8 12:18:00 2004
Subject: testbios loops?
Message-ID: <E8F8DBCB0468204E856114A2CD20741F2C181A@mail.local.ActualitySystems.com>

Update...

Well the last complete trace I sent was due to only having 32k
And not 64k of the image.  Weird is that iomem shows linux as using
Only 0xc0000 to 0xc7fff which is 32k.  Now when I excute a 64k
Code size it eventually loops, but takes a bit longer.  What's
Really funny is that appears the image is doing nothing of interest.
Here is a snap shot of what I mean.  It just keeps adding BX+SI which
Are both 0.

Any ideas???

Thanks,
Dave

running file vgabios-1k.rom
No base specified. defaulting to 0xc0000
No initial code segment specified. defaulting to 0xc000
No initial instruction pointer specified. defaulting to 0x0003
Switching to single step mode.
	AX=00ff  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=0005   NV UP DI PL NZ NA
PO NC 
c000:0003 eb4b                JMP	50
	AX=00ff  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=0053   NV UP DI PL NZ NA
PO NC 
c000:0050 e9bcd4              JMP	d50f
	AX=00ff  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=d511   NV UP DI PL NZ NA
PO NC 
c000:d50f 1818                SBB	[BX+SI],BL
	AX=00ff  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=d513   NV UP DI PL ZR NA
PE NC 
c000:d511 0000                ADD	[BX+SI],AL
	AX=00ff  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=d516   NV UP DI NG NZ NA
PE NC 
c000:d513 3366cc              XOR	SP,-52[BP]
	AX=00ff  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=d517   NV UP DI NG NZ NA
PO NC 
c000:d516 66                  DATA:
	AX=00ff  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=d519   NV UP DI NG NZ NA
PO NC 
c000:d517 3300                XOR	EAX,[BX+SI]
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=d51b   NV UP DI PL ZR NA
PE NC 
c000:d519 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=d51c   NV UP DI NG NZ NA
PE NC 
c000:d51b cc                  INT 3
int3 vector at 0
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0002   NV UP DI NG NZ NA
PE NC 
0000:0000 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0004   NV UP DI NG NZ NA
PE NC 
0000:0002 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0006   NV UP DI NG NZ NA
PE NC 
0000:0004 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0008   NV UP DI NG NZ NA
PE NC 
0000:0006 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=000a   NV UP DI NG NZ NA
PE NC 
0000:0008 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=000c   NV UP DI NG NZ NA
PE NC 
0000:000a 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=000e   NV UP DI NG NZ NA
PE NC 
0000:000c 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0010   NV UP DI NG NZ NA
PE NC 
0000:000e 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0012   NV UP DI NG NZ NA
PE NC 
0000:0010 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0014   NV UP DI NG NZ NA
PE NC 
0000:0012 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0016   NV UP DI NG NZ NA
PE NC 
0000:0014 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0018   NV UP DI NG NZ NA
PE NC 
0000:0016 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=001a   NV UP DI NG NZ NA
PE NC 
0000:0018 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=001c   NV UP DI NG NZ NA
PE NC 
0000:001a 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=001e   NV UP DI NG NZ NA
PE NC 
0000:001c 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0020   NV UP DI NG NZ NA
PE NC 
0000:001e 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0022   NV UP DI NG NZ NA
PE NC 
0000:0020 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0024   NV UP DI NG NZ NA
PE NC 
0000:0022 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0026   NV UP DI NG NZ NA
PE NC 
0000:0024 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0028   NV UP DI NG NZ NA
PE NC 
0000:0026 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=002a   NV UP DI NG NZ NA
PE NC 
0000:0028 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=002c   NV UP DI NG NZ NA
PE NC 
0000:002a 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=002e   NV UP DI NG NZ NA
PE NC 
0000:002c 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0030   NV UP DI NG NZ NA
PE NC 
0000:002e 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0032   NV UP DI NG NZ NA
PE NC 
0000:0030 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0034   NV UP DI NG NZ NA
PE NC 
0000:0032 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0036   NV UP DI NG NZ NA
PE NC 
0000:0034 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0038   NV UP DI NG NZ NA
PE NC 
0000:0036 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=003a   NV UP DI NG NZ NA
PE NC 
0000:0038 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=003c   NV UP DI NG NZ NA
PE NC 
0000:003a 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=003e   NV UP DI NG NZ NA
PE NC 
0000:003c 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0040   NV UP DI NG NZ NA
PE NC 
0000:003e 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0042   NV UP DI NG NZ NA
PE NC 
0000:0040 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0044   NV UP DI NG NZ NA
PE NC 
0000:0042 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0046   NV UP DI NG NZ NA
PE NC 
0000:0044 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0048   NV UP DI NG NZ NA
PE NC 
0000:0046 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=004a   NV UP DI NG NZ NA
PE NC 
0000:0048 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=004c   NV UP DI NG NZ NA
PE NC 
0000:004a 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=004e   NV UP DI NG NZ NA
PE NC 
0000:004c 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0050   NV UP DI NG NZ NA
PE NC 
0000:004e 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0052   NV UP DI NG NZ NA
PE NC 
0000:0050 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0054   NV UP DI NG NZ NA
PE NC 
0000:0052 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0056   NV UP DI NG NZ NA
PE NC 
0000:0054 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0058   NV UP DI NG NZ NA
PE NC 
0000:0056 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=005a   NV UP DI NG NZ NA
PE NC 
0000:0058 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=005c   NV UP DI NG NZ NA
PE NC 
0000:005a 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=005e   NV UP DI NG NZ NA
PE NC 
0000:005c 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0060   NV UP DI NG NZ NA
PE NC 
0000:005e 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0062   NV UP DI NG NZ NA
PE NC 
0000:0060 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0064   NV UP DI NG NZ NA
PE NC 
0000:0062 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0066   NV UP DI NG NZ NA
PE NC 
0000:0064 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0068   NV UP DI NG NZ NA
PE NC 
0000:0066 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=006a   NV UP DI NG NZ NA
PE NC 
0000:0068 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=006c   NV UP DI NG NZ NA
PE NC 
0000:006a 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=006e   NV UP DI NG NZ NA
PE NC 
0000:006c 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0070   NV UP DI NG NZ NA
PE NC 
0000:006e 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0072   NV UP DI NG NZ NA
PE NC 
0000:0070 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0074   NV UP DI NG NZ NA
PE NC 
0000:0072 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0076   NV UP DI NG NZ NA
PE NC 
0000:0074 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0078   NV UP DI NG NZ NA
PE NC 
0000:0076 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=007a   NV UP DI NG NZ NA
PE NC 
0000:0078 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=007c   NV UP DI NG NZ NA
PE NC 
0000:007a 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=007e   NV UP DI NG NZ NA
PE NC 
0000:007c 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0080   NV UP DI NG NZ NA
PE NC 
0000:007e 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0082   NV UP DI NG NZ NA
PE NC 
0000:0080 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0084   NV UP DI NG NZ NA
PE NC 
0000:0082 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0086   NV UP DI NG NZ NA
PE NC 
0000:0084 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0088   NV UP DI NG NZ NA
PE NC 
0000:0086 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=008a   NV UP DI NG NZ NA
PE NC 
0000:0088 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=008c   NV UP DI NG NZ NA
PE NC 
0000:008a 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=008e   NV UP DI NG NZ NA
PE NC 
0000:008c 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0090   NV UP DI NG NZ NA
PE NC 
0000:008e 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0092   NV UP DI NG NZ NA
PE NC 
0000:0090 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0094   NV UP DI NG NZ NA
PE NC 
0000:0092 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0096   NV UP DI NG NZ NA
PE NC 
0000:0094 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0098   NV UP DI NG NZ NA
PE NC 
0000:0096 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=009a   NV UP DI NG NZ NA
PE NC 
0000:0098 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=009c   NV UP DI NG NZ NA
PE NC 
0000:009a 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=009e   NV UP DI NG NZ NA
PE NC 
0000:009c 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00a0   NV UP DI NG NZ NA
PE NC 
0000:009e 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00a2   NV UP DI NG NZ NA
PE NC 
0000:00a0 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00a4   NV UP DI NG NZ NA
PE NC 
0000:00a2 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00a6   NV UP DI NG NZ NA
PE NC 
0000:00a4 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00a8   NV UP DI NG NZ NA
PE NC 
0000:00a6 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00aa   NV UP DI NG NZ NA
PE NC 
0000:00a8 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00ac   NV UP DI NG NZ NA
PE NC 
0000:00aa 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00ae   NV UP DI NG NZ NA
PE NC 
0000:00ac 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00b0   NV UP DI NG NZ NA
PE NC 
0000:00ae 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00b2   NV UP DI NG NZ NA
PE NC 
0000:00b0 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00b4   NV UP DI NG NZ NA
PE NC 
0000:00b2 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00b6   NV UP DI NG NZ NA
PE NC 
0000:00b4 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00b8   NV UP DI NG NZ NA
PE NC 
0000:00b6 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00ba   NV UP DI NG NZ NA
PE NC 
0000:00b8 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00bc   NV UP DI NG NZ NA
PE NC 
0000:00ba 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00be   NV UP DI NG NZ NA
PE NC 
0000:00bc 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00c0   NV UP DI NG NZ NA
PE NC 
0000:00be 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00c2   NV UP DI NG NZ NA
PE NC 
0000:00c0 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00c4   NV UP DI NG NZ NA
PE NC 
0000:00c2 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00c6   NV UP DI NG NZ NA
PE NC 
0000:00c4 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00c8   NV UP DI NG NZ NA
PE NC 
0000:00c6 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00ca   NV UP DI NG NZ NA
PE NC 
0000:00c8 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00cc   NV UP DI NG NZ NA
PE NC 
0000:00ca 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00ce   NV UP DI NG NZ NA
PE NC 
0000:00cc 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00d0   NV UP DI NG NZ NA
PE NC 
0000:00ce 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00d2   NV UP DI NG NZ NA
PE NC 
0000:00d0 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00d4   NV UP DI NG NZ NA
PE NC 
0000:00d2 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00d6   NV UP DI NG NZ NA
PE NC 
0000:00d4 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00d8   NV UP DI NG NZ NA
PE NC 
0000:00d6 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00da   NV UP DI NG NZ NA
PE NC 
0000:00d8 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00dc   NV UP DI NG NZ NA
PE NC 
0000:00da 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00de   NV UP DI NG NZ NA
PE NC 
0000:00dc 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00e0   NV UP DI NG NZ NA
PE NC 
0000:00de 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00e2   NV UP DI NG NZ NA
PE NC 
0000:00e0 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00e4   NV UP DI NG NZ NA
PE NC 
0000:00e2 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00e6   NV UP DI NG NZ NA
PE NC 
0000:00e4 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00e8   NV UP DI NG NZ NA
PE NC 
0000:00e6 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00ea   NV UP DI NG NZ NA
PE NC 
0000:00e8 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00ec   NV UP DI NG NZ NA
PE NC 
0000:00ea 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00ee   NV UP DI NG NZ NA
PE NC 
0000:00ec 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00f0   NV UP DI NG NZ NA
PE NC 
0000:00ee 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00f2   NV UP DI NG NZ NA
PE NC 
0000:00f0 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00f4   NV UP DI NG NZ NA
PE NC 
0000:00f2 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00f6   NV UP DI NG NZ NA
PE NC 
0000:00f4 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00f8   NV UP DI NG NZ NA
PE NC 
0000:00f6 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00fa   NV UP DI NG NZ NA
PE NC 
0000:00f8 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00fc   NV UP DI NG NZ NA
PE NC 
0000:00fa 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00fe   NV UP DI NG NZ NA
PE NC 
0000:00fc 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0100   NV UP DI NG NZ NA
PE NC 
0000:00fe 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0102   NV UP DI NG NZ NA
PE NC 
0000:0100 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0104   NV UP DI NG NZ NA
PE NC 
0000:0102 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0106   NV UP DI NG NZ NA
PE NC 
0000:0104 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0108   NV UP DI NG NZ NA
PE NC 
0000:0106 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=010a   NV UP DI NG NZ NA
PE NC 
0000:0108 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=010c   NV UP DI NG NZ NA
PE NC 
0000:010a 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=010e   NV UP DI NG NZ NA
PE NC 
0000:010c 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0110   NV UP DI NG NZ NA
PE NC 
0000:010e 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0112   NV UP DI NG NZ NA
PE NC 
0000:0110 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0114   NV UP DI NG NZ NA
PE NC 
0000:0112 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0116   NV UP DI NG NZ NA
PE NC 
0000:0114 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0118   NV UP DI NG NZ NA
PE NC 
0000:0116 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=011a   NV UP DI NG NZ NA
PE NC 
0000:0118 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=011c   NV UP DI NG NZ NA
PE NC 
0000:011a 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=011e   NV UP DI NG NZ NA
PE NC 
0000:011c 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0120   NV UP DI NG NZ NA
PE NC 
0000:011e 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0122   NV UP DI NG NZ NA
PE NC 
0000:0120 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0124   NV UP DI NG NZ NA
PE NC 
0000:0122 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0126   NV UP DI NG NZ NA
PE NC 
0000:0124 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0128   NV UP DI NG NZ NA
PE NC 
0000:0126 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=012a   NV UP DI NG NZ NA
PE NC 
0000:0128 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=012c   NV UP DI NG NZ NA
PE NC 
0000:012a 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=012e   NV UP DI NG NZ NA
PE NC 
0000:012c 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0130   NV UP DI NG NZ NA
PE NC  

-----Original Message-----
From: Dave Aubin 
Sent: Friday, October 08, 2004 11:40 AM
To: 'Li-Ta Lo'
Cc: LinuxBIOS
Subject: RE: testbios loops?

Here is a dump of the following:
/usr/bin/testbios -s 65536 -d 0x200 --abseg /dev/mem
/usr/bin/nv6800gt.bin -t

I slightly different behavior with this incantation.  Normally I leave
off The -d 0x200.  My device is located off of 2:0:0.

running file /usr/bin/nv6800gt.bin
No base specified. defaulting to 0xc0000 No initial code segment
specified. defaulting to 0xc000 No initial instruction pointer
specified. defaulting to 0x0003 Switching to single step mode.
	AX=0200  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=0005   NV UP DI PL NZ NA
PO NC 
c000:0003 eb4b                JMP	50
	AX=0200  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=0053   NV UP DI PL NZ NA
PO NC 
c000:0050 e99cd4              JMP	d4ef
	AX=0200  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=d4f0   NV UP DI PL NZ NA
PO NC 
c000:d4ef 2e                  CS:
	AX=0200  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=d4f5   NV UP DI PL NZ NA
PO NC 
c000:d4f0 f606480001          TEST	BYTE PTR [0048],01
	AX=0200  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=d4f7   NV UP DI PL ZR NA
PE NC 
c000:d4f5 742d                JZ	d524
	AX=0200  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=d525   NV UP DI PL ZR NA
PE NC 
c000:d524 55                  PUSH	BP
	AX=0200  BX=0000  CX=0000  DX=0080  SP=fff6  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=d526   NV UP DI PL ZR NA
PE NC 
c000:d525 50                  PUSH	AX
	AX=0200  BX=0000  CX=0000  DX=0080  SP=fff4  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=d529   NV UP DI PL ZR NA
PE NC 
c000:d526 e85afa              CALL	cf83
	AX=0200  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=cf84   NV UP DI PL ZR NA
PE NC 
c000:cf83 60                  PUSHA
	AX=0200  BX=0000  CX=0000  DX=0080  SP=ffe2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=cf87   NV UP DI PL ZR NA
PE NC 
c000:cf84 bac303              MOV	DX,3c3
	AX=0200  BX=0000  CX=0000  DX=03c3  SP=ffe2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=cf89   NV UP DI PL ZR NA
PE NC 
c000:cf87 b001                MOV	AL,1
	AX=0201  BX=0000  CX=0000  DX=03c3  SP=ffe2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=cf8a   NV UP DI PL ZR NA
PE NC 
c000:cf89 ee                  OUT	DX,AL
	AX=0201  BX=0000  CX=0000  DX=03c3  SP=ffe2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=cf8b   NV UP DI PL ZR NA
PE NC 
c000:cf8a ed                  IN	AX,DX
	AX=0001  BX=0000  CX=0000  DX=03c3  SP=ffe2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=cf8e   NV UP DI PL ZR NA
PE NC 
c000:cf8b bacc03              MOV	DX,3cc
	AX=0001  BX=0000  CX=0000  DX=03cc  SP=ffe2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=cf8f   NV UP DI PL ZR NA
PE NC 
c000:cf8e ec                  IN	AL,DX
	AX=0000  BX=0000  CX=0000  DX=03cc  SP=ffe2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=cf91   NV UP DI PL ZR NA
PE NC 
c000:cf8f 0c01                OR	AL,1
	AX=0001  BX=0000  CX=0000  DX=03cc  SP=ffe2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=cf94   NV UP DI PL NZ NA
PO NC 
c000:cf91 bac203              MOV	DX,3c2
	AX=0001  BX=0000  CX=0000  DX=03c2  SP=ffe2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=cf95   NV UP DI PL NZ NA
PO NC 
c000:cf94 ee                  OUT	DX,AL
	AX=0001  BX=0000  CX=0000  DX=03c2  SP=ffe2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=cf98   NV UP DI PL NZ NA
PO NC 
c000:cf95 bac303              MOV	DX,3c3
	AX=0001  BX=0000  CX=0000  DX=03c3  SP=ffe2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=cf99   NV UP DI PL NZ NA
PO NC 
c000:cf98 ec                  IN	AL,DX
	AX=0001  BX=0000  CX=0000  DX=03c3  SP=ffe2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=cf9c   NV UP DI PL NZ NA
PO NC 
c000:cf99 e82675              CALL	44c2
	AX=0001  BX=0000  CX=0000  DX=03c3  SP=ffe0  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=44c3   NV UP DI PL NZ NA
PO NC 
c000:44c2 50                  PUSH	AX
	AX=0001  BX=0000  CX=0000  DX=03c3  SP=ffde  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=44c4   NV UP DI PL NZ NA
PO NC 
c000:44c3 52                  PUSH	DX
	AX=0001  BX=0000  CX=0000  DX=03c3  SP=ffdc  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=44c7   NV UP DI PL NZ NA
PO NC 
c000:44c4 e833d3              CALL	17fa
	AX=0001  BX=0000  CX=0000  DX=03c3  SP=ffda  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=17fb   NV UP DI PL NZ NA
PO NC 
c000:17fa 50                  PUSH	AX
	AX=0001  BX=0000  CX=0000  DX=03c3  SP=ffd8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=17fe   NV UP DI PL NZ NA
PO NC 
c000:17fb bacc03              MOV	DX,3cc
	AX=0001  BX=0000  CX=0000  DX=03cc  SP=ffd8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=17ff   NV UP DI PL NZ NA
PO NC 
c000:17fe ec                  IN	AL,DX
	AX=0001  BX=0000  CX=0000  DX=03cc  SP=ffd8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=1802   NV UP DI PL NZ NA
PO NC 
c000:17ff bab403              MOV	DX,3b4
	AX=0001  BX=0000  CX=0000  DX=03b4  SP=ffd8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=1804   NV UP DI PL NZ NA
PO NC 
c000:1802 a801                TEST	AL,0001
	AX=0001  BX=0000  CX=0000  DX=03b4  SP=ffd8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=1806   NV UP DI PL NZ NA
PO NC 
c000:1804 7402                JZ	1808
	AX=0001  BX=0000  CX=0000  DX=03b4  SP=ffd8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=1808   NV UP DI PL NZ NA
PO NC 
c000:1806 b2d4                MOV	DL,d4
	AX=0001  BX=0000  CX=0000  DX=03d4  SP=ffd8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=1809   NV UP DI PL NZ NA
PO NC 
c000:1808 58                  POP	AX
	AX=0001  BX=0000  CX=0000  DX=03d4  SP=ffda  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=180a   NV UP DI PL NZ NA
PO NC 
c000:1809 c3                  RET
	AX=0001  BX=0000  CX=0000  DX=03d4  SP=ffdc  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=44c8   NV UP DI PL NZ NA
PO NC 
c000:44c7 ec                  IN	AL,DX
	AX=0000  BX=0000  CX=0000  DX=03d4  SP=ffdc  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=44c9   NV UP DI PL NZ NA
PO NC 
c000:44c8 50                  PUSH	AX
	AX=0000  BX=0000  CX=0000  DX=03d4  SP=ffda  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=44ca   NV UP DI PL NZ NA
PO NC 
c000:44c9 53                  PUSH	BX
	AX=0000  BX=0000  CX=0000  DX=03d4  SP=ffd8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=44cc   NV UP DI PL NZ NA
PO NC 
c000:44ca b01f                MOV	AL,1f
	AX=001f  BX=0000  CX=0000  DX=03d4  SP=ffd8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=44cf   NV UP DI PL NZ NA
PO NC 
c000:44cc e8f8d0              CALL	15c7
	AX=001f  BX=0000  CX=0000  DX=03d4  SP=ffd6  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=15ca   NV UP DI PL NZ NA
PO NC 
c000:15c7 e83002              CALL	17fa
	AX=001f  BX=0000  CX=0000  DX=03d4  SP=ffd4  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=17fb   NV UP DI PL NZ NA
PO NC 
c000:17fa 50                  PUSH	AX
	AX=001f  BX=0000  CX=0000  DX=03d4  SP=ffd2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=17fe   NV UP DI PL NZ NA
PO NC 
c000:17fb bacc03              MOV	DX,3cc
	AX=001f  BX=0000  CX=0000  DX=03cc  SP=ffd2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=17ff   NV UP DI PL NZ NA
PO NC 
c000:17fe ec                  IN	AL,DX
	AX=0001  BX=0000  CX=0000  DX=03cc  SP=ffd2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=1802   NV UP DI PL NZ NA
PO NC 
c000:17ff bab403              MOV	DX,3b4
	AX=0001  BX=0000  CX=0000  DX=03b4  SP=ffd2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=1804   NV UP DI PL NZ NA
PO NC 
c000:1802 a801                TEST	AL,0001
	AX=0001  BX=0000  CX=0000  DX=03b4  SP=ffd2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=1806   NV UP DI PL NZ NA
PO NC 
c000:1804 7402                JZ	1808
	AX=0001  BX=0000  CX=0000  DX=03b4  SP=ffd2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=1808   NV UP DI PL NZ NA
PO NC 
c000:1806 b2d4                MOV	DL,d4
	AX=0001  BX=0000  CX=0000  DX=03d4  SP=ffd2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=1809   NV UP DI PL NZ NA
PO NC 
c000:1808 58                  POP	AX
	AX=001f  BX=0000  CX=0000  DX=03d4  SP=ffd4  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=180a   NV UP DI PL NZ NA
PO NC 
c000:1809 c3                  RET
	AX=001f  BX=0000  CX=0000  DX=03d4  SP=ffd6  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=15cb   NV UP DI PL NZ NA
PO NC 
c000:15ca ee                  OUT	DX,AL
	AX=001f  BX=0000  CX=0000  DX=03d4  SP=ffd6  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=15cc   NV UP DI PL NZ NA
PO NC 
c000:15cb ed                  IN	AX,DX
	AX=001f  BX=0000  CX=0000  DX=03d4  SP=ffd6  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=15cd   NV UP DI PL NZ NA
PO NC 
c000:15cc c3                  RET
	AX=001f  BX=0000  CX=0000  DX=03d4  SP=ffd8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=44d2   NV UP DI PL NZ NA
PO NC 
c000:44cf 80e401              AND	AH,1
	AX=001f  BX=0000  CX=0000  DX=03d4  SP=ffd8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=44d4   NV UP DI PL ZR NA
PE NC 
c000:44d2 8afc                MOV	BH,AH
	AX=001f  BX=0000  CX=0000  DX=03d4  SP=ffd8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=44d7   NV UP DI PL ZR NA
PE NC 
c000:44d4 b82c01              MOV	AX,12c
	AX=012c  BX=0000  CX=0000  DX=03d4  SP=ffd8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=44d9   NV UP DI PL ZR NA
PE NC 
c000:44d7 0aff                OR	BH,BH
	AX=012c  BX=0000  CX=0000  DX=03d4  SP=ffd8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=44db   NV UP DI PL ZR NA
PE NC 
c000:44d9 7405                JZ	44e0
	AX=012c  BX=0000  CX=0000  DX=03d4  SP=ffd8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=44e3   NV UP DI PL ZR NA
PE NC 
c000:44e0 e8350d              CALL	5218
	AX=012c  BX=0000  CX=0000  DX=03d4  SP=ffd6  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=521a   NV UP DI PL ZR NA
PE NC 
c000:5218 f6d4                NOT	AH
	AX=fe2c  BX=0000  CX=0000  DX=03d4  SP=ffd6  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=521b   NV UP DI PL ZR NA
PE NC 
c000:521a 52                  PUSH	DX
	AX=fe2c  BX=0000  CX=0000  DX=03d4  SP=ffd4  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=521c   NV UP DI PL ZR NA
PE NC 
c000:521b 50                  PUSH	AX
	AX=fe2c  BX=0000  CX=0000  DX=03d4  SP=ffd2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=521f   NV UP DI PL ZR NA
PE NC 
c000:521c e890ff              CALL	51af
	AX=fe2c  BX=0000  CX=0000  DX=03d4  SP=ffd0  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=51b0   NV UP DI PL ZR NA
PE NC 
c000:51af 53                  PUSH	BX
	AX=fe2c  BX=0000  CX=0000  DX=03d4  SP=ffce  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=51b1   NV UP DI PL ZR NA
PE NC 
c000:51b0 93                  XCHG	AX,BX
	AX=0000  BX=fe2c  CX=0000  DX=03d4  SP=ffce  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=51b4   NV UP DI PL ZR NA
PE NC 
c000:51b1 e8e3ff              CALL	5197
	AX=0000  BX=fe2c  CX=0000  DX=03d4  SP=ffcc  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=5199   NV UP DI PL ZR NA
PE NC 
c000:5197 32e4                XOR	AH,AH
	AX=0000  BX=fe2c  CX=0000  DX=03d4  SP=ffcc  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=519c   NV UP DI PL ZR NA
PE NC 
c000:5199 e8deff              CALL	517a
	AX=0000  BX=fe2c  CX=0000  DX=03d4  SP=ffca  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=517b   NV UP DI PL ZR NA
PE NC 
c000:517a 9c                  PUSHF
	AX=0000  BX=fe2c  CX=0000  DX=03d4  SP=ffc8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=517c   NV UP DI PL ZR NA
PE NC 
c000:517b 52                  PUSH	DX
	AX=0000  BX=fe2c  CX=0000  DX=03d4  SP=ffc6  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=517d   NV UP DI PL ZR NA
PE NC 
c000:517c 53                  PUSH	BX
	AX=0000  BX=fe2c  CX=0000  DX=03d4  SP=ffc4  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=517f   NV UP DI PL ZR NA
PE NC 
c000:517d 8bd8                MOV	BX,AX
	AX=0000  BX=0000  CX=0000  DX=03d4  SP=ffc4  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=5181   NV UP DI PL ZR NA
PE NC 
c000:517f b044                MOV	AL,44
	AX=0044  BX=0000  CX=0000  DX=03d4  SP=ffc4  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=5184   NV UP DI PL ZR NA
PE NC 
c000:5181 e843c4              CALL	15c7
	AX=0044  BX=0000  CX=0000  DX=03d4  SP=ffc2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=15ca   NV UP DI PL ZR NA
PE NC 
c000:15c7 e83002              CALL	17fa
	AX=0044  BX=0000  CX=0000  DX=03d4  SP=ffc0  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=17fb   NV UP DI PL ZR NA
PE NC 
c000:17fa 50                  PUSH	AX
	AX=0044  BX=0000  CX=0000  DX=03d4  SP=ffbe  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=17fe   NV UP DI PL ZR NA
PE NC 
c000:17fb bacc03              MOV	DX,3cc
	AX=0044  BX=0000  CX=0000  DX=03cc  SP=ffbe  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=17ff   NV UP DI PL ZR NA
PE NC 
c000:17fe ec                  IN	AL,DX
	AX=0001  BX=0000  CX=0000  DX=03cc  SP=ffbe  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=1802   NV UP DI PL ZR NA
PE NC 
c000:17ff bab403              MOV	DX,3b4
	AX=0001  BX=0000  CX=0000  DX=03b4  SP=ffbe  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=1804   NV UP DI PL ZR NA
PE NC 
c000:1802 a801                TEST	AL,0001
	AX=0001  BX=0000  CX=0000  DX=03b4  SP=ffbe  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=1806   NV UP DI PL NZ NA
PO NC 
c000:1804 7402                JZ	1808
	AX=0001  BX=0000  CX=0000  DX=03b4  SP=ffbe  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=1808   NV UP DI PL NZ NA
PO NC 
c000:1806 b2d4                MOV	DL,d4
	AX=0001  BX=0000  CX=0000  DX=03d4  SP=ffbe  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=1809   NV UP DI PL NZ NA
PO NC 
c000:1808 58                  POP	AX
	AX=0044  BX=0000  CX=0000  DX=03d4  SP=ffc0  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=180a   NV UP DI PL NZ NA
PO NC 
c000:1809 c3                  RET
	AX=0044  BX=0000  CX=0000  DX=03d4  SP=ffc2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=15cb   NV UP DI PL NZ NA
PO NC 
c000:15ca ee                  OUT	DX,AL
	AX=0044  BX=0000  CX=0000  DX=03d4  SP=ffc2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=15cc   NV UP DI PL NZ NA
PO NC 
c000:15cb ed                  IN	AX,DX
	AX=0044  BX=0000  CX=0000  DX=03d4  SP=ffc2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=15cd   NV UP DI PL NZ NA
PO NC 
c000:15cc c3                  RET
	AX=0044  BX=0000  CX=0000  DX=03d4  SP=ffc4  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=5185   NV UP DI PL NZ NA
PO NC 
c000:5184 50                  PUSH	AX
	AX=0044  BX=0000  CX=0000  DX=03d4  SP=ffc2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=5187   NV UP DI PL NZ NA
PO NC 
c000:5185 8ae7                MOV	AH,BH
	AX=0044  BX=0000  CX=0000  DX=03d4  SP=ffc2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=5188   NV UP DI PL NZ NA
PO NC 
c000:5187 ef                  OUT	DX,AX
	AX=0044  BX=0000  CX=0000  DX=03d4  SP=ffc2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=5189   NV UP DI PL NZ NA
PO NC 
c000:5188 58                  POP	AX
	AX=0044  BX=0000  CX=0000  DX=03d4  SP=ffc4  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=518a   NV UP DI PL NZ NA
PO NC 
c000:5189 5b                  POP	BX
	AX=0044  BX=fe2c  CX=0000  DX=03d4  SP=ffc6  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=518b   NV UP DI PL NZ NA
PO NC 
c000:518a 5a                  POP	DX
	AX=0044  BX=fe2c  CX=0000  DX=03d4  SP=ffc8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=518c   NV UP DI PL NZ NA
PO NC 
c000:518b 9d                  POPF
	AX=0044  BX=fe2c  CX=0000  DX=03d4  SP=ffca  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=518d   NV UP DI PL ZR NA
PE NC 
c000:518c c3                  RET
	AX=0044  BX=fe2c  CX=0000  DX=03d4  SP=ffcc  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=519d   NV UP DI PL ZR NA
PE NC 
c000:519c c3                  RET
	AX=0044  BX=fe2c  CX=0000  DX=03d4  SP=ffce  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=51b5   NV UP DI PL ZR NA
PE NC 
c000:51b4 50                  PUSH	AX
	AX=0044  BX=fe2c  CX=0000  DX=03d4  SP=ffcc  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=51b6   NV UP DI PL ZR NA
PE NC 
c000:51b5 93                  XCHG	AX,BX
	AX=fe2c  BX=0044  CX=0000  DX=03d4  SP=ffcc  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=51b9   NV UP DI PL ZR NA
PE NC 
c000:51b6 e80ec4              CALL	15c7
	AX=fe2c  BX=0044  CX=0000  DX=03d4  SP=ffca  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=15ca   NV UP DI PL ZR NA
PE NC 
c000:15c7 e83002              CALL	17fa
	AX=fe2c  BX=0044  CX=0000  DX=03d4  SP=ffc8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=17fb   NV UP DI PL ZR NA
PE NC 
c000:17fa 50                  PUSH	AX
	AX=fe2c  BX=0044  CX=0000  DX=03d4  SP=ffc6  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=17fe   NV UP DI PL ZR NA
PE NC 
 

-----Original Message-----
From: Li-Ta Lo [mailto:ollie at lanl.gov]
Sent: Friday, October 08, 2004 11:14 AM
To: Dave Aubin
Cc: LinuxBIOS
Subject: RE: testbios loops?

On Fri, 2004-10-08 at 09:04, Dave Aubin wrote:
> Hi,
> 
>   Oh it does.  I just left that snippet out.  It starts at the correct
> place:)
> 

Then there is a big problem. The code just to somewhere that is not code
(0000). Can you send more messages ?

Ollie

> -----Original Message-----
> From: Li-Ta Lo [mailto:ollie at lanl.gov]
> Sent: Friday, October 08, 2004 11:02 AM
> To: Dave Aubin
> Cc: LinuxBIOS
> Subject: RE: testbios loops?
> 
> On Fri, 2004-10-08 at 08:58, Dave Aubin wrote:
> > Hi,
> 
> Why it starts from c000:fffd ? It should starts from c000:0003
> 
> Ollie
> 
> > 
> > It will first do this (I'm using the testbios -t option)
> > c000:fffd 0000                ADD       [BX+SI],AL
> >         AX=0200  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000  
> > SI=0000 DI=0000
> >         DS=0040  ES=0000  SS=0030  CS=c000  IP=0002   NV UP DI PL ZR
> NA
> > PE NC 
> > c000:ffff 000000              ADD       -86[DI],DL
> >         AX=0200  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000  
> > SI=0000 DI=0000
> >         DS=0040  ES=0000  SS=0030  CS=c000  IP=0004   NV UP DI NG NZ
> NA
> > PO NC 
> > c000:0002 74eb                JZ        ffef
> >         AX=0200  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000  
> > SI=0000 DI=0000
> >         DS=0040  ES=0000  SS=0030  CS=c000  IP=0005   NV UP DI NG NZ
> NA
> > PO NC 
> > c000:0004 4b                  DEC       BX
> >         AX=0200  BX=ffff  CX=0000  DX=0080  SP=fff8  BP=0000  
> > SI=0000 DI=0000
> >         DS=0040  ES=0000  SS=0030  CS=c000  IP=0006   NV UP DI NG NZ
> AC
> > PE NC 
> > c000:0005 37                  AAA
> >         AX=0306  BX=ffff  CX=0000  DX=0080  SP=fff8  BP=0000  
> > SI=0000 DI=0000
> >         DS=0040  ES=0000  SS=0030  CS=c000  IP=0008   NV UP DI PL NZ
> AC
> > PE CY
> > 
> > Then it will do this:
> > c000:0137 0d0a00              OR        AX,a
> >         AX=debf  BX=ffff  CX=0335  DX=0080  SP=ffef  BP=0000  
> > SI=0004
> > DI=0002
> >         DS=0040  ES=0000  SS=0030  CS=c000  IP=013c   NV UP DI NG NZ
> NA
> > PO NC 
> > c000:013a 0000                ADD       [BX+SI],AL
> >         AX=debf  BX=ffff  CX=0335  DX=0080  SP=ffef  BP=0000  
> > SI=0004
> > DI=0002
> >         DS=0040  ES=0000  SS=0030  CS=c000  IP=013f   NV UP DI NG NZ
> AC
> > PO CY 
> > c000:013c ba9198              MOV       DX,9891
> >         AX=debf  BX=ffff  CX=0335  DX=9891  SP=ffef  BP=0000  
> > SI=0004
> > DI=0002
> >         DS=0040  ES=0000  SS=0030  CS=c000  IP=0140   NV UP DI NG NZ
> AC
> > PO CY 
> > c000:013f 96                  XCHG      AX,SI
> >         AX=0004  BX=ffff  CX=0335  DX=9891  SP=ffef  BP=0000  
> > SI=debf
> > DI=0002
> >         DS=0040  ES=0000  SS=0030  CS=c000  IP=0141   NV UP DI NG NZ
> AC
> > PO CY 
> > c000:0140 91                  XCHG      AX,CX
> >         AX=0335  BX=ffff  CX=0004  DX=9891  SP=ffef  BP=0000  
> > SI=debf
> > DI=0002
> >         DS=0040  ES=0000  SS=0030  CS=c000  IP=0146   NV UP DI NG NZ
> AC
> > PO CY 
> > c000:0141 9a9a8d9691          CALL      9196:8d9a
> >         AX=0335  BX=ffff  CX=0004  DX=9891  SP=ffeb  BP=0000  
> > SI=debf
> > DI=0002
> >         DS=0040  ES=0000  SS=0030  CS=9196  IP=8d9c   NV UP DI NG NZ
> AC
> > PO CY 
> > 9196:8d9a 0000                ADD       [BX+SI],AL
> >         AX=0335  BX=ffff  CX=0004  DX=9891  SP=ffeb  BP=0000  
> > SI=debf
> > DI=0002
> >         DS=0040  ES=0000  SS=0030  CS=9196  IP=8d9e   NV UP DI PL NZ
> NA
> > PE NC 
> > 9196:8d9c 0000                ADD       [BX+SI],AL
> >         AX=0335  BX=ffff  CX=0004  DX=9891  SP=ffeb  BP=0000  
> > SI=debf
> > DI=0002
> >         DS=0040  ES=0000  SS=0030  CS=9196  IP=8da0   NV UP DI PL NZ
> NA
> > PE NC
> > 
> > I'm still looking for the openbios utility.  So far found broken 
> > links:( I can get some other bios to work, but they appear to be 
> > flacky.  I really think I should be using the one that came 
> > programmed
> 
> > on the board.
> > 
> > Thanks,
> > Dave
> > 
> > -----Original Message-----
> > From: Li-Ta Lo [mailto:ollie at lanl.gov]
> > Sent: Friday, October 08, 2004 10:53 AM
> > To: Dave Aubin
> > Cc: LinuxBIOS
> > Subject: Re: testbios loops?
> > 
> > On Fri, 2004-10-08 at 08:35, Dave Aubin wrote:
> > > Hi,
> > >  
> > >   I went back to trying to get the Nvida 6800gt card's bios, but 
> > > still
> > 
> > > even with dd -if=/dev/mem of=vgabios.rom skip=786432 bs=1
> > > count=32768 I get the same binary as dd -if=/dev/mem 
> > > of=vgabios.rom
> > > skip=1536 count=64.
> > > I used dhex (free util) to verify they are the same.
> > >   What happens when I run them trough testbios is that once it is 
> > > done
> > 
> > > programming 0xc7fff it jump to 0x9 something or other and the 
> > > video bios isn't programmed correctly.
> > 
> > 
> > What do you mean by 'programming oxc7ff it jump to 0x9' ?
> > 
> > Ollie
> > 
> > 
> > 
> 
> 



From daubin at actuality-systems.com  Fri Oct  8 13:25:01 2004
From: daubin at actuality-systems.com (Dave Aubin)
Date: Fri Oct  8 13:25:01 2004
Subject: testbios loops?
Message-ID: <E8F8DBCB0468204E856114A2CD20741F2C1828@mail.local.ActualitySystems.com>

I now have it working. 
I had to use a ... Gasp dos tool to help me!

I suspected the linux dd wasn't retrieving the rom correctly
For some reason either linux didn't copy the rom correctly
Or it got modified after linux ran or what have you.
So I found this nvflash utility from 
http://www.nvplanet.com/modules.php?name=Downloads&d_op=viewdownload&cid
=10

I had to a dos boot disk.  I picked 6.22 from:
http://www.bootdisk.com/bootdisk.htm

Removed all things qbasic to free up some room.
Then copied over the nvflash utilities and rebooted
A windows machine with said graphics card.
Ran the utility nvflash --save nv6800w.rom (remember 8.3 format here)

I then compared the linux retrieved image with the nvflash
Image and they were slightly different at first by a byte or two,
Then got progressively different as the file went on.

So what this means is the dd method might not always work, but this
Dos method did do the trick.  Good news is it seems to work with 
A lot of nvidia roms:)

Hope this helps.  

Thanks,
Dave:)

-----Original Message-----
From: Dave Aubin 
Sent: Friday, October 08, 2004 1:36 PM
To: Dave Aubin; Li-Ta Lo
Cc: LinuxBIOS
Subject: RE: testbios loops?

Update...

Well the last complete trace I sent was due to only having 32k
And not 64k of the image.  Weird is that iomem shows linux as using
Only 0xc0000 to 0xc7fff which is 32k.  Now when I excute a 64k
Code size it eventually loops, but takes a bit longer.  What's
Really funny is that appears the image is doing nothing of interest.
Here is a snap shot of what I mean.  It just keeps adding BX+SI which
Are both 0.

Any ideas???

Thanks,
Dave

running file vgabios-1k.rom
No base specified. defaulting to 0xc0000
No initial code segment specified. defaulting to 0xc000
No initial instruction pointer specified. defaulting to 0x0003
Switching to single step mode.
	AX=00ff  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=0005   NV UP DI PL NZ NA
PO NC 
c000:0003 eb4b                JMP	50
	AX=00ff  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=0053   NV UP DI PL NZ NA
PO NC 
c000:0050 e9bcd4              JMP	d50f
	AX=00ff  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=d511   NV UP DI PL NZ NA
PO NC 
c000:d50f 1818                SBB	[BX+SI],BL
	AX=00ff  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=d513   NV UP DI PL ZR NA
PE NC 
c000:d511 0000                ADD	[BX+SI],AL
	AX=00ff  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=d516   NV UP DI NG NZ NA
PE NC 
c000:d513 3366cc              XOR	SP,-52[BP]
	AX=00ff  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=d517   NV UP DI NG NZ NA
PO NC 
c000:d516 66                  DATA:
	AX=00ff  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=d519   NV UP DI NG NZ NA
PO NC 
c000:d517 3300                XOR	EAX,[BX+SI]
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=d51b   NV UP DI PL ZR NA
PE NC 
c000:d519 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=d51c   NV UP DI NG NZ NA
PE NC 
c000:d51b cc                  INT 3
int3 vector at 0
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0002   NV UP DI NG NZ NA
PE NC 
0000:0000 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0004   NV UP DI NG NZ NA
PE NC 
0000:0002 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0006   NV UP DI NG NZ NA
PE NC 
0000:0004 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0008   NV UP DI NG NZ NA
PE NC 
0000:0006 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=000a   NV UP DI NG NZ NA
PE NC 
0000:0008 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=000c   NV UP DI NG NZ NA
PE NC 
0000:000a 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=000e   NV UP DI NG NZ NA
PE NC 
0000:000c 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0010   NV UP DI NG NZ NA
PE NC 
0000:000e 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0012   NV UP DI NG NZ NA
PE NC 
0000:0010 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0014   NV UP DI NG NZ NA
PE NC 
0000:0012 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0016   NV UP DI NG NZ NA
PE NC 
0000:0014 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0018   NV UP DI NG NZ NA
PE NC 
0000:0016 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=001a   NV UP DI NG NZ NA
PE NC 
0000:0018 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=001c   NV UP DI NG NZ NA
PE NC 
0000:001a 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=001e   NV UP DI NG NZ NA
PE NC 
0000:001c 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0020   NV UP DI NG NZ NA
PE NC 
0000:001e 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0022   NV UP DI NG NZ NA
PE NC 
0000:0020 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0024   NV UP DI NG NZ NA
PE NC 
0000:0022 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0026   NV UP DI NG NZ NA
PE NC 
0000:0024 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0028   NV UP DI NG NZ NA
PE NC 
0000:0026 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=002a   NV UP DI NG NZ NA
PE NC 
0000:0028 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=002c   NV UP DI NG NZ NA
PE NC 
0000:002a 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=002e   NV UP DI NG NZ NA
PE NC 
0000:002c 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0030   NV UP DI NG NZ NA
PE NC 
0000:002e 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0032   NV UP DI NG NZ NA
PE NC 
0000:0030 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0034   NV UP DI NG NZ NA
PE NC 
0000:0032 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0036   NV UP DI NG NZ NA
PE NC 
0000:0034 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0038   NV UP DI NG NZ NA
PE NC 
0000:0036 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=003a   NV UP DI NG NZ NA
PE NC 
0000:0038 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=003c   NV UP DI NG NZ NA
PE NC 
0000:003a 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=003e   NV UP DI NG NZ NA
PE NC 
0000:003c 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0040   NV UP DI NG NZ NA
PE NC 
0000:003e 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0042   NV UP DI NG NZ NA
PE NC 
0000:0040 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0044   NV UP DI NG NZ NA
PE NC 
0000:0042 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0046   NV UP DI NG NZ NA
PE NC 
0000:0044 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0048   NV UP DI NG NZ NA
PE NC 
0000:0046 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=004a   NV UP DI NG NZ NA
PE NC 
0000:0048 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=004c   NV UP DI NG NZ NA
PE NC 
0000:004a 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=004e   NV UP DI NG NZ NA
PE NC 
0000:004c 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0050   NV UP DI NG NZ NA
PE NC 
0000:004e 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0052   NV UP DI NG NZ NA
PE NC 
0000:0050 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0054   NV UP DI NG NZ NA
PE NC 
0000:0052 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0056   NV UP DI NG NZ NA
PE NC 
0000:0054 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0058   NV UP DI NG NZ NA
PE NC 
0000:0056 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=005a   NV UP DI NG NZ NA
PE NC 
0000:0058 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=005c   NV UP DI NG NZ NA
PE NC 
0000:005a 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=005e   NV UP DI NG NZ NA
PE NC 
0000:005c 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0060   NV UP DI NG NZ NA
PE NC 
0000:005e 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0062   NV UP DI NG NZ NA
PE NC 
0000:0060 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0064   NV UP DI NG NZ NA
PE NC 
0000:0062 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0066   NV UP DI NG NZ NA
PE NC 
0000:0064 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0068   NV UP DI NG NZ NA
PE NC 
0000:0066 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=006a   NV UP DI NG NZ NA
PE NC 
0000:0068 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=006c   NV UP DI NG NZ NA
PE NC 
0000:006a 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=006e   NV UP DI NG NZ NA
PE NC 
0000:006c 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0070   NV UP DI NG NZ NA
PE NC 
0000:006e 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0072   NV UP DI NG NZ NA
PE NC 
0000:0070 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0074   NV UP DI NG NZ NA
PE NC 
0000:0072 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0076   NV UP DI NG NZ NA
PE NC 
0000:0074 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0078   NV UP DI NG NZ NA
PE NC 
0000:0076 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=007a   NV UP DI NG NZ NA
PE NC 
0000:0078 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=007c   NV UP DI NG NZ NA
PE NC 
0000:007a 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=007e   NV UP DI NG NZ NA
PE NC 
0000:007c 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0080   NV UP DI NG NZ NA
PE NC 
0000:007e 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0082   NV UP DI NG NZ NA
PE NC 
0000:0080 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0084   NV UP DI NG NZ NA
PE NC 
0000:0082 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0086   NV UP DI NG NZ NA
PE NC 
0000:0084 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0088   NV UP DI NG NZ NA
PE NC 
0000:0086 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=008a   NV UP DI NG NZ NA
PE NC 
0000:0088 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=008c   NV UP DI NG NZ NA
PE NC 
0000:008a 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=008e   NV UP DI NG NZ NA
PE NC 
0000:008c 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0090   NV UP DI NG NZ NA
PE NC 
0000:008e 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0092   NV UP DI NG NZ NA
PE NC 
0000:0090 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0094   NV UP DI NG NZ NA
PE NC 
0000:0092 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0096   NV UP DI NG NZ NA
PE NC 
0000:0094 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0098   NV UP DI NG NZ NA
PE NC 
0000:0096 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=009a   NV UP DI NG NZ NA
PE NC 
0000:0098 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=009c   NV UP DI NG NZ NA
PE NC 
0000:009a 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=009e   NV UP DI NG NZ NA
PE NC 
0000:009c 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00a0   NV UP DI NG NZ NA
PE NC 
0000:009e 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00a2   NV UP DI NG NZ NA
PE NC 
0000:00a0 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00a4   NV UP DI NG NZ NA
PE NC 
0000:00a2 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00a6   NV UP DI NG NZ NA
PE NC 
0000:00a4 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00a8   NV UP DI NG NZ NA
PE NC 
0000:00a6 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00aa   NV UP DI NG NZ NA
PE NC 
0000:00a8 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00ac   NV UP DI NG NZ NA
PE NC 
0000:00aa 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00ae   NV UP DI NG NZ NA
PE NC 
0000:00ac 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00b0   NV UP DI NG NZ NA
PE NC 
0000:00ae 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00b2   NV UP DI NG NZ NA
PE NC 
0000:00b0 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00b4   NV UP DI NG NZ NA
PE NC 
0000:00b2 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00b6   NV UP DI NG NZ NA
PE NC 
0000:00b4 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00b8   NV UP DI NG NZ NA
PE NC 
0000:00b6 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00ba   NV UP DI NG NZ NA
PE NC 
0000:00b8 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00bc   NV UP DI NG NZ NA
PE NC 
0000:00ba 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00be   NV UP DI NG NZ NA
PE NC 
0000:00bc 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00c0   NV UP DI NG NZ NA
PE NC 
0000:00be 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00c2   NV UP DI NG NZ NA
PE NC 
0000:00c0 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00c4   NV UP DI NG NZ NA
PE NC 
0000:00c2 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00c6   NV UP DI NG NZ NA
PE NC 
0000:00c4 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00c8   NV UP DI NG NZ NA
PE NC 
0000:00c6 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00ca   NV UP DI NG NZ NA
PE NC 
0000:00c8 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00cc   NV UP DI NG NZ NA
PE NC 
0000:00ca 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00ce   NV UP DI NG NZ NA
PE NC 
0000:00cc 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00d0   NV UP DI NG NZ NA
PE NC 
0000:00ce 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00d2   NV UP DI NG NZ NA
PE NC 
0000:00d0 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00d4   NV UP DI NG NZ NA
PE NC 
0000:00d2 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00d6   NV UP DI NG NZ NA
PE NC 
0000:00d4 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00d8   NV UP DI NG NZ NA
PE NC 
0000:00d6 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00da   NV UP DI NG NZ NA
PE NC 
0000:00d8 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00dc   NV UP DI NG NZ NA
PE NC 
0000:00da 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00de   NV UP DI NG NZ NA
PE NC 
0000:00dc 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00e0   NV UP DI NG NZ NA
PE NC 
0000:00de 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00e2   NV UP DI NG NZ NA
PE NC 
0000:00e0 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00e4   NV UP DI NG NZ NA
PE NC 
0000:00e2 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00e6   NV UP DI NG NZ NA
PE NC 
0000:00e4 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00e8   NV UP DI NG NZ NA
PE NC 
0000:00e6 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00ea   NV UP DI NG NZ NA
PE NC 
0000:00e8 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00ec   NV UP DI NG NZ NA
PE NC 
0000:00ea 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00ee   NV UP DI NG NZ NA
PE NC 
0000:00ec 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00f0   NV UP DI NG NZ NA
PE NC 
0000:00ee 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00f2   NV UP DI NG NZ NA
PE NC 
0000:00f0 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00f4   NV UP DI NG NZ NA
PE NC 
0000:00f2 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00f6   NV UP DI NG NZ NA
PE NC 
0000:00f4 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00f8   NV UP DI NG NZ NA
PE NC 
0000:00f6 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00fa   NV UP DI NG NZ NA
PE NC 
0000:00f8 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00fc   NV UP DI NG NZ NA
PE NC 
0000:00fa 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=00fe   NV UP DI NG NZ NA
PE NC 
0000:00fc 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0100   NV UP DI NG NZ NA
PE NC 
0000:00fe 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0102   NV UP DI NG NZ NA
PE NC 
0000:0100 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0104   NV UP DI NG NZ NA
PE NC 
0000:0102 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0106   NV UP DI NG NZ NA
PE NC 
0000:0104 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0108   NV UP DI NG NZ NA
PE NC 
0000:0106 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=010a   NV UP DI NG NZ NA
PE NC 
0000:0108 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=010c   NV UP DI NG NZ NA
PE NC 
0000:010a 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=010e   NV UP DI NG NZ NA
PE NC 
0000:010c 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0110   NV UP DI NG NZ NA
PE NC 
0000:010e 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0112   NV UP DI NG NZ NA
PE NC 
0000:0110 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0114   NV UP DI NG NZ NA
PE NC 
0000:0112 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0116   NV UP DI NG NZ NA
PE NC 
0000:0114 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0118   NV UP DI NG NZ NA
PE NC 
0000:0116 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=011a   NV UP DI NG NZ NA
PE NC 
0000:0118 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=011c   NV UP DI NG NZ NA
PE NC 
0000:011a 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=011e   NV UP DI NG NZ NA
PE NC 
0000:011c 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0120   NV UP DI NG NZ NA
PE NC 
0000:011e 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0122   NV UP DI NG NZ NA
PE NC 
0000:0120 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0124   NV UP DI NG NZ NA
PE NC 
0000:0122 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0126   NV UP DI NG NZ NA
PE NC 
0000:0124 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0128   NV UP DI NG NZ NA
PE NC 
0000:0126 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=012a   NV UP DI NG NZ NA
PE NC 
0000:0128 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=012c   NV UP DI NG NZ NA
PE NC 
0000:012a 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=012e   NV UP DI NG NZ NA
PE NC 
0000:012c 0000                ADD	[BX+SI],AL
	AX=0000  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=0000  IP=0130   NV UP DI NG NZ NA
PE NC  

-----Original Message-----
From: Dave Aubin 
Sent: Friday, October 08, 2004 11:40 AM
To: 'Li-Ta Lo'
Cc: LinuxBIOS
Subject: RE: testbios loops?

Here is a dump of the following:
/usr/bin/testbios -s 65536 -d 0x200 --abseg /dev/mem
/usr/bin/nv6800gt.bin -t

I slightly different behavior with this incantation.  Normally I leave
off The -d 0x200.  My device is located off of 2:0:0.

running file /usr/bin/nv6800gt.bin
No base specified. defaulting to 0xc0000 No initial code segment
specified. defaulting to 0xc000 No initial instruction pointer
specified. defaulting to 0x0003 Switching to single step mode.
	AX=0200  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=0005   NV UP DI PL NZ NA
PO NC 
c000:0003 eb4b                JMP	50
	AX=0200  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=0053   NV UP DI PL NZ NA
PO NC 
c000:0050 e99cd4              JMP	d4ef
	AX=0200  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=d4f0   NV UP DI PL NZ NA
PO NC 
c000:d4ef 2e                  CS:
	AX=0200  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=d4f5   NV UP DI PL NZ NA
PO NC 
c000:d4f0 f606480001          TEST	BYTE PTR [0048],01
	AX=0200  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=d4f7   NV UP DI PL ZR NA
PE NC 
c000:d4f5 742d                JZ	d524
	AX=0200  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=d525   NV UP DI PL ZR NA
PE NC 
c000:d524 55                  PUSH	BP
	AX=0200  BX=0000  CX=0000  DX=0080  SP=fff6  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=d526   NV UP DI PL ZR NA
PE NC 
c000:d525 50                  PUSH	AX
	AX=0200  BX=0000  CX=0000  DX=0080  SP=fff4  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=d529   NV UP DI PL ZR NA
PE NC 
c000:d526 e85afa              CALL	cf83
	AX=0200  BX=0000  CX=0000  DX=0080  SP=fff2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=cf84   NV UP DI PL ZR NA
PE NC 
c000:cf83 60                  PUSHA
	AX=0200  BX=0000  CX=0000  DX=0080  SP=ffe2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=cf87   NV UP DI PL ZR NA
PE NC 
c000:cf84 bac303              MOV	DX,3c3
	AX=0200  BX=0000  CX=0000  DX=03c3  SP=ffe2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=cf89   NV UP DI PL ZR NA
PE NC 
c000:cf87 b001                MOV	AL,1
	AX=0201  BX=0000  CX=0000  DX=03c3  SP=ffe2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=cf8a   NV UP DI PL ZR NA
PE NC 
c000:cf89 ee                  OUT	DX,AL
	AX=0201  BX=0000  CX=0000  DX=03c3  SP=ffe2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=cf8b   NV UP DI PL ZR NA
PE NC 
c000:cf8a ed                  IN	AX,DX
	AX=0001  BX=0000  CX=0000  DX=03c3  SP=ffe2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=cf8e   NV UP DI PL ZR NA
PE NC 
c000:cf8b bacc03              MOV	DX,3cc
	AX=0001  BX=0000  CX=0000  DX=03cc  SP=ffe2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=cf8f   NV UP DI PL ZR NA
PE NC 
c000:cf8e ec                  IN	AL,DX
	AX=0000  BX=0000  CX=0000  DX=03cc  SP=ffe2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=cf91   NV UP DI PL ZR NA
PE NC 
c000:cf8f 0c01                OR	AL,1
	AX=0001  BX=0000  CX=0000  DX=03cc  SP=ffe2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=cf94   NV UP DI PL NZ NA
PO NC 
c000:cf91 bac203              MOV	DX,3c2
	AX=0001  BX=0000  CX=0000  DX=03c2  SP=ffe2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=cf95   NV UP DI PL NZ NA
PO NC 
c000:cf94 ee                  OUT	DX,AL
	AX=0001  BX=0000  CX=0000  DX=03c2  SP=ffe2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=cf98   NV UP DI PL NZ NA
PO NC 
c000:cf95 bac303              MOV	DX,3c3
	AX=0001  BX=0000  CX=0000  DX=03c3  SP=ffe2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=cf99   NV UP DI PL NZ NA
PO NC 
c000:cf98 ec                  IN	AL,DX
	AX=0001  BX=0000  CX=0000  DX=03c3  SP=ffe2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=cf9c   NV UP DI PL NZ NA
PO NC 
c000:cf99 e82675              CALL	44c2
	AX=0001  BX=0000  CX=0000  DX=03c3  SP=ffe0  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=44c3   NV UP DI PL NZ NA
PO NC 
c000:44c2 50                  PUSH	AX
	AX=0001  BX=0000  CX=0000  DX=03c3  SP=ffde  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=44c4   NV UP DI PL NZ NA
PO NC 
c000:44c3 52                  PUSH	DX
	AX=0001  BX=0000  CX=0000  DX=03c3  SP=ffdc  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=44c7   NV UP DI PL NZ NA
PO NC 
c000:44c4 e833d3              CALL	17fa
	AX=0001  BX=0000  CX=0000  DX=03c3  SP=ffda  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=17fb   NV UP DI PL NZ NA
PO NC 
c000:17fa 50                  PUSH	AX
	AX=0001  BX=0000  CX=0000  DX=03c3  SP=ffd8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=17fe   NV UP DI PL NZ NA
PO NC 
c000:17fb bacc03              MOV	DX,3cc
	AX=0001  BX=0000  CX=0000  DX=03cc  SP=ffd8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=17ff   NV UP DI PL NZ NA
PO NC 
c000:17fe ec                  IN	AL,DX
	AX=0001  BX=0000  CX=0000  DX=03cc  SP=ffd8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=1802   NV UP DI PL NZ NA
PO NC 
c000:17ff bab403              MOV	DX,3b4
	AX=0001  BX=0000  CX=0000  DX=03b4  SP=ffd8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=1804   NV UP DI PL NZ NA
PO NC 
c000:1802 a801                TEST	AL,0001
	AX=0001  BX=0000  CX=0000  DX=03b4  SP=ffd8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=1806   NV UP DI PL NZ NA
PO NC 
c000:1804 7402                JZ	1808
	AX=0001  BX=0000  CX=0000  DX=03b4  SP=ffd8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=1808   NV UP DI PL NZ NA
PO NC 
c000:1806 b2d4                MOV	DL,d4
	AX=0001  BX=0000  CX=0000  DX=03d4  SP=ffd8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=1809   NV UP DI PL NZ NA
PO NC 
c000:1808 58                  POP	AX
	AX=0001  BX=0000  CX=0000  DX=03d4  SP=ffda  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=180a   NV UP DI PL NZ NA
PO NC 
c000:1809 c3                  RET
	AX=0001  BX=0000  CX=0000  DX=03d4  SP=ffdc  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=44c8   NV UP DI PL NZ NA
PO NC 
c000:44c7 ec                  IN	AL,DX
	AX=0000  BX=0000  CX=0000  DX=03d4  SP=ffdc  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=44c9   NV UP DI PL NZ NA
PO NC 
c000:44c8 50                  PUSH	AX
	AX=0000  BX=0000  CX=0000  DX=03d4  SP=ffda  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=44ca   NV UP DI PL NZ NA
PO NC 
c000:44c9 53                  PUSH	BX
	AX=0000  BX=0000  CX=0000  DX=03d4  SP=ffd8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=44cc   NV UP DI PL NZ NA
PO NC 
c000:44ca b01f                MOV	AL,1f
	AX=001f  BX=0000  CX=0000  DX=03d4  SP=ffd8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=44cf   NV UP DI PL NZ NA
PO NC 
c000:44cc e8f8d0              CALL	15c7
	AX=001f  BX=0000  CX=0000  DX=03d4  SP=ffd6  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=15ca   NV UP DI PL NZ NA
PO NC 
c000:15c7 e83002              CALL	17fa
	AX=001f  BX=0000  CX=0000  DX=03d4  SP=ffd4  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=17fb   NV UP DI PL NZ NA
PO NC 
c000:17fa 50                  PUSH	AX
	AX=001f  BX=0000  CX=0000  DX=03d4  SP=ffd2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=17fe   NV UP DI PL NZ NA
PO NC 
c000:17fb bacc03              MOV	DX,3cc
	AX=001f  BX=0000  CX=0000  DX=03cc  SP=ffd2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=17ff   NV UP DI PL NZ NA
PO NC 
c000:17fe ec                  IN	AL,DX
	AX=0001  BX=0000  CX=0000  DX=03cc  SP=ffd2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=1802   NV UP DI PL NZ NA
PO NC 
c000:17ff bab403              MOV	DX,3b4
	AX=0001  BX=0000  CX=0000  DX=03b4  SP=ffd2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=1804   NV UP DI PL NZ NA
PO NC 
c000:1802 a801                TEST	AL,0001
	AX=0001  BX=0000  CX=0000  DX=03b4  SP=ffd2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=1806   NV UP DI PL NZ NA
PO NC 
c000:1804 7402                JZ	1808
	AX=0001  BX=0000  CX=0000  DX=03b4  SP=ffd2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=1808   NV UP DI PL NZ NA
PO NC 
c000:1806 b2d4                MOV	DL,d4
	AX=0001  BX=0000  CX=0000  DX=03d4  SP=ffd2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=1809   NV UP DI PL NZ NA
PO NC 
c000:1808 58                  POP	AX
	AX=001f  BX=0000  CX=0000  DX=03d4  SP=ffd4  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=180a   NV UP DI PL NZ NA
PO NC 
c000:1809 c3                  RET
	AX=001f  BX=0000  CX=0000  DX=03d4  SP=ffd6  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=15cb   NV UP DI PL NZ NA
PO NC 
c000:15ca ee                  OUT	DX,AL
	AX=001f  BX=0000  CX=0000  DX=03d4  SP=ffd6  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=15cc   NV UP DI PL NZ NA
PO NC 
c000:15cb ed                  IN	AX,DX
	AX=001f  BX=0000  CX=0000  DX=03d4  SP=ffd6  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=15cd   NV UP DI PL NZ NA
PO NC 
c000:15cc c3                  RET
	AX=001f  BX=0000  CX=0000  DX=03d4  SP=ffd8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=44d2   NV UP DI PL NZ NA
PO NC 
c000:44cf 80e401              AND	AH,1
	AX=001f  BX=0000  CX=0000  DX=03d4  SP=ffd8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=44d4   NV UP DI PL ZR NA
PE NC 
c000:44d2 8afc                MOV	BH,AH
	AX=001f  BX=0000  CX=0000  DX=03d4  SP=ffd8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=44d7   NV UP DI PL ZR NA
PE NC 
c000:44d4 b82c01              MOV	AX,12c
	AX=012c  BX=0000  CX=0000  DX=03d4  SP=ffd8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=44d9   NV UP DI PL ZR NA
PE NC 
c000:44d7 0aff                OR	BH,BH
	AX=012c  BX=0000  CX=0000  DX=03d4  SP=ffd8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=44db   NV UP DI PL ZR NA
PE NC 
c000:44d9 7405                JZ	44e0
	AX=012c  BX=0000  CX=0000  DX=03d4  SP=ffd8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=44e3   NV UP DI PL ZR NA
PE NC 
c000:44e0 e8350d              CALL	5218
	AX=012c  BX=0000  CX=0000  DX=03d4  SP=ffd6  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=521a   NV UP DI PL ZR NA
PE NC 
c000:5218 f6d4                NOT	AH
	AX=fe2c  BX=0000  CX=0000  DX=03d4  SP=ffd6  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=521b   NV UP DI PL ZR NA
PE NC 
c000:521a 52                  PUSH	DX
	AX=fe2c  BX=0000  CX=0000  DX=03d4  SP=ffd4  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=521c   NV UP DI PL ZR NA
PE NC 
c000:521b 50                  PUSH	AX
	AX=fe2c  BX=0000  CX=0000  DX=03d4  SP=ffd2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=521f   NV UP DI PL ZR NA
PE NC 
c000:521c e890ff              CALL	51af
	AX=fe2c  BX=0000  CX=0000  DX=03d4  SP=ffd0  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=51b0   NV UP DI PL ZR NA
PE NC 
c000:51af 53                  PUSH	BX
	AX=fe2c  BX=0000  CX=0000  DX=03d4  SP=ffce  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=51b1   NV UP DI PL ZR NA
PE NC 
c000:51b0 93                  XCHG	AX,BX
	AX=0000  BX=fe2c  CX=0000  DX=03d4  SP=ffce  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=51b4   NV UP DI PL ZR NA
PE NC 
c000:51b1 e8e3ff              CALL	5197
	AX=0000  BX=fe2c  CX=0000  DX=03d4  SP=ffcc  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=5199   NV UP DI PL ZR NA
PE NC 
c000:5197 32e4                XOR	AH,AH
	AX=0000  BX=fe2c  CX=0000  DX=03d4  SP=ffcc  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=519c   NV UP DI PL ZR NA
PE NC 
c000:5199 e8deff              CALL	517a
	AX=0000  BX=fe2c  CX=0000  DX=03d4  SP=ffca  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=517b   NV UP DI PL ZR NA
PE NC 
c000:517a 9c                  PUSHF
	AX=0000  BX=fe2c  CX=0000  DX=03d4  SP=ffc8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=517c   NV UP DI PL ZR NA
PE NC 
c000:517b 52                  PUSH	DX
	AX=0000  BX=fe2c  CX=0000  DX=03d4  SP=ffc6  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=517d   NV UP DI PL ZR NA
PE NC 
c000:517c 53                  PUSH	BX
	AX=0000  BX=fe2c  CX=0000  DX=03d4  SP=ffc4  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=517f   NV UP DI PL ZR NA
PE NC 
c000:517d 8bd8                MOV	BX,AX
	AX=0000  BX=0000  CX=0000  DX=03d4  SP=ffc4  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=5181   NV UP DI PL ZR NA
PE NC 
c000:517f b044                MOV	AL,44
	AX=0044  BX=0000  CX=0000  DX=03d4  SP=ffc4  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=5184   NV UP DI PL ZR NA
PE NC 
c000:5181 e843c4              CALL	15c7
	AX=0044  BX=0000  CX=0000  DX=03d4  SP=ffc2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=15ca   NV UP DI PL ZR NA
PE NC 
c000:15c7 e83002              CALL	17fa
	AX=0044  BX=0000  CX=0000  DX=03d4  SP=ffc0  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=17fb   NV UP DI PL ZR NA
PE NC 
c000:17fa 50                  PUSH	AX
	AX=0044  BX=0000  CX=0000  DX=03d4  SP=ffbe  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=17fe   NV UP DI PL ZR NA
PE NC 
c000:17fb bacc03              MOV	DX,3cc
	AX=0044  BX=0000  CX=0000  DX=03cc  SP=ffbe  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=17ff   NV UP DI PL ZR NA
PE NC 
c000:17fe ec                  IN	AL,DX
	AX=0001  BX=0000  CX=0000  DX=03cc  SP=ffbe  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=1802   NV UP DI PL ZR NA
PE NC 
c000:17ff bab403              MOV	DX,3b4
	AX=0001  BX=0000  CX=0000  DX=03b4  SP=ffbe  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=1804   NV UP DI PL ZR NA
PE NC 
c000:1802 a801                TEST	AL,0001
	AX=0001  BX=0000  CX=0000  DX=03b4  SP=ffbe  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=1806   NV UP DI PL NZ NA
PO NC 
c000:1804 7402                JZ	1808
	AX=0001  BX=0000  CX=0000  DX=03b4  SP=ffbe  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=1808   NV UP DI PL NZ NA
PO NC 
c000:1806 b2d4                MOV	DL,d4
	AX=0001  BX=0000  CX=0000  DX=03d4  SP=ffbe  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=1809   NV UP DI PL NZ NA
PO NC 
c000:1808 58                  POP	AX
	AX=0044  BX=0000  CX=0000  DX=03d4  SP=ffc0  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=180a   NV UP DI PL NZ NA
PO NC 
c000:1809 c3                  RET
	AX=0044  BX=0000  CX=0000  DX=03d4  SP=ffc2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=15cb   NV UP DI PL NZ NA
PO NC 
c000:15ca ee                  OUT	DX,AL
	AX=0044  BX=0000  CX=0000  DX=03d4  SP=ffc2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=15cc   NV UP DI PL NZ NA
PO NC 
c000:15cb ed                  IN	AX,DX
	AX=0044  BX=0000  CX=0000  DX=03d4  SP=ffc2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=15cd   NV UP DI PL NZ NA
PO NC 
c000:15cc c3                  RET
	AX=0044  BX=0000  CX=0000  DX=03d4  SP=ffc4  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=5185   NV UP DI PL NZ NA
PO NC 
c000:5184 50                  PUSH	AX
	AX=0044  BX=0000  CX=0000  DX=03d4  SP=ffc2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=5187   NV UP DI PL NZ NA
PO NC 
c000:5185 8ae7                MOV	AH,BH
	AX=0044  BX=0000  CX=0000  DX=03d4  SP=ffc2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=5188   NV UP DI PL NZ NA
PO NC 
c000:5187 ef                  OUT	DX,AX
	AX=0044  BX=0000  CX=0000  DX=03d4  SP=ffc2  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=5189   NV UP DI PL NZ NA
PO NC 
c000:5188 58                  POP	AX
	AX=0044  BX=0000  CX=0000  DX=03d4  SP=ffc4  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=518a   NV UP DI PL NZ NA
PO NC 
c000:5189 5b                  POP	BX
	AX=0044  BX=fe2c  CX=0000  DX=03d4  SP=ffc6  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=518b   NV UP DI PL NZ NA
PO NC 
c000:518a 5a                  POP	DX
	AX=0044  BX=fe2c  CX=0000  DX=03d4  SP=ffc8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=518c   NV UP DI PL NZ NA
PO NC 
c000:518b 9d                  POPF
	AX=0044  BX=fe2c  CX=0000  DX=03d4  SP=ffca  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=518d   NV UP DI PL ZR NA
PE NC 
c000:518c c3                  RET
	AX=0044  BX=fe2c  CX=0000  DX=03d4  SP=ffcc  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=519d   NV UP DI PL ZR NA
PE NC 
c000:519c c3                  RET
	AX=0044  BX=fe2c  CX=0000  DX=03d4  SP=ffce  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=51b5   NV UP DI PL ZR NA
PE NC 
c000:51b4 50                  PUSH	AX
	AX=0044  BX=fe2c  CX=0000  DX=03d4  SP=ffcc  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=51b6   NV UP DI PL ZR NA
PE NC 
c000:51b5 93                  XCHG	AX,BX
	AX=fe2c  BX=0044  CX=0000  DX=03d4  SP=ffcc  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=51b9   NV UP DI PL ZR NA
PE NC 
c000:51b6 e80ec4              CALL	15c7
	AX=fe2c  BX=0044  CX=0000  DX=03d4  SP=ffca  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=15ca   NV UP DI PL ZR NA
PE NC 
c000:15c7 e83002              CALL	17fa
	AX=fe2c  BX=0044  CX=0000  DX=03d4  SP=ffc8  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=17fb   NV UP DI PL ZR NA
PE NC 
c000:17fa 50                  PUSH	AX
	AX=fe2c  BX=0044  CX=0000  DX=03d4  SP=ffc6  BP=0000  SI=0000
DI=0000
	DS=0040  ES=0000  SS=0030  CS=c000  IP=17fe   NV UP DI PL ZR NA
PE NC 
 

-----Original Message-----
From: Li-Ta Lo [mailto:ollie at lanl.gov]
Sent: Friday, October 08, 2004 11:14 AM
To: Dave Aubin
Cc: LinuxBIOS
Subject: RE: testbios loops?

On Fri, 2004-10-08 at 09:04, Dave Aubin wrote:
> Hi,
> 
>   Oh it does.  I just left that snippet out.  It starts at the correct
> place:)
> 

Then there is a big problem. The code just to somewhere that is not code
(0000). Can you send more messages ?

Ollie

> -----Original Message-----
> From: Li-Ta Lo [mailto:ollie at lanl.gov]
> Sent: Friday, October 08, 2004 11:02 AM
> To: Dave Aubin
> Cc: LinuxBIOS
> Subject: RE: testbios loops?
> 
> On Fri, 2004-10-08 at 08:58, Dave Aubin wrote:
> > Hi,
> 
> Why it starts from c000:fffd ? It should starts from c000:0003
> 
> Ollie
> 
> > 
> > It will first do this (I'm using the testbios -t option)
> > c000:fffd 0000                ADD       [BX+SI],AL
> >         AX=0200  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000  
> > SI=0000 DI=0000
> >         DS=0040  ES=0000  SS=0030  CS=c000  IP=0002   NV UP DI PL ZR
> NA
> > PE NC 
> > c000:ffff 000000              ADD       -86[DI],DL
> >         AX=0200  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000  
> > SI=0000 DI=0000
> >         DS=0040  ES=0000  SS=0030  CS=c000  IP=0004   NV UP DI NG NZ
> NA
> > PO NC 
> > c000:0002 74eb                JZ        ffef
> >         AX=0200  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000  
> > SI=0000 DI=0000
> >         DS=0040  ES=0000  SS=0030  CS=c000  IP=0005   NV UP DI NG NZ
> NA
> > PO NC 
> > c000:0004 4b                  DEC       BX
> >         AX=0200  BX=ffff  CX=0000  DX=0080  SP=fff8  BP=0000  
> > SI=0000 DI=0000
> >         DS=0040  ES=0000  SS=0030  CS=c000  IP=0006   NV UP DI NG NZ
> AC
> > PE NC 
> > c000:0005 37                  AAA
> >         AX=0306  BX=ffff  CX=0000  DX=0080  SP=fff8  BP=0000  
> > SI=0000 DI=0000
> >         DS=0040  ES=0000  SS=0030  CS=c000  IP=0008   NV UP DI PL NZ
> AC
> > PE CY
> > 
> > Then it will do this:
> > c000:0137 0d0a00              OR        AX,a
> >         AX=debf  BX=ffff  CX=0335  DX=0080  SP=ffef  BP=0000  
> > SI=0004
> > DI=0002
> >         DS=0040  ES=0000  SS=0030  CS=c000  IP=013c   NV UP DI NG NZ
> NA
> > PO NC 
> > c000:013a 0000                ADD       [BX+SI],AL
> >         AX=debf  BX=ffff  CX=0335  DX=0080  SP=ffef  BP=0000  
> > SI=0004
> > DI=0002
> >         DS=0040  ES=0000  SS=0030  CS=c000  IP=013f   NV UP DI NG NZ
> AC
> > PO CY 
> > c000:013c ba9198              MOV       DX,9891
> >         AX=debf  BX=ffff  CX=0335  DX=9891  SP=ffef  BP=0000  
> > SI=0004
> > DI=0002
> >         DS=0040  ES=0000  SS=0030  CS=c000  IP=0140   NV UP DI NG NZ
> AC
> > PO CY 
> > c000:013f 96                  XCHG      AX,SI
> >         AX=0004  BX=ffff  CX=0335  DX=9891  SP=ffef  BP=0000  
> > SI=debf
> > DI=0002
> >         DS=0040  ES=0000  SS=0030  CS=c000  IP=0141   NV UP DI NG NZ
> AC
> > PO CY 
> > c000:0140 91                  XCHG      AX,CX
> >         AX=0335  BX=ffff  CX=0004  DX=9891  SP=ffef  BP=0000  
> > SI=debf
> > DI=0002
> >         DS=0040  ES=0000  SS=0030  CS=c000  IP=0146   NV UP DI NG NZ
> AC
> > PO CY 
> > c000:0141 9a9a8d9691          CALL      9196:8d9a
> >         AX=0335  BX=ffff  CX=0004  DX=9891  SP=ffeb  BP=0000  
> > SI=debf
> > DI=0002
> >         DS=0040  ES=0000  SS=0030  CS=9196  IP=8d9c   NV UP DI NG NZ
> AC
> > PO CY 
> > 9196:8d9a 0000                ADD       [BX+SI],AL
> >         AX=0335  BX=ffff  CX=0004  DX=9891  SP=ffeb  BP=0000  
> > SI=debf
> > DI=0002
> >         DS=0040  ES=0000  SS=0030  CS=9196  IP=8d9e   NV UP DI PL NZ
> NA
> > PE NC 
> > 9196:8d9c 0000                ADD       [BX+SI],AL
> >         AX=0335  BX=ffff  CX=0004  DX=9891  SP=ffeb  BP=0000  
> > SI=debf
> > DI=0002
> >         DS=0040  ES=0000  SS=0030  CS=9196  IP=8da0   NV UP DI PL NZ
> NA
> > PE NC
> > 
> > I'm still looking for the openbios utility.  So far found broken 
> > links:( I can get some other bios to work, but they appear to be 
> > flacky.  I really think I should be using the one that came 
> > programmed
> 
> > on the board.
> > 
> > Thanks,
> > Dave
> > 
> > -----Original Message-----
> > From: Li-Ta Lo [mailto:ollie at lanl.gov]
> > Sent: Friday, October 08, 2004 10:53 AM
> > To: Dave Aubin
> > Cc: LinuxBIOS
> > Subject: Re: testbios loops?
> > 
> > On Fri, 2004-10-08 at 08:35, Dave Aubin wrote:
> > > Hi,
> > >  
> > >   I went back to trying to get the Nvida 6800gt card's bios, but 
> > > still
> > 
> > > even with dd -if=/dev/mem of=vgabios.rom skip=786432 bs=1
> > > count=32768 I get the same binary as dd -if=/dev/mem 
> > > of=vgabios.rom
> > > skip=1536 count=64.
> > > I used dhex (free util) to verify they are the same.
> > >   What happens when I run them trough testbios is that once it is 
> > > done
> > 
> > > programming 0xc7fff it jump to 0x9 something or other and the 
> > > video bios isn't programmed correctly.
> > 
> > 
> > What do you mean by 'programming oxc7ff it jump to 0x9' ?
> > 
> > Ollie
> > 
> > 
> > 
> 
> 



From jerj at coplanar.net  Fri Oct  8 20:32:00 2004
From: jerj at coplanar.net (Jeremy Jackson)
Date: Fri Oct  8 20:32:00 2004
Subject: Freebios support for Soyo SY-6BA+
Message-ID: <416743D5.3040305@coplanar.net>

I had it working a month ago, but I fried the board the next day.  It 
just didn't seem worth it to spend $100 CAD for another off eBay + 
shipping + taxes, etc. and I haven't run into another locally yet.

I'm posting what I had at the time I got it working, maybe it can go 
into CVS for safe keeping.

freebios/src/mainboard/soyo/6ba+ directory contents attached.
-- 
Jeremy Jackson
Coplanar Networks
(519)897-1516
http://www.coplanar.net
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Config
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20041008/842f0c58/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: STATUS
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20041008/842f0c58/attachment-0001.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: config.soyo
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20041008/842f0c58/attachment-0002.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: do_ramtest.inc
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20041008/842f0c58/attachment-0003.ksh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: irq_tables.c
Type: text/x-csrc
Size: 1796 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20041008/842f0c58/attachment.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mainboard.c
Type: text/x-csrc
Size: 4223 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20041008/842f0c58/attachment-0001.c>

From dmitry at vp.kis.ru  Sat Oct  9 14:11:01 2004
From: dmitry at vp.kis.ru (Dmitry Zavyalov)
Date: Sat Oct  9 14:11:01 2004
Subject: Small changes + videobios question...
Message-ID: <411548565.20041009232637@vp.kis.ru>

Hello All,

  I've made small changes for
   southbridge/intel/piix4e/southbridge.c
   to let it setup PM and IDE controller properly on Banister(I440MX)
   chipset. Do anyone interesting in it?

   Is someone has good results to put standard 32k videobios in flash
   and init the videochip during main hardware init? I mean without
   testbios but directly in flash.


-- 
Best regards,
 Dmitry                          mailto:dmitry at vp.kis.ru

Saturday, October 9, 2004



From rsmith at bitworks.com  Sat Oct  9 15:31:00 2004
From: rsmith at bitworks.com (Richard Smith)
Date: Sat Oct  9 15:31:00 2004
Subject: Small changes + videobios question...
In-Reply-To: <411548565.20041009232637@vp.kis.ru>
References: <411548565.20041009232637@vp.kis.ru>
Message-ID: <41684ED7.1070200@bitworks.com>

Dmitry Zavyalov wrote:

>    Is someone has good results to put standard 32k videobios in flash
>    and init the videochip during main hardware init? I mean without
>    testbios but directly in flash.

Depends.  I've been able to make this work with a couple of different 
video boards but only using ADLO.

-- 
Richard A. Smith




From dmitry at vp.kis.ru  Sat Oct  9 15:48:00 2004
From: dmitry at vp.kis.ru (Dmitry Zavyalov)
Date: Sat Oct  9 15:48:00 2004
Subject: Small changes + videobios question...
In-Reply-To: <41684ED7.1070200@bitworks.com>
References: <411548565.20041009232637@vp.kis.ru> <41684ED7.1070200@bitworks.com>
Message-ID: <1517514113.20041010010603@vp.kis.ru>

Hello Richard,

Sunday, October 10, 2004, 12:49:27 AM, you wrote:

RS> Dmitry Zavyalov wrote:

>>    Is someone has good results to put standard 32k videobios in flash
>>    and init the videochip during main hardware init? I mean without
>>    testbios but directly in flash.

RS> Depends.  I've been able to make this work with a couple of different 
RS> video boards but only using ADLO.

ADLO??? what's it?

I have CNT69000 integrated on board and 32k video bios image. Just
thinking how to put it in. It should work in x86 real mode and must be
copied in proper memory region. Any ready solution for it or I have to
write the code for it from zero?


-- 
Best regards,
 Dmitry                            mailto:dmitry at vp.kis.ru

Sunday, October 10, 2004



From rsmith at bitworks.com  Sat Oct  9 16:08:00 2004
From: rsmith at bitworks.com (Richard Smith)
Date: Sat Oct  9 16:08:00 2004
Subject: Small changes + videobios question...
In-Reply-To: <1517514113.20041010010603@vp.kis.ru>
References: <411548565.20041009232637@vp.kis.ru> <41684ED7.1070200@bitworks.com> <1517514113.20041010010603@vp.kis.ru>
Message-ID: <4168575A.8080109@bitworks.com>

Dmitry Zavyalov wrote:

Oh I forgot to ask are you useing V1 or V2?

> RS> Depends.  I've been able to make this work with a couple of
> different RS> video boards but only using ADLO.
> 
> ADLO??? what's it?

If you are usning V1 then:

ADLO is a quasi legacy bios payload for linuxbios.  It comprises of the
BIOS code from the BOCHS project and a glue layer.  In a nutshell ADLO
copies the BOCHS code, Vieo bios, and PIRQ tabled into your BIOS shadow
area, drops back to real mode and jumps to the BOCHS BIOS.  One of the
things the BOCHS bios does is to scan the ROM expansion ranges looking
for extensions and it runs them if it finds them.
BOCHS has a long of legacy compatiblity but its not 100% there yet.

see freebios/utils/ADLO.

ADLO won't run out of the box.  You have to setup your shadowing
properly look through loader.s for the details.

I don't think ADLO has been ported to V2 but since its just a payload 
its probally not a big deal.

> I have CNT69000 integrated on board and 32k video bios image. Just 
> thinking how to put it in.

Chips and Tech (Now Assilaint) 69000 chips work perfectly under ADLO.
That what we used to use.  Are you aware they went end-of-life last year?

> It should work in x86 real mode and must be copied in proper memory
> region. Any ready solution for it or I have to write the code for it
> from zero?

In V1 there also exists a Legacy VGA mode in linuxbios that will setup 
the IDT drop to real mode and run vbios as well but I've not tested it much.

Search the code and the list archives for the following config options:
VIDEO_CONSOLE
CONFIG_VGABIOS
VGABIOS_START
CONFIG_REALMODE_IDT
CONFIG_PCIBIOS

That ought to give you enough info to you started.

-- 
Richard A. Smith




From adam at cfar.umd.edu  Sat Oct  9 17:06:01 2004
From: adam at cfar.umd.edu (Adam Sulmicki)
Date: Sat Oct  9 17:06:01 2004
Subject: Small changes + videobios question...
In-Reply-To: <4168575A.8080109@bitworks.com>
Message-ID: <20041009182625.D17345-100000@www.missl.cs.umd.edu>

On Sat, 9 Oct 2004, Richard Smith wrote:

> I don't think ADLO has been ported to V2 but since its just a payload
> its probally not a big deal.

It is just a module so no changes should be required.

I think the reason why it is not in the V2 is that at the moment it does
not have offical maintainer.




From dmitry at vp.kis.ru  Sun Oct 10 09:45:01 2004
From: dmitry at vp.kis.ru (Dmitry Zavyalov)
Date: Sun Oct 10 09:45:01 2004
Subject: Small changes + videobios question...
In-Reply-To: <4168575A.8080109@bitworks.com>
References: <411548565.20041009232637@vp.kis.ru>
 <41684ED7.1070200@bitworks.com> <1517514113.20041010010603@vp.kis.ru>
 <4168575A.8080109@bitworks.com>
Message-ID: <1927589453.20041010190323@vp.kis.ru>

Hello Richard,

Sunday, October 10, 2004, 1:25:46 AM, you wrote:

RS> Dmitry Zavyalov wrote:

RS> Oh I forgot to ask are you useing V1 or V2?

>> RS> Depends.  I've been able to make this work with a couple of
>> different RS> video boards but only using ADLO.
>> 
>> ADLO??? what's it?

RS> If you are usning V1 then:

RS> ADLO is a quasi legacy bios payload for linuxbios.  It comprises of the
RS> BIOS code from the BOCHS project and a glue layer.  In a nutshell ADLO
RS> copies the BOCHS code, Vieo bios, and PIRQ tabled into your BIOS shadow
RS> area, drops back to real mode and jumps to the BOCHS BIOS.  One of the
RS> things the BOCHS bios does is to scan the ROM expansion ranges looking
RS> for extensions and it runs them if it finds them.
RS> BOCHS has a long of legacy compatiblity but its not 100% there yet.

RS> see freebios/utils/ADLO.

RS> ADLO won't run out of the box.  You have to setup your shadowing
RS> properly look through loader.s for the details.

RS> I don't think ADLO has been ported to V2 but since its just a payload 
RS> its probally not a big deal.

>> I have CNT69000 integrated on board and 32k video bios image. Just 
>> thinking how to put it in.

RS> Chips and Tech (Now Assilaint) 69000 chips work perfectly under ADLO.
RS> That what we used to use.  Are you aware they went end-of-life last year?

It's a testing board... For games to play :) I doubt I will use these
chips in future...

>> It should work in x86 real mode and must be copied in proper memory
>> region. Any ready solution for it or I have to write the code for it
>> from zero?

RS> In V1 there also exists a Legacy VGA mode in linuxbios that will setup 
RS> the IDT drop to real mode and run vbios as well but I've not tested it much.

RS> Search the code and the list archives for the following config options:
RS> VIDEO_CONSOLE
RS> CONFIG_VGABIOS
RS> VGABIOS_START
RS> CONFIG_REALMODE_IDT
RS> CONFIG_PCIBIOS

RS> That ought to give you enough info to you started.

Thanks a lot...
Now it hangs when jumping into the entry point of video BIOS. Really
doubt that I can find the reason why :(


-- 
Best regards,
 Dmitry                            mailto:dmitry at vp.kis.ru

Sunday, October 10, 2004



From sagivy at 3vium.com  Mon Oct 11 03:43:01 2004
From: sagivy at 3vium.com (Sagiv Yefet)
Date: Mon Oct 11 03:43:01 2004
Subject: Kernel for linuxbios
Message-ID: <4A3D5F6DC9406A4DBE93D9BA8F07E4BB22D6C2@cronos.trivium>

I add the console support and there is output. Thanks.

My machine has no disks and I need initrd. So I took initrd from
Thinstation and build the elf file by the command : 

./objdir/sbin/mkelfImage -t bzImage-i386 --kernel=/home/sagivy/bzImage	
	--command-line="rw console=ttyS0,115200 root=/dev/ram0"  
	--ramdisk=/home/sagivy/initrd --output=/home/sagivy/bzImage.elf

and I got panic message:

RAMDISK: Couldn't find valid RAM disk image starting at 0.
Freeing initrd memory: 11922k freed
Kernel panic: VFS: Unable to mount root fs on 01:00

I also had ram disk support.

Any idea?

Sagiv.

-----Original Message-----
From: Stefan Reinauer [mailto:stepan at openbios.org] 
Sent: Sunday, September 26, 2004 6:49 PM
To: Sagiv Yefet
Cc: linuxbios at clustermatic.org
Subject: Re: Kernel for linuxbios

* Sagiv Yefet <sagivy at 3vium.com> [040926 15:33]:
> I tried without success:
> 1.         Thinstation (etherboot)
> 2.         Kernel from kernel.org.

> Is there any specific version I need to use of those kernels? 
 
No, all Linux kernels work fine.
 
> Are there any patches made for the kernels that I didn't use? Where
can
> I find them.
 
No. No patches needed at all.

> What could be the problem? 

The biggest problem is the low availability of crystal balls nowadays ;)

Maybe you did not compile your kernel with serial console support or did
not  enable serial console on the command line? 

Stefan





From stepan at openbios.org  Mon Oct 11 04:02:00 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Mon Oct 11 04:02:00 2004
Subject: Kernel for linuxbios
In-Reply-To: <4A3D5F6DC9406A4DBE93D9BA8F07E4BB22D6C2@cronos.trivium>
References: <4A3D5F6DC9406A4DBE93D9BA8F07E4BB22D6C2@cronos.trivium>
Message-ID: <20041011092047.GA22587@openbios.org>

* Sagiv Yefet <sagivy at 3vium.com> [041011 11:06]:
> 
> I add the console support and there is output. Thanks.
> 
> My machine has no disks and I need initrd. So I took initrd from
> Thinstation and build the elf file by the command : 
> 
> RAMDISK: Couldn't find valid RAM disk image starting at 0.
> Freeing initrd memory: 11922k freed
> Kernel panic: VFS: Unable to mount root fs on 01:00
 
use initrd, not ramdisk!

Stefan



From rminnich at lanl.gov  Mon Oct 11 13:13:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Oct 11 13:13:00 2004
Subject: Small changes + videobios question...
In-Reply-To: <411548565.20041009232637@vp.kis.ru>
References: <411548565.20041009232637@vp.kis.ru>
Message-ID: <Pine.LNX.4.58.0410111231050.17999@linux.site>


On Sat, 9 Oct 2004, Dmitry Zavyalov wrote:

>   I've made small changes for
>    southbridge/intel/piix4e/southbridge.c
>    to let it setup PM and IDE controller properly on Banister(I440MX)
>    chipset. Do anyone interesting in it?

I would like to see the patch.

ron


From dmitry at vp.kis.ru  Mon Oct 11 16:06:01 2004
From: dmitry at vp.kis.ru (Dmitry Zavyalov)
Date: Mon Oct 11 16:06:01 2004
Subject: VGA BIOS
Message-ID: <17639893023.20041012012429@vp.kis.ru>

Hello All,

  I've found a trouble copy the VGA BIOS from standard 512kb flash to
  the 0xc0000 memory. When I read the ROM the data reading via 4k
  blocks (1st block - ok, 2nd block - copy of block 1, 3rd block - ok,
  4th block - copy of block 4). Looks like it's some hack to work with
  MTD devices (that uses only 12 address lines on ISA bus and works
  trough window). How to disable it? (i440bx/mx chipset).


-- 
Best regards,
 Dmitry                          mailto:dmitry at vp.kis.ru

Tuesday, October 12, 2004



From rsmith at bitworks.com  Mon Oct 11 16:42:00 2004
From: rsmith at bitworks.com (Richard Smith)
Date: Mon Oct 11 16:42:00 2004
Subject: VGA BIOS
In-Reply-To: <17639893023.20041012012429@vp.kis.ru>
References: <17639893023.20041012012429@vp.kis.ru>
Message-ID: <416B0277.20202@bitworks.com>

Dmitry Zavyalov wrote:

>   the 0xc0000 memory. When I read the ROM the data reading via 4k
>   blocks (1st block - ok, 2nd block - copy of block 1, 3rd block - ok,
>   4th block - copy of block 4). Looks like it's some hack to work with
>   MTD devices (that uses only 12 address lines on ISA bus and works
>   trough window). How to disable it? (i440bx/mx chipset).

How are you doing the copy?

-- 
Richard A. Smith




From dmitry at vp.kis.ru  Tue Oct 12 04:03:00 2004
From: dmitry at vp.kis.ru (Dmitry Zavyalov)
Date: Tue Oct 12 04:03:00 2004
Subject: VGA BIOS
In-Reply-To: <416B0277.20202@bitworks.com>
References: <17639893023.20041012012429@vp.kis.ru> <416B0277.20202@bitworks.com>
Message-ID: <482032011.20041012132142@vp.kis.ru>

Hello Richard,

Tuesday, October 12, 2004, 2:00:23 AM, you wrote:

RS> Dmitry Zavyalov wrote:

>>   the 0xc0000 memory. When I read the ROM the data reading via 4k
>>   blocks (1st block - ok, 2nd block - copy of block 1, 3rd block - ok,
>>   4th block - copy of block 4). Looks like it's some hack to work with
>>   MTD devices (that uses only 12 address lines on ISA bus and works
>>   trough window). How to disable it? (i440bx/mx chipset).

RS> How are you doing the copy?

as it appears in standard implementation
memcpy ((void*)0xc0000, rom, size);


-- 
Best regards,
 Dmitry                            mailto:dmitry at vp.kis.ru

Tuesday, October 12, 2004



From liutao at safe-mail.net  Tue Oct 12 06:08:00 2004
From: liutao at safe-mail.net (Liu Tao)
Date: Tue Oct 12 06:08:00 2004
Subject: IRQ-Tables once again
Message-ID: <416BBFCE.7020109@safe-mail.net>

*ron minnich wrote:

*> On Tue, 20 Jan 2004, Stefan Reinauer wrote:
> 
> >/ Reading the Linux kernel sources it seems that Linux _does_ expect the
/> >/ devices to have interrupts assigned already, which obviously LinuxBIOS
/> >/ does not do. This has to be "fixed" if LinuxBIOS shall be open to
/> >/ anybody not patching special kernels that do the right thing.
/> 
> no. In 2.4, in the right circumstances, the kernel can assign interrupts 
> just fine. 

Does linux2.4 assign interrupts accroding to the pirq table?
Does linux assign interrupts even if BIOS already assigned the interrupts?

> 
> >/ If we provide tables at all, can we maybe drop the irq table and only
/> >/ use the mptable?
/> 
> no, sadly the kernel needs an irq table for pci bus scanning.
> 
> ron

Does linuxbios now provide dynamic way to write pirq table?

Regards,
Liu Tao



From rminnich at lanl.gov  Wed Oct 13 00:12:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Wed Oct 13 00:12:00 2004
Subject: IRQ-Tables once again
In-Reply-To: <416BBFCE.7020109@safe-mail.net>
References: <416BBFCE.7020109@safe-mail.net>
Message-ID: <Pine.LNX.4.58.0410122330400.21682@linux.site>


On Tue, 12 Oct 2004, Liu Tao wrote:

> Does linux2.4 assign interrupts accroding to the pirq table?

in non-APIC situation, yes. 

> Does linux assign interrupts even if BIOS already assigned the interrupts?

no.

> Does linuxbios now provide dynamic way to write pirq table?

no

ron


From sagivy at 3vium.com  Wed Oct 13 06:46:01 2004
From: sagivy at 3vium.com (Sagiv Yefet)
Date: Wed Oct 13 06:46:01 2004
Subject: Kernel for linuxbios
Message-ID: <4A3D5F6DC9406A4DBE93D9BA8F07E4BB228A94@cronos.trivium>

I tried to use initrd - same problem.

Sagiv 

-----Original Message-----
From: Stefan Reinauer [mailto:stepan at openbios.org] 
Sent: Monday, October 11, 2004 11:21 AM
To: Sagiv Yefet
Cc: linuxbios at clustermatic.org
Subject: Re: Kernel for linuxbios

* Sagiv Yefet <sagivy at 3vium.com> [041011 11:06]:
> 
> I add the console support and there is output. Thanks.
> 
> My machine has no disks and I need initrd. So I took initrd from
> Thinstation and build the elf file by the command : 
> 
> RAMDISK: Couldn't find valid RAM disk image starting at 0.
> Freeing initrd memory: 11922k freed
> Kernel panic: VFS: Unable to mount root fs on 01:00
 
use initrd, not ramdisk!

Stefan




From daubin at actuality-systems.com  Wed Oct 13 07:29:00 2004
From: daubin at actuality-systems.com (Dave Aubin)
Date: Wed Oct 13 07:29:00 2004
Subject: Kernel for linuxbios
Message-ID: <E8F8DBCB0468204E856114A2CD20741F2C18AA@mail.local.ActualitySystems.com>

Sorry for the late response.  Are you using
Linux 2.6.*.  If so give initramfs a try.
Here is a link to aid you in how:

http://linuxfromscratch.org/pipermail/lfs-hackers/2004-June/001424.html

Dave
 

-----Original Message-----
From: linuxbios-admin at clustermatic.org
[mailto:linuxbios-admin at clustermatic.org] On Behalf Of Sagiv Yefet
Sent: Wednesday, October 13, 2004 8:10 AM
To: Stefan Reinauer
Cc: linuxbios at clustermatic.org
Subject: RE: Kernel for linuxbios

I tried to use initrd - same problem.

Sagiv 

-----Original Message-----
From: Stefan Reinauer [mailto:stepan at openbios.org]
Sent: Monday, October 11, 2004 11:21 AM
To: Sagiv Yefet
Cc: linuxbios at clustermatic.org
Subject: Re: Kernel for linuxbios

* Sagiv Yefet <sagivy at 3vium.com> [041011 11:06]:
> 
> I add the console support and there is output. Thanks.
> 
> My machine has no disks and I need initrd. So I took initrd from 
> Thinstation and build the elf file by the command :
> 
> RAMDISK: Couldn't find valid RAM disk image starting at 0.
> Freeing initrd memory: 11922k freed
> Kernel panic: VFS: Unable to mount root fs on 01:00
 
use initrd, not ramdisk!

Stefan


_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From sagivy at 3vium.com  Wed Oct 13 08:47:01 2004
From: sagivy at 3vium.com (Sagiv Yefet)
Date: Wed Oct 13 08:47:01 2004
Subject: Kernel for linuxbios
Message-ID: <4A3D5F6DC9406A4DBE93D9BA8F07E4BB22D6C3@cronos.trivium>

Actually, I am using 2.4.24. 
Maybe I should upgrade to 2.6.*. 
but in the meanwhile what could be the problem?

The command is:

./objdir/sbin/mkelfImage -t bzImage-i386 --kernel=/home/sagivy/bzImage	
	--command-line="rw console=ttyS0,115200 root=/dev/ram0"  
	--initrd=/home/sagivy/initrd --output=/home/sagivy/bzImage.elf

initrd created by thinstation: 2646kb.

Sagiv.

-----Original Message-----
From: Dave Aubin [mailto:daubin at actuality-systems.com] 
Sent: Wednesday, October 13, 2004 2:47 PM
To: Sagiv Yefet; Stefan Reinauer
Cc: linuxbios at clustermatic.org
Subject: RE: Kernel for linuxbios

Sorry for the late response.  Are you using
Linux 2.6.*.  If so give initramfs a try.
Here is a link to aid you in how:

http://linuxfromscratch.org/pipermail/lfs-hackers/2004-June/001424.html

Dave
 

-----Original Message-----
From: linuxbios-admin at clustermatic.org
[mailto:linuxbios-admin at clustermatic.org] On Behalf Of Sagiv Yefet
Sent: Wednesday, October 13, 2004 8:10 AM
To: Stefan Reinauer
Cc: linuxbios at clustermatic.org
Subject: RE: Kernel for linuxbios

I tried to use initrd - same problem.

Sagiv 

-----Original Message-----
From: Stefan Reinauer [mailto:stepan at openbios.org]
Sent: Monday, October 11, 2004 11:21 AM
To: Sagiv Yefet
Cc: linuxbios at clustermatic.org
Subject: Re: Kernel for linuxbios

* Sagiv Yefet <sagivy at 3vium.com> [041011 11:06]:
> 
> I add the console support and there is output. Thanks.
> 
> My machine has no disks and I need initrd. So I took initrd from 
> Thinstation and build the elf file by the command :
> 
> RAMDISK: Couldn't find valid RAM disk image starting at 0.
> Freeing initrd memory: 11922k freed
> Kernel panic: VFS: Unable to mount root fs on 01:00
 
use initrd, not ramdisk!

Stefan


_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios




From stepan at openbios.org  Wed Oct 13 09:09:00 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Wed Oct 13 09:09:00 2004
Subject: Kernel for linuxbios
In-Reply-To: <4A3D5F6DC9406A4DBE93D9BA8F07E4BB22D6C3@cronos.trivium>
References: <4A3D5F6DC9406A4DBE93D9BA8F07E4BB22D6C3@cronos.trivium>
Message-ID: <20041013142804.GA1507@openbios.org>

* Sagiv Yefet <sagivy at 3vium.com> [041013 16:11]:
> Actually, I am using 2.4.24. 
> Maybe I should upgrade to 2.6.*. 
> but in the meanwhile what could be the problem?
> 
> The command is:
> 
> ./objdir/sbin/mkelfImage -t bzImage-i386 --kernel=/home/sagivy/bzImage	
> 	--command-line="rw console=ttyS0,115200 root=/dev/ram0"  
> 	--initrd=/home/sagivy/initrd --output=/home/sagivy/bzImage.elf

leave root=/dev/ram0 away in the parameters and say initrd=initrd
instead. IIRC there was some check in Linux that it only looks for an
initrd if there is a parameter saying that there is one.

Stefan



From daubin at actuality-systems.com  Wed Oct 13 09:31:00 2004
From: daubin at actuality-systems.com (Dave Aubin)
Date: Wed Oct 13 09:31:00 2004
Subject: Kernel for linuxbios
Message-ID: <E8F8DBCB0468204E856114A2CD20741F2C18BA@mail.local.ActualitySystems.com>

Hi,

  I have no idea what is in your initrd.  But cracking it open
Might help.  There is an initrc file.  How do you look at the
Contents of an initrd?  Well I am glad you asked;)

First you need to uncompress it as it is compress with gzip.
1.  gunzip -df initrd
2.  mkdir initrd_dir (we will use this to mount the initrd via loopback)
3.  /bin/mount -o loop initrd initrd_dir
4.  cd to initrd_dir

Now you can look at and modify the contents of the initrd.  Specifically
You can see what the initrd is trying to do.  It could be hard coded to
Look at /dev/ram0 I really have no idea.  I know for example suse linux
Has a /etc/sysconfig  that when it's initrd is made it makes assumptions
Based on these files in /etc/config.

Also make sure you have mkelfImage 2.5.

Make sure you have a big enough ramdisk size in your kernel, default is
8Meg???  Or is it 4?
You can override this with ramdisk=8192.  That would be 1024 * 8 for 8
Meg or 8192.

More info for ramdisk, taken from the kernel docs:

--------------------------------------------------
Using the RAM disk block device with Linux
------------------------------------------

Contents:

	1) Overview
	2) Kernel Command Line Parameters
	3) Using "rdev -r" With New Kernels
	4) An Example of Creating a Compressed RAM Disk 


1) Overview
-----------

As of kernel v1.3.48, the RAM disk driver was substantially changed.

The older versions would grab a chunk of memory off the top before
handing the remainder to the kernel at boot time. Thus a size parameter
had to be specified via "ramdisk=1440" or "rdev -r /dev/fd0 1440" so
that the driver knew how much memory to grab.

Now the RAM disk dynamically grows as more space is required. It does
this by using RAM from the buffer cache. The driver marks the buffers
it is using with a new "BH_Protected" flag so that the kernel does 
not try to reuse them later. This means that the old size parameter
is no longer used, new command line parameters exist, and the behavior
of the "rdev -r" or "ramsize" (usually a symbolic link to "rdev")
command has changed.

Also, the new RAM disk supports up to 16 RAM disks out of the box, and
can
be reconfigured in rd.c to support up to 255 RAM disks.  To use multiple
RAM disk support with your system, run 'mknod /dev/ramX b 1 X' and chmod
(to change its permissions) it to your liking.  The default
/dev/ram(disk)
uses minor #1, so start with ram2 and go from there.

The old "ramdisk=<ram_size>" has been changed to
"ramdisk_size=<ram_size>"
to make it clearer.  The original "ramdisk=<ram_size>" has been kept
around
for compatibility reasons, but it will probably be removed in 2.1.x.

The new RAM disk also has the ability to load compressed RAM disk
images,
allowing one to squeeze more programs onto an average installation or 
rescue floppy disk.

Notes: You may have "/dev/ram" or "/dev/ramdisk" or both. They are
equivalent from the standpoint of this document. Also, the new RAM disk
is a config option. When running "make config", make sure you enable
RAM disk support for the kernel with which you intend to use the RAM
disk.


2) Kernel Command Line Parameters
---------------------------------

	ramdisk_start=NNN
	=================

To allow a kernel image to reside on a floppy disk along with a
compressed
RAM disk image, the "ramdisk_start=<offset>" command was added. The
kernel
can't be included into the compressed RAM disk filesystem image, because
it needs to be stored starting at block zero so that the BIOS can load
the 
boot sector and then the kernel can bootstrap itself to get going.

Note: If you are using an uncompressed RAM disk image, then the kernel
can
be a part of the filesystem image that is being loaded into the RAM
disk,
and the floppy can be booted with LILO, or the two can be separate as
is done for the compressed images.

If you are using a two-disk boot/root setup (kernel on #1, RAM disk
image
on #2) then the RAM disk would start at block zero, and an offset of
zero would be used. Since this is the default value, you would not need
to actually use the command at all.

If instead, you have a "zImage" of about 350 kB, and a "fs_image.gz" of
say about 1 MB, and you want them both on the same disk, then you
would use an offset. If you stored the "fs_image.gz" onto the floppy
starting at an offset of 400 kB, you would use "ramdisk_start=400".


	load_ramdisk=N
	==============

This parameter tells the kernel whether it is to try to load a
RAM disk image or not. Specifying "load_ramdisk=1" will tell the
kernel to load a floppy into the RAM disk. The default value is
zero, meaning that the kernel should not try to load a RAM disk.


	prompt_ramdisk=N
	================

This parameter tells the kernel whether or not to give you a prompt
asking you to insert the floppy containing the RAM disk image. In
a single floppy configuration the RAM disk image is on the same floppy
as the kernel that just finished loading/booting and so a prompt
is not needed. In this case one can use "prompt_ramdisk=0". In a
two floppy configuration, you will need the chance to switch disks,
and thus "prompt_ramdisk=1" can be used. Since this is the default 
value, it doesn't really need to be specified.

	ramdisk_size=N
	==============

This parameter tells the RAM disk driver to set up RAM disks of N k
size.  The
default is 4096 (4 MB). 

3) Using "rdev -r" With New Kernels
-----------------------------------

The usage of the word (two bytes) that "rdev -r" sets in the kernel
image
has changed. The low 11 bits (0 -> 10) specify an offset (in 1 k blocks)

of up to 2 MB (2^11) of where to find the RAM disk (this used to be the 
size). Bit 14 indicates that a RAM disk is to be loaded, and bit 15
indicates whether a prompt/wait sequence is to be given before trying
to read the RAM disk. Since the RAM disk dynamically grows as data is
being written into it, a size field is no longer required. Bits 11
to 13 are not currently used and may as well be zero. These numbers
are no magical secrets, as seen below:

./arch/i386/kernel/setup.c:#define RAMDISK_IMAGE_START_MASK     0x07FF
./arch/i386/kernel/setup.c:#define RAMDISK_PROMPT_FLAG          0x8000
./arch/i386/kernel/setup.c:#define RAMDISK_LOAD_FLAG            0x4000

Consider a typical two floppy disk setup, where you will have the 
kernel on disk one, and have already put a RAM disk image onto disk #2.

Hence you want to set bits 0 to 13 as 0, meaning that your RAM disk
starts at an offset of 0 kB from the beginning of the floppy.
The command line equivalent is: "ramdisk_start=0"

You want bit 14 as one, indicating that a RAM disk is to be loaded.
The command line equivalent is: "load_ramdisk=1"

You want bit 15 as one, indicating that you want a prompt/keypress
sequence so that you have a chance to switch floppy disks.
The command line equivalent is: "prompt_ramdisk=1"

Putting that together gives 2^15 + 2^14 + 0 = 49152 for an rdev word.
So to create disk one of the set, you would do:

	/usr/src/linux# cat arch/i386/boot/zImage > /dev/fd0
	/usr/src/linux# rdev /dev/fd0 /dev/fd0
	/usr/src/linux# rdev -r /dev/fd0 49152

If you make a boot disk that has LILO, then for the above, you would
use:
	append = "ramdisk_start=0 load_ramdisk=1 prompt_ramdisk=1"
Since the default start = 0 and the default prompt = 1, you could use:
	append = "load_ramdisk=1"


4) An Example of Creating a Compressed RAM Disk 
----------------------------------------------

To create a RAM disk image, you will need a spare block device to
construct it on. This can be the RAM disk device itself, or an
unused disk partition (such as an unmounted swap partition). For this 
example, we will use the RAM disk device, "/dev/ram".

Note: This technique should not be done on a machine with less than 8 MB
of RAM. If using a spare disk partition instead of /dev/ram, then this
restriction does not apply.

a) Decide on the RAM disk size that you want. Say 2 MB for this example.
   Create it by writing to the RAM disk device. (This step is not
currently
   required, but may be in the future.) It is wise to zero out the
   area (esp. for disks) so that maximal compression is achieved for
   the unused blocks of the image that you are about to create.

	dd if=/dev/zero of=/dev/ram bs=1k count=2048

b) Make a filesystem on it. Say ext2fs for this example.

	mke2fs -vm0 /dev/ram 2048

c) Mount it, copy the files you want to it (eg: /etc/* /dev/* ...)
   and unmount it again.

d) Compress the contents of the RAM disk. The level of compression
   will be approximately 50% of the space used by the files. Unused
   space on the RAM disk will compress to almost nothing.

	dd if=/dev/ram bs=1k count=2048 | gzip -v9 > /tmp/ram_image.gz

e) Put the kernel onto the floppy

	dd if=zImage of=/dev/fd0 bs=1k

f) Put the RAM disk image onto the floppy, after the kernel. Use an
offset
   that is slightly larger than the kernel, so that you can put another
   (possibly larger) kernel onto the same floppy later without
overlapping
   the RAM disk image. An offset of 400 kB for kernels about 350 kB in
   size would be reasonable. Make sure offset+size of ram_image.gz is
   not larger than the total space on your floppy (usually 1440 kB).

	dd if=/tmp/ram_image.gz of=/dev/fd0 bs=1k seek=400

g) Use "rdev" to set the boot device, RAM disk offset, prompt flag, etc.
   For prompt_ramdisk=1, load_ramdisk=1, ramdisk_start=400, one would
   have 2^15 + 2^14 + 400 = 49552.

	rdev /dev/fd0 /dev/fd0
	rdev -r /dev/fd0 49552

That is it. You now have your boot/root compressed RAM disk floppy. Some
users may wish to combine steps (d) and (f) by using a pipe.

------------------------------------------------------------------------
--
						Paul Gortmaker 12/95	

-----Original Message-----
From: Stefan Reinauer [mailto:stepan at openbios.org] 
Sent: Wednesday, October 13, 2004 10:28 AM
To: Sagiv Yefet
Cc: Dave Aubin; linuxbios at clustermatic.org
Subject: Re: Kernel for linuxbios

* Sagiv Yefet <sagivy at 3vium.com> [041013 16:11]:
> Actually, I am using 2.4.24. 
> Maybe I should upgrade to 2.6.*. 
> but in the meanwhile what could be the problem?
> 
> The command is:
> 
> ./objdir/sbin/mkelfImage -t bzImage-i386 --kernel=/home/sagivy/bzImage

> 	--command-line="rw console=ttyS0,115200 root=/dev/ram0"  
> 	--initrd=/home/sagivy/initrd --output=/home/sagivy/bzImage.elf

leave root=/dev/ram0 away in the parameters and say initrd=initrd
instead. IIRC there was some check in Linux that it only looks for an
initrd if there is a parameter saying that there is one.

Stefan



From dmitry at vp.kis.ru  Wed Oct 13 15:06:01 2004
From: dmitry at vp.kis.ru (Dmitry Zavyalov)
Date: Wed Oct 13 15:06:01 2004
Subject: Small changes + videobios question...
In-Reply-To: <Pine.LNX.4.58.0410111231050.17999@linux.site>
References: <411548565.20041009232637@vp.kis.ru>
 <Pine.LNX.4.58.0410111231050.17999@linux.site>
Message-ID: <10418772743.20041014002515@vp.kis.ru>

Ron,

Here is the changed file. The patch comes too big.
Here's not 100% working code yet cause I'm still working but I can say
that is enough to start kernel on 440mx based system.

Also I have success results in running pc338 SIO(serial ports only for
now) and working to run VGA BIOS for CNT69000.

Monday, October 11, 2004, 10:31:21 PM, you wrote:

RGM> On Sat, 9 Oct 2004, Dmitry Zavyalov wrote:
>>   I've made small changes for
>>    southbridge/intel/piix4e/southbridge.c
>>    to let it setup PM and IDE controller properly on Banister(I440MX)
>>    chipset. Do anyone interesting in it?

RGM> I would like to see the patch.

-- 
Best regards,
 Dmitry                            mailto:dmitry at vp.kis.ru

Monday, October 11, 2004
-------------- next part --------------
A non-text attachment was scrubbed...
Name: southbridge.c.gz
Type: application/x-gzip
Size: 2683 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20041013/c8305673/attachment.gz>

From ginlin at nexcom.com.tw  Thu Oct 14 02:15:01 2004
From: ginlin at nexcom.com.tw (Gin)
Date: Thu Oct 14 02:15:01 2004
Subject: linux kernel patch 
Message-ID: <000001c4b1c0$35efc640$8e04010a@nexcom.com.tw>

Hello Ron,
I don't' know if you are still working on this project since it's 2004
now. I just finished a presentation of Linuxbios at work. We are highly
interested in getting linuxbios running on our systems(we design
motherboards). I have a question about the way you do the kernel patch.
If the patch is to initialize the uninitialized hardware in order to run
linux. Then why didn't we add it into the C code. Let it become part of
linuxbios rom image? Furthermore, why do you have different patches for
different linux kernel versions?   
Sorry if the questions are too basic. We just started trying to get it
built. 
 
Thanks,
Gin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20041014/3e8c01ff/attachment.html>

From cro_marmot at comcast.net  Thu Oct 14 02:48:00 2004
From: cro_marmot at comcast.net (David Hendricks)
Date: Thu Oct 14 02:48:00 2004
Subject: linux kernel patch
In-Reply-To: <000001c4b1c0$35efc640$8e04010a@nexcom.com.tw>
References: <000001c4b1c0$35efc640$8e04010a@nexcom.com.tw>
Message-ID: <20041014020732.4c455186@sunder>

We appreciate your interest in the project! As I recall, the patches
were just something for some SiS chipset support in older LinuxBIOS
versions (freebios1). Since then, LinuxBIOS has advanced to include more
generic chipset support that does not require kernel patches.

The current LinuxBIOS (freebios2) will work without patches to your
kernel.

On Thu, 14 Oct 2004 15:34:13 +0800
"Gin" <ginlin at nexcom.com.tw> wrote:

> Hello Ron,
> I don't' know if you are still working on this project since it's 2004
> now. I just finished a presentation of Linuxbios at work. We are
> highly interested in getting linuxbios running on our systems(we
> design motherboards). I have a question about the way you do the
> kernel patch. If the patch is to initialize the uninitialized hardware
> in order to run linux. Then why didn't we add it into the C code. Let
> it become part of linuxbios rom image? Furthermore, why do you have
> different patches for different linux kernel versions?   
> Sorry if the questions are too basic. We just started trying to get it
> built. 
>  
> Thanks,
> Gin
> 


From ginlin at nexcom.com.tw  Thu Oct 14 03:45:01 2004
From: ginlin at nexcom.com.tw (Gin)
Date: Thu Oct 14 03:45:01 2004
Subject: linux kernel patch
In-Reply-To: <20041014020732.4c455186@sunder>
Message-ID: <000001c4b1cc$d2a797e0$8e04010a@nexcom.com.tw>

Hello David,
Thanks for your quick response. Do you know where I can get the latest
linuxbios source code(freebios2)? Call me crazy, but I couldn't seem
able to find it through SourceForge.
http://sourceforge.net/

thanks,
Gin
  

-----Original Message-----
From: linuxbios-admin at clustermatic.org
[mailto:linuxbios-admin at clustermatic.org] On Behalf Of David Hendricks
Sent: Thursday, October 14, 2004 4:08 PM
To: linuxbios at clustermatic.org
Subject: Re: linux kernel patch

We appreciate your interest in the project! As I recall, the patches
were just something for some SiS chipset support in older LinuxBIOS
versions (freebios1). Since then, LinuxBIOS has advanced to include more
generic chipset support that does not require kernel patches.

The current LinuxBIOS (freebios2) will work without patches to your
kernel.

On Thu, 14 Oct 2004 15:34:13 +0800
"Gin" <ginlin at nexcom.com.tw> wrote:

> Hello Ron,
> I don't' know if you are still working on this project since it's 2004
> now. I just finished a presentation of Linuxbios at work. We are
> highly interested in getting linuxbios running on our systems(we
> design motherboards). I have a question about the way you do the
> kernel patch. If the patch is to initialize the uninitialized hardware
> in order to run linux. Then why didn't we add it into the C code. Let
> it become part of linuxbios rom image? Furthermore, why do you have
> different patches for different linux kernel versions?   
> Sorry if the questions are too basic. We just started trying to get it
> built. 
>  
> Thanks,
> Gin
> 
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios



From daubin at actuality-systems.com  Thu Oct 14 07:27:00 2004
From: daubin at actuality-systems.com (Dave Aubin)
Date: Thu Oct 14 07:27:00 2004
Subject: linux kernel patch
Message-ID: <E8F8DBCB0468204E856114A2CD20741F2C18E3@mail.local.ActualitySystems.com>

http://sourceforge.net/cvs/?group_id=3206

Freebios2 is the latest chipsets and mainboards. 

-----Original Message-----
From: linuxbios-admin at clustermatic.org
[mailto:linuxbios-admin at clustermatic.org] On Behalf Of Gin
Sent: Thursday, October 14, 2004 5:05 AM
To: 'David Hendricks'
Cc: linuxbios at clustermatic.org
Subject: RE: linux kernel patch

Hello David,
Thanks for your quick response. Do you know where I can get the latest
linuxbios source code(freebios2)? Call me crazy, but I couldn't seem
able to find it through SourceForge.
http://sourceforge.net/

thanks,
Gin
  

-----Original Message-----
From: linuxbios-admin at clustermatic.org
[mailto:linuxbios-admin at clustermatic.org] On Behalf Of David Hendricks
Sent: Thursday, October 14, 2004 4:08 PM
To: linuxbios at clustermatic.org
Subject: Re: linux kernel patch

We appreciate your interest in the project! As I recall, the patches
were just something for some SiS chipset support in older LinuxBIOS
versions (freebios1). Since then, LinuxBIOS has advanced to include more
generic chipset support that does not require kernel patches.

The current LinuxBIOS (freebios2) will work without patches to your
kernel.

On Thu, 14 Oct 2004 15:34:13 +0800
"Gin" <ginlin at nexcom.com.tw> wrote:

> Hello Ron,
> I don't' know if you are still working on this project since it's 2004

> now. I just finished a presentation of Linuxbios at work. We are 
> highly interested in getting linuxbios running on our systems(we 
> design motherboards). I have a question about the way you do the 
> kernel patch. If the patch is to initialize the uninitialized hardware

> in order to run linux. Then why didn't we add it into the C code. Let 
> it become part of linuxbios rom image? Furthermore, why do you have
> different patches for different linux kernel versions?   
> Sorry if the questions are too basic. We just started trying to get it

> built.
>  
> Thanks,
> Gin
> 
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios

_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From rminnich at lanl.gov  Thu Oct 14 10:12:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Thu Oct 14 10:12:00 2004
Subject: linux kernel patch 
In-Reply-To: <000001c4b1c0$35efc640$8e04010a@nexcom.com.tw>
References: <000001c4b1c0$35efc640$8e04010a@nexcom.com.tw>
Message-ID: <Pine.LNX.4.58.0410140931120.25847@linux.site>

we don't patch kernels any more. Just ignore anything about kernel 
patches.

What's the hardware in question ?What chipset? We're happy to help.

ron



From ebiederman at lnxi.com  Thu Oct 14 14:02:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Oct 14 14:02:00 2004
Subject: FYI: Merge in progress...
Message-ID: <m31xg1p0l4.fsf@maxwell.lnxi.com>

Ron and I are in the middle of a major merge.  So the CVS tree is likely to be in flux
for a bit.

Eric



From yhlu at tyan.com  Thu Oct 14 17:50:00 2004
From: yhlu at tyan.com (Yinghai Lu)
Date: Thu Oct 14 17:50:00 2004
Subject: Merge in progress...
In-Reply-To: <m31xg1p0l4.fsf@maxwell.lnxi.com>
Message-ID: <200410142149.i9ELnwL30507@nwn.definitive.org>

Adding Lindenhurst support?

-----Original Message-----
From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
Sent: Thursday, October 14, 2004 12:22 PM
To: LinuxBIOS
Subject: FYI: Merge in progress...


Ron and I are in the middle of a major merge.  So the CVS tree is likely to
be in flux
for a bit.

Eric

_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios



From rminnich at lanl.gov  Thu Oct 14 20:48:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Thu Oct 14 20:48:01 2004
Subject: FYI: Merge in progress...
In-Reply-To: <m31xg1p0l4.fsf@maxwell.lnxi.com>
References: <m31xg1p0l4.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.58.0410141411200.26315@linux.site>


On Thu, 14 Oct 2004, Eric W. Biederman wrote:

> Ron and I are in the middle of a major merge.  So the CVS tree is likely
> to be in flux for a bit.

Eric, you are so polite. 

Ollie and I are at LNXI in Utah visting Eric, and Jason Schildt of LNXI
just joined on as a new committer (HI JASON :-). We're all hacking like
mad. We're going to really mess things up, but you will thank us in the
end :-)

DON'T do a cvs update unless you're ready to help fix things we bust up.

thanks

ron


From rminnich at lanl.gov  Fri Oct 15 00:26:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Fri Oct 15 00:26:01 2004
Subject: Merge in progress...
In-Reply-To: <200410142149.i9ELnwL30507@nwn.definitive.org>
References: <200410142149.i9ELnwL30507@nwn.definitive.org>
Message-ID: <Pine.LNX.4.58.0410142342480.27226@linux.site>


On Thu, 14 Oct 2004, Yinghai Lu wrote:

> Adding Lindenhurst support?


no, mainly doing a huge code cleanup to make things easier for people. I 
am convinced you will like it.

ron


From ginlin at nexcom.com.tw  Fri Oct 15 03:35:00 2004
From: ginlin at nexcom.com.tw (Gin)
Date: Fri Oct 15 03:35:00 2004
Subject: linux kernel patch 
In-Reply-To: <Pine.LNX.4.58.0410140931120.25847@linux.site>
Message-ID: <000001c4b294$9b9c4430$8e04010a@nexcom.com.tw>

Ron, 
Thanks for the email. I downloaded the freebios2 version. It looks much
cleaner. Good work. Currently we are looking for a proper mainboard
among our products to run linuxbios on. I don't know the specific
chipset but we tend to use Intel solution on our products. Is there any
suggestion for us to pick a chipset/cpu model? We hope to build a more
stable machine at the first time. 

I happened to have a old board(440GX). As I can't wait for they to pick
a mainboard, I decide to try linuxbios on this one first. 
Can I build the linuxbios image from the new source- freebios2? Would
that work as the included directories might have been changed in the new
source?  

For the new source(freebios2)
1. Do we need a Config file for each mainboard to run? Does it work(the
building process)like the old way or it has been changed?
2. Is any document of how to build linuxbios on the new source? 


Regards,
Gin
-----Original Message-----
From: Ronald G. Minnich [mailto:rminnich at lanl.gov] 
Sent: Thursday, October 14, 2004 11:32 PM
To: Gin
Cc: linuxbios at clustermatic.org
Subject: Re: linux kernel patch 

we don't patch kernels any more. Just ignore anything about kernel 
patches.

What's the hardware in question ?What chipset? We're happy to help.

ron



From rminnich at lanl.gov  Fri Oct 15 10:02:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Fri Oct 15 10:02:01 2004
Subject: Flash Chip on EPIA-M10000 (fwd)
Message-ID: <Pine.LNX.4.58.0410150921300.28570@linux.site>


---------- Forwarded message ----------
Date: Fri, 15 Oct 2004 08:10:27 +0200
From: Matthias Stierli <matthias.stierli at hayloft.ch>
To: 'Ronald G. Minnich' <rminnich at lanl.gov>
Subject: Flash Chip on EPIA-M10000


Hi

I'm searching for a bios chip for the EPIA-M10000. 
Unfortunatly I found no distributor for the standard chip (SST 39SF020A) in
switzerland and some neighbour countries.

Is there some alternative for this flash chip, which also can flash during a
running system or a good distributor for a small number of items?

Matthias


Ron?
Is this the common way if i'd have a question to the list?


From joshua at joshuawise.com  Fri Oct 15 14:00:01 2004
From: joshua at joshuawise.com (Joshua Wise)
Date: Fri Oct 15 14:00:01 2004
Subject: Flash Chip on EPIA-M10000 (fwd)
In-Reply-To: <Pine.LNX.4.58.0410150921300.28570@linux.site>
References: <Pine.LNX.4.58.0410150921300.28570@linux.site>
Message-ID: <417022C7.2080809@joshuawise.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

| I'm searching for a bios chip for the EPIA-M10000.
| Unfortunatly I found no distributor for the standard chip (SST
39SF020A) in
| switzerland and some neighbour countries.
|
| Is there some alternative for this flash chip, which also can flash
during a
| running system or a good distributor for a small number of items?
I believe that mouser (mouser.com) will ship anywhere in the world. They
~ seem to have the 39sf020a in stock, priced at $1.84 for one.

They also have the 512kbyte 39sf040, which AFAIK is pin-compatible. The
040 is priced at $2.35 for one.

Of course, as Mouser is in the US, shipping is likely to cost more than
the part itself (d'oh!).

I have heard good things about the UK-based Radio Spares. A quick search
of their site - rswww.com - doesn't turn up the part, but I assume that
if you compare some datasheets for the PLCC parts, you can find a
pin-compatable part.

joshua
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBcCLGPn9tWOqA4LMRAqGzAJ95grRaTJNxIgSKVwKQ9PzNngtQ0ACcCMlT
yUBfqcVqfNYAkZuPQXuy7Lw=
=yRBp
-----END PGP SIGNATURE-----


From rminnich at lanl.gov  Fri Oct 15 14:15:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Fri Oct 15 14:15:01 2004
Subject: Flash Chip on EPIA-M10000 (fwd)
In-Reply-To: <417022C7.2080809@joshuawise.com>
References: <Pine.LNX.4.58.0410150921300.28570@linux.site>
 <417022C7.2080809@joshuawise.com>
Message-ID: <Pine.LNX.4.58.0410151334220.28966@linux.site>

This conversation looks like a beginning to a "where do I get a flash 
part" FAQ

ron

On Fri, 15 Oct 2004, Joshua Wise wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> | I'm searching for a bios chip for the EPIA-M10000.
> | Unfortunatly I found no distributor for the standard chip (SST
> 39SF020A) in
> | switzerland and some neighbour countries.
> |
> | Is there some alternative for this flash chip, which also can flash
> during a
> | running system or a good distributor for a small number of items?
> I believe that mouser (mouser.com) will ship anywhere in the world. They
> ~ seem to have the 39sf020a in stock, priced at $1.84 for one.
> 
> They also have the 512kbyte 39sf040, which AFAIK is pin-compatible. The
> 040 is priced at $2.35 for one.
> 
> Of course, as Mouser is in the US, shipping is likely to cost more than
> the part itself (d'oh!).
> 
> I have heard good things about the UK-based Radio Spares. A quick search
> of their site - rswww.com - doesn't turn up the part, but I assume that
> if you compare some datasheets for the PLCC parts, you can find a
> pin-compatable part.
> 
> joshua
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.6 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> 
> iD8DBQFBcCLGPn9tWOqA4LMRAqGzAJ95grRaTJNxIgSKVwKQ9PzNngtQ0ACcCMlT
> yUBfqcVqfNYAkZuPQXuy7Lw=
> =yRBp
> -----END PGP SIGNATURE-----
> 


From yhlu at tyan.com  Fri Oct 15 15:23:00 2004
From: yhlu at tyan.com (Yinghai Lu)
Date: Fri Oct 15 15:23:00 2004
Subject: FYI: Merge in progress...
In-Reply-To: <Pine.LNX.4.58.0410141411200.26315@linux.site>
Message-ID: <200410151922.i9FJMRL02648@nwn.definitive.org>

If there is another device in CPU link0. how to change the Config.lb?

Also after buildtarget, make failed.

Regards

YH

chip northbridge/amd/amdk8
        print "HI MOM!\n"
        device pnp cf8.0 on                                     # cf8 config
        print "HI MOM!\n"
                device pci 18.0 on                              #
northbridge
        print "HI MOM!\n"
....
end

chip northbridge/amd/amdk8
        print "HI MOM!\n"
        device pnp cf8.0 on                                     # cf8 config
        print "HI MOM!\n"
                device pci 19.0 on                              #
northbridge
        print "HI MOM!\n"
....
end

-----Original Message-----
From: linuxbios-admin at clustermatic.org
[mailto:linuxbios-admin at clustermatic.org] On Behalf Of Ronald G. Minnich
Sent: Thursday, October 14, 2004 1:13 PM
To: Eric W. Biederman
Cc: LinuxBIOS
Subject: Re: FYI: Merge in progress...



On Thu, 14 Oct 2004, Eric W. Biederman wrote:

> Ron and I are in the middle of a major merge.  So the CVS tree is likely
> to be in flux for a bit.

Eric, you are so polite. 

Ollie and I are at LNXI in Utah visting Eric, and Jason Schildt of LNXI
just joined on as a new committer (HI JASON :-). We're all hacking like
mad. We're going to really mess things up, but you will thank us in the
end :-)

DON'T do a cvs update unless you're ready to help fix things we bust up.

thanks

ron
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios



From rminnich at lanl.gov  Fri Oct 15 15:31:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Fri Oct 15 15:31:01 2004
Subject: FYI: Merge in progress...
In-Reply-To: <200410152045.i9FKjLcr021205@proofpoint2.lanl.gov>
References: <200410152045.i9FKjLcr021205@proofpoint2.lanl.gov>
Message-ID: <Pine.LNX.4.58.0410151450140.29014@linux.site>


On Fri, 15 Oct 2004, Yinghai Lu wrote:

> Also after buildtarget, make failed.

don't worry, it won't work for a while.


ron


From ebiederman at lnxi.com  Fri Oct 15 22:09:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Oct 15 22:09:01 2004
Subject: FYI: Merge in progress...
In-Reply-To: <3174569B9743D511922F00A0C94314230665B1A4@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B1A4@TYANWEB>
Message-ID: <m3vfdbcpds.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> Config.g still miss to add
> 
> crt0.S: $(CRT0)
>         cp $< $@
> linuxbios.rom: linuxbios.strip buildrom
>         ./buildrom $< $@ $(PAYLOAD) $(ROM_IMAGE_SIZE) $(ROM_SECTION_SIZE)
> 
> to the fallback/Makfile

Yep.  That is now fixed.

I am working through the changes necessary changes to the static device tree
now.

We are getting there.

Eric


From ebiederman at lnxi.com  Sat Oct 16 04:00:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Sat Oct 16 04:00:01 2004
Subject: FYI: Merge in progress...
In-Reply-To: <m3vfdbcpds.fsf@maxwell.lnxi.com>
References: <3174569B9743D511922F00A0C94314230665B1A4@TYANWEB>
	<m3vfdbcpds.fsf@maxwell.lnxi.com>
Message-ID: <m3wtxr9g0a.fsf@maxwell.lnxi.com>

The ARIMA HDAMA now boots, and everything looks like it is working properly.

Converting everything else still remains but we now have a working example
to look at.

We are down to one device tree instead of two.
And hardwaremain has been reduced to:

void hardwaremain(int boot_complete)
{
	/* the order here is a bit tricky. We don't want to do much of 
	 * anything that uses config registers until after PciAllocateResources
	 * since that function also figures out what kind of config strategy
	 * to use (type 1 or type 2). 
	 * so we turn on cache, then worry about PCI setup, then do other 
	 * things, so that the other work can use the PciRead* and PciWrite*
	 * functions. 
	 */
	struct lb_memory *lb_mem;

	post_code(0x80);

	/* displayinit MUST PRECEDE ALL PRINTK! */
	console_init();
	
	post_code(0x39);
	printk_notice("LinuxBIOS-%s%s %s %s...\n", 
		linuxbios_version, linuxbios_extra_version, linuxbios_build,
		(boot_complete)?"rebooting":"booting");

	post_code(0x40);

	/* If we have already booted attempt a hard reboot */
	if (boot_complete) {
		hard_reset();
	}

	/* FIXME: Is there a better way to handle this? */
	init_timer(); 

	/* pick how to scan the bus. This is first so we can get at memory size. */
	printk_info("Finding PCI configuration type.\n");
	pci_set_method();
	post_code(0x5f);
	dev_enumerate();
	post_code(0x66);
	/* Now do the real bus.
	 * We round the total ram up a lot for thing like the SISFB, which 
	 * shares high memory with the CPU. 
	 */
	dev_configure();
	post_code(0x88);

	dev_enable();

	dev_initialize();
	post_code(0x89);

	/* Now that we have collected all of our information
	 * write our configuration tables.
	 */
	lb_mem = write_tables();

#if CONFIG_FS_STREAM == 1
	filo(lb_mem);
#else
	elfboot(lb_mem);
#endif
}

There is more scrubbing on the horizon but so for things look good.

Eric


From yhlu at tyan.com  Sat Oct 16 11:44:00 2004
From: yhlu at tyan.com (Yinghai Lu)
Date: Sat Oct 16 11:44:00 2004
Subject: FYI: Merge in progress...
In-Reply-To: <m3wtxr9g0a.fsf@maxwell.lnxi.com>
Message-ID: <200410161543.i9GFhML07115@nwn.definitive.org>

So chip tree is merged into device tree.

I'm eager to convert my MB to use that.

Is there any problem for different inherent links in second K8?

Regards

YH

-----Original Message-----
From: Eric W. Biederman [mailto:eric at lnxi.com] On Behalf Of Eric W.
Biederman
Sent: Saturday, October 16, 2004 2:20 AM
To: Ronald G. Minnich
Cc: YhLu; LinuxBIOS
Subject: Re: FYI: Merge in progress...


The ARIMA HDAMA now boots, and everything looks like it is working properly.

Converting everything else still remains but we now have a working example
to look at.

We are down to one device tree instead of two.
And hardwaremain has been reduced to:

void hardwaremain(int boot_complete)
{
	/* the order here is a bit tricky. We don't want to do much of 
	 * anything that uses config registers until after
PciAllocateResources
	 * since that function also figures out what kind of config strategy
	 * to use (type 1 or type 2). 
	 * so we turn on cache, then worry about PCI setup, then do other 
	 * things, so that the other work can use the PciRead* and PciWrite*
	 * functions. 
	 */
	struct lb_memory *lb_mem;

	post_code(0x80);

	/* displayinit MUST PRECEDE ALL PRINTK! */
	console_init();
	
	post_code(0x39);
	printk_notice("LinuxBIOS-%s%s %s %s...\n", 
		linuxbios_version, linuxbios_extra_version, linuxbios_build,
		(boot_complete)?"rebooting":"booting");

	post_code(0x40);

	/* If we have already booted attempt a hard reboot */
	if (boot_complete) {
		hard_reset();
	}

	/* FIXME: Is there a better way to handle this? */
	init_timer(); 

	/* pick how to scan the bus. This is first so we can get at memory
size. */
	printk_info("Finding PCI configuration type.\n");
	pci_set_method();
	post_code(0x5f);
	dev_enumerate();
	post_code(0x66);
	/* Now do the real bus.
	 * We round the total ram up a lot for thing like the SISFB, which 
	 * shares high memory with the CPU. 
	 */
	dev_configure();
	post_code(0x88);

	dev_enable();

	dev_initialize();
	post_code(0x89);

	/* Now that we have collected all of our information
	 * write our configuration tables.
	 */
	lb_mem = write_tables();

#if CONFIG_FS_STREAM == 1
	filo(lb_mem);
#else
	elfboot(lb_mem);
#endif
}

There is more scrubbing on the horizon but so for things look good.

Eric



From ebiederman at lnxi.com  Sat Oct 16 12:32:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Sat Oct 16 12:32:01 2004
Subject: FYI: Merge in progress...
In-Reply-To: <20041016170343.3FFB5D03DF16@spam.llix.net>
References: <20041016170343.3FFB5D03DF16@spam.llix.net>
Message-ID: <m3mzym5z5d.fsf@maxwell.lnxi.com>

"Yinghai Lu" <yhlu at tyan.com> writes:

> So chip tree is merged into device tree.

Yep.
 
> I'm eager to convert my MB to use that.
> 
> Is there any problem for different inherent links in second K8?

Not in theory.  In practice I think this is the one case that has not yet
been fixed in config.g for generation of static.c.

I will take a quick look.

Eric


From ebiederman at lnxi.com  Sat Oct 16 14:47:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Sat Oct 16 14:47:00 2004
Subject: FYI: Merge in progress...
In-Reply-To: <m3mzym5z5d.fsf@maxwell.lnxi.com>
References: <20041016170343.3FFB5D03DF16@spam.llix.net>
	<m3mzym5z5d.fsf@maxwell.lnxi.com>
Message-ID: <m3oej22zsz.fsf@maxwell.lnxi.com>

ebiederman at lnxi.com (Eric W. Biederman) writes:

> "Yinghai Lu" <yhlu at tyan.com> writes:
> 
> > So chip tree is merged into device tree.
> 
> Yep.
>  
> > I'm eager to convert my MB to use that.
> > 
> > Is there any problem for different inherent links in second K8?

Not anymore.  I just worked through that case in config.g and cleaned up that
whole area of code.  Everything looks good at this point.

Eric


From yhlu at tyan.com  Sat Oct 16 19:58:01 2004
From: yhlu at tyan.com (Yinghai Lu)
Date: Sat Oct 16 19:58:01 2004
Subject: FYI: Merge in progress...
In-Reply-To: <m3oej22zsz.fsf@maxwell.lnxi.com>
Message-ID: <200410162357.i9GNvpL08837@nwn.definitive.org>

Great, I will test that Monday. The code can be complied for s2885 and
s2895.

Regards

Yinghai Lu

-----Original Message-----
From: Eric W. Biederman [mailto:eric at lnxi.com] On Behalf Of Eric W.
Biederman
Sent: Saturday, October 16, 2004 1:06 PM
To: Yinghai Lu
Cc: 'Ronald G. Minnich'; 'LinuxBIOS'
Subject: Re: FYI: Merge in progress...

ebiederman at lnxi.com (Eric W. Biederman) writes:

> "Yinghai Lu" <yhlu at tyan.com> writes:
> 
> > So chip tree is merged into device tree.
> 
> Yep.
>  
> > I'm eager to convert my MB to use that.
> > 
> > Is there any problem for different inherent links in second K8?

Not anymore.  I just worked through that case in config.g and cleaned up
that
whole area of code.  Everything looks good at this point.

Eric



From spirit at reactor.ru  Sun Oct 17 11:05:00 2004
From: spirit at reactor.ru (Alexander Amelkin)
Date: Sun Oct 17 11:05:00 2004
Subject: M789 power loss restart
Message-ID: <1199828372.20041017202450@amelkin.msk.ru>

I  bought several M789 motherboards for my company to make Linux-based
routers.  The  boards  seemed very well suitable for such needs and we
previously used similar boards (787cl+ and others, not from PC Chips).

The HUGE problem is that the board does not support Power Loss Restart
function.  That  means  that  if power goes out, then our routers stop
working  and  never resume, even if the power returns. Our routers are
ususally  installed  in  places that are hardly reachable and it takes
several hours to bring them back up after the power outage. Power
outages are often that long that UPS can't handle it. Nobody cares of
it, because the outage usually covers the whole building or district.
However when the power returns to the building, people want their
Internet back. But the router is down due to no "power loss restart".
:(

Previously with 787cl+ motherboard it helped to short-circuit the 14th
and  the  15th  pins  of  the ATX connector so the PSU stayed on. With
M789CLU  such  a  trick  does  not  work. The PSU stays on, but the MB
doesn't boot.

Does anybody know how can I make the board to be always on?
Is there any port register that I should write to?
Or is it a CMOS bit?

The board is built around VIA CLE266/VIA8235 chipset.

Thanks in advance for any hints.
Alexander Amelkin, MSCS
Head of hardware design dept.
TRC FIORD, JSC




From sagivy at 3vium.com  Sun Oct 17 11:51:01 2004
From: sagivy at 3vium.com (Sagiv Yefet)
Date: Sun Oct 17 11:51:01 2004
Subject: Kernel for linuxbios
Message-ID: <4A3D5F6DC9406A4DBE93D9BA8F07E4BB228A9B@cronos.trivium>

I did what you said.
New error:

RAMDISK: Couldn't find valid RAM disk image starting at 0.
Freeing initrd memory: 2624k freed
VFS: Cannot open root device "" or 03:00
Please append a correct "root=" boot option
Kernel panic: VFS: Unable to mount root fs on 03:00

Sagiv.

-----Original Message-----
From: Stefan Reinauer [mailto:stepan at openbios.org] 
Sent: Wednesday, October 13, 2004 4:28 PM
To: Sagiv Yefet
Cc: Dave Aubin; linuxbios at clustermatic.org
Subject: Re: Kernel for linuxbios

* Sagiv Yefet <sagivy at 3vium.com> [041013 16:11]:
> Actually, I am using 2.4.24. 
> Maybe I should upgrade to 2.6.*. 
> but in the meanwhile what could be the problem?
> 
> The command is:
> 
> ./objdir/sbin/mkelfImage -t bzImage-i386 --kernel=/home/sagivy/bzImage

> 	--command-line="rw console=ttyS0,115200 root=/dev/ram0"  
> 	--initrd=/home/sagivy/initrd --output=/home/sagivy/bzImage.elf

leave root=/dev/ram0 away in the parameters and say initrd=initrd
instead. IIRC there was some check in Linux that it only looks for an
initrd if there is a parameter saying that there is one.

Stefan




From joshua at joshuawise.com  Sun Oct 17 13:54:00 2004
From: joshua at joshuawise.com (Joshua Wise)
Date: Sun Oct 17 13:54:00 2004
Subject: M789 power loss restart
In-Reply-To: <1199828372.20041017202450@amelkin.msk.ru>
References: <1199828372.20041017202450@amelkin.msk.ru>
Message-ID: <4172C478.3050903@joshuawise.com>

> Previously with 787cl+ motherboard it helped to short-circuit the 14th
> and  the  15th  pins  of  the ATX connector so the PSU stayed on. With
> M789CLU  such  a  trick  does  not  work. The PSU stays on, but the MB
> doesn't boot.
> 
> Does anybody know how can I make the board to be always on?
> Is there any port register that I should write to?
> Or is it a CMOS bit?
Not sure if there's a software solution, but the hardware solution I'd
recommend would be a 555 timer or some such. Connect the output to a
transistor that would short the power switch lines, and have it pulse
every 30sec or so. (29sec off, 1sec on, or thereabouts) That would give
the board enough time to get into protected mode (and hence refuse to
power down at a single toggle of the switch), while still having a
vaguely responsive system after poweron. You would have to disable acpid
in Linux to keep it from powering itself down again, but that is not a
big deal.

My schematic would look something like this:

    ^ +5V
    |
    +v^v+v^v+-----------+---|(---Ground
    |   |   |           |
+--O---O---O---O--+    |
|  +  DSC THR BYP |    |
  )      555       |    |
| GND TRG OUT RST |    |
+--O---O---O---O--+    |
    |   |   |           |
   GND  +---)-----------+
            |
            >
            <
            >
SW+ ----\  |
          |-+   (NPN)
SW- ----/

joshua

Message not GPG signed because it would screw with the ASCII art; sorry. 
If you would like me to resend with a GPG signature I would be more than 
happy to do so.



From ebiederman at lnxi.com  Sun Oct 17 15:32:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Sun Oct 17 15:32:01 2004
Subject: Kernel for linuxbios
In-Reply-To: <20041013142804.GA1507@openbios.org>
References: <4A3D5F6DC9406A4DBE93D9BA8F07E4BB22D6C3@cronos.trivium>
	<20041013142804.GA1507@openbios.org>
Message-ID: <m34qktt6ft.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at openbios.org> writes:

> * Sagiv Yefet <sagivy at 3vium.com> [041013 16:11]:
> > Actually, I am using 2.4.24. 
> > Maybe I should upgrade to 2.6.*. 
> > but in the meanwhile what could be the problem?
> > 
> > The command is:
> > 
> > ./objdir/sbin/mkelfImage -t bzImage-i386 --kernel=/home/sagivy/bzImage
> 
> > 	--command-line="rw console=ttyS0,115200 root=/dev/ram0"  
> > 	--initrd=/home/sagivy/initrd --output=/home/sagivy/bzImage.elf
> 
> leave root=/dev/ram0 away in the parameters and say initrd=initrd
> instead. IIRC there was some check in Linux that it only looks for an
> initrd if there is a parameter saying that there is one.

Not those arguments should be correct.  The initrd command line
is only parsed by bootloaders, especially by the HPA's bootloaders
syslinux, isolinux, and pxelinux.

Eric




From ebiederman at lnxi.com  Sun Oct 17 15:37:59 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Sun Oct 17 15:37:59 2004
Subject: Kernel for linuxbios
In-Reply-To: <4A3D5F6DC9406A4DBE93D9BA8F07E4BB228A9B@cronos.trivium>
References: <4A3D5F6DC9406A4DBE93D9BA8F07E4BB228A9B@cronos.trivium>
Message-ID: <m3zn2lrrqa.fsf@maxwell.lnxi.com>

"Sagiv Yefet" <sagivy at 3vium.com> writes:

> I did what you said.
> New error:
> 
> RAMDISK: Couldn't find valid RAM disk image starting at 0.
> Freeing initrd memory: 2624k freed
> VFS: Cannot open root device "" or 03:00
> Please append a correct "root=" boot option
> Kernel panic: VFS: Unable to mount root fs on 03:00

I hate looking at things with the messages cropped, it can hide useful
information.

In any case the kernel line:
> Freeing initrd memory: 2624k freed.
Indicates that the initrd is being found, and there is data there.

The line:
> RAMDISK: Couldn't find valid RAM disk image starting at 0.

Indicates that your initrd is either corrupted or it is in a format
your kernel does not recognize.

Do you have the proper filesystem in your kernel.  Is your initrd
compressed?  In some cases filesystems are only recognized inside a
compressed initrd.

Eric


From marc at geekythings.com  Sun Oct 17 17:39:00 2004
From: marc at geekythings.com (Marc Nicholas)
Date: Sun Oct 17 17:39:00 2004
Subject: Flash Chip on EPIA-M10000 (fwd)
In-Reply-To: <Pine.LNX.4.58.0410151334220.28966@linux.site>
References: <Pine.LNX.4.58.0410150921300.28570@linux.site>
 <417022C7.2080809@joshuawise.com> <Pine.LNX.4.58.0410151334220.28966@linux.site>
Message-ID: <Pine.GSO.4.60.0410171852310.6416@geek>

Does this mean the EPIA boards use LPC flash?


-marc

On Fri, 15 Oct 2004, Ronald G. Minnich wrote:

>
> This conversation looks like a beginning to a "where do I get a flash
> part" FAQ
>
> ron
>
> On Fri, 15 Oct 2004, Joshua Wise wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> | I'm searching for a bios chip for the EPIA-M10000.
>> | Unfortunatly I found no distributor for the standard chip (SST
>> 39SF020A) in
>> | switzerland and some neighbour countries.
>> |
>> | Is there some alternative for this flash chip, which also can flash
>> during a
>> | running system or a good distributor for a small number of items?
>> I believe that mouser (mouser.com) will ship anywhere in the world. They
>> ~ seem to have the 39sf020a in stock, priced at $1.84 for one.
>>
>> They also have the 512kbyte 39sf040, which AFAIK is pin-compatible. The
>> 040 is priced at $2.35 for one.
>>
>> Of course, as Mouser is in the US, shipping is likely to cost more than
>> the part itself (d'oh!).
>>
>> I have heard good things about the UK-based Radio Spares. A quick search
>> of their site - rswww.com - doesn't turn up the part, but I assume that
>> if you compare some datasheets for the PLCC parts, you can find a
>> pin-compatable part.
>>
>> joshua
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.2.6 (GNU/Linux)
>> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>>
>> iD8DBQFBcCLGPn9tWOqA4LMRAqGzAJ95grRaTJNxIgSKVwKQ9PzNngtQ0ACcCMlT
>> yUBfqcVqfNYAkZuPQXuy7Lw=
>> =yRBp
>> -----END PGP SIGNATURE-----
>>
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>


From liutao at safe-mail.net  Mon Oct 18 04:06:00 2004
From: liutao at safe-mail.net (Liu Tao)
Date: Mon Oct 18 04:06:00 2004
Subject: PCI IRQ tables
In-Reply-To: <3174569B9743D511922F00A0C94314230624C5E6@TYANWEB>
References: <3174569B9743D511922F00A0C94314230624C5E6@TYANWEB>
Message-ID: <41738C77.2090202@safe-mail.net>

YhLu wrote:

>SMP or single CPU?
> 
>If SMP, and io apci is enabled, you may only focus on mptable.c and
>irq-tables.c may only contain device that point to the peer roots bus.
> 
>YH
>  
>
How about single CPU with IO-APIC enabled in linux?

We are designing a new AMD64 mainboard and want to use linuxbios,
the IO architecture is showed in the attached picture. I'm not sure how
to specify the "PCI IRQ Router" in pirq table for this architecture. Since
each AMD8131 and AMD8111 all provide legacy PIC mode interrupt
controller, I think maybe there isn't a global legacy PIC mode PCI IRQ
router for different NCHT channels? Maybe APIC is the better choice?

Best Regards,
Liu Tao


From liutao at safe-mail.net  Mon Oct 18 04:29:01 2004
From: liutao at safe-mail.net (Liu Tao)
Date: Mon Oct 18 04:29:01 2004
Subject: PCI IRQ tables
In-Reply-To: <3174569B9743D511922F00A0C94314230624C5E6@TYANWEB>
References: <3174569B9743D511922F00A0C94314230624C5E6@TYANWEB>
Message-ID: <417391E3.9040300@safe-mail.net>

YhLu wrote:

>SMP or single CPU?
> 
>If SMP, and io apci is enabled, you may only focus on mptable.c and
>irq-tables.c may only contain device that point to the peer roots bus.
> 
>YH
>  
>

How about single CPU with IO-APIC enabled in linux?

We are designing a new AMD64 mainboard and want to use linuxbios,
the IO architecture is showed in the attached picture. I'm not
sure how to specify the "PCI IRQ Router" in pirq table for this 
architecture. Since each AMD8131 and AMD8111 all provide legacy
PIC mode interrupt controller, I think maybe there isn't a global
legacy PIC mode PCI IRQ router for different NCHT channels?
Maybe APIC is the better choice?

Best Regards,
Liu Tao

-------------- next part --------------
A non-text attachment was scrubbed...
Name: amd64.png
Type: image/png
Size: 35833 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20041018/ea3f710d/attachment.png>

From ginlin at nexcom.com.tw  Mon Oct 18 05:07:00 2004
From: ginlin at nexcom.com.tw (Gin)
Date: Mon Oct 18 05:07:00 2004
Subject: linux kernel patch 
In-Reply-To: <Pine.LNX.4.58.0410140931120.25847@linux.site>
Message-ID: <000001c4b4fc$f60f4290$8e04010a@nexcom.com.tw>

Ron,
We have decided to build linuxbios on one of our mainboards, which
contains 
Intel chipset E7501, Xeon Processor.
Since now it's during the major cleanup of the code, do you suggest we
can go ahead and build it on the new source(freebios2)?
Is there any documentation related to how to build rom image from the
new source? We appreciate your help. The product we try to build
linuxbios on is currently in the market. We are also interested in
building it on another platform that has an AMD K8 CPU on it. 

Regards,
Gin  





-----Original Message-----
From: linuxbios-admin at clustermatic.org
[mailto:linuxbios-admin at clustermatic.org] On Behalf Of Ronald G. Minnich
Sent: Thursday, October 14, 2004 11:32 PM
To: Gin
Cc: linuxbios at clustermatic.org
Subject: Re: linux kernel patch 

we don't patch kernels any more. Just ignore anything about kernel 
patches.

What's the hardware in question ?What chipset? We're happy to help.

ron

_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios



From rminnich at lanl.gov  Mon Oct 18 11:00:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Oct 18 11:00:01 2004
Subject: FYI: Merge in progress...
In-Reply-To: <200410161543.i9GFhML07115@nwn.definitive.org>
References: <200410161543.i9GFhML07115@nwn.definitive.org>
Message-ID: <Pine.LNX.4.58.0410181017570.3965@linux.site>

Yeah, well, how about this: here's how target config files look now:



# Sample config file for Motorola Sandpoint X3 Demo Board with
# the Arima HDAMA
# This will make a target directory of ./hdama


target hdama
mainboard arima/hdama

# Arima hdama
romimage "normal"
	option USE_FALLBACK_IMAGE=0
	option ROM_IMAGE_SIZE=0x10000
	option LINUXBIOS_EXTRA_VERSION=".0Normal"
	payload /usr/share/etherboot/5.2.1eb1-lnxi-lb/tg3--ide_disk.zelf
end

romimage "fallback" 
	option USE_FALLBACK_IMAGE=1
	option ROM_IMAGE_SIZE=0x10000
	option LINUXBIOS_EXTRA_VERSION=".0Fallback"
	payload /usr/share/etherboot/5.2.1eb1-lnxi-lb/tg3--ide_disk.zelf
end

buildrom ./linuxbios.rom ROM_SIZE "normal" "fallback"




A bit simpler eh?

ron


From rminnich at lanl.gov  Mon Oct 18 11:08:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Oct 18 11:08:00 2004
Subject: FYI: Merge in progress...
In-Reply-To: <200410161543.i9GFhML07115@nwn.definitive.org>
References: <200410161543.i9GFhML07115@nwn.definitive.org>
Message-ID: <Pine.LNX.4.58.0410181019500.3965@linux.site>

I ought to mention:

last week's efforts which result in this week's improvements were a joint 
project of Eric, Tom, and Jason (LNXI) and Ollie and me (LANL). 

So thanks to them if you like what happened :-)

ron


From YhLu at tyan.com  Mon Oct 18 11:13:00 2004
From: YhLu at tyan.com (YhLu)
Date: Mon Oct 18 11:13:00 2004
Subject: PCI IRQ tables
Message-ID: <3174569B9743D511922F00A0C94314230665B1B0@TYANWEB>

It's the same if you enable io apic.

In the irq-table.

Add 
Entry Bus 1 for 8111 and 8131
Other 8131 bus may be discovered by Kernel.

Regards

YH

-----Original Message-----
From: Liu Tao [mailto:liutao at safe-mail.net] 
Sent: Monday, October 18, 2004 2:50 AM
To: YhLu
Cc: Dave Aubin; linuxbios at clustermatic.org
Subject: Re: PCI IRQ tables

YhLu wrote:

>SMP or single CPU?
> 
>If SMP, and io apci is enabled, you may only focus on mptable.c and
>irq-tables.c may only contain device that point to the peer roots bus.
> 
>YH
>  
>

How about single CPU with IO-APIC enabled in linux?

We are designing a new AMD64 mainboard and want to use linuxbios,
the IO architecture is showed in the attached picture. I'm not
sure how to specify the "PCI IRQ Router" in pirq table for this 
architecture. Since each AMD8131 and AMD8111 all provide legacy
PIC mode interrupt controller, I think maybe there isn't a global
legacy PIC mode PCI IRQ router for different NCHT channels?
Maybe APIC is the better choice?

Best Regards,
Liu Tao



From ollie at lanl.gov  Mon Oct 18 11:21:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Mon Oct 18 11:21:01 2004
Subject: FYI: Merge in progress...
In-Reply-To: <200410161543.i9GFhML07115@nwn.definitive.org>
References: <200410161543.i9GFhML07115@nwn.definitive.org>
Message-ID: <1098117597.3495.33.camel@exponential.lanl.gov>

On Sat, 2004-10-16 at 11:03, Yinghai Lu wrote:
> So chip tree is merged into device tree.
> 
> I'm eager to convert my MB to use that.
> 
> Is there any problem for different inherent links in second K8?
> 

I am a little bit confused with that too. I think now the 'link' keyword
is not used anymore, the device enumeration code will put the 2nd 
northbridge on the right LDT accroding to the early HT enumertion.

Ollie




From ebiederman at lnxi.com  Mon Oct 18 11:44:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Oct 18 11:44:00 2004
Subject: FYI: Merge in progress...
In-Reply-To: <1098117597.3495.33.camel@exponential.lanl.gov>
References: <200410161543.i9GFhML07115@nwn.definitive.org>
	<1098117597.3495.33.camel@exponential.lanl.gov>
Message-ID: <m3y8i46jq8.fsf@maxwell.lnxi.com>

Li-Ta Lo <ollie at lanl.gov> writes:

> On Sat, 2004-10-16 at 11:03, Yinghai Lu wrote:
> > So chip tree is merged into device tree.
> > 
> > I'm eager to convert my MB to use that.
> > 
> > Is there any problem for different inherent links in second K8?
> > 
> 
> I am a little bit confused with that too. I think now the 'link' keyword
> is not used anymore, the device enumeration code will put the 2nd 
> northbridge on the right LDT accroding to the early HT enumertion.

Sorry, for not making this clearer.  Look at the generated static.c
if my following explanation does not clear things up.

The device tree from the HDAMA mainboard Config.lb is below:
The first time device pci 18.0 is mentioned that is link[0] in for the device.
The second time is link[1] the third time is link[2]...

And then the amdk8 code maps link[0] to LDT0 link[1] to LD[1 and link[2] to LDT2.

A similar condition exists for the phillips pca9545 i2c switch.
It only has one register but it has 4 downstream ports.  

We may want to do something cleaner than just repeating the device once for
each ``link/bus'' but for now that works.

Eric


chip northbridge/amd/amdk8
	device pci_domain 0 on
		device pci 18.0 on #  northbridge 
			#  devices on link 0, link 0 == LDT 0 
			chip southbridge/amd/amd8131
				# the on/off keyword is mandatory
				device pci 0.0 on end
				device pci 0.1 on end
				device pci 1.0 on end
				device pci 1.1 on end
			end
			chip southbridge/amd/amd8111
				# this "device pci 0.0" is the parent the next one
				# PCI bridge
				device pci 0.0 on
					device pci 0.0 on end
					device pci 0.1 on end
					device pci 0.2 on end
					device pci 1.0 off end
				end
				device pci 1.0 on
					chip superio/NSC/pc87360
						device	pnp 2e.0 off  # Floppy 
							 io 0x60 = 0x3f0
							irq 0x70 = 6
							drq 0x74 = 2
						end
						device pnp 2e.1 off  # Parallel Port
							 io 0x60 = 0x378
							irq 0x70 = 7
						end
						device pnp 2e.2 off # Com 2
							 io 0x60 = 0x2f8
							irq 0x70 = 3
						end
						device pnp 2e.3 on  # Com 1
							 io 0x60 = 0x3f8
							irq 0x70 = 4
						end
						device pnp 2e.4 off end # SWC
						device pnp 2e.5 off end # Mouse
						device pnp 2e.6 on  # Keyboard
							 io 0x60 = 0x60
							 io 0x62 = 0x64
							irq 0x70 = 1
						end
						device pnp 2e.7 off end # GPIO
						device pnp 2e.8 off end # ACB
						device pnp 2e.9 off end # FSCM
						device pnp 2e.a off end # WDT  
					end
				end
				device pci 1.1 on end
				device pci 1.2 on end
				device pci 1.3 on 
					chip drivers/generic/generic
						#phillips pca9545 smbus mux
						device i2c 70 on 
							# analog_devices adm1026	
							chip drivers/generic/generic
								device i2c 2c on end
							end
						end
						device i2c 70 on end
						device i2c 70 on end
						device i2c 70 on end
					end
					chip drivers/generic/generic #dimm 0-0-0
						device i2c 50 on end
					end
					chip drivers/generic/generic #dimm 0-0-1
						device i2c 51 on end
					end 
					chip drivers/generic/generic #dimm 0-1-0
						device i2c 52 on end
					end 
					chip drivers/generic/generic #dimm 0-1-1
						device i2c 53 on end
					end 
					chip drivers/generic/generic #dimm 1-0-0
						device i2c 54 on end 
					end
					chip drivers/generic/generic #dimm 1-0-1
						device i2c 55 on end
					end 
					chip drivers/generic/generic #dimm 1-1-0
						device i2c 56 on end
					end 
					chip drivers/generic/generic #dimm 1-1-1
						device i2c 57 on end
					end 
				end
				device pci 1.5 off end
				device pci 1.6 on end
			end
		end #  device pci 18.0 
		
		device pci 18.0 on end # LDT1
		device pci 18.0 on end # LDT2
		device pci 18.1 on end
		device pci 18.2 on end
		device pci 18.3 on end

		chip northbridge/amd/amdk8
			device pci 19.0 on end
			device pci 19.0 on end
			device pci 19.0 on end
			device pci 19.1 on end
			device pci 19.2 on end
			device pci 19.3 on end
		end
	end 
	device apic_cluster 0 on
		chip cpu/amd/socket_940
			device apic 0 on end
		end
		chip cpu/amd/socket_940
			device apic 1 on end
		end
	end
end





From rminnich at lanl.gov  Mon Oct 18 12:02:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Oct 18 12:02:00 2004
Subject: Kernel for linuxbios
In-Reply-To: <4A3D5F6DC9406A4DBE93D9BA8F07E4BB228A9B@cronos.trivium>
References: <4A3D5F6DC9406A4DBE93D9BA8F07E4BB228A9B@cronos.trivium>
Message-ID: <Pine.LNX.4.58.0410181121210.3965@linux.site>


On Sun, 17 Oct 2004, Sagiv Yefet wrote:

> I did what you said.
> New error:
> 
> RAMDISK: Couldn't find valid RAM disk image starting at 0.
> Freeing initrd memory: 2624k freed
> VFS: Cannot open root device "" or 03:00
> Please append a correct "root=" boot option
> Kernel panic: VFS: Unable to mount root fs on 03:00

3:00 is hda, which is not what you what, I guess. 

ron


From YhLu at tyan.com  Mon Oct 18 12:11:00 2004
From: YhLu at tyan.com (YhLu)
Date: Mon Oct 18 12:11:00 2004
Subject: FYI: Merge in progress...
Message-ID: <3174569B9743D511922F00A0C94314230665B1C0@TYANWEB>

I got some err.

It seems scan_k8_chains is not called.


LinuxBIOS-1.1.62.0_Fallback Mon Oct 18 09:29:09 PDT 2004 booting...
Finding PCI configuration type.
PCI: Using configuration type 1
Enumerating buses...
scan_static_bus for Root Device
PCI_DOMAIN: 0000 enabled
APIC_CLUSTER: 0 enabled
PCI_DOMAIN: 0000 scanning...
PCI: pci_scan_bus for bus 0
PCI: 00:18.0 [1022/1100] bus ops
PCI: 00:18.0 [1022/1100] enabled
PCI: 00:18.1 [1022/1101] enabled
PCI: 00:18.2 [1022/1102] enabled
PCI: 00:18.3 [1022/1103] ops
PCI: 00:18.3 [1022/1103] enabled
PCI: 00:19.0 [1022/1100] bus ops
PCI: 00:19.0 [1022/1100] enabled
PCI: 00:19.1 [1022/1101] enabled
PCI: 00:19.2 [1022/1102] enabled
PCI: 00:19.3 [1022/1103] ops
PCI: 00:19.3 [1022/1103] enabled
PCI: 01:01.0 Hypertransport link capability not foundHyperT reset not needed
PCI: pci_scan_bus for bus 1
PCI: 01:00.0 [10de/005e] enabled
PCI: 01:01.0 [10de/0051] bus ops
PCI: 01:01.0 [10de/0051] enabled
PCI: 01:01.1 [10de/0052] enabled
scan_static_bus for PCI: 01:01.0


From rminnich at lanl.gov  Mon Oct 18 12:18:08 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Oct 18 12:18:08 2004
Subject: linux kernel patch 
In-Reply-To: <000001c4b4fc$f60f4290$8e04010a@nexcom.com.tw>
References: <000001c4b4fc$f60f4290$8e04010a@nexcom.com.tw>
Message-ID: <Pine.LNX.4.58.0410181133470.3965@linux.site>


On Mon, 18 Oct 2004, Gin wrote:

> Ron,
> We have decided to build linuxbios on one of our mainboards, which
> contains 
> Intel chipset E7501, Xeon Processor.
> Since now it's during the major cleanup of the code, do you suggest we
> can go ahead and build it on the new source(freebios2)?

absolutely.

> Is there any documentation related to how to build rom image from the
> new source? 

no. Sorry. It's a problem.

we can help, however.

ron


From ollie at lanl.gov  Mon Oct 18 12:32:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Mon Oct 18 12:32:00 2004
Subject: FYI: Merge in progress...
In-Reply-To: <m3y8i46jq8.fsf@maxwell.lnxi.com>
References: <200410161543.i9GFhML07115@nwn.definitive.org>
	 <1098117597.3495.33.camel@exponential.lanl.gov>
	 <m3y8i46jq8.fsf@maxwell.lnxi.com>
Message-ID: <1098121944.3495.42.camel@exponential.lanl.gov>

On Mon, 2004-10-18 at 11:04, Eric W. Biederman wrote:
> Li-Ta Lo <ollie at lanl.gov> writes:
> 
> > On Sat, 2004-10-16 at 11:03, Yinghai Lu wrote:
> > > So chip tree is merged into device tree.
> > > 
> > > I'm eager to convert my MB to use that.
> > > 
> > > Is there any problem for different inherent links in second K8?
> > > 
> > 
> > I am a little bit confused with that too. I think now the 'link' keyword
> > is not used anymore, the device enumeration code will put the 2nd 
> > northbridge on the right LDT accroding to the early HT enumertion.
> 
> Sorry, for not making this clearer.  Look at the generated static.c
> if my following explanation does not clear things up.
> 
> The device tree from the HDAMA mainboard Config.lb is below:
> The first time device pci 18.0 is mentioned that is link[0] in for the device.
> The second time is link[1] the third time is link[2]...
> 
> And then the amdk8 code maps link[0] to LDT0 link[1] to LD[1 and link[2] to LDT2.
> 
> A similar condition exists for the phillips pca9545 i2c switch.
> It only has one register but it has 4 downstream ports.  
> 
> We may want to do something cleaner than just repeating the device once for
> each ``link/bus'' but for now that works.
> 

I think YHLu's question is that the CPU0 and CPU1 are connected by LDT1 
one each side. So how do we say
	northbridge_18_0.link[0].something = northbridge_19_0
and
	northbridge_19_0.link[0].something = northbridge_18_0
in the config file ?

Or it will be set dynamically at run time ?

Ollie
  



From YhLu at tyan.com  Mon Oct 18 13:19:00 2004
From: YhLu at tyan.com (YhLu)
Date: Mon Oct 18 13:19:00 2004
Subject: FYI: Merge in progress...
Message-ID: <3174569B9743D511922F00A0C94314230665B1E4@TYANWEB>

Werid, it should look for 1:0.0 instead of 1:1.0 before unit id is updated
in hypertransport_scan_chain.

YH

-----Original Message-----
From: YhLu 
Sent: Monday, October 18, 2004 10:36 AM
To: ebiederman at lnxi.com; Li-Ta Lo
Cc: 'Ronald G. Minnich'; 'LinuxBIOS'
Subject: RE: FYI: Merge in progress...

I got some err.

It seems scan_k8_chains is not called.


LinuxBIOS-1.1.62.0_Fallback Mon Oct 18 09:29:09 PDT 2004 booting...
Finding PCI configuration type.
PCI: Using configuration type 1
Enumerating buses...
scan_static_bus for Root Device
PCI_DOMAIN: 0000 enabled
APIC_CLUSTER: 0 enabled
PCI_DOMAIN: 0000 scanning...
PCI: pci_scan_bus for bus 0
PCI: 00:18.0 [1022/1100] bus ops
PCI: 00:18.0 [1022/1100] enabled
PCI: 00:18.1 [1022/1101] enabled
PCI: 00:18.2 [1022/1102] enabled
PCI: 00:18.3 [1022/1103] ops
PCI: 00:18.3 [1022/1103] enabled
PCI: 00:19.0 [1022/1100] bus ops
PCI: 00:19.0 [1022/1100] enabled
PCI: 00:19.1 [1022/1101] enabled
PCI: 00:19.2 [1022/1102] enabled
PCI: 00:19.3 [1022/1103] ops
PCI: 00:19.3 [1022/1103] enabled
PCI: 01:01.0 Hypertransport link capability not foundHyperT reset not needed
PCI: pci_scan_bus for bus 1
PCI: 01:00.0 [10de/005e] enabled
PCI: 01:01.0 [10de/0051] bus ops
PCI: 01:01.0 [10de/0051] enabled
PCI: 01:01.1 [10de/0052] enabled
scan_static_bus for PCI: 01:01.0
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From ebiederman at lnxi.com  Mon Oct 18 13:48:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Oct 18 13:48:00 2004
Subject: FYI: Merge in progress...
In-Reply-To: <1098121944.3495.42.camel@exponential.lanl.gov>
References: <200410161543.i9GFhML07115@nwn.definitive.org>
	<1098117597.3495.33.camel@exponential.lanl.gov>
	<m3y8i46jq8.fsf@maxwell.lnxi.com>
	<1098121944.3495.42.camel@exponential.lanl.gov>
Message-ID: <m3zn2j4zf4.fsf@maxwell.lnxi.com>

Li-Ta Lo <ollie at lanl.gov> writes:


> I think YHLu's question is that the CPU0 and CPU1 are connected by LDT1 
> one each side. So how do we say
> 	northbridge_18_0.link[0].something = northbridge_19_0
> and
> 	northbridge_19_0.link[0].something = northbridge_18_0
> in the config file ?
> 
> Or it will be set dynamically at run time ?

So far the is still handled in auto.c like it always has been.
The dynamic code ignores coherent links.

While we have moved things around.  The functional part of the code
really has not changed.  We just skip the step of the old static
tree.

An interesting static is that static.c compiles to 35K but compresses
to about 500 bytes. :)

Eric


From ollie at lanl.gov  Mon Oct 18 13:54:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Mon Oct 18 13:54:01 2004
Subject: FYI: Merge in progress...
In-Reply-To: <m3zn2j4zf4.fsf@maxwell.lnxi.com>
References: <200410161543.i9GFhML07115@nwn.definitive.org>
	 <1098117597.3495.33.camel@exponential.lanl.gov>
	 <m3y8i46jq8.fsf@maxwell.lnxi.com>
	 <1098121944.3495.42.camel@exponential.lanl.gov>
	 <m3zn2j4zf4.fsf@maxwell.lnxi.com>
Message-ID: <1098126855.3495.44.camel@exponential.lanl.gov>

On Mon, 2004-10-18 at 13:08, Eric W. Biederman wrote:
> 
> An interesting static is that static.c compiles to 35K but compresses
> to about 500 bytes. :)
> 

This is exactly why I was proposing this change. We also got rid of
a lot of static -> dynamice code.

Ollie




From ebiederman at lnxi.com  Mon Oct 18 14:00:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Oct 18 14:00:01 2004
Subject: FYI: Merge in progress...
In-Reply-To: <3174569B9743D511922F00A0C94314230665B1E4@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B1E4@TYANWEB>
Message-ID: <m3vfd74ywb.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> Werid, it should look for 1:0.0 instead of 1:1.0 before unit id is updated
> in hypertransport_scan_chain.

There is a double scan.  Once in hypertransport.c  where the unitids are
assigned.  And pci_scan_bus is called to finish the enumeration.

The logic should still play nice with Nvidia chipsets, but I may have
touched something.  There was a nonsensical disabling of link optimizations
in misc_control.c for the single cpu case.  Just limiting the optimization
to AMD chipsets as the FIXME suggested would have been better.

> -----Original Message-----
> From: YhLu 
> Sent: Monday, October 18, 2004 10:36 AM
> To: ebiederman at lnxi.com; Li-Ta Lo
> Cc: 'Ronald G. Minnich'; 'LinuxBIOS'
> Subject: RE: FYI: Merge in progress...
> 
> I got some err.
> 
> It seems scan_k8_chains is not called.

I think I have just disabled that print statement.
 
> LinuxBIOS-1.1.62.0_Fallback Mon Oct 18 09:29:09 PDT 2004 booting...
> Finding PCI configuration type.
> PCI: Using configuration type 1
> Enumerating buses...
> scan_static_bus for Root Device
> PCI_DOMAIN: 0000 enabled
> APIC_CLUSTER: 0 enabled
> PCI_DOMAIN: 0000 scanning...
> PCI: pci_scan_bus for bus 0
> PCI: 00:18.0 [1022/1100] bus ops
> PCI: 00:18.0 [1022/1100] enabled
> PCI: 00:18.1 [1022/1101] enabled
> PCI: 00:18.2 [1022/1102] enabled
> PCI: 00:18.3 [1022/1103] ops
> PCI: 00:18.3 [1022/1103] enabled
> PCI: 00:19.0 [1022/1100] bus ops
> PCI: 00:19.0 [1022/1100] enabled
> PCI: 00:19.1 [1022/1101] enabled
> PCI: 00:19.2 [1022/1102] enabled
> PCI: 00:19.3 [1022/1103] ops
> PCI: 00:19.3 [1022/1103] enabled
> PCI: 01:01.0 Hypertransport link capability not foundHyperT reset not needed
> PCI: pci_scan_bus for bus 1
> PCI: 01:00.0 [10de/005e] enabled
> PCI: 01:01.0 [10de/0051] bus ops
> PCI: 01:01.0 [10de/0051] enabled
> PCI: 01:01.1 [10de/0052] enabled
> scan_static_bus for PCI: 01:01.0

For comparison purposes the HDAMA boot looks like:
LinuxBIOS-1.1.6.8pre3Normal Sat Oct 16 13:50:39 MDT 2004 starting...
setting up resource map....done.
02 nodes initialized.
coherent_ht_finalize
done
Ram1.00
Ram1.01
Ram2.00
Ram2.01
Ram3
Initializing memory:  done
Initializing memory:  done
Clearing initial memory region:  done
Ram4
Copying LinuxBIOS to ram.
Jumping to LinuxBIOS.
LinuxBIOS-1.1.6.8pre3Normal Sat Oct 16 13:50:39 MDT 2004 booting...
Finding PCI configuration type.
PCI: Using configuration type 1
Enumerating buses...
scan_static_bus for Root Device
PCI_DOMAIN: 0000 enabled
APIC_CLUSTER: 0 enabled
PCI_DOMAIN: 0000 scanning...
PCI: pci_scan_bus for bus 0
PCI: 00:18.0 [1022/1100] bus ops
PCI: 00:18.0 [1022/1100] enabled
PCI: 00:18.1 [1022/1101] enabled
PCI: 00:18.2 [1022/1102] enabled
PCI: 00:18.3 [1022/1103] ops
PCI: 00:18.3 [1022/1103] enabled
PCI: 00:19.0 [1022/1100] bus ops
PCI: 00:19.0 [1022/1100] enabled
PCI: 00:19.1 [1022/1101] enabled
PCI: 00:19.2 [1022/1102] enabled
PCI: 00:19.3 [1022/1103] ops
PCI: 00:19.3 [1022/1103] enabled
PCI: 01:01.0 [1022/7450] enabled next_unitid: 0003
PCI: 01:03.0 [1022/7460] enabled next_unitid: 0007
HyperT reset not needed
PCI: pci_scan_bus for bus 1
PCI: 01:01.0 [1022/7450] bus ops
PCI: 01:01.0 [1022/7450] enabled
PCI: 01:01.1 [1022/7451] ops
PCI: 01:01.1 [1022/7451] enabled
PCI: 01:02.0 [1022/7450] bus ops
PCI: 01:02.0 [1022/7450] enabled
PCI: 01:02.1 [1022/7451] ops
PCI: 01:02.1 [1022/7451] enabled
PCI: 01:03.0 [1022/7460] bus ops
PCI: 01:03.0 [1022/7460] enabled
PCI: 01:04.0 [1022/7468] bus ops
PCI: 01:04.0 [1022/7468] enabled
PCI: 01:04.1 [1022/7469] ops
PCI: 01:04.1 [1022/7469] enabled
PCI: 01:04.2 [1022/746a] enabled
PCI: 01:04.3 [1022/746b] ops
PCI: 01:04.3 [1022/746b] enabled
PCI: 01:04.5 No device operations
PCI: 01:04.6 [1022/746e] ops
PCI: 01:04.6 [1022/746e] enabled
PCI: pci_scan_bus for bus 2
PCI: 02:03.0 [14e4/16a6] enabled
PCI: 02:04.0 [14e4/16a6] enabled
PCI: pci_scan_bus returning with max=02
PCI: pci_scan_bus for bus 3
PCI: 03:01.0 [15b3/5a46] enabled
PCI: pci_scan_bus for bus 4
PCI: 04:00.0 [15b3/5a44] enabled
PCI: pci_scan_bus returning with max=04
PCI: pci_scan_bus returning with max=04
PCI: pci_scan_bus for bus 5
PCI: 05:00.0 [1022/7464] enabled
PCI: 05:00.1 [1022/7464] enabled
PCI: 05:00.2 [1022/7463] enabled
PCI: 05:01.0 No device operations
PCI: 05:06.0 [1002/4752] enabled
PCI: pci_scan_bus returning with max=05
scan_static_bus for PCI: 01:04.0
PNP: 002e.0 disabled
PNP: 002e.1 disabled
PNP: 002e.2 disabled
PNP: 002e.3 enabled
PNP: 002e.4 disabled
PNP: 002e.5 disabled
PNP: 002e.6 enabled
PNP: 002e.7 disabled
PNP: 002e.8 disabled
PNP: 002e.9 disabled
PNP: 002e.a disabled
scan_static_bus done
PCI: pci_scan_bus returning with max=05
PCI: pci_scan_bus returning with max=05
APIC_CLUSTER: 0 scanning...
CPU: APIC: 00 enabled
CPU: APIC: 01 enabled
scan_static_bus done
done
Allocating resources...
PCI: 01:01.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 2 io
PCI: 01:01.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 2 prefmem
PCI: 03:01.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 4 io
PCI: 01:02.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 3 io
PCI: 01:03.0 24 <- [0x00fff00000 - 0x00ffefffff] bus 5 prefmem
Allocating VGA resource PCI: 05:06.0
PCI_DOMAIN: 0000 00 <- [0x0000001000 - 0x0000002fff] io
PCI_DOMAIN: 0000 01 <- [0xfcf0000000 - 0xfcf87fffff] prefmem
PCI_DOMAIN: 0000 02 <- [0x00f8000000 - 0x00fd3fffff] mem
PCI: 00:18.0 1b8 <- [0xfcf0000000 - 0xfcf87fffff] prefmem <node 0 link 0>
PCI: 00:18.0 1c0 <- [0x0000001000 - 0x0000002fff] io <node 0 link 0>
PCI: 00:18.0 1b0 <- [0x00fc000000 - 0x00fd3fffff] mem <node 0 link 0>
PCI: 01:01.0 20 <- [0x00fd100000 - 0x00fd1fffff] bus 2 mem
PCI: 02:03.0 10 <- [0x00fd100000 - 0x00fd10ffff] mem
PCI: 02:04.0 10 <- [0x00fd110000 - 0x00fd11ffff] mem
PCI: 01:01.1 10 <- [0x00fd300000 - 0x00fd300fff] mem
PCI: 01:02.0 24 <- [0xfcf0000000 - 0xfcf87fffff] bus 3 prefmem
PCI: 01:02.0 20 <- [0x00fd200000 - 0x00fd2fffff] bus 3 mem
PCI: 03:01.0 24 <- [0xfcf0000000 - 0xfcf87fffff] bus 4 prefmem
PCI: 03:01.0 20 <- [0x00fd200000 - 0x00fd2fffff] bus 4 mem
PCI: 04:00.0 10 <- [0x00fd200000 - 0x00fd2fffff] mem
PCI: 04:00.0 18 <- [0xfcf8000000 - 0xfcf87fffff] prefmem
PCI: 04:00.0 20 <- [0xfcf0000000 - 0xfcf7ffffff] prefmem
PCI: 01:02.1 10 <- [0x00fd301000 - 0x00fd301fff] mem
PCI: 01:03.0 1c <- [0x0000001000 - 0x0000001fff] bus 5 io
PCI: 01:03.0 20 <- [0x00fc000000 - 0x00fd0fffff] bus 5 mem
PCI: 05:00.0 10 <- [0x00fd000000 - 0x00fd000fff] mem
PCI: 05:00.1 10 <- [0x00fd001000 - 0x00fd001fff] mem
PCI: 05:00.2 10 <- [0x00fd003000 - 0x00fd0030ff] mem
PCI: 05:00.2 14 <- [0x00fd004000 - 0x00fd00401f] mem
PCI: 05:06.0 10 <- [0x00fc000000 - 0x00fcffffff] mem
PCI: 05:06.0 14 <- [0x0000001000 - 0x00000010ff] io
PCI: 05:06.0 18 <- [0x00fd002000 - 0x00fd002fff] mem
ERROR: PNP: 002e.3 60 not allocated
ERROR: PNP: 002e.3 70 not allocated
ERROR: PNP: 002e.6 60 not allocated
ERROR: PNP: 002e.6 62 not allocated
ERROR: PNP: 002e.6 70 not allocated
PCI: 01:04.1 20 <- [0x00000028b0 - 0x00000028bf] io
PCI: 01:04.2 10 <- [0x0000002880 - 0x000000289f] io
PCI: 01:04.3 58 <- [0x0000002000 - 0x00000020ff] io
PCI: 01:04.6 10 <- [0x0000002400 - 0x00000024ff] io
PCI: 01:04.6 14 <- [0x0000002800 - 0x000000287f] io
PCI: 00:18.3 94 <- [0x00f8000000 - 0x00fbffffff] mem <gart>
PCI: 00:19.3 94 <- [0x00f8000000 - 0x00fbffffff] mem <gart>
done.
Enabling resourcess...
PCI: 00:18.0 cmd <- 140
PCI: 01:01.0 bridge ctrl <- 0003
PCI: 01:01.0 cmd <- 146
PCI: 02:03.0 cmd <- 142
PCI: 02:04.0 cmd <- 142
PCI: 01:01.1 cmd <- 146
PCI: 01:02.0 bridge ctrl <- 0003
PCI: 01:02.0 cmd <- 146
PCI: 03:01.0 bridge ctrl <- 0003
PCI: 03:01.0 cmd <- 146
PCI: 04:00.0 cmd <- 142
PCI: 01:02.1 cmd <- 146
PCI: 01:03.0 bridge ctrl <- 000b
PCI: 01:03.0 cmd <- 147
PCI: 05:00.0 subsystem <- 00/00
PCI: 05:00.0 cmd <- 142
PCI: 05:00.1 subsystem <- 00/00
PCI: 05:00.1 cmd <- 142
PCI: 05:00.2 subsystem <- 00/00
PCI: 05:00.2 cmd <- 142
PCI: 05:06.0 cmd <- 1c3
PCI: 01:04.0 cmd <- 14f
PCI: 01:04.1 cmd <- 141
PCI: 01:04.2 subsystem <- 00/00
PCI: 01:04.2 cmd <- 141
PCI: 01:04.3 cmd <- 141
I2C: 70 missing enable_resources
I2C: 50 missing enable_resources
I2C: 51 missing enable_resources
I2C: 52 missing enable_resources
I2C: 53 missing enable_resources
I2C: 54 missing enable_resources
I2C: 55 missing enable_resources
I2C: 56 missing enable_resources
I2C: 57 missing enable_resources
PCI: 01:04.6 cmd <- 141
PCI: 00:18.1 subsystem <- 00/00
PCI: 00:18.1 cmd <- 140
PCI: 00:18.2 subsystem <- 00/00
PCI: 00:18.2 cmd <- 140
PCI: 00:18.3 cmd <- 140
PCI: 00:19.0 cmd <- 140
PCI: 00:19.1 subsystem <- 00/00
PCI: 00:19.1 cmd <- 140
PCI: 00:19.2 subsystem <- 00/00
PCI: 00:19.2 cmd <- 140
PCI: 00:19.3 cmd <- 140
done.
Initializing devices...
Root Device init
PCI: 00:18.0 init
done.
PCI: 01:01.0 init
PCI: 01:02.0 init
PCI: 01:03.0 init
PCI: 01:04.0 init
RTC Init
enabling HPET @0xfed00000
PNP: 002e.3 init
PNP: 002e.6 init
PCI: 01:04.1 init
IDE1 IDE0 PCI: 01:04.3 init
set power on after power fail
PCI: 00:18.3 init
NB: Function 3 Misc Control.. done.
PCI: 00:19.0 init
done.
PCI: 00:19.3 init
NB: Function 3 Misc Control.. done.
APIC_CLUSTER: 0 init
Initializing CPU #0
CPU: vendor AMD device f58
Enabling cache

Setting fixed MTRRs(0-88) type: UC
Setting fixed MTRRs(0-16) Type: WB
Setting fixed MTRRs(24-88) Type: WB
DONE fixed MTRRs
Setting variable MTRR 0, base:    0MB, range: 2048MB, type WB
Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB
Setting variable MTRR 2, base: 3072MB, range:  512MB, type WB
Setting variable MTRR 3, base: 3584MB, range:  256MB, type WB
Setting variable MTRR 4, base: 3840MB, range:  128MB, type WB
Setting variable MTRR 5, base: 4096MB, range: 1024MB, type WB
DONE variable MTRRs
Clear out the extra MTRR's

MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

Clearing memory 0K - 4194304K: --------------------------------------------------------------- done
Setting up local apic... apic_id: 0 done.
CPU #0 Initialized
Initializing CPU #1
Waiting for 1 CPUS to stop
CPU: vendor AMD device f58
Enabling cache

Setting fixed MTRRs(0-88) type: UC
Setting fixed MTRRs(0-16) Type: WB
Setting fixed MTRRs(24-88) Type: WB
DONE fixed MTRRs
Setting variable MTRR 0, base:    0MB, range: 2048MB, type WB
Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB
Setting variable MTRR 2, base: 3072MB, range:  512MB, type WB
Setting variable MTRR 3, base: 3584MB, range:  256MB, type WB
Setting variable MTRR 4, base: 3840MB, range:  128MB, type WB
Setting variable MTRR 5, base: 4096MB, range: 1024MB, type WB
DONE variable MTRRs
Clear out the extra MTRR's

MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

C - 5242880K: ++++++++++++++++ done
Setting up local apic... apic_id: 1 done.
CPU #1 Initialized
All AP CPUs stopped
Devices initialized
Copying IRQ routing tables to 0xf0000...done.
Verifing copy of IRQ routing tables at 0xf0000...done
Checking IRQ routing table consistency...
/home/eric/projects/linuxbios/linuxbios/hdama/freebios2/src/arch/i386/boot/pirq_routing.c:    28:check_pirq_routing_table() - irq_routing_table located at: 0x000f0000
done.
Wrote the mp table end at: 00000020 - 00000224
Wrote linuxbios table at: 00000500 - 00000d94  checksum 21a5

Welcome to elfboot, the open sourced starter.
January 2002, Eric Biederman.
Version 1.3


    23:stream_init() - rom_stream: 0xfff80000 - 0xfffcffff
Found ELF candiate at offset 0
Loading Etherboot version: 5.2.4eb6
Dropping non PT_LOAD segment
New segment addr 0x20000 size 0x41e43 offset 0xc0 filesize 0x9928
(cleaned up) New segment addr 0x20000 size 0x41e43 offset 0xc0 filesize 0x9928
Loading Segment: addr: 0x00000000f7fc8000 memsz: 0x000000000000e000 filesz: 0x0000000000009928
Clearing Segment: addr: 0x00000000f7fd1928 memsz: 0x00000000000046d8
Loading Segment: addr: 0x000000000002e000 memsz: 0x0000000000033e43 filesz: 0x0000000000000000
Clearing Segment: addr: 0x000000000002e000 memsz: 0x0000000000033e43
Jumping to boot code at 0x20000
ROM segment 0x0000 length 0x0000 reloc 0x00020000
CPU 2072 Mhz
Etherboot 5.2.4eb6 (GPL) http://etherboot.org ELF64 ELF with TFTP SLAM LACP for [EEPRO100][E1000][3C90X][TG3][IDE]
Relocating _text from: [00029920,00063070) to [f7ec68b0,f7f00000)
Boot from (N)etwork (D)isk or (Q)uit? ^Mrobing pci nic...
[tg3-5702X]Ethernet addr: 00:50:45:00:E5:13
Tigon3 [partno(BCM95702A20) rev 1002 PHY(5703)] (PCI:66MHz:32-bit)
Link is up at 100 Mbps, full duplex. TX RX flow control
Searching for server (DHCP)...
...Me: 172.16.16.90, Server: 172.16.31.253, Relay: 172.16.23.254, Gateway 172.16.23.254
Loading 172.16.31.253:k8-boot.ebi ...(ELF)... ..................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................done


From YhLu at tyan.com  Mon Oct 18 14:03:01 2004
From: YhLu at tyan.com (YhLu)
Date: Mon Oct 18 14:03:01 2004
Subject: FYI: Merge in progress...
Message-ID: <3174569B9743D511922F00A0C94314230665B1ED@TYANWEB>

My fault, last week I change my Config.lb and build scripts. Mess up the pci
0.0 to pci 1.0.

YH

-----Original Message-----
From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
Sent: Monday, October 18, 2004 12:20 PM
To: YhLu
Cc: Li-Ta Lo; 'Ronald G. Minnich'; 'LinuxBIOS'
Subject: Re: FYI: Merge in progress...

YhLu <YhLu at tyan.com> writes:

> Werid, it should look for 1:0.0 instead of 1:1.0 before unit id is updated
> in hypertransport_scan_chain.

There is a double scan.  Once in hypertransport.c  where the unitids are
assigned.  And pci_scan_bus is called to finish the enumeration.

The logic should still play nice with Nvidia chipsets, but I may have
touched something.  There was a nonsensical disabling of link optimizations
in misc_control.c for the single cpu case.  Just limiting the optimization
to AMD chipsets as the FIXME suggested would have been better.

> -----Original Message-----
> From: YhLu 
> Sent: Monday, October 18, 2004 10:36 AM
> To: ebiederman at lnxi.com; Li-Ta Lo
> Cc: 'Ronald G. Minnich'; 'LinuxBIOS'
> Subject: RE: FYI: Merge in progress...
> 
> I got some err.
> 
> It seems scan_k8_chains is not called.

I think I have just disabled that print statement.
 
> LinuxBIOS-1.1.62.0_Fallback Mon Oct 18 09:29:09 PDT 2004 booting...
> Finding PCI configuration type.
> PCI: Using configuration type 1
> Enumerating buses...
> scan_static_bus for Root Device
> PCI_DOMAIN: 0000 enabled
> APIC_CLUSTER: 0 enabled
> PCI_DOMAIN: 0000 scanning...
> PCI: pci_scan_bus for bus 0
> PCI: 00:18.0 [1022/1100] bus ops
> PCI: 00:18.0 [1022/1100] enabled
> PCI: 00:18.1 [1022/1101] enabled
> PCI: 00:18.2 [1022/1102] enabled
> PCI: 00:18.3 [1022/1103] ops
> PCI: 00:18.3 [1022/1103] enabled
> PCI: 00:19.0 [1022/1100] bus ops
> PCI: 00:19.0 [1022/1100] enabled
> PCI: 00:19.1 [1022/1101] enabled
> PCI: 00:19.2 [1022/1102] enabled
> PCI: 00:19.3 [1022/1103] ops
> PCI: 00:19.3 [1022/1103] enabled
> PCI: 01:01.0 Hypertransport link capability not foundHyperT reset not
needed
> PCI: pci_scan_bus for bus 1
> PCI: 01:00.0 [10de/005e] enabled
> PCI: 01:01.0 [10de/0051] bus ops
> PCI: 01:01.0 [10de/0051] enabled
> PCI: 01:01.1 [10de/0052] enabled
> scan_static_bus for PCI: 01:01.0

For comparison purposes the HDAMA boot looks like:
LinuxBIOS-1.1.6.8pre3Normal Sat Oct 16 13:50:39 MDT 2004 starting...
setting up resource map....done.
02 nodes initialized.
coherent_ht_finalize
done
Ram1.00
Ram1.01
Ram2.00
Ram2.01
Ram3
Initializing memory:  done
Initializing memory:  done
Clearing initial memory region:  done
Ram4
Copying LinuxBIOS to ram.
Jumping to LinuxBIOS.
LinuxBIOS-1.1.6.8pre3Normal Sat Oct 16 13:50:39 MDT 2004 booting...
Finding PCI configuration type.
PCI: Using configuration type 1
Enumerating buses...
scan_static_bus for Root Device
PCI_DOMAIN: 0000 enabled
APIC_CLUSTER: 0 enabled
PCI_DOMAIN: 0000 scanning...
PCI: pci_scan_bus for bus 0
PCI: 00:18.0 [1022/1100] bus ops
PCI: 00:18.0 [1022/1100] enabled
PCI: 00:18.1 [1022/1101] enabled
PCI: 00:18.2 [1022/1102] enabled
PCI: 00:18.3 [1022/1103] ops
PCI: 00:18.3 [1022/1103] enabled
PCI: 00:19.0 [1022/1100] bus ops
PCI: 00:19.0 [1022/1100] enabled
PCI: 00:19.1 [1022/1101] enabled
PCI: 00:19.2 [1022/1102] enabled
PCI: 00:19.3 [1022/1103] ops
PCI: 00:19.3 [1022/1103] enabled
PCI: 01:01.0 [1022/7450] enabled next_unitid: 0003
PCI: 01:03.0 [1022/7460] enabled next_unitid: 0007
HyperT reset not needed
PCI: pci_scan_bus for bus 1
PCI: 01:01.0 [1022/7450] bus ops
PCI: 01:01.0 [1022/7450] enabled
PCI: 01:01.1 [1022/7451] ops
PCI: 01:01.1 [1022/7451] enabled
PCI: 01:02.0 [1022/7450] bus ops
PCI: 01:02.0 [1022/7450] enabled
PCI: 01:02.1 [1022/7451] ops
PCI: 01:02.1 [1022/7451] enabled
PCI: 01:03.0 [1022/7460] bus ops
PCI: 01:03.0 [1022/7460] enabled
PCI: 01:04.0 [1022/7468] bus ops
PCI: 01:04.0 [1022/7468] enabled
PCI: 01:04.1 [1022/7469] ops
PCI: 01:04.1 [1022/7469] enabled
PCI: 01:04.2 [1022/746a] enabled
PCI: 01:04.3 [1022/746b] ops
PCI: 01:04.3 [1022/746b] enabled
PCI: 01:04.5 No device operations
PCI: 01:04.6 [1022/746e] ops
PCI: 01:04.6 [1022/746e] enabled
PCI: pci_scan_bus for bus 2
PCI: 02:03.0 [14e4/16a6] enabled
PCI: 02:04.0 [14e4/16a6] enabled
PCI: pci_scan_bus returning with max=02
PCI: pci_scan_bus for bus 3
PCI: 03:01.0 [15b3/5a46] enabled
PCI: pci_scan_bus for bus 4
PCI: 04:00.0 [15b3/5a44] enabled
PCI: pci_scan_bus returning with max=04
PCI: pci_scan_bus returning with max=04
PCI: pci_scan_bus for bus 5
PCI: 05:00.0 [1022/7464] enabled
PCI: 05:00.1 [1022/7464] enabled
PCI: 05:00.2 [1022/7463] enabled
PCI: 05:01.0 No device operations
PCI: 05:06.0 [1002/4752] enabled
PCI: pci_scan_bus returning with max=05
scan_static_bus for PCI: 01:04.0
PNP: 002e.0 disabled
PNP: 002e.1 disabled
PNP: 002e.2 disabled
PNP: 002e.3 enabled
PNP: 002e.4 disabled
PNP: 002e.5 disabled
PNP: 002e.6 enabled
PNP: 002e.7 disabled
PNP: 002e.8 disabled
PNP: 002e.9 disabled
PNP: 002e.a disabled
scan_static_bus done
PCI: pci_scan_bus returning with max=05
PCI: pci_scan_bus returning with max=05
APIC_CLUSTER: 0 scanning...
CPU: APIC: 00 enabled
CPU: APIC: 01 enabled
scan_static_bus done
done
Allocating resources...
PCI: 01:01.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 2 io
PCI: 01:01.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 2 prefmem
PCI: 03:01.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 4 io
PCI: 01:02.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 3 io
PCI: 01:03.0 24 <- [0x00fff00000 - 0x00ffefffff] bus 5 prefmem
Allocating VGA resource PCI: 05:06.0
PCI_DOMAIN: 0000 00 <- [0x0000001000 - 0x0000002fff] io
PCI_DOMAIN: 0000 01 <- [0xfcf0000000 - 0xfcf87fffff] prefmem
PCI_DOMAIN: 0000 02 <- [0x00f8000000 - 0x00fd3fffff] mem
PCI: 00:18.0 1b8 <- [0xfcf0000000 - 0xfcf87fffff] prefmem <node 0 link 0>
PCI: 00:18.0 1c0 <- [0x0000001000 - 0x0000002fff] io <node 0 link 0>
PCI: 00:18.0 1b0 <- [0x00fc000000 - 0x00fd3fffff] mem <node 0 link 0>
PCI: 01:01.0 20 <- [0x00fd100000 - 0x00fd1fffff] bus 2 mem
PCI: 02:03.0 10 <- [0x00fd100000 - 0x00fd10ffff] mem
PCI: 02:04.0 10 <- [0x00fd110000 - 0x00fd11ffff] mem
PCI: 01:01.1 10 <- [0x00fd300000 - 0x00fd300fff] mem
PCI: 01:02.0 24 <- [0xfcf0000000 - 0xfcf87fffff] bus 3 prefmem
PCI: 01:02.0 20 <- [0x00fd200000 - 0x00fd2fffff] bus 3 mem
PCI: 03:01.0 24 <- [0xfcf0000000 - 0xfcf87fffff] bus 4 prefmem
PCI: 03:01.0 20 <- [0x00fd200000 - 0x00fd2fffff] bus 4 mem
PCI: 04:00.0 10 <- [0x00fd200000 - 0x00fd2fffff] mem
PCI: 04:00.0 18 <- [0xfcf8000000 - 0xfcf87fffff] prefmem
PCI: 04:00.0 20 <- [0xfcf0000000 - 0xfcf7ffffff] prefmem
PCI: 01:02.1 10 <- [0x00fd301000 - 0x00fd301fff] mem
PCI: 01:03.0 1c <- [0x0000001000 - 0x0000001fff] bus 5 io
PCI: 01:03.0 20 <- [0x00fc000000 - 0x00fd0fffff] bus 5 mem
PCI: 05:00.0 10 <- [0x00fd000000 - 0x00fd000fff] mem
PCI: 05:00.1 10 <- [0x00fd001000 - 0x00fd001fff] mem
PCI: 05:00.2 10 <- [0x00fd003000 - 0x00fd0030ff] mem
PCI: 05:00.2 14 <- [0x00fd004000 - 0x00fd00401f] mem
PCI: 05:06.0 10 <- [0x00fc000000 - 0x00fcffffff] mem
PCI: 05:06.0 14 <- [0x0000001000 - 0x00000010ff] io
PCI: 05:06.0 18 <- [0x00fd002000 - 0x00fd002fff] mem
ERROR: PNP: 002e.3 60 not allocated
ERROR: PNP: 002e.3 70 not allocated
ERROR: PNP: 002e.6 60 not allocated
ERROR: PNP: 002e.6 62 not allocated
ERROR: PNP: 002e.6 70 not allocated
PCI: 01:04.1 20 <- [0x00000028b0 - 0x00000028bf] io
PCI: 01:04.2 10 <- [0x0000002880 - 0x000000289f] io
PCI: 01:04.3 58 <- [0x0000002000 - 0x00000020ff] io
PCI: 01:04.6 10 <- [0x0000002400 - 0x00000024ff] io
PCI: 01:04.6 14 <- [0x0000002800 - 0x000000287f] io
PCI: 00:18.3 94 <- [0x00f8000000 - 0x00fbffffff] mem <gart>
PCI: 00:19.3 94 <- [0x00f8000000 - 0x00fbffffff] mem <gart>
done.
Enabling resourcess...
PCI: 00:18.0 cmd <- 140
PCI: 01:01.0 bridge ctrl <- 0003
PCI: 01:01.0 cmd <- 146
PCI: 02:03.0 cmd <- 142
PCI: 02:04.0 cmd <- 142
PCI: 01:01.1 cmd <- 146
PCI: 01:02.0 bridge ctrl <- 0003
PCI: 01:02.0 cmd <- 146
PCI: 03:01.0 bridge ctrl <- 0003
PCI: 03:01.0 cmd <- 146
PCI: 04:00.0 cmd <- 142
PCI: 01:02.1 cmd <- 146
PCI: 01:03.0 bridge ctrl <- 000b
PCI: 01:03.0 cmd <- 147
PCI: 05:00.0 subsystem <- 00/00
PCI: 05:00.0 cmd <- 142
PCI: 05:00.1 subsystem <- 00/00
PCI: 05:00.1 cmd <- 142
PCI: 05:00.2 subsystem <- 00/00
PCI: 05:00.2 cmd <- 142
PCI: 05:06.0 cmd <- 1c3
PCI: 01:04.0 cmd <- 14f
PCI: 01:04.1 cmd <- 141
PCI: 01:04.2 subsystem <- 00/00
PCI: 01:04.2 cmd <- 141
PCI: 01:04.3 cmd <- 141
I2C: 70 missing enable_resources
I2C: 50 missing enable_resources
I2C: 51 missing enable_resources
I2C: 52 missing enable_resources
I2C: 53 missing enable_resources
I2C: 54 missing enable_resources
I2C: 55 missing enable_resources
I2C: 56 missing enable_resources
I2C: 57 missing enable_resources
PCI: 01:04.6 cmd <- 141
PCI: 00:18.1 subsystem <- 00/00
PCI: 00:18.1 cmd <- 140
PCI: 00:18.2 subsystem <- 00/00
PCI: 00:18.2 cmd <- 140
PCI: 00:18.3 cmd <- 140
PCI: 00:19.0 cmd <- 140
PCI: 00:19.1 subsystem <- 00/00
PCI: 00:19.1 cmd <- 140
PCI: 00:19.2 subsystem <- 00/00
PCI: 00:19.2 cmd <- 140
PCI: 00:19.3 cmd <- 140
done.
Initializing devices...
Root Device init
PCI: 00:18.0 init
done.
PCI: 01:01.0 init
PCI: 01:02.0 init
PCI: 01:03.0 init
PCI: 01:04.0 init
RTC Init
enabling HPET @0xfed00000
PNP: 002e.3 init
PNP: 002e.6 init
PCI: 01:04.1 init
IDE1 IDE0 PCI: 01:04.3 init
set power on after power fail
PCI: 00:18.3 init
NB: Function 3 Misc Control.. done.
PCI: 00:19.0 init
done.
PCI: 00:19.3 init
NB: Function 3 Misc Control.. done.
APIC_CLUSTER: 0 init
Initializing CPU #0
CPU: vendor AMD device f58
Enabling cache

Setting fixed MTRRs(0-88) type: UC
Setting fixed MTRRs(0-16) Type: WB
Setting fixed MTRRs(24-88) Type: WB
DONE fixed MTRRs
Setting variable MTRR 0, base:    0MB, range: 2048MB, type WB
Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB
Setting variable MTRR 2, base: 3072MB, range:  512MB, type WB
Setting variable MTRR 3, base: 3584MB, range:  256MB, type WB
Setting variable MTRR 4, base: 3840MB, range:  128MB, type WB
Setting variable MTRR 5, base: 4096MB, range: 1024MB, type WB
DONE variable MTRRs
Clear out the extra MTRR's

MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

Clearing memory 0K - 4194304K:
--------------------------------------------------------------- done
Setting up local apic... apic_id: 0 done.
CPU #0 Initialized
Initializing CPU #1
Waiting for 1 CPUS to stop
CPU: vendor AMD device f58
Enabling cache

Setting fixed MTRRs(0-88) type: UC
Setting fixed MTRRs(0-16) Type: WB
Setting fixed MTRRs(24-88) Type: WB
DONE fixed MTRRs
Setting variable MTRR 0, base:    0MB, range: 2048MB, type WB
Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB
Setting variable MTRR 2, base: 3072MB, range:  512MB, type WB
Setting variable MTRR 3, base: 3584MB, range:  256MB, type WB
Setting variable MTRR 4, base: 3840MB, range:  128MB, type WB
Setting variable MTRR 5, base: 4096MB, range: 1024MB, type WB
DONE variable MTRRs
Clear out the extra MTRR's

MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

C - 5242880K: ++++++++++++++++ done
Setting up local apic... apic_id: 1 done.
CPU #1 Initialized
All AP CPUs stopped
Devices initialized
Copying IRQ routing tables to 0xf0000...done.
Verifing copy of IRQ routing tables at 0xf0000...done
Checking IRQ routing table consistency...
/home/eric/projects/linuxbios/linuxbios/hdama/freebios2/src/arch/i386/boot/p
irq_routing.c:    28:check_pirq_routing_table() - irq_routing_table located
at: 0x000f0000
done.
Wrote the mp table end at: 00000020 - 00000224
Wrote linuxbios table at: 00000500 - 00000d94  checksum 21a5

Welcome to elfboot, the open sourced starter.
January 2002, Eric Biederman.
Version 1.3


    23:stream_init() - rom_stream: 0xfff80000 - 0xfffcffff
Found ELF candiate at offset 0
Loading Etherboot version: 5.2.4eb6
Dropping non PT_LOAD segment
New segment addr 0x20000 size 0x41e43 offset 0xc0 filesize 0x9928
(cleaned up) New segment addr 0x20000 size 0x41e43 offset 0xc0 filesize
0x9928
Loading Segment: addr: 0x00000000f7fc8000 memsz: 0x000000000000e000 filesz:
0x0000000000009928
Clearing Segment: addr: 0x00000000f7fd1928 memsz: 0x00000000000046d8
Loading Segment: addr: 0x000000000002e000 memsz: 0x0000000000033e43 filesz:
0x0000000000000000
Clearing Segment: addr: 0x000000000002e000 memsz: 0x0000000000033e43
Jumping to boot code at 0x20000
ROM segment 0x0000 length 0x0000 reloc 0x00020000
CPU 2072 Mhz
Etherboot 5.2.4eb6 (GPL) http://etherboot.org ELF64 ELF with TFTP SLAM LACP
for [EEPRO100][E1000][3C90X][TG3][IDE]
Relocating _text from: [00029920,00063070) to [f7ec68b0,f7f00000)
Boot from (N)etwork (D)isk or (Q)uit? ^Mrobing pci nic...
[tg3-5702X]Ethernet addr: 00:50:45:00:E5:13
Tigon3 [partno(BCM95702A20) rev 1002 PHY(5703)] (PCI:66MHz:32-bit)
Link is up at 100 Mbps, full duplex. TX RX flow control
Searching for server (DHCP)...
...Me: 172.16.16.90, Server: 172.16.31.253, Relay: 172.16.23.254, Gateway
172.16.23.254
Loading 172.16.31.253:k8-boot.ebi ...(ELF)...
............................................................................
............................................................................
............................................................................
............................................................................
............................................................................
............................................................................
............................................................................
............................................................................
............................................................................
............................................................................
............................................................................
............................................................................
............................................................................
............................................................................
............................................................................
............................................................................
............................................................................
......done


From rminnich at lanl.gov  Mon Oct 18 15:16:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Oct 18 15:16:00 2004
Subject: FYI: Merge in progress...
In-Reply-To: <1098126855.3495.44.camel@exponential.lanl.gov>
References: <200410161543.i9GFhML07115@nwn.definitive.org> 
 <1098117597.3495.33.camel@exponential.lanl.gov>  <m3y8i46jq8.fsf@maxwell.lnxi.com>
  <1098121944.3495.42.camel@exponential.lanl.gov>  <m3zn2j4zf4.fsf@maxwell.lnxi.com>
 <1098126855.3495.44.camel@exponential.lanl.gov>
Message-ID: <Pine.LNX.4.58.0410181435180.3965@linux.site>


On Mon, 18 Oct 2004, Li-Ta Lo wrote:
> This is exactly why I was proposing this change. We also got rid of
> a lot of static -> dynamice code.
> 

even cooler: there is no static code structure any more. What the config 
tool creates is a statically allocated set of device structs. The 
enumeration of static to dynamic is gone. 

And so on, and so on, it's a huge improvement.

ron


From YhLu at tyan.com  Mon Oct 18 15:22:00 2004
From: YhLu at tyan.com (YhLu)
Date: Mon Oct 18 15:22:00 2004
Subject: FYI: Merge in progress...
Message-ID: <3174569B9743D511922F00A0C94314230665B201@TYANWEB>

It should config.g bug, there is some un consistent.
For dev33 and it sibling
should be .bus = &_dev4.link[2],
instead of 
	.bus = &_dev4.link[0],

struct device _dev4 = {
        .ops = 0,
        .bus = &_dev3.link[0],
        .path = {.type=DEVICE_PATH_PCI,.u={.pci={ .devfn =
PCI_DEVFN(0x18,0)}}},
        .enabled = 1,
        .link = {
                [0] = {
                        .link = 0,
                        .dev = &_dev4,
                        .children = &_dev6,
                },
                [1] = {
                        .link = 1,
                        .dev = &_dev4,
                },
                [2] = {
                        .link = 2,
                        .dev = &_dev4,
                        .children = &_dev33,
                },
        },
        .links = 3,
        .sibling = &_dev37,
        .chip_ops = &northbridge_amd_amdk8_ops,
        .chip_info = &northbridge_amd_amdk8_info_2,
        .next=&_dev6
};

struct device _dev33 = {
        .ops = 0,
        .bus = &_dev4.link[0],
        .path = {.type=DEVICE_PATH_PCI,.u={.pci={ .devfn =
PCI_DEVFN(0x0,0)}}},
        .enabled = 1,
        .link = {
        },
        .links = 0,
        .sibling = &_dev34,
        .next=&_dev34
};
struct device _dev34 = {
        .ops = 0,
        .bus = &_dev4.link[0],
        .path = {.type=DEVICE_PATH_PCI,.u={.pci={ .devfn =
PCI_DEVFN(0x0,1)}}},
        .enabled = 1,
        .link = {
        },
        .links = 0,
        .sibling = &_dev35,
        .next=&_dev35
};
struct device _dev35 = {
        .ops = 0,
        .bus = &_dev4.link[0],
        .path = {.type=DEVICE_PATH_PCI,.u={.pci={ .devfn =
PCI_DEVFN(0x1,0)}}},
        .enabled = 1,
        .link = {
        },
        .links = 0,
        .sibling = &_dev36,
        .next=&_dev36
};
struct device _dev36 = {
        .ops = 0,
        .bus = &_dev4.link[0],
        .path = {.type=DEVICE_PATH_PCI,.u={.pci={ .devfn =
PCI_DEVFN(0x1,1)}}},
        .enabled = 1,
        .link = {
        },
        .links = 0,
        .next=&_dev37
};

-----Original Message-----
From: Ronald G. Minnich [mailto:rminnich at lanl.gov] 
Sent: Monday, October 18, 2004 1:36 PM
To: Li-Ta Lo
Cc: Eric W. Biederman; YhLu; 'LinuxBIOS'
Subject: Re: FYI: Merge in progress...



On Mon, 18 Oct 2004, Li-Ta Lo wrote:
> This is exactly why I was proposing this change. We also got rid of
> a lot of static -> dynamice code.
> 

even cooler: there is no static code structure any more. What the config 
tool creates is a statically allocated set of device structs. The 
enumeration of static to dynamic is gone. 

And so on, and so on, it's a huge improvement.

ron


From rminnich at lanl.gov  Mon Oct 18 15:34:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Oct 18 15:34:01 2004
Subject: FYI: Merge in progress...
In-Reply-To: <3174569B9743D511922F00A0C94314230665B201@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B201@TYANWEB>
Message-ID: <Pine.LNX.4.58.0410181453250.3965@linux.site>


On Mon, 18 Oct 2004, YhLu wrote:

> It should config.g bug, there is some un consistent.
> For dev33 and it sibling
> should be .bus = &_dev4.link[2],

config.g bug. 

Basically when we wrote that code last week we always set to .link[0]. 

So we have to fix it. 

My brain is too tired to try that today, so unless Ollie or Eric does it 
it will have to happen tomorrow. 

Go ahead and commit the various Config.lb files and tell me how to repeat 
the problem so I can see it.

ron


From ollie at lanl.gov  Mon Oct 18 15:53:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Mon Oct 18 15:53:00 2004
Subject: FYI: Merge in progress...
In-Reply-To: <Pine.LNX.4.58.0410181453250.3965@linux.site>
References: <3174569B9743D511922F00A0C94314230665B201@TYANWEB>
	 <Pine.LNX.4.58.0410181453250.3965@linux.site>
Message-ID: <1098134011.3495.47.camel@exponential.lanl.gov>

On Mon, 2004-10-18 at 14:54, Ronald G. Minnich wrote:
> On Mon, 18 Oct 2004, YhLu wrote:
> 
> > It should config.g bug, there is some un consistent.
> > For dev33 and it sibling
> > should be .bus = &_dev4.link[2],
> 
> config.g bug. 
> 
> Basically when we wrote that code last week we always set to .link[0]. 
> 
> So we have to fix it. 
> 
> My brain is too tired to try that today, so unless Ollie or Eric does it 
> it will have to happen tomorrow. 
> 

Sorry, I put all my attention on the usenix paper.

> Go ahead and commit the various Config.lb files and tell me how to repeat 
> the problem so I can see it.
> 

I will try to hack the config.g too once I finish the paper.

Ollie

> ron
> 



From ebiederman at lnxi.com  Mon Oct 18 16:02:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Oct 18 16:02:00 2004
Subject: FYI: Merge in progress...
In-Reply-To: <3174569B9743D511922F00A0C94314230665B201@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B201@TYANWEB>
Message-ID: <m38ya32045.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> It should config.g bug, there is some un consistent.

It could be. I should have fixed this Saturday, but...

Looking Hmm...

> For dev33 and it sibling
> should be .bus = &_dev4.link[2],
> instead of 
> 	.bus = &_dev4.link[0],

Good catch.  We do not yet have the link of the parent device set
properly in the .bus field.  It is always hard coded to 0 :(

Ok the fix looks easy, committed.

Hopefully I have not missed any other cases...

Eric





From YhLu at tyan.com  Mon Oct 18 16:09:00 2004
From: YhLu at tyan.com (YhLu)
Date: Mon Oct 18 16:09:00 2004
Subject: FYI: Merge in progress...
Message-ID: <3174569B9743D511922F00A0C94314230665B220@TYANWEB>

self.firstparentdevicelink()

How about IORESOURCE_FIXED ?

static void pnp_set_resource(device_t dev, struct resource *resource)
{
        if (!(resource->flags & IORESOURCE_ASSIGNED)) {
                printk_err("ERROR: %s %02x not allocated\n",
                        dev_path(dev), resource->index);
                return; 
        }       

-----Original Message-----
From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
Sent: Monday, October 18, 2004 2:22 PM
To: YhLu
Cc: Ronald G. Minnich; Li-Ta Lo; 'LinuxBIOS'
Subject: Re: FYI: Merge in progress...

YhLu <YhLu at tyan.com> writes:

> It should config.g bug, there is some un consistent.

It could be. I should have fixed this Saturday, but...

Looking Hmm...

> For dev33 and it sibling
> should be .bus = &_dev4.link[2],
> instead of 
> 	.bus = &_dev4.link[0],

Good catch.  We do not yet have the link of the parent device set
properly in the .bus field.  It is always hard coded to 0 :(

Ok the fix looks easy, committed.

Hopefully I have not missed any other cases...

Eric




From YhLu at tyan.com  Mon Oct 18 16:25:01 2004
From: YhLu at tyan.com (YhLu)
Date: Mon Oct 18 16:25:01 2004
Subject: FYI: Merge in progress...
Message-ID: <3174569B9743D511922F00A0C94314230665B223@TYANWEB>

There is overlapping between prefmem and mem.

PCI_DOMAIN: 0000 00 <- [0x0000001000 - 0x0000005fff] io
PCI_DOMAIN: 0000 01 <- [0x00f8000000 - 0x01007fffff] prefmem
PCI_DOMAIN: 0000 02 <- [0x00f8000000 - 0x00fe6fffff] mem
PCI: 00:18.0 1c0 <- [0x0000001000 - 0x0000003fff] io <node 0 link 0>
PCI: 00:18.0 1b8 <- [0x0000000000 - 0x000fffffff] prefmem <node 0 link 0>
PCI: 00:18.0 1b0 <- [0x00fc000000 - 0x00fe1fffff] mem <node 0 link 0>
PCI: 00:18.0 1da <- [0x0000004000 - 0x0000004fff] io <node 0 link 2>
PCI: 00:18.0 1aa <- [0x0100800000 - 0x01007fffff] prefmem <node 0 link 2>
PCI: 00:18.0 1a2 <- [0x00fe200000 - 0x00fe4fffff] mem <node 0 link 2>

PCI: 00:18.3 94 <- [0x00f8000000 - 0x00fbffffff] mem <gart>
PCI: 00:19.3 94 <- [0x00f8000000 - 0x00fbffffff] mem <gart>
PCI: 00:19.0 1c8 <- [0x0000005000 - 0x0000005fff] io <node 1 link 0>
PCI: 00:19.0 198 <- [0x00f8000000 - 0x01007fffff] prefmem <node 1 link 0>
PCI: 00:19.0 190 <- [0x00fe500000 - 0x00fe6fffff] mem <node 1 link 0>

-----Original Message-----
From: YhLu 
Sent: Monday, October 18, 2004 2:29 PM
To: 'ebiederman at lnxi.com'
Cc: Ronald G. Minnich; Li-Ta Lo; 'LinuxBIOS'
Subject: RE: FYI: Merge in progress...

self.firstparentdevicelink()

How about IORESOURCE_FIXED ?

static void pnp_set_resource(device_t dev, struct resource *resource)
{
        if (!(resource->flags & IORESOURCE_ASSIGNED)) {
                printk_err("ERROR: %s %02x not allocated\n",
                        dev_path(dev), resource->index);
                return; 
        }       

-----Original Message-----
From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
Sent: Monday, October 18, 2004 2:22 PM
To: YhLu
Cc: Ronald G. Minnich; Li-Ta Lo; 'LinuxBIOS'
Subject: Re: FYI: Merge in progress...

YhLu <YhLu at tyan.com> writes:

> It should config.g bug, there is some un consistent.

It could be. I should have fixed this Saturday, but...

Looking Hmm...

> For dev33 and it sibling
> should be .bus = &_dev4.link[2],
> instead of 
> 	.bus = &_dev4.link[0],

Good catch.  We do not yet have the link of the parent device set
properly in the .bus field.  It is always hard coded to 0 :(

Ok the fix looks easy, committed.

Hopefully I have not missed any other cases...

Eric




From stepan at openbios.org  Mon Oct 18 17:35:01 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Mon Oct 18 17:35:01 2004
Subject: FYI: Merge in progress...
In-Reply-To: <Pine.LNX.4.58.0410181017570.3965@linux.site>
References: <200410161543.i9GFhML07115@nwn.definitive.org> <Pine.LNX.4.58.0410181017570.3965@linux.site>
Message-ID: <20041018225536.GA28241@openbios.org>

* Ronald G. Minnich <rminnich at lanl.gov> [041018 18:19]:
> Yeah, well, how about this: here's how target config files look now:

Really awesome! Now LinuxBIOS is not a step further, but a couple of
big jumps. 

> target hdama
> mainboard arima/hdama
> romimage "normal"
> 	option USE_FALLBACK_IMAGE=0
> 	option ROM_IMAGE_SIZE=0x10000
> 	option LINUXBIOS_EXTRA_VERSION=".0Normal"
> 	payload /usr/share/etherboot/5.2.1eb1-lnxi-lb/tg3--ide_disk.zelf
> end
> romimage "fallback" 
> 	option USE_FALLBACK_IMAGE=1
> 	option ROM_IMAGE_SIZE=0x10000
> 	option LINUXBIOS_EXTRA_VERSION=".0Fallback"
> 	payload /usr/share/etherboot/5.2.1eb1-lnxi-lb/tg3--ide_disk.zelf
> end
> buildrom ./linuxbios.rom ROM_SIZE "normal" "fallback"

With such simple target config files, one could think about an autobuild
kind of thing, checking the status of all LinuxBIOS target builds
nightly. This would put immediate attention on changes that break
something. I hacked down attached little script, which creates output
similar to the following, leaving flashable images for each platform.

[..]
Processing mainboard amd solo (i386: ok)
  Creating config file... ok
  Creating builddir...FAILED!

Processing mainboard arima hdama (i386: ok)
  Creating config file... ok
  Creating builddir...ok
  Compiling image ..FAILED!
[..]
Processing mainboard embeddedplanet ep405pc (ppc: skipped, we're i386)
[..]

I attached a little script to do this. If someone likes it, I would
check it into freebios2/util/abuild and give it a try on base of the
linuxbios snapshots (http://www.linuxbios.org/snapshots/)

Ideas, hints, patches, flames welcome...

Stefan



-------------- next part --------------
A non-text attachment was scrubbed...
Name: abuild.sh
Type: application/x-sh
Size: 3121 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20041018/34107afd/attachment.sh>

From rminnich at lanl.gov  Mon Oct 18 17:47:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Oct 18 17:47:01 2004
Subject: FYI: Merge in progress...
In-Reply-To: <3174569B9743D511922F00A0C94314230665B223@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B223@TYANWEB>
Message-ID: <Pine.LNX.4.58.0410181659220.3965@linux.site>


On Mon, 18 Oct 2004, YhLu wrote:

> There is overlapping between prefmem and mem.

Dr. Lu, we could not ask for a better tester than you!

Thanks for your patience ... I realize we did break things a bit last 
week!

Thanks

ron


From rminnich at lanl.gov  Mon Oct 18 17:49:07 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Oct 18 17:49:07 2004
Subject: FYI: Merge in progress...
In-Reply-To: <20041018225536.GA28241@openbios.org>
References: <200410161543.i9GFhML07115@nwn.definitive.org>
 <Pine.LNX.4.58.0410181017570.3965@linux.site> <20041018225536.GA28241@openbios.org>
Message-ID: <Pine.LNX.4.58.0410181702190.3965@linux.site>

Please check that in Stefan, we have needed something like that for a long 
time. We need to finish up Greg Watson's work on cross compile flags etc. 
so we can do all builds in one place.

ron



From ebiederman at lnxi.com  Mon Oct 18 17:56:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Oct 18 17:56:01 2004
Subject: FYI: Merge in progress...
In-Reply-To: <3174569B9743D511922F00A0C94314230665B220@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B220@TYANWEB>
Message-ID: <m34qkrwray.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> self.firstparentdevicelink()
> 
> How about IORESOURCE_FIXED ?

Good point. I guess I should have looked at chip.c when I was doing 
that part of the conversion.  I have just added IORESOURCE_ASSIGNED to the flags.

I was so happy it booted I forgot to look for error messages :)

I will get the trivial fix for that commited in a moment.

> static void pnp_set_resource(device_t dev, struct resource *resource)
> {
>         if (!(resource->flags & IORESOURCE_ASSIGNED)) {
>                 printk_err("ERROR: %s %02x not allocated\n",
>                         dev_path(dev), resource->index);
>                 return; 
>         }       

Eric


From YhLu at tyan.com  Mon Oct 18 18:04:01 2004
From: YhLu at tyan.com (YhLu)
Date: Mon Oct 18 18:04:01 2004
Subject: FYI: Merge in progress...
Message-ID: <3174569B9743D511922F00A0C94314230665B240@TYANWEB>

The prefmem and mem overlapping is the last problem.
If I using pci-e card, it will overlap the range of io apic, and it will
hang MB.

I just happen to have some multi HT link MB to dig some problem for you.

I will commit change about s288x ....today.

Regards

Yinghai Lu

-----Original Message-----
From: Ronald G. Minnich [mailto:rminnich at lanl.gov] 
Sent: Monday, October 18, 2004 4:00 PM
To: YhLu
Cc: ebiederman at lnxi.com; Li-Ta Lo; 'LinuxBIOS'
Subject: RE: FYI: Merge in progress...



On Mon, 18 Oct 2004, YhLu wrote:

> There is overlapping between prefmem and mem.

Dr. Lu, we could not ask for a better tester than you!

Thanks for your patience ... I realize we did break things a bit last 
week!

Thanks

ron
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From rminnich at lanl.gov  Mon Oct 18 18:07:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Oct 18 18:07:00 2004
Subject: FYI: Merge in progress...
In-Reply-To: <m38ya32045.fsf@maxwell.lnxi.com>
References: <3174569B9743D511922F00A0C94314230665B201@TYANWEB>
 <m38ya32045.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.58.0410181529220.3965@linux.site>


On Mon, 18 Oct 2004, Eric W. Biederman wrote:

> Ok the fix looks easy, committed.

well, eric, you are rewarding my laziness. :-)

ron


From ebiederman at lnxi.com  Mon Oct 18 18:11:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Oct 18 18:11:01 2004
Subject: FYI: Merge in progress...
In-Reply-To: <3174569B9743D511922F00A0C94314230665B223@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B223@TYANWEB>
Message-ID: <m3zn2jvc2i.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> There is overlapping between prefmem and mem.

Ok that is really weird.

Do you have a prefmem resource whose limit is below 4G?

A few small glitches don't surprise me as the 64bit support in
the resources is new, and I am still refining it.  And it should
be suboptimal for multiple HT chains. (Because I am artificially
limiting them in the PCI_DOMAIN).

However.  I don't know of a case that would assign
prefmem and mem the same base address.

In src/northbridge/amd/amdk8/northbridge.c:pci_domain_read_resources

You might try setting the limit to 4G - 1 == 0xffffffff

An lspci -vvv of the failing system would be interesting if you have
BIOS under which it boots.


> PCI_DOMAIN: 0000 00 <- [0x0000001000 - 0x0000005fff] io
> PCI_DOMAIN: 0000 01 <- [0x00f8000000 - 0x01007fffff] prefmem
> PCI_DOMAIN: 0000 02 <- [0x00f8000000 - 0x00fe6fffff] mem
> PCI: 00:18.0 1c0 <- [0x0000001000 - 0x0000003fff] io <node 0 link 0>
> PCI: 00:18.0 1b8 <- [0x0000000000 - 0x000fffffff] prefmem <node 0 link 0>
> PCI: 00:18.0 1b0 <- [0x00fc000000 - 0x00fe1fffff] mem <node 0 link 0>
> PCI: 00:18.0 1da <- [0x0000004000 - 0x0000004fff] io <node 0 link 2>
> PCI: 00:18.0 1aa <- [0x0100800000 - 0x01007fffff] prefmem <node 0 link 2>
> PCI: 00:18.0 1a2 <- [0x00fe200000 - 0x00fe4fffff] mem <node 0 link 2>
> 
> PCI: 00:18.3 94 <- [0x00f8000000 - 0x00fbffffff] mem <gart>
> PCI: 00:19.3 94 <- [0x00f8000000 - 0x00fbffffff] mem <gart>
> PCI: 00:19.0 1c8 <- [0x0000005000 - 0x0000005fff] io <node 1 link 0>
> PCI: 00:19.0 198 <- [0x00f8000000 - 0x01007fffff] prefmem <node 1 link 0>
> PCI: 00:19.0 190 <- [0x00fe500000 - 0x00fe6fffff] mem <node 1 link 0>


For reference on my HDAMA with a mellanox HCA plugged in I am getting:

PCI_DOMAIN: 0000 00 <- [0x0000001000 - 0x0000002fff] io
PCI_DOMAIN: 0000 01 <- [0xfcf0000000 - 0xfcf87fffff] prefmem
PCI_DOMAIN: 0000 02 <- [0x00f8000000 - 0x00fd3fffff] mem
PCI: 00:18.0 1b8 <- [0xfcf0000000 - 0xfcf87fffff] prefmem <node 0 link 0>
PCI: 00:18.0 1c0 <- [0x0000001000 - 0x0000002fff] io <node 0 link 0>
PCI: 00:18.0 1b0 <- [0x00fc000000 - 0x00fd3fffff] mem <node 0 link 0>


Eric


From rsmith at bitworks.com  Mon Oct 18 18:23:00 2004
From: rsmith at bitworks.com (Richard Smith)
Date: Mon Oct 18 18:23:00 2004
Subject: FYI: Merge in progress...
In-Reply-To: <Pine.LNX.4.58.0410181659220.3965@linux.site>
References: <3174569B9743D511922F00A0C94314230665B223@TYANWEB> <Pine.LNX.4.58.0410181659220.3965@linux.site>
Message-ID: <41745527.7090201@bitworks.com>

I've been reading this new v2 stuff with some interest.   I may be able 
to finde time to move the 440bx stuff over into v2.  We've hired a big 
gun PCI guru to help find our problems that have been keeping me from 
getting video to work.

While he's working on that and I'm playing gopher boy, I may be able to 
scratch in some v2 conversion work.  What v2 boards have a working SPD 
implementation?

Whats all this new stuff mean for those of us without these fancy new 
wizbang chipsets and only 1 pci bus?

-- 
Richard A. Smith




From YhLu at tyan.com  Mon Oct 18 18:49:00 2004
From: YhLu at tyan.com (YhLu)
Date: Mon Oct 18 18:49:00 2004
Subject: FYI: Merge in progress...
Message-ID: <3174569B9743D511922F00A0C94314230665B24F@TYANWEB>

I'm using Mallanox PCI-E HCA.

YH

-----Original Message-----
From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
Sent: Monday, October 18, 2004 4:31 PM
To: YhLu
Cc: Ronald G. Minnich; Li-Ta Lo; 'LinuxBIOS'
Subject: Re: FYI: Merge in progress...

YhLu <YhLu at tyan.com> writes:

> There is overlapping between prefmem and mem.

Ok that is really weird.

Do you have a prefmem resource whose limit is below 4G?

A few small glitches don't surprise me as the 64bit support in
the resources is new, and I am still refining it.  And it should
be suboptimal for multiple HT chains. (Because I am artificially
limiting them in the PCI_DOMAIN).

However.  I don't know of a case that would assign
prefmem and mem the same base address.

In src/northbridge/amd/amdk8/northbridge.c:pci_domain_read_resources

You might try setting the limit to 4G - 1 == 0xffffffff

An lspci -vvv of the failing system would be interesting if you have
BIOS under which it boots.


> PCI_DOMAIN: 0000 00 <- [0x0000001000 - 0x0000005fff] io
> PCI_DOMAIN: 0000 01 <- [0x00f8000000 - 0x01007fffff] prefmem
> PCI_DOMAIN: 0000 02 <- [0x00f8000000 - 0x00fe6fffff] mem
> PCI: 00:18.0 1c0 <- [0x0000001000 - 0x0000003fff] io <node 0 link 0>
> PCI: 00:18.0 1b8 <- [0x0000000000 - 0x000fffffff] prefmem <node 0 link 0>
> PCI: 00:18.0 1b0 <- [0x00fc000000 - 0x00fe1fffff] mem <node 0 link 0>
> PCI: 00:18.0 1da <- [0x0000004000 - 0x0000004fff] io <node 0 link 2>
> PCI: 00:18.0 1aa <- [0x0100800000 - 0x01007fffff] prefmem <node 0 link 2>
> PCI: 00:18.0 1a2 <- [0x00fe200000 - 0x00fe4fffff] mem <node 0 link 2>
> 
> PCI: 00:18.3 94 <- [0x00f8000000 - 0x00fbffffff] mem <gart>
> PCI: 00:19.3 94 <- [0x00f8000000 - 0x00fbffffff] mem <gart>
> PCI: 00:19.0 1c8 <- [0x0000005000 - 0x0000005fff] io <node 1 link 0>
> PCI: 00:19.0 198 <- [0x00f8000000 - 0x01007fffff] prefmem <node 1 link 0>
> PCI: 00:19.0 190 <- [0x00fe500000 - 0x00fe6fffff] mem <node 1 link 0>


For reference on my HDAMA with a mellanox HCA plugged in I am getting:

PCI_DOMAIN: 0000 00 <- [0x0000001000 - 0x0000002fff] io
PCI_DOMAIN: 0000 01 <- [0xfcf0000000 - 0xfcf87fffff] prefmem
PCI_DOMAIN: 0000 02 <- [0x00f8000000 - 0x00fd3fffff] mem
PCI: 00:18.0 1b8 <- [0xfcf0000000 - 0xfcf87fffff] prefmem <node 0 link 0>
PCI: 00:18.0 1c0 <- [0x0000001000 - 0x0000002fff] io <node 0 link 0>
PCI: 00:18.0 1b0 <- [0x00fc000000 - 0x00fd3fffff] mem <node 0 link 0>


Eric


From ebiederman at lnxi.com  Mon Oct 18 19:46:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Oct 18 19:46:01 2004
Subject: FYI: Merge in progress...
In-Reply-To: <41745527.7090201@bitworks.com>
References: <3174569B9743D511922F00A0C94314230665B223@TYANWEB>
	<Pine.LNX.4.58.0410181659220.3965@linux.site>
	<41745527.7090201@bitworks.com>
Message-ID: <m31xfvtt3h.fsf@maxwell.lnxi.com>

Richard Smith <rsmith at bitworks.com> writes:

> I've been reading this new v2 stuff with some interest.  I may be able to finde
> 
> time to move the 440bx stuff over into v2.  We've hired a big gun PCI guru to
> help find our problems that have been keeping me from getting video to work.
> 
> While he's working on that and I'm playing gopher boy, I may be able to scratch
> in some v2 conversion work.  What v2 boards have a working SPD implementation?

I think everything except the epia. I wish I could point you at a simple port.
 
> Whats all this new stuff mean for those of us without these fancy new wizbang
> chipsets and only 1 pci bus?

Possibly an extra nesting level in Config.lb.  If you have a PCI slot
you can still have multiple busses.

Hmm. I suspect your configuration would look something like:

Except that some of the unused parts don't compile out it really
should be fairly simple.

chip northbridge/intel/440bx 
        device pci_domain 0 on 
                device pci 0.0 on end  # memory controller
                device pci 0.1 on end  # PCI-PCI bridge?
                chip southbridge/intel/piix4e
                        device pci 12.0 on end # ISA bridge
                        device pci 12.1 on end # IDE controller
                        device pci 12.2 on end # USB host controller
                        device pci 12.3 on end # Power management registers
                end
        end
        device apic_cluster 0 on
                chip cpu/intel/slot_2
                     device apic 0 on end
                end
        end
end

Eric


From ebiederman at lnxi.com  Mon Oct 18 20:01:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Oct 18 20:01:00 2004
Subject: FYI: Merge in progress...
In-Reply-To: <Pine.LNX.4.58.0410181529220.3965@linux.site>
References: <3174569B9743D511922F00A0C94314230665B201@TYANWEB>
	<m38ya32045.fsf@maxwell.lnxi.com>
	<Pine.LNX.4.58.0410181529220.3965@linux.site>
Message-ID: <m3ekjvpko5.fsf@maxwell.lnxi.com>

"Ronald G. Minnich" <rminnich at lanl.gov> writes:

> On Mon, 18 Oct 2004, Eric W. Biederman wrote:
> 
> > Ok the fix looks easy, committed.
> 
> well, eric, you are rewarding my laziness. :-)

Then this would be a bad time to mention Thayne looked at the supermon
kernel code and ran away screaming?

Eric


From rsmith at bitworks.com  Mon Oct 18 20:05:01 2004
From: rsmith at bitworks.com (Richard Smith)
Date: Mon Oct 18 20:05:01 2004
Subject: FYI: Merge in progress...
In-Reply-To: <m31xfvtt3h.fsf@maxwell.lnxi.com>
References: <3174569B9743D511922F00A0C94314230665B223@TYANWEB>	<Pine.LNX.4.58.0410181659220.3965@linux.site>	<41745527.7090201@bitworks.com> <m31xfvtt3h.fsf@maxwell.lnxi.com>
Message-ID: <41746CEB.5020802@bitworks.com>

Eric W. Biederman wrote:

> Hmm. I suspect your configuration would look something like:
> 

> chip northbridge/intel/440bx 
>         device pci_domain 0 on 

Ok so I guess I'll start asking questions.  "pci_domain"  this is the 
top level I guess?  Where are all the different device types listed at?

The use of "on" this is on as in on/off and not "this item is on this item"

Is the order of the config file related to the order of the init 
sequence the code generates?

>         device apic_cluster 0 on
>                 chip cpu/intel/slot_2
>                      device apic 0 on end
>                 end
>         end
> end

So after I fix up this example to match our board where would my board 
specific code go?  Is there still a mainboard.c? I've got things that 
disable the secondary IDE controller and a few other specials.

-- 
Richard A. Smith




From YhLu at tyan.com  Mon Oct 18 20:08:00 2004
From: YhLu at tyan.com (YhLu)
Date: Mon Oct 18 20:08:00 2004
Subject: FYI: Merge in progress...
Message-ID: <3174569B9743D511922F00A0C94314230665B266@TYANWEB>

The pci_device is using PCI 64, how to disable it and let it use 32 bit
premem?

Regards

YH

-----Original Message-----
From: YhLu 
Sent: Monday, October 18, 2004 5:14 PM
To: ebiederman at lnxi.com
Cc: Ronald G. Minnich; Li-Ta Lo; 'LinuxBIOS'
Subject: RE: FYI: Merge in progress...

I'm using Mallanox PCI-E HCA.

YH

-----Original Message-----
From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
Sent: Monday, October 18, 2004 4:31 PM
To: YhLu
Cc: Ronald G. Minnich; Li-Ta Lo; 'LinuxBIOS'
Subject: Re: FYI: Merge in progress...

YhLu <YhLu at tyan.com> writes:

> There is overlapping between prefmem and mem.

Ok that is really weird.

Do you have a prefmem resource whose limit is below 4G?

A few small glitches don't surprise me as the 64bit support in
the resources is new, and I am still refining it.  And it should
be suboptimal for multiple HT chains. (Because I am artificially
limiting them in the PCI_DOMAIN).

However.  I don't know of a case that would assign
prefmem and mem the same base address.

In src/northbridge/amd/amdk8/northbridge.c:pci_domain_read_resources

You might try setting the limit to 4G - 1 == 0xffffffff

An lspci -vvv of the failing system would be interesting if you have
BIOS under which it boots.


> PCI_DOMAIN: 0000 00 <- [0x0000001000 - 0x0000005fff] io
> PCI_DOMAIN: 0000 01 <- [0x00f8000000 - 0x01007fffff] prefmem
> PCI_DOMAIN: 0000 02 <- [0x00f8000000 - 0x00fe6fffff] mem
> PCI: 00:18.0 1c0 <- [0x0000001000 - 0x0000003fff] io <node 0 link 0>
> PCI: 00:18.0 1b8 <- [0x0000000000 - 0x000fffffff] prefmem <node 0 link 0>
> PCI: 00:18.0 1b0 <- [0x00fc000000 - 0x00fe1fffff] mem <node 0 link 0>
> PCI: 00:18.0 1da <- [0x0000004000 - 0x0000004fff] io <node 0 link 2>
> PCI: 00:18.0 1aa <- [0x0100800000 - 0x01007fffff] prefmem <node 0 link 2>
> PCI: 00:18.0 1a2 <- [0x00fe200000 - 0x00fe4fffff] mem <node 0 link 2>
> 
> PCI: 00:18.3 94 <- [0x00f8000000 - 0x00fbffffff] mem <gart>
> PCI: 00:19.3 94 <- [0x00f8000000 - 0x00fbffffff] mem <gart>
> PCI: 00:19.0 1c8 <- [0x0000005000 - 0x0000005fff] io <node 1 link 0>
> PCI: 00:19.0 198 <- [0x00f8000000 - 0x01007fffff] prefmem <node 1 link 0>
> PCI: 00:19.0 190 <- [0x00fe500000 - 0x00fe6fffff] mem <node 1 link 0>


For reference on my HDAMA with a mellanox HCA plugged in I am getting:

PCI_DOMAIN: 0000 00 <- [0x0000001000 - 0x0000002fff] io
PCI_DOMAIN: 0000 01 <- [0xfcf0000000 - 0xfcf87fffff] prefmem
PCI_DOMAIN: 0000 02 <- [0x00f8000000 - 0x00fd3fffff] mem
PCI: 00:18.0 1b8 <- [0xfcf0000000 - 0xfcf87fffff] prefmem <node 0 link 0>
PCI: 00:18.0 1c0 <- [0x0000001000 - 0x0000002fff] io <node 0 link 0>
PCI: 00:18.0 1b0 <- [0x00fc000000 - 0x00fd3fffff] mem <node 0 link 0>


Eric
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From ebiederman at lnxi.com  Mon Oct 18 20:44:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Oct 18 20:44:00 2004
Subject: FYI: Merge in progress...
In-Reply-To: <3174569B9743D511922F00A0C94314230665B266@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B266@TYANWEB>
Message-ID: <m3r7nvlazy.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> The pci_device is using PCI 64, how to disable it and let it use 32 bit
> premem?

I still need to make it an option so we can boot 32bit kernels.

All you should need to do is to set the resource limits to 4G.
See below for the function to modify to set it.

The pci_domain resources that you are seeing current make no sense to me.

Eric 

> > There is overlapping between prefmem and mem.
> 
> Ok that is really weird.
> 
> Do you have a prefmem resource whose limit is below 4G?
> 
> A few small glitches don't surprise me as the 64bit support in
> the resources is new, and I am still refining it.  And it should
> be suboptimal for multiple HT chains. (Because I am artificially
> limiting them in the PCI_DOMAIN).
> 
> However.  I don't know of a case that would assign
> prefmem and mem the same base address.
> 
> In src/northbridge/amd/amdk8/northbridge.c:pci_domain_read_resources
> 
> You might try setting the limit to 4G - 1 == 0xffffffff
> 
> An lspci -vvv of the failing system would be interesting if you have
> BIOS under which it boots.
> 
> 
> > PCI_DOMAIN: 0000 00 <- [0x0000001000 - 0x0000005fff] io
> > PCI_DOMAIN: 0000 01 <- [0x00f8000000 - 0x01007fffff] prefmem
> > PCI_DOMAIN: 0000 02 <- [0x00f8000000 - 0x00fe6fffff] mem
> > PCI: 00:18.0 1c0 <- [0x0000001000 - 0x0000003fff] io <node 0 link 0>
> > PCI: 00:18.0 1b8 <- [0x0000000000 - 0x000fffffff] prefmem <node 0 link 0>
> > PCI: 00:18.0 1b0 <- [0x00fc000000 - 0x00fe1fffff] mem <node 0 link 0>
> > PCI: 00:18.0 1da <- [0x0000004000 - 0x0000004fff] io <node 0 link 2>
> > PCI: 00:18.0 1aa <- [0x0100800000 - 0x01007fffff] prefmem <node 0 link 2>
> > PCI: 00:18.0 1a2 <- [0x00fe200000 - 0x00fe4fffff] mem <node 0 link 2>
> > 
> > PCI: 00:18.3 94 <- [0x00f8000000 - 0x00fbffffff] mem <gart>
> > PCI: 00:19.3 94 <- [0x00f8000000 - 0x00fbffffff] mem <gart>
> > PCI: 00:19.0 1c8 <- [0x0000005000 - 0x0000005fff] io <node 1 link 0>
> > PCI: 00:19.0 198 <- [0x00f8000000 - 0x01007fffff] prefmem <node 1 link 0>
> > PCI: 00:19.0 190 <- [0x00fe500000 - 0x00fe6fffff] mem <node 1 link 0>
> 
> 
> For reference on my HDAMA with a mellanox HCA plugged in I am getting:
> 
> PCI_DOMAIN: 0000 00 <- [0x0000001000 - 0x0000002fff] io
> PCI_DOMAIN: 0000 01 <- [0xfcf0000000 - 0xfcf87fffff] prefmem
> PCI_DOMAIN: 0000 02 <- [0x00f8000000 - 0x00fd3fffff] mem
> PCI: 00:18.0 1b8 <- [0xfcf0000000 - 0xfcf87fffff] prefmem <node 0 link 0>
> PCI: 00:18.0 1c0 <- [0x0000001000 - 0x0000002fff] io <node 0 link 0>
> PCI: 00:18.0 1b0 <- [0x00fc000000 - 0x00fd3fffff] mem <node 0 link 0>
> 
> 
> Eric
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios


From YhLu at tyan.com  Mon Oct 18 21:12:01 2004
From: YhLu at tyan.com (YhLu)
Date: Mon Oct 18 21:12:01 2004
Subject: FYI: Merge in progress...
Message-ID: <3174569B9743D511922F00A0C94314230665B280@TYANWEB>

Get more worse.

-----Original Message-----
From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
Sent: Monday, October 18, 2004 7:04 PM
To: YhLu
Cc: Ronald G. Minnich; Li-Ta Lo; 'LinuxBIOS'
Subject: Re: FYI: Merge in progress...

YhLu <YhLu at tyan.com> writes:

> The pci_device is using PCI 64, how to disable it and let it use 32 bit
> premem?

I still need to make it an option so we can boot 32bit kernels.

All you should need to do is to set the resource limits to 4G.
See below for the function to modify to set it.

The pci_domain resources that you are seeing current make no sense to me.

Eric 

> > There is overlapping between prefmem and mem.
> 
> Ok that is really weird.
> 
> Do you have a prefmem resource whose limit is below 4G?
> 
> A few small glitches don't surprise me as the 64bit support in
> the resources is new, and I am still refining it.  And it should
> be suboptimal for multiple HT chains. (Because I am artificially
> limiting them in the PCI_DOMAIN).
> 
> However.  I don't know of a case that would assign
> prefmem and mem the same base address.
> 
> In src/northbridge/amd/amdk8/northbridge.c:pci_domain_read_resources
> 
> You might try setting the limit to 4G - 1 == 0xffffffff
> 
> An lspci -vvv of the failing system would be interesting if you have
> BIOS under which it boots.
> 
> 
> > PCI_DOMAIN: 0000 00 <- [0x0000001000 - 0x0000005fff] io
> > PCI_DOMAIN: 0000 01 <- [0x00f8000000 - 0x01007fffff] prefmem
> > PCI_DOMAIN: 0000 02 <- [0x00f8000000 - 0x00fe6fffff] mem
> > PCI: 00:18.0 1c0 <- [0x0000001000 - 0x0000003fff] io <node 0 link 0>
> > PCI: 00:18.0 1b8 <- [0x0000000000 - 0x000fffffff] prefmem <node 0 link
0>
> > PCI: 00:18.0 1b0 <- [0x00fc000000 - 0x00fe1fffff] mem <node 0 link 0>
> > PCI: 00:18.0 1da <- [0x0000004000 - 0x0000004fff] io <node 0 link 2>
> > PCI: 00:18.0 1aa <- [0x0100800000 - 0x01007fffff] prefmem <node 0 link
2>
> > PCI: 00:18.0 1a2 <- [0x00fe200000 - 0x00fe4fffff] mem <node 0 link 2>
> > 
> > PCI: 00:18.3 94 <- [0x00f8000000 - 0x00fbffffff] mem <gart>
> > PCI: 00:19.3 94 <- [0x00f8000000 - 0x00fbffffff] mem <gart>
> > PCI: 00:19.0 1c8 <- [0x0000005000 - 0x0000005fff] io <node 1 link 0>
> > PCI: 00:19.0 198 <- [0x00f8000000 - 0x01007fffff] prefmem <node 1 link
0>
> > PCI: 00:19.0 190 <- [0x00fe500000 - 0x00fe6fffff] mem <node 1 link 0>
> 
> 
> For reference on my HDAMA with a mellanox HCA plugged in I am getting:
> 
> PCI_DOMAIN: 0000 00 <- [0x0000001000 - 0x0000002fff] io
> PCI_DOMAIN: 0000 01 <- [0xfcf0000000 - 0xfcf87fffff] prefmem
> PCI_DOMAIN: 0000 02 <- [0x00f8000000 - 0x00fd3fffff] mem
> PCI: 00:18.0 1b8 <- [0xfcf0000000 - 0xfcf87fffff] prefmem <node 0 link 0>
> PCI: 00:18.0 1c0 <- [0x0000001000 - 0x0000002fff] io <node 0 link 0>
> PCI: 00:18.0 1b0 <- [0x00fc000000 - 0x00fd3fffff] mem <node 0 link 0>
> 
> 
> Eric
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios


From ebiederman at lnxi.com  Mon Oct 18 21:21:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Oct 18 21:21:00 2004
Subject: FYI: Merge in progress...
In-Reply-To: <41746CEB.5020802@bitworks.com>
References: <3174569B9743D511922F00A0C94314230665B223@TYANWEB>
	<Pine.LNX.4.58.0410181659220.3965@linux.site>
	<41745527.7090201@bitworks.com> <m31xfvtt3h.fsf@maxwell.lnxi.com>
	<41746CEB.5020802@bitworks.com>
Message-ID: <m3mzyjl99r.fsf@maxwell.lnxi.com>

Richard Smith <rsmith at bitworks.com> writes:

> Eric W. Biederman wrote:
> 
> > Hmm. I suspect your configuration would look something like:
> >
> 
> > chip northbridge/intel/440bx         device pci_domain 0 on
> 
> Ok so I guess I'll start asking questions.  "pci_domain"  this is the top level
> I guess?  Where are all the different device types listed at?

src/include/device/path.h

> The use of "on" this is on as in on/off and not "this item is on this item"

Correct.  It is there so we do things like disable unused integrated hardware.
 
> Is the order of the config file related to the order of the init sequence the
> code generates?

Roughly. Yes.  

The compile time information is merged with what can be found dynamically.
The resources are allocated (much like v1 pci devices) but the methods
can be overridden.

Then the init methods of all of the devices are called.

 
> >         device apic_cluster 0 on
> >                 chip cpu/intel/slot_2
> >                      device apic 0 on end
> >                 end
> >         end
> > end
> 
> So after I fix up this example to match our board where would my board specific
> code go?  Is there still a mainboard.c? I've got things that disable the
> secondary IDE controller and a few other specials.

Yes, but we try to avoid 

Basically the code is inside out from the v1 tree.  That makes the
code a little harder to follow but a lot easier to reuse.

I am stunned that the ide interface enable/disable thing has not come up,
before.  That looks something we have just glossed over.  To many other
glitches I guess.

I am trying to think of a clean way to handle it so the ide enable/disable
can be set in the configuration file.

I can see two possible ways and I will list an example of both:
Either we add and ide_socket path and only enable IDE controllers
who have an attached socket, or we add a chip specific configuration option.

chip southbridge/intel/piix4e
        device pci 12.0 on end # ISA bridge
        device pci 12.1 on 
                device ide_socket on end
	end # IDE controller
        device pci 12.1 on end # IDE controller
        device pci 12.2 on end # USB host controller
        device pci 12.3 on end # Power management registers

        register enable_ide_0 = "1"
        register enable_ide_1 = "0"
end

We can still run mainboard specific code in the appropriate init method.
Note however that will be the first init method run.  In general it is assumed
that the order of init methods does not matter, so the just get run in
the order the devices were discovered.

Eric





From ebiederman at lnxi.com  Mon Oct 18 21:33:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Oct 18 21:33:01 2004
Subject: FYI: Merge in progress...
In-Reply-To: <3174569B9743D511922F00A0C94314230665B280@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B280@TYANWEB>
Message-ID: <m3zn2jh100.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> Get more worse.

Ouch.  If you can boot the board in linux please give me an lspci -vvv

I don't have enough information to even guess what is going on.
I need to know what the size and limit of the resources are,
so I can walk through the code and see what it would do.

At the moment I can't even begin to guess what is going wrong.

The obvious problem of doubly allocating a base register does
not appear to apply.  I am using the standard compute_allocate_resource
function which should traverse the bus and do the right thing.

Unless my rewrite of the limit calculation code is causing a problem.

I just don't know where to look.

Eric


From liutao at safe-mail.net  Mon Oct 18 22:51:00 2004
From: liutao at safe-mail.net (Liu Tao)
Date: Mon Oct 18 22:51:00 2004
Subject: PCI IRQ tables
In-Reply-To: <3174569B9743D511922F00A0C94314230665B1B0@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B1B0@TYANWEB>
Message-ID: <41749442.8040402@safe-mail.net>

Hello,

Thanks for your answer:)
But I'm still not very clear of the PCI interrupt
routing for legacy PIC mode on AMD64. For example in
s2885 mainboard the pirq table specifys the AMD8111
as the interrupt router (bus1 dev4 fn3), then how
does the interrupt from the PCIX devices on AMD8131
routed to CPU?

Or does the interrupt router in pirq table only
responses of legacy 32bitPCI/ISA devices, and Linux
handles all the AMD8131?

Another question is, if use IO-APIC, does linuxbios
specify the bus/devfn in mptable and let linux
do the real job of setting the IO-APIC registers?

Best Regards,
Liu Tao

YhLu wrote:

 >It's the same if you enable io apic.
 >
 >In the irq-table.
 >
 >Add
 >Entry Bus 1 for 8111 and 8131
 >Other 8131 bus may be discovered by Kernel.
 >


From stepan at openbios.org  Tue Oct 19 09:59:00 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Tue Oct 19 09:59:00 2004
Subject: LinuxBIOS snapshots
Message-ID: <20041019151950.GA8118@openbios.org>

Hi,

http://snapshots.linuxbios.org/ has been updated a bit. 
I hope it is more usable now...

 * New snapshots are only generated, if something changed in CVS
 * The snapshot script now generates a diff to the last snapshot.
 * Snapshot directories have a timestamp now.
 * old snapshots are not deleted automatically anymore (since there
   are not 48 new ones every day)

Comments, wishes, ideas welcome.

Stefan



From rminnich at lanl.gov  Tue Oct 19 10:06:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Tue Oct 19 10:06:01 2004
Subject: FYI: Merge in progress...
In-Reply-To: <41745527.7090201@bitworks.com>
References: <3174569B9743D511922F00A0C94314230665B223@TYANWEB>
 <Pine.LNX.4.58.0410181659220.3965@linux.site> <41745527.7090201@bitworks.com>
Message-ID: <Pine.LNX.4.58.0410190924250.6863@linux.site>


On Mon, 18 Oct 2004, Richard Smith wrote:

> I've been reading this new v2 stuff with some interest.   I may be able to
> finde time to move the 440bx stuff over into v2.  We've hired a big gun PCI
> guru to help find our problems that have been keeping me from getting video to
> work.

excellent!


> While he's working on that and I'm playing gopher boy, I may be able to
> scratch in some v2 conversion work.  What v2 boards have a working SPD
> implementation?

Try the port for the digitallogic adl855pc or whatever it is. modulo 
Intel's unwillingness to tell us how the chips actually work I think the 
structure is close to right. 

The Arima HDAMA is still the gold standard, but it is really way more 
complex than a simple 440bx system. That's why I like the digitallogic 
port better as an example.

ron


From rsmith at bitworks.com  Tue Oct 19 10:22:01 2004
From: rsmith at bitworks.com (Richard Smith)
Date: Tue Oct 19 10:22:01 2004
Subject: FYI: Merge in progress...
In-Reply-To: <Pine.LNX.4.58.0410190924250.6863@linux.site>
References: <3174569B9743D511922F00A0C94314230665B223@TYANWEB> <Pine.LNX.4.58.0410181659220.3965@linux.site> <41745527.7090201@bitworks.com> <Pine.LNX.4.58.0410190924250.6863@linux.site>
Message-ID: <417535FC.1040004@bitworks.com>

Ronald G. Minnich wrote:

> 
> Try the port for the digitallogic adl855pc or whatever it is. modulo 
> Intel's unwillingness to tell us how the chips actually work I think the 
> structure is close to right. 
> 
> The Arima HDAMA is still the gold standard, but it is really way more 
> complex than a simple 440bx system. That's why I like the digitallogic 
> port better as an example.

I've been going over the various ports trying to get a feel for whats 
needed.  What I think I may do is take a stab at creating a generic 
port.  Some fictious motherboard that has the minimum structure 
necessary as a search and replace starting point.  Does that sound 
useful?   If so what should I name it?


-- 
Richard A. Smith




From rminnich at lanl.gov  Tue Oct 19 10:35:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Tue Oct 19 10:35:01 2004
Subject: FYI: Merge in progress...
In-Reply-To: <417535FC.1040004@bitworks.com>
References: <3174569B9743D511922F00A0C94314230665B223@TYANWEB>
 <Pine.LNX.4.58.0410181659220.3965@linux.site> <41745527.7090201@bitworks.com>
 <Pine.LNX.4.58.0410190924250.6863@linux.site> <417535FC.1040004@bitworks.com>
Message-ID: <Pine.LNX.4.58.0410190955260.6863@linux.site>


On Tue, 19 Oct 2004, Richard Smith wrote:

> I've been going over the various ports trying to get a feel for whats needed.
> What I think I may do is take a stab at creating a generic port.  Some
> fictious motherboard that has the minimum structure necessary as a search and
> replace starting point.  Does that sound useful?   If so what should I name
> it?

I'm not sure it's less work than a full one, although you could set up 
'user mode linuxbios' for educational purposes.

ron


From rsmith at bitworks.com  Tue Oct 19 11:10:01 2004
From: rsmith at bitworks.com (Richard Smith)
Date: Tue Oct 19 11:10:01 2004
Subject: FYI: Merge in progress...
In-Reply-To: <Pine.LNX.4.58.0410190955260.6863@linux.site>
References: <3174569B9743D511922F00A0C94314230665B223@TYANWEB> <Pine.LNX.4.58.0410181659220.3965@linux.site> <41745527.7090201@bitworks.com> <Pine.LNX.4.58.0410190924250.6863@linux.site> <417535FC.1040004@bitworks.com> <Pine.LNX.4.58.0410190955260.6863@linux.site>
Message-ID: <4175411A.9090204@bitworks.com>

Ronald G. Minnich wrote:

>>replace starting point.  Does that sound useful?   If so what should I name
>>it?
>  
> I'm not sure it's less work than a full one, although you could set up 
> 'user mode linuxbios' for educational purposes.

I'm not doing it because its less work. *grin*

I'm thinking about those who come after me.  With the purpose of 
creating a well documented starting structure at the same time teaching 
me how v2 goes together.

Then next guy then has a clean starting point and dosen't have to wade 
through the same stuff.

-- 
Richard A. Smith




From linuxbios at mikebell.org  Tue Oct 19 11:55:00 2004
From: linuxbios at mikebell.org (linuxbios at mikebell.org)
Date: Tue Oct 19 11:55:00 2004
Subject: PCI IRQ tables
In-Reply-To: <41749442.8040402@safe-mail.net>
References: <3174569B9743D511922F00A0C94314230665B1B0@TYANWEB> <41749442.8040402@safe-mail.net>
Message-ID: <20041019171642.GA1397@tinyvaio.nome.ca>

On Tue, Oct 19, 2004 at 12:12:50PM +0800, Liu Tao wrote:
> Or does the interrupt router in pirq table only
> responses of legacy 32bitPCI/ISA devices, and Linux
> handles all the AMD8131?

Forgive my ignorance, but doesn't the fact that PCI-X is all message
signaled interrupts obviate the need for a PCIIRQ table?


From adam at cfar.umd.edu  Tue Oct 19 12:03:01 2004
From: adam at cfar.umd.edu (Adam Sulmicki)
Date: Tue Oct 19 12:03:01 2004
Subject: FYI: Merge in progress...
In-Reply-To: <417535FC.1040004@bitworks.com>
Message-ID: <20041019132737.B32141-100000@www.missl.cs.umd.edu>

On Tue, 19 Oct 2004, Richard Smith wrote:

> I've been going over the various ports trying to get a feel for whats
> needed.  What I think I may do is take a stab at creating a generic
> port.  Some fictious motherboard that has the minimum structure
> necessary as a search and replace starting point.  Does that sound
> useful?   If so what should I name it?

it has a name. the name is bochs.

more seriously if we could do it one way and move bochs bios to real
hardware, we could go other way and move LB to bochs hardware (which is
something like intel 440BX IIRC).




From daubin at actuality-systems.com  Tue Oct 19 12:07:01 2004
From: daubin at actuality-systems.com (Dave Aubin)
Date: Tue Oct 19 12:07:01 2004
Subject: PCI IRQ tables
Message-ID: <E8F8DBCB0468204E856114A2CD20741F2C1A0A@mail.local.ActualitySystems.com>

Don't I wish!  PCI-X is dangled off of the 8131?  I think....
My memory is bad.  But one needs to configure the pci irq
Before getting to the pci-x in order to see it show up 
Correctly under linux by lspci.  Then I believe your 
Messages can be handled via the virtual signaled interrupts.

-----Original Message-----
From: linuxbios at mikebell.org [mailto:linuxbios at mikebell.org] 
Sent: Tuesday, October 19, 2004 1:17 PM
To: Liu Tao
Cc: YhLu; Dave Aubin; linuxbios at clustermatic.org
Subject: Re: PCI IRQ tables

On Tue, Oct 19, 2004 at 12:12:50PM +0800, Liu Tao wrote:
> Or does the interrupt router in pirq table only responses of legacy 
> 32bitPCI/ISA devices, and Linux handles all the AMD8131?

Forgive my ignorance, but doesn't the fact that PCI-X is all message
signaled interrupts obviate the need for a PCIIRQ table?


From yhlu at tyan.com  Tue Oct 19 12:09:14 2004
From: yhlu at tyan.com (Yinghai Lu)
Date: Tue Oct 19 12:09:14 2004
Subject: PCI IRQ tables
In-Reply-To: <41749442.8040402@safe-mail.net>
Message-ID: <200410191606.i9JG6kL29490@nwn.definitive.org>

To use PIC in you configuration, you need program 8111 0x56 about int
routing

                        /* initialize PCI interupts - these assignments
depend
                        on the PCB routing of PINTA-D 

                        PINTA = IRQ5
                        PINTB = IRQ9
                        PINTC = IRQ11
                        PINTD = IRQ10
                        */
                        pci_write_config16(dev, 0x56, 0xab95);

Then you need to program  all device in PCI-X slot with
        printk_info("setting Slot 2\n");
        static const unsigned char slotIrqs_8131_2_1[4] = { 9, 11, 10, 5 };
        pci_assign_irqs(bus_8131_2, 1, slotIrqs_8131_2_1);
that will update the interrupt line for every device in slot.

Please remember you need to make sure your HW connection about INT.

Then you can use NO SMP Kernel with apic disabled.

Regards

YH

-----Original Message-----
From: Liu Tao [mailto:liutao at safe-mail.net] 
Sent: Monday, October 18, 2004 9:13 PM
To: YhLu
Cc: Dave Aubin; linuxbios at clustermatic.org
Subject: Re: PCI IRQ tables

Hello,

Thanks for your answer:)
But I'm still not very clear of the PCI interrupt
routing for legacy PIC mode on AMD64. For example in
s2885 mainboard the pirq table specifys the AMD8111
as the interrupt router (bus1 dev4 fn3), then how
does the interrupt from the PCIX devices on AMD8131
routed to CPU?

Or does the interrupt router in pirq table only
responses of legacy 32bitPCI/ISA devices, and Linux
handles all the AMD8131?

Another question is, if use IO-APIC, does linuxbios
specify the bus/devfn in mptable and let linux
do the real job of setting the IO-APIC registers?

Best Regards,
Liu Tao

YhLu wrote:

 >It's the same if you enable io apic.
 >
 >In the irq-table.
 >
 >Add
 >Entry Bus 1 for 8111 and 8131
 >Other 8131 bus may be discovered by Kernel.
 >



From stepan at openbios.org  Tue Oct 19 12:12:00 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Tue Oct 19 12:12:00 2004
Subject: FYI: Merge in progress...
In-Reply-To: <Pine.LNX.4.58.0410190955260.6863@linux.site>
References: <3174569B9743D511922F00A0C94314230665B223@TYANWEB> <Pine.LNX.4.58.0410181659220.3965@linux.site> <41745527.7090201@bitworks.com> <Pine.LNX.4.58.0410190924250.6863@linux.site> <417535FC.1040004@bitworks.com> <Pine.LNX.4.58.0410190955260.6863@linux.site>
Message-ID: <20041019172831.GA10145@openbios.org>

* Ronald G. Minnich <rminnich at lanl.gov> [041019 17:55]:
> > I've been going over the various ports trying to get a feel for
> > whats needed.  What I think I may do is take a stab at creating a
> > generic port.  Some fictious motherboard that has the minimum
> > structure necessary as a search and replace starting point.  Does
> > that sound useful?   If so what should I name it?
> 
> I'm not sure it's less work than a full one, although you could set up 
> 'user mode linuxbios' for educational purposes.
 
Wait!! That is already there... Have a look at the emulation/qemu-i386
motherboard before you start anything new! I did that a while ago, but 
it could use some work (the PCI resource allocation vanished when I
dropped around the time I dropped the normal image to get more space for
my payload)

Stefan



From stepan at openbios.org  Tue Oct 19 12:16:48 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Tue Oct 19 12:16:48 2004
Subject: FYI: Merge in progress...
In-Reply-To: <4175411A.9090204@bitworks.com>
References: <3174569B9743D511922F00A0C94314230665B223@TYANWEB> <Pine.LNX.4.58.0410181659220.3965@linux.site> <41745527.7090201@bitworks.com> <Pine.LNX.4.58.0410190924250.6863@linux.site> <417535FC.1040004@bitworks.com> <Pine.LNX.4.58.0410190955260.6863@linux.site> <4175411A.9090204@bitworks.com>
Message-ID: <20041019173049.GB10145@openbios.org>

* Richard Smith <rsmith at bitworks.com> [041019 18:30]:
> I'm not doing it because its less work. *grin*
> 
> I'm thinking about those who come after me.  With the purpose of 
> creating a well documented starting structure at the same time teaching 
> me how v2 goes together.
> 
> Then next guy then has a clean starting point and dosen't have to wade 
> through the same stuff.


Maybe some good documentation about what needs to be done in which order
helps better in this case? I started describing the AMD64 work in
freebios2/documentation/LinuxBIOS-AMD64.tex, but this is obsolete with
the latest config file changes and it could need a lot more
contributions, ie generalizing the  AMD64isms.

Stefan



From stepan at openbios.org  Tue Oct 19 12:20:01 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Tue Oct 19 12:20:01 2004
Subject: FYI: Merge in progress...
In-Reply-To: <20041019132737.B32141-100000@www.missl.cs.umd.edu>
References: <417535FC.1040004@bitworks.com> <20041019132737.B32141-100000@www.missl.cs.umd.edu>
Message-ID: <20041019173839.GC10145@openbios.org>

* Adam Sulmicki <adam at cfar.umd.edu> [041019 19:28]:
> it has a name. the name is bochs.
> 
> more seriously if we could do it one way and move bochs bios to real
> hardware, we could go other way and move LB to bochs hardware (which is
> something like intel 440BX IIRC).
 
The emulation/qemu-i386 target should work with bochs, if it supports 
rom images with more than 64k. The reason I called it qemu-i386 is
because qemu is a lot faster than bochs, and it supports many CPU
architectures, instead of just x86 while emulating a fixed set of PCI
hardware. Thus, creating a qemu-ppc or qemu-sparc target for LinuxBIOS
would probably not be too much work.

Stefan



From YhLu at tyan.com  Tue Oct 19 13:54:00 2004
From: YhLu at tyan.com (YhLu)
Date: Tue Oct 19 13:54:00 2004
Subject: FYI: Merge in progress...
Message-ID: <3174569B9743D511922F00A0C94314230665B2B7@TYANWEB>

Eric,

The PCI_DOMAIN has two mem resource, root calculate the mem base correctly.
But PCI_DOMAIN get the wrong base.

root mem limit=0x00febfffff, size=0x0022700000, align=28, base=0x00d0000000
Allocating VGA resource PCI: 03:00.0
PCI_DOMAIN: 0000 00 <- [0x0000001000 - 0x0000005fff] io
PCI_DOMAIN: 0000 01 <- [0x00f8000000 - 0x01007fffff] prefmem
PCI_DOMAIN: 0000 02 <- [0x00f8000000 - 0x00fe6fffff] mem



-----Original Message-----
From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
Sent: Monday, October 18, 2004 7:54 PM
To: YhLu
Cc: Ronald G. Minnich; Li-Ta Lo; 'LinuxBIOS'
Subject: Re: FYI: Merge in progress...

YhLu <YhLu at tyan.com> writes:

> Get more worse.

Ouch.  If you can boot the board in linux please give me an lspci -vvv

I don't have enough information to even guess what is going on.
I need to know what the size and limit of the resources are,
so I can walk through the code and see what it would do.

At the moment I can't even begin to guess what is going wrong.

The obvious problem of doubly allocating a base register does
not appear to apply.  I am using the standard compute_allocate_resource
function which should traverse the bus and do the right thing.

Unless my rewrite of the limit calculation code is causing a problem.

I just don't know where to look.

Eric


From rsmith at bitworks.com  Tue Oct 19 13:58:00 2004
From: rsmith at bitworks.com (Richard Smith)
Date: Tue Oct 19 13:58:00 2004
Subject: FYI: Merge in progress...
In-Reply-To: <20041019185628.GA11647@openbios.org>
References: <3174569B9743D511922F00A0C94314230665B223@TYANWEB> <Pine.LNX.4.58.0410181659220.3965@linux.site> <41745527.7090201@bitworks.com> <Pine.LNX.4.58.0410190924250.6863@linux.site> <417535FC.1040004@bitworks.com> <Pine.LNX.4.58.0410190955260.6863@linux.site> <20041019172831.GA10145@openbios.org> <4175598E.3050205@bitworks.com> <20041019185628.GA11647@openbios.org>
Message-ID: <4175688B.8070409@bitworks.com>

Stefan Reinauer wrote:

> actually a real problem. I have not been able without hacks to find out
> the memory "layout" in qemu except the old read,write,read method of
> scanning through memory. Emulating enough of a northbridge would allow
> holes in memory and such, too.
> 
> Otoh, bochs and qemu (which per default uses the bochs bios) are
> concentrating a lot on userspace, even though they would suit perfectly
> for demonstrating and testing firmware development (besides the hardware
> weirdnesses) 

Its probally not very well suited then for a reference implementation.

Currently there is no "simple" port framework for v2.  I'm proposing 
creating that.  Then I'll attempt to use that to do my 440bx port and 
see how well it works.  Perhaps thats what I'll call it... "simple"

-- 
Richard A. Smith




From YhLu at tyan.com  Tue Oct 19 14:06:01 2004
From: YhLu at tyan.com (YhLu)
Date: Tue Oct 19 14:06:01 2004
Subject: FYI: Merge in progress...
Message-ID: <3174569B9743D511922F00A0C94314230665B2BA@TYANWEB>

strange size for prefmem of PCI_DOMAIN

root mem limit=0x00febfffff, size=0x0022700000, align=28, base=0x00d0000000
Allocating VGA resource PCI: 03:00.0
base1: 0xf8000000 limit1: 0xf7ffffff size: 0x1880000000000000
base2: 0xf8000000 limit2: 0xfebfffff size: 0x06700000
PCI_DOMAIN: 0000 00 <- [0x0000001000 - 0x0000005fff] io
PCI_DOMAIN: 0000 01 <- [0x00f8000000 - 0x01007fffff] prefmem
PCI_DOMAIN: 0000 02 <- [0x00f8000000 - 0x00fe6fffff] mem

-----Original Message-----
From: YhLu 
Sent: Tuesday, October 19, 2004 12:18 PM
To: ebiederman at lnxi.com
Cc: Ronald G. Minnich; Li-Ta Lo; 'LinuxBIOS'
Subject: RE: FYI: Merge in progress...

Eric,

The PCI_DOMAIN has two mem resource, root calculate the mem base correctly.
But PCI_DOMAIN get the wrong base.

root mem limit=0x00febfffff, size=0x0022700000, align=28, base=0x00d0000000
Allocating VGA resource PCI: 03:00.0
PCI_DOMAIN: 0000 00 <- [0x0000001000 - 0x0000005fff] io
PCI_DOMAIN: 0000 01 <- [0x00f8000000 - 0x01007fffff] prefmem
PCI_DOMAIN: 0000 02 <- [0x00f8000000 - 0x00fe6fffff] mem



-----Original Message-----
From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
Sent: Monday, October 18, 2004 7:54 PM
To: YhLu
Cc: Ronald G. Minnich; Li-Ta Lo; 'LinuxBIOS'
Subject: Re: FYI: Merge in progress...

YhLu <YhLu at tyan.com> writes:

> Get more worse.

Ouch.  If you can boot the board in linux please give me an lspci -vvv

I don't have enough information to even guess what is going on.
I need to know what the size and limit of the resources are,
so I can walk through the code and see what it would do.

At the moment I can't even begin to guess what is going wrong.

The obvious problem of doubly allocating a base register does
not appear to apply.  I am using the standard compute_allocate_resource
function which should traverse the bus and do the right thing.

Unless my rewrite of the limit calculation code is causing a problem.

I just don't know where to look.

Eric
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From YhLu at tyan.com  Tue Oct 19 14:38:00 2004
From: YhLu at tyan.com (YhLu)
Date: Tue Oct 19 14:38:00 2004
Subject: FYI: Merge in progress...
Message-ID: <3174569B9743D511922F00A0C94314230665B2BF@TYANWEB>

Align is not assigned and it will be used to calculate the base too. (using
resource_max)



root mem limit=0x00febfffff, size=0x0022700000, align=28, base=0x00d0000000
Allocating VGA resource PCI: 03:00.0
base1: a 0xd0000000 limit1: 0xfebfffff size: 0x1880000000000000 align:
0x1c00000000
base2: a 0xec000000 limit2: 0xfebfffff size: 0x06700000 align:
0x2bfc40000001a
base1: b 0xf8000000 limit1: 0xf7ffffff size: 0x1880000000000000 align:
0x1c00000000
base2: b 0xf8000000 limit2: 0xfebfffff size: 0x06700000 align:
0x2bfc40000001a

-----Original Message-----
From: YhLu 
Sent: Tuesday, October 19, 2004 12:31 PM
To: YhLu; ebiederman at lnxi.com
Cc: Ronald G. Minnich; Li-Ta Lo; 'LinuxBIOS'
Subject: RE: FYI: Merge in progress...

strange size for prefmem of PCI_DOMAIN

root mem limit=0x00febfffff, size=0x0022700000, align=28, base=0x00d0000000
Allocating VGA resource PCI: 03:00.0
base1: 0xf8000000 limit1: 0xf7ffffff size: 0x1880000000000000
base2: 0xf8000000 limit2: 0xfebfffff size: 0x06700000
PCI_DOMAIN: 0000 00 <- [0x0000001000 - 0x0000005fff] io
PCI_DOMAIN: 0000 01 <- [0x00f8000000 - 0x01007fffff] prefmem
PCI_DOMAIN: 0000 02 <- [0x00f8000000 - 0x00fe6fffff] mem

-----Original Message-----
From: YhLu 
Sent: Tuesday, October 19, 2004 12:18 PM
To: ebiederman at lnxi.com
Cc: Ronald G. Minnich; Li-Ta Lo; 'LinuxBIOS'
Subject: RE: FYI: Merge in progress...

Eric,

The PCI_DOMAIN has two mem resource, root calculate the mem base correctly.
But PCI_DOMAIN get the wrong base.

root mem limit=0x00febfffff, size=0x0022700000, align=28, base=0x00d0000000
Allocating VGA resource PCI: 03:00.0
PCI_DOMAIN: 0000 00 <- [0x0000001000 - 0x0000005fff] io
PCI_DOMAIN: 0000 01 <- [0x00f8000000 - 0x01007fffff] prefmem
PCI_DOMAIN: 0000 02 <- [0x00f8000000 - 0x00fe6fffff] mem



-----Original Message-----
From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
Sent: Monday, October 18, 2004 7:54 PM
To: YhLu
Cc: Ronald G. Minnich; Li-Ta Lo; 'LinuxBIOS'
Subject: Re: FYI: Merge in progress...

YhLu <YhLu at tyan.com> writes:

> Get more worse.

Ouch.  If you can boot the board in linux please give me an lspci -vvv

I don't have enough information to even guess what is going on.
I need to know what the size and limit of the resources are,
so I can walk through the code and see what it would do.

At the moment I can't even begin to guess what is going wrong.

The obvious problem of doubly allocating a base register does
not appear to apply.  I am using the standard compute_allocate_resource
function which should traverse the bus and do the right thing.

Unless my rewrite of the limit calculation code is causing a problem.

I just don't know where to look.

Eric
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From ollie at lanl.gov  Tue Oct 19 14:43:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Tue Oct 19 14:43:00 2004
Subject: FYI: Merge in progress...
In-Reply-To: <3174569B9743D511922F00A0C94314230665B2BF@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B2BF@TYANWEB>
Message-ID: <1098216214.3495.57.camel@exponential.lanl.gov>

On Tue, 2004-10-19 at 14:02, YhLu wrote:

YhLu,

Which mainboard are you working on ? Is it some board that's already in 
the public tree ? If it is already in the public tree, could be commit
you change so people on the list can try it.

Don't worry about broken code, every mainboard is broken in the current 
CVS.

Ollie 
> Align is not assigned and it will be used to calculate the base too. (using
> resource_max)
> 
> 
> 
> root mem limit=0x00febfffff, size=0x0022700000, align=28, base=0x00d0000000
> Allocating VGA resource PCI: 03:00.0
> base1: a 0xd0000000 limit1: 0xfebfffff size: 0x1880000000000000 align:
> 0x1c00000000
> base2: a 0xec000000 limit2: 0xfebfffff size: 0x06700000 align:
> 0x2bfc40000001a
> base1: b 0xf8000000 limit1: 0xf7ffffff size: 0x1880000000000000 align:
> 0x1c00000000
> base2: b 0xf8000000 limit2: 0xfebfffff size: 0x06700000 align:
> 0x2bfc40000001a
> 
> -----Original Message-----
> From: YhLu 
> Sent: Tuesday, October 19, 2004 12:31 PM
> To: YhLu; ebiederman at lnxi.com
> Cc: Ronald G. Minnich; Li-Ta Lo; 'LinuxBIOS'
> Subject: RE: FYI: Merge in progress...
> 
> strange size for prefmem of PCI_DOMAIN
> 
> root mem limit=0x00febfffff, size=0x0022700000, align=28, base=0x00d0000000
> Allocating VGA resource PCI: 03:00.0
> base1: 0xf8000000 limit1: 0xf7ffffff size: 0x1880000000000000
> base2: 0xf8000000 limit2: 0xfebfffff size: 0x06700000
> PCI_DOMAIN: 0000 00 <- [0x0000001000 - 0x0000005fff] io
> PCI_DOMAIN: 0000 01 <- [0x00f8000000 - 0x01007fffff] prefmem
> PCI_DOMAIN: 0000 02 <- [0x00f8000000 - 0x00fe6fffff] mem
> 
> -----Original Message-----
> From: YhLu 
> Sent: Tuesday, October 19, 2004 12:18 PM
> To: ebiederman at lnxi.com
> Cc: Ronald G. Minnich; Li-Ta Lo; 'LinuxBIOS'
> Subject: RE: FYI: Merge in progress...
> 
> Eric,
> 
> The PCI_DOMAIN has two mem resource, root calculate the mem base correctly.
> But PCI_DOMAIN get the wrong base.
> 
> root mem limit=0x00febfffff, size=0x0022700000, align=28, base=0x00d0000000
> Allocating VGA resource PCI: 03:00.0
> PCI_DOMAIN: 0000 00 <- [0x0000001000 - 0x0000005fff] io
> PCI_DOMAIN: 0000 01 <- [0x00f8000000 - 0x01007fffff] prefmem
> PCI_DOMAIN: 0000 02 <- [0x00f8000000 - 0x00fe6fffff] mem
> 
> 
> 
> -----Original Message-----
> From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
> Sent: Monday, October 18, 2004 7:54 PM
> To: YhLu
> Cc: Ronald G. Minnich; Li-Ta Lo; 'LinuxBIOS'
> Subject: Re: FYI: Merge in progress...
> 
> YhLu <YhLu at tyan.com> writes:
> 
> > Get more worse.
> 
> Ouch.  If you can boot the board in linux please give me an lspci -vvv
> 
> I don't have enough information to even guess what is going on.
> I need to know what the size and limit of the resources are,
> so I can walk through the code and see what it would do.
> 
> At the moment I can't even begin to guess what is going wrong.
> 
> The obvious problem of doubly allocating a base register does
> not appear to apply.  I am using the standard compute_allocate_resource
> function which should traverse the bus and do the right thing.
> 
> Unless my rewrite of the limit calculation code is causing a problem.
> 
> I just don't know where to look.
> 
> Eric
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 



From Stephen.Kimball at bench.com  Tue Oct 19 15:13:00 2004
From: Stephen.Kimball at bench.com (Stephen.Kimball at bench.com)
Date: Tue Oct 19 15:13:00 2004
Subject: Makefile changes for symbols
Message-ID: <9B124F08B3EFDA4F8813B05102DC719501A90262@nh-ex01.nh.bench.com>

Can someone give me the Makefile changes to make a LinuxBIOS with
symbols?  I tried adding "-gdwarf-2" to CFLAGS, but I'm not sure where
the unstripped output would be.  

Are there any features in the code that are useful in debugging
LinuxBIOS?
Any defines that should change as well?

Someone must have some experience with source code level debugging of
LinuxBIOS with an American Arium ECM-50.  Thanks.

Steve Kimball
Benchmark Electronics
Hudson, NH 


From YhLu at tyan.com  Tue Oct 19 15:36:01 2004
From: YhLu at tyan.com (YhLu)
Date: Tue Oct 19 15:36:01 2004
Subject: FYI: Merge in progress...
Message-ID: <3174569B9743D511922F00A0C94314230665B2D6@TYANWEB>

I will try s2885.

-----Original Message-----
From: Li-Ta Lo [mailto:ollie at lanl.gov] 
Sent: Tuesday, October 19, 2004 1:04 PM
To: YhLu
Cc: 'ebiederman at lnxi.com'; 'Ronald G. Minnich'; 'LinuxBIOS'
Subject: RE: FYI: Merge in progress...

On Tue, 2004-10-19 at 14:02, YhLu wrote:

YhLu,

Which mainboard are you working on ? Is it some board that's already in 
the public tree ? If it is already in the public tree, could be commit
you change so people on the list can try it.

Don't worry about broken code, every mainboard is broken in the current 
CVS.

Ollie 
> Align is not assigned and it will be used to calculate the base too.
(using
> resource_max)
> 
> 
> 
> root mem limit=0x00febfffff, size=0x0022700000, align=28,
base=0x00d0000000
> Allocating VGA resource PCI: 03:00.0
> base1: a 0xd0000000 limit1: 0xfebfffff size: 0x1880000000000000 align:
> 0x1c00000000
> base2: a 0xec000000 limit2: 0xfebfffff size: 0x06700000 align:
> 0x2bfc40000001a
> base1: b 0xf8000000 limit1: 0xf7ffffff size: 0x1880000000000000 align:
> 0x1c00000000
> base2: b 0xf8000000 limit2: 0xfebfffff size: 0x06700000 align:
> 0x2bfc40000001a
> 
> -----Original Message-----
> From: YhLu 
> Sent: Tuesday, October 19, 2004 12:31 PM
> To: YhLu; ebiederman at lnxi.com
> Cc: Ronald G. Minnich; Li-Ta Lo; 'LinuxBIOS'
> Subject: RE: FYI: Merge in progress...
> 
> strange size for prefmem of PCI_DOMAIN
> 
> root mem limit=0x00febfffff, size=0x0022700000, align=28,
base=0x00d0000000
> Allocating VGA resource PCI: 03:00.0
> base1: 0xf8000000 limit1: 0xf7ffffff size: 0x1880000000000000
> base2: 0xf8000000 limit2: 0xfebfffff size: 0x06700000
> PCI_DOMAIN: 0000 00 <- [0x0000001000 - 0x0000005fff] io
> PCI_DOMAIN: 0000 01 <- [0x00f8000000 - 0x01007fffff] prefmem
> PCI_DOMAIN: 0000 02 <- [0x00f8000000 - 0x00fe6fffff] mem
> 
> -----Original Message-----
> From: YhLu 
> Sent: Tuesday, October 19, 2004 12:18 PM
> To: ebiederman at lnxi.com
> Cc: Ronald G. Minnich; Li-Ta Lo; 'LinuxBIOS'
> Subject: RE: FYI: Merge in progress...
> 
> Eric,
> 
> The PCI_DOMAIN has two mem resource, root calculate the mem base
correctly.
> But PCI_DOMAIN get the wrong base.
> 
> root mem limit=0x00febfffff, size=0x0022700000, align=28,
base=0x00d0000000
> Allocating VGA resource PCI: 03:00.0
> PCI_DOMAIN: 0000 00 <- [0x0000001000 - 0x0000005fff] io
> PCI_DOMAIN: 0000 01 <- [0x00f8000000 - 0x01007fffff] prefmem
> PCI_DOMAIN: 0000 02 <- [0x00f8000000 - 0x00fe6fffff] mem
> 
> 
> 
> -----Original Message-----
> From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
> Sent: Monday, October 18, 2004 7:54 PM
> To: YhLu
> Cc: Ronald G. Minnich; Li-Ta Lo; 'LinuxBIOS'
> Subject: Re: FYI: Merge in progress...
> 
> YhLu <YhLu at tyan.com> writes:
> 
> > Get more worse.
> 
> Ouch.  If you can boot the board in linux please give me an lspci -vvv
> 
> I don't have enough information to even guess what is going on.
> I need to know what the size and limit of the resources are,
> so I can walk through the code and see what it would do.
> 
> At the moment I can't even begin to guess what is going wrong.
> 
> The obvious problem of doubly allocating a base register does
> not appear to apply.  I am using the standard compute_allocate_resource
> function which should traverse the bus and do the right thing.
> 
> Unless my rewrite of the limit calculation code is causing a problem.
> 
> I just don't know where to look.
> 
> Eric
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 


From YhLu at tyan.com  Tue Oct 19 15:38:59 2004
From: YhLu at tyan.com (YhLu)
Date: Tue Oct 19 15:38:59 2004
Subject: FYI: Merge in progress...
Message-ID: <3174569B9743D511922F00A0C94314230665B2D7@TYANWEB>

Eric, 

after comment out something in 

static void pci_domain_set_resources(device_t dev)

#if 0
        /* Now reallocate the pci resources memory with the
         * highest addresses I can manage.
         */

It works now.

you may need to look at these lines.

Regards

YH
-----Original Message-----
From: Li-Ta Lo [mailto:ollie at lanl.gov] 
Sent: Tuesday, October 19, 2004 1:04 PM
To: YhLu
Cc: 'ebiederman at lnxi.com'; 'Ronald G. Minnich'; 'LinuxBIOS'
Subject: RE: FYI: Merge in progress...

On Tue, 2004-10-19 at 14:02, YhLu wrote:

YhLu,

Which mainboard are you working on ? Is it some board that's already in 
the public tree ? If it is already in the public tree, could be commit
you change so people on the list can try it.

Don't worry about broken code, every mainboard is broken in the current 
CVS.

Ollie 
> Align is not assigned and it will be used to calculate the base too.
(using
> resource_max)
> 
> 
> 
> root mem limit=0x00febfffff, size=0x0022700000, align=28,
base=0x00d0000000
> Allocating VGA resource PCI: 03:00.0
> base1: a 0xd0000000 limit1: 0xfebfffff size: 0x1880000000000000 align:
> 0x1c00000000
> base2: a 0xec000000 limit2: 0xfebfffff size: 0x06700000 align:
> 0x2bfc40000001a
> base1: b 0xf8000000 limit1: 0xf7ffffff size: 0x1880000000000000 align:
> 0x1c00000000
> base2: b 0xf8000000 limit2: 0xfebfffff size: 0x06700000 align:
> 0x2bfc40000001a
> 
> -----Original Message-----
> From: YhLu 
> Sent: Tuesday, October 19, 2004 12:31 PM
> To: YhLu; ebiederman at lnxi.com
> Cc: Ronald G. Minnich; Li-Ta Lo; 'LinuxBIOS'
> Subject: RE: FYI: Merge in progress...
> 
> strange size for prefmem of PCI_DOMAIN
> 
> root mem limit=0x00febfffff, size=0x0022700000, align=28,
base=0x00d0000000
> Allocating VGA resource PCI: 03:00.0
> base1: 0xf8000000 limit1: 0xf7ffffff size: 0x1880000000000000
> base2: 0xf8000000 limit2: 0xfebfffff size: 0x06700000
> PCI_DOMAIN: 0000 00 <- [0x0000001000 - 0x0000005fff] io
> PCI_DOMAIN: 0000 01 <- [0x00f8000000 - 0x01007fffff] prefmem
> PCI_DOMAIN: 0000 02 <- [0x00f8000000 - 0x00fe6fffff] mem
> 
> -----Original Message-----
> From: YhLu 
> Sent: Tuesday, October 19, 2004 12:18 PM
> To: ebiederman at lnxi.com
> Cc: Ronald G. Minnich; Li-Ta Lo; 'LinuxBIOS'
> Subject: RE: FYI: Merge in progress...
> 
> Eric,
> 
> The PCI_DOMAIN has two mem resource, root calculate the mem base
correctly.
> But PCI_DOMAIN get the wrong base.
> 
> root mem limit=0x00febfffff, size=0x0022700000, align=28,
base=0x00d0000000
> Allocating VGA resource PCI: 03:00.0
> PCI_DOMAIN: 0000 00 <- [0x0000001000 - 0x0000005fff] io
> PCI_DOMAIN: 0000 01 <- [0x00f8000000 - 0x01007fffff] prefmem
> PCI_DOMAIN: 0000 02 <- [0x00f8000000 - 0x00fe6fffff] mem
> 
> 
> 
> -----Original Message-----
> From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
> Sent: Monday, October 18, 2004 7:54 PM
> To: YhLu
> Cc: Ronald G. Minnich; Li-Ta Lo; 'LinuxBIOS'
> Subject: Re: FYI: Merge in progress...
> 
> YhLu <YhLu at tyan.com> writes:
> 
> > Get more worse.
> 
> Ouch.  If you can boot the board in linux please give me an lspci -vvv
> 
> I don't have enough information to even guess what is going on.
> I need to know what the size and limit of the resources are,
> so I can walk through the code and see what it would do.
> 
> At the moment I can't even begin to guess what is going wrong.
> 
> The obvious problem of doubly allocating a base register does
> not appear to apply.  I am using the standard compute_allocate_resource
> function which should traverse the bus and do the right thing.
> 
> Unless my rewrite of the limit calculation code is causing a problem.
> 
> I just don't know where to look.
> 
> Eric
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 


From cm-lists at murgott.de  Tue Oct 19 15:59:00 2004
From: cm-lists at murgott.de (Christof Murgott)
Date: Tue Oct 19 15:59:00 2004
Subject: hanging 'Setting fixed MTRRs' 810lmr
Message-ID: <20041019211944.GA417@murgott.de>

Hi,

I've downloaded the linuxbios source via CVS and the 2.4.19 from
ftp.kernel.org, built everything as Antony Stone has explained in this
howto[1]. However, the computer (PCCHIPS 810lmr) stalls with the
following output on the serial console:

LinuxBIOS-1.0.0 Mon Aug 30 09:03:42 CEST 2004 starting...
Copying LinuxBIOS to ram.
Jumping to LinuxBIOS.
POST: 0x39
LinuxBIOS-1.0.0 Mon Aug 30 09:03:42 CEST 2004 booting...
POST: 0x40
Finding PCI configuration type.
PCI: Using configuration type 1
POST: 0x5f
handle_superio start, nsuperio 1
handle_superio: Pass 0, check #0, s 0000bf40 s->super 0000c218
handle_superio: Pass 0, Superio SiS 950
handle_superio:  port 0x0, defaultport 0x2e
handle_superio:  Using port 0x2e
handle_superio: Pass 0, done #0
handle_superio done
Scanning PCI bus...PCI: pci_scan_bus for bus 0
POST: 0x24
PCI: 00:00.0 [1039/0730]
PCI: 00:00.1 [1039/5513]
PCI: 00:01.0 [1039/0008]
PCI: 00:01.4 [1039/7018]
PCI: 00:02.0 [1039/0001]
POST: 0x25
PCI: pci_scan_bus for bus 1
POST: 0x24
PCI: 01:00.0 [1039/6300]
POST: 0x25
PCI: pci_scan_bus returning with max=01
POST: 0x55
PCI: pci_scan_bus returning with max=01
POST: 0x55
done
POST: 0x66
Allocating PCI resources...
ASSIGN RESOURCES, bus 0
PCI: 00:00.0 10 <- [0xf8000000 - 0xfbffffff] mem
PCI: 00:00.1 10 <- [0x00002410 - 0x00002413] io
PCI: 00:00.1 14 <- [0x00002420 - 0x00002423] io
PCI: 00:00.1 18 <- [0x00002430 - 0x00002433] io
PCI: 00:00.1 1c <- [0x00002440 - 0x00002443] io
PCI: 00:00.1 20 <- [0x00002400 - 0x0000240f] io
PCI: 00:01.4 10 <- [0x00002000 - 0x000020ff] io
PCI: 00:01.4 14 <- [0xfc100000 - 0xfc100fff] mem
PCI: 00:02.0 1c <- [0x00001000 - 0x00001fff] bus 1 io
PCI: 00:02.0 24 <- [0xf0000000 - 0xf7ffffff] bus 1 prefmem
PCI: 00:02.0 20 <- [0xfc000000 - 0xfc0fffff] bus 1 mem
ASSIGN RESOURCES, bus 1
PCI: 01:00.0 10 <- [0xf0000000 - 0xf7ffffff] prefmem
PCI: 01:00.0 14 <- [0xfc000000 - 0xfc01ffff] mem
PCI: 01:00.0 18 <- [0x00001000 - 0x0000107f] io
ASSIGNED RESOURCES, bus 1
ASSIGNED RESOURCES, bus 0
Allocating VGA resource
done.
POST: 0x88
Enabling PCI resourcess...PCI: 00:00.0 cmd <- 07
PCI: 00:00.1 cmd <- 01
PCI: 00:01.0 cmd <- 0c
PCI: 00:01.4 cmd <- 03
PCI: 00:02.0 cmd <- 27
PCI: 01:00.0 cmd <- 03
done.
Initializing PCI devices...
PCI devices initialized
POST: 0x89
POST: 0x70
totalram: 248M
Initializing CPU #0
POST: 0x60
Enabling cache...
Setting fixed MTRRs(0-42647) type: UC

I can't do anything with it. So I searched the mailinglist archive and
found a patch[2] from Andrew Ip. But nothing changed!

Can anybody help me?

Bye,
 Christof

The System is running Redhat 7.2 and I have a MD-2802-D08.

[1] http://www.linuxbios.org/developer/portguides/M810LR/index.html
[2] http://www.clustermatic.org/pipermail/linuxbios/2003-June/003808.html



From rminnich at lanl.gov  Tue Oct 19 16:29:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Tue Oct 19 16:29:01 2004
Subject: Makefile changes for symbols
In-Reply-To: <9B124F08B3EFDA4F8813B05102DC719501A90262@nh-ex01.nh.bench.com>
References: <9B124F08B3EFDA4F8813B05102DC719501A90262@nh-ex01.nh.bench.com>
Message-ID: <Pine.LNX.4.58.0410191525000.6863@linux.site>


On Tue, 19 Oct 2004 Stephen.Kimball at bench.com wrote:

> 
> Someone must have some experience with source code level debugging of
> LinuxBIOS with an American Arium ECM-50.  Thanks.

wow! I want to hear about that when you get it going. Another FAQ entry.

ron


From YhLu at tyan.com  Tue Oct 19 16:53:01 2004
From: YhLu at tyan.com (YhLu)
Date: Tue Oct 19 16:53:01 2004
Subject: FYI: Merge in progress...
Message-ID: <3174569B9743D511922F00A0C94314230665B2EE@TYANWEB>

Eric, 

The mail server bounce back my email....

Regards

Yinghai Lu

-----Original Message-----
From: YhLu 
Sent: Tuesday, October 19, 2004 2:00 PM
To: 'Li-Ta Lo'
Cc: 'ebiederman at lnxi.com'; 'Ronald G. Minnich'; 'LinuxBIOS'
Subject: RE: FYI: Merge in progress...

Eric, 

after comment out something in 

static void pci_domain_set_resources(device_t dev)

#if 0
        /* Now reallocate the pci resources memory with the
         * highest addresses I can manage.
         */

It works now.

you may need to look at these lines.

Regards

YH
-----Original Message-----
From: Li-Ta Lo [mailto:ollie at lanl.gov] 
Sent: Tuesday, October 19, 2004 1:04 PM
To: YhLu
Cc: 'ebiederman at lnxi.com'; 'Ronald G. Minnich'; 'LinuxBIOS'
Subject: RE: FYI: Merge in progress...

On Tue, 2004-10-19 at 14:02, YhLu wrote:

YhLu,

Which mainboard are you working on ? Is it some board that's already in 
the public tree ? If it is already in the public tree, could be commit
you change so people on the list can try it.

Don't worry about broken code, every mainboard is broken in the current 
CVS.

Ollie 
> Align is not assigned and it will be used to calculate the base too.
(using
> resource_max)
> 
> 
> 
> root mem limit=0x00febfffff, size=0x0022700000, align=28,
base=0x00d0000000
> Allocating VGA resource PCI: 03:00.0
> base1: a 0xd0000000 limit1: 0xfebfffff size: 0x1880000000000000 align:
> 0x1c00000000
> base2: a 0xec000000 limit2: 0xfebfffff size: 0x06700000 align:
> 0x2bfc40000001a
> base1: b 0xf8000000 limit1: 0xf7ffffff size: 0x1880000000000000 align:
> 0x1c00000000
> base2: b 0xf8000000 limit2: 0xfebfffff size: 0x06700000 align:
> 0x2bfc40000001a
> 
> -----Original Message-----
> From: YhLu 
> Sent: Tuesday, October 19, 2004 12:31 PM
> To: YhLu; ebiederman at lnxi.com
> Cc: Ronald G. Minnich; Li-Ta Lo; 'LinuxBIOS'
> Subject: RE: FYI: Merge in progress...
> 
> strange size for prefmem of PCI_DOMAIN
> 
> root mem limit=0x00febfffff, size=0x0022700000, align=28,
base=0x00d0000000
> Allocating VGA resource PCI: 03:00.0
> base1: 0xf8000000 limit1: 0xf7ffffff size: 0x1880000000000000
> base2: 0xf8000000 limit2: 0xfebfffff size: 0x06700000
> PCI_DOMAIN: 0000 00 <- [0x0000001000 - 0x0000005fff] io
> PCI_DOMAIN: 0000 01 <- [0x00f8000000 - 0x01007fffff] prefmem
> PCI_DOMAIN: 0000 02 <- [0x00f8000000 - 0x00fe6fffff] mem
> 
> -----Original Message-----
> From: YhLu 
> Sent: Tuesday, October 19, 2004 12:18 PM
> To: ebiederman at lnxi.com
> Cc: Ronald G. Minnich; Li-Ta Lo; 'LinuxBIOS'
> Subject: RE: FYI: Merge in progress...
> 
> Eric,
> 
> The PCI_DOMAIN has two mem resource, root calculate the mem base
correctly.
> But PCI_DOMAIN get the wrong base.
> 
> root mem limit=0x00febfffff, size=0x0022700000, align=28,
base=0x00d0000000
> Allocating VGA resource PCI: 03:00.0
> PCI_DOMAIN: 0000 00 <- [0x0000001000 - 0x0000005fff] io
> PCI_DOMAIN: 0000 01 <- [0x00f8000000 - 0x01007fffff] prefmem
> PCI_DOMAIN: 0000 02 <- [0x00f8000000 - 0x00fe6fffff] mem
> 
> 
> 
> -----Original Message-----
> From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
> Sent: Monday, October 18, 2004 7:54 PM
> To: YhLu
> Cc: Ronald G. Minnich; Li-Ta Lo; 'LinuxBIOS'
> Subject: Re: FYI: Merge in progress...
> 
> YhLu <YhLu at tyan.com> writes:
> 
> > Get more worse.
> 
> Ouch.  If you can boot the board in linux please give me an lspci -vvv
> 
> I don't have enough information to even guess what is going on.
> I need to know what the size and limit of the resources are,
> so I can walk through the code and see what it would do.
> 
> At the moment I can't even begin to guess what is going wrong.
> 
> The obvious problem of doubly allocating a base register does
> not appear to apply.  I am using the standard compute_allocate_resource
> function which should traverse the bus and do the right thing.
> 
> Unless my rewrite of the limit calculation code is causing a problem.
> 
> I just don't know where to look.
> 
> Eric
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 


From YhLu at tyan.com  Tue Oct 19 17:59:01 2004
From: YhLu at tyan.com (YhLu)
Date: Tue Oct 19 17:59:01 2004
Subject: FYI: Merge in progress...
Message-ID: <3174569B9743D511922F00A0C94314230665B30A@TYANWEB>

Find out the problem, should be typo error.

                /* Now place the memory as high up as it will go */
                mem2->base = resource_max(mem2);
                mem1->limit = mem2->base - 1;
                mem1->base = resource_max(mem2);
------>
                /* Now place the memory as high up as it will go */
                mem2->base = resource_max(mem2);
                mem1->limit = mem2->base - 1;
                mem1->base = resource_max(mem1);

regards

YH
-----Original Message-----
From: YhLu 
Sent: Tuesday, October 19, 2004 2:04 PM
To: Li-Ta Lo
Cc: 'ebiederman at lnxi.com'; 'Ronald G. Minnich'; 'LinuxBIOS'
Subject: RE: FYI: Merge in progress...

Eric, 

after comment out something in 

static void pci_domain_set_resources(device_t dev)

#if 0
        /* Now reallocate the pci resources memory with the
         * highest addresses I can manage.
         */

It works now.

you may need to look at these lines.

Regards

YH
-----Original Message-----
From: Li-Ta Lo [mailto:ollie at lanl.gov] 
Sent: Tuesday, October 19, 2004 1:04 PM
To: YhLu
Cc: 'ebiederman at lnxi.com'; 'Ronald G. Minnich'; 'LinuxBIOS'
Subject: RE: FYI: Merge in progress...

On Tue, 2004-10-19 at 14:02, YhLu wrote:

YhLu,

Which mainboard are you working on ? Is it some board that's already in 
the public tree ? If it is already in the public tree, could be commit
you change so people on the list can try it.

Don't worry about broken code, every mainboard is broken in the current 
CVS.

Ollie 
> Align is not assigned and it will be used to calculate the base too.
(using
> resource_max)
> 
> 
> 
> root mem limit=0x00febfffff, size=0x0022700000, align=28,
base=0x00d0000000
> Allocating VGA resource PCI: 03:00.0
> base1: a 0xd0000000 limit1: 0xfebfffff size: 0x1880000000000000 align:
> 0x1c00000000
> base2: a 0xec000000 limit2: 0xfebfffff size: 0x06700000 align:
> 0x2bfc40000001a
> base1: b 0xf8000000 limit1: 0xf7ffffff size: 0x1880000000000000 align:
> 0x1c00000000
> base2: b 0xf8000000 limit2: 0xfebfffff size: 0x06700000 align:
> 0x2bfc40000001a
> 
> -----Original Message-----
> From: YhLu 
> Sent: Tuesday, October 19, 2004 12:31 PM
> To: YhLu; ebiederman at lnxi.com
> Cc: Ronald G. Minnich; Li-Ta Lo; 'LinuxBIOS'
> Subject: RE: FYI: Merge in progress...
> 
> strange size for prefmem of PCI_DOMAIN
> 
> root mem limit=0x00febfffff, size=0x0022700000, align=28,
base=0x00d0000000
> Allocating VGA resource PCI: 03:00.0
> base1: 0xf8000000 limit1: 0xf7ffffff size: 0x1880000000000000
> base2: 0xf8000000 limit2: 0xfebfffff size: 0x06700000
> PCI_DOMAIN: 0000 00 <- [0x0000001000 - 0x0000005fff] io
> PCI_DOMAIN: 0000 01 <- [0x00f8000000 - 0x01007fffff] prefmem
> PCI_DOMAIN: 0000 02 <- [0x00f8000000 - 0x00fe6fffff] mem
> 
> -----Original Message-----
> From: YhLu 
> Sent: Tuesday, October 19, 2004 12:18 PM
> To: ebiederman at lnxi.com
> Cc: Ronald G. Minnich; Li-Ta Lo; 'LinuxBIOS'
> Subject: RE: FYI: Merge in progress...
> 
> Eric,
> 
> The PCI_DOMAIN has two mem resource, root calculate the mem base
correctly.
> But PCI_DOMAIN get the wrong base.
> 
> root mem limit=0x00febfffff, size=0x0022700000, align=28,
base=0x00d0000000
> Allocating VGA resource PCI: 03:00.0
> PCI_DOMAIN: 0000 00 <- [0x0000001000 - 0x0000005fff] io
> PCI_DOMAIN: 0000 01 <- [0x00f8000000 - 0x01007fffff] prefmem
> PCI_DOMAIN: 0000 02 <- [0x00f8000000 - 0x00fe6fffff] mem
> 
> 
> 
> -----Original Message-----
> From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
> Sent: Monday, October 18, 2004 7:54 PM
> To: YhLu
> Cc: Ronald G. Minnich; Li-Ta Lo; 'LinuxBIOS'
> Subject: Re: FYI: Merge in progress...
> 
> YhLu <YhLu at tyan.com> writes:
> 
> > Get more worse.
> 
> Ouch.  If you can boot the board in linux please give me an lspci -vvv
> 
> I don't have enough information to even guess what is going on.
> I need to know what the size and limit of the resources are,
> so I can walk through the code and see what it would do.
> 
> At the moment I can't even begin to guess what is going wrong.
> 
> The obvious problem of doubly allocating a base register does
> not appear to apply.  I am using the standard compute_allocate_resource
> function which should traverse the bus and do the right thing.
> 
> Unless my rewrite of the limit calculation code is causing a problem.
> 
> I just don't know where to look.
> 
> Eric
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From ebiederman at lnxi.com  Tue Oct 19 18:16:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Oct 19 18:16:00 2004
Subject: FYI: Merge in progress...
In-Reply-To: <3174569B9743D511922F00A0C94314230665B30A@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B30A@TYANWEB>
Message-ID: <m3u0sq9t5z.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> Find out the problem, should be typo error.
> 
>                 /* Now place the memory as high up as it will go */
>                 mem2->base = resource_max(mem2);
>                 mem1->limit = mem2->base - 1;
>                 mem1->base = resource_max(mem2);
> ------>
>                 /* Now place the memory as high up as it will go */
>                 mem2->base = resource_max(mem2);
>                 mem1->limit = mem2->base - 1;
>                 mem1->base = resource_max(mem1);
> 
> regards

Thanks.  That was a definite blind spot, on my side.

I have now committed the fix.

Eric




From YhLu at tyan.com  Tue Oct 19 20:06:01 2004
From: YhLu at tyan.com (YhLu)
Date: Tue Oct 19 20:06:01 2004
Subject: FYI: Merge in progress...
Message-ID: <3174569B9743D511922F00A0C94314230665B332@TYANWEB>

Suggest you to add two options
1. premem 64 bit support? PCI_MEM_PREF_64BIT_SUPPORT
2. pci mmio optimizing?  PCI_MEM_BASE_OPTIMIZATION

Regards

YH

-----Original Message-----
From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
Sent: Tuesday, October 19, 2004 4:37 PM
To: YhLu
Cc: Li-Ta Lo; 'ebiederman at lnxi.com'; 'Ronald G. Minnich'; 'LinuxBIOS'
Subject: Re: FYI: Merge in progress...

YhLu <YhLu at tyan.com> writes:

> Find out the problem, should be typo error.
> 
>                 /* Now place the memory as high up as it will go */
>                 mem2->base = resource_max(mem2);
>                 mem1->limit = mem2->base - 1;
>                 mem1->base = resource_max(mem2);
> ------>
>                 /* Now place the memory as high up as it will go */
>                 mem2->base = resource_max(mem2);
>                 mem1->limit = mem2->base - 1;
>                 mem1->base = resource_max(mem1);
> 
> regards

Thanks.  That was a definite blind spot, on my side.

I have now committed the fix.

Eric



From YhLu at tyan.com  Tue Oct 19 21:03:01 2004
From: YhLu at tyan.com (YhLu)
Date: Tue Oct 19 21:03:01 2004
Subject: FYI: Merge in progress...
Message-ID: <3174569B9743D511922F00A0C94314230665B33E@TYANWEB>

Why enable cache in amd_early_mtrr_init?

That causes CPU sleep 5s again.

After get rid of that, the new auto.c stage still cost more 1s than the code
two weeks ago.

Regards

YH

-----Original Message-----
From: YhLu 
Sent: Tuesday, October 19, 2004 6:30 PM
To: ebiederman at lnxi.com
Cc: Li-Ta Lo; 'Ronald G. Minnich'; 'LinuxBIOS'
Subject: RE: FYI: Merge in progress...

Suggest you to add two options
1. premem 64 bit support? PCI_MEM_PREF_64BIT_SUPPORT
2. pci mmio optimizing?  PCI_MEM_BASE_OPTIMIZATION

Regards

YH

-----Original Message-----
From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
Sent: Tuesday, October 19, 2004 4:37 PM
To: YhLu
Cc: Li-Ta Lo; 'ebiederman at lnxi.com'; 'Ronald G. Minnich'; 'LinuxBIOS'
Subject: Re: FYI: Merge in progress...

YhLu <YhLu at tyan.com> writes:

> Find out the problem, should be typo error.
> 
>                 /* Now place the memory as high up as it will go */
>                 mem2->base = resource_max(mem2);
>                 mem1->limit = mem2->base - 1;
>                 mem1->base = resource_max(mem2);
> ------>
>                 /* Now place the memory as high up as it will go */
>                 mem2->base = resource_max(mem2);
>                 mem1->limit = mem2->base - 1;
>                 mem1->base = resource_max(mem1);
> 
> regards

Thanks.  That was a definite blind spot, on my side.

I have now committed the fix.

Eric

_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From YhLu at tyan.com  Tue Oct 19 23:49:01 2004
From: YhLu at tyan.com (YhLu)
Date: Tue Oct 19 23:49:01 2004
Subject: FYI: Merge in progress...
Message-ID: <3174569B9743D511922F00A0C94314230665B35B@TYANWEB>

Just check in Tyan update to support new config.

CVS: ----------------------------------------------------------------------
CVS: Enter Log.  Lines beginning with `CVS:' are removed automatically
CVS:
CVS: Committing in .
CVS:
CVS: Modified Files:
CVS:    src/include/device/device.h src/mainboard/amd/quartet/auto.c
CVS:    src/mainboard/tyan/s2850/Config.lb
CVS:    src/mainboard/tyan/s2850/auto.c
CVS:    src/mainboard/tyan/s2850/chip.h
CVS:    src/mainboard/tyan/s2850/cmos.layout
CVS:    src/mainboard/tyan/s2850/failover.c
CVS:    src/mainboard/tyan/s2850/mainboard.c
CVS:    src/mainboard/tyan/s2850/mptable.c
CVS:    src/mainboard/tyan/s2875/Config.lb
CVS:    src/mainboard/tyan/s2875/auto.c
CVS:    src/mainboard/tyan/s2875/chip.h
CVS:    src/mainboard/tyan/s2875/cmos.layout
CVS:    src/mainboard/tyan/s2875/failover.c
CVS:    src/mainboard/tyan/s2875/mainboard.c
CVS:    src/mainboard/tyan/s2875/mptable.c
CVS:    src/mainboard/tyan/s2880/Config.lb
CVS:    src/mainboard/tyan/s2880/auto.c
CVS:    src/mainboard/tyan/s2880/chip.h
CVS:    src/mainboard/tyan/s2880/cmos.layout
CVS:    src/mainboard/tyan/s2880/failover.c
CVS:    src/mainboard/tyan/s2880/mainboard.c
CVS:    src/mainboard/tyan/s2880/mptable.c
CVS:    src/mainboard/tyan/s2881/Config.lb
CVS:    src/mainboard/tyan/s2881/auto.c
CVS:    src/mainboard/tyan/s2881/chip.h
CVS:    src/mainboard/tyan/s2881/cmos.layout
CVS:    src/mainboard/tyan/s2881/failover.c
CVS:    src/mainboard/tyan/s2881/mainboard.c
CVS:    src/mainboard/tyan/s2881/mptable.c
CVS:    src/mainboard/tyan/s2882/Config.lb
CVS:    src/mainboard/tyan/s2882/auto.c
CVS:    src/mainboard/tyan/s2882/chip.h
CVS:    src/mainboard/tyan/s2882/cmos.layout
CVS:    src/mainboard/tyan/s2882/failover.c
CVS:    src/mainboard/tyan/s2882/irq_tables.c
CVS:    src/mainboard/tyan/s2882/mainboard.c
CVS:    src/mainboard/tyan/s2882/mptable.c
CVS:    src/mainboard/tyan/s2885/Config.lb
CVS:    src/mainboard/tyan/s2885/auto.c
CVS:    src/mainboard/tyan/s2885/chip.h 
CVS:    src/mainboard/tyan/s2885/cmos.layout
CVS:    src/mainboard/tyan/s2885/failover.c 
CVS:    src/mainboard/tyan/s2885/mainboard.c
CVS:    src/mainboard/tyan/s2885/mptable.c 
CVS:    src/mainboard/tyan/s2885/resourcemap.c
CVS:    src/mainboard/tyan/s2885/ti_firewire.c
CVS:    src/mainboard/tyan/s4880/Config.lb
CVS:    src/mainboard/tyan/s4880/auto.c
CVS:    src/mainboard/tyan/s4880/chip.h 
CVS:    src/mainboard/tyan/s4880/cmos.layout
CVS:    src/mainboard/tyan/s4880/failover.c 
CVS:    src/mainboard/tyan/s4880/mainboard.c
CVS:    src/mainboard/tyan/s4880/mptable.c
CVS:    src/mainboard/tyan/s4882/Config.lb
CVS:    src/mainboard/tyan/s4882/auto.c
CVS:    src/mainboard/tyan/s4882/chip.h 
CVS:    src/mainboard/tyan/s4882/cmos.layout
CVS:    src/mainboard/tyan/s4882/failover.c 
CVS:    src/mainboard/tyan/s4882/mainboard.c
CVS:    src/mainboard/tyan/s4882/mptable.c 
CVS:    src/northbridge/amd/amdk8/incoherent_ht.c
CVS:    src/superio/winbond/w83627hf/chip.h 
CVS:    src/superio/winbond/w83627hf/superio.c 
CVS:    targets/tyan/s2850/Config.lb targets/tyan/s2875/Config.lb
CVS:    targets/tyan/s2880/Config.lb targets/tyan/s2880/ns2880 
CVS:    targets/tyan/s2881/Config.lb targets/tyan/s2882/Config.lb
CVS:    targets/tyan/s2885/Config.lb targets/tyan/s4880/Config.lb 
CVS:    targets/tyan/s4882/Config.lb util/flash_and_burn/flash_rom.c
CVS:    util/flash_and_burn/pm49fl004.c
-----------------------------------------



From sagivy at 3vium.com  Wed Oct 20 03:29:00 2004
From: sagivy at 3vium.com (Sagiv Yefet)
Date: Wed Oct 20 03:29:00 2004
Subject: building Image with RTL8169 NIC
Message-ID: <4A3D5F6DC9406A4DBE93D9BA8F07E4BB22D6C5@cronos.trivium>

Hello,
 
I am trying to build IMAGE for Tyan 2850 with RTL8169 NIC.
 
Which driver supports this NIC?
 
Sagiv
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20041020/bda7982d/attachment.html>

From Stephen.Kimball at bench.com  Wed Oct 20 07:08:01 2004
From: Stephen.Kimball at bench.com (Stephen.Kimball at bench.com)
Date: Wed Oct 20 07:08:01 2004
Subject: Makefile changes for symbols
Message-ID: <9B124F08B3EFDA4F8813B05102DC719501A90264@nh-ex01.nh.bench.com>

Ron,

Is LinuxBIOS development done with only serial port debug messages?
You guys are good.

Steve

-----Original Message-----
From: Ronald G. Minnich [mailto:rminnich at lanl.gov] 
Sent: Tuesday, October 19, 2004 5:25 PM
To: Kimball, Stephen
Cc: linuxbios at clustermatic.org
Subject: Re: Makefile changes for symbols



On Tue, 19 Oct 2004 Stephen.Kimball at bench.com wrote:

> 
> Someone must have some experience with source code level debugging of
> LinuxBIOS with an American Arium ECM-50.  Thanks.

wow! I want to hear about that when you get it going. Another FAQ entry.

ron


From stepan at openbios.org  Wed Oct 20 07:37:00 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Wed Oct 20 07:37:00 2004
Subject: FYI: Merge in progress...
In-Reply-To: <3174569B9743D511922F00A0C94314230665B35B@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B35B@TYANWEB>
Message-ID: <20041020125757.GB29045@openbios.org>

* YhLu <YhLu at tyan.com> [041020 07:13]:
> Just check in Tyan update to support new config.
 
Hey Yinghai!

It seems you forgot to commit the Options.lb files:

freebios2/src/mainboard/tyan/*/Options.lb

Currently config creation fails for all tyan boards complaining about
this file ..

    Stefan



From daubin at actuality-systems.com  Wed Oct 20 07:45:01 2004
From: daubin at actuality-systems.com (Dave Aubin)
Date: Wed Oct 20 07:45:01 2004
Subject: Makefile changes for symbols
Message-ID: <E8F8DBCB0468204E856114A2CD20741F2C1A34@mail.local.ActualitySystems.com>

Hi Steve,

  Nice to hear someone else in the northeast is using lb:)
Methods we use to do linux bios debugging:
1.  Serial
2.  netconsole (same as serial but over ethernet)
3.  Hardware Emulator with debugger
4.  Toggling leds at certain places (i.e. like printfs for leds;)

-----Original Message-----
From: linuxbios-admin at clustermatic.org
[mailto:linuxbios-admin at clustermatic.org] On Behalf Of
Stephen.Kimball at bench.com
Sent: Wednesday, October 20, 2004 8:29 AM
To: rminnich at lanl.gov
Cc: linuxbios at clustermatic.org
Subject: RE: Makefile changes for symbols

Ron,

Is LinuxBIOS development done with only serial port debug messages?
You guys are good.

Steve

-----Original Message-----
From: Ronald G. Minnich [mailto:rminnich at lanl.gov]
Sent: Tuesday, October 19, 2004 5:25 PM
To: Kimball, Stephen
Cc: linuxbios at clustermatic.org
Subject: Re: Makefile changes for symbols



On Tue, 19 Oct 2004 Stephen.Kimball at bench.com wrote:

> 
> Someone must have some experience with source code level debugging of
> LinuxBIOS with an American Arium ECM-50.  Thanks.

wow! I want to hear about that when you get it going. Another FAQ entry.

ron
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From Rodney.Kittleson at bench.com  Wed Oct 20 10:27:00 2004
From: Rodney.Kittleson at bench.com (Rodney.Kittleson at bench.com)
Date: Wed Oct 20 10:27:00 2004
Subject: Makefile changes for symbols
Message-ID: <8E8200E838D692429246225038E1736302771C80@mn-ex02.mn.bench.com>

Linuxbios_c, from the build directory, can be sucked into Sourcepoint to
extract the symbols. This allows the disassembled instructions to
display the symbols inline. It makes it easier to set breakpoints and
follow the code, but it's a far cry from source level debugging.  

I haven't attempted to link the source with sourcepoint yet. I may try
it later this week, let me know if you have any success.

Rod

-----Original Message-----
From: Kimball, Stephen 
Sent: Tuesday, October 19, 2004 3:33 PM
To: linuxbios at clustermatic.org
Subject: Makefile changes for symbols



Can someone give me the Makefile changes to make a LinuxBIOS with
symbols?  I tried adding "-gdwarf-2" to CFLAGS, but I'm not sure where
the unstripped output would be.  

Are there any features in the code that are useful in debugging
LinuxBIOS? Any defines that should change as well?

Someone must have some experience with source code level debugging of
LinuxBIOS with an American Arium ECM-50.  Thanks.

Steve Kimball
Benchmark Electronics
Hudson, NH 
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From yhlu at tyan.com  Wed Oct 20 11:58:00 2004
From: yhlu at tyan.com (Yinghai Lu)
Date: Wed Oct 20 11:58:00 2004
Subject: building Image with RTL8169 NIC
In-Reply-To: <4A3D5F6DC9406A4DBE93D9BA8F07E4BB22D6C5@cronos.trivium>
Message-ID: <200410201557.i9KFvAL03306@nwn.definitive.org>

Make bin/r8169.zelf
 
  _____  

From: linuxbios-admin at clustermatic.org
[mailto:linuxbios-admin at clustermatic.org] On Behalf Of Sagiv Yefet
Sent: Wednesday, October 20, 2004 1:55 AM
To: linuxbios at clustermatic.org
Subject: building Image with RTL8169 NIC
 
Hello,
 
I am trying to build IMAGE for Tyan 2850 with RTL8169 NIC.
 
Which driver supports this NIC?
 
Sagiv
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20041020/d237ae10/attachment.html>

From yhlu at tyan.com  Wed Oct 20 12:40:01 2004
From: yhlu at tyan.com (Yinghai Lu)
Date: Wed Oct 20 12:40:01 2004
Subject: FYI: Merge in progress...
In-Reply-To: <20041020125757.GB29045@openbios.org>
Message-ID: <200410201639.i9KGd0L03555@nwn.definitive.org>

Done.

-----Original Message-----
From: Stefan Reinauer [mailto:stepan at openbios.org] 
Sent: Wednesday, October 20, 2004 5:58 AM
To: YhLu
Cc: ebiederman at lnxi.com; Li-Ta Lo; 'Ronald G. Minnich'; 'LinuxBIOS'
Subject: Re: FYI: Merge in progress...

* YhLu <YhLu at tyan.com> [041020 07:13]:
> Just check in Tyan update to support new config.
 
Hey Yinghai!

It seems you forgot to commit the Options.lb files:

freebios2/src/mainboard/tyan/*/Options.lb

Currently config creation fails for all tyan boards complaining about
this file ..

    Stefan



From Stephen.Kimball at bench.com  Wed Oct 20 12:44:01 2004
From: Stephen.Kimball at bench.com (Stephen.Kimball at bench.com)
Date: Wed Oct 20 12:44:01 2004
Subject: Makefile changes for symbols
Message-ID: <9B124F08B3EFDA4F8813B05102DC719501A90266@nh-ex01.nh.bench.com>

The file under your target in normal/linuxbios_c.o seems to have all the
symbols if you add "-gdwarf-2" to the $CFLAGS in the Makefile.  Then
when you open the first C module the SourcePoint software asks where the
file exists, after you tell SourcePoint it seems to find the rest by
itself.  I recreated the same Linux directory structure on Windows.
Thanks Rod!

Steve  

-----Original Message-----
From: Kittleson, Rodney C. 
Sent: Wednesday, October 20, 2004 11:47 AM
To: Kimball, Stephen; linuxbios at clustermatic.org
Subject: RE: Makefile changes for symbols

Linuxbios_c, from the build directory, can be sucked into Sourcepoint to
extract the symbols. This allows the disassembled instructions to
display the symbols inline. It makes it easier to set breakpoints and
follow the code, but it's a far cry from source level debugging.  

I haven't attempted to link the source with sourcepoint yet. I may try
it later this week, let me know if you have any success.

Rod

-----Original Message-----
From: Kimball, Stephen 
Sent: Tuesday, October 19, 2004 3:33 PM
To: linuxbios at clustermatic.org
Subject: Makefile changes for symbols



Can someone give me the Makefile changes to make a LinuxBIOS with
symbols?  I tried adding "-gdwarf-2" to CFLAGS, but I'm not sure where
the unstripped output would be.  

Are there any features in the code that are useful in debugging
LinuxBIOS? Any defines that should change as well?

Someone must have some experience with source code level debugging of
LinuxBIOS with an American Arium ECM-50.  Thanks.

Steve Kimball
Benchmark Electronics
Hudson, NH 
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From YhLu at tyan.com  Wed Oct 20 12:56:01 2004
From: YhLu at tyan.com (YhLu)
Date: Wed Oct 20 12:56:01 2004
Subject: FYI: Merge in progress...
Message-ID: <3174569B9743D511922F00A0C94314230665B378@TYANWEB>

I want to do some change to coherent_ht.c, otherwise s2885 can not be
compiled under Loglevel = 8

diff -r freebios2/src/northbridge/amd/amdk8/coherent_ht.c
../freebios2/src/northbridge/amd/amdk8/coherent_ht.c
369a370
> #if 1
377a379
> #endif
394c396
<       
---
> #if 1 
418a421
> #endif
456,457c459,460
<       print_debug_hex8(result.cpus);
<       print_debug(" nodes initialized.\r\n");
---
>       print_spew_hex8(result.cpus);
>       print_spew(" nodes initialized.\r\n");
511c514
<       print_debug("coherent_ht_finalize\r\n");
---
>       print_spew("coherent_ht_finalize\r\n");
539a543
> #if 0
540a545
> #endif
548c553
<       print_debug("done\r\n");
---
>       print_spew("done\r\n");

-----Original Message-----
From: YhLu 
Sent: Wednesday, October 20, 2004 11:00 AM
To: 'Stefan Reinauer'
Cc: ebiederman at lnxi.com; 'Li-Ta Lo'; 'Ronald G. Minnich'; 'LinuxBIOS'
Subject: RE: FYI: Merge in progress...

Done.

-----Original Message-----
From: Stefan Reinauer [mailto:stepan at openbios.org] 
Sent: Wednesday, October 20, 2004 5:58 AM
To: YhLu
Cc: ebiederman at lnxi.com; Li-Ta Lo; 'Ronald G. Minnich'; 'LinuxBIOS'
Subject: Re: FYI: Merge in progress...

* YhLu <YhLu at tyan.com> [041020 07:13]:
> Just check in Tyan update to support new config.
 
Hey Yinghai!

It seems you forgot to commit the Options.lb files:

freebios2/src/mainboard/tyan/*/Options.lb

Currently config creation fails for all tyan boards complaining about
this file ..

    Stefan

_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From ebiederman at lnxi.com  Wed Oct 20 14:31:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed Oct 20 14:31:00 2004
Subject: FYI: Merge in progress...
In-Reply-To: <3174569B9743D511922F00A0C94314230665B33E@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B33E@TYANWEB>
Message-ID: <m3vfd52mpp.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> Why enable cache in amd_early_mtrr_init?

Usually that is a speed up.  I think all I changed was using the C implementation.
Previously the assembly was called from Config.lb.

> That causes CPU sleep 5s again.

That is peculiar.  
 
> After get rid of that, the new auto.c stage still cost more 1s than the code
> two weeks ago.

Hmm.  

This is certainly worth fixing.  And it tends to explain why I have
not yet seen the 5s speed up.

Eric


From YhLu at tyan.com  Wed Oct 20 14:37:01 2004
From: YhLu at tyan.com (YhLu)
Date: Wed Oct 20 14:37:01 2004
Subject: FYI: Merge in progress...
Message-ID: <3174569B9743D511922F00A0C94314230665B38B@TYANWEB>

Comment out disable_cache and enabe_cache in amd_early_mtrr_init you will
get 5s speed up.

I checked old amd_early_mtrr.inc, it seems it only has enable cache, but no
wbinvd.

Regards

YH

-----Original Message-----
From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
Sent: Wednesday, October 20, 2004 12:50 PM
To: YhLu
Cc: Li-Ta Lo; 'Ronald G. Minnich'; 'LinuxBIOS'
Subject: Re: FYI: Merge in progress...

YhLu <YhLu at tyan.com> writes:

> Why enable cache in amd_early_mtrr_init?

Usually that is a speed up.  I think all I changed was using the C
implementation.
Previously the assembly was called from Config.lb.

> That causes CPU sleep 5s again.

That is peculiar.  
 
> After get rid of that, the new auto.c stage still cost more 1s than the
code
> two weeks ago.

Hmm.  

This is certainly worth fixing.  And it tends to explain why I have
not yet seen the 5s speed up.

Eric


From rminnich at lanl.gov  Wed Oct 20 14:45:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Wed Oct 20 14:45:01 2004
Subject: Makefile changes for symbols
In-Reply-To: <9B124F08B3EFDA4F8813B05102DC719501A90264@nh-ex01.nh.bench.com>
References: <9B124F08B3EFDA4F8813B05102DC719501A90264@nh-ex01.nh.bench.com>
Message-ID: <Pine.LNX.4.58.0410201404230.10087@linux.site>


On Wed, 20 Oct 2004 Stephen.Kimball at bench.com wrote:

> Is LinuxBIOS development done with only serial port debug messages?

in the early days, we had an ICE. But for the last 4 years, it's all 
serial debug. 

> You guys are good.

You've very kind. We've got a lot of very smart people all over the world
on this project, and they're all pretty amazing.

ron


From ebiederman at lnxi.com  Wed Oct 20 15:25:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed Oct 20 15:25:01 2004
Subject: FYI: Merge in progress...
In-Reply-To: <3174569B9743D511922F00A0C94314230665B38B@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B38B@TYANWEB>
Message-ID: <m3ekjtw22f.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> Comment out disable_cache and enabe_cache in amd_early_mtrr_init you will
> get 5s speed up.
> 
> I checked old amd_early_mtrr.inc, it seems it only has enable cache, but no
> wbinvd.

Right.  At the time I had no clue invalidates were a problem.

I have just removed the wbinvd, it was just there for good measure.

Eric


From YhLu at tyan.com  Wed Oct 20 15:40:01 2004
From: YhLu at tyan.com (YhLu)
Date: Wed Oct 20 15:40:01 2004
Subject: FYI: Merge in progress...
Message-ID: <3174569B9743D511922F00A0C94314230665B39A@TYANWEB>

You still need wbinvd in disable_cache. It is called by raminit.c and
without it the mem can not init properly.

The amd_early_mtrr_init
 Only call do_early_mtrr_init
But that doesn't include

        /* Enable the access to AMD RdDram and WrDram extension bits */
        msr = rdmsr(SYSCFG_MSR);
        msr.lo |= SYSCFG_MSR_MtrrFixDramModEn;
        wrmsr(SYSCFG_MSR, msr);

....
        /* Disable the access to AMD RdDram and WrDram extension bits */
        msr = rdmsr(SYSCFG_MSR);
        msr.lo &= ~SYSCFG_MSR_MtrrFixDramModEn;
        wrmsr(SYSCFG_MSR, msr);


Also 

        /* Enable caching for 0 - 1MB using variable mtrr */
        msr = rdmsr(0x200);
        msr.hi &= 0xfffffff0; 
        msr.hi |= 0x00000000;
        msr.lo &= 0x00000f00; 
        msr.lo |= 0x00000000 | MTRR_TYPE_WRBACK;
        wrmsr(0x200, msr);
                
        msr = rdmsr(0x201);
        msr.hi &= 0xfffffff0;
        msr.hi |= 0x0000000f;
        msr.lo &= 0x000007ff;
        msr.lo |= (~((CONFIG_LB_MEM_TOPK << 10) - 1)) | 0x800;
        wrmsr(0x201, msr);

regards

YH
-----Original Message-----
From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
Sent: Wednesday, October 20, 2004 1:46 PM
To: YhLu
Cc: Li-Ta Lo; 'Ronald G. Minnich'; 'LinuxBIOS'
Subject: Re: FYI: Merge in progress...

YhLu <YhLu at tyan.com> writes:

> Comment out disable_cache and enabe_cache in amd_early_mtrr_init you will
> get 5s speed up.
> 
> I checked old amd_early_mtrr.inc, it seems it only has enable cache, but
no
> wbinvd.

Right.  At the time I had no clue invalidates were a problem.

I have just removed the wbinvd, it was just there for good measure.

Eric


From YhLu at tyan.com  Wed Oct 20 16:04:00 2004
From: YhLu at tyan.com (YhLu)
Date: Wed Oct 20 16:04:00 2004
Subject: FYI: Merge in progress...
Message-ID: <3174569B9743D511922F00A0C94314230665B3A1@TYANWEB>

Amd_early_mtrr.c

#ifndef AMD_EARLYMTRR_C
#define AMD_EARLYMTRR_C
#include <cpu/x86/mtrr.h>
#include <cpu/amd/mtrr.h>
#include "cpu/x86/mtrr/earlymtrr.c"

static void amd_early_mtrr_init(void)
{
        static const unsigned long mtrr_msrs[] = {
                /* fixed mtrr */
                0x250, 0x258, 0x259,
                0x268, 0x269, 0x26A,
                0x26B, 0x26C, 0x26D,
                0x26E, 0x26F,
                /* var mtrr */
                0x200, 0x201, 0x202, 0x203,
                0x204, 0x205, 0x206, 0x207,
                0x208, 0x209, 0x20A, 0x20B,
                0x20C, 0x20D, 0x20E, 0x20F,
                /* var iorr msr */
                0xC0010016, 0xC0010017, 0xC0010018, 0xC0010019,
                /* mem top */
                0xC001001A, 0xC001001D,
                /* NULL end of table */
                0
        };
        msr_t msr;
        const unsigned long *msr_addr;

        /* Enable the access to AMD RdDram and WrDram extension bits */
        msr = rdmsr(SYSCFG_MSR);
        msr.lo |= SYSCFG_MSR_MtrrFixDramModEn;
        wrmsr(SYSCFG_MSR, msr);

        /* Inialize all of the relevant msrs to 0 */
        msr.lo = 0;
        msr.hi = 0;

        for (msr_addr = mtrr_msrs; *msr_addr; msr_addr++) {
                wrmsr(*msr_addr, msr);
        }

        /* Disable the access to AMD RdDram and WrDram extension bits */
        msr = rdmsr(SYSCFG_MSR);
        msr.lo &= ~SYSCFG_MSR_MtrrFixDramModEn;
        wrmsr(SYSCFG_MSR, msr);

        /* Enable memory access for 0 - 1MB using top_mem */
        msr.hi = 0;
        msr.lo = ((CONFIG_LB_MEM_TOPK << 10) + TOP_MEM_MASK) &
~TOP_MEM_MASK;
        wrmsr(TOP_MEM, msr);

        /* Enable caching for 0 - 1MB using variable mtrr */
        set_var_mtrr(0, 0, (CONFIG_LB_MEM_TOPK << 10), MTRR_TYPE_WRBACK);

#if defined(XIP_ROM_SIZE)
        /* enable write through caching so we can do execute in place
         * on the flash rom.
         */
        set_var_mtrr(1, XIP_ROM_BASE, XIP_ROM_SIZE, MTRR_TYPE_WRBACK);
#endif

        /* Set the default memory type and enable fixed and variable MTRRs 
         */
        /* Enable Variable MTRRs */
        msr.hi = 0x00000000;
        msr.lo = 0x00000800;
        wrmsr(MTRRdefType_MSR, msr);

        /* Enale the MTRRs in SYSCFG */
        msr = rdmsr(SYSCFG_MSR);
        msr.lo |= SYSCFG_MSR_MtrrVarDramEn;
        wrmsr(SYSCFG_MSR, msr);

        /* Enable the cache */
        enable_cache();
}

#endif /* AMD_EARLYMTRR_C */


From stepan at openbios.org  Wed Oct 20 16:26:01 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Wed Oct 20 16:26:01 2004
Subject: FYI: Merge in progress...
In-Reply-To: <3174569B9743D511922F00A0C94314230665B378@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B378@TYANWEB>
Message-ID: <20041020214635.GA9118@openbios.org>

* YhLu <YhLu at tyan.com> [041020 20:20]:
> I want to do some change to coherent_ht.c, otherwise s2885 can not be
> compiled under Loglevel = 8
> 
> <       print_debug_hex8(result.cpus);
> <       print_debug(" nodes initialized.\r\n");
> ---
> >       print_spew_hex8(result.cpus);
> >       print_spew(" nodes initialized.\r\n");

Printing the number of CPUs found by cht init is not really "spewing". 

Time to look at CAR again? ;-) (don't hit me) - Last state was that it
worked fine on UP systems but did not on SMP. Did anybody analyze this
with a HDT?

Stefan


From YhLu at tyan.com  Wed Oct 20 16:56:01 2004
From: YhLu at tyan.com (YhLu)
Date: Wed Oct 20 16:56:01 2004
Subject: FYI: Merge in progress...
Message-ID: <3174569B9743D511922F00A0C94314230665B3AC@TYANWEB>

If the romcc support the function instead using of all inline. It will be
very small.

Current auto.c ---> part before c_start is near 30K.

Regards

YH

-----Original Message-----
From: Stefan Reinauer [mailto:stepan at openbios.org] 
Sent: Wednesday, October 20, 2004 2:47 PM
To: YhLu
Cc: 'LinuxBIOS'
Subject: Re: FYI: Merge in progress...

* YhLu <YhLu at tyan.com> [041020 20:20]:
> I want to do some change to coherent_ht.c, otherwise s2885 can not be
> compiled under Loglevel = 8
> 
> <       print_debug_hex8(result.cpus);
> <       print_debug(" nodes initialized.\r\n");
> ---
> >       print_spew_hex8(result.cpus);
> >       print_spew(" nodes initialized.\r\n");

Printing the number of CPUs found by cht init is not really "spewing". 

Time to look at CAR again? ;-) (don't hit me) - Last state was that it
worked fine on UP systems but did not on SMP. Did anybody analyze this
with a HDT?

Stefan


From rminnich at lanl.gov  Wed Oct 20 17:01:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Wed Oct 20 17:01:01 2004
Subject: FYI: Merge in progress...
In-Reply-To: <3174569B9743D511922F00A0C94314230665B3AC@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B3AC@TYANWEB>
Message-ID: <Pine.LNX.4.58.0410201621290.10087@linux.site>


On Wed, 20 Oct 2004, YhLu wrote:

> If the romcc support the function instead using of all inline. It will be
> very small.

that's why we need cache-as-ram :-)

ron


From ollie at lanl.gov  Wed Oct 20 17:11:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Wed Oct 20 17:11:01 2004
Subject: FYI: Merge in progress...
In-Reply-To: <3174569B9743D511922F00A0C94314230665B3AC@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B3AC@TYANWEB>
Message-ID: <1098311509.15883.31.camel@exponential.lanl.gov>

On Wed, 2004-10-20 at 16:20, YhLu wrote:
> If the romcc support the function instead using of all inline. It will be
> very small.
> 
> Current auto.c ---> part before c_start is near 30K.
> 
> Regards
> 
> YH
> 
> -----Original Message-----
> From: Stefan Reinauer [mailto:stepan at openbios.org] 
> Sent: Wednesday, October 20, 2004 2:47 PM
> To: YhLu
> Cc: 'LinuxBIOS'
> Subject: Re: FYI: Merge in progress...
> Printing the number of CPUs found by cht init is not really "spewing". 
> 
> Time to look at CAR again? ;-) (don't hit me) - Last state was that it
> worked fine on UP systems but did not on SMP. Did anybody analyze this
> with a HDT?
> 

The HDT I used can't do that. Actually, the HDT lost track of everything
after the ht_reset in auto.c.

We purchased a hardware debugger from American Arium but we never have
time to setup.

Ollie




From rminnich at lanl.gov  Wed Oct 20 17:15:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Wed Oct 20 17:15:00 2004
Subject: FYI: Merge in progress...
In-Reply-To: <20041020214635.GA9118@openbios.org>
References: <3174569B9743D511922F00A0C94314230665B378@TYANWEB>
 <20041020214635.GA9118@openbios.org>
Message-ID: <Pine.LNX.4.58.0410201635050.10087@linux.site>


On Wed, 20 Oct 2004, Stefan Reinauer wrote:

> Time to look at CAR again? ;-) (don't hit me) - Last state was that it
> worked fine on UP systems but did not on SMP. Did anybody analyze this
> with a HDT?

Ollie is discussing it with some people.

ron


From ollie at lanl.gov  Wed Oct 20 17:27:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Wed Oct 20 17:27:01 2004
Subject: FYI: Merge in progress...
In-Reply-To: <Pine.LNX.4.58.0410201635050.10087@linux.site>
References: <3174569B9743D511922F00A0C94314230665B378@TYANWEB>
	 <20041020214635.GA9118@openbios.org>
	 <Pine.LNX.4.58.0410201635050.10087@linux.site>
Message-ID: <1098312458.15883.33.camel@exponential.lanl.gov>

On Wed, 2004-10-20 at 16:35, Ronald G. Minnich wrote:
> On Wed, 20 Oct 2004, Stefan Reinauer wrote:
> 
> > Time to look at CAR again? ;-) (don't hit me) - Last state was that it
> > worked fine on UP systems but did not on SMP. Did anybody analyze this
> > with a HDT?
> 
> Ollie is discussing it with some people.
> 

But I haven't heard anything from them for a LOOONG time :-(

Ollie

> ron
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 



From rsmith at bitworks.com  Wed Oct 20 19:04:01 2004
From: rsmith at bitworks.com (Richard Smith)
Date: Wed Oct 20 19:04:01 2004
Subject: FYI: Merge in progress...
In-Reply-To: <1098311509.15883.31.camel@exponential.lanl.gov>
References: <3174569B9743D511922F00A0C94314230665B3AC@TYANWEB> <1098311509.15883.31.camel@exponential.lanl.gov>
Message-ID: <417701CD.50407@bitworks.com>

Li-Ta Lo wrote:

> The HDT I used can't do that. Actually, the HDT lost track of everything
> after the ht_reset in auto.c.
> 
> We purchased a hardware debugger from American Arium but we never have
> time to setup.
> 

Dude, send that puppy to me then.  I'll use it. *grin*

-- 
Richard A. Smith




From YhLu at tyan.com  Wed Oct 20 20:35:00 2004
From: YhLu at tyan.com (YhLu)
Date: Wed Oct 20 20:35:00 2004
Subject: FYI: Merge in progress... -- amd8111 enable_dev better suppor
	t
Message-ID: <3174569B9743D511922F00A0C94314230665B3D6@TYANWEB>

Just commit amd8111_better support

Comment some line in amd8111/Config.lb
Also reenable disable USB2 in amd8111.

Regards

YH


From ebiederman at lnxi.com  Wed Oct 20 21:52:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed Oct 20 21:52:01 2004
Subject: FYI: Merge in progress...
In-Reply-To: <3174569B9743D511922F00A0C94314230665B3A1@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B3A1@TYANWEB>
Message-ID: <m3lle0lr3q.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> Amd_early_mtrr.c

Ok. I will agree that disable_cache in amd_early_mtrr is overkill
and remove that.  Since the wbinvd seems to be necessary in the
general disable_cache case.

I am leery about not reusing code between the various versions
of mtrr setup because that causes behaviour skew.

It actually is not appropriate to enable cache of memory until
we have enabled it.  You don't see that on an Opteron but
it is trivial to see on a Xeon, and that has been a bug that
has been waiting to hit us for a while.  CPU prefetch units
can cause amazing problems.

As for messing with RdDram and WrDram extension bits we are not
using the fixed mtrrs at this point and I fee that is better
a question left up cpu initialization code to handle later.
Hmm.  We don't actually handle it later either so I have just
added that code, there.    That way everything should be all in
one place.

Thanks for the code review.

Eric


From ebiederman at lnxi.com  Wed Oct 20 22:02:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed Oct 20 22:02:01 2004
Subject: FYI: Merge in progress...
In-Reply-To: <20041020214635.GA9118@openbios.org>
References: <3174569B9743D511922F00A0C94314230665B378@TYANWEB>
	<20041020214635.GA9118@openbios.org>
Message-ID: <m3y8i0eovh.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at openbios.org> writes:

> * YhLu <YhLu at tyan.com> [041020 20:20]:
> > I want to do some change to coherent_ht.c, otherwise s2885 can not be
> > compiled under Loglevel = 8
> > 
> > <       print_debug_hex8(result.cpus);
> > <       print_debug(" nodes initialized.\r\n");
> > ---
> > >       print_spew_hex8(result.cpus);
> > >       print_spew(" nodes initialized.\r\n");
> 
> Printing the number of CPUs found by cht init is not really "spewing". 

I would agree.
 
> Time to look at CAR again? ;-) (don't hit me) - Last state was that it
> worked fine on UP systems but did not on SMP. Did anybody analyze this
> with a HDT?

Either that or to improve romcc.  Right now everything works well
enough that things are just tight but not quite deadly.  
So I am proceeding forward on other cleanup issues.

Once the code base generally works again.  We need to look at
the handling of irqs.  About then is when I am likely to be open
to ideas.

I managed to shave off 500bytes just by no longer including console.inc

Eric


From liutao at safe-mail.net  Thu Oct 21 02:43:00 2004
From: liutao at safe-mail.net (Liu Tao)
Date: Thu Oct 21 02:43:00 2004
Subject: Does linux kernel parse linuxbios table?
Message-ID: <41776DAD.20903@safe-mail.net>

Hello Eric,

   I searched the linux kernel mail archive and found your
patch for x86 boot linuxbios support, but I didn't find the
linuxbios table parse code in linux-2.6.8.1, does linux kernel
still parse the linuxbios table now?

Regards,
Liu Tao


From ebiederman at lnxi.com  Thu Oct 21 05:31:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Oct 21 05:31:01 2004
Subject: Does linux kernel parse linuxbios table?
In-Reply-To: <41776DAD.20903@safe-mail.net>
References: <41776DAD.20903@safe-mail.net>
Message-ID: <m3d5zc8hsy.fsf@maxwell.lnxi.com>

Liu Tao <liutao at safe-mail.net> writes:

> Hello Eric,
> 
>    I searched the linux kernel mail archive and found your
> patch for x86 boot linuxbios support, but I didn't find the
> linuxbios table parse code in linux-2.6.8.1, does linux kernel
> still parse the linuxbios table now?

Not currently.  When I originally introduced the table I could not
get my patch in.  At the moment mkelfImage just digest the table
and feeds Linux what it is expecting.

A bit of hack but a pragmatic solution for now.

Eric


From ebiederman at lnxi.com  Thu Oct 21 05:39:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Oct 21 05:39:00 2004
Subject: hanging 'Setting fixed MTRRs' 810lmr
In-Reply-To: <20041019211944.GA417@murgott.de>
References: <20041019211944.GA417@murgott.de>
Message-ID: <m38ya08hh0.fsf@maxwell.lnxi.com>

Christof Murgott <cm-lists at murgott.de> writes:

> Hi,
> 
> I've downloaded the linuxbios source via CVS and the 2.4.19 from
> ftp.kernel.org, built everything as Antony Stone has explained in this
> howto[1]. However, the computer (PCCHIPS 810lmr) stalls with the
> following output on the serial console:
> 
> LinuxBIOS-1.0.0 Mon Aug 30 09:03:42 CEST 2004 starting...
> Copying LinuxBIOS to ram.
> Jumping to LinuxBIOS.
> POST: 0x39
> LinuxBIOS-1.0.0 Mon Aug 30 09:03:42 CEST 2004 booting...
> POST: 0x40
> Finding PCI configuration type.
> PCI: Using configuration type 1
> POST: 0x5f
> handle_superio start, nsuperio 1
> handle_superio: Pass 0, check #0, s 0000bf40 s->super 0000c218
> handle_superio: Pass 0, Superio SiS 950
> handle_superio:  port 0x0, defaultport 0x2e
> handle_superio:  Using port 0x2e
> handle_superio: Pass 0, done #0
> handle_superio done
> Scanning PCI bus...PCI: pci_scan_bus for bus 0
> POST: 0x24
> PCI: 00:00.0 [1039/0730]
> PCI: 00:00.1 [1039/5513]
> PCI: 00:01.0 [1039/0008]
> PCI: 00:01.4 [1039/7018]
> PCI: 00:02.0 [1039/0001]
> POST: 0x25
> PCI: pci_scan_bus for bus 1
> POST: 0x24
> PCI: 01:00.0 [1039/6300]
> POST: 0x25
> PCI: pci_scan_bus returning with max=01
> POST: 0x55
> PCI: pci_scan_bus returning with max=01
> POST: 0x55
> done
> POST: 0x66
> Allocating PCI resources...
> ASSIGN RESOURCES, bus 0
> PCI: 00:00.0 10 <- [0xf8000000 - 0xfbffffff] mem
> PCI: 00:00.1 10 <- [0x00002410 - 0x00002413] io
> PCI: 00:00.1 14 <- [0x00002420 - 0x00002423] io
> PCI: 00:00.1 18 <- [0x00002430 - 0x00002433] io
> PCI: 00:00.1 1c <- [0x00002440 - 0x00002443] io
> PCI: 00:00.1 20 <- [0x00002400 - 0x0000240f] io
> PCI: 00:01.4 10 <- [0x00002000 - 0x000020ff] io
> PCI: 00:01.4 14 <- [0xfc100000 - 0xfc100fff] mem
> PCI: 00:02.0 1c <- [0x00001000 - 0x00001fff] bus 1 io
> PCI: 00:02.0 24 <- [0xf0000000 - 0xf7ffffff] bus 1 prefmem
> PCI: 00:02.0 20 <- [0xfc000000 - 0xfc0fffff] bus 1 mem
> ASSIGN RESOURCES, bus 1
> PCI: 01:00.0 10 <- [0xf0000000 - 0xf7ffffff] prefmem
> PCI: 01:00.0 14 <- [0xfc000000 - 0xfc01ffff] mem
> PCI: 01:00.0 18 <- [0x00001000 - 0x0000107f] io
> ASSIGNED RESOURCES, bus 1
> ASSIGNED RESOURCES, bus 0
> Allocating VGA resource
> done.
> POST: 0x88
> Enabling PCI resourcess...PCI: 00:00.0 cmd <- 07
> PCI: 00:00.1 cmd <- 01
> PCI: 00:01.0 cmd <- 0c
> PCI: 00:01.4 cmd <- 03
> PCI: 00:02.0 cmd <- 27
> PCI: 01:00.0 cmd <- 03
> done.
> Initializing PCI devices...
> PCI devices initialized
> POST: 0x89
> POST: 0x70
> totalram: 248M
> Initializing CPU #0
> POST: 0x60
> Enabling cache...
> Setting fixed MTRRs(0-42647) type: UC
> 
> I can't do anything with it. So I searched the mailinglist archive and
> found a patch[2] from Andrew Ip. But nothing changed!

Hmm.  It looks like memory is not being initialized properly.
That is usually the problem when the system dies right after
the cache has been disabled.  

It looks like the system was simply running out of the cache.


Eric


From ebiederman at lnxi.com  Thu Oct 21 06:32:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Oct 21 06:32:01 2004
Subject: Freebios2 recovery progress...
Message-ID: <m34qko8h2k.fsf@maxwell.lnxi.com>

I have managed to get another chunk of merging and bug fixing
done tonight.

I now have pci subsystem vendor and subsystem id's being set on
the arima hdama, so the board is now identifiable with lspci.

I have bumped the LinuxBIOS minor version so we can track
these changes.

All of the superio chips should not work or at least be very close
except the weird via superio/pci hybrid that I could not make sense
of.

I have changed all of the references to chip_control to chip_operations.
And fixed up the usage while I was in the neighborhood if I could clearly
see what the fix should be.  So Config.lb for most of the Opteron ports
should work, or at least be very close now.

It is time for me to break off and head home.

Eric



From spirit at reactor.ru  Thu Oct 21 06:48:01 2004
From: spirit at reactor.ru (Alexander Amelkin)
Date: Thu Oct 21 06:48:01 2004
Subject: M789 power loss restart - the solution is very easy!
In-Reply-To: <1199828372.20041017202450@amelkin.msk.ru>
References: <1199828372.20041017202450@amelkin.msk.ru>
Message-ID: <42247797.20041021160827@amelkin.msk.ru>

Hi all!

  I think, this can be put onto the FAQ.

  I found the solution that works for M789 and is very easy and cheap.
  It also must be a universal solution, helping to power-up any ATX
  motherboard on power up of the PSU.

  Just take a small capacitor (i used a 2uF one) and put it in
  parallel with the standard power button on your case. Or just
  connect the capacitor to the PWR BTN header on the motherboard.

  This is much easier and cheaper than using any digital solution
  (with a counter IC or anything). The principle behind my solution is
  that upon powering up the PSU, the 5VSB line becomes high on the
  motherboard. That line powers the circuitry needed to react to the
  power button. Additionally, voltage appears on one of the pins of
  the PWR BTN header on the mobo (the other pin is ground). So, when
  there is a capacitor between the pins, it starts charging. That
  looks like a short circuit to the mobo. It boots up. The capacitor
  becomes fully charged and it starts looking like an open circuit to
  the motherboard. The capacitor is never discharged while the mobo is
  powered and is discharged quickly after the power is removed.
  Additionally, the functionality of the power button is preserved -
  you can still push it to turn the PC off.

  In other words, the capacitor is equal to "AC Power Loss restart:
  Always On" setting in the BIOS.

WBR, Alexander                          mailto:spirit at reactor.ru



From ollie at lanl.gov  Thu Oct 21 09:09:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu Oct 21 09:09:01 2004
Subject: FYI: Merge in progress...
In-Reply-To: <m3lle0lr3q.fsf@maxwell.lnxi.com>
References: <3174569B9743D511922F00A0C94314230665B3A1@TYANWEB>
	 <m3lle0lr3q.fsf@maxwell.lnxi.com>
Message-ID: <1098368973.15883.39.camel@exponential.lanl.gov>

On Wed, 2004-10-20 at 20:52, Eric W. Biederman wrote:
> As for messing with RdDram and WrDram extension bits we are not
> using the fixed mtrrs at this point and I fee that is better
> a question left up cpu initialization code to handle later.
> Hmm.  We don't actually handle it later either so I have just
> added that code, there.    That way everything should be all in
> one place.
> 

I have done that but you removed they ALL in your new CPU thing.
It was there for reasons, we need the RdDRAM/WrDram programmed
correct for VGA devices.

Ollie




From ollie at lanl.gov  Thu Oct 21 11:10:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu Oct 21 11:10:00 2004
Subject: Freebios2 recovery progress...
In-Reply-To: <m34qko8h2k.fsf@maxwell.lnxi.com>
References: <m34qko8h2k.fsf@maxwell.lnxi.com>
Message-ID: <1098376258.15883.46.camel@exponential.lanl.gov>

On Thu, 2004-10-21 at 05:08, Eric W. Biederman wrote:
> I have managed to get another chunk of merging and bug fixing
> done tonight.
> 
> I now have pci subsystem vendor and subsystem id's being set on
> the arima hdama, so the board is now identifiable with lspci.
> 

How did you do that ? Where do you put those IDs ?

Ollie




From YhLu at tyan.com  Thu Oct 21 11:36:01 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Oct 21 11:36:01 2004
Subject: Freebios2 recovery progress...
Message-ID: <3174569B9743D511922F00A0C94314230665B3E4@TYANWEB>

You changes all mb config for AMD/Iwill/IBM....that took some time.

If there is on board scsi, I want to set subsystem id, I need to put that in
Config.lb?


YH

-----Original Message-----
From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
Sent: Thursday, October 21, 2004 4:08 AM
To: LinuxBIOS
Subject: Freebios2 recovery progress...

I have managed to get another chunk of merging and bug fixing
done tonight.

I now have pci subsystem vendor and subsystem id's being set on
the arima hdama, so the board is now identifiable with lspci.

I have bumped the LinuxBIOS minor version so we can track
these changes.

All of the superio chips should not work or at least be very close
except the weird via superio/pci hybrid that I could not make sense
of.

I have changed all of the references to chip_control to chip_operations.
And fixed up the usage while I was in the neighborhood if I could clearly
see what the fix should be.  So Config.lb for most of the Opteron ports
should work, or at least be very close now.

It is time for me to break off and head home.

Eric

_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From YhLu at tyan.com  Thu Oct 21 11:59:00 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Oct 21 11:59:00 2004
Subject: Freebios2 recovery progress...
Message-ID: <3174569B9743D511922F00A0C94314230665B3E9@TYANWEB>

Driver add 
< static void lpci_set_subsystem(device_t dev, unsigned vendor, unsigned
device)
< {
<       pci_write_config32(dev, 0x2c, 
<               ((device & 0xffff) << 16) | (vendor & 0xffff));
< }
< 
< static struct pci_operations lops_pci = {
<       .set_subsystem = lpci_set_subsystem,
< };


-----Original Message-----
From: Li-Ta Lo [mailto:ollie at lanl.gov] 
Sent: Thursday, October 21, 2004 9:31 AM
To: Eric W. Biederman
Cc: LinuxBIOS
Subject: Re: Freebios2 recovery progress...

On Thu, 2004-10-21 at 05:08, Eric W. Biederman wrote:
> I have managed to get another chunk of merging and bug fixing
> done tonight.
> 
> I now have pci subsystem vendor and subsystem id's being set on
> the arima hdama, so the board is now identifiable with lspci.
> 

How did you do that ? Where do you put those IDs ?

Ollie


_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From ollie at lanl.gov  Thu Oct 21 12:07:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu Oct 21 12:07:01 2004
Subject: Freebios2 recovery progress...
In-Reply-To: <3174569B9743D511922F00A0C94314230665B3E9@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B3E9@TYANWEB>
Message-ID: <1098379676.15883.58.camel@exponential.lanl.gov>

On Thu, 2004-10-21 at 11:23, YhLu wrote:

Are the IDs configurable by config file ?

Ollie

> Driver add 
> < static void lpci_set_subsystem(device_t dev, unsigned vendor, unsigned
> device)
> < {
> <       pci_write_config32(dev, 0x2c, 
> <               ((device & 0xffff) << 16) | (vendor & 0xffff));
> < }
> < 
> < static struct pci_operations lops_pci = {
> <       .set_subsystem = lpci_set_subsystem,
> < };
> 
> 
> -----Original Message-----
> From: Li-Ta Lo [mailto:ollie at lanl.gov] 
> Sent: Thursday, October 21, 2004 9:31 AM
> To: Eric W. Biederman
> Cc: LinuxBIOS
> Subject: Re: Freebios2 recovery progress...
> 
> On Thu, 2004-10-21 at 05:08, Eric W. Biederman wrote:
> > I have managed to get another chunk of merging and bug fixing
> > done tonight.
> > 
> > I now have pci subsystem vendor and subsystem id's being set on
> > the arima hdama, so the board is now identifiable with lspci.
> > 
> 
> How did you do that ? Where do you put those IDs ?
> 
> Ollie
> 
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 



From ollie at lanl.gov  Thu Oct 21 12:23:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu Oct 21 12:23:00 2004
Subject: Freebios2 recovery progress...
In-Reply-To: <3174569B9743D511922F00A0C94314230665B3E9@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B3E9@TYANWEB>
Message-ID: <1098380621.15883.68.camel@exponential.lanl.gov>

On Thu, 2004-10-21 at 11:23, YhLu wrote:
> Driver add 
> < static void lpci_set_subsystem(device_t dev, unsigned vendor, unsigned
> device)
> < {
> <       pci_write_config32(dev, 0x2c, 
> <               ((device & 0xffff) << 16) | (vendor & 0xffff));
> < }
> < 
> < static struct pci_operations lops_pci = {
> <       .set_subsystem = lpci_set_subsystem,
> < };
> 
> 


OOPS, we are doing it with "uses MAINBOARD_SUBSYSTEM_ID" and if I am 
right every on board device share the same ID. For devices who want
its own ID it has to implement the .set_subsystem method. This is
really ugly. IMHO, we should treat the subsystem ids as attributes
of PCI device and it should be defined in the mainboard config file.
It should look like this

device pci 0.0 on
	vendor 0x1234
	device 0x5678
end

or

device pci 0.0 on
	register "subsystem_vendor_id" = "0x1234"
	register "subsystem_device_id" = "0x5678"
end

and the PCI enumeration code will call the generic
pci_set_subsystem() function to set subsystem ID for every
PCI device. For those device with subsystem ID unspecified,
it is default to zero any.

Ollie




From YhLu at tyan.com  Thu Oct 21 12:28:11 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Oct 21 12:28:11 2004
Subject: Freebios2 recovery progress...
Message-ID: <3174569B9743D511922F00A0C94314230665B3F2@TYANWEB>

Eric, 

You overwrite some lines in amd8131....

        /* We have to enable MEM and Bus Master for IOAPIC */
        value = pci_read_config32(dev, 0x4);
        value |= 6;
        pci_write_config32(dev, 0x4, value);

Regards

YH

static void ioapic_enable(device_t dev)
{       
        uint32_t value;
        
        value = pci_read_config32(dev, 0x44);
        if (dev->enabled) {
                value |= ((1 << 1) | (1 << 0));
        } else {
                value &= ~((1 << 1) | (1 << 0));
        }
        pci_write_config32(dev, 0x44, value);

        /* We have to enable MEM and Bus Master for IOAPIC */
        value = pci_read_config32(dev, 0x4);
        value |= 6;
        pci_write_config32(dev, 0x4, value);
}

-----Original Message-----
From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
Sent: Thursday, October 21, 2004 4:08 AM
To: LinuxBIOS
Subject: Freebios2 recovery progress...

I have managed to get another chunk of merging and bug fixing
done tonight.

I now have pci subsystem vendor and subsystem id's being set on
the arima hdama, so the board is now identifiable with lspci.

I have bumped the LinuxBIOS minor version so we can track
these changes.

All of the superio chips should not work or at least be very close
except the weird via superio/pci hybrid that I could not make sense
of.

I have changed all of the references to chip_control to chip_operations.
And fixed up the usage while I was in the neighborhood if I could clearly
see what the fix should be.  So Config.lb for most of the Opteron ports
should work, or at least be very close now.

It is time for me to break off and head home.

Eric

_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From ebiederman at lnxi.com  Thu Oct 21 12:47:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Oct 21 12:47:00 2004
Subject: FYI: Merge in progress...
In-Reply-To: <1098368973.15883.39.camel@exponential.lanl.gov>
References: <3174569B9743D511922F00A0C94314230665B3A1@TYANWEB>
	<m3lle0lr3q.fsf@maxwell.lnxi.com>
	<1098368973.15883.39.camel@exponential.lanl.gov>
Message-ID: <m3is94uf2i.fsf@maxwell.lnxi.com>

Li-Ta Lo <ollie at lanl.gov> writes:

> On Wed, 2004-10-20 at 20:52, Eric W. Biederman wrote:
> > As for messing with RdDram and WrDram extension bits we are not
> > using the fixed mtrrs at this point and I fee that is better
> > a question left up cpu initialization code to handle later.
> > Hmm.  We don't actually handle it later either so I have just
> > added that code, there.    That way everything should be all in
> > one place.
> > 
> 
> I have done that but you removed they ALL in your new CPU thing.
> It was there for reasons, we need the RdDRAM/WrDram programmed
> correct for VGA devices.

Oops it was a big re-org and I had not realized I had missed some
of the cpu development.  What it should have been was a lot
of code motion and a few cleanups in structure I did not intend 
to drop any functionality.  

I still need to get back in there and implement overlapping mtrrs.

At this point we should be able to look at the device tree and
see if we need to use and io range register or the RdRam WrDram bits.

Eric


From ebiederman at lnxi.com  Thu Oct 21 12:51:24 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Oct 21 12:51:24 2004
Subject: Freebios2 recovery progress...
In-Reply-To: <1098380621.15883.68.camel@exponential.lanl.gov>
References: <3174569B9743D511922F00A0C94314230665B3E9@TYANWEB>
	<1098380621.15883.68.camel@exponential.lanl.gov>
Message-ID: <m3mzyguf9p.fsf@maxwell.lnxi.com>

Li-Ta Lo <ollie at lanl.gov> writes:

> On Thu, 2004-10-21 at 11:23, YhLu wrote:
> > Driver add 
> > < static void lpci_set_subsystem(device_t dev, unsigned vendor, unsigned
> > device)
> > < {
> > <       pci_write_config32(dev, 0x2c, 
> > <               ((device & 0xffff) << 16) | (vendor & 0xffff));
> > < }
> > < 
> > < static struct pci_operations lops_pci = {
> > <       .set_subsystem = lpci_set_subsystem,
> > < };
> > 
> > 
> 
> 
> OOPS, we are doing it with "uses MAINBOARD_SUBSYSTEM_ID" and if I am 
> right every on board device share the same ID. For devices who want
> its own ID it has to implement the .set_subsystem method. This is
> really ugly. IMHO, we should treat the subsystem ids as attributes
> of PCI device and it should be defined in the mainboard config file.
> It should look like this

As far as I know there is only one that we need to set.
The subsystem id of the motherboard.  And we need to set
this for all devices.

The .set_subsystem simply exists because there is not
a standard way to set that value.  The almost generic
version is in src/devices/pci_device.c but I can use
it only occasionally.
 
> device pci 0.0 on
> 	vendor 0x1234
> 	device 0x5678
> end
> 
> or
> 
> device pci 0.0 on
> 	register "subsystem_vendor_id" = "0x1234"
> 	register "subsystem_device_id" = "0x5678"
> end

I don't see the benefit of those methods over having
an Option if you have exactly 1 subsystem vendor_id+device_id that
need to be set.

> and the PCI enumeration code will call the generic
> pci_set_subsystem() function to set subsystem ID for every
> PCI device.
It does.

>  For those device with subsystem ID unspecified,
> it is default to zero any.

Yes.

Eric


From ebiederman at lnxi.com  Thu Oct 21 12:54:10 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Oct 21 12:54:10 2004
Subject: Freebios2 recovery progress...
In-Reply-To: <3174569B9743D511922F00A0C94314230665B3E4@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B3E4@TYANWEB>
Message-ID: <m3fz48ynfl.fsf@maxwell.lnxi.com>

Li-Ta Lo <ollie at lanl.gov> writes:

> How did you do that ? Where do you put those IDs ?


YhLu <YhLu at tyan.com> writes:

> You changes all mb config for AMD/Iwill/IBM....that took some time.
> 
> If there is on board scsi, I want to set subsystem id, I need to put that in
> Config.lb?

Or more likely src/mainboarod/???/???/Options.lb

src/devices/pci_device.c:pci_dev_enable_resources()
calls dev->ops->pci_ops->set_subsystem() when the device 
dev->on_mainboard is true.  In turn config.g sets that
in static.c for all devices in the static tree.

I believe those are the correct semantics.  That the subsystem is
essentially an identifier for the board the chips are sitting on.

The values are come from:
Look at MAINBOARD_PCI_SUBSYSTEM_VENDOR_ID and MAINBOARD_SUBSYSTEM_DEVICE_ID.

So for the onboard scsi case you likely need to have a driver for
the onboard scsi device that implements the set_subsystem method
because there is not a generic way of doing that.

Eric


From ebiederman at lnxi.com  Thu Oct 21 12:57:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Oct 21 12:57:00 2004
Subject: Freebios2 recovery progress...
In-Reply-To: <3174569B9743D511922F00A0C94314230665B3F2@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B3F2@TYANWEB>
Message-ID: <m3r7nsq6rd.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> Eric, 
> 
> You overwrite some lines in amd8131....
> 
>         /* We have to enable MEM and Bus Master for IOAPIC */
>         value = pci_read_config32(dev, 0x4);
>         value |= 6;
>         pci_write_config32(dev, 0x4, value);

Yep.

But in src/devices/pci_device.c:pci_scan_bus I added:
		/* Architectural/System devices always need to
		 * be bus masters.
		 */
		if ((dev->class >> 16) == PCI_BASE_CLASS_SYSTEM) {
			dev->command |= PCI_COMMAND_MASTER;
		}

Which achieves the same thing in a generally less fragile way.
We still might have one or two devices that we need to hard code
the master command status for but this catches the general
case.

Basically system devices have well known interfaces so they are
likely to have a generic driver instead of a device specific driver.
So enabling them as bus masters looks safe and will fix all of
the cases I know about where this is needed.

And I checked and the bus master bit is still getting set on
the IOAPICs on the HDAMA.

But thanks good catch, this needed an explanation.

Did I mention I was just a little behind on merging my code? :)

Eric


From YhLu at tyan.com  Thu Oct 21 12:59:41 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Oct 21 12:59:41 2004
Subject: Freebios2 recovery progress...
Message-ID: <3174569B9743D511922F00A0C94314230665B3F8@TYANWEB>

I agree that all onboard device should use the same subsystem id as MB's.

Regards

YH

-----Original Message-----
From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
Sent: Thursday, October 21, 2004 10:46 AM
To: YhLu; Li-Ta Lo
Cc: LinuxBIOS
Subject: Re: Freebios2 recovery progress...

Li-Ta Lo <ollie at lanl.gov> writes:

> How did you do that ? Where do you put those IDs ?


YhLu <YhLu at tyan.com> writes:

> You changes all mb config for AMD/Iwill/IBM....that took some time.
> 
> If there is on board scsi, I want to set subsystem id, I need to put that
in
> Config.lb?

Or more likely src/mainboarod/???/???/Options.lb

src/devices/pci_device.c:pci_dev_enable_resources()
calls dev->ops->pci_ops->set_subsystem() when the device 
dev->on_mainboard is true.  In turn config.g sets that
in static.c for all devices in the static tree.

I believe those are the correct semantics.  That the subsystem is
essentially an identifier for the board the chips are sitting on.

The values are come from:
Look at MAINBOARD_PCI_SUBSYSTEM_VENDOR_ID and MAINBOARD_SUBSYSTEM_DEVICE_ID.

So for the onboard scsi case you likely need to have a driver for
the onboard scsi device that implements the set_subsystem method
because there is not a generic way of doing that.

Eric


From YhLu at tyan.com  Thu Oct 21 13:02:28 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Oct 21 13:02:28 2004
Subject: Freebios2 recovery progress...
Message-ID: <3174569B9743D511922F00A0C94314230665B3FA@TYANWEB>

You may remove
.enable           = amd8111_enable,

It will be called twice. One in enable_dev.

-----Original Message-----
From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
Sent: Thursday, October 21, 2004 10:46 AM
To: YhLu; Li-Ta Lo
Cc: LinuxBIOS
Subject: Re: Freebios2 recovery progress...

Li-Ta Lo <ollie at lanl.gov> writes:

> How did you do that ? Where do you put those IDs ?


YhLu <YhLu at tyan.com> writes:

> You changes all mb config for AMD/Iwill/IBM....that took some time.
> 
> If there is on board scsi, I want to set subsystem id, I need to put that
in
> Config.lb?

Or more likely src/mainboarod/???/???/Options.lb

src/devices/pci_device.c:pci_dev_enable_resources()
calls dev->ops->pci_ops->set_subsystem() when the device 
dev->on_mainboard is true.  In turn config.g sets that
in static.c for all devices in the static tree.

I believe those are the correct semantics.  That the subsystem is
essentially an identifier for the board the chips are sitting on.

The values are come from:
Look at MAINBOARD_PCI_SUBSYSTEM_VENDOR_ID and MAINBOARD_SUBSYSTEM_DEVICE_ID.

So for the onboard scsi case you likely need to have a driver for
the onboard scsi device that implements the set_subsystem method
because there is not a generic way of doing that.

Eric


From YhLu at tyan.com  Thu Oct 21 13:05:01 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Oct 21 13:05:01 2004
Subject: Freebios2 recovery progress...
Message-ID: <3174569B9743D511922F00A0C94314230665B3FB@TYANWEB>

You can not test that in arima board. Because all device on 8131 is using
ioapic in amd8111.

YH

-----Original Message-----
From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
Sent: Thursday, October 21, 2004 11:13 AM
To: YhLu
Cc: LinuxBIOS
Subject: Re: Freebios2 recovery progress...

YhLu <YhLu at tyan.com> writes:

> Eric, 
> 
> You overwrite some lines in amd8131....
> 
>         /* We have to enable MEM and Bus Master for IOAPIC */
>         value = pci_read_config32(dev, 0x4);
>         value |= 6;
>         pci_write_config32(dev, 0x4, value);

Yep.

But in src/devices/pci_device.c:pci_scan_bus I added:
		/* Architectural/System devices always need to
		 * be bus masters.
		 */
		if ((dev->class >> 16) == PCI_BASE_CLASS_SYSTEM) {
			dev->command |= PCI_COMMAND_MASTER;
		}

Which achieves the same thing in a generally less fragile way.
We still might have one or two devices that we need to hard code
the master command status for but this catches the general
case.

Basically system devices have well known interfaces so they are
likely to have a generic driver instead of a device specific driver.
So enabling them as bus masters looks safe and will fix all of
the cases I know about where this is needed.

And I checked and the bus master bit is still getting set on
the IOAPICs on the HDAMA.

But thanks good catch, this needed an explanation.

Did I mention I was just a little behind on merging my code? :)

Eric


From stepan at openbios.org  Thu Oct 21 13:07:38 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Thu Oct 21 13:07:38 2004
Subject: Freebios2 recovery progress...
In-Reply-To: <m3mzyguf9p.fsf@maxwell.lnxi.com>
References: <3174569B9743D511922F00A0C94314230665B3E9@TYANWEB> <1098380621.15883.68.camel@exponential.lanl.gov> <m3mzyguf9p.fsf@maxwell.lnxi.com>
Message-ID: <20041021181649.GA30860@openbios.org>

* Eric W. Biederman <ebiederman at lnxi.com> [041021 19:56]:
> > OOPS, we are doing it with "uses MAINBOARD_SUBSYSTEM_ID" and if I am 
> > right every on board device share the same ID. For devices who want
> > its own ID it has to implement the .set_subsystem method. This is
> > really ugly. IMHO, we should treat the subsystem ids as attributes
> > of PCI device and it should be defined in the mainboard config file.
> > It should look like this
> 
> As far as I know there is only one that we need to set.
> The subsystem id of the motherboard.  And we need to set
> this for all devices.

Who needs the subsystem ids?

Stefan



From ollie at lanl.gov  Thu Oct 21 13:14:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu Oct 21 13:14:01 2004
Subject: FYI: Merge in progress...
In-Reply-To: <m3is94uf2i.fsf@maxwell.lnxi.com>
References: <3174569B9743D511922F00A0C94314230665B3A1@TYANWEB>
	 <m3lle0lr3q.fsf@maxwell.lnxi.com>
	 <1098368973.15883.39.camel@exponential.lanl.gov>
	 <m3is94uf2i.fsf@maxwell.lnxi.com>
Message-ID: <1098382691.15883.76.camel@exponential.lanl.gov>

On Thu, 2004-10-21 at 12:00, Eric W. Biederman wrote:
> At this point we should be able to look at the device tree and
> see if we need to use and io range register or the RdRam WrDram bits.
> 

Are you talking somthing in my mind ? I hope in the mtrr.c for K8
instead of hack with the mem_map we have:
 
setup_mtrr()
{
	if (search_for_vga_device_on_the_tree() == FOUND) {
		enable_rd_wr_mem_in_fixed_mtrr();
		clear_rd_wr_mem_for_legacy_vga_buffer();
		set_IORR_to_AGP_aperture();
	} else {
		disable_rd_wr_mem();
	}

	do_some_other_thigs();
}

And the code is executed on each processors.

Ollie




From ollie at lanl.gov  Thu Oct 21 13:17:09 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu Oct 21 13:17:09 2004
Subject: Freebios2 recovery progress...
In-Reply-To: <m3mzyguf9p.fsf@maxwell.lnxi.com>
References: <3174569B9743D511922F00A0C94314230665B3E9@TYANWEB>
	 <1098380621.15883.68.camel@exponential.lanl.gov>
	 <m3mzyguf9p.fsf@maxwell.lnxi.com>
Message-ID: <1098382878.15883.79.camel@exponential.lanl.gov>

On Thu, 2004-10-21 at 11:56, Eric W. Biederman wrote:
> 
> The .set_subsystem simply exists because there is not
> a standard way to set that value.  The almost generic
> version is in src/devices/pci_device.c but I can use
> it only occasionally.
>  
> > device pci 0.0 on
> > 	vendor 0x1234
> > 	device 0x5678
> > end
> > 
> > or
> > 
> > device pci 0.0 on
> > 	register "subsystem_vendor_id" = "0x1234"
> > 	register "subsystem_device_id" = "0x5678"
> > end
> 
> I don't see the benefit of those methods over having
> an Option if you have exactly 1 subsystem vendor_id+device_id that
> need to be set.
> 

YhLu's intention is to set subsystem ID differently for each devices
on the mainboard. It is totally the opposite to what you want and doing.

Ollie




From YhLu at tyan.com  Thu Oct 21 13:19:48 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Oct 21 13:19:48 2004
Subject: Freebios2 recovery progress...
Message-ID: <3174569B9743D511922F00A0C94314230665B3FF@TYANWEB>

No., Onboard scsi subsystem id should be same to others.

-----Original Message-----
From: Li-Ta Lo [mailto:ollie at lanl.gov] 
Sent: Thursday, October 21, 2004 11:21 AM
To: Eric W. Biederman
Cc: YhLu; LinuxBIOS
Subject: Re: Freebios2 recovery progress...

On Thu, 2004-10-21 at 11:56, Eric W. Biederman wrote:
> 
> The .set_subsystem simply exists because there is not
> a standard way to set that value.  The almost generic
> version is in src/devices/pci_device.c but I can use
> it only occasionally.
>  
> > device pci 0.0 on
> > 	vendor 0x1234
> > 	device 0x5678
> > end
> > 
> > or
> > 
> > device pci 0.0 on
> > 	register "subsystem_vendor_id" = "0x1234"
> > 	register "subsystem_device_id" = "0x5678"
> > end
> 
> I don't see the benefit of those methods over having
> an Option if you have exactly 1 subsystem vendor_id+device_id that
> need to be set.
> 

YhLu's intention is to set subsystem ID differently for each devices
on the mainboard. It is totally the opposite to what you want and doing.

Ollie



From ollie at lanl.gov  Thu Oct 21 13:22:38 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu Oct 21 13:22:38 2004
Subject: Freebios2 recovery progress...
In-Reply-To: <3174569B9743D511922F00A0C94314230665B3FF@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B3FF@TYANWEB>
Message-ID: <1098383162.15883.81.camel@exponential.lanl.gov>

On Thu, 2004-10-21 at 12:28, YhLu wrote:
> No., Onboard scsi subsystem id should be same to others.
> 

O.K. 

Ollie

> -----Original Message-----
> From: Li-Ta Lo [mailto:ollie at lanl.gov] 
> Sent: Thursday, October 21, 2004 11:21 AM
> To: Eric W. Biederman
> Cc: YhLu; LinuxBIOS
> Subject: Re: Freebios2 recovery progress...
> 
> On Thu, 2004-10-21 at 11:56, Eric W. Biederman wrote:
> > 
> > The .set_subsystem simply exists because there is not
> > a standard way to set that value.  The almost generic
> > version is in src/devices/pci_device.c but I can use
> > it only occasionally.
> >  
> > > device pci 0.0 on
> > > 	vendor 0x1234
> > > 	device 0x5678
> > > end
> > > 
> > > or
> > > 
> > > device pci 0.0 on
> > > 	register "subsystem_vendor_id" = "0x1234"
> > > 	register "subsystem_device_id" = "0x5678"
> > > end
> > 
> > I don't see the benefit of those methods over having
> > an Option if you have exactly 1 subsystem vendor_id+device_id that
> > need to be set.
> > 
> 
> YhLu's intention is to set subsystem ID differently for each devices
> on the mainboard. It is totally the opposite to what you want and doing.
> 
> Ollie
> 



From ollie at lanl.gov  Thu Oct 21 13:28:12 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu Oct 21 13:28:12 2004
Subject: Freebios2 recovery progress...
In-Reply-To: <3174569B9743D511922F00A0C94314230665B3F8@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B3F8@TYANWEB>
Message-ID: <1098384054.15883.92.camel@exponential.lanl.gov>

On Thu, 2004-10-21 at 12:14, YhLu wrote:
> I agree that all onboard device should use the same subsystem id as MB's.
> 

One interesting thing. In PCI Spec 2.2, section 6.2.4 it says that:

	Values in these registers must be loaded and valid prioir to the
	system BIOS or any system software accessing the PCI 
	Coniguration Space. blah,blah, blah. These values must not be 
	loaded using expansion ROM software becuase expansion ROM 
	software is not guaranteed to be run during POST 
	in all systems.

Are we doing something out of spec ?


BTW, why I can't download PCI spec form PCI-SIG anymore ? Even for
the 'useless' PCI conventional stuff.

Ollie




From stepan at openbios.org  Thu Oct 21 13:43:00 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Thu Oct 21 13:43:00 2004
Subject: Freebios2 recovery progress...
In-Reply-To: <1098384054.15883.92.camel@exponential.lanl.gov>
References: <3174569B9743D511922F00A0C94314230665B3F8@TYANWEB> <1098384054.15883.92.camel@exponential.lanl.gov>
Message-ID: <20041021190330.GA488@openbios.org>

* Li-Ta Lo <ollie at lanl.gov> [041021 20:40]:
> One interesting thing. In PCI Spec 2.2, section 6.2.4 it says that:
> 
> 	Values in these registers must be loaded and valid prioir to the
> 	system BIOS or any system software accessing the PCI 
> 	Coniguration Space.

Haha.. who should set them then, if they are not set in hardware? 

> These values must not be 
> 	loaded using expansion ROM software becuase expansion ROM 
> 	software is not guaranteed to be run during POST 
> 	in all systems.
> 
> Are we doing something out of spec ?
 
Don't think so, since we're usually not executing any expansion rom
software (option roms) at all. And especially we're not _writing_ option
roms

> BTW, why I can't download PCI spec form PCI-SIG anymore ? Even for
> the 'useless' PCI conventional stuff.

I assume they want $$


Stefan



From ebiederman at lnxi.com  Thu Oct 21 13:47:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Oct 21 13:47:00 2004
Subject: Freebios2 recovery progress...
In-Reply-To: <3174569B9743D511922F00A0C94314230665B3FB@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B3FB@TYANWEB>
Message-ID: <m3pt3bkjaw.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> You can not test that in arima board. Because all device on 8131 is using
> ioapic in amd8111.

I can't test that it works but I can test that the bits are getting
set by running lspci.   And that is how I tested.  The bus
master bit is still getting set.  I just move the location.

Eric


From ollie at lanl.gov  Thu Oct 21 13:50:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu Oct 21 13:50:00 2004
Subject: Freebios2 recovery progress...
In-Reply-To: <20041021190330.GA488@openbios.org>
References: <3174569B9743D511922F00A0C94314230665B3F8@TYANWEB>
	 <1098384054.15883.92.camel@exponential.lanl.gov>
	 <20041021190330.GA488@openbios.org>
Message-ID: <1098385829.15883.101.camel@exponential.lanl.gov>

On Thu, 2004-10-21 at 13:03, Stefan Reinauer wrote:
> * Li-Ta Lo <ollie at lanl.gov> [041021 20:40]:
> > One interesting thing. In PCI Spec 2.2, section 6.2.4 it says that:
> > 
> > 	Values in these registers must be loaded and valid prioir to the
> > 	system BIOS or any system software accessing the PCI 
> > 	Coniguration Space.
> 
> Haha.. who should set them then, if they are not set in hardware? 
> 

That is the blah, blah, blah part. It is:

	How these values are loaded is NOT SPECIFIED but could be done 	during
the manufactureing process or loaded form external logic
	(e.g., strapping options, serial ROMs, etc.)

> 
> > BTW, why I can't download PCI spec form PCI-SIG anymore ? Even for
> > the 'useless' PCI conventional stuff.
> 
> I assume they want $$
> 

I jsut read that on LWN, the InfiniBand TA also closed their 
used-to-be free downloadable specification.

Why those people hate us so much ?

Ollie




From YhLu at tyan.com  Thu Oct 21 13:52:38 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Oct 21 13:52:38 2004
Subject: Freebios2 recovery progress...
Message-ID: <3174569B9743D511922F00A0C94314230665B414@TYANWEB>

I will test that on s2885.

I suspect that will need MEM enable too.

YH

-----Original Message-----
From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
Sent: Thursday, October 21, 2004 11:39 AM
To: YhLu
Cc: LinuxBIOS
Subject: Re: Freebios2 recovery progress...

YhLu <YhLu at tyan.com> writes:

> You can not test that in arima board. Because all device on 8131 is using
> ioapic in amd8111.

I can't test that it works but I can test that the bits are getting
set by running lspci.   And that is how I tested.  The bus
master bit is still getting set.  I just move the location.

Eric


From YhLu at tyan.com  Thu Oct 21 14:00:01 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Oct 21 14:00:01 2004
Subject: FYI: Merge in progress...
Message-ID: <3174569B9743D511922F00A0C94314230665B415@TYANWEB>

Why just set subsystem id, in amd_8111.c enable_dev function?

That would more easy.

Need one switch case to figure out different reg position.

Regards

YH

-----Original Message-----
From: Li-Ta Lo [mailto:ollie at lanl.gov] 
Sent: Thursday, October 21, 2004 11:18 AM
To: Eric W. Biederman
Cc: YhLu; 'Ronald G. Minnich'; 'LinuxBIOS'
Subject: Re: FYI: Merge in progress...

On Thu, 2004-10-21 at 12:00, Eric W. Biederman wrote:
> At this point we should be able to look at the device tree and
> see if we need to use and io range register or the RdRam WrDram bits.
> 

Are you talking somthing in my mind ? I hope in the mtrr.c for K8
instead of hack with the mem_map we have:
 
setup_mtrr()
{
	if (search_for_vga_device_on_the_tree() == FOUND) {
		enable_rd_wr_mem_in_fixed_mtrr();
		clear_rd_wr_mem_for_legacy_vga_buffer();
		set_IORR_to_AGP_aperture();
	} else {
		disable_rd_wr_mem();
	}

	do_some_other_thigs();
}

And the code is executed on each processors.

Ollie



From ollie at lanl.gov  Thu Oct 21 14:07:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu Oct 21 14:07:00 2004
Subject: FYI: Merge in progress...
In-Reply-To: <3174569B9743D511922F00A0C94314230665B415@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B415@TYANWEB>
Message-ID: <1098386878.15883.106.camel@exponential.lanl.gov>

On Thu, 2004-10-21 at 13:24, YhLu wrote:
> Why just set subsystem id, in amd_8111.c enable_dev function?
> 
> That would more easy.
> 
> Need one switch case to figure out different reg position.
> 

??? I am talking about the K8 MTRR stuff I need to support VGA BIOS
in LinuxBIOS. It has to be done based on what CPU we are running and
if there is any VGA device in the system.

Ollie

> Regards
> 
> YH
> 
> -----Original Message-----
> From: Li-Ta Lo [mailto:ollie at lanl.gov] 
> Sent: Thursday, October 21, 2004 11:18 AM
> To: Eric W. Biederman
> Cc: YhLu; 'Ronald G. Minnich'; 'LinuxBIOS'
> Subject: Re: FYI: Merge in progress...
> 
> On Thu, 2004-10-21 at 12:00, Eric W. Biederman wrote:
> > At this point we should be able to look at the device tree and
> > see if we need to use and io range register or the RdRam WrDram bits.
> > 
> 
> Are you talking somthing in my mind ? I hope in the mtrr.c for K8
> instead of hack with the mem_map we have:
>  
> setup_mtrr()
> {
> 	if (search_for_vga_device_on_the_tree() == FOUND) {
> 		enable_rd_wr_mem_in_fixed_mtrr();
> 		clear_rd_wr_mem_for_legacy_vga_buffer();
> 		set_IORR_to_AGP_aperture();
> 	} else {
> 		disable_rd_wr_mem();
> 	}
> 
> 	do_some_other_thigs();
> }
> 
> And the code is executed on each processors.
> 
> Ollie
> 



From stepan at openbios.org  Thu Oct 21 14:31:01 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Thu Oct 21 14:31:01 2004
Subject: Tyan 488x
Message-ID: <20041021195221.GA675@openbios.org>

In the Tyan 488x Option.lb files the maximum number of CPUs is set to 2.
Is this on purpose?

Stefan


From YhLu at tyan.com  Thu Oct 21 14:34:01 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Oct 21 14:34:01 2004
Subject: Tyan 488x
Message-ID: <3174569B9743D511922F00A0C94314230665B416@TYANWEB>

My fault. Need to change to 4.

YH

-----Original Message-----
From: Stefan Reinauer [mailto:stepan at openbios.org] 
Sent: Thursday, October 21, 2004 12:52 PM
To: YhLu
Cc: 'LinuxBIOS'
Subject: Tyan 488x

In the Tyan 488x Option.lb files the maximum number of CPUs is set to 2.
Is this on purpose?

Stefan


From YhLu at tyan.com  Thu Oct 21 15:38:00 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Oct 21 15:38:00 2004
Subject: Freebios2 recovery progress...
Message-ID: <3174569B9743D511922F00A0C94314230665B421@TYANWEB>

It's OK.

PCI: 04:01.0 bridge ctrl <- 0003
PCI: 04:01.0 cmd <- 146
PCI: 05:04.0 cmd <- 142
PCI: 04:01.1 subsystem <- 10f1/2895
PCI: 04:01.1 cmd <- 146
PCI: 04:02.0 bridge ctrl <- 0003
PCI: 04:02.0 cmd <- 147
PCI: 06:06.0 cmd <- 143
PCI: 06:06.1 cmd <- 143

-----Original Message-----
From: YhLu 
Sent: Thursday, October 21, 2004 12:11 PM
To: 'ebiederman at lnxi.com'
Cc: LinuxBIOS
Subject: RE: Freebios2 recovery progress...

I will test that on s2885.

I suspect that will need MEM enable too.

YH

-----Original Message-----
From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
Sent: Thursday, October 21, 2004 11:39 AM
To: YhLu
Cc: LinuxBIOS
Subject: Re: Freebios2 recovery progress...

YhLu <YhLu at tyan.com> writes:

> You can not test that in arima board. Because all device on 8131 is using
> ioapic in amd8111.

I can't test that it works but I can test that the bits are getting
set by running lspci.   And that is how I tested.  The bus
master bit is still getting set.  I just move the location.

Eric


From rminnich at lanl.gov  Thu Oct 21 15:49:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Thu Oct 21 15:49:00 2004
Subject: Freebios2 recovery progress...
In-Reply-To: <1098384054.15883.92.camel@exponential.lanl.gov>
References: <3174569B9743D511922F00A0C94314230665B3F8@TYANWEB>
 <1098384054.15883.92.camel@exponential.lanl.gov>
Message-ID: <Pine.LNX.4.58.0410211501350.13025@linux.site>


On Thu, 21 Oct 2004, Li-Ta Lo wrote:

> BTW, why I can't download PCI spec form PCI-SIG anymore ? Even for
> the 'useless' PCI conventional stuff.

cause they want your money.

ron


From rminnich at lanl.gov  Thu Oct 21 15:53:52 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Thu Oct 21 15:53:52 2004
Subject: Freebios2 recovery progress...
In-Reply-To: <1098385829.15883.101.camel@exponential.lanl.gov>
References: <3174569B9743D511922F00A0C94314230665B3F8@TYANWEB> 
 <1098384054.15883.92.camel@exponential.lanl.gov>  <20041021190330.GA488@openbios.org>
 <1098385829.15883.101.camel@exponential.lanl.gov>
Message-ID: <Pine.LNX.4.58.0410211504260.13025@linux.site>


On Thu, 21 Oct 2004, Li-Ta Lo wrote:
> Why those people hate us so much ?

because you're a customer.

ron


From ollie at lanl.gov  Thu Oct 21 15:59:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu Oct 21 15:59:01 2004
Subject: Freebios2 recovery progress...
In-Reply-To: <Pine.LNX.4.58.0410211504260.13025@linux.site>
References: <3174569B9743D511922F00A0C94314230665B3F8@TYANWEB>
	 <1098384054.15883.92.camel@exponential.lanl.gov>
	 <20041021190330.GA488@openbios.org>
	 <1098385829.15883.101.camel@exponential.lanl.gov>
	 <Pine.LNX.4.58.0410211504260.13025@linux.site>
Message-ID: <1098393052.4774.11.camel@exponential.lanl.gov>

On Thu, 2004-10-21 at 15:04, Ronald G. Minnich wrote:
> On Thu, 21 Oct 2004, Li-Ta Lo wrote:
> > Why those people hate us so much ?
> 
> because you're a customer.
> 

Sounds like a Dilbert passage. You PHB !!!

Ollie




From YhLu at tyan.com  Thu Oct 21 16:12:00 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Oct 21 16:12:00 2004
Subject: Freebios2 recovery progress... moving enable_childrens_resour
	ces
Message-ID: <3174569B9743D511922F00A0C94314230665B42D@TYANWEB>

Eric,

Why moving 
enable_childrens_resources(dev);
from void pci_dev_enable_resources(struct device *dev)
to 
void pci_bus_enable_resources(struct device *dev)

the superio under the PCI device will not be enabled with resources.

Regards

YH

-----Original Message-----
From: YhLu 
Sent: Thursday, October 21, 2004 2:03 PM
To: ebiederman at lnxi.com
Cc: LinuxBIOS
Subject: RE: Freebios2 recovery progress...

It's OK.

PCI: 04:01.0 bridge ctrl <- 0003
PCI: 04:01.0 cmd <- 146
PCI: 05:04.0 cmd <- 142
PCI: 04:01.1 subsystem <- 10f1/2895
PCI: 04:01.1 cmd <- 146
PCI: 04:02.0 bridge ctrl <- 0003
PCI: 04:02.0 cmd <- 147
PCI: 06:06.0 cmd <- 143
PCI: 06:06.1 cmd <- 143

-----Original Message-----
From: YhLu 
Sent: Thursday, October 21, 2004 12:11 PM
To: 'ebiederman at lnxi.com'
Cc: LinuxBIOS
Subject: RE: Freebios2 recovery progress...

I will test that on s2885.

I suspect that will need MEM enable too.

YH

-----Original Message-----
From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
Sent: Thursday, October 21, 2004 11:39 AM
To: YhLu
Cc: LinuxBIOS
Subject: Re: Freebios2 recovery progress...

YhLu <YhLu at tyan.com> writes:

> You can not test that in arima board. Because all device on 8131 is using
> ioapic in amd8111.

I can't test that it works but I can test that the bits are getting
set by running lspci.   And that is how I tested.  The bus
master bit is still getting set.  I just move the location.

Eric
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From Rodney.Kittleson at bench.com  Thu Oct 21 16:21:01 2004
From: Rodney.Kittleson at bench.com (Rodney.Kittleson at bench.com)
Date: Thu Oct 21 16:21:01 2004
Subject: Makefile changes for symbols
Message-ID: <8E8200E838D692429246225038E1736302771C81@mn-ex02.mn.bench.com>

Steve, 

What version of Source point are you using? The symbols are coming in
but SourcePoint doesn't allow me to reference the source files.

I mapped the linuxbios directory on my Win2000 system for SourcePoint to
access.  (I have samba running on my linux system) I just need to get
SourcePoint working.

Thanks,
Rod

-----Original Message-----
From: Kimball, Stephen 
Sent: Wednesday, October 20, 2004 1:04 PM
To: Kittleson, Rodney C.; linuxbios at clustermatic.org
Cc: Jeff_Pitts at arium.com
Subject: RE: Makefile changes for symbols


The file under your target in normal/linuxbios_c.o seems to have all the
symbols if you add "-gdwarf-2" to the $CFLAGS in the Makefile.  Then
when you open the first C module the SourcePoint software asks where the
file exists, after you tell SourcePoint it seems to find the rest by
itself.  I recreated the same Linux directory structure on Windows.
Thanks Rod!

Steve  

-----Original Message-----
From: Kittleson, Rodney C. 
Sent: Wednesday, October 20, 2004 11:47 AM
To: Kimball, Stephen; linuxbios at clustermatic.org
Subject: RE: Makefile changes for symbols

Linuxbios_c, from the build directory, can be sucked into Sourcepoint to
extract the symbols. This allows the disassembled instructions to
display the symbols inline. It makes it easier to set breakpoints and
follow the code, but it's a far cry from source level debugging.  

I haven't attempted to link the source with sourcepoint yet. I may try
it later this week, let me know if you have any success.

Rod

-----Original Message-----
From: Kimball, Stephen 
Sent: Tuesday, October 19, 2004 3:33 PM
To: linuxbios at clustermatic.org
Subject: Makefile changes for symbols



Can someone give me the Makefile changes to make a LinuxBIOS with
symbols?  I tried adding "-gdwarf-2" to CFLAGS, but I'm not sure where
the unstripped output would be.  

Are there any features in the code that are useful in debugging
LinuxBIOS? Any defines that should change as well?

Someone must have some experience with source code level debugging of
LinuxBIOS with an American Arium ECM-50.  Thanks.

Steve Kimball
Benchmark Electronics
Hudson, NH 
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From YhLu at tyan.com  Thu Oct 21 17:36:01 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Oct 21 17:36:01 2004
Subject: Freebios2 recovery progress... pci64 mem optimization
Message-ID: <3174569B9743D511922F00A0C94314230665B439@TYANWEB>

Eric,

In northbridge.c

Another typo error

			/* If so place the one with the most stringent
alignment first */
                if (mem2->align > mem1->align) {
                        struct resource *tmp;
                        tmp = mem1;
                        mem1 = mem2;
                        mem2 = mem1;
                }
                /* Now place the memory as high up as it will go */
                mem2->base = resource_max(mem2);
                mem1->limit = mem2->base - 1;
                mem1->base = resource_max(mem1);

---->
		  /* If so place the one with the most stringent alignment
first */
                if (mem2->align > mem1->align) {
                        struct resource *tmp;
                        tmp = mem1;
                        mem1 = mem2;
                        mem2 = tmp;
                }
                /* Now place the memory as high up as it will go */
                mem2->base = resource_max(mem2);
                mem1->limit = mem2->base - 1;
                mem1->base = resource_max(mem1);


Another question is

Should do align big allocation at first or align small first.

It seems you should do align big allocation.


Align big first

base1: 0xd0000000 limit1: 0xfebfffff size: 0x18800000 align: 28
base2: 0xec000000 limit2: 0xfebfffff size: 0x06b00000 align: 26
base1: 0xd8000000 limit1: 0xdfffffff size: 0x06b00000 align: 26
base2: 0xe0000000 limit2: 0xfebfffff size: 0x18800000 align: 28
PCI_DOMAIN: 0000 00 <- [0x0000001000 - 0x0000005fff] io
PCI_DOMAIN: 0000 01 <- [0x00e0000000 - 0x00f87fffff] prefmem
PCI_DOMAIN: 0000 02 <- [0x00d8000000 - 0x00deafffff] mem

Align small first
base1: 0xd0000000 limit1: 0xfebfffff size: 0x18800000 align: 28
base2: 0xec000000 limit2: 0xfebfffff size: 0x06b00000 align: 26
base1: 0xd0000000 limit1: 0xf7ffffff size: 0x18800000 align: 28
base2: 0xf8000000 limit2: 0xfebfffff size: 0x06b00000 align: 26
PCI_DOMAIN: 0000 00 <- [0x0000001000 - 0x0000005fff] io
PCI_DOMAIN: 0000 01 <- [0x00d0000000 - 0x00e87fffff] prefmem
PCI_DOMAIN: 0000 02 <- [0x00f8000000 - 0x00feafffff] mem




From YhLu at tyan.com  Thu Oct 21 17:50:01 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Oct 21 17:50:01 2004
Subject: Freebios2 recovery progress... pci64 mem optimization
Message-ID: <3174569B9743D511922F00A0C94314230665B43E@TYANWEB>

Another case

Align big allocation at first
base1: 0xe0000000 limit1: 0xfebfffff size: 0x10000000 align: 28
base2: 0xf0000000 limit2: 0xfebfffff size: 0x06a00000 align: 26
base1: 0xd8000000 limit1: 0xdfffffff size: 0x06a00000 align: 26
base2: 0xe0000000 limit2: 0xfebfffff size: 0x10000000 align: 28
PCI_DOMAIN: 0000 00 <- [0x0000001000 - 0x0000005fff] io
PCI_DOMAIN: 0000 01 <- [0x00e0000000 - 0x00efffffff] prefmem
PCI_DOMAIN: 0000 02 <- [0x00d8000000 - 0x00de9fffff] mem

Align small allocation at first

base1: 0xe0000000 limit1: 0xfebfffff size: 0x10000000 align: 28
base2: 0xf0000000 limit2: 0xfebfffff size: 0x06a00000 align: 26
base1: 0xe0000000 limit1: 0xf7ffffff size: 0x10000000 align: 28
base2: 0xf8000000 limit2: 0xfebfffff size: 0x06a00000 align: 26
PCI_DOMAIN: 0000 00 <- [0x0000001000 - 0x0000005fff] io
PCI_DOMAIN: 0000 01 <- [0x00e0000000 - 0x00efffffff] prefmem
PCI_DOMAIN: 0000 02 <- [0x00f8000000 - 0x00fe9fffff] mem

Maybe need to compare the base to find out which one first.

-----Original Message-----
From: YhLu 
Sent: Thursday, October 21, 2004 3:57 PM
To: ebiederman at lnxi.com
Cc: LinuxBIOS
Subject: RE: Freebios2 recovery progress... pci64 mem optimization

Eric,

In northbridge.c

Another typo error

			/* If so place the one with the most stringent
alignment first */
                if (mem2->align > mem1->align) {
                        struct resource *tmp;
                        tmp = mem1;
                        mem1 = mem2;
                        mem2 = mem1;
                }
                /* Now place the memory as high up as it will go */
                mem2->base = resource_max(mem2);
                mem1->limit = mem2->base - 1;
                mem1->base = resource_max(mem1);

---->
		  /* If so place the one with the most stringent alignment
first */
                if (mem2->align > mem1->align) {
                        struct resource *tmp;
                        tmp = mem1;
                        mem1 = mem2;
                        mem2 = tmp;
                }
                /* Now place the memory as high up as it will go */
                mem2->base = resource_max(mem2);
                mem1->limit = mem2->base - 1;
                mem1->base = resource_max(mem1);


Another question is

Should do align big allocation at first or align small first.

It seems you should do align big allocation.


Align big first

base1: 0xd0000000 limit1: 0xfebfffff size: 0x18800000 align: 28
base2: 0xec000000 limit2: 0xfebfffff size: 0x06b00000 align: 26
base1: 0xd8000000 limit1: 0xdfffffff size: 0x06b00000 align: 26
base2: 0xe0000000 limit2: 0xfebfffff size: 0x18800000 align: 28
PCI_DOMAIN: 0000 00 <- [0x0000001000 - 0x0000005fff] io
PCI_DOMAIN: 0000 01 <- [0x00e0000000 - 0x00f87fffff] prefmem
PCI_DOMAIN: 0000 02 <- [0x00d8000000 - 0x00deafffff] mem

Align small first
base1: 0xd0000000 limit1: 0xfebfffff size: 0x18800000 align: 28
base2: 0xec000000 limit2: 0xfebfffff size: 0x06b00000 align: 26
base1: 0xd0000000 limit1: 0xf7ffffff size: 0x18800000 align: 28
base2: 0xf8000000 limit2: 0xfebfffff size: 0x06b00000 align: 26
PCI_DOMAIN: 0000 00 <- [0x0000001000 - 0x0000005fff] io
PCI_DOMAIN: 0000 01 <- [0x00d0000000 - 0x00e87fffff] prefmem
PCI_DOMAIN: 0000 02 <- [0x00f8000000 - 0x00feafffff] mem




From YhLu at tyan.com  Thu Oct 21 20:20:01 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Oct 21 20:20:01 2004
Subject: Freebios2 recovery progress... pci64 mem optimization
Message-ID: <3174569B9743D511922F00A0C94314230665B498@TYANWEB>

Cool, with prefmem 64 bit, and mem opt.

Get back 512M RAM.

Mellanox IB PCI-E card support real pci mem64.

base1: 0xd8000000 limit1: 0xfcffffffff size: 0x18800000 align: 27
base2: 0xf4000000 limit2: 0xfe8fffff size: 0x04c00000 align: 26
base1: 0xfce0000000 limit1: 0xfcffffffff size: 0x18800000 align: 27
base2: 0xf8000000 limit2: 0xfe8fffff size: 0x04c00000 align: 26
PCI_DOMAIN: 0000 00 <- [0x0000001000 - 0x0000005fff] io
PCI_DOMAIN: 0000 01 <- [0xfce0000000 - 0xfcf87fffff] prefmem
PCI_DOMAIN: 0000 02 <- [0x00f8000000 - 0x00fcbfffff] mem

Setting variable MTRR 0, base:    0MB, range: 2048MB, type WB
Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB
Setting variable MTRR 2, base: 3072MB, range:  512MB, type WB
Setting variable MTRR 3, base: 3584MB, range:  256MB, type WB
Setting variable MTRR 4, base: 3840MB, range:  128MB, type WB

LBsuse91AMD64:~ # lspci -vvxxx -s 3:0.0 
0000:03:00.0 InfiniBand: Mellanox Technology MT25208 InfiniHost III Ex HCA
(rev a0)
        Subsystem: Mellanox Technology MT25208 InfiniHost III Ex HCA
        Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr+
Stepping- SERR+ FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Interrupt: pin A routed to IRQ 18
        Region 0: Memory at fc800000 (64-bit, non-prefetchable)
        Region 2: Memory at fce8000000 (64-bit, prefetchable) [size=8M]
        Region 4: Memory at fce0000000 (64-bit, prefetchable) [size=128M]
        Capabilities: [40] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [48] Vital Product Data
        Capabilities: [90] Message Signalled Interrupts: 64bit+ Queue=0/5
Enable-
                Address: 0000000000000000  Data: 0000
        Capabilities: [60] #10 [0001]
00: b3 15 78 62 42 01 10 00 a0 00 06 0c 10 00 00 00
10: 04 00 80 fc 00 00 00 00 0c 00 00 e8 fc 00 00 00
20: 0c 00 00 e0 fc 00 00 00 00 00 00 00 b3 15 78 62
30: 00 00 00 00 40 00 00 00 00 00 00 00 00 01 00 00
40: 01 48 02 00 00 00 00 00 03 90 ff 7f 11 11 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 10 00 01 00 c0 0f 00 00 00 20 01 00 81 f4 03 08
70: 00 00 81 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 11 00 1f 00 00 20 08 00 00 22 08 00
90: 05 60 8a 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

LBsuse91AMD64:~ # lspci -vvxxx -s 8:0.0  
0000:08:00.0 InfiniBand: Mellanox Technology MT25208 InfiniHost III Ex HCA
(rev a0)
        Subsystem: Mellanox Technology MT25208 InfiniHost III Ex HCA
        Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr+
Stepping- SERR+ FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Interrupt: pin A routed to IRQ 50
        Region 0: Memory at fca00000 (64-bit, non-prefetchable)
        Region 2: Memory at fcf8000000 (64-bit, prefetchable) [size=8M]
        Region 4: Memory at fcf0000000 (64-bit, prefetchable) [size=128M]
        Capabilities: [40] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [48] Vital Product Data
        Capabilities: [90] Message Signalled Interrupts: 64bit+ Queue=0/5
Enable-
                Address: 0000000000000000  Data: 0000
        Capabilities: [60] #10 [0001]
00: b3 15 78 62 42 01 10 00 a0 00 06 0c 10 00 00 00
10: 04 00 a0 fc 00 00 00 00 0c 00 00 f8 fc 00 00 00
20: 0c 00 00 f0 fc 00 00 00 00 00 00 00 b3 15 78 62
30: 00 00 00 00 40 00 00 00 00 00 00 00 00 01 00 00
40: 01 48 02 00 00 00 00 00 03 90 ff 7f 11 11 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 10 00 01 00 c0 0f 00 00 00 20 01 00 81 f4 03 08
70: 00 00 81 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 11 00 1f 00 00 20 08 00 00 22 08 00
90: 05 60 8a 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00


From YhLu at tyan.com  Thu Oct 21 20:34:00 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Oct 21 20:34:00 2004
Subject: Freebios2 recovery progress... pci64 mem optimization
Message-ID: <3174569B9743D511922F00A0C94314230665B499@TYANWEB>

If no agp,
Still need gart?

YH

PCI: 00:18.3 94 <- [0x00f8000000 - 0x00fbffffff] mem <gart>
PCI: 00:19.3 94 <- [0x00f8000000 - 0x00fbffffff] mem <gart>


From ebiederman at lnxi.com  Thu Oct 21 20:37:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Oct 21 20:37:00 2004
Subject: Freebios2 recovery progress... pci64 mem optimization
In-Reply-To: <3174569B9743D511922F00A0C94314230665B498@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B498@TYANWEB>
Message-ID: <m365535xbk.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> Cool, with prefmem 64 bit, and mem opt.
> 
> Get back 512M RAM.

That is my motivation.  The fact that 256M video cards
are prefmem but are not 64bit is annoying.

On the server side everything seems to be large 64bit prefetchable memory areas.

32bit kernels have an issue with 64bit resources though :(

Eric


From ebiederman at lnxi.com  Thu Oct 21 20:47:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Oct 21 20:47:00 2004
Subject: Freebios2 recovery progress... pci64 mem optimization
In-Reply-To: <3174569B9743D511922F00A0C94314230665B499@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B499@TYANWEB>
Message-ID: <m3655333p0.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> If no agp,
> Still need gart?
> 
> YH
> 
> PCI: 00:18.3 94 <- [0x00f8000000 - 0x00fbffffff] mem <gart>
> PCI: 00:19.3 94 <- [0x00f8000000 - 0x00fbffffff] mem <gart>

With more than 4GB of memory it is used as an IOMMU so you don't
need bounce buffers.

Eric


From YhLu at tyan.com  Thu Oct 21 20:56:01 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Oct 21 20:56:01 2004
Subject: Freebios2 recovery progress... pci64 mem optimization
Message-ID: <3174569B9743D511922F00A0C94314230665B49D@TYANWEB>

Iommu is only needed when system installed memory > 4G?

YH

-----Original Message-----
From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
Sent: Thursday, October 21, 2004 7:08 PM
To: YhLu
Cc: 'LinuxBIOS'
Subject: Re: Freebios2 recovery progress... pci64 mem optimization

YhLu <YhLu at tyan.com> writes:

> If no agp,
> Still need gart?
> 
> YH
> 
> PCI: 00:18.3 94 <- [0x00f8000000 - 0x00fbffffff] mem <gart>
> PCI: 00:19.3 94 <- [0x00f8000000 - 0x00fbffffff] mem <gart>

With more than 4GB of memory it is used as an IOMMU so you don't
need bounce buffers.

Eric


From ebiederman at lnxi.com  Thu Oct 21 20:58:45 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Oct 21 20:58:45 2004
Subject: Freebios2 recovery progress... pci64 mem optimization
In-Reply-To: <3174569B9743D511922F00A0C94314230665B439@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B439@TYANWEB>
Message-ID: <m33c0733a2.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> Eric,
> 
> In northbridge.c
> 
> Another typo error

Thanks. My test case obviously does not include a 32bit prefetchable memory
resource.

> Another question is
> 
> Should do align big allocation at first or align small first.
> 
> It seems you should do align big allocation.

Hmm. 

What has generally proved to be a good solution.
Is to allocate the resources with the largest alignment at
the lowest addresses, and the resources with the less strict
alignment at later addresses.  
So I think we are in agreement about what works well.

I don't think it matters which order you perform the allocation
so long as the larger alignments come at the lower addresses in
memory.

Right now this is a first pass and it does ok, but it has
all sorts of issues.  I believe what really needs to happen
is that these resources become transparent/subtractive
and that compute_allocate_resource be taught how to do a better
job with limits.

That should also help with the case where one bridge can do something
better than another bridge.

The current strategy of reducing the limit of the parent resource actually
falls down when we hit pnp I/O resources that are only 12 bit.

I need to be fresh before I fix the general problem though.

Eric


From ebiederman at lnxi.com  Thu Oct 21 21:02:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Oct 21 21:02:00 2004
Subject: Freebios2 recovery progress... moving enable_childrens_resour ces
In-Reply-To: <3174569B9743D511922F00A0C94314230665B42D@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B42D@TYANWEB>
Message-ID: <m3y8hz1ojr.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> Eric,
> 
> Why moving 
> enable_childrens_resources(dev);
> from void pci_dev_enable_resources(struct device *dev)
> to 
> void pci_bus_enable_resources(struct device *dev)
> 
> the superio under the PCI device will not be enabled with resources.

We have some busses like i2c where it really is nonsense, the devices
don't have any resources.

In addition we manually have to recurse for all of the other functions
so this is not much of a burden except right now when I have made the
change.

I actually forgot about LPC/ISA busses when I made that change so I forgot
to fix them up, I will do that shortly.

Eric


From YhLu at tyan.com  Thu Oct 21 21:09:01 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Oct 21 21:09:01 2004
Subject: Freebios2 recovery progress... moving enable_childrens_resour
	 ces
Message-ID: <3174569B9743D511922F00A0C94314230665B49F@TYANWEB>

add one call to amd8111 lpc ?

static struct device_operations lpc_ops  = {
        .read_resources   = amd8111_lpc_read_resources,
        .set_resources    = pci_dev_set_resources,
        .enable_resources = pci_dev_enable_resources,
        .init             = lpc_init,
        .scan_bus         = scan_static_bus,
        .enable           = amd8111_enable,
        .ops_pci          = &lops_pci,
};

---->

static void amd8111_lpc_enable_resources(device_t dev)
{
	pci_dev_enable_resources(dev);
	enable_childrens_resources(dev);
}

static struct device_operations lpc_ops  = {
        .read_resources   = amd8111_lpc_read_resources,
        .set_resources    = pci_dev_set_resources,
        .enable_resources = amd8111_lpc_enable_resources,
        .init             = lpc_init,
        .scan_bus         = scan_static_bus,
        .enable           = amd8111_enable,
        .ops_pci          = &lops_pci,
};


From ebiederman at lnxi.com  Thu Oct 21 21:19:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Oct 21 21:19:01 2004
Subject: Freebios2 recovery progress... pci64 mem optimization
In-Reply-To: <3174569B9743D511922F00A0C94314230665B49D@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B49D@TYANWEB>
Message-ID: <m3hdonv5lj.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> Iommu is only needed when system installed memory > 4G?

IOMMU's have 2 uses.
1) let devices with small DMA ranges reach all of memory
   (pci devices that don't implement DAC can only talk to the first 4G)
2) Isolation.  Allowing the OS to controll which memory may be touched
   by I/O devices.

The current Opteron IOMMU does not appear to be general enough to 
perform isolation so it is only needed when you have more than 4GB of
memory.

So there may be some point in disabling it on systems with 4GB.

Plus the linux kernel seems to be able to properly allocate the iommu
if it needs it.

Eric


From ebiederman at lnxi.com  Thu Oct 21 21:22:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Oct 21 21:22:00 2004
Subject: Freebios2 recovery progress... moving enable_childrens_resour ces
In-Reply-To: <3174569B9743D511922F00A0C94314230665B49F@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B49F@TYANWEB>
Message-ID: <m3d5zbv5g2.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> add one call to amd8111 lpc ?

Exactly.  And committed for the amd8111 and the i82801??? chips.

The rest of the southbridges did not appear to an lpc or an isa
bus that I could identify code wise so it appears they have more
that needs to be done to get them into shape.

Eric


From YhLu at tyan.com  Thu Oct 21 21:24:36 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Oct 21 21:24:36 2004
Subject: Freebios2 recovery progress... pci64 mem optimization
Message-ID: <3174569B9743D511922F00A0C94314230665B4A1@TYANWEB>

Clear. Thanks.

-----Original Message-----
From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
Sent: Thursday, October 21, 2004 7:40 PM
To: YhLu
Cc: 'LinuxBIOS'
Subject: Re: Freebios2 recovery progress... pci64 mem optimization

YhLu <YhLu at tyan.com> writes:

> Iommu is only needed when system installed memory > 4G?

IOMMU's have 2 uses.
1) let devices with small DMA ranges reach all of memory
   (pci devices that don't implement DAC can only talk to the first 4G)
2) Isolation.  Allowing the OS to controll which memory may be touched
   by I/O devices.

The current Opteron IOMMU does not appear to be general enough to 
perform isolation so it is only needed when you have more than 4GB of
memory.

So there may be some point in disabling it on systems with 4GB.

Plus the linux kernel seems to be able to properly allocate the iommu
if it needs it.

Eric


From YhLu at tyan.com  Thu Oct 21 21:33:01 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Oct 21 21:33:01 2004
Subject: Freebios2 recovery progress... pci64 mem optimization
Message-ID: <3174569B9743D511922F00A0C94314230665B4A6@TYANWEB>

You are right

4G installed: 
PCI-DMA: Disabling IOMMU.

---->

8G installed:
PCI-DMA: Disabling AGP.
PCI-DMA: aperture base @ 8000000 size 65536 KB
PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture

-----Original Message-----
From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
Sent: Thursday, October 21, 2004 7:40 PM
To: YhLu
Cc: 'LinuxBIOS'
Subject: Re: Freebios2 recovery progress... pci64 mem optimization

YhLu <YhLu at tyan.com> writes:

> Iommu is only needed when system installed memory > 4G?

IOMMU's have 2 uses.
1) let devices with small DMA ranges reach all of memory
   (pci devices that don't implement DAC can only talk to the first 4G)
2) Isolation.  Allowing the OS to controll which memory may be touched
   by I/O devices.

The current Opteron IOMMU does not appear to be general enough to 
perform isolation so it is only needed when you have more than 4GB of
memory.

So there may be some point in disabling it on systems with 4GB.

Plus the linux kernel seems to be able to properly allocate the iommu
if it needs it.

Eric


From ebiederman at lnxi.com  Thu Oct 21 21:36:02 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Oct 21 21:36:02 2004
Subject: Freebios2 recovery progress...
In-Reply-To: <1098384054.15883.92.camel@exponential.lanl.gov>
References: <3174569B9743D511922F00A0C94314230665B3F8@TYANWEB>
	<1098384054.15883.92.camel@exponential.lanl.gov>
Message-ID: <m3u0sno40q.fsf@maxwell.lnxi.com>

Li-Ta Lo <ollie at lanl.gov> writes:

> On Thu, 2004-10-21 at 12:14, YhLu wrote:
> > I agree that all onboard device should use the same subsystem id as MB's.
> > 
> 
> One interesting thing. In PCI Spec 2.2, section 6.2.4 it says that:
> 
> 	Values in these registers must be loaded and valid prioir to the
> 	system BIOS or any system software accessing the PCI 
> 	Coniguration Space. blah,blah, blah. These values must not be 
> 	loaded using expansion ROM software becuase expansion ROM 
> 	software is not guaranteed to be run during POST 
> 	in all systems.
> 
> Are we doing something out of spec ?

I think it is more a matter of the spec no governing for
onboard devices.  For any devices that is implemented on a plug-in
card I believe that governs.
 
> BTW, why I can't download PCI spec form PCI-SIG anymore ? Even for
> the 'useless' PCI conventional stuff.

I have never been able to download it so it is news to me that
was possible.

I think they use the money for operating money for the SIG
but I really don't know.

Eric


From ebiederman at lnxi.com  Thu Oct 21 21:49:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Oct 21 21:49:01 2004
Subject: FYI: Merge in progress...
In-Reply-To: <1098382691.15883.76.camel@exponential.lanl.gov>
References: <3174569B9743D511922F00A0C94314230665B3A1@TYANWEB>
	<m3lle0lr3q.fsf@maxwell.lnxi.com>
	<1098368973.15883.39.camel@exponential.lanl.gov>
	<m3is94uf2i.fsf@maxwell.lnxi.com>
	<1098382691.15883.76.camel@exponential.lanl.gov>
Message-ID: <m3pt3bo3ca.fsf@maxwell.lnxi.com>

Li-Ta Lo <ollie at lanl.gov> writes:

> On Thu, 2004-10-21 at 12:00, Eric W. Biederman wrote:
> > At this point we should be able to look at the device tree and
> > see if we need to use and io range register or the RdRam WrDram bits.
> > 
> 
> Are you talking somthing in my mind ? I hope in the mtrr.c for K8
> instead of hack with the mem_map we have:
>  
> setup_mtrr()
> {
> 	if (search_for_vga_device_on_the_tree() == FOUND) {
> 		enable_rd_wr_mem_in_fixed_mtrr();
> 		clear_rd_wr_mem_for_legacy_vga_buffer();
> 		set_IORR_to_AGP_aperture();
> 	} else {
> 		disable_rd_wr_mem();
> 	}
> 
> 	do_some_other_thigs();
> }
> 
> And the code is executed on each processors.

I was thinking more like:

for_each_mem_resource() {
        if (resource < TOP_MEM) {
                if (can_use_fixed_iorr()) {
                        setup_fixed_iorr_in_fixed_mtrr();
		}
		else {
                        setup_iorr();
                }
        }
}

That should be a fairly simple loop to code up.  The interesting
part is to add a resource to the VGA devices who gets to
live at the legacy address.

Largely I had not realized mtrr.c had been updated to
handle this before my merge or I would have made an attempt
to convert that code.

It looks like it would be profitable for me to look through
the old cpu directories and see what code changes I have 
missed.  

Eric


From YhLu at tyan.com  Thu Oct 21 22:09:00 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Oct 21 22:09:00 2004
Subject: Freebios2 recovery progress... moving enable_childrens_resour
	 ces
Message-ID: <3174569B9743D511922F00A0C94314230665B4A9@TYANWEB>

Mis spelling

diff -r freebios2/src/southbridge/amd/amd8111/amd8111_lpc.c
../freebios2/src/southbridge/amd/amd8111/amd8111_lpc.c
173c173
< static void amd8111_lpc_enable_resoruces(device_t dev)
---
> static void amd8111_lpc_enable_resources(device_t dev)



-----Original Message-----
From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
Sent: Thursday, October 21, 2004 7:43 PM
To: YhLu
Cc: LinuxBIOS
Subject: Re: Freebios2 recovery progress... moving enable_childrens_resour
ces

YhLu <YhLu at tyan.com> writes:

> add one call to amd8111 lpc ?

Exactly.  And committed for the amd8111 and the i82801??? chips.

The rest of the southbridges did not appear to an lpc or an isa
bus that I could identify code wise so it appears they have more
that needs to be done to get them into shape.

Eric


From liutao at safe-mail.net  Thu Oct 21 23:03:01 2004
From: liutao at safe-mail.net (Liu Tao)
Date: Thu Oct 21 23:03:01 2004
Subject: Freebios2 recovery progress...
In-Reply-To: <3174569B9743D511922F00A0C94314230665B3FB@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B3FB@TYANWEB>
Message-ID: <41788B9E.2010207@safe-mail.net>

Why devices on amd8131 don't use ioapic in amd8131?

 >You can not test that in arima board. Because all device on 8131 is using
 >ioapic in amd8111.
 >
 >YH
 >



From ebiederman at lnxi.com  Thu Oct 21 23:16:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Oct 21 23:16:00 2004
Subject: Freebios2 recovery progress...
In-Reply-To: <41788B9E.2010207@safe-mail.net>
References: <3174569B9743D511922F00A0C94314230665B3FB@TYANWEB>
	<41788B9E.2010207@safe-mail.net>
Message-ID: <m3r7nrl66n.fsf@maxwell.lnxi.com>

Liu Tao <liutao at safe-mail.net> writes:

> Why devices on amd8131 don't use ioapic in amd8131?

On the ARIMA HDAMA motherboard the devices on the PCI-X
buses created by the amd8131 have their interrupts hooked
to the amd8111.  Leaving the ioapics on the amd8131 unused.

It is a board implementation bug.

Eric


From ebiederman at lnxi.com  Thu Oct 21 23:47:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Oct 21 23:47:01 2004
Subject: FYI: Merge in progress...
In-Reply-To: <1098382691.15883.76.camel@exponential.lanl.gov>
References: <3174569B9743D511922F00A0C94314230665B3A1@TYANWEB>
	<m3lle0lr3q.fsf@maxwell.lnxi.com>
	<1098368973.15883.39.camel@exponential.lanl.gov>
	<m3is94uf2i.fsf@maxwell.lnxi.com>
	<1098382691.15883.76.camel@exponential.lanl.gov>
Message-ID: <m3mzyfl5ti.fsf@maxwell.lnxi.com>

Li-Ta Lo <ollie at lanl.gov> writes:

> On Thu, 2004-10-21 at 12:00, Eric W. Biederman wrote:
> > At this point we should be able to look at the device tree and
> > see if we need to use and io range register or the RdRam WrDram bits.
> > 
> 
> Are you talking somthing in my mind ? I hope in the mtrr.c for K8
> instead of hack with the mem_map we have:

Ok I just put in amd_mtrr.c the equivalent of what you had in
mtrr.c  At least with respect to the fixed mtrrs.

Things still need to be refined quite a bit, but this should be a good
start for the short term.

Eric


From rminnich at lanl.gov  Fri Oct 22 00:09:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Fri Oct 22 00:09:00 2004
Subject: FYI: Merge in progress...
In-Reply-To: <m3pt3bo3ca.fsf@maxwell.lnxi.com>
References: <3174569B9743D511922F00A0C94314230665B3A1@TYANWEB>
 <m3lle0lr3q.fsf@maxwell.lnxi.com> <1098368973.15883.39.camel@exponential.lanl.gov>
 <m3is94uf2i.fsf@maxwell.lnxi.com> <1098382691.15883.76.camel@exponential.lanl.gov>
 <m3pt3bo3ca.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.58.0410212329520.14508@linux.site>


On Thu, 21 Oct 2004, Eric W. Biederman wrote:

> It looks like it would be profitable for me to look through
> the old cpu directories and see what code changes I have 
> missed.  
> 

and, ah, <cough>, commit more often. 

"Be more committed" :-)

ron


From rminnich at lanl.gov  Fri Oct 22 00:17:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Fri Oct 22 00:17:01 2004
Subject: Freebios2 recovery progress... (fwd)
Message-ID: <Pine.LNX.4.58.0410212336550.14508@linux.site>

Just a little note. From this day forward, if I get a bounce like this for 
harmless mail, I'm going to remove that person from the list. In the case 
of harmanbecker.com, I've tried to get them to fix their stupid filter and 
gotten nowhere. Sorry to have to be so mean about this.

thanks

ron

---------- Forwarded message ----------
Date: Fri, 22 Oct 2004 06:29:48 +02120 (MEST)
From: contentfilter at harmanbecker.com
To: linuxbios-admin at clustermatic.org
Subject: RE: Re: Freebios2 recovery progress...

Absender/Sender: linuxbios-admin at clustermatic.org
Betreff/Subject: Re: Freebios2 recovery progress...
Datum/Date: Fri, 22 Oct 2004 12:25:02 +0800
Empf?nger/Recipients: IBaab at becker.de
mrosen at becker.de

Nachrichten-ID/Message ID: T6ccbbc5993ac10df0f4c0

[DEUTSCHER TEXT - SIEHE UNTEN]

************************************************** 
[ENGLISH VERSION - PLEASE READ NOTE CAREFULLY] 

Dear Sender : 

Your message has not been delivered to the recipient at harmanbecker.com.  Your message has been classified as unsolicited automatic mass advertising email (spam) by our email content filtering systems.

!!!!  Should this have happened in error, and you wish to send this mail to your recipient, please resend the message with the following text in the message body :  nospam231   !!!!  Our systems will then automatically deliver the email to the recipients within the harmanbecker organization.

We apologize for the inconvenience but this is required in order to prevent the mass mailing of several spam filters into our organization.  If your organization communicates on a very regular basis with Harman/Becker, please contact your Harman/Becker internal contact and ask them to contact their internal IT department.  Upon verification, your organization's email address can be added to our "safe lists" thus enabling future communication without SPAM filtering.

This is an automatically generated email.Do not reply directly. For further inquiry please contact mailsweeper at harmanbecker.com

************************************************** 

Die Nachricht wurde nicht zugestellt!
Sie wurde von unseren Content Filtern als unerwuenschte automatische Massenwerbemail (Spam) klassifiziert und gesperrt.
Falls es sich hierbei um einen Irrtum handelt, senden Sie Ihre Nachricht bitte noch einmal, indem Sie an beliebiger Stelle im Nachrichtentext folgendes Schluesselwort hinzufuegen: nospam231
Falls Ihre Nachrichten haeufig faelschlicherweise als Spam klassifiziert werden, benachrichtigen Sie uns bitte unter nachfolgender Mailadresse: mailsweeper at harmanbecker.com. Wir werden Sie dann in unsere Liste bekannter Sender aufnehmen.

Dies ist eine automatisch generierte EMail! Antworten Sie nicht direkt darauf. Bei Rueckfragen wenden Sie sich bitte an mailsweeper at harmanbecker.com


From joshua at joshuawise.com  Fri Oct 22 00:32:00 2004
From: joshua at joshuawise.com (Joshua Wise)
Date: Fri Oct 22 00:32:00 2004
Subject: Dunno if you guys have seen this or not...
Message-ID: <4178A059.8060105@joshuawise.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dunno if you guys have seen this or not, but slashdot is reporting on a
discussion on LKML about the possibility of an open-hardware video card
with an open-source BIOS.

http://linux.slashdot.org/article.pl?sid=04/10/22/021213&threshold=0&tid=152&tid=137&tid=1&tid=106

joshua
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBeKBYPn9tWOqA4LMRAmrwAKCbMsyCqWxpT8S4880lGvqA/Xc/XQCdFZYk
SI0xgsnM9JLGVsgZeayqpUk=
=ULzN
-----END PGP SIGNATURE-----


From rminnich at lanl.gov  Fri Oct 22 00:42:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Fri Oct 22 00:42:01 2004
Subject: Dunno if you guys have seen this or not...
In-Reply-To: <4178A059.8060105@joshuawise.com>
References: <4178A059.8060105@joshuawise.com>
Message-ID: <Pine.LNX.4.58.0410220002290.14508@linux.site>


> Dunno if you guys have seen this or not, but slashdot is reporting on a
> discussion on LKML about the possibility of an open-hardware video card
> with an open-source BIOS.

I love the idea but wonder if it can be economically feasible.

ron


From spirit at reactor.ru  Fri Oct 22 01:27:00 2004
From: spirit at reactor.ru (Alexander Amelkin)
Date: Fri Oct 22 01:27:00 2004
Subject: Is Linuxbios alive as of now?
Message-ID: <1424185733.20041022104805@amelkin.msk.ru>

Hi all!

 With all that "Merge in progress" and "Recovery progress" stuff, is
 the current CVS snapshot suitable for use with EPIA MII ? Or should I
 wait some time before trying it? How soon is it planned to finish all
 that "merger"?

-- 
With best regards,
 Alexander                          mailto:spirit at reactor.ru



From stepan at openbios.org  Fri Oct 22 03:08:01 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Fri Oct 22 03:08:01 2004
Subject: Is Linuxbios alive as of now?
In-Reply-To: <1424185733.20041022104805@amelkin.msk.ru>
References: <1424185733.20041022104805@amelkin.msk.ru>
Message-ID: <20041022082856.GA11527@openbios.org>

* Alexander Amelkin <spirit at reactor.ru> [041022 08:48]:
> Hi all!
> 
>  With all that "Merge in progress" and "Recovery progress" stuff, is
>  the current CVS snapshot suitable for use with EPIA MII ? Or should I
>  wait some time before trying it? How soon is it planned to finish all
>  that "merger"?
 
Talking about freebios2, epia-m does not build currently. You will
either have to wait or look into fixing it ;-))

Stefan




From zhushisongzhu at yahoo.com  Fri Oct 22 05:33:00 2004
From: zhushisongzhu at yahoo.com (zhu shi song)
Date: Fri Oct 22 05:33:00 2004
Subject: about i845gv ddr sdram init
Message-ID: <20041022105343.2662.qmail@web13201.mail.yahoo.com>

After working hard about two weeks, I can't init sdram
successfully.  I'll attach the raminit.inc please help
me check what's wrong.  I've contacted with intel,
they wouldn't like to provide me red book.
  tks
  zhu



		
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: raminit.inc
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20041022/53c43988/attachment.ksh>

From stepan at openbios.org  Fri Oct 22 06:20:01 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Fri Oct 22 06:20:01 2004
Subject: about i845gv ddr sdram init
In-Reply-To: <20041022105343.2662.qmail@web13201.mail.yahoo.com>
References: <20041022105343.2662.qmail@web13201.mail.yahoo.com>
Message-ID: <20041022114041.GA17610@openbios.org>

* zhu shi song <zhushisongzhu at yahoo.com> [041022 12:53]:
> After working hard about two weeks, I can't init sdram
> successfully.  I'll attach the raminit.inc please help
> me check what's wrong.  I've contacted with intel,
> they wouldn't like to provide me red book.

Please go freebios2, the old code should not be enhanced anymore..
v2 allows you to write dram init code in C, which is a lot more readable
and makes it easier to help.

Stefan




From Stephen.Kimball at bench.com  Fri Oct 22 07:44:01 2004
From: Stephen.Kimball at bench.com (Stephen.Kimball at bench.com)
Date: Fri Oct 22 07:44:01 2004
Subject: Makefile changes for symbols
Message-ID: <9B124F08B3EFDA4F8813B05102DC719501A9026A@nh-ex01.nh.bench.com>

Rod,

I'm using Source Point 7.0.0.  I can see the source files.  I can
display source, disassembly or mixed.  However, the disassembly doesn't
match up with the source code.  There is a way to give Source Point an
offset when the symbols are loaded, but I can't seem to get the right
value.  I know the address of _start and __protected_start but these
labels are not in linuxbios_c.o.  I need to find the location of a
symbol in linuxbios_c.o to compute the offset.

Steve 

-----Original Message-----
From: Kittleson, Rodney C. 
Sent: Thursday, October 21, 2004 5:42 PM
To: Kimball, Stephen; linuxbios at clustermatic.org
Cc: Jeff_Pitts at arium.com
Subject: RE: Makefile changes for symbols

Steve, 

What version of Source point are you using? The symbols are coming in
but SourcePoint doesn't allow me to reference the source files.

I mapped the linuxbios directory on my Win2000 system for SourcePoint to
access.  (I have samba running on my linux system) I just need to get
SourcePoint working.

Thanks,
Rod

-----Original Message-----
From: Kimball, Stephen 
Sent: Wednesday, October 20, 2004 1:04 PM
To: Kittleson, Rodney C.; linuxbios at clustermatic.org
Cc: Jeff_Pitts at arium.com
Subject: RE: Makefile changes for symbols


The file under your target in normal/linuxbios_c.o seems to have all the
symbols if you add "-gdwarf-2" to the $CFLAGS in the Makefile.  Then
when you open the first C module the SourcePoint software asks where the
file exists, after you tell SourcePoint it seems to find the rest by
itself.  I recreated the same Linux directory structure on Windows.
Thanks Rod!

Steve  

-----Original Message-----
From: Kittleson, Rodney C. 
Sent: Wednesday, October 20, 2004 11:47 AM
To: Kimball, Stephen; linuxbios at clustermatic.org
Subject: RE: Makefile changes for symbols

Linuxbios_c, from the build directory, can be sucked into Sourcepoint to
extract the symbols. This allows the disassembled instructions to
display the symbols inline. It makes it easier to set breakpoints and
follow the code, but it's a far cry from source level debugging.  

I haven't attempted to link the source with sourcepoint yet. I may try
it later this week, let me know if you have any success.

Rod

-----Original Message-----
From: Kimball, Stephen 
Sent: Tuesday, October 19, 2004 3:33 PM
To: linuxbios at clustermatic.org
Subject: Makefile changes for symbols



Can someone give me the Makefile changes to make a LinuxBIOS with
symbols?  I tried adding "-gdwarf-2" to CFLAGS, but I'm not sure where
the unstripped output would be.  

Are there any features in the code that are useful in debugging
LinuxBIOS? Any defines that should change as well?

Someone must have some experience with source code level debugging of
LinuxBIOS with an American Arium ECM-50.  Thanks.

Steve Kimball
Benchmark Electronics
Hudson, NH 
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From Rodney.Kittleson at bench.com  Fri Oct 22 08:34:00 2004
From: Rodney.Kittleson at bench.com (Rodney.Kittleson at bench.com)
Date: Fri Oct 22 08:34:00 2004
Subject: Makefile changes for symbols
Message-ID: <8E8200E838D692429246225038E1736302771C82@mn-ex02.mn.bench.com>

I have an offset of 4000 for "linuxbios_c.o".  "linuxbios_c" has the
correct addresses and as far as I can tell "linuxbios_c" has all the
symbols "linuxbios_c.o" has.

I just upgraded SP to 7.0.0, source still isn't loaded. Could you give
me a step by step?

Thanks,
Rod

-----Original Message-----
From: Kimball, Stephen 
Sent: Friday, October 22, 2004 8:04 AM
To: Kittleson, Rodney C.; linuxbios at clustermatic.org
Cc: Jeff_Pitts at arium.com
Subject: RE: Makefile changes for symbols


Rod,

I'm using Source Point 7.0.0.  I can see the source files.  I can
display source, disassembly or mixed.  However, the disassembly doesn't
match up with the source code.  There is a way to give Source Point an
offset when the symbols are loaded, but I can't seem to get the right
value.  I know the address of _start and __protected_start but these
labels are not in linuxbios_c.o.  I need to find the location of a
symbol in linuxbios_c.o to compute the offset.

Steve 

-----Original Message-----
From: Kittleson, Rodney C. 
Sent: Thursday, October 21, 2004 5:42 PM
To: Kimball, Stephen; linuxbios at clustermatic.org
Cc: Jeff_Pitts at arium.com
Subject: RE: Makefile changes for symbols

Steve, 

What version of Source point are you using? The symbols are coming in
but SourcePoint doesn't allow me to reference the source files.

I mapped the linuxbios directory on my Win2000 system for SourcePoint to
access.  (I have samba running on my linux system) I just need to get
SourcePoint working.

Thanks,
Rod

-----Original Message-----
From: Kimball, Stephen 
Sent: Wednesday, October 20, 2004 1:04 PM
To: Kittleson, Rodney C.; linuxbios at clustermatic.org
Cc: Jeff_Pitts at arium.com
Subject: RE: Makefile changes for symbols


The file under your target in normal/linuxbios_c.o seems to have all the
symbols if you add "-gdwarf-2" to the $CFLAGS in the Makefile.  Then
when you open the first C module the SourcePoint software asks where the
file exists, after you tell SourcePoint it seems to find the rest by
itself.  I recreated the same Linux directory structure on Windows.
Thanks Rod!

Steve  

-----Original Message-----
From: Kittleson, Rodney C. 
Sent: Wednesday, October 20, 2004 11:47 AM
To: Kimball, Stephen; linuxbios at clustermatic.org
Subject: RE: Makefile changes for symbols

Linuxbios_c, from the build directory, can be sucked into Sourcepoint to
extract the symbols. This allows the disassembled instructions to
display the symbols inline. It makes it easier to set breakpoints and
follow the code, but it's a far cry from source level debugging.  

I haven't attempted to link the source with sourcepoint yet. I may try
it later this week, let me know if you have any success.

Rod

-----Original Message-----
From: Kimball, Stephen 
Sent: Tuesday, October 19, 2004 3:33 PM
To: linuxbios at clustermatic.org
Subject: Makefile changes for symbols



Can someone give me the Makefile changes to make a LinuxBIOS with
symbols?  I tried adding "-gdwarf-2" to CFLAGS, but I'm not sure where
the unstripped output would be.  

Are there any features in the code that are useful in debugging
LinuxBIOS? Any defines that should change as well?

Someone must have some experience with source code level debugging of
LinuxBIOS with an American Arium ECM-50.  Thanks.

Steve Kimball
Benchmark Electronics
Hudson, NH 
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From ollie at lanl.gov  Fri Oct 22 09:09:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Fri Oct 22 09:09:01 2004
Subject: Freebios2 recovery progress...
In-Reply-To: <m3u0sno40q.fsf@maxwell.lnxi.com>
References: <3174569B9743D511922F00A0C94314230665B3F8@TYANWEB>
	 <1098384054.15883.92.camel@exponential.lanl.gov>
	 <m3u0sno40q.fsf@maxwell.lnxi.com>
Message-ID: <1098455402.16598.0.camel@exponential.lanl.gov>

On Thu, 2004-10-21 at 20:55, Eric W. Biederman wrote:
> Li-Ta Lo <ollie at lanl.gov> writes:
> 
> > On Thu, 2004-10-21 at 12:14, YhLu wrote:
> > > I agree that all onboard device should use the same subsystem id as MB's.
> > > 
> > 
> > One interesting thing. In PCI Spec 2.2, section 6.2.4 it says that:
> > 
> > 	Values in these registers must be loaded and valid prioir to the
> > 	system BIOS or any system software accessing the PCI 
> > 	Coniguration Space. blah,blah, blah. These values must not be 
> > 	loaded using expansion ROM software becuase expansion ROM 
> > 	software is not guaranteed to be run during POST 
> > 	in all systems.
> > 
> > Are we doing something out of spec ?
> 
> I think it is more a matter of the spec no governing for
> onboard devices.  For any devices that is implemented on a plug-in
> card I believe that governs.
>  
> > BTW, why I can't download PCI spec form PCI-SIG anymore ? Even for
> > the 'useless' PCI conventional stuff.
> 
> I have never been able to download it so it is news to me that
> was possible.
> 

How did you implement PCI stuff ?

Ollie




From ollie at lanl.gov  Fri Oct 22 09:14:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Fri Oct 22 09:14:01 2004
Subject: Freebios2 recovery progress... pci64 mem optimization
In-Reply-To: <m3655333p0.fsf@maxwell.lnxi.com>
References: <3174569B9743D511922F00A0C94314230665B499@TYANWEB>
	 <m3655333p0.fsf@maxwell.lnxi.com>
Message-ID: <1098455733.16598.3.camel@exponential.lanl.gov>

On Thu, 2004-10-21 at 20:08, Eric W. Biederman wrote:
> YhLu <YhLu at tyan.com> writes:
> 
> > If no agp,
> > Still need gart?
> > 
> > YH
> > 
> > PCI: 00:18.3 94 <- [0x00f8000000 - 0x00fbffffff] mem <gart>
> > PCI: 00:19.3 94 <- [0x00f8000000 - 0x00fbffffff] mem <gart>
> 
> With more than 4GB of memory it is used as an IOMMU so you don't
> need bounce buffers.
> 

Could you tell me more about this ? Is "bounce buffer" that bounce
buffer for PCI DMA in the kernel ? How does an AGP aperture solve
it ?

Ollie




From stepan at openbios.org  Fri Oct 22 09:18:01 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Fri Oct 22 09:18:01 2004
Subject: changes today.
In-Reply-To: <3174569B9743D511922F00A0C94314230624C5E1@TYANWEB>
References: <3174569B9743D511922F00A0C94314230624C5E1@TYANWEB>
Message-ID: <20041022143918.GA20867@openbios.org>

* YhLu <YhLu at tyan.com> [040930 21:00]:
> Ron/Eric/Stephan/Ollie,
> 
> Please check the patch.
> 
> 1. some tyan volatile messing because of ROMCC changes.
> 2. S2882 interrupt line assignment in mptable.c
> 3. exclude range for flash_rom.
> 4. better ht_setup_chainx() in incoherent_ht.c ---> change share bus 0 to
> different bus for different incoherent HT link.
> 5. fix one bug about io and mem allocation for multi ht links. --- in
> northbridge.c
> 	Mark it if used before assign final value.
> 6. enable amd/quartet to init multi incoherent HT link in auto.c --- not
> test, no MB on hand.
> 7. enable S2885 to init multi incoherent HT link in auto.c

Have all these been commited now?

Stefan



From rminnich at lanl.gov  Fri Oct 22 10:02:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Fri Oct 22 10:02:01 2004
Subject: Is Linuxbios alive as of now?
In-Reply-To: <1424185733.20041022104805@amelkin.msk.ru>
References: <1424185733.20041022104805@amelkin.msk.ru>
Message-ID: <Pine.LNX.4.58.0410220922140.15797@linux.site>


On Fri, 22 Oct 2004, Alexander Amelkin wrote:

>  With all that "Merge in progress" and "Recovery progress" stuff, is the
>  current CVS snapshot suitable for use with EPIA MII ? Or should I wait
>  some time before trying it? How soon is it planned to finish all that
>  "merger"?

well, here's the issue. Ollie and I have to go live in Infiniband Hell for 
the next 6 days. Then the week after that I will try to do EPIA, and if 
that goes, EPIA M-II. 

Don't do an update until I say "EPIA works" or "EPIA MII" works or some 
such. 

Or if you want, try to do EPIA MII yourself -- my guess is you will be 
happy with the ease with which you can do the port. 

The code base is really a LOT better.

ron


From rminnich at lanl.gov  Fri Oct 22 10:09:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Fri Oct 22 10:09:00 2004
Subject: about i845gv ddr sdram init
In-Reply-To: <20041022105343.2662.qmail@web13201.mail.yahoo.com>
References: <20041022105343.2662.qmail@web13201.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0410220929250.15797@linux.site>


On Fri, 22 Oct 2004, zhu shi song wrote:

> After working hard about two weeks, I can't init sdram successfully.  
> I'll attach the raminit.inc please help me check what's wrong.  I've
> contacted with intel, they wouldn't like to provide me red book.


you'll get no help from intel. 

We're just going to have to work this one out.

ron


From rminnich at lanl.gov  Fri Oct 22 10:12:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Fri Oct 22 10:12:00 2004
Subject: about i845gv ddr sdram init
In-Reply-To: <20041022114041.GA17610@openbios.org>
References: <20041022105343.2662.qmail@web13201.mail.yahoo.com>
 <20041022114041.GA17610@openbios.org>
Message-ID: <Pine.LNX.4.58.0410220930380.15797@linux.site>


On Fri, 22 Oct 2004, Stefan Reinauer wrote:

> * zhu shi song <zhushisongzhu at yahoo.com> [041022 12:53]:
> > After working hard about two weeks, I can't init sdram
> > successfully.  I'll attach the raminit.inc please help
> > me check what's wrong.  I've contacted with intel,
> > they wouldn't like to provide me red book.
> 
> Please go freebios2, the old code should not be enhanced anymore..
> v2 allows you to write dram init code in C, which is a lot more readable
> and makes it easier to help.
> 

In fact, look at my (broken) 855gm northbridge code for an example.

ron


From rminnich at lanl.gov  Fri Oct 22 10:16:57 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Fri Oct 22 10:16:57 2004
Subject: Makefile changes for symbols
In-Reply-To: <9B124F08B3EFDA4F8813B05102DC719501A9026A@nh-ex01.nh.bench.com>
References: <9B124F08B3EFDA4F8813B05102DC719501A9026A@nh-ex01.nh.bench.com>
Message-ID: <Pine.LNX.4.58.0410220932580.15797@linux.site>


On Fri, 22 Oct 2004 Stephen.Kimball at bench.com wrote:

> Rod,
> 
> I'm using Source Point 7.0.0.  I can see the source files.  I can
> display source, disassembly or mixed.  However, the disassembly doesn't
> match up with the source code.  There is a way to give Source Point an
> offset when the symbols are loaded, but I can't seem to get the right
> value.  I know the address of _start and __protected_start but these
> labels are not in linuxbios_c.o.  I need to find the location of a
> symbol in linuxbios_c.o to compute the offset.

there is a file we create called linuxbios.map, did you check that out?

ron


From Rodney.Kittleson at bench.com  Fri Oct 22 10:27:00 2004
From: Rodney.Kittleson at bench.com (Rodney.Kittleson at bench.com)
Date: Fri Oct 22 10:27:00 2004
Subject: Makefile changes for symbols
Message-ID: <8E8200E838D692429246225038E1736302A14ACE@mn-ex02.mn.bench.com>

Yep.  The format isn't compatible with SourcePoint. 

Rod

-----Original Message-----
From: Ronald G. Minnich [mailto:rminnich at lanl.gov] 
Sent: Friday, October 22, 2004 10:33 AM
To: Kimball, Stephen
Cc: Kittleson, Rodney C.; linuxbios at clustermatic.org;
Jeff_Pitts at arium.com
Subject: RE: Makefile changes for symbols




On Fri, 22 Oct 2004 Stephen.Kimball at bench.com wrote:

> Rod,
> 
> I'm using Source Point 7.0.0.  I can see the source files.  I can 
> display source, disassembly or mixed.  However, the disassembly 
> doesn't match up with the source code.  There is a way to give Source 
> Point an offset when the symbols are loaded, but I can't seem to get 
> the right value.  I know the address of _start and __protected_start 
> but these labels are not in linuxbios_c.o.  I need to find the 
> location of a symbol in linuxbios_c.o to compute the offset.

there is a file we create called linuxbios.map, did you check that out?

ron


From daubin at actuality-systems.com  Fri Oct 22 10:41:00 2004
From: daubin at actuality-systems.com (Dave Aubin)
Date: Fri Oct 22 10:41:00 2004
Subject: Makefile changes for symbols
Message-ID: <E8F8DBCB0468204E856114A2CD20741F2C1B0F@mail.local.ActualitySystems.com>

Hi,

  I don't know if this is your problem or not, but I have seen
Issues when using #if 0 or #ifdef <something no set> causing 
Alignment issues.   What you co do is run the file through the
Pre-procesor to generate output as what the compiler sees and then
Use this as your source.  Windows .net actuality is the one I've
Seen this alignment issue with.  That might be it.

Dave

-----Original Message-----
From: linuxbios-admin at clustermatic.org
[mailto:linuxbios-admin at clustermatic.org] On Behalf Of Ronald G. Minnich
Sent: Friday, October 22, 2004 11:33 AM
To: Stephen.Kimball at bench.com
Cc: Rodney.Kittleson at bench.com; linuxbios at clustermatic.org;
Jeff_Pitts at arium.com
Subject: RE: Makefile changes for symbols



On Fri, 22 Oct 2004 Stephen.Kimball at bench.com wrote:

> Rod,
> 
> I'm using Source Point 7.0.0.  I can see the source files.  I can 
> display source, disassembly or mixed.  However, the disassembly 
> doesn't match up with the source code.  There is a way to give Source 
> Point an offset when the symbols are loaded, but I can't seem to get 
> the right value.  I know the address of _start and __protected_start 
> but these labels are not in linuxbios_c.o.  I need to find the 
> location of a symbol in linuxbios_c.o to compute the offset.

there is a file we create called linuxbios.map, did you check that out?

ron
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From Rodney.Kittleson at bench.com  Fri Oct 22 10:54:00 2004
From: Rodney.Kittleson at bench.com (Rodney.Kittleson at bench.com)
Date: Fri Oct 22 10:54:00 2004
Subject: Makefile changes for symbols
Message-ID: <8E8200E838D692429246225038E1736302771C83@mn-ex02.mn.bench.com>

Thanks Ron, I'm a little slow today.

Steve,
The linuxbios_c.map file should help you find the offset you need for
importing linuxbios_c.o into SourcePoint. The map file itself cannot be
imported.  

Rod

-----Original Message-----
From: Kittleson, Rodney C. 
Sent: Friday, October 22, 2004 10:47 AM
To: 'Ronald G. Minnich'; Kimball, Stephen
Cc: linuxbios at clustermatic.org; Jeff_Pitts at arium.com
Subject: RE: Makefile changes for symbols


Yep.  The format isn't compatible with SourcePoint. 

Rod

-----Original Message-----
From: Ronald G. Minnich [mailto:rminnich at lanl.gov] 
Sent: Friday, October 22, 2004 10:33 AM
To: Kimball, Stephen
Cc: Kittleson, Rodney C.; linuxbios at clustermatic.org;
Jeff_Pitts at arium.com
Subject: RE: Makefile changes for symbols




On Fri, 22 Oct 2004 Stephen.Kimball at bench.com wrote:

> Rod,
> 
> I'm using Source Point 7.0.0.  I can see the source files.  I can
> display source, disassembly or mixed.  However, the disassembly 
> doesn't match up with the source code.  There is a way to give Source 
> Point an offset when the symbols are loaded, but I can't seem to get 
> the right value.  I know the address of _start and __protected_start 
> but these labels are not in linuxbios_c.o.  I need to find the 
> location of a symbol in linuxbios_c.o to compute the offset.

there is a file we create called linuxbios.map, did you check that out?

ron


From ebiederman at lnxi.com  Fri Oct 22 11:03:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Oct 22 11:03:00 2004
Subject: Is Linuxbios alive as of now?
In-Reply-To: <20041022082856.GA11527@openbios.org>
References: <1424185733.20041022104805@amelkin.msk.ru>
	<20041022082856.GA11527@openbios.org>
Message-ID: <m3zn2evhzh.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at openbios.org> writes:

> * Alexander Amelkin <spirit at reactor.ru> [041022 08:48]:
> > Hi all!
> > 
> >  With all that "Merge in progress" and "Recovery progress" stuff, is
> >  the current CVS snapshot suitable for use with EPIA MII ? Or should I
> >  wait some time before trying it? How soon is it planned to finish all
> >  that "merger"?
>  
> Talking about freebios2, epia-m does not build currently. You will
> either have to wait or look into fixing it ;-))

Alternatively you can do a cvs checkout with the date set earlier
than the 14th of October and you can get the last version that built.

The epia and epia-m ports have been in barely functional for a while.
And the current code base cleanups have pushed them over the edge.

The core work of the merger and core code enhancements are done
now it is just a matter of getting everything cleaned up so that
it will build and work again.  And that requires people who
can test the motherboard ports...

Eric


From ebiederman at lnxi.com  Fri Oct 22 11:11:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Oct 22 11:11:01 2004
Subject: about i845gv ddr sdram init
In-Reply-To: <20041022105343.2662.qmail@web13201.mail.yahoo.com>
References: <20041022105343.2662.qmail@web13201.mail.yahoo.com>
Message-ID: <m3vfd2vhn1.fsf@maxwell.lnxi.com>

zhu shi song <zhushisongzhu at yahoo.com> writes:

> After working hard about two weeks, I can't init sdram
> successfully.  I'll attach the raminit.inc please help
> me check what's wrong.  I've contacted with intel,
> they wouldn't like to provide me red book.

Hmm. It should not require anything more than a yellow book.
Basically Intel does not like to publicly document all of their
registers and occasionally that is the problem.

The thing not to expect is for any vendor to hold your hand.

Where I usually start is with a hard coded configuration for
a particular DIMM configuration.  And I will verify that the
DIMMs are known good so I don't have to worry about the hardware.

Where are you at in this process and what problems are you seeing?

Eric


From don at bowery.com  Fri Oct 22 11:14:00 2004
From: don at bowery.com (Don Elwell)
Date: Fri Oct 22 11:14:00 2004
Subject: about i845gv ddr sdram init
Message-ID: <417936CF.3020506@bowery.com>

I burned a ton of time on this a while ago but got nowhere.  It would 
seem that Intel provides only partial documentation for their chipsets 
on their web site.  I discovered that there are hidden/undocumented 
registers used in the DDR SDRAM setup (there are probably others).  I 
also tried in vain to get a contact there but again came up empty 
handed.  In the end, we ended up going with a different chipset 
manufacturer.

Ron,  where did you get information for your 855 port in v2?  Is it 
broken for the "hidden registers" reason?

-don




From rminnich at lanl.gov  Fri Oct 22 11:17:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Fri Oct 22 11:17:00 2004
Subject: Makefile changes for symbols
In-Reply-To: <8E8200E838D692429246225038E1736302A14ACE@mn-ex02.mn.bench.com>
References: <8E8200E838D692429246225038E1736302A14ACE@mn-ex02.mn.bench.com>
Message-ID: <Pine.LNX.4.58.0410221037540.15945@linux.site>


On Fri, 22 Oct 2004 Rodney.Kittleson at bench.com wrote:

> Yep.  The format isn't compatible with SourcePoint. 

I was only thinking you could use that as a source of correct values, not 
that it would be usable by sourcepoint directly. 

ron


From ebiederman at lnxi.com  Fri Oct 22 11:20:07 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Oct 22 11:20:07 2004
Subject: Freebios2 recovery progress...
In-Reply-To: <1098455402.16598.0.camel@exponential.lanl.gov>
References: <3174569B9743D511922F00A0C94314230665B3F8@TYANWEB>
	<1098384054.15883.92.camel@exponential.lanl.gov>
	<m3u0sno40q.fsf@maxwell.lnxi.com>
	<1098455402.16598.0.camel@exponential.lanl.gov>
Message-ID: <m3r7nqvhdc.fsf@maxwell.lnxi.com>

Li-Ta Lo <ollie at lanl.gov> writes:

> How did you implement PCI stuff ?

There are also several books you can buy that go into detail,
usually those are more understandable than the spec.  Although
the spec is more precise. 

In addition Linux Networx has copies of some of the PCI specs that
I have referred  to. 

However the hardest part of the work has been the resource allocator
which simply requires understanding how a BAR register works.  And
creativity in how to figure out how to assign the BAR values.

So for most things looking at pci_def.h and pci_ids.h is generally about
as much reference as is needed.

Eric


From ebiederman at lnxi.com  Fri Oct 22 11:22:48 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Oct 22 11:22:48 2004
Subject: Freebios2 recovery progress... pci64 mem optimization
In-Reply-To: <1098455733.16598.3.camel@exponential.lanl.gov>
References: <3174569B9743D511922F00A0C94314230665B499@TYANWEB>
	<m3655333p0.fsf@maxwell.lnxi.com>
	<1098455733.16598.3.camel@exponential.lanl.gov>
Message-ID: <m34qkmwwtm.fsf@maxwell.lnxi.com>

Li-Ta Lo <ollie at lanl.gov> writes:

> On Thu, 2004-10-21 at 20:08, Eric W. Biederman wrote:
> > With more than 4GB of memory it is used as an IOMMU so you don't
> > need bounce buffers.
> > 
> 
> Could you tell me more about this ? 

Some.

> Is "bounce buffer" that bounce buffer for PCI DMA in the kernel ? 

Yes.  The simple explanation is that without an IOMMU the
PCI hardware that is not capable of DAC cycles must DMA to
and address below 4GB.  If it is desired for that data to
be above 4GB a temporary buffer is allocated below for
4GB (a bounce buffer) and after the DMA is complete the data
is copied to the destination buffer.

The kernel swiotlb code from the ia64 implements this behavior.

> How does an AGP aperture solve it ?

Because you can allocate a DMA target address below 4GB that
points to memory above 4GB.  So long as the IOUMMU setup is less
expensive than the memory copy this is a win.

Eric


From rminnich at lanl.gov  Fri Oct 22 11:26:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Fri Oct 22 11:26:01 2004
Subject: Is Linuxbios alive as of now?
In-Reply-To: <m3zn2evhzh.fsf@maxwell.lnxi.com>
References: <1424185733.20041022104805@amelkin.msk.ru> <20041022082856.GA11527@openbios.org>
 <m3zn2evhzh.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.58.0410221041310.15945@linux.site>


On Fri, 22 Oct 2004, Eric W. Biederman wrote:

> The epia and epia-m ports have been in barely functional for a while.

??

you must not have used them. I've been using EPIA for some 14 months now
and they work fine, for both Linux and Plan 9.

Maybe what you meant is "Eric never liked that code anyways, so it's no 
loss" :-)

> And the current code base cleanups have pushed them over the edge.

That I'll believe. 

ron


From rminnich at lanl.gov  Fri Oct 22 11:28:39 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Fri Oct 22 11:28:39 2004
Subject: Makefile changes for symbols
In-Reply-To: <E8F8DBCB0468204E856114A2CD20741F2C1B0F@mail.local.ActualitySystems.com>
References: <E8F8DBCB0468204E856114A2CD20741F2C1B0F@mail.local.ActualitySystems.com>
Message-ID: <Pine.LNX.4.58.0410221039240.15945@linux.site>


On Fri, 22 Oct 2004, Dave Aubin wrote:

>   I don't know if this is your problem or not, but I have seen
> Issues when using #if 0 or #ifdef <something no set> causing 
> Alignment issues.   What you co do is run the file through the
> Pre-procesor to generate output as what the compiler sees and then
> Use this as your source.  Windows .net actuality is the one I've
> Seen this alignment issue with.  That might be it.

I think it's an actual thing a compiler supports or does not. The Xen guy 
was horrified that 8c didn't just support it ... "how do you write 
drivers" etc. 


Here's where I put in some obligatory old-fart reminiscence about V6 C and
how it laid out structs but I'm too tired to do it.

ron


From YhLu at tyan.com  Fri Oct 22 11:32:00 2004
From: YhLu at tyan.com (YhLu)
Date: Fri Oct 22 11:32:00 2004
Subject: changes today.
Message-ID: <3174569B9743D511922F00A0C94314230665B4C5@TYANWEB>

4, 6, 7 done Tuesday.
5 is not nesscery, eric have use compare resource with 0x100+res+links in
dev 0x18,0.

Regards

YH

-----Original Message-----
From: Stefan Reinauer [mailto:stepan at openbios.org] 
Sent: Friday, October 22, 2004 7:39 AM
To: YhLu
Cc: Ronald G. Minnich; ebiederman at lnxi.com; Li-Ta Lo;
linuxbios at clustermatic.org
Subject: Re: changes today.

* YhLu <YhLu at tyan.com> [040930 21:00]:
> Ron/Eric/Stephan/Ollie,
> 
> Please check the patch.
> 
> 1. some tyan volatile messing because of ROMCC changes.
> 2. S2882 interrupt line assignment in mptable.c
> 3. exclude range for flash_rom.
> 4. better ht_setup_chainx() in incoherent_ht.c ---> change share bus 0 to
> different bus for different incoherent HT link.
> 5. fix one bug about io and mem allocation for multi ht links. --- in
> northbridge.c
> 	Mark it if used before assign final value.
> 6. enable amd/quartet to init multi incoherent HT link in auto.c --- not
> test, no MB on hand.
> 7. enable S2885 to init multi incoherent HT link in auto.c

Have all these been commited now?

Stefan


From rminnich at lanl.gov  Fri Oct 22 11:34:38 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Fri Oct 22 11:34:38 2004
Subject: about i845gv ddr sdram init
In-Reply-To: <417936CF.3020506@bowery.com>
References: <417936CF.3020506@bowery.com>
Message-ID: <Pine.LNX.4.58.0410221044470.15945@linux.site>


On Fri, 22 Oct 2004, Don Elwell wrote:

> 
> I burned a ton of time on this a while ago but got nowhere.  It would seem
> that Intel provides only partial documentation for their chipsets on their web
> site.  I discovered that there are hidden/undocumented registers used in the
> DDR SDRAM setup (there are probably others).  I also tried in vain to get a
> contact there but again came up empty handed.  In the end, we ended up going
> with a different chipset manufacturer.

I hear this story about Intel a lot. Every intel port we've done has had
an issue of undocumented behavior, except I think for the 440BX. 

Other vendors's parts do also have undocumented behavior but the level of 
helpfulness at some of them is better than Intel. I keep hoping things 
will get better with Intel because I do like their parts and the fact that 
once a part comes out it's stable for a long time. 

> Ron,  where did you get information for your 855 port in v2?  Is it broken for
> the "hidden registers" reason?

I got the info from the public web site, and yes I'm hung up due to lack 
of real info. The question is, is it worth the effort to do this pentium-M 
with such a lack of vendor support, or is time better spent with vendors 
who want to work with you (AMD, IBM, others)? For now I'm putting my time 
into vendors who want to play nice. Pentium-M is turned off for a while.


ron


From ebiederman at lnxi.com  Fri Oct 22 11:38:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Oct 22 11:38:01 2004
Subject: Is Linuxbios alive as of now?
In-Reply-To: <Pine.LNX.4.58.0410221041310.15945@linux.site>
References: <1424185733.20041022104805@amelkin.msk.ru>
	<20041022082856.GA11527@openbios.org>
	<m3zn2evhzh.fsf@maxwell.lnxi.com>
	<Pine.LNX.4.58.0410221041310.15945@linux.site>
Message-ID: <m37jpipu7u.fsf@maxwell.lnxi.com>

"Ronald G. Minnich" <rminnich at lanl.gov> writes:

> On Fri, 22 Oct 2004, Eric W. Biederman wrote:
> 
> > The epia and epia-m ports have been in barely functional for a while.
> 
> ??
> 
> you must not have used them. I've been using EPIA for some 14 months now
> and they work fine, for both Linux and Plan 9.
> 
> Maybe what you meant is "Eric never liked that code anyways, so it's no 
> loss" :-)

What I meant was that the code structure has been barely functional.

The code worked and I don't like the fact that it is broken at all.  
That is one of the reasons I have been working like mad to get the ports
in the LinuxBIOS tree up and going again.

> > And the current code base cleanups have pushed them over the edge.
> 
> That I'll believe. 

The difference from some of the other ports is those were just
a matter of fixing up the references to the new way of handling things.

With the epia and epia-m ports you can't do that with simple code inspection.

If you know how things are supposed to work and can test it.  Putting
Humpty-Dumpty back together again should still be fairly doable.  But
it is not something someone who does not have a board and is not
familiar with the details of the port can reasonably try. 

Eric


From YhLu at tyan.com  Fri Oct 22 11:40:38 2004
From: YhLu at tyan.com (YhLu)
Date: Fri Oct 22 11:40:38 2004
Subject: Freebios2 recovery progress...
Message-ID: <3174569B9743D511922F00A0C94314230665B4C8@TYANWEB>

Design problem, should use ioapic in 8131.

-----Original Message-----
From: Liu Tao [mailto:liutao at safe-mail.net] 
Sent: Thursday, October 21, 2004 9:25 PM
To: YhLu
Cc: ebiederman at lnxi.com; LinuxBIOS
Subject: Re: Freebios2 recovery progress...

Why devices on amd8131 don't use ioapic in amd8131?

 >You can not test that in arima board. Because all device on 8131 is using
 >ioapic in amd8111.
 >
 >YH
 >


From ebiederman at lnxi.com  Fri Oct 22 11:51:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Oct 22 11:51:00 2004
Subject: FYI: Merge in progress...
In-Reply-To: <Pine.LNX.4.58.0410212329520.14508@linux.site>
References: <3174569B9743D511922F00A0C94314230665B3A1@TYANWEB>
	<m3lle0lr3q.fsf@maxwell.lnxi.com>
	<1098368973.15883.39.camel@exponential.lanl.gov>
	<m3is94uf2i.fsf@maxwell.lnxi.com>
	<1098382691.15883.76.camel@exponential.lanl.gov>
	<m3pt3bo3ca.fsf@maxwell.lnxi.com>
	<Pine.LNX.4.58.0410212329520.14508@linux.site>
Message-ID: <m3fz46llsr.fsf@maxwell.lnxi.com>

"Ronald G. Minnich" <rminnich at lanl.gov> writes:

> On Thu, 21 Oct 2004, Eric W. Biederman wrote:
> 
> > It looks like it would be profitable for me to look through
> > the old cpu directories and see what code changes I have 
> > missed.  
> > 
> 
> and, ah, <cough>, commit more often. 
> 
> "Be more committed" :-)

Ron that joke is getting real old.  Especially when I am working hard to
get all of the pieces sorted out.

The joke actually grates when it comes to this piece of code
especially as you asked me to hold of on committing  these changes and
then before we could resolve anything LANL had 2 months of downtime.

I was intending to be very careful about breaking things at that
point.  But at this were delayed so much I figured it was much
healthier to go ahead push in the code reorganization and break
everything, and then pick up the pieces.

If time were not a finite resource I could do more...
Hmm....  Ron do you know if any of the research at LANL is working
on something that could help with this problem?

Eric


From ebiederman at lnxi.com  Fri Oct 22 11:53:59 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Oct 22 11:53:59 2004
Subject: Makefile changes for symbols
In-Reply-To: <9B124F08B3EFDA4F8813B05102DC719501A9026A@nh-ex01.nh.bench.com>
References: <9B124F08B3EFDA4F8813B05102DC719501A9026A@nh-ex01.nh.bench.com>
Message-ID: <m3d5zallqp.fsf@maxwell.lnxi.com>

<Stephen.Kimball at bench.com> writes:

> Rod,
> 
> I'm using Source Point 7.0.0.  I can see the source files.  I can
> display source, disassembly or mixed.  However, the disassembly doesn't
> match up with the source code.  There is a way to give Source Point an
> offset when the symbols are loaded, but I can't seem to get the right
> value.  I know the address of _start and __protected_start but these
> labels are not in linuxbios_c.o.  I need to find the location of a
> symbol in linuxbios_c.o to compute the offset.

???

linuxbios_c is run at an absolute location in memory so the address
of the symbols within it should be fine.

Look at readelf -a linuxbios_c.  

Now these are not addresses within the rom chip.  The are the addresses
the code is copied to after memory initialization.

Currently romcc which generates the code that executes immediately
out of the rom chip does not give good debugging output.  But
you should still be able to see the assembly.  crt0.s should
match what you are looking at.

You don't have the debugger in 16bit mode or something do you?

Eric


From stephen.kimball at bench.com  Fri Oct 22 11:56:37 2004
From: stephen.kimball at bench.com (Steve Kimball)
Date: Fri Oct 22 11:56:37 2004
Subject: Makefile changes for symbols
In-Reply-To: <Pine.LNX.4.58.0410220932580.15797@linux.site>
References: <9B124F08B3EFDA4F8813B05102DC719501A9026A@nh-ex01.nh.bench.com>
	 <Pine.LNX.4.58.0410220932580.15797@linux.site>
Message-ID: <1098465160.3565.6.camel@localhost.localdomain>

On Fri, 2004-10-22 at 11:33, Ronald G. Minnich wrote:
> On Fri, 22 Oct 2004 Stephen.Kimball at bench.com wrote:
> 
> > Rod,
> > 
> > I'm using Source Point 7.0.0.  I can see the source files.  I can
> > display source, disassembly or mixed.  However, the disassembly doesn't
> > match up with the source code.  There is a way to give Source Point an
> > offset when the symbols are loaded, but I can't seem to get the right
> > value.  I know the address of _start and __protected_start but these
> > labels are not in linuxbios_c.o.  I need to find the location of a
> > symbol in linuxbios_c.o to compute the offset.
> 
> there is a file we create called linuxbios.map, did you check that out?
> 
> ron

Since you brought it up.  What's the Lxxxx stuff in the linuxbios.map
file.  There seems to be lots of labels starting with a "L" on the
crt0.s code?

It looks like crt0.s runs first.  The crt0.s code resets the process or
3 times.  crt0.s calls hardwaremain ...

Steve


From rminnich at lanl.gov  Fri Oct 22 12:01:09 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Fri Oct 22 12:01:09 2004
Subject: FYI: Merge in progress...
In-Reply-To: <m3fz46llsr.fsf@maxwell.lnxi.com>
References: <3174569B9743D511922F00A0C94314230665B3A1@TYANWEB>
 <m3lle0lr3q.fsf@maxwell.lnxi.com> <1098368973.15883.39.camel@exponential.lanl.gov>
 <m3is94uf2i.fsf@maxwell.lnxi.com> <1098382691.15883.76.camel@exponential.lanl.gov>
 <m3pt3bo3ca.fsf@maxwell.lnxi.com> <Pine.LNX.4.58.0410212329520.14508@linux.site>
 <m3fz46llsr.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.58.0410221122080.15945@linux.site>


On Fri, 22 Oct 2004, Eric W. Biederman wrote:

> Ron that joke is getting real old.  Especially when I am working hard to
> get all of the pieces sorted out.

sorry! your efforts are always appreciated. 

> If time were not a finite resource I could do more...
> Hmm....  Ron do you know if any of the research at LANL is working
> on something that could help with this problem?

if you don't mind being sucked into a black hole.

ron


From rminnich at lanl.gov  Fri Oct 22 12:04:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Fri Oct 22 12:04:00 2004
Subject: Makefile changes for symbols
In-Reply-To: <1098465160.3565.6.camel@localhost.localdomain>
References: <9B124F08B3EFDA4F8813B05102DC719501A9026A@nh-ex01.nh.bench.com>
  <Pine.LNX.4.58.0410220932580.15797@linux.site> <1098465160.3565.6.camel@localhost.localdomain>
Message-ID: <Pine.LNX.4.58.0410221122370.15945@linux.site>


On Fri, 22 Oct 2004, Steve Kimball wrote:

> Since you brought it up.  What's the Lxxxx stuff in the linuxbios.map
> file.  There seems to be lots of labels starting with a "L" on the
> crt0.s code?

Local symbols.

ron


From ebiederman at lnxi.com  Fri Oct 22 12:07:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Oct 22 12:07:00 2004
Subject: Makefile changes for symbols
In-Reply-To: <9B124F08B3EFDA4F8813B05102DC719501A90264@nh-ex01.nh.bench.com>
References: <9B124F08B3EFDA4F8813B05102DC719501A90264@nh-ex01.nh.bench.com>
Message-ID: <m3k6tiirwo.fsf@maxwell.lnxi.com>

<Stephen.Kimball at bench.com> writes:

> Ron,
> 
> Is LinuxBIOS development done with only serial port debug messages?
> You guys are good.

The code is single threaded, and most of the issues are with respect
to poorly setup registers.  Which requires thinking and reading about.
Since the debuggers give no insight into how the rest of the hardware works
I don't see them being a big help there.

Eric


From rminnich at lanl.gov  Fri Oct 22 12:10:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Fri Oct 22 12:10:01 2004
Subject: Makefile changes for symbols
In-Reply-To: <m3k6tiirwo.fsf@maxwell.lnxi.com>
References: <9B124F08B3EFDA4F8813B05102DC719501A90264@nh-ex01.nh.bench.com>
 <m3k6tiirwo.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.58.0410221129050.15945@linux.site>


On Fri, 22 Oct 2004, Eric W. Biederman wrote:

> Since the debuggers give no insight into how the rest of the hardware works
> I don't see them being a big help there.

one case I saw that helped was with buggy northbridges (old via vt8601 
comes to mind) which would lock up in certain situations. In that case, I 
really liked the Arium.

ron


From ebiederman at lnxi.com  Fri Oct 22 12:13:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Oct 22 12:13:00 2004
Subject: Makefile changes for symbols
In-Reply-To: <9B124F08B3EFDA4F8813B05102DC719501A90262@nh-ex01.nh.bench.com>
References: <9B124F08B3EFDA4F8813B05102DC719501A90262@nh-ex01.nh.bench.com>
Message-ID: <m3fz46irpq.fsf@maxwell.lnxi.com>

<Stephen.Kimball at bench.com> writes:

> Can someone give me the Makefile changes to make a LinuxBIOS with
> symbols?  I tried adding "-gdwarf-2" to CFLAGS, but I'm not sure where
> the unstripped output would be.  
> 
> Are there any features in the code that are useful in debugging
> LinuxBIOS?
> Any defines that should change as well?

Hmm. The ring buffer console might be useful.
 
> Someone must have some experience with source code level debugging of
> LinuxBIOS with an American Arium ECM-50.  Thanks.

Alternatively it might be work adding gdb stubs into LinuxBIOS.  And doing
using a remote debugger that way.  What a jtag interface provides
is really not much more than what gdb stubs provides.  At least
not after memory is initialized.

Eric


From YhLu at tyan.com  Fri Oct 22 12:20:01 2004
From: YhLu at tyan.com (YhLu)
Date: Fri Oct 22 12:20:01 2004
Subject: FYI: Merge in progress...S2735
Message-ID: <3174569B9743D511922F00A0C94314230665B4D5@TYANWEB>

Eric,
About S2735, in auto.c
How to change 
#include "cpu/p6/apic_timer.c"

Amd version is
#include "cpu/amd/model_fxx/apic_timer.c"

I can not find other apic_timer.c in src/cpu

Regards

YH


From YhLu at tyan.com  Fri Oct 22 13:27:01 2004
From: YhLu at tyan.com (YhLu)
Date: Fri Oct 22 13:27:01 2004
Subject: FYI: Merge in progress...S2735
Message-ID: <3174569B9743D511922F00A0C94314230665B4E9@TYANWEB>

Eric,

I change sth for s2735. I don't know how to modify 
src/northbridge/intel/e7501/norbridge.c

Can you have a look at that?

Regards

YH

s2735 half update
CVS: ----------------------------------------------------------------------
CVS: Enter Log.  Lines beginning with `CVS:' are removed automatically
CVS:
CVS: Committing in .
CVS:
CVS: Modified Files:
CVS:    src/cpu/intel/model_f2x/Config.lb
CVS:    src/cpu/intel/model_f2x/model_f2x_init.c
CVS:    src/cpu/intel/socket_mPGA604_533Mhz/chip.h
CVS:    src/cpu/intel/socket_mPGA604_533Mhz/socket_mPGA604_533Mhz.c
CVS:    src/mainboard/tyan/s2735/Config.lb
CVS:    src/mainboard/tyan/s2735/auto.c
CVS:    src/mainboard/tyan/s2735/chip.h
CVS:    src/mainboard/tyan/s2735/failover.c
CVS:    src/mainboard/tyan/s2735/mainboard.c
CVS:    src/mainboard/tyan/s2735/mptable.c
CVS:    src/mainboard/tyan/s4880/Options.lb
CVS:    src/mainboard/tyan/s4882/Options.lb
CVS:    targets/tyan/s2735/Config.lb targets/tyan/s2735/ns2735
CVS: ----------------------------------------------------------------------

-----Original Message-----
From: YhLu 
Sent: Friday, October 22, 2004 10:45 AM
To: ebiederman at lnxi.com; Ronald G. Minnich
Cc: Li-Ta Lo; 'LinuxBIOS'
Subject: RE: FYI: Merge in progress...S2735

Eric,
About S2735, in auto.c
How to change 
#include "cpu/p6/apic_timer.c"

Amd version is
#include "cpu/amd/model_fxx/apic_timer.c"

I can not find other apic_timer.c in src/cpu

Regards

YH
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From rminnich at lanl.gov  Fri Oct 22 13:45:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Fri Oct 22 13:45:01 2004
Subject: Makefile changes for symbols
In-Reply-To: <m3fz46irpq.fsf@maxwell.lnxi.com>
References: <9B124F08B3EFDA4F8813B05102DC719501A90262@nh-ex01.nh.bench.com>
 <m3fz46irpq.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.58.0410221305270.16599@linux.site>


On Fri, 22 Oct 2004, Eric W. Biederman wrote:

> Alternatively it might be work adding gdb stubs into LinuxBIOS.  And doing
> using a remote debugger that way.  What a jtag interface provides
> is really not much more than what gdb stubs provides.  At least
> not after memory is initialized.

that's not quite correct. There are a host of cpu failures you can detect 
with a jtag interface that gdb stubs are useless for. GDB stubs requires 
that the processor be basically sane, jtag interfaces are not near as 
picky.

ron


From Stephen.Kimball at bench.com  Fri Oct 22 14:57:00 2004
From: Stephen.Kimball at bench.com (Stephen.Kimball at bench.com)
Date: Fri Oct 22 14:57:00 2004
Subject: JTAG debugging
Message-ID: <9B124F08B3EFDA4F8813B05102DC719501A9026D@nh-ex01.nh.bench.com>

I agree with Ron.  JTAG debuggers are more robust.  But I am interested
in stepping through LinuxBIOS on a working target to quickly understand
the code, so I'm able to attempt a port to a new target.  I view it as a
learning tool and a productivity tool.  If you could show people how to
use  a product like the American Arium, you might get more help.

Steve

-----Original Message-----
From: Ronald G. Minnich [mailto:rminnich at lanl.gov] 
Sent: Friday, October 22, 2004 3:06 PM
To: Eric W. Biederman
Cc: Kimball, Stephen; linuxbios at clustermatic.org
Subject: Re: Makefile changes for symbols



On Fri, 22 Oct 2004, Eric W. Biederman wrote:

> Alternatively it might be work adding gdb stubs into LinuxBIOS.  And
doing
> using a remote debugger that way.  What a jtag interface provides
> is really not much more than what gdb stubs provides.  At least
> not after memory is initialized.

that's not quite correct. There are a host of cpu failures you can
detect 
with a jtag interface that gdb stubs are useless for. GDB stubs requires

that the processor be basically sane, jtag interfaces are not near as 
picky.

ron


From rminnich at lanl.gov  Fri Oct 22 15:10:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Fri Oct 22 15:10:00 2004
Subject: JTAG debugging
In-Reply-To: <9B124F08B3EFDA4F8813B05102DC719501A9026D@nh-ex01.nh.bench.com>
References: <9B124F08B3EFDA4F8813B05102DC719501A9026D@nh-ex01.nh.bench.com>
Message-ID: <Pine.LNX.4.58.0410221430440.16599@linux.site>


On Fri, 22 Oct 2004 Stephen.Kimball at bench.com wrote:

> I agree with Ron.  JTAG debuggers are more robust.  But I am interested
> in stepping through LinuxBIOS on a working target to quickly understand
> the code, so I'm able to attempt a port to a new target.  I view it as a
> learning tool and a productivity tool.  If you could show people how to
> use  a product like the American Arium, you might get more help.

well, we'll try to get to that end of next week once we're out of 
infiniband hell. 

I'm building arima hdama images with the new source base and config tool. 

What a nice set of changes :-)

ron


From Stephen.Kimball at bench.com  Fri Oct 22 15:17:00 2004
From: Stephen.Kimball at bench.com (Stephen.Kimball at bench.com)
Date: Fri Oct 22 15:17:00 2004
Subject: Makefile changes for symbols
Message-ID: <9B124F08B3EFDA4F8813B05102DC719501A9026E@nh-ex01.nh.bench.com>


> <Stephen.Kimball at bench.com> writes:
>
> > Rod,
> > 
> > I'm using Source Point 7.0.0.  I can see the source files.  I can
> > display source, disassembly or mixed.  However, the disassembly
doesn't
> > match up with the source code.  There is a way to give Source Point
an
> > offset when the symbols are loaded, but I can't seem to get the
right
> > value.  I know the address of _start and __protected_start but these
> > labels are not in linuxbios_c.o.  I need to find the location of a
> >symbol in linuxbios_c.o to compute the offset.
>
> ???
>
> linuxbios_c is run at an absolute location in memory so the address
> of the symbols within it should be fine.
>
> Look at readelf -a linuxbios_c.

I have looked at the readelf output.  Readelf says hardwaremain is at
000020b8, but I can't find it. SourcePoint thinks it's at 0008:000020B8
(32-bit mode).  But it's not there even after the copy into RAM.
  
>
> Now these are not addresses within the rom chip.  The are the
addresses
> the code is copied to after memory initialization.
>
> Currently romcc which generates the code that executes immediately
> out of the rom chip does not give good debugging output.  But
> you should still be able to see the assembly.  crt0.s should
> match what you are looking at.
> 
> You don't have the debugger in 16bit mode or something do you?

SourcePoint switches to 32-bit mode 16 instructions into crt0.s at the
JMP instruction.

Am I right that crt0.s loads LinuxBIOS into RAM then branches to
hardwaremain?

Steve


From rminnich at lanl.gov  Fri Oct 22 15:34:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Fri Oct 22 15:34:00 2004
Subject: Makefile changes for symbols
In-Reply-To: <9B124F08B3EFDA4F8813B05102DC719501A9026E@nh-ex01.nh.bench.com>
References: <9B124F08B3EFDA4F8813B05102DC719501A9026E@nh-ex01.nh.bench.com>
Message-ID: <Pine.LNX.4.58.0410221451590.16599@linux.site>


On Fri, 22 Oct 2004 Stephen.Kimball at bench.com wrote:

> I have looked at the readelf output.  Readelf says hardwaremain is at
> 000020b8, but I can't find it. SourcePoint thinks it's at 0008:000020B8
> (32-bit mode).  But it's not there even after the copy into RAM.

well that's interesting, now I have to try to remember if you're v1 or v2. 
But that segment: address pair looks quite reasonable. 

For example on the arima I am using hardwaremain is 723c. Basically all 
this stuff is in low memory. 

When you say "not there" you mean you see nothing in memory, right? 

I wonder if there's an issue with the debugger?

ron


From ollie at lanl.gov  Fri Oct 22 16:03:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Fri Oct 22 16:03:01 2004
Subject: Makefile changes for symbols
In-Reply-To: <Pine.LNX.4.58.0410221451590.16599@linux.site>
References: <9B124F08B3EFDA4F8813B05102DC719501A9026E@nh-ex01.nh.bench.com>
	 <Pine.LNX.4.58.0410221451590.16599@linux.site>
Message-ID: <1098480250.16598.22.camel@exponential.lanl.gov>

On Fri, 2004-10-22 at 14:55, Ronald G. Minnich wrote:
> On Fri, 22 Oct 2004 Stephen.Kimball at bench.com wrote:
> 
> > I have looked at the readelf output.  Readelf says hardwaremain is at
> > 000020b8, but I can't find it. SourcePoint thinks it's at 0008:000020B8
> > (32-bit mode).  But it's not there even after the copy into RAM.
> 
> well that's interesting, now I have to try to remember if you're v1 or v2. 
> But that segment: address pair looks quite reasonable. 
> 
> For example on the arima I am using hardwaremain is 723c. Basically all 
> this stuff is in low memory. 
> 
> When you say "not there" you mean you see nothing in memory, right? 
> 

I think he means the ROMCC part of LinuxBIOS copy the hardwaremain
part to RAM but he can't find it at the address.

I think you should try "linear" or "physical" address 000020b8.
Some hardware debugger have problem doing virtual to physical
translation.

Ollie

> I wonder if there's an issue with the debugger?
> 
> ron
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 



From stephen.kimball at bench.com  Fri Oct 22 16:25:00 2004
From: stephen.kimball at bench.com (Steve Kimball)
Date: Fri Oct 22 16:25:00 2004
Subject: Makefile changes for symbols
In-Reply-To: <1098480250.16598.22.camel@exponential.lanl.gov>
References: <9B124F08B3EFDA4F8813B05102DC719501A9026E@nh-ex01.nh.bench.com>
	 <Pine.LNX.4.58.0410221451590.16599@linux.site>
	 <1098480250.16598.22.camel@exponential.lanl.gov>
Message-ID: <1098481504.2738.7.camel@localhost.localdomain>

On Fri, 2004-10-22 at 17:24, Li-Ta Lo wrote:
> On Fri, 2004-10-22 at 14:55, Ronald G. Minnich wrote:
> > On Fri, 22 Oct 2004 Stephen.Kimball at bench.com wrote:
> > 
> > > I have looked at the readelf output.  Readelf says hardwaremain is at
> > > 000020b8, but I can't find it. SourcePoint thinks it's at 0008:000020B8
> > > (32-bit mode).  But it's not there even after the copy into RAM.
> > 
> > well that's interesting, now I have to try to remember if you're v1 or v2. 
> > But that segment: address pair looks quite reasonable. 

I'm using freebios2.  Is that v2?
> > 
> > For example on the arima I am using hardwaremain is 723c. Basically all 
> > this stuff is in low memory. 
> > 
> > When you say "not there" you mean you see nothing in memory, right? 

I look at the hardwaremain source code in mixed mode (assembly with C
code mixed in).  Even the two post_code() calls don't disassemble to
similar code.  It's code, but not the right code.
> 
> I think he means the ROMCC part of LinuxBIOS copy the hardwaremain
> part to RAM but he can't find it at the address.
> 
> I think you should try "linear" or "physical" address 000020b8.
> Some hardware debugger have problem doing virtual to physical
> translation.
> 
> Ollie
> 
> > I wonder if there's an issue with the debugger?
> > 
> > ron



From rminnich at lanl.gov  Fri Oct 22 16:54:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Fri Oct 22 16:54:01 2004
Subject: Makefile changes for symbols
In-Reply-To: <1098480250.16598.22.camel@exponential.lanl.gov>
References: <9B124F08B3EFDA4F8813B05102DC719501A9026E@nh-ex01.nh.bench.com>
  <Pine.LNX.4.58.0410221451590.16599@linux.site> <1098480250.16598.22.camel@exponential.lanl.gov>
Message-ID: <Pine.LNX.4.58.0410221614180.16599@linux.site>


On Fri, 22 Oct 2004, Li-Ta Lo wrote:

> I think you should try "linear" or "physical" address 000020b8.
> Some hardware debugger have problem doing virtual to physical
> translation.

good point. I forgot completely about that. On the arium I would almost 
always use 'physical' on the mapping. try that.

ron


From rminnich at lanl.gov  Fri Oct 22 16:57:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Fri Oct 22 16:57:01 2004
Subject: Makefile changes for symbols
In-Reply-To: <1098481504.2738.7.camel@localhost.localdomain>
References: <9B124F08B3EFDA4F8813B05102DC719501A9026E@nh-ex01.nh.bench.com>
  <Pine.LNX.4.58.0410221451590.16599@linux.site>  <1098480250.16598.22.camel@exponential.lanl.gov>
 <1098481504.2738.7.camel@localhost.localdomain>
Message-ID: <Pine.LNX.4.58.0410221617230.16599@linux.site>


On Fri, 22 Oct 2004, Steve Kimball wrote:

> I'm using freebios2.  Is that v2?

that's v2. 

> I look at the hardwaremain source code in mixed mode (assembly with C
> code mixed in).  Even the two post_code() calls don't disassemble to
> similar code.  It's code, but not the right code.

I'm really sorry, what mobo again?

ron


From rsmith at bitworks.com  Fri Oct 22 18:51:01 2004
From: rsmith at bitworks.com (Richard Smith)
Date: Fri Oct 22 18:51:01 2004
Subject: JTAG debugging
In-Reply-To: <9B124F08B3EFDA4F8813B05102DC719501A9026D@nh-ex01.nh.bench.com>
References: <9B124F08B3EFDA4F8813B05102DC719501A9026D@nh-ex01.nh.bench.com>
Message-ID: <4179A1D1.5030800@bitworks.com>

>>is really not much more than what gdb stubs provides.  At least
>>not after memory is initialized.
> 

A gdb stub would be pretty cool.  I could have used it lots already.

What happend to this?

http://www.mail-archive.com/linuxbios at clustermatic.org/msg02078.html


-- 
Richard A. Smith




From YhLu at tyan.com  Fri Oct 22 19:01:01 2004
From: YhLu at tyan.com (YhLu)
Date: Fri Oct 22 19:01:01 2004
Subject: FYI: Merge in progress...S2735
Message-ID: <3174569B9743D511922F00A0C94314230665B52F@TYANWEB>

Eric,

I copy some line from amd k8 to intel e7501 northbridge.c.

Can you check that for me?

Regards

YH

-----Original Message-----
From: YhLu 
Sent: Friday, October 22, 2004 11:53 AM
To: ebiederman at lnxi.com; Ronald G. Minnich
Cc: Li-Ta Lo; 'LinuxBIOS'
Subject: RE: FYI: Merge in progress...S2735

Eric,

I change sth for s2735. I don't know how to modify 
src/northbridge/intel/e7501/norbridge.c

Can you have a look at that?

Regards

YH

s2735 half update
CVS: ----------------------------------------------------------------------
CVS: Enter Log.  Lines beginning with `CVS:' are removed automatically
CVS:
CVS: Committing in .
CVS:
CVS: Modified Files:
CVS:    src/cpu/intel/model_f2x/Config.lb
CVS:    src/cpu/intel/model_f2x/model_f2x_init.c
CVS:    src/cpu/intel/socket_mPGA604_533Mhz/chip.h
CVS:    src/cpu/intel/socket_mPGA604_533Mhz/socket_mPGA604_533Mhz.c
CVS:    src/mainboard/tyan/s2735/Config.lb
CVS:    src/mainboard/tyan/s2735/auto.c
CVS:    src/mainboard/tyan/s2735/chip.h
CVS:    src/mainboard/tyan/s2735/failover.c
CVS:    src/mainboard/tyan/s2735/mainboard.c
CVS:    src/mainboard/tyan/s2735/mptable.c
CVS:    src/mainboard/tyan/s4880/Options.lb
CVS:    src/mainboard/tyan/s4882/Options.lb
CVS:    targets/tyan/s2735/Config.lb targets/tyan/s2735/ns2735
CVS: ----------------------------------------------------------------------

-----Original Message-----
From: YhLu 
Sent: Friday, October 22, 2004 10:45 AM
To: ebiederman at lnxi.com; Ronald G. Minnich
Cc: Li-Ta Lo; 'LinuxBIOS'
Subject: RE: FYI: Merge in progress...S2735

Eric,
About S2735, in auto.c
How to change 
#include "cpu/p6/apic_timer.c"

Amd version is
#include "cpu/amd/model_fxx/apic_timer.c"

I can not find other apic_timer.c in src/cpu

Regards

YH
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From ebiederman at lnxi.com  Fri Oct 22 20:23:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Oct 22 20:23:01 2004
Subject: JTAG debugging
In-Reply-To: <4179A1D1.5030800@bitworks.com>
References: <9B124F08B3EFDA4F8813B05102DC719501A9026D@nh-ex01.nh.bench.com>
	<4179A1D1.5030800@bitworks.com>
Message-ID: <m37jpidx9t.fsf@maxwell.lnxi.com>

Richard Smith <rsmith at bitworks.com> writes:

> >>is really not much more than what gdb stubs provides.  At least
> >>not after memory is initialized.
> >
> 
> A gdb stub would be pretty cool.  I could have used it lots already.
> 
> What happend to this?

Good question.

I was not terribly enthusiastic as most of my time is spent setting
up the memory controller where gdb stubs simply cannot go.  At least
not until we can figure out cache as ram.  Which unfortunately tends
to be about as bad a setting up a memory controller. 

So I figured romcc is generally and still do that romcc is a lot more
useful.

In any case gdb stubs are fairly simple and I have some.  So I might
just integrate them into LinuxBIOS.

The painful part is adding exception handlers, and it would be nice
to have exception handlers in any event so that mysteriously triggered
exceptions can be caught.

Eric


From ebiederman at lnxi.com  Fri Oct 22 21:13:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Oct 22 21:13:00 2004
Subject: FYI: Merge in progress...S2735
In-Reply-To: <3174569B9743D511922F00A0C94314230665B52F@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B52F@TYANWEB>
Message-ID: <m31xfqduy3.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> Eric,
> 
> I copy some line from amd k8 to intel e7501 northbridge.c.
> 
> Can you check that for me?

I have just checked it and cleaned it up.
It makes a much simpler example than the k8 northbridge.

Eric


From ebiederman at lnxi.com  Fri Oct 22 21:46:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Oct 22 21:46:00 2004
Subject: FYI: Merge in progress...S2735
In-Reply-To: <3174569B9743D511922F00A0C94314230665B4D5@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B4D5@TYANWEB>
Message-ID: <m3wtxicev1.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> Eric,
> About S2735, in auto.c
> How to change 
> #include "cpu/p6/apic_timer.c"
> 
> Amd version is
> #include "cpu/amd/model_fxx/apic_timer.c"
> 
> I can not find other apic_timer.c in src/cpu

This is a good question.  

The simple answer is that an apic timer based delay was
an extremely clever hack on the Opteron.  Possibly too clever.

Intel cpus to my knowledge to not have a fixed front side bus.
And even where they effectively do I don't know how if that
even relates to the speed at which the apic timer runs.

So for the moment I have reverted the e7501 to it's historical
tsc, timer2 and inb(0x80) based delays.  

I am willing to revist this.  But if we change this I want
it to be because we are doing something better.

In practice even the Opteron code should change and have the
apic_timer code included in the cpu/socket directory.

Timers are one of those things we have always needed but there
does not seem to be a good method of making them work.

Eric



From yhlu at tyan.com  Sat Oct 23 16:34:01 2004
From: yhlu at tyan.com (Yinghai Lu)
Date: Sat Oct 23 16:34:01 2004
Subject: FYI: Merge in progress...S2735
In-Reply-To: <m31xfqduy3.fsf@maxwell.lnxi.com>
Message-ID: <200410232033.i9NKX1L24659@nwn.definitive.org>

Thanks. 

1. no 64 bit PCI mem.
2. better way get MC.
3. enable memremap
4. remove cpu_bus_scan.

I guess it can be copy to intel/i855pm.

Regards

YH


-----Original Message-----
From: Eric W. Biederman [mailto:eric at lnxi.com] On Behalf Of Eric W.
Biederman
Sent: Friday, October 22, 2004 7:34 PM
To: YhLu
Cc: Ronald G. Minnich; Li-Ta Lo; 'LinuxBIOS'
Subject: Re: FYI: Merge in progress...S2735

YhLu <YhLu at tyan.com> writes:

> Eric,
> 
> I copy some line from amd k8 to intel e7501 northbridge.c.
> 
> Can you check that for me?

I have just checked it and cleaned it up.
It makes a much simpler example than the k8 northbridge.

Eric



From ebiederman at lnxi.com  Sat Oct 23 23:53:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Sat Oct 23 23:53:00 2004
Subject: FYI: Merge in progress...S2735
In-Reply-To: <20041023215454.435DED0187A2@spam.llix.net>
References: <20041023215454.435DED0187A2@spam.llix.net>
Message-ID: <m34qkky9yu.fsf@maxwell.lnxi.com>

"Yinghai Lu" <yhlu at tyan.com> writes:

> Thanks. 
> 
> 1. no 64 bit PCI mem.
> 2. better way get MC.
> 3. enable memremap
> 4. remove cpu_bus_scan.
> 
> I guess it can be copy to intel/i855pm.

Pretty much.  Things like the memory remap may need to be removed
but for the most part the e7501 code looks like a decent example of how
to convert sizeram() to the new tree.

Eric


From stephen.kimball at bench.com  Mon Oct 25 07:55:01 2004
From: stephen.kimball at bench.com (Steve Kimball)
Date: Mon Oct 25 07:55:01 2004
Subject: Makefile changes for symbols
In-Reply-To: <Pine.LNX.4.58.0410221617230.16599@linux.site>
References: <9B124F08B3EFDA4F8813B05102DC719501A9026E@nh-ex01.nh.bench.com>
	 <Pine.LNX.4.58.0410221451590.16599@linux.site>
	 <1098480250.16598.22.camel@exponential.lanl.gov>
	 <1098481504.2738.7.camel@localhost.localdomain>
	 <Pine.LNX.4.58.0410221617230.16599@linux.site>
Message-ID: <1098710105.2721.3.camel@localhost.localdomain>

On Fri, 2004-10-22 at 18:17, Ronald G. Minnich wrote:
> On Fri, 22 Oct 2004, Steve Kimball wrote:
> 
> > I'm using freebios2.  Is that v2?
> 
> that's v2. 
> 
> > I look at the hardwaremain source code in mixed mode (assembly with C
> > code mixed in).  Even the two post_code() calls don't disassemble to
> > similar code.  It's code, but not the right code.
> 
> I'm really sorry, what mobo again?

AMD/Serenade with a FILO payload.  It runs great.  It loads Linux fine. 
Just can get the source and disassembly to line up.

Steve


From rminnich at lanl.gov  Mon Oct 25 09:29:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Oct 25 09:29:01 2004
Subject: Makefile changes for symbols
In-Reply-To: <1098710105.2721.3.camel@localhost.localdomain>
References: <9B124F08B3EFDA4F8813B05102DC719501A9026E@nh-ex01.nh.bench.com>
  <Pine.LNX.4.58.0410221451590.16599@linux.site>  <1098480250.16598.22.camel@exponential.lanl.gov>
  <1098481504.2738.7.camel@localhost.localdomain>  <Pine.LNX.4.58.0410221617230.16599@linux.site>
 <1098710105.2721.3.camel@localhost.localdomain>
Message-ID: <Pine.LNX.4.58.0410250850150.25731@linux.site>


On Mon, 25 Oct 2004, Steve Kimball wrote:

> AMD/Serenade with a FILO payload.  It runs great.  It loads Linux fine. 
> Just can get the source and disassembly to line up.

it seems to me that the addresses you are using are correct. Did you try 
pointing the arium at physical memory instead of seg:offset addresses?

ron


From stephen.kimball at bench.com  Mon Oct 25 10:30:01 2004
From: stephen.kimball at bench.com (Steve Kimball)
Date: Mon Oct 25 10:30:01 2004
Subject: Makefile changes for symbols
In-Reply-To: <Pine.LNX.4.58.0410250850150.25731@linux.site>
References: <9B124F08B3EFDA4F8813B05102DC719501A9026E@nh-ex01.nh.bench.com>
	 <Pine.LNX.4.58.0410221451590.16599@linux.site>
	 <1098480250.16598.22.camel@exponential.lanl.gov>
	 <1098481504.2738.7.camel@localhost.localdomain>
	 <Pine.LNX.4.58.0410221617230.16599@linux.site>
	 <1098710105.2721.3.camel@localhost.localdomain>
	 <Pine.LNX.4.58.0410250850150.25731@linux.site>
Message-ID: <1098719346.2721.140.camel@localhost.localdomain>

On Mon, 2004-10-25 at 10:50, Ronald G. Minnich wrote:
> On Mon, 25 Oct 2004, Steve Kimball wrote:
> 
> > AMD/Serenade with a FILO payload.  It runs great.  It loads Linux fine. 
> > Just can get the source and disassembly to line up.
> 
> it seems to me that the addresses you are using are correct. Did you try 
> pointing the arium at physical memory instead of seg:offset addresses?
> 
> ron

I don't know how to force physical or virtual addressing.
The arium seems to change automaically when the mode changes. 
I can single step an follow instruction execution as log as I'd like.
I have been displaying hardwaremain in mixed (source and assembly)
at various points.  I'm assuming it gets copied from FLASH to RAM 
at some point.  So it should be junk initially.  

  time                 mode     hardwaremain address      instr values
after reset      16-bit      F000:0000 20b8        non-zero junk
after 16 instr   32-bit      0008:0000 20b8        different non-zero
junk
later                                              all 0xff
scanning PCI bus 32-bit      0018:0000 20b8        all zeros

If I display memory at 0000:0000 20b8 it seems to always match the
values at hardwaremain?  Why does the American Arium think the segment
register for hardwaremain changes?
Why is it never good instructions?

Steve


From rminnich at lanl.gov  Mon Oct 25 10:39:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Oct 25 10:39:00 2004
Subject: Makefile changes for symbols
In-Reply-To: <1098719346.2721.140.camel@localhost.localdomain>
References: <9B124F08B3EFDA4F8813B05102DC719501A9026E@nh-ex01.nh.bench.com>
  <Pine.LNX.4.58.0410221451590.16599@linux.site>  <1098480250.16598.22.camel@exponential.lanl.gov>
  <1098481504.2738.7.camel@localhost.localdomain>  <Pine.LNX.4.58.0410221617230.16599@linux.site>
  <1098710105.2721.3.camel@localhost.localdomain>  <Pine.LNX.4.58.0410250850150.25731@linux.site>
 <1098719346.2721.140.camel@localhost.localdomain>
Message-ID: <Pine.LNX.4.58.0410250958540.25731@linux.site>


On Mon, 25 Oct 2004, Steve Kimball wrote:

> I don't know how to force physical or virtual addressing.
> The arium seems to change automaically when the mode changes. 

yes, that automagic thing is wonderful ... when it works. 

You can force it, and I forget how. I think you just close the seg:offset 
window and then pop up a disassembly but specify physical addressing. 

> If I display memory at 0000:0000 20b8 it seems to always match the
> values at hardwaremain?  Why does the American Arium think the segment
> register for hardwaremain changes?

All I know is that displaying memory with seg:offset was always a problem 
for me, so I tried to keep it at physical addressing.

ron


From ollie at lanl.gov  Mon Oct 25 22:46:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Mon Oct 25 22:46:00 2004
Subject: Makefile changes for symbols
In-Reply-To: <Pine.LNX.4.58.0410250958540.25731@linux.site>
References: <9B124F08B3EFDA4F8813B05102DC719501A9026E@nh-ex01.nh.bench.com>
	 <Pine.LNX.4.58.0410221451590.16599@linux.site>
	 <1098480250.16598.22.camel@exponential.lanl.gov>
	 <1098481504.2738.7.camel@localhost.localdomain>
	 <Pine.LNX.4.58.0410221617230.16599@linux.site>
	 <1098710105.2721.3.camel@localhost.localdomain>
	 <Pine.LNX.4.58.0410250850150.25731@linux.site>
	 <1098719346.2721.140.camel@localhost.localdomain>
	 <Pine.LNX.4.58.0410250958540.25731@linux.site>
Message-ID: <1098732363.16598.69.camel@exponential.lanl.gov>

On Mon, 2004-10-25 at 10:00, Ronald G. Minnich wrote:
> On Mon, 25 Oct 2004, Steve Kimball wrote:
> 
> > I don't know how to force physical or virtual addressing.
> > The arium seems to change automaically when the mode changes. 
> 
> yes, that automagic thing is wonderful ... when it works. 
> 
> You can force it, and I forget how. I think you just close the seg:offset 
> window and then pop up a disassembly but specify physical addressing. 
> 
> > If I display memory at 0000:0000 20b8 it seems to always match the
> > values at hardwaremain?  Why does the American Arium think the segment
> > register for hardwaremain changes?
> 
> All I know is that displaying memory with seg:offset was always a problem 
> for me, so I tried to keep it at physical addressing.
> 


BTW, the ht reset confused the AMD HDT such that I have no way to 
debug anything other the auto.c. Is AA as stupid ?

Ollie




From stepan at openbios.org  Tue Oct 26 02:17:00 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Tue Oct 26 02:17:00 2004
Subject: Makefile changes for symbols
In-Reply-To: <1098732363.16598.69.camel@exponential.lanl.gov>
References: <9B124F08B3EFDA4F8813B05102DC719501A9026E@nh-ex01.nh.bench.com> <Pine.LNX.4.58.0410221451590.16599@linux.site> <1098480250.16598.22.camel@exponential.lanl.gov> <1098481504.2738.7.camel@localhost.localdomain> <Pine.LNX.4.58.0410221617230.16599@linux.site> <1098710105.2721.3.camel@localhost.localdomain> <Pine.LNX.4.58.0410250850150.25731@linux.site> <1098719346.2721.140.camel@localhost.localdomain> <Pine.LNX.4.58.0410250958540.25731@linux.site> <1098732363.16598.69.camel@exponential.lanl.gov>
Message-ID: <20041026073904.GA9126@openbios.org>

* Li-Ta Lo <ollie at lanl.gov> [041025 21:26]:
> > All I know is that displaying memory with seg:offset was always a problem 
> > for me, so I tried to keep it at physical addressing.
> 
> BTW, the ht reset confused the AMD HDT such that I have no way to 
> debug anything other the auto.c. Is AA as stupid ?
 
Now that A stepping CPUs start dying out, could we not switch the reset
mechanism to use LDTSTOP instead of a complete reset? 
It's more solid and a lot faster.

Stefan



From ebiederman at lnxi.com  Tue Oct 26 05:28:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Oct 26 05:28:00 2004
Subject: Makefile changes for symbols
In-Reply-To: <20041026073904.GA9126@openbios.org>
References: <9B124F08B3EFDA4F8813B05102DC719501A9026E@nh-ex01.nh.bench.com>
	<Pine.LNX.4.58.0410221451590.16599@linux.site>
	<1098480250.16598.22.camel@exponential.lanl.gov>
	<1098481504.2738.7.camel@localhost.localdomain>
	<Pine.LNX.4.58.0410221617230.16599@linux.site>
	<1098710105.2721.3.camel@localhost.localdomain>
	<Pine.LNX.4.58.0410250850150.25731@linux.site>
	<1098719346.2721.140.camel@localhost.localdomain>
	<Pine.LNX.4.58.0410250958540.25731@linux.site>
	<1098732363.16598.69.camel@exponential.lanl.gov>
	<20041026073904.GA9126@openbios.org>
Message-ID: <m3654xvjmv.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at openbios.org> writes:

> * Li-Ta Lo <ollie at lanl.gov> [041025 21:26]:
> > > All I know is that displaying memory with seg:offset was always a problem 
> > > for me, so I tried to keep it at physical addressing.
> > 
> > BTW, the ht reset confused the AMD HDT such that I have no way to 
> > debug anything other the auto.c. Is AA as stupid ?
>  
> Now that A stepping CPUs start dying out, could we not switch the reset
> mechanism to use LDTSTOP instead of a complete reset? 
> It's more solid and a lot faster.

Solid?  There are several errata with using LDTSTOP and you can not use it after
memory is initialized. 

As for performance now that we have removed the earlier unnecessary cache invalidations
that killed performance there is no noticeable speed penalty.

So far I have not seen a reason to use LDTSTOP, or a win by doing so.  Perhaps
when we get as far as hotplug hypertransport that will be a win.

Eric


From salvatorelionetti at yahoo.it  Tue Oct 26 05:50:01 2004
From: salvatorelionetti at yahoo.it (Salvatore Lionetti)
Date: Tue Oct 26 05:50:01 2004
Subject: cpu,flash,sdram,usb
Message-ID: <20041026111215.65487.qmail@web25106.mail.ukl.yahoo.com>

Hi,
i'm choicing an alternati to boot loader.
This is the system on which i'd wish to install
linuxbios; here's the question:
1) if usb need initialization (like sdram controller);
2) where i can find doc on how to boot another kernel
after linuxbios;
3) if you have any hint to me.
Than you.


		
___________________________________ 
Nuovo Yahoo! Messenger: E' molto pi? divertente: Audibles, Avatar, Webcam, Giochi, Rubrica
 Scaricalo ora! 
http://it.messenger.yahoo.it


From Stephen.Kimball at bench.com  Tue Oct 26 08:02:01 2004
From: Stephen.Kimball at bench.com (Stephen.Kimball at bench.com)
Date: Tue Oct 26 08:02:01 2004
Subject: LinuxBIOS debugging with an emulator
Message-ID: <9B124F08B3EFDA4F8813B05102DC719501A90273@nh-ex01.nh.bench.com>

Can someone tell me what the starting sequence is with LinuxBIOS?

Reset jumps to crt0.s.  crt0.s calls auto.E.  auto.E is built using
romcc, so source-level debugging is not possible.  The statement
locations can be found using the Lxxxx labels in linuxbios.map.  Then
hardwaremain is called.
Hardwaremain is the first C function called.

Crt0 and auto run out of FLASH.  Hardwaremain is the first function
called after LinuxBIOS is copied to RAM.

Is this correct?  Maybe this will help get the American Arium to work.

Steve


From rminnich at lanl.gov  Tue Oct 26 11:00:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Tue Oct 26 11:00:01 2004
Subject: ARIMA HDAMA
Message-ID: <Pine.LNX.4.58.0410251706460.26831@linux.site>

The new boot speed is really nice to watch. 

I'm having one problem in that the irq table seems wrong now. 


Has anyone brought HDAMA up under the new tree, booted linux, and seen 
interrupts work on the ethernet devices? Just checking. I am going to take 
a closer look tomorrow.

ron



From jschildt at lnxi.com  Tue Oct 26 11:51:01 2004
From: jschildt at lnxi.com (Jason Schildt)
Date: Tue Oct 26 11:51:01 2004
Subject: [BULK] ARIMA HDAMA
In-Reply-To: <Pine.LNX.4.58.0410251706460.26831@linux.site>
References: <Pine.LNX.4.58.0410251706460.26831@linux.site>
Message-ID: <20041026171318.GB8632@lnxi.com>

Ron, 

As soon as Eric gets our local repository synced with the public tree
I'll build the HDAMA here.  I have a new rev of the HDAMA from Rioworks,
so I'll test it here and let you know how it turns out.

--jason--
-- 

Jason W. Schildt	
Software Engineer   
Linux Networx      

On Mon, Oct 25, 2004 at 05:11:42PM -0600, Ronald G. Minnich wrote:
> 
> The new boot speed is really nice to watch. 
> 
> I'm having one problem in that the irq table seems wrong now. 
> 
> 
> Has anyone brought HDAMA up under the new tree, booted linux, and seen 
> interrupts work on the ethernet devices? Just checking. I am going to take 
> a closer look tomorrow.
> 
> ron
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios



From ebiederman at lnxi.com  Tue Oct 26 12:10:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Oct 26 12:10:00 2004
Subject: [BULK] ARIMA HDAMA
In-Reply-To: <Pine.LNX.4.58.0410251706460.26831@linux.site>
References: <Pine.LNX.4.58.0410251706460.26831@linux.site>
Message-ID: <m31xfl9yit.fsf@maxwell.lnxi.com>

"Ronald G. Minnich" <rminnich at lanl.gov> writes:

> The new boot speed is really nice to watch. 
> 
> I'm having one problem in that the irq table seems wrong now. 

I have not any problems.  pirq or mptable?

Nothing should have changed with respect to interrupts.
I think there was a very modest tweak to mptable.c

Eric


From rminnich at lanl.gov  Tue Oct 26 13:22:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Tue Oct 26 13:22:01 2004
Subject: Makefile changes for symbols
In-Reply-To: <m3654xvjmv.fsf@maxwell.lnxi.com>
References: <9B124F08B3EFDA4F8813B05102DC719501A9026E@nh-ex01.nh.bench.com>
 <Pine.LNX.4.58.0410221451590.16599@linux.site> <1098480250.16598.22.camel@exponential.lanl.gov>
 <1098481504.2738.7.camel@localhost.localdomain> <Pine.LNX.4.58.0410221617230.16599@linux.site>
 <1098710105.2721.3.camel@localhost.localdomain> <Pine.LNX.4.58.0410250850150.25731@linux.site>
 <1098719346.2721.140.camel@localhost.localdomain> <Pine.LNX.4.58.0410250958540.25731@linux.site>
 <1098732363.16598.69.camel@exponential.lanl.gov> <20041026073904.GA9126@openbios.org>
 <m3654xvjmv.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.58.0410260738190.29083@linux.site>


On Tue, 26 Oct 2004, Eric W. Biederman wrote:

> As for performance now that we have removed the earlier unnecessary cache invalidations
> that killed performance there is no noticeable speed penalty.

Stefan, try the newest snap. Startup on K8 is FAST now.

ron


From YhLu at tyan.com  Tue Oct 26 13:36:01 2004
From: YhLu at tyan.com (YhLu)
Date: Tue Oct 26 13:36:01 2004
Subject: S2885
Message-ID: <3174569B9743D511922F00A0C94314230665B60D@TYANWEB>

Eric,

I find the device on amd8111 pci io allocation get werid. Please check 6:b.0
and 6:c.0 io allocation. It comes from 0x0000, instead of 0x1000.

It works well before you add set_subsystem.

Regards

YH


PCI_DOMAIN: 0000 00 <- [0x0000000400 - 0x0000000fff] io
PCI_DOMAIN: 0000 01 <- [0x00e0000000 - 0x00efffffff] prefmem
PCI_DOMAIN: 0000 02 <- [0x00f0000000 - 0x00f03fffff] mem
PCI: 00:18.0 1ba <- [0x00f0000000 - 0x00efffffff] prefmem <node 0 link 2>
PCI: 00:18.0 1d8 <- [0x0000001000 - 0x0000000fff] io <node 0 link 0>
PCI: 00:18.0 1b0 <- [0x00e0000000 - 0x00efffffff] prefmem <node 0 link 0>
PCI: 00:18.0 1a8 <- [0x00f0300000 - 0x00f03fffff] mem <node 0 link 0>
PCI: 00:18.0 1a2 <- [0x00f0000000 - 0x00f02fffff] mem <node 0 link 2>
PCI: 01:01.0 10 <- [0x00e0000000 - 0x00efffffff] prefmem
PCI: 01:01.0 14 <- [0x00f0300000 - 0x00f0300000] mem
PCI: 03:01.0 20 <- [0x00f0000000 - 0x00f00fffff] bus 4 mem
PCI: 04:09.0 10 <- [0x00f0000000 - 0x00f000ffff] mem
PCI: 03:01.1 10 <- [0x00f0200000 - 0x00f0200fff] mem
PCI: 03:02.1 10 <- [0x00f0201000 - 0x00f0201fff] mem
PCI: 03:03.0 1c <- [0x0000000000 - 0x0000000fff] bus 6 io
PCI: 03:03.0 20 <- [0x00f0100000 - 0x00f01fffff] bus 6 mem
PCI: 06:00.0 10 <- [0x00f0104000 - 0x00f0104fff] mem
PCI: 06:00.1 10 <- [0x00f0105000 - 0x00f0105fff] mem
PCI: 06:0b.0 10 <- [0x0000000010 - 0x0000000017] io
PCI: 06:0b.0 14 <- [0x0000000030 - 0x0000000033] io
PCI: 06:0b.0 18 <- [0x0000000020 - 0x0000000027] io
PCI: 06:0b.0 1c <- [0x0000000040 - 0x0000000043] io
PCI: 06:0b.0 20 <- [0x0000000000 - 0x000000000f] io
PCI: 06:0b.0 24 <- [0x00f0107000 - 0x00f01073ff] mem
PCI: 06:0c.0 10 <- [0x00f0106000 - 0x00f01067ff] mem
PCI: 06:0c.0 14 <- [0x00f0100000 - 0x00f0103fff] mem


And it should be

PCI_DOMAIN: 0000 00 <- [0x0000001000 - 0x0000002fff] io
PCI_DOMAIN: 0000 01 <- [0x00e0000000 - 0x00efffffff] prefmem
PCI_DOMAIN: 0000 02 <- [0x00f0000000 - 0x00f03fffff] mem
PCI: 00:18.0 1ba <- [0x00f0000000 - 0x00efffffff] prefmem <node 0 link 2>
PCI: 00:18.0 1c2 <- [0x0000001000 - 0x0000002fff] io <node 0 link 2>
PCI: 00:18.0 1d8 <- [0x0000003000 - 0x0000002fff] io <node 0 link 0>
PCI: 00:18.0 1b0 <- [0x00e0000000 - 0x00efffffff] prefmem <node 0 link 0>
PCI: 00:18.0 1a8 <- [0x00f0300000 - 0x00f03fffff] mem <node 0 link 0>
PCI: 00:18.0 1a2 <- [0x00f0000000 - 0x00f02fffff] mem <node 0 link 2>
PCI: 01:01.0 10 <- [0x00e0000000 - 0x00efffffff] prefmem
PCI: 01:01.0 14 <- [0x00f0300000 - 0x00f0300000] mem
PCI: 03:01.0 20 <- [0x00f0000000 - 0x00f00fffff] bus 4 mem
PCI: 04:09.0 10 <- [0x00f0000000 - 0x00f000ffff] mem
PCI: 03:01.1 10 <- [0x00f0200000 - 0x00f0200fff] mem
PCI: 03:02.1 10 <- [0x00f0201000 - 0x00f0201fff] mem
PCI: 03:03.0 1c <- [0x0000001000 - 0x0000001fff] bus 6 io
PCI: 03:03.0 20 <- [0x00f0100000 - 0x00f01fffff] bus 6 mem
PCI: 06:00.0 10 <- [0x00f0104000 - 0x00f0104fff] mem
PCI: 06:00.1 10 <- [0x00f0105000 - 0x00f0105fff] mem
PCI: 06:0b.0 10 <- [0x0000001010 - 0x0000001017] io
PCI: 06:0b.0 14 <- [0x0000001030 - 0x0000001033] io
PCI: 06:0b.0 18 <- [0x0000001020 - 0x0000001027] io
PCI: 06:0b.0 1c <- [0x0000001040 - 0x0000001043] io
PCI: 06:0b.0 20 <- [0x0000001000 - 0x000000100f] io
PCI: 06:0b.0 24 <- [0x00f0107000 - 0x00f01073ff] mem
PCI: 06:0c.0 10 <- [0x00f0106000 - 0x00f01067ff] mem
PCI: 06:0c.0 14 <- [0x00f0100000 - 0x00f0103fff] mem


From rminnich at lanl.gov  Tue Oct 26 13:49:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Tue Oct 26 13:49:00 2004
Subject: ARIMA HDAMA
In-Reply-To: <Pine.LNX.4.58.0410251706460.26831@linux.site>
References: <Pine.LNX.4.58.0410251706460.26831@linux.site>
Message-ID: <Pine.LNX.4.58.0410261055110.29083@linux.site>


On Mon, 25 Oct 2004, Ronald G. Minnich wrote:

> I'm having one problem in that the irq table seems wrong now. 

nope, I was wrong, the table is fine. 

2.6 even now, in 32-bit mode, can't handle the 0x746b interrupt router ... 
here is a patch.

ron
--- linux-2.6.8.1-boot/arch/i386/pci/irq.c.org 2004-10-26 
10:23:40.654334364 -0600
+++ linux-2.6.8.1-boot/arch/i386/pci/irq.c     2004-10-26 
10:26:16.002263267 -0600
@@ -613,6 +613,9 @@
       case PCI_DEVICE_ID_AMD_VIPER_7443:
       r->name = "AMD768";
       break;
+      case 0x746b: /*PCI_DEVICE_ID_AMD_VIPER_746B*/
+      r->name = "AMD746B";
+      break;
       default:
       return 0;
       }





From rminnich at lanl.gov  Tue Oct 26 13:52:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Tue Oct 26 13:52:01 2004
Subject: FILO users
Message-ID: <Pine.LNX.4.58.0410261059220.29083@linux.site>

who is keeping FILO nowadays? I have a simple patch.

ron


From ollie at lanl.gov  Tue Oct 26 13:54:10 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Tue Oct 26 13:54:10 2004
Subject: [BULK] ARIMA HDAMA
In-Reply-To: <m31xfl9yit.fsf@maxwell.lnxi.com>
References: <Pine.LNX.4.58.0410251706460.26831@linux.site>
	 <m31xfl9yit.fsf@maxwell.lnxi.com>
Message-ID: <1098817946.3253.12.camel@exponential.lanl.gov>

On Tue, 2004-10-26 at 11:31, Eric W. Biederman wrote:
> "Ronald G. Minnich" <rminnich at lanl.gov> writes:
> 
> > The new boot speed is really nice to watch. 
> > 
> > I'm having one problem in that the irq table seems wrong now. 
> 
> I have not any problems.  pirq or mptable?
> 
> Nothing should have changed with respect to interrupts.
> I think there was a very modest tweak to mptable.c
> 

There was no problem actually. Ron forgot that the stupid old kernel
can't do irq routing on K8.

Ollie




From ebiederman at lnxi.com  Tue Oct 26 14:30:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Oct 26 14:30:00 2004
Subject: S2885
In-Reply-To: <3174569B9743D511922F00A0C94314230665B60D@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B60D@TYANWEB>
Message-ID: <m3acu99s0h.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> Eric,
> 
> I find the device on amd8111 pci io allocation get werid. Please check 6:b.0
> and 6:c.0 io allocation. It comes from 0x0000, instead of 0x1000.

Agreed this is a bug.  

Currently the code updates the limit on bridges if all of the devices
behind the bridge cannot use that limit.  In theory that works
great in practice however it barely works.

With I/O devices typically the problem is typically superio chips
with a limit of 0xfff.
 
> It works well before you add set_subsystem.

set_subsystem has been there since somewhere the start of the merge.
Although all of the methods for the amd8111 and amd8131 were not.

I suspect this has more to do with the updated pnp device code,
which now correctly computes the limit address.  And thus messes
up the computation logic for everything else.  At least if the resource
is not set statically.

If this is what I think it is, except for hard coding the superio resources
I don't see a quick fix in the works.

Eric


From YhLu at tyan.com  Tue Oct 26 14:45:00 2004
From: YhLu at tyan.com (YhLu)
Date: Tue Oct 26 14:45:00 2004
Subject: S2885
Message-ID: <3174569B9743D511922F00A0C94314230665B61B@TYANWEB>

You are right, after I comment out the superio section in Config.lb. it
allocate correct io range for device in amd8111 PCI bridge.

Regards

YH



-----Original Message-----
From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
Sent: Tuesday, October 26, 2004 12:52 PM
To: YhLu
Cc: Ronald G. Minnich; linuxbios at clustermatic.org
Subject: Re: S2885

YhLu <YhLu at tyan.com> writes:

> Eric,
> 
> I find the device on amd8111 pci io allocation get werid. Please check
6:b.0
> and 6:c.0 io allocation. It comes from 0x0000, instead of 0x1000.

Agreed this is a bug.  

Currently the code updates the limit on bridges if all of the devices
behind the bridge cannot use that limit.  In theory that works
great in practice however it barely works.

With I/O devices typically the problem is typically superio chips
with a limit of 0xfff.
 
> It works well before you add set_subsystem.

set_subsystem has been there since somewhere the start of the merge.
Although all of the methods for the amd8111 and amd8131 were not.

I suspect this has more to do with the updated pnp device code,
which now correctly computes the limit address.  And thus messes
up the computation logic for everything else.  At least if the resource
is not set statically.

If this is what I think it is, except for hard coding the superio resources
I don't see a quick fix in the works.

Eric


From YhLu at tyan.com  Tue Oct 26 15:28:01 2004
From: YhLu at tyan.com (YhLu)
Date: Tue Oct 26 15:28:01 2004
Subject: S2885
Message-ID: <3174569B9743D511922F00A0C94314230665B629@TYANWEB>

Comment out

//      resource->limit = info->mask | (step - 1);

In pnp_get_ioresource

Will make it works right.

Regards

YH

-----Original Message-----
From: YhLu 
Sent: Tuesday, October 26, 2004 1:12 PM
To: ebiederman at lnxi.com
Cc: Ronald G. Minnich; linuxbios at clustermatic.org
Subject: RE: S2885

You are right, after I comment out the superio section in Config.lb. it
allocate correct io range for device in amd8111 PCI bridge.

Regards

YH



-----Original Message-----
From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
Sent: Tuesday, October 26, 2004 12:52 PM
To: YhLu
Cc: Ronald G. Minnich; linuxbios at clustermatic.org
Subject: Re: S2885

YhLu <YhLu at tyan.com> writes:

> Eric,
> 
> I find the device on amd8111 pci io allocation get werid. Please check
6:b.0
> and 6:c.0 io allocation. It comes from 0x0000, instead of 0x1000.

Agreed this is a bug.  

Currently the code updates the limit on bridges if all of the devices
behind the bridge cannot use that limit.  In theory that works
great in practice however it barely works.

With I/O devices typically the problem is typically superio chips
with a limit of 0xfff.
 
> It works well before you add set_subsystem.

set_subsystem has been there since somewhere the start of the merge.
Although all of the methods for the amd8111 and amd8131 were not.

I suspect this has more to do with the updated pnp device code,
which now correctly computes the limit address.  And thus messes
up the computation logic for everything else.  At least if the resource
is not set statically.

If this is what I think it is, except for hard coding the superio resources
I don't see a quick fix in the works.

Eric
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From ebiederman at lnxi.com  Tue Oct 26 15:55:02 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Oct 26 15:55:02 2004
Subject: S2885
In-Reply-To: <3174569B9743D511922F00A0C94314230665B629@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B629@TYANWEB>
Message-ID: <m3k6tdxjqe.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> Comment out
> 
> //      resource->limit = info->mask | (step - 1);
> 
> In pnp_get_ioresource
> 
> Will make it works right.

That part of the code is correct.  Fixing that exposed the problem.

The chunk of code out of device.c:compute_allocate_resource() that
clamps the limit is below.

If you notice it currently ignores anything that is IORESOURCE_FIXED.
So if you hard code the problem resource in Config.lb the symptoms
will go away.

This is not a good long term solution, but it does work for now.
This is a general problem with taking resource limits into account
and compute_allocate_resource() needs an overhaul to do that properly.
I will get to that as soon as I get back to getting 64bit resource
handling properly and making it generic.  So it should not be delayed
too long.

		/* Do NOT I repeat do not ignore resources which have zero size.
		 * If they need to be ignored dev->read_resources should not even
		 * return them.   Some resources must be set even when they have
		 * no size.  PCI bridge resources are a good example of this.
		 */

		/* Propogate the resource alignment to the bridge register  */
		if (resource->align > bridge->align) {
			bridge->align = resource->align;
		}

		/* Make certain we are dealing with a good minimum size */
		size = resource->size;
		align = resource->align;
		if (align < min_align) {
			align = min_align;
		}
		if (resource->flags & IORESOURCE_FIXED) {
			continue;
		}
		/* Propogate the resource limit to the bridge register */
		if (bridge->limit > resource->limit) {
			bridge->limit = resource->limit;
		}
		/* Artificially deny limits between DEVICE_MEM_HIGH and 0xffffffff */
		if ((bridge->limit > DEVICE_MEM_HIGH) && (bridge->limit <= 0xffffffff)) {
			bridge->limit = DEVICE_MEM_HIGH;
		}


Eric


From YhLu at tyan.com  Tue Oct 26 16:10:01 2004
From: YhLu at tyan.com (YhLu)
Date: Tue Oct 26 16:10:01 2004
Subject: S2885
Message-ID: <3174569B9743D511922F00A0C94314230665B63D@TYANWEB>

I'm little confused. In the static.c
 
The superio is already set to IORESOURCE_FIXED.
 
YH
 
struct device _dev25 = {
        .ops = 0,
        .bus = &_dev21.link[0],
        .path = {.type=DEVICE_PATH_PNP,.u={.pnp={ .port = 0x2e, .device =
0x2 }}},
        .enabled = 1,
        .on_mainboard = 1,
        .resources = 2,
        .resource = {
                { .flags=IORESOURCE_FIXED | IORESOURCE_ASSIGNED |
IORESOURCE_IO, .index=0x60, .base=0x3f8},
                { .flags=IORESOURCE_FIXED | IORESOURCE_ASSIGNED |
IORESOURCE_IRQ, .index=0x70, .base=0x4},
         },
        .link = {
        },
        .links = 0,
        .sibling = &_dev26,
        .chip_ops = &superio_winbond_w83627hf_ops,
        .chip_info = &superio_winbond_w83627hf_info_22,
        .next=&_dev26
};
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20041026/c75de90f/attachment.html>

From ebiederman at lnxi.com  Tue Oct 26 16:17:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Oct 26 16:17:00 2004
Subject: S2885
In-Reply-To: <3174569B9743D511922F00A0C94314230665B63D@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B63D@TYANWEB>
Message-ID: <m3wtxdtb0k.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> I'm little confused. In the static.c
>  
> The superio is already set to IORESOURCE_FIXED.

First.  Double check you have a fairly recent device.c as I moved
the check for IORESOURCE_FIXED the first time I ran into this problem.

Second at check to see if there are any other resources that are not
being set in Config.lb.  It does not look like it from here but...

Eric


From rminnich at lanl.gov  Tue Oct 26 16:52:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Tue Oct 26 16:52:00 2004
Subject: LinuxBIOS debugging with an emulator
In-Reply-To: <9B124F08B3EFDA4F8813B05102DC719501A90273@nh-ex01.nh.bench.com>
References: <9B124F08B3EFDA4F8813B05102DC719501A90273@nh-ex01.nh.bench.com>
Message-ID: <Pine.LNX.4.58.0410260739320.29083@linux.site>


On Tue, 26 Oct 2004 Stephen.Kimball at bench.com wrote:

> 
> Can someone tell me what the starting sequence is with LinuxBIOS?
> 
> Reset jumps to crt0.s.  crt0.s calls auto.E.  auto.E is built using
> romcc, so source-level debugging is not possible.  

ah well :-)

>The statement
> locations can be found using the Lxxxx labels in linuxbios.map.  Then
> hardwaremain is called. Hardwaremain is the first C function called.

yep.

> Crt0 and auto run out of FLASH.  Hardwaremain is the first function
> called after LinuxBIOS is copied to RAM.

sounds good so far.

ron


From YhLu at tyan.com  Tue Oct 26 17:02:00 2004
From: YhLu at tyan.com (YhLu)
Date: Tue Oct 26 17:02:00 2004
Subject: S2885
Message-ID: <3174569B9743D511922F00A0C94314230665B654@TYANWEB>

I add print_debug in device.c
 
                if (resource->flags & IORESOURCE_FIXED) {
                        printk_debug("\t\t%s, base=%08Lx, limit=%08Lx\r\n",
dev_path(dev), resource->base, resource->limit);
                        continue;
                }
 
Found some interesting result
                PNP: 002e.0, base=000003f0, limit=000007ff
                PNP: 002e.1, base=00000378, limit=000007ff
                PNP: 002e.2, base=000003f8, limit=000007ff
                PNP: 002e.3, base=000002f8, limit=000007ff
                PNP: 002e.b, base=00000290, limit=00000fff
                PNP: 002e.5, base=00000060, limit=ffffffff
                PNP: 002e.5, base=00000064, limit=ffffffff
 
1. It real does the continue.
2. it process disabled device,if it is get the fixed values in Config.lb
 
 
PNP: 002e.0 enabled
PNP: 002e.1 disabled
PNP: 002e.2 enabled
PNP: 002e.3 disabled
PNP: 002e.5 enabled
PNP: 002e.6 disabled
PNP: 002e.7 disabled
PNP: 002e.8 disabled
PNP: 002e.9 disabled
PNP: 002e.a disabled
PNP: 002e.b enabled
 
In Config.lb
                                        chip superio/winbond/w83627hf
                                                device pnp 2e.0 on #  Floppy
                                                        io 0x60 = 0x3f0
                                                        irq 0x70 = 6
                                                        drq 0x74 = 2
                                                end
                                                device pnp 2e.1 off #
Parallel Port
                                                        io 0x60 = 0x378
                                                        irq 0x70 = 7
                                                end
                                                device pnp 2e.2 on #  Com1
                                                        io 0x60 = 0x3f8
                                                        irq 0x70 = 4
                                                end
                                                device pnp 2e.3 off #  Com2
                                                        io 0x60 = 0x2f8
                                                        irq 0x70 = 3
                                                end
                                                device pnp 2e.5 on #
Keyboard
                                                        io 0x60 = 0x60
                                                        io 0x62 = 0x64
                                                        irq 0x70 = 1
                                                        irq 0x72 = 12
                                                end
                                                device pnp 2e.6 off end #
CIR
                                                device pnp 2e.7 off end #
GAME_MIDI_GIPO1
                                                device pnp 2e.8 off end #
GPIO2
                                                device pnp 2e.9 off end #
GPIO3
                                                device pnp 2e.a off end #
ACPI
                                                device pnp 2e.b on #  HW
Monitor
                                                        io 0x60 = 0x290
                                                        irq 0x70 = 5
                                                end
                                        end
 
in superio.c
static struct pnp_info pnp_dev_info[] = {
        { &ops, W83627HF_FDC,  PNP_IO0 | PNP_IRQ0 | PNP_DRQ0, { 0x07f8, 0},
},
        { &ops, W83627HF_PP,   PNP_IO0 | PNP_IRQ0 | PNP_DRQ0, { 0x07f8, 0},
},
        { &ops, W83627HF_SP1,  PNP_IO0 | PNP_IRQ0, { 0x7f8, 0 }, },
        { &ops, W83627HF_SP2,  PNP_IO0 | PNP_IRQ0, { 0x7f8, 0 }, },
        // No 4 { 0,},
        { &ops, W83627HF_KBC,  PNP_IO0 | PNP_IO1 | PNP_IRQ0 | PNP_IRQ1, {
0x7ff, 0 }, { 0x7ff, 0x4}, },
        { &ops, W83627HF_CIR, PNP_IO0 | PNP_IRQ0, { 0x7f8, 0 }, },
        { &ops, W83627HF_GAME_MIDI_GPIO1, PNP_IO0 | PNP_IO1 | PNP_IRQ0, {
0x7ff, 0 }, {0x7fe, 4}, },
        { &ops, W83627HF_GPIO2,},
        { &ops, W83627HF_GPIO3,},
        { &ops, W83627HF_ACPI, PNP_IRQ0,  },
        { &ops, W83627HF_HWM,  PNP_IO0 | PNP_IRQ0, { 0xff8, 0 }, },
};
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20041026/b8640f87/attachment.html>

From YhLu at tyan.com  Tue Oct 26 17:55:01 2004
From: YhLu at tyan.com (YhLu)
Date: Tue Oct 26 17:55:01 2004
Subject: S2885
Message-ID: <3174569B9743D511922F00A0C94314230665B66A@TYANWEB>

Eric, 
 
So even the pnp is disabled, the fixed value should be there.
 
I wonder if add                if(!curdev->enabled) continue;
In find_largest_resource is good way to fix it.
 
Regards
 
YH
 
 
static void find_largest_resource(struct pick_largest_state *state,
        struct bus *bus, unsigned long type_mask, unsigned long type)
{
        struct device *curdev;
        for(curdev = bus->children; curdev; curdev = curdev->sibling) {
                int i;
                if(!curdev->enabled) continue;
 
                                        chip superio/winbond/w83627hf
                                                device pnp 2e.0 on #  Floppy
                                                        io 0x60 = 0x3f0
                                                        irq 0x70 = 6
                                                        drq 0x74 = 2
                                                end
                                                device pnp 2e.1 off #
Parallel Port
                                                        io 0x60 = 0x378
                                                        irq 0x70 = 7
                                                end
                                                device pnp 2e.2 on #  Com1
                                                        io 0x60 = 0x3f8
                                                        irq 0x70 = 4
                                                end
                                                device pnp 2e.3 off #  Com2
                                                        io 0x60 = 0x2f8
                                                        irq 0x70 = 3
                                                end
                                                device pnp 2e.5 on #
Keyboard
                                                        io 0x60 = 0x60
                                                        io 0x62 = 0x64
                                                        irq 0x70 = 1
                                                        irq 0x72 = 12
                                                end
                                                device pnp 2e.6 off #  CIR
                                                        io 0x60 = 0x90
                                                end
                                                device pnp 2e.7 off #
GAME_MIDI_GIPO1
                                                        io 0x60 = 0x70
                                                        io 0x62 = 0x74
                                                        irq 0x70 = 5
                                                end
                                                device pnp 2e.8 off end #
GPIO2
                                                device pnp 2e.9 off end #
GPIO3
                                                device pnp 2e.a off end #
ACPI
                                                device pnp 2e.b on #  HW
Monitor
                                                        io 0x60 = 0x290
                                                        irq 0x70 = 5
                                                end
                                        end
 
  _____  

From: YhLu 
Sent: Tuesday, October 26, 2004 3:29 PM
To: ebiederman at lnxi.com
Cc: Ronald G. Minnich; linuxbios at clustermatic.org
Subject: RE: S2885
 
I add print_debug in device.c
 
                if (resource->flags & IORESOURCE_FIXED) {
                        printk_debug("\t\t%s, base=%08Lx, limit=%08Lx\r\n",
dev_path(dev), resource->base, resource->limit);
                        continue;
                }
 
Found some interesting result
                PNP: 002e.0, base=000003f0, limit=000007ff
                PNP: 002e.1, base=00000378, limit=000007ff
                PNP: 002e.2, base=000003f8, limit=000007ff
                PNP: 002e.3, base=000002f8, limit=000007ff
                PNP: 002e.b, base=00000290, limit=00000fff
                PNP: 002e.5, base=00000060, limit=ffffffff
                PNP: 002e.5, base=00000064, limit=ffffffff
 
1. It real does the continue.
2. it process disabled device,if it is get the fixed values in Config.lb
 
 
PNP: 002e.0 enabled
PNP: 002e.1 disabled
PNP: 002e.2 enabled
PNP: 002e.3 disabled
PNP: 002e.5 enabled
PNP: 002e.6 disabled
PNP: 002e.7 disabled
PNP: 002e.8 disabled
PNP: 002e.9 disabled
PNP: 002e.a disabled
PNP: 002e.b enabled
 
In Config.lb
                                        chip superio/winbond/w83627hf
                                                device pnp 2e.0 on #  Floppy
                                                        io 0x60 = 0x3f0
                                                        irq 0x70 = 6
                                                        drq 0x74 = 2
                                                end
                                                device pnp 2e.1 off #
Parallel Port
                                                        io 0x60 = 0x378
                                                        irq 0x70 = 7
                                                end
                                                device pnp 2e.2 on #  Com1
                                                        io 0x60 = 0x3f8
                                                        irq 0x70 = 4
                                                end
                                                device pnp 2e.3 off #  Com2
                                                        io 0x60 = 0x2f8
                                                        irq 0x70 = 3
                                                end
                                                device pnp 2e.5 on #
Keyboard
                                                        io 0x60 = 0x60
                                                        io 0x62 = 0x64
                                                        irq 0x70 = 1
                                                        irq 0x72 = 12
                                                end
                                                device pnp 2e.6 off end #
CIR
                                                device pnp 2e.7 off end #
GAME_MIDI_GIPO1
                                                device pnp 2e.8 off end #
GPIO2
                                                device pnp 2e.9 off end #
GPIO3
                                                device pnp 2e.a off end #
ACPI
                                                device pnp 2e.b on #  HW
Monitor
                                                        io 0x60 = 0x290
                                                        irq 0x70 = 5
                                                end
                                        end
 
in superio.c
static struct pnp_info pnp_dev_info[] = {
        { &ops, W83627HF_FDC,  PNP_IO0 | PNP_IRQ0 | PNP_DRQ0, { 0x07f8, 0},
},
        { &ops, W83627HF_PP,   PNP_IO0 | PNP_IRQ0 | PNP_DRQ0, { 0x07f8, 0},
},
        { &ops, W83627HF_SP1,  PNP_IO0 | PNP_IRQ0, { 0x7f8, 0 }, },
        { &ops, W83627HF_SP2,  PNP_IO0 | PNP_IRQ0, { 0x7f8, 0 }, },
        // No 4 { 0,},
        { &ops, W83627HF_KBC,  PNP_IO0 | PNP_IO1 | PNP_IRQ0 | PNP_IRQ1, {
0x7ff, 0 }, { 0x7ff, 0x4}, },
        { &ops, W83627HF_CIR, PNP_IO0 | PNP_IRQ0, { 0x7f8, 0 }, },
        { &ops, W83627HF_GAME_MIDI_GPIO1, PNP_IO0 | PNP_IO1 | PNP_IRQ0, {
0x7ff, 0 }, {0x7fe, 4}, },
        { &ops, W83627HF_GPIO2,},
        { &ops, W83627HF_GPIO3,},
        { &ops, W83627HF_ACPI, PNP_IRQ0,  },
        { &ops, W83627HF_HWM,  PNP_IO0 | PNP_IRQ0, { 0xff8, 0 }, },
};
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20041026/5e555c9b/attachment.html>

From ebiederman at lnxi.com  Tue Oct 26 20:31:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Oct 26 20:31:01 2004
Subject: Q: Which is used the 855pm or the i855pm code?
Message-ID: <m3oeipt0i4.fsf@maxwell.lnxi.com>

I am walking through the code converting the sizeram() functions
and have run across a duplicate 855pm and the i855pm.

The digitallogic/adl855pc is using the i855pm, so that appears
to be the active one.  

Is there a reason we have two of these?  If not can we just delete
src/northbridge/intel/855pm?

Eric


From YhLu at tyan.com  Tue Oct 26 20:39:00 2004
From: YhLu at tyan.com (YhLu)
Date: Tue Oct 26 20:39:00 2004
Subject: Which is used the 855pm or the i855pm code?
Message-ID: <3174569B9743D511922F00A0C94314230665B697@TYANWEB>

Should be Ron.

You should delete 855pm. Without (i) in i855pm, it will not be processed by
config.g and ....

YH

-----Original Message-----
From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
Sent: Tuesday, October 26, 2004 6:26 PM
To: Ron Minnich
Cc: LinuxBIOS
Subject: Q: Which is used the 855pm or the i855pm code?


I am walking through the code converting the sizeram() functions
and have run across a duplicate 855pm and the i855pm.

The digitallogic/adl855pc is using the i855pm, so that appears
to be the active one.  

Is there a reason we have two of these?  If not can we just delete
src/northbridge/intel/855pm?

Eric
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From YhLu at tyan.com  Tue Oct 26 20:53:00 2004
From: YhLu at tyan.com (YhLu)
Date: Tue Oct 26 20:53:00 2004
Subject: S2885 -- spare 4s in rebooting
Message-ID: <3174569B9743D511922F00A0C94314230665B69D@TYANWEB>

Spare 4s for rebooting
 
I add some comments in s2885/auto.c.
 
In auto.c call soft2_reset directly instead of jmp to __cpu_reset
 
#if 0
                        asm volatile ("jmp __cpu_reset");
#else 
                /* cpu reset also reset the memtroller ????
                        need soft_reset to reset all except keep HT link
freq and width */
                /* So we don't need to 
                        1. jmp to __cpu_reset
                        2. jmp to __main to copy ROM to ram (It costs some
time) 
                        3. call hardwaremain(), it will according to
boot_complete to issue hard_reset in southbridge. 
                                (Actually it is soft2_reset(); --- without
call hard_reset, the memory is corrupted.
                  We will call soft2_reset directly to spare time in 1 and 2
and 3.2
                */
                        distinguish_cpu_resets();
                        soft2_reset();
#endif
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20041026/a8218cc9/attachment.html>

From ginlin at nexcom.com.tw  Tue Oct 26 21:19:00 2004
From: ginlin at nexcom.com.tw (Gin)
Date: Tue Oct 26 21:19:00 2004
Subject: boot linux from an ide
In-Reply-To: <Pine.LNX.4.58.0410260739320.29083@linux.site>
Message-ID: <000001c4bbce$55c9eb90$8e04010a@nexcom.com.tw>

Hi, 
I have a board with intel E7501 and Xeon CPU. We want to boot the linux
kernel from the IDE drive(we don't need the compressed linux kernel
part). What should I change in the config file to make it do that?

Thanks,
Gin
 



From ebiederman at lnxi.com  Tue Oct 26 23:06:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Oct 26 23:06:01 2004
Subject: S2885
In-Reply-To: <3174569B9743D511922F00A0C94314230665B66A@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B66A@TYANWEB>
Message-ID: <m3pt34rdja.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> Eric, 
>  
> So even the pnp is disabled, the fixed value should be there.
>  
> I wonder if add                if(!curdev->enabled) continue;
> In find_largest_resource is good way to fix it.

It is a little weird but that sounds like a sane way to do it.
Although I think a test of !curdev->have_resources is a little
better.  

What puzzles me is that even disabled you seem to have had all of
the resources specified so they should have had IORESOURCE_FIXED set.
So I don't see how they were being looked at.

Eric


From ebiederman at lnxi.com  Wed Oct 27 03:46:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed Oct 27 03:46:01 2004
Subject: [COMMI] Merge recover status...
Message-ID: <m3lldsr0k0.fsf@maxwell.lnxi.com>

I should have fixed the sizeram function for all of the x86 ports.
So while I don't expect everything to work it should mostly a
matter of cleanup of the configuration files now, so it should
be pretty easy.   

The one remaining x86 gotcha is likely adding support for the
via c3 and the transmeta TM5800 cpus that it looks like we try
and support.  It looks like we have a lot of ports that were
started and not completed :(

PPC is still broken.  I need to be fresh to tackle fixing it up.
At the moment I don't have the slightest clue what the PPC code
flow looks like.  I don't see hide nor hare of the dynamic device
tree in the ppc code I have looked at, so I don't know yet where
to start to convert the code.

Anyway the maelstrom of changes is settling down.  So feel free
to take your favorite port and see if you can get it building
or running again.

A build success report from the Stefan's all port builder would
will be interesting.

Eric


sizeram removal/conversion.
- mem.h and sizeram.h and all includes killed because the are no longer needed.
- linuxbios_table.c updated to directly look at the device tree for occupied memory areas.
- first very incomplete stab a converting the ppc code to work with the dynamic device tree
- Ignore resources before we have read them from devices, (if the device is disabled ignore it's resources).
- First stab at Pentium-M support
- add part/init_timer.h making init_timer conditional until there is a better way of handling it.
- Converted all of the x86 sizeram to northbridge set_resources functions.
CVS: ----------------------------------------------------------------------
CVS: Enter Log.  Lines beginning with `CVS:' are removed automatically
CVS:
CVS: Committing in .
CVS:
CVS: Modified Files:
CVS:    src/arch/i386/boot/linuxbios_table.c
CVS:    src/arch/i386/boot/linuxbios_table.h
CVS:    src/arch/ppc/boot/linuxbios_table.c src/arch/ppc/boot/tables.c
CVS:    src/arch/ppc/lib/cpu.c src/arch/ppc/lib/cpuid.c
CVS:    src/boot/hardwaremain.c src/config/Options.lb
CVS:    src/cpu/amd/model_fxx/Config.lb src/cpu/x86/tsc/Config.lb
CVS:    src/devices/device.c src/include/part/fallback_boot.h
CVS:    src/mainboard/arima/hdama/Options.lb
CVS:    src/mainboard/arima/hdama/auto.c
CVS:    src/mainboard/digitallogic/adl855pc/Config.lb
CVS:    src/mainboard/emulation/qemu-i386/Config.lb
CVS:    src/northbridge/amd/amdk8/northbridge.c
CVS:    src/northbridge/emulation/qemu-i386/northbridge.c
CVS:    src/northbridge/intel/e7501/northbridge.c
CVS:    src/northbridge/intel/i855pm/northbridge.c
CVS:    src/northbridge/motorola/mpc107/mpc107.c
CVS:    src/northbridge/transmeta/tm5800/northbridge.c
CVS:    src/northbridge/via/vt8601/northbridge.c
CVS:    src/northbridge/via/vt8623/northbridge.c
CVS:    src/southbridge/intel/i82870/p64h2_pci_parity.c
CVS: Added Files:
CVS:    src/include/part/init_timer.h
CVS: Removed Files:
CVS:    src/include/mem.h src/include/part/sizeram.h
CVS: ----------------------------------------------------------------------


From stepan at openbios.org  Wed Oct 27 08:57:01 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Wed Oct 27 08:57:01 2004
Subject: boot linux from an ide
In-Reply-To: <000001c4bbce$55c9eb90$8e04010a@nexcom.com.tw>
References: <Pine.LNX.4.58.0410260739320.29083@linux.site> <000001c4bbce$55c9eb90$8e04010a@nexcom.com.tw>
Message-ID: <20041027141917.GA4306@openbios.org>

* Gin <ginlin at nexcom.com.tw> [041027 04:40]:
> Hi, 
> I have a board with intel E7501 and Xeon CPU. We want to boot the linux
> kernel from the IDE drive(we don't need the compressed linux kernel
> part). What should I change in the config file to make it do that?

use filo as a payload.

Stefan



From rminnich at lanl.gov  Wed Oct 27 09:19:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Wed Oct 27 09:19:00 2004
Subject: S2885
In-Reply-To: <3174569B9743D511922F00A0C94314230665B66A@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B66A@TYANWEB>
Message-ID: <Pine.LNX.4.58.0410270840190.2564@linux.site>


On Tue, 26 Oct 2004, YhLu wrote:

> Eric, 
>  
> So even the pnp is disabled, the fixed value should be there.


folks, sorry the LANL guys are not engaged in this discussions :-(


we're on Infinibomb all week :-(

ron


From rminnich at lanl.gov  Wed Oct 27 09:25:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Wed Oct 27 09:25:01 2004
Subject: Q: Which is used the 855pm or the i855pm code?
In-Reply-To: <m3oeipt0i4.fsf@maxwell.lnxi.com>
References: <m3oeipt0i4.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.58.0410270845180.2564@linux.site>


On Tue, 26 Oct 2004, Eric W. Biederman wrote:

> 
> I am walking through the code converting the sizeram() functions
> and have run across a duplicate 855pm and the i855pm.

my fault. Sorry, ignore 855pm. 

> Is there a reason we have two of these?  If not can we just delete
> src/northbridge/intel/855pm?

yeah, delete it. 

Thanks very much for looking this port. 

It's worse than that. Early docs I had indicated it was the pm part but I 
think it is the GM part, so that code is probably GM code by now. I have 
not had time to go back and put that back together. 

ron


From rminnich at lanl.gov  Wed Oct 27 09:27:10 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Wed Oct 27 09:27:10 2004
Subject: Which is used the 855pm or the i855pm code?
In-Reply-To: <3174569B9743D511922F00A0C94314230665B697@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B697@TYANWEB>
Message-ID: <Pine.LNX.4.58.0410270847140.2564@linux.site>


On Tue, 26 Oct 2004, YhLu wrote:

> You should delete 855pm. Without (i) in i855pm, it will not be processed by
> config.g and ....

that's what bit me. 

ron


From rminnich at lanl.gov  Wed Oct 27 09:30:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Wed Oct 27 09:30:01 2004
Subject: boot linux from an ide
In-Reply-To: <000001c4bbce$55c9eb90$8e04010a@nexcom.com.tw>
References: <000001c4bbce$55c9eb90$8e04010a@nexcom.com.tw>
Message-ID: <Pine.LNX.4.58.0410270848270.2564@linux.site>


On Wed, 27 Oct 2004, Gin wrote:

> I have a board with intel E7501 and Xeon CPU. We want to boot the linux
> kernel from the IDE drive(we don't need the compressed linux kernel
> part). What should I change in the config file to make it do that?

use FILO or ETherboot, or (best) enable FILO in etherboot, and you can 
boot kernel from ext2 partitions.

ron


From rminnich at lanl.gov  Wed Oct 27 09:36:02 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Wed Oct 27 09:36:02 2004
Subject: [COMMI] Merge recover status...
In-Reply-To: <m3lldsr0k0.fsf@maxwell.lnxi.com>
References: <m3lldsr0k0.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.58.0410270856430.2564@linux.site>


On Wed, 27 Oct 2004, Eric W. Biederman wrote:

> The one remaining x86 gotcha is likely adding support for the
> via c3 and the transmeta TM5800 cpus that it looks like we try
> and support.  It looks like we have a lot of ports that were
> started and not completed :(

yes, transmeta refused to help with the details of DDR on the new cpu, in 
spite of promises to do so, hence that effort (with a 3rd party) ended. 

A shame.

ron



From YhLu at tyan.com  Wed Oct 27 11:44:01 2004
From: YhLu at tyan.com (YhLu)
Date: Wed Oct 27 11:44:01 2004
Subject: S2885
Message-ID: <3174569B9743D511922F00A0C94314230665B6C9@TYANWEB>

I  will try !curdev->have_resources

Regards

YH

-----Original Message-----
From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
Sent: Tuesday, October 26, 2004 9:28 PM
To: YhLu
Cc: Ronald G. Minnich; linuxbios at clustermatic.org
Subject: Re: S2885

YhLu <YhLu at tyan.com> writes:

> Eric, 
>  
> So even the pnp is disabled, the fixed value should be there.
>  
> I wonder if add                if(!curdev->enabled) continue;
> In find_largest_resource is good way to fix it.

It is a little weird but that sounds like a sane way to do it.
Although I think a test of !curdev->have_resources is a little
better.  

What puzzles me is that even disabled you seem to have had all of
the resources specified so they should have had IORESOURCE_FIXED set.
So I don't see how they were being looked at.

Eric


From ebiederman at lnxi.com  Wed Oct 27 11:53:59 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed Oct 27 11:53:59 2004
Subject: [COMMI] Merge recover status...
In-Reply-To: <Pine.LNX.4.58.0410270856430.2564@linux.site>
References: <m3lldsr0k0.fsf@maxwell.lnxi.com>
	<Pine.LNX.4.58.0410270856430.2564@linux.site>
Message-ID: <m3wtxcrssf.fsf@maxwell.lnxi.com>

"Ronald G. Minnich" <rminnich at lanl.gov> writes:

> On Wed, 27 Oct 2004, Eric W. Biederman wrote:
> 
> > The one remaining x86 gotcha is likely adding support for the
> > via c3 and the transmeta TM5800 cpus that it looks like we try
> > and support.  It looks like we have a lot of ports that were
> > started and not completed :(
> 
> yes, transmeta refused to help with the details of DDR on the new cpu, in 
> spite of promises to do so, hence that effort (with a 3rd party) ended. 
> 
> A shame.

Yes.  Somehow I would have suspected the procedure would have been
the same, or simpler though.  Dump the SPD values from the DIMMs into the
northbridge.

Eric


From ebiederman at lnxi.com  Wed Oct 27 11:56:21 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed Oct 27 11:56:21 2004
Subject: Q: Which is used the 855pm or the i855pm code?
In-Reply-To: <Pine.LNX.4.58.0410270845180.2564@linux.site>
References: <m3oeipt0i4.fsf@maxwell.lnxi.com>
	<Pine.LNX.4.58.0410270845180.2564@linux.site>
Message-ID: <m3sm80rsph.fsf@maxwell.lnxi.com>

"Ronald G. Minnich" <rminnich at lanl.gov> writes:

> On Tue, 26 Oct 2004, Eric W. Biederman wrote:
> 
> > 
> > I am walking through the code converting the sizeram() functions
> > and have run across a duplicate 855pm and the i855pm.
> 
> my fault. Sorry, ignore 855pm. 
> 
> > Is there a reason we have two of these?  If not can we just delete
> > src/northbridge/intel/855pm?
> 
> yeah, delete it. 

Deleted.

> Thanks very much for looking this port. 
> 
> It's worse than that. Early docs I had indicated it was the pm part but I 
> think it is the GM part, so that code is probably GM code by now. I have 
> not had time to go back and put that back together. 

Ok.  The GM and the PM appear to be strongly related so I don't think it
is likely to be a problem.  It is just a pain to start updating a port
so it works and then you come to realize the port never worked.

Eric




From rminnich at lanl.gov  Wed Oct 27 11:58:33 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Wed Oct 27 11:58:33 2004
Subject: [COMMI] Merge recover status...
In-Reply-To: <m3wtxcrssf.fsf@maxwell.lnxi.com>
References: <m3lldsr0k0.fsf@maxwell.lnxi.com> <Pine.LNX.4.58.0410270856430.2564@linux.site>
 <m3wtxcrssf.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.58.0410271113130.2564@linux.site>


On Wed, 27 Oct 2004, Eric W. Biederman wrote:

> Yes.  Somehow I would have suspected the procedure would have been
> the same, or simpler though.  Dump the SPD values from the DIMMs into the
> northbridge.

the new policy is we put our effort first into efforts with cooperative 
vendors, and the other efforts take a back seat. 

I agree with you, we could reverse engineer this easily, but I do know of 
a company that has done the port, so we are waiting to talk to them first. 

ron


From ebiederman at lnxi.com  Wed Oct 27 12:00:45 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed Oct 27 12:00:45 2004
Subject: S2885 -- spare 4s in rebooting
In-Reply-To: <3174569B9743D511922F00A0C94314230665B69D@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B69D@TYANWEB>
Message-ID: <m3oeiorsij.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> Spare 4s for rebooting
>  
> I add some comments in s2885/auto.c.
>  
> In auto.c call soft2_reset directly instead of jmp to __cpu_reset

Hmm. That does seem to have some merit.  Where are you seeing the code
run slowly?  In particular I am wondering if this is an mtrr setup
problem or something else you are avoiding.

Eric


From ebiederman at lnxi.com  Wed Oct 27 12:06:11 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed Oct 27 12:06:11 2004
Subject: Which is used the 855pm or the i855pm code?
In-Reply-To: <Pine.LNX.4.58.0410270847140.2564@linux.site>
References: <3174569B9743D511922F00A0C94314230665B697@TYANWEB>
	<Pine.LNX.4.58.0410270847140.2564@linux.site>
Message-ID: <m3k6tcrs4v.fsf@maxwell.lnxi.com>

"Ronald G. Minnich" <rminnich at lanl.gov> writes:

> On Tue, 26 Oct 2004, YhLu wrote:
> 
> > You should delete 855pm. Without (i) in i855pm, it will not be processed by
> > config.g and ....
> 
> that's what bit me. 

Hmm. I am confused about what part of config.g makes that a problem,
but I guess I can look.

Speaking of config.g what would it take to not allow uses in anything
except src/mainboard/xxx/Options.lb.  

Having one place were we simply declare which variables we are going
to be using for the entire board, (while still allowing them to be set
elsewhere) seems sane.  That actually reflects the current state
of the mainboard configuration right now.

When I added part/init_timer.h and set HAVE_INIT_TIMER
in src/cpu/k8/Config.lb and src/cpu/tsc/Config.lb I noticed
that I had to include a uses directive in those Config.lb files.

Eric


From YhLu at tyan.com  Wed Oct 27 12:08:20 2004
From: YhLu at tyan.com (YhLu)
Date: Wed Oct 27 12:08:20 2004
Subject: [COMMI] Merge recover status...
Message-ID: <3174569B9743D511922F00A0C94314230665B6D2@TYANWEB>

Amd k8 northbridge.c  line 717

for(i = 0; i < 7; i++) {

is it shoule be 8 instead of 7?

Regards

YH


-----Original Message-----
From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
Sent: Wednesday, October 27, 2004 10:10 AM
To: Ronald G. Minnich
Cc: LinuxBIOS
Subject: Re: [COMMI] Merge recover status...

"Ronald G. Minnich" <rminnich at lanl.gov> writes:

> On Wed, 27 Oct 2004, Eric W. Biederman wrote:
> 
> > The one remaining x86 gotcha is likely adding support for the
> > via c3 and the transmeta TM5800 cpus that it looks like we try
> > and support.  It looks like we have a lot of ports that were
> > started and not completed :(
> 
> yes, transmeta refused to help with the details of DDR on the new cpu, in 
> spite of promises to do so, hence that effort (with a 3rd party) ended. 
> 
> A shame.

Yes.  Somehow I would have suspected the procedure would have been
the same, or simpler though.  Dump the SPD values from the DIMMs into the
northbridge.

Eric
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From rminnich at lanl.gov  Wed Oct 27 12:31:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Wed Oct 27 12:31:01 2004
Subject: Which is used the 855pm or the i855pm code?
In-Reply-To: <m3k6tcrs4v.fsf@maxwell.lnxi.com>
References: <3174569B9743D511922F00A0C94314230665B697@TYANWEB>
 <Pine.LNX.4.58.0410270847140.2564@linux.site> <m3k6tcrs4v.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.58.0410271148500.2564@linux.site>


On Wed, 27 Oct 2004, Eric W. Biederman wrote:

> Hmm. I am confused about what part of config.g makes that a problem,
> but I guess I can look.

generated C identifiers somewhere. I don't think it is worth fussing over 
too much, but that's your call. :-)

> Speaking of config.g what would it take to not allow uses in anything
> except src/mainboard/xxx/Options.lb.  

that is a problem for greg and PPC mezzanine cards. We're going to maybe 
need options in the cpu and one other directory. I would like to make it 
impossible for Options.lb anywhere else.

> When I added part/init_timer.h and set HAVE_INIT_TIMER
> in src/cpu/k8/Config.lb and src/cpu/tsc/Config.lb I noticed
> that I had to include a uses directive in those Config.lb files.

eek. I agree with you.

ron


From YhLu at tyan.com  Wed Oct 27 12:36:02 2004
From: YhLu at tyan.com (YhLu)
Date: Wed Oct 27 12:36:02 2004
Subject: S2885 -- spare 4s in rebooting
Message-ID: <3174569B9743D511922F00A0C94314230665B6E0@TYANWEB>

With cpu_reset

~ # reboot
INIT: Sending processes the TERM signal
INIT: Cmos information update
Getting settings
Stop port mapper
Shutdown syslog daemon
Shutdown klogd daemon
Sending all processes the TERM signal...
Sending all processes the KILL signal..
Please, stand by while rebooting the system ...
Restarting system.
Copying LinuxBIOS to ram. <------- here take sometime ---skipped by
Soft2_reset
Jumping to LinuxBIOS. <------------------ skipped by Soft2_reset
LinuxBIOS-1.1.72.0_Fallback Tue Oct 26 18:48:45 PDT 2004 rebooting...----->
skipped by soft2_reset

LinuxBIOS-1.1.72.0_Fallback Tue Oct 26 18:48:45 PDT 2004 starting...
Ram1.00
Ram1.01
Ram2.00
Ram2.01
Ram3
Initializing memory:  done
Initializing memory:  done
Clearing initial memory region:  done
Ram4
Copying LinuxBIOS to ram.
Jumping to LinuxBIOS.
LinuxBIOS-1.1.72.0_Fallback Tue Oct 26 18:48:45 PDT 2004 booting...
Finding PCI configuration type.
PCI: Using configuration type 1

-----Original Message-----
From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
Sent: Wednesday, October 27, 2004 10:16 AM
To: YhLu
Cc: Ronald G. Minnich; linuxbios at clustermatic.org
Subject: Re: S2885 -- spare 4s in rebooting

YhLu <YhLu at tyan.com> writes:

> Spare 4s for rebooting
>  
> I add some comments in s2885/auto.c.
>  
> In auto.c call soft2_reset directly instead of jmp to __cpu_reset

Hmm. That does seem to have some merit.  Where are you seeing the code
run slowly?  In particular I am wondering if this is an mtrr setup
problem or something else you are avoiding.

Eric


From stephen.kimball at bench.com  Wed Oct 27 13:25:00 2004
From: stephen.kimball at bench.com (Steve Kimball)
Date: Wed Oct 27 13:25:00 2004
Subject: boot linux from an ide
In-Reply-To: <Pine.LNX.4.58.0410270848270.2564@linux.site>
References: <000001c4bbce$55c9eb90$8e04010a@nexcom.com.tw>
	 <Pine.LNX.4.58.0410270848270.2564@linux.site>
Message-ID: <1098902737.2770.33.camel@localhost.localdomain>

On Wed, 2004-10-27 at 10:48, Ronald G. Minnich wrote:
> On Wed, 27 Oct 2004, Gin wrote:
> 
> > I have a board with intel E7501 and Xeon CPU. We want to boot the linux
> > kernel from the IDE drive(we don't need the compressed linux kernel
> > part). What should I change in the config file to make it do that?
> 
> use FILO or ETherboot, or (best) enable FILO in etherboot, and you can 
> boot kernel from ext2 partitions.
> 
> ron

To use FILO or Etherboot you change the payload.
So you need to change the 
   freebios2/targets/<vendor>/<board>/Config.lb
file to point to the FILO or Etherboot payload 
and make linuxbios.rom.

Steve


From ebiederman at lnxi.com  Wed Oct 27 13:32:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed Oct 27 13:32:00 2004
Subject: [COMMI] Merge recover status...
In-Reply-To: <3174569B9743D511922F00A0C94314230665B6D2@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B6D2@TYANWEB>
Message-ID: <m3y8hsm1pz.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> Amd k8 northbridge.c  line 717
> 
> for(i = 0; i < 7; i++) {
> 
> is it shoule be 8 instead of 7?

Yes.  Thanks for catching that.

Eric


From ebiederman at lnxi.com  Wed Oct 27 13:35:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed Oct 27 13:35:00 2004
Subject: [COMMI] Merge recover status...
In-Reply-To: <Pine.LNX.4.58.0410271113130.2564@linux.site>
References: <m3lldsr0k0.fsf@maxwell.lnxi.com>
	<Pine.LNX.4.58.0410270856430.2564@linux.site>
	<m3wtxcrssf.fsf@maxwell.lnxi.com>
	<Pine.LNX.4.58.0410271113130.2564@linux.site>
Message-ID: <m3u0sgm1me.fsf@maxwell.lnxi.com>

"Ronald G. Minnich" <rminnich at lanl.gov> writes:

> On Wed, 27 Oct 2004, Eric W. Biederman wrote:
> 
> > Yes.  Somehow I would have suspected the procedure would have been
> > the same, or simpler though.  Dump the SPD values from the DIMMs into the
> > northbridge.
> 
> the new policy is we put our effort first into efforts with cooperative 
> vendors, and the other efforts take a back seat. 

I think that is largely how I have always worked.  Although it is slowly
getting to the point where it is interesting to handle more cases.

> I agree with you, we could reverse engineer this easily, but I do know of 
> a company that has done the port, so we are waiting to talk to them first. 

That's fine.

Eric


From rsmith at bitworks.com  Wed Oct 27 13:40:01 2004
From: rsmith at bitworks.com (Richard Smith)
Date: Wed Oct 27 13:40:01 2004
Subject: Can some EPIA-M person fix this?
In-Reply-To: <20041027141917.GA4306@openbios.org>
References: <Pine.LNX.4.58.0410260739320.29083@linux.site> <000001c4bbce$55c9eb90$8e04010a@nexcom.com.tw> <20041027141917.GA4306@openbios.org>
Message-ID: <417FF0AE.3080103@bitworks.com>

I found this last night.

http://www.linuxjournal.com/article.php?sid=7857

Something is wrong with his setup as 9 seconds to get to the kernel is 
way too slow.  I'm getting that on my setup in less than a second.  But 
I don't know any thing about the EPIA so I can't help him much.

-- 
Richard A. Smith




From rminnich at lanl.gov  Wed Oct 27 14:21:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Wed Oct 27 14:21:00 2004
Subject: Can some EPIA-M person fix this?
In-Reply-To: <417FF0AE.3080103@bitworks.com>
References: <Pine.LNX.4.58.0410260739320.29083@linux.site>
 <000001c4bbce$55c9eb90$8e04010a@nexcom.com.tw> <20041027141917.GA4306@openbios.org>
 <417FF0AE.3080103@bitworks.com>
Message-ID: <Pine.LNX.4.58.0410271342140.2564@linux.site>


On Wed, 27 Oct 2004, Richard Smith wrote:

> I found this last night.
> 
> http://www.linuxjournal.com/article.php?sid=7857
> 
> Something is wrong with his setup as 9 seconds to get to the kernel is way too
> slow.  I'm getting that on my setup in less than a second.  But I don't know
> any thing about the EPIA so I can't help him much.
> 

I send them a note offering help, no word back. 

I don't know why it's so slow.

ron


From rminnich at lanl.gov  Wed Oct 27 14:49:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Wed Oct 27 14:49:01 2004
Subject: boot linux from an ide
In-Reply-To: <1098902737.2770.33.camel@localhost.localdomain>
References: <000001c4bbce$55c9eb90$8e04010a@nexcom.com.tw> 
 <Pine.LNX.4.58.0410270848270.2564@linux.site> <1098902737.2770.33.camel@localhost.localdomain>
Message-ID: <Pine.LNX.4.58.0410271309180.2564@linux.site>


On Wed, 27 Oct 2004, Steve Kimball wrote:

> To use FILO or Etherboot you change the payload.
> So you need to change the 
>    freebios2/targets/<vendor>/<board>/Config.lb
> file to point to the FILO or Etherboot payload 
> and make linuxbios.rom.

don't forget you can make your own!

I have 

targets/arima/hdama/Config.filo.lb

and I do this:

./buildtarget arima/hdama/Config.filo.lb


File is this:


# Sample config file for the Arima HDAMA

target hdama.filo
mainboard arima/hdama

romimage "normal"
	option USE_FALLBACK_IMAGE=0
	option ROM_IMAGE_SIZE=0x10000
	option LINUXBIOS_EXTRA_VERSION=".0Normal"
	payload /opt/filo/normal/filo.elf
end

romimage "fallback" 
	option USE_FALLBACK_IMAGE=1
	option ROM_IMAGE_SIZE=0x10000
	option LINUXBIOS_EXTRA_VERSION=".0Fallback"
	payload /opt/filo/fallback/filo.elf
end

buildrom ./linuxbios.rom ROM_SIZE "normal" "fallback"


From jbors at mail.ru  Wed Oct 27 14:52:01 2004
From: jbors at mail.ru (Dmitry Borisov)
Date: Wed Oct 27 14:52:01 2004
Subject: Can some EPIA-M person fix this=?koi8-r?Q?=3F?=
In-Reply-To: <Pine.LNX.4.58.0410271342140.2564@linux.site>
Message-ID: <E1CMuBm-000HHh-00.jbors-mail-ru@f26.mail.ru>

From: "Ronald G. Minnich" <rminnich at lanl.gov>
To: Richard Smith <rsmith at bitworks.com>
Date: Wed, 27 Oct 2004 13:42:40 -0600 (MDT)
Subject: Re: Can some EPIA-M person fix this?

> On Wed, 27 Oct 2004, Richard Smith wrote:
> 
> > I found this last night.
> > 
> > http://www.linuxjournal.com/article.php?sid=7857
> > 
> > Something is wrong with his setup as 9 seconds to get to the kernel is way too
> > slow.  I'm getting that on my setup in less than a second.  But I don't know
> > any thing about the EPIA so I can't help him much.
> > 
> 
> I send them a note offering help, no word back. 
> 
> I don't know why it's so slow.

Don't worry about them. They have enough money to hire somebody who can make it work, but they barely contribute it back :(
I also was not able to have it <7sec, but I probably fix that before the NY as I need it badly.
It will not be compatible with linuxbios though( epibios may be ? )
Dmitry/


From linuxbios at mikebell.org  Wed Oct 27 14:54:14 2004
From: linuxbios at mikebell.org (linuxbios at mikebell.org)
Date: Wed Oct 27 14:54:14 2004
Subject: Can some EPIA-M person fix this?
In-Reply-To: <Pine.LNX.4.58.0410271342140.2564@linux.site>
References: <Pine.LNX.4.58.0410260739320.29083@linux.site> <000001c4bbce$55c9eb90$8e04010a@nexcom.com.tw> <20041027141917.GA4306@openbios.org> <417FF0AE.3080103@bitworks.com> <Pine.LNX.4.58.0410271342140.2564@linux.site>
Message-ID: <20041027200030.GJ968@tinyvaio.nome.ca>

On Wed, Oct 27, 2004 at 01:42:40PM -0600, Ronald G. Minnich wrote:
> I send them a note offering help, no word back. 
> 
> I don't know why it's so slow.

We looked at it earlier and found several very large sleeps and
decompression were the primary culprits. With the sleeps
disabled/shorted and compression turned off, it was much faster, though
still nothing like as fast as the original epia.


From yosh at yosh.biz  Wed Oct 27 15:07:00 2004
From: yosh at yosh.biz (Adrien Moulin)
Date: Wed Oct 27 15:07:00 2004
Subject: Can some EPIA-M person fix this?
In-Reply-To: <Pine.LNX.4.58.0410271342140.2564@linux.site>
References: <Pine.LNX.4.58.0410260739320.29083@linux.site> <000001c4bbce$55c9eb90$8e04010a@nexcom.com.tw> <20041027141917.GA4306@openbios.org> <417FF0AE.3080103@bitworks.com> <Pine.LNX.4.58.0410271342140.2564@linux.site>
Message-ID: <41800501.7030401@yosh.biz>

Ronald G. Minnich wrote:

> I don't know why it's so slow.

I had about the same timing some months ago, but with freebios2 and the 
patch from Nick Barker I get about 1 second to go to FILO.
This is with the loglevel set to 0, it was *much* longer with loglevel 
set to 9.

-- 
Adrien Moulin


From rsmith at bitworks.com  Wed Oct 27 15:09:17 2004
From: rsmith at bitworks.com (Richard Smith)
Date: Wed Oct 27 15:09:17 2004
Subject: Can some EPIA-M person fix this?
In-Reply-To: <20041027200030.GJ968@tinyvaio.nome.ca>
References: <Pine.LNX.4.58.0410260739320.29083@linux.site> <000001c4bbce$55c9eb90$8e04010a@nexcom.com.tw> <20041027141917.GA4306@openbios.org> <417FF0AE.3080103@bitworks.com> <Pine.LNX.4.58.0410271342140.2564@linux.site> <20041027200030.GJ968@tinyvaio.nome.ca>
Message-ID: <41800523.9050209@bitworks.com>

linuxbios at mikebell.org wrote:

> On Wed, Oct 27, 2004 at 01:42:40PM -0600, Ronald G. Minnich wrote:

>>I send them a note offering help, no word back. 
>>
>>I don't know why it's so slow.
>  
> We looked at it earlier and found several very large sleeps and
> decompression were the primary culprits. With the sleeps
> disabled/shorted and compression turned off, it was much faster, though
> still nothing like as fast as the original epia.

So what's his new serial log look like now?   Is it still 300mS to 
enable the RAM?

-- 
Richard A. Smith




From rminnich at lanl.gov  Wed Oct 27 15:13:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Wed Oct 27 15:13:00 2004
Subject: Can some EPIA-M person fix this?
In-Reply-To: <41800501.7030401@yosh.biz>
References: <Pine.LNX.4.58.0410260739320.29083@linux.site>
 <000001c4bbce$55c9eb90$8e04010a@nexcom.com.tw> <20041027141917.GA4306@openbios.org>
 <417FF0AE.3080103@bitworks.com> <Pine.LNX.4.58.0410271342140.2564@linux.site>
 <41800501.7030401@yosh.biz>
Message-ID: <Pine.LNX.4.58.0410271434590.2564@linux.site>

I think they did set loglevel too high, judging by some of what they said.

lotsa prints will slow you down a LOT

ron



From rsmith at bitworks.com  Wed Oct 27 15:48:01 2004
From: rsmith at bitworks.com (Richard Smith)
Date: Wed Oct 27 15:48:01 2004
Subject: Can some EPIA-M person fix this?
In-Reply-To: <E1CMuBm-000HHh-00.jbors-mail-ru@f26.mail.ru>
References: <E1CMuBm-000HHh-00.jbors-mail-ru@f26.mail.ru>
Message-ID: <41800EC8.1050109@bitworks.com>

Dmitry Borisov wrote:


> Don't worry about them. They have enough money to hire somebody who can make it work, but they barely contribute it back :(
> I also was not able to have it <7sec, but I probably fix that before the NY as I need it badly.
> It will not be compatible with linuxbios though( epibios may be ? )

Well the problem is that its bad publicity.  Of course any publicity is 
acutally good for LB but it would be nice to have those numbers be 
really small and the article talking about how LB was the best solution 
and as a bonus its open source rather than just an OK solution thats 
open source.

-- 
Richard A. Smith




From YhLu at tyan.com  Wed Oct 27 15:54:01 2004
From: YhLu at tyan.com (YhLu)
Date: Wed Oct 27 15:54:01 2004
Subject: boot linux from an ide
Message-ID: <3174569B9743D511922F00A0C94314230665B712@TYANWEB>

Just remind:

His MB has E7501 ....

So first step is make freebios2 work on that.

He may need to copy Tyan S2735 to make his MB copy at first. Then he .....


Regards

YH

-----Original Message-----
From: Ronald G. Minnich [mailto:rminnich at lanl.gov] 
Sent: Wednesday, October 27, 2004 12:11 PM
To: Steve Kimball
Cc: Gin; linuxbios at clustermatic.org
Subject: Re: boot linux from an ide



On Wed, 27 Oct 2004, Steve Kimball wrote:

> To use FILO or Etherboot you change the payload.
> So you need to change the 
>    freebios2/targets/<vendor>/<board>/Config.lb
> file to point to the FILO or Etherboot payload 
> and make linuxbios.rom.

don't forget you can make your own!

I have 

targets/arima/hdama/Config.filo.lb

and I do this:

./buildtarget arima/hdama/Config.filo.lb


File is this:


# Sample config file for the Arima HDAMA

target hdama.filo
mainboard arima/hdama

romimage "normal"
	option USE_FALLBACK_IMAGE=0
	option ROM_IMAGE_SIZE=0x10000
	option LINUXBIOS_EXTRA_VERSION=".0Normal"
	payload /opt/filo/normal/filo.elf
end

romimage "fallback" 
	option USE_FALLBACK_IMAGE=1
	option ROM_IMAGE_SIZE=0x10000
	option LINUXBIOS_EXTRA_VERSION=".0Fallback"
	payload /opt/filo/fallback/filo.elf
end

buildrom ./linuxbios.rom ROM_SIZE "normal" "fallback"
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From jbors at mail.ru  Wed Oct 27 15:57:00 2004
From: jbors at mail.ru (Dmitry Borisov)
Date: Wed Oct 27 15:57:00 2004
Subject: Can some EPIA-M person fix this=?koi8-r?Q?=3F?=
In-Reply-To: <41800EC8.1050109@bitworks.com>
Message-ID: <E1CMvAq-000DkQ-00.jbors-mail-ru@f27.mail.ru>

From: Richard Smith
To: Dmitry Borisov 
Date: Wed, 27 Oct 2004 16:10:32 -0500
Subject: Re: Can some EPIA-M person fix this?

> Well the problem is that its bad publicity.  Of course any publicity is 
> acutally good for LB but it would be nice to have those numbers be 
> really small and the article talking about how LB was the best solution 
> and as a bonus its open source rather than just an OK solution thats 
> open source.

Well, The problem is in companies that don't want their solution to get better. 
VIA does not give any details about CLE chipset at all. This way you cannot expect LB work faster/better than legacy software.
So when even such innovative company as carbot claims that they are unable to use VIA solutions along the way, it may force somebody to think.
Ask Ron about some other vendors who's more responsible than VIA and how fast LB works there...
I'm also thinking to switch to some other motherboard with better docs support.
Dmitry/


From sxpert at esitcom.org  Wed Oct 27 17:36:01 2004
From: sxpert at esitcom.org (Amaury Jacquot)
Date: Wed Oct 27 17:36:01 2004
Subject: Can some EPIA-M person fix this?
In-Reply-To: <417FF0AE.3080103@bitworks.com>
References: <Pine.LNX.4.58.0410260739320.29083@linux.site>
	 <000001c4bbce$55c9eb90$8e04010a@nexcom.com.tw>
	 <20041027141917.GA4306@openbios.org>  <417FF0AE.3080103@bitworks.com>
Message-ID: <1098917923.9293.1.camel@localhost>

On Wed, 2004-10-27 at 14:02 -0500, Richard Smith wrote:
> I found this last night.
> 
> http://www.linuxjournal.com/article.php?sid=7857
> 
> Something is wrong with his setup as 9 seconds to get to the kernel is 
> way too slow.  I'm getting that on my setup in less than a second.  But 
> I don't know any thing about the EPIA so I can't help him much.
> 

I am to make one of those for myself and would be glad to have something
that'd work for sure (using an MII 12000 here)
currently, booting my gentoo is about 2 minutes...



From marc at geekythings.com  Wed Oct 27 17:59:00 2004
From: marc at geekythings.com (Marc Nicholas)
Date: Wed Oct 27 17:59:00 2004
Subject: Can some EPIA-M person fix this?
In-Reply-To: <1098917923.9293.1.camel@localhost>
References: <Pine.LNX.4.58.0410260739320.29083@linux.site> 
 <000001c4bbce$55c9eb90$8e04010a@nexcom.com.tw>  <20041027141917.GA4306@openbios.org>
  <417FF0AE.3080103@bitworks.com> <1098917923.9293.1.camel@localhost>
Message-ID: <Pine.GSO.4.60.0410271914170.5213@nerd>


On Thu, 28 Oct 2004, Amaury Jacquot wrote:

> I am to make one of those for myself and would be glad to have something
> that'd work for sure (using an MII 12000 here)
> currently, booting my gentoo is about 2 minutes...

I'm about to try the same wsith an MII 10000.... :D

-marc


From bari at onelabs.com  Wed Oct 27 20:57:01 2004
From: bari at onelabs.com (Bari Ari)
Date: Wed Oct 27 20:57:01 2004
Subject: Epia-N
Message-ID: <41805791.8000008@onelabs.com>

Has anyone started working on a port to the Epia-N yet? It uses the new 
CN400 northbridge and the VT8237 sothbridge.

-Bari


From rminnich at lanl.gov  Wed Oct 27 21:04:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Wed Oct 27 21:04:00 2004
Subject: Epia-N
In-Reply-To: <41805791.8000008@onelabs.com>
References: <41805791.8000008@onelabs.com>
Message-ID: <Pine.LNX.4.58.0410272026230.5895@linux.site>


On Wed, 27 Oct 2004, Bari Ari wrote:

> Has anyone started working on a port to the Epia-N yet? It uses the new CN400
> northbridge and the VT8237 sothbridge.

do you think we'll get docs?

ron


From marc at geekythings.com  Wed Oct 27 21:17:00 2004
From: marc at geekythings.com (Marc Nicholas)
Date: Wed Oct 27 21:17:00 2004
Subject: Epia-N
In-Reply-To: <41805791.8000008@onelabs.com>
References: <41805791.8000008@onelabs.com>
Message-ID: <Pine.GSO.4.60.0410272233000.5385@nerd>

Does this mean you have one? I didn't know they were in the wild yet...

On Wed, 27 Oct 2004, Bari Ari wrote:

> Has anyone started working on a port to the Epia-N yet? It uses the new CN400 
> northbridge and the VT8237 sothbridge.
>
> -Bari
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>


From ginlin at nexcom.com.tw  Wed Oct 27 21:26:00 2004
From: ginlin at nexcom.com.tw (Gin)
Date: Wed Oct 27 21:26:00 2004
Subject: boot linux from an ide
In-Reply-To: <3174569B9743D511922F00A0C94314230665B712@TYANWEB>
Message-ID: <000001c4bc98$7b6935c0$8e04010a@nexcom.com.tw>

Thanks everyone. I found the Config file for Tyan S2735.
1. why are the Config.lb files different under /target and /src for
Tyan/S2735? Which one should I use? Also the one under /target doesn't
specify the chipset model. 

2. I was looking at the freebios instead freebios2. I notice it's a lot
different. How do I build the rom image from the freebios2 source? Is it
similar to freebios?

Thanks,
Gin 




From rminnich at lanl.gov  Wed Oct 27 21:30:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Wed Oct 27 21:30:01 2004
Subject: boot linux from an ide
In-Reply-To: <000001c4bc98$7b6935c0$8e04010a@nexcom.com.tw>
References: <000001c4bc98$7b6935c0$8e04010a@nexcom.com.tw>
Message-ID: <Pine.LNX.4.58.0410272051480.5895@linux.site>


On Thu, 28 Oct 2004, Gin wrote:

> Thanks everyone. I found the Config file for Tyan S2735.
> 1. why are the Config.lb files different under /target and /src for
> Tyan/S2735? Which one should I use? Also the one under /target doesn't
> specify the chipset model. 

to build the S2735

cd targets
./buildtarget tyan/s2735

cd tyan/s2735/s2735
make

ron


From bari at onelabs.com  Wed Oct 27 21:34:01 2004
From: bari at onelabs.com (Bari Ari)
Date: Wed Oct 27 21:34:01 2004
Subject: Epia-N
In-Reply-To: <Pine.GSO.4.60.0410272233000.5385@nerd>
References: <41805791.8000008@onelabs.com> <Pine.GSO.4.60.0410272233000.5385@nerd>
Message-ID: <41806035.4070000@onelabs.com>

Marc Nicholas wrote:

> Does this mean you have one? I didn't know they were in the wild yet...

We are designing a consumer product that uses the same chipset.

-Bari


From YhLu at tyan.com  Wed Oct 27 21:45:00 2004
From: YhLu at tyan.com (YhLu)
Date: Wed Oct 27 21:45:00 2004
Subject: S2885 -- spare 4s in rebooting
Message-ID: <3174569B9743D511922F00A0C94314230665B777@TYANWEB>

Under normal mode, using jmp __cpu_reset, the stage is rather faster.

Copying LinuxBIOS to ram. <------- here take sometime ---skipped by
Soft2_reset
Jumping to LinuxBIOS. <------------------ skipped by Soft2_reset
LinuxBIOS-1.1.72.0_Fallback Tue Oct 26 18:48:45 PDT 2004 rebooting...----->



-----Original Message-----
From: YhLu 
Sent: Wednesday, October 27, 2004 11:00 AM
To: ebiederman at lnxi.com
Cc: Ronald G. Minnich; linuxbios at clustermatic.org
Subject: RE: S2885 -- spare 4s in rebooting

With cpu_reset

~ # reboot
INIT: Sending processes the TERM signal
INIT: Cmos information update
Getting settings
Stop port mapper
Shutdown syslog daemon
Shutdown klogd daemon
Sending all processes the TERM signal...
Sending all processes the KILL signal..
Please, stand by while rebooting the system ...
Restarting system.
Copying LinuxBIOS to ram. <------- here take sometime ---skipped by
Soft2_reset
Jumping to LinuxBIOS. <------------------ skipped by Soft2_reset
LinuxBIOS-1.1.72.0_Fallback Tue Oct 26 18:48:45 PDT 2004 rebooting...----->
skipped by soft2_reset

LinuxBIOS-1.1.72.0_Fallback Tue Oct 26 18:48:45 PDT 2004 starting...
Ram1.00
Ram1.01
Ram2.00
Ram2.01
Ram3
Initializing memory:  done
Initializing memory:  done
Clearing initial memory region:  done
Ram4
Copying LinuxBIOS to ram.
Jumping to LinuxBIOS.
LinuxBIOS-1.1.72.0_Fallback Tue Oct 26 18:48:45 PDT 2004 booting...
Finding PCI configuration type.
PCI: Using configuration type 1

-----Original Message-----
From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
Sent: Wednesday, October 27, 2004 10:16 AM
To: YhLu
Cc: Ronald G. Minnich; linuxbios at clustermatic.org
Subject: Re: S2885 -- spare 4s in rebooting

YhLu <YhLu at tyan.com> writes:

> Spare 4s for rebooting
>  
> I add some comments in s2885/auto.c.
>  
> In auto.c call soft2_reset directly instead of jmp to __cpu_reset

Hmm. That does seem to have some merit.  Where are you seeing the code
run slowly?  In particular I am wondering if this is an mtrr setup
problem or something else you are avoiding.

Eric
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From bchafy at ccs.neu.edu  Wed Oct 27 21:49:01 2004
From: bchafy at ccs.neu.edu (Bryan E. Chafy)
Date: Wed Oct 27 21:49:01 2004
Subject: low level shell
Message-ID: <20041028031054.GA14447@denali.ccs.neu.edu>


Apologies if this is a redundant contribution.

None of my pc motherboards have JTAG or HW debug capabilites.
And constantly (hot)flashing, changing ram init code, then (hot)flashing again 
gets old really fast.
Looking around, I couldnt find any debug tools that would operate at
basically the reset vector level.  I thought this was the goal of openbios,
but I got lost in all the jibberish about 4th and firmware standards.

So I set out to make a small interactive low level shell with the goal
of providing at least some tools to aid in board/memory bringup and debugging.
This was nontrivial given the system limitations, however I got a few
things to work.

Attached is llshell.inc (for linuxbios1, Ive not tried any of the new
stuff yet) and llshell_linux (for running/testing inside of linux).
It's written entirely in asm and can run in a memoryless early stage
(say at the beginning of ram_set_registers or points afterword).

List of commands:

beep                    -- pc speaker beep
rst (or RST)            -- reset
out(b,w,l) <val> <port> -- raw out val at port
in(b,w,l)  <port>       -- show raw port value
jmp  <address>          -- jmp to address (llshell addr is in eax)
call <address>          -- funcion call (assumes a working stack)
cli                     -- clear interrupts
sti                     -- enable interrupts
push <value>            -- push value onto stack
pop                     -- pop from stack and display
wm(b,w,l) <addr> <val>  -- write mem
dm   <addr> <lines>     -- dump mem
mcp  <src> <dst> <size> -- mem copy
mpat <pat> <dst> <size> -- mem pattern
memt <begin> <end>      -- memory test
pcir(b,w,l) <loc>       -- pci read config
pciw(b,w,l) <loc> <val> -- pci write config
dl   <addr> <size>      -- memory download (display xor cheksum at completion)
cram <addr> <size>      -- enable cache to be ram (experimental)
baud <val>              -- change baudrate (not yet implemented)
exit                    -- exit shell
All values in hex (0x prefixing ok)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: llshell.tar.gz
Type: application/x-tar-gz
Size: 16947 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20041027/2a59c312/attachment.bin>

From jbors at mail.ru  Wed Oct 27 22:17:00 2004
From: jbors at mail.ru (Dmitry Borisov)
Date: Wed Oct 27 22:17:00 2004
Subject: Epia-N
References: <41805791.8000008@onelabs.com> <Pine.GSO.4.60.0410272233000.5385@nerd> <41806035.4070000@onelabs.com>
Message-ID: <027001c4bc9f$b8368820$0200a8c0@amr.corp.intel.com>

From: "Bari Ari" 
Cc: <linuxbios at clustermatic.org>
Sent: Wednesday, October 27, 2004 7:57 PM
Subject: Re: Epia-N


> Marc Nicholas wrote:
> 
> > Does this mean you have one? I didn't know they were in the wild yet...
> 
> We are designing a consumer product that uses the same chipset.
> 
> -Bari

Sooo ?
Do you have specs( mostly cn400 ) ?
Dmitry/


From ebiederman at lnxi.com  Wed Oct 27 23:51:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed Oct 27 23:51:01 2004
Subject: low level shell
In-Reply-To: <20041028031054.GA14447@denali.ccs.neu.edu>
References: <20041028031054.GA14447@denali.ccs.neu.edu>
Message-ID: <m3vfcvjui5.fsf@maxwell.lnxi.com>

"Bryan E. Chafy" <bchafy at ccs.neu.edu> writes:

> Apologies if this is a redundant contribution.
> 
> None of my pc motherboards have JTAG or HW debug capabilites.
> And constantly (hot)flashing, changing ram init code, then (hot)flashing again 
> gets old really fast.

:)

romcc helps by reducing typos. But this addresses the problem
of understanding what is wrong :)

The other trick that helps is to hard code the memory configuration
and put that in the fallback image.  And then use a second copy of linuxbios
to develop new code.  At least that way you don't need to swap the rom chip.

> Looking around, I couldnt find any debug tools that would operate at
> basically the reset vector level.  I thought this was the goal of openbios,
> but I got lost in all the jibberish about 4th and firmware standards.

I think the people who described it as such could not get that low level :)
Forth certainly needs memory to work.

> So I set out to make a small interactive low level shell with the goal
> of providing at least some tools to aid in board/memory bringup and debugging.
> This was nontrivial given the system limitations, however I got a few
> things to work.

It looks nice.  And inspires some more ideas.
 
> Attached is llshell.inc (for linuxbios1, Ive not tried any of the new
> stuff yet) and llshell_linux (for running/testing inside of linux).
> It's written entirely in asm and can run in a memoryless early stage
> (say at the beginning of ram_set_registers or points afterword).

Now if only we can figure out a way to successfully trap exceptions
without memory working....

Eric


From sxpert at esitcom.org  Thu Oct 28 00:25:01 2004
From: sxpert at esitcom.org (Amaury Jacquot)
Date: Thu Oct 28 00:25:01 2004
Subject: Can some EPIA-M person fix this?
In-Reply-To: <Pine.GSO.4.60.0410271914170.5213@nerd>
References: <Pine.LNX.4.58.0410260739320.29083@linux.site>  <000001c4bbce$55c9eb90$8e04010a@nexcom.com.tw>  <20041027141917.GA4306@openbios.org>  <417FF0AE.3080103@bitworks.com> <1098917923.9293.1.camel@localhost> <Pine.GSO.4.60.0410271914170.5213@nerd>
Message-ID: <418087F2.2010006@esitcom.org>

Marc Nicholas wrote:
> 
> 
> On Thu, 28 Oct 2004, Amaury Jacquot wrote:
> 
>> I am to make one of those for myself and would be glad to have something
>> that'd work for sure (using an MII 12000 here)
>> currently, booting my gentoo is about 2 minutes...
> 
> 
> I'm about to try the same wsith an MII 10000.... :D
> 
> -marc

ok, I'll wait ;D


From stepan at openbios.org  Thu Oct 28 01:51:01 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Thu Oct 28 01:51:01 2004
Subject: Which is used the 855pm or the i855pm code?
In-Reply-To: <m3k6tcrs4v.fsf@maxwell.lnxi.com>
References: <3174569B9743D511922F00A0C94314230665B697@TYANWEB> <Pine.LNX.4.58.0410270847140.2564@linux.site> <m3k6tcrs4v.fsf@maxwell.lnxi.com>
Message-ID: <20041028071314.GA4650@openbios.org>

* Eric W. Biederman <ebiederman at lnxi.com> [041027 19:24]:
> Speaking of config.g what would it take to not allow uses in anything
> except src/mainboard/xxx/Options.lb.  

> Having one place were we simply declare which variables we are going
> to be using for the entire board, (while still allowing them to be set
> elsewhere) seems sane.  That actually reflects the current state
> of the mainboard configuration right now.

Would anything speak against putting a "uses CC"
into all mainboard/xxx/Options.lb then? Some mechanism to specify the
compiler will be needed for cross compiling LinuxBIOS. 

Stefan




From sxpert at esitcom.org  Thu Oct 28 04:09:01 2004
From: sxpert at esitcom.org (Amaury Jacquot)
Date: Thu Oct 28 04:09:01 2004
Subject: VIA GPL Violation ?
Message-ID: <1098955883.1304.6.camel@raph.imag.fr>

hi guys
was looking through via arena, and found this file :

http://www.viaarena.com/guides/WinCE/fastboot%20v2.03.zip

problem is, running

strings */BIOS_*.BIN | grep inux

gives 2 mentions of LinuxBios for each binary bios file, which makes the
whole thing suspect...

should via be hit with some GPL cluestick ?



From stepan at openbios.org  Thu Oct 28 06:29:01 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Thu Oct 28 06:29:01 2004
Subject: status information
Message-ID: <20041028115139.GA19778@openbios.org>

Hi,

the "reference build" arima hdama seems to be too big when being
compiled with gcc 3.3.1 or 3.3.3..

See attached log file.

Please, if anyone has time and test capabilities, have an eye on the non
working ports and try to submit fixes.


Stefan


-------------- next part --------------
Processing mainboard amd quartet (i386: ok)
  Creating config file... ok
  Creating builddir...ok
  Compiling image ..FAILED! Log excerpt:
In file included from /home/stepan/freebios2/src/mainboard/amd/quartet/auto.c:148:
/home/stepan/freebios2/src/northbridge/amd/amdk8/raminit.c:568:2: warning: #warning "FIXME implement a better test for opterons"
make[1]: *** [auto.E] Error 1
make[1]: Leaving directory `/home/stepan/freebios2/util/abuild/linuxbios-builds/amd_quartet/fallback'
make: *** [fallback-rom] Error 1

Processing mainboard amd serenade (i386: ok)
  Creating config file... ok
  Creating builddir...ok
  Compiling image ..FAILED! Log excerpt:
In file included from /home/stepan/freebios2/src/mainboard/amd/serenade/auto.c:121:
/home/stepan/freebios2/src/northbridge/amd/amdk8/raminit.c:568:2: warning: #warning "FIXME implement a better test for opterons"
make[1]: *** [auto.E] Error 1
make[1]: Leaving directory `/home/stepan/freebios2/util/abuild/linuxbios-builds/amd_serenade/fallback'
make: *** [fallback-rom] Error 1

Processing mainboard amd solo (i386: ok)
  Creating config file... ok
  Creating builddir...ok
  Compiling image ..ok.

Processing mainboard arima hdama (i386: ok)
  Creating config file... ok
  Creating builddir...ok
  Compiling image ..FAILED! Log excerpt:
/usr/lib/gcc-lib/i586-suse-linux/3.3.3/../../../../i586-suse-linux/bin/ld: section .id [00000000ffffffd8 -> 00000000ffffffef] overlaps section .payload [00000000ffff90a0 -> 0000000100000080]
collect2: ld returned 1 exit status
make[1]: *** [linuxbios] Error 1
make[1]: Leaving directory `/home/stepan/freebios2/util/abuild/linuxbios-builds/arima_hdama/fallback'
make: *** [fallback-rom] Error 1

Processing mainboard densitron dpx114 (i386: ok)
  Creating config file... ok
  Creating builddir...FAILED! Log excerpt:
Configuring TARGET densitron_dpx114
Will place Makefile, crt0.S, etc. in densitron_dpx114
===> ERROR: Could not open file "/home/stepan/freebios2/src/mainboard/densitron/dpx114/Options.lb"
Config-densitron_dpx114.lb:0

Processing mainboard digitallogic adl855pc (i386: ok)
  Creating config file... ok
  Creating builddir...FAILED! Log excerpt:
Configuring TARGET digitallogic_adl855pc
Will place Makefile, crt0.S, etc. in digitallogic_adl855pc
===> ERROR: Could not open file "/home/stepan/freebios2/src/mainboard/digitallogic/adl855pc/Options.lb"
Config-digitallogic_adl855pc.lb:0

Processing mainboard embeddedplanet ep405pc (ppc: skipped, we're i386)

Processing mainboard emulation qemu-i386 (i386: ok)
  Creating config file... ok
  Creating builddir...FAILED! Log excerpt:
List of nearby tokens: 
  (@0)  EOF  =  ''
===> ERROR: Could not parse file
Config-emulation_qemu-i386.lb:0
src/mainboard/emulation/qemu-i386/Options.lb:0

Processing mainboard ibm e325 (i386: ok)
  Creating config file... ok
  Creating builddir...ok
  Compiling image ..FAILED! Log excerpt:
make[1]: Entering directory `/home/stepan/freebios2/util/abuild/linuxbios-builds/ibm_e325/fallback'
cp /home/stepan/freebios2/src/arch/i386/init/crt0.S.lb crt0.S
make[1]: *** No rule to make target `/home/stepan/freebios2/src/cpu/i386/entry16.inc', needed by `crt0.s'.  Stop.
make[1]: Leaving directory `/home/stepan/freebios2/util/abuild/linuxbios-builds/ibm_e325/fallback'
make: *** [fallback-rom] Error 1

Processing mainboard Iwill DK8S2 (i386: ok)
  Creating config file... ok
  Creating builddir...FAILED! Log excerpt:
Configuring TARGET Iwill_DK8S2
Will place Makefile, crt0.S, etc. in Iwill_DK8S2
===> ERROR: Could not open file "/home/stepan/freebios2/src/mainboard/Iwill/DK8S2/Options.lb"
Config-Iwill_DK8S2.lb:0

Processing mainboard Iwill DK8X (i386: ok)
  Creating config file... ok
  Creating builddir...FAILED! Log excerpt:
Configuring TARGET Iwill_DK8X
Will place Makefile, crt0.S, etc. in Iwill_DK8X
===> ERROR: Could not open file "/home/stepan/freebios2/src/mainboard/Iwill/DK8X/Options.lb"
Config-Iwill_DK8X.lb:0

Processing mainboard motorola sandpoint (ppc: skipped, we're i386)

Processing mainboard newisys khepri (i386: ok)
  Creating config file... ok
  Creating builddir...ok
  Compiling image ..FAILED! Log excerpt:
make[1]: Entering directory `/home/stepan/freebios2/util/abuild/linuxbios-builds/newisys_khepri/fallback'
cp /home/stepan/freebios2/src/arch/i386/init/crt0.S.lb crt0.S
make[1]: *** No rule to make target `/home/stepan/freebios2/src/cpu/i386/entry16.inc', needed by `crt0.s'.  Stop.
make[1]: Leaving directory `/home/stepan/freebios2/util/abuild/linuxbios-builds/newisys_khepri/fallback'
make: *** [fallback-rom] Error 1

Processing mainboard technologic ts5300 (i386: ok)
  Creating config file... ok
  Creating builddir...FAILED! Log excerpt:
Configuring TARGET technologic_ts5300
Will place Makefile, crt0.S, etc. in technologic_ts5300
===> ERROR: Could not open file "/home/stepan/freebios2/src/mainboard/technologic/ts5300/Options.lb"
Config-technologic_ts5300.lb:0

Processing mainboard totalimpact briq (ppc: skipped, we're i386)

Processing mainboard tyan s2735 (i386: ok)
  Creating config file... ok
  Creating builddir...ok
  Compiling image ..ok.

Processing mainboard tyan s2850 (i386: ok)
  Creating config file... ok
  Creating builddir...ok
  Compiling image ..ok.

Processing mainboard tyan s2875 (i386: ok)
  Creating config file... ok
  Creating builddir...ok
  Compiling image ..ok.

Processing mainboard tyan s2880 (i386: ok)
  Creating config file... ok
  Creating builddir...ok
  Compiling image ..ok.

Processing mainboard tyan s2881 (i386: ok)
  Creating config file... ok
  Creating builddir...ok
  Compiling image ..ok.

Processing mainboard tyan s2882 (i386: ok)
  Creating config file... ok
  Creating builddir...ok
  Compiling image ..ok.

Processing mainboard tyan s2885 (i386: ok)
  Creating config file... ok
  Creating builddir...ok
  Compiling image ..FAILED! Log excerpt:
In file included from /home/stepan/freebios2/src/mainboard/tyan/s2885/auto.c:149:
/home/stepan/freebios2/src/northbridge/amd/amdk8/raminit.c:568:2: warning: #warning "FIXME implement a better test for opterons"
make[1]: *** [auto.E] Error 1
make[1]: Leaving directory `/home/stepan/freebios2/util/abuild/linuxbios-builds/tyan_s2885/fallback'
make: *** [fallback-rom] Error 1

Processing mainboard tyan s4880 (i386: ok)
  Creating config file... ok
  Creating builddir...ok
  Compiling image ..ok.

Processing mainboard tyan s4882 (i386: ok)
  Creating config file... ok
  Creating builddir...ok
  Compiling image ..ok.

Processing mainboard via epia (i386: ok)
  Creating config file... ok
  Creating builddir...ok
  Compiling image ..FAILED! Log excerpt:
gcc -x assembler-with-cpp -DASSEMBLY -E -I/home/stepan/freebios2/src -D__ROMCC__=0 -D__ROMCC_MINOR__=64 -I/home/stepan/freebios2/src/include -I/home/stepan/freebios2/src/arch/i386/include -I/usr/lib/gcc-lib/i586-suse-linux/3.3.3/include -DARCH='i386' -DCROSS_COMPILE -DCC='gcc' -DHOSTCC='gcc' -DOBJCOPY='objcopy' -DLINUXBIOS_VERSION='"1.1.7"' -DLINUXBIOS_BUILD='"Wed Oct 27 23:23:11 CEST 2004"' -DLINUXBIOS_COMPILE_TIME='"23:23:11"' -DLINUXBIOS_COMPILE_BY='"stepan"' -DLINUXBIOS_COMPILE_HOST='"apophis"' -DLINUXBIOS_COMPILE_DOMAIN='"openbios.org"' -DLINUXBIOS_COMPILER='"gcc version 3.3.3 (SuSE Linux)"' -DLINUXBIOS_LINKER='"GNU ld version 2.15.90.0.1.1 20040303 (SuSE Linux)"' -DLINUXBIOS_ASSEMBLER='"GNU assembler version 2.15.90.0.1.1 (i586-suse-linux) using BFD version 2.15.90.0.1.1 20040303 (SuSE Linux)"' -DHAVE_FALLBACK_BOOT='1' -DROM_IMAGE_SIZE='0x10000' -DPAYLOAD_SIZE='0x0' -D_ROMBASE='0xffff0000' -D_RESET='0xffff0000' -D_EXCEPTION_VECTORS='0xffff0100' -DSTACK_SIZE='0x2000' -DHEAP_SIZE='0x4000' -D_RAMBASE='0x4000' -DCONFIG_COMPRESS='1' -DCONFIG_UNCOMPRESSED='0' -DCONFIG_LB_MEM_TOPK='1024' -DHAVE_OPTION_TABLE='1' -DUSE_OPTION_TABLE='0' -DLB_CKS_RANGE_START='49' -DLB_CKS_RANGE_END='125' -DLB_CKS_LOC='126' -DCRT0='/home/stepan/freebios2/src/arch/i386/init/crt0.S.lb' -DDEBUG='1' -DCONFIG_CONSOLE_VGA='0' -DCONFIG_CONSOLE_BTEXT='0' -DCONFIG_CONSOLE_LOGBUF='0' -DCONFIG_CONSOLE_SROM='0' -DCONFIG_CONSOLE_SERIAL8250='0' -DDEFAULT_CONSOLE_LOGLEVEL='7' -DMAXIMUM_CONSOLE_LOGLEVEL='8' -DCONFIG_SERIAL_POST='0' -DTTYS0_BASE='0x3f8' -DTTYS0_BAUD='115200' -DTTYS0_LCS='0x3' -DMAINBOARD='/home/stepan/freebios2/src/mainboard/via/epia' -DMAINBOARD_PART_NUMBER='"epia"' -DMAINBOARD_VENDOR='"via"' -DMAINBOARD_PCI_SUBSYSTEM_VENDOR_ID='0' -DMAINBOARD_PCI_SUBSYSTEM_DEVICE_ID='0x0' -DCONFIG_SMP='0' -DCONFIG_MAX_CPUS='1' -DCONFIG_LOGICAL_CPUS='0' -DCONFIG_IDE_STREAM='0' -DCONFIG_ROM_STREAM='1' -DCONFIG_ROM_STREAM_START='0xffff0000' -DCONFIG_FS_STREAM='0' -DCONFIG_FS_EXT2='0' -DCONFIG_FS_ISO9660='0' -DCONFIG_FS_FAT='0' -DAUTOBOOT_DELAY='2' -DAUTOBOOT_CMDLINE='"hdc1:/vmlinuz root=/dev/hdc3 console=tty0 console=ttyS0,115200"' -DCONFIG_IDE='0' -DIDE_BOOT_DRIVE='0' -DIDE_OFFSET='0' -DHAVE_INIT_TIMER='0' -DHARD_RESET_BUS='1' -DHARD_RESET_DEVICE='5' -DHARD_RESET_FUNCTION='0' -DMAX_REBOOT_CNT='3' -DFAKE_SPDROM='0' -DHAVE_ACPI_TABLES='0' -DHAVE_MP_TABLE='0' -DHAVE_PIRQ_TABLE='1' -DUSE_FALLBACK_IMAGE='1' -DHAVE_HARD_RESET='1' -DIRQ_SLOT_COUNT='5' -DLINUXBIOS_EXTRA_VERSION='".0-fallback"' -DFALLBACK_SIZE='0x10000' -DROM_SIZE='0x40000' -DROM_SECTION_SIZE='0x10000' -DROM_SECTION_OFFSET='0x30000' -DXIP_ROM_SIZE='0x10000' -DXIP_ROM_BASE='0xffff0000' -DCONFIG_USE_INIT='0' -DCONFIG_LEGACY_VGABIOS='0' /home/stepan/freebios2/src/mainboard/via/epia/failover.c > ./failover.E
/home/stepan/freebios2/src/mainboard/via/epia/failover.c:8:29: cpu/p6/boot_cpu.c: No such file or directory
make[1]: *** [failover.E] Error 1
make[1]: Leaving directory `/home/stepan/freebios2/util/abuild/linuxbios-builds/via_epia/fallback'
make: *** [fallback-rom] Error 1

Processing mainboard via epia-m (i386: ok)
  Creating config file... ok
  Creating builddir...FAILED! Log excerpt:
Configuring TARGET via_epia-m
Will place Makefile, crt0.S, etc. in via_epia-m
===> ERROR: Could not open file "/home/stepan/freebios2/src/mainboard/via/epia-m/Options.lb"
Config-via_epia-m.lb:0


From ebiederman at lnxi.com  Thu Oct 28 06:37:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Oct 28 06:37:01 2004
Subject: VIA GPL Violation ?
In-Reply-To: <1098955883.1304.6.camel@raph.imag.fr>
References: <1098955883.1304.6.camel@raph.imag.fr>
Message-ID: <m38y9rcaur.fsf@maxwell.lnxi.com>

Amaury Jacquot <sxpert at esitcom.org> writes:

> hi guys
> was looking through via arena, and found this file :
> 
> http://www.viaarena.com/guides/WinCE/fastboot%20v2.03.zip
> 
> problem is, running
> 
> strings */BIOS_*.BIN | grep inux
> 
> gives 2 mentions of LinuxBios for each binary bios file, which makes the
> whole thing suspect...
> 
> should via be hit with some GPL cluestick ?

Have you asked them for the code?

Eric


From ebiederman at lnxi.com  Thu Oct 28 06:41:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Oct 28 06:41:00 2004
Subject: status information
In-Reply-To: <20041028115139.GA19778@openbios.org>
References: <20041028115139.GA19778@openbios.org>
Message-ID: <m3acu79hie.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at openbios.org> writes:

> Hi,
> 
> the "reference build" arima hdama seems to be too big when being
> compiled with gcc 3.3.1 or 3.3.3..

So gcc 3.4 does produce smaller code. :)

I'm pushing things pretty close so I will take a look and see if I can
get some more breathing room.

Eric


From ebiederman at lnxi.com  Thu Oct 28 07:07:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Oct 28 07:07:01 2004
Subject: status information
In-Reply-To: <20041028115139.GA19778@openbios.org>
References: <20041028115139.GA19778@openbios.org>
Message-ID: <m3654v9gbn.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at openbios.org> writes:

> Hi,


> the "reference build" arima hdama seems to be too big when being
> compiled with gcc 3.3.1 or 3.3.3..

I will (hopefully) commit later today, but I have found one general
technique that will cut down the code size but a small amount.
In the chip_operations struct we have a name for debugging.
Since we are no longer printing that name there is no point in
keeping it.

Eric


From sxpert at esitcom.org  Thu Oct 28 07:10:01 2004
From: sxpert at esitcom.org (Amaury Jacquot)
Date: Thu Oct 28 07:10:01 2004
Subject: VIA GPL Violation ?
In-Reply-To: <m38y9rcaur.fsf@maxwell.lnxi.com>
References: <1098955883.1304.6.camel@raph.imag.fr>
	 <m38y9rcaur.fsf@maxwell.lnxi.com>
Message-ID: <1098966645.1304.9.camel@raph.imag.fr>

On Thu, 2004-10-28 at 05:59 -0600, Eric W. Biederman wrote:
> Amaury Jacquot <sxpert at esitcom.org> writes:
> 
> > hi guys
> > was looking through via arena, and found this file :
> > 
> > http://www.viaarena.com/guides/WinCE/fastboot%20v2.03.zip
> > 
> > problem is, running
> > 
> > strings */BIOS_*.BIN | grep inux
> > 
> > gives 2 mentions of LinuxBios for each binary bios file, which makes the
> > whole thing suspect...
> > 
> > should via be hit with some GPL cluestick ?
> 
> Have you asked them for the code?

no, I haven't... shouldn't it be readily available from the download
page at http://www.viaarena.com/default.aspx?
PageID=22&DSCat=41&DCatType=3 where the files are pointed from ?

> Eric
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios



From ebiederman at lnxi.com  Thu Oct 28 07:21:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Oct 28 07:21:01 2004
Subject: VIA GPL Violation ?
In-Reply-To: <1098966645.1304.9.camel@raph.imag.fr>
References: <1098955883.1304.6.camel@raph.imag.fr>
	<m38y9rcaur.fsf@maxwell.lnxi.com>
	<1098966645.1304.9.camel@raph.imag.fr>
Message-ID: <m3oein2etz.fsf@maxwell.lnxi.com>

Amaury Jacquot <sxpert at esitcom.org> writes:

> On Thu, 2004-10-28 at 05:59 -0600, Eric W. Biederman wrote:
> > Amaury Jacquot <sxpert at esitcom.org> writes:
> > 
> > > hi guys
> > > was looking through via arena, and found this file :
> > > 
> > > http://www.viaarena.com/guides/WinCE/fastboot%20v2.03.zip
> > > 
> > > problem is, running
> > > 
> > > strings */BIOS_*.BIN | grep inux
> > > 
> > > gives 2 mentions of LinuxBios for each binary bios file, which makes the
> > > whole thing suspect...
> > > 
> > > should via be hit with some GPL cluestick ?
> > 
> > Have you asked them for the code?
> 
> no, I haven't... shouldn't it be readily available from the download
> page at http://www.viaarena.com/default.aspx?
> PageID=22&DSCat=41&DCatType=3 where the files are pointed from ?

The GPL is not quite that demanding.  But it comes close.

Anyway it is best to start with giving companies the benefit
of the doubt.  It may be they just forgot, or you did not
see it.

If they actually refuse the code that is a separate issue entirely.


Eric


From marc at geekythings.com  Thu Oct 28 07:47:01 2004
From: marc at geekythings.com (Marc Nicholas)
Date: Thu Oct 28 07:47:01 2004
Subject: VIA GPL Violation ?
In-Reply-To: <1098955883.1304.6.camel@raph.imag.fr>
References: <1098955883.1304.6.camel@raph.imag.fr>
Message-ID: <Pine.GSO.4.60.0410280902500.6091@nerd>

Fastboot is based on LinuxBIOS....that's pretty common knowledge, no?

On Thu, 28 Oct 2004, Amaury Jacquot wrote:

> hi guys
> was looking through via arena, and found this file :
>
> http://www.viaarena.com/guides/WinCE/fastboot%20v2.03.zip
>
> problem is, running
>
> strings */BIOS_*.BIN | grep inux
>
> gives 2 mentions of LinuxBios for each binary bios file, which makes the
> whole thing suspect...
>
> should via be hit with some GPL cluestick ?
>
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>


From rminnich at lanl.gov  Thu Oct 28 08:47:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Thu Oct 28 08:47:01 2004
Subject: low level shell
In-Reply-To: <m3vfcvjui5.fsf@maxwell.lnxi.com>
References: <20041028031054.GA14447@denali.ccs.neu.edu> <m3vfcvjui5.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.58.0410280808550.7845@linux.site>


On Wed, 27 Oct 2004, Eric W. Biederman wrote:

> The other trick that helps is to hard code the memory configuration and
> put that in the fallback image.  And then use a second copy of linuxbios
> to develop new code.  At least that way you don't need to swap the rom
> chip.

some times that works, sometimes not. On the i855gm, hardcoding did not 
seem to work -- there's something dynamic you have to do, evidently, and 
just setting in the registers was not it.


ron


From rminnich at lanl.gov  Thu Oct 28 08:50:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Thu Oct 28 08:50:01 2004
Subject: Which is used the 855pm or the i855pm code?
In-Reply-To: <20041028071314.GA4650@openbios.org>
References: <3174569B9743D511922F00A0C94314230665B697@TYANWEB>
 <Pine.LNX.4.58.0410270847140.2564@linux.site> <m3k6tcrs4v.fsf@maxwell.lnxi.com>
 <20041028071314.GA4650@openbios.org>
Message-ID: <Pine.LNX.4.58.0410280810180.7845@linux.site>


On Thu, 28 Oct 2004, Stefan Reinauer wrote:

> Would anything speak against putting a "uses CC" into all
> mainboard/xxx/Options.lb then? Some mechanism to specify the compiler
> will be needed for cross compiling LinuxBIOS.

works for me!

ron


From rminnich at lanl.gov  Thu Oct 28 08:53:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Thu Oct 28 08:53:00 2004
Subject: VIA GPL Violation ?
In-Reply-To: <m3oein2etz.fsf@maxwell.lnxi.com>
References: <1098955883.1304.6.camel@raph.imag.fr> <m38y9rcaur.fsf@maxwell.lnxi.com>
 <1098966645.1304.9.camel@raph.imag.fr> <m3oein2etz.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.58.0410280814440.7845@linux.site>


On Thu, 28 Oct 2004, Eric W. Biederman wrote:

> The GPL is not quite that demanding.  But it comes close.

yes, you've got to 
a) buy the software from them or a product running the software
b) ask for the software

or so I understand.

ron


From ebiederman at lnxi.com  Thu Oct 28 09:01:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Oct 28 09:01:00 2004
Subject: low level shell
In-Reply-To: <Pine.LNX.4.58.0410280808550.7845@linux.site>
References: <20041028031054.GA14447@denali.ccs.neu.edu>
	<m3vfcvjui5.fsf@maxwell.lnxi.com>
	<Pine.LNX.4.58.0410280808550.7845@linux.site>
Message-ID: <m3vfcux6pz.fsf@maxwell.lnxi.com>

"Ronald G. Minnich" <rminnich at lanl.gov> writes:

> On Wed, 27 Oct 2004, Eric W. Biederman wrote:
> 
> > The other trick that helps is to hard code the memory configuration and
> > put that in the fallback image.  And then use a second copy of linuxbios
> > to develop new code.  At least that way you don't need to swap the rom
> > chip.
> 
> some times that works, sometimes not. On the i855gm, hardcoding did not 
> seem to work -- there's something dynamic you have to do, evidently, and 
> just setting in the registers was not it.

I guess what I meant was that you can hard code the values that
only change when you swap dimms.  This means you don't initially need
to look at SPD and all of that jazz when you first start bringing
your memory up.

Eric


From rminnich at lanl.gov  Thu Oct 28 09:04:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Thu Oct 28 09:04:01 2004
Subject: low level shell
In-Reply-To: <20041028031054.GA14447@denali.ccs.neu.edu>
References: <20041028031054.GA14447@denali.ccs.neu.edu>
Message-ID: <Pine.LNX.4.58.0410280825380.7845@linux.site>

I think this is a good example of something that goes in the extensions 
directory, I'll try to figure this out. It looks like a really handy tool.

thanks

ron



From arc at xiph.org  Thu Oct 28 09:55:01 2004
From: arc at xiph.org (Arc Riley)
Date: Thu Oct 28 09:55:01 2004
Subject: VIA GPL Violation ?
In-Reply-To: <1098955883.1304.6.camel@raph.imag.fr>
References: <1098955883.1304.6.camel@raph.imag.fr>
Message-ID: <20041028151812.GV15892@xiph.org>

On Thu, Oct 28, 2004 at 11:31:22AM +0200, Amaury Jacquot wrote:
> hi guys
> was looking through via arena, and found this file :
> 
> http://www.viaarena.com/guides/WinCE/fastboot%20v2.03.zip
> 
> problem is, running
> 
> strings */BIOS_*.BIN | grep inux
> 
> gives 2 mentions of LinuxBios for each binary bios file, which makes the
> whole thing suspect...
> 
> should via be hit with some GPL cluestick ?

Send them a registered letter via USPS mail requesting the source code, 
and specify the URL of the code, the source code in question, the 
license, and a specific request for their modified sourcecode under the 
terms of the license.  Make sure to give them a date for compliance.

Make sure you have a copy of the letter, and if they don't comply, I'm 
sure the happy lawyers down at the FSF would be happy to contact them.. 

Rule of thumb:  Do not make a public scene about this.  Handle this 
quietly until public exposure is a last resort; let the FSF handle it.  
If you make a public scene (ie, /. posting) VIA is much less likely to 
be amicable in the future, especially since we *WANT* them developing 
GPL code and being part of the community, not setting policies like 
"never touch GPLed code, it's a minefield".



From arc at xiph.org  Thu Oct 28 10:01:01 2004
From: arc at xiph.org (Arc Riley)
Date: Thu Oct 28 10:01:01 2004
Subject: VIA GPL Violation ?
In-Reply-To: <Pine.LNX.4.58.0410280814440.7845@linux.site>
References: <1098955883.1304.6.camel@raph.imag.fr> <m38y9rcaur.fsf@maxwell.lnxi.com> <1098966645.1304.9.camel@raph.imag.fr> <m3oein2etz.fsf@maxwell.lnxi.com> <Pine.LNX.4.58.0410280814440.7845@linux.site>
Message-ID: <20041028152201.GW15892@xiph.org>

On Thu, 28 Oct 2004, Eric W. Biederman wrote:
> 
> yes, you've got to 
> a) buy the software from them or a product running the software
> b) ask for the software
> 
> or so I understand.

Actually, no, all you have to do is aquire the software in binary form.  
If source is not included, then they must provide it through specific 
means outlined in the GPL whenever requested.

Wether it's sold or given gratis is of no consequence, as I've known..


From sckim2s at msn.com  Thu Oct 28 10:09:00 2004
From: sckim2s at msn.com (=?ks_c_5601-1987?B?6rmAIOyDgeyyoA==?=)
Date: Thu Oct 28 10:09:00 2004
Subject: loadoptions problem for buildtarget via/epia-m
Message-ID: <BAY4-F17uAyHsjCGvse00028763@hotmail.com>

I have some problem with buildtarget via/epia-m for freebios2.

My environment is: SUSE 9, Python 2.3

At the directory "/opt/bios/freebios2/targets",
the command "./buildtarget via/epia-m" makes the following error.
Anybody help me to solve the problem?

============= Error Message =======================
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
===================================================

_________________________________________________________________
?? ?? ?? ??? ??? ?? ? ????. MSN ??/??   
http://www.msn.co.kr/stock/  



From ollie at lanl.gov  Thu Oct 28 10:58:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu Oct 28 10:58:01 2004
Subject: status information
In-Reply-To: <m3654v9gbn.fsf@maxwell.lnxi.com>
References: <20041028115139.GA19778@openbios.org>
	 <m3654v9gbn.fsf@maxwell.lnxi.com>
Message-ID: <1098980402.12894.0.camel@exponential.lanl.gov>

On Thu, 2004-10-28 at 06:29, Eric W. Biederman wrote:
> Stefan Reinauer <stepan at openbios.org> writes:
> 
> > Hi,
> 
> 
> > the "reference build" arima hdama seems to be too big when being
> > compiled with gcc 3.3.1 or 3.3.3..
> 
> I will (hopefully) commit later today, but I have found one general
> technique that will cut down the code size but a small amount.
> In the chip_operations struct we have a name for debugging.
> Since we are no longer printing that name there is no point in
> keeping it.
> 


Why don't we just enlarge the size to, say, 128kB ??

Ollie

> Eric
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 



From ollie at lanl.gov  Thu Oct 28 11:04:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu Oct 28 11:04:00 2004
Subject: boot linux from an ide
In-Reply-To: <000001c4bc98$7b6935c0$8e04010a@nexcom.com.tw>
References: <000001c4bc98$7b6935c0$8e04010a@nexcom.com.tw>
Message-ID: <1098980769.12894.6.camel@exponential.lanl.gov>

On Wed, 2004-10-27 at 20:47, Gin wrote:
> Thanks everyone. I found the Config file for Tyan S2735.
> 1. why are the Config.lb files different under /target and /src for
> Tyan/S2735? Which one should I use? Also the one under /target doesn't
> specify the chipset model. 
> 

You should use the Config.lb in the target directory. The Config.lb in 
the src/mainboard is a general config file to the mainboard. You can
make your own specific change in the target/ Config.lb.
 
> 2. I was looking at the freebios instead freebios2. I notice it's a lot
> different. How do I build the rom image from the freebios2 source? Is it
> similar to freebios?
> 

Use freebios2 if it supports your mainboard. freebios is going to be 
obselete soon.

Ollie

> Thanks,
> Gin 
> 
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 



From ollie at lanl.gov  Thu Oct 28 11:09:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu Oct 28 11:09:00 2004
Subject: low level shell
In-Reply-To: <m3vfcux6pz.fsf@maxwell.lnxi.com>
References: <20041028031054.GA14447@denali.ccs.neu.edu>
	 <m3vfcvjui5.fsf@maxwell.lnxi.com>
	 <Pine.LNX.4.58.0410280808550.7845@linux.site>
	 <m3vfcux6pz.fsf@maxwell.lnxi.com>
Message-ID: <1098981105.12894.9.camel@exponential.lanl.gov>

On Thu, 2004-10-28 at 08:22, Eric W. Biederman wrote:
> "Ronald G. Minnich" <rminnich at lanl.gov> writes:
> 
> > On Wed, 27 Oct 2004, Eric W. Biederman wrote:
> > 
> > > The other trick that helps is to hard code the memory configuration and
> > > put that in the fallback image.  And then use a second copy of linuxbios
> > > to develop new code.  At least that way you don't need to swap the rom
> > > chip.
> > 
> > some times that works, sometimes not. On the i855gm, hardcoding did not 
> > seem to work -- there's something dynamic you have to do, evidently, and 
> > just setting in the registers was not it.
> 
> I guess what I meant was that you can hard code the values that
> only change when you swap dimms.  This means you don't initially need
> to look at SPD and all of that jazz when you first start bringing
> your memory up.
> 

I guess this is the most diffcult part. Once you know how to issue the
JEDEC command to the DRAM chip via the memory controller, you have no
problem to program the size info in the controller.

Ollie

> Eric
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 



From kfuchs at winternet.com  Thu Oct 28 11:50:00 2004
From: kfuchs at winternet.com (Ken Fuchs)
Date: Thu Oct 28 11:50:00 2004
Subject: VIA GPL Violation ? 
Message-ID: <200410281712.i9SHCK3R019144@tundra.winternet.com>

Arc Riley wrote:

>Actually, no, all you have to do is aquire the software in binary
>form.  If source is not included, then they must provide it through
>specific means outlined in the GPL whenever requested.

>Wether it's sold or given gratis is of no consequence, as I've known..

The above are sufficient, but not necessary conditions for getting the
modified source code under the GPL.  Refer to the version of the GPL
that LinuxBIOS is licensed under (Version 2, June 1991):

http://www.gnu.org/licenses/gpl.html

The code in question doesn't include source and the distributer of
this code is not a non-profit, so the following clause applies:

------

# b)  Accompany it with a written offer, valid for at least three
years, to give any third party, for a charge no more than your cost of
physically performing source distribution, a complete machine-readable
copy of the corresponding source code, to be distributed under the
terms of Sections 1 and 2 above on a medium customarily used for
software interchange; or,

------

Such an offer is not included in the zip file and it must be, if any
binary code in the zip file is generated from GPL licensed code, i.e.
LinuxBIOS.  Therefore, if any LinuxBIOS source or binary code is
compiled/linked to generate binaries in the zip file in question,
distribution of that zip file is a violation of the GPL.

The next step is proving that GPL code (LinuxBIOS) is actually being
incorporated.  Without that proof, there is no GPL violation.
Contacting the FSF for advise would be next best step.

I don't see any point in discussing this potential GPL violation in a
this public forum.  However, continued generic discussion of the GPL
and what it requires might be helpful.

Sincerely,

Ken Fuchs <kfuchs at winternet.com>


From rminnich at lanl.gov  Thu Oct 28 12:48:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Thu Oct 28 12:48:00 2004
Subject: status information
In-Reply-To: <m3654v9gbn.fsf@maxwell.lnxi.com>
References: <20041028115139.GA19778@openbios.org> <m3654v9gbn.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.58.0410280813530.7845@linux.site>


On Thu, 28 Oct 2004, Eric W. Biederman wrote:

> I will (hopefully) commit later today, but I have found one general
> technique that will cut down the code size but a small amount.
> In the chip_operations struct we have a name for debugging.
> Since we are no longer printing that name there is no point in
> keeping it.

hmm, this sounds like a lot of potential pain for a small gain. Can we 
talk about this a bit first. 

ron


From rminnich at lanl.gov  Thu Oct 28 12:55:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Thu Oct 28 12:55:01 2004
Subject: VIA GPL Violation ?
In-Reply-To: <1098955883.1304.6.camel@raph.imag.fr>
References: <1098955883.1304.6.camel@raph.imag.fr>
Message-ID: <Pine.LNX.4.58.0410280811280.7845@linux.site>


On Thu, 28 Oct 2004, Amaury Jacquot wrote:

> hi guys
> was looking through via arena, and found this file :
> 
> http://www.viaarena.com/guides/WinCE/fastboot%20v2.03.zip
> 
> problem is, running
> 
> strings */BIOS_*.BIN | grep inux
> 
> gives 2 mentions of LinuxBios for each binary bios file, which makes the
> whole thing suspect...
> 
> should via be hit with some GPL cluestick ?

if you're sure and have the time, sounds good. 

I have also asked Cray for the LinuxBIOS source for the XD1 and received 
no response as of yet. This is getting to be a problem.

ron


From ollie at lanl.gov  Thu Oct 28 13:38:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu Oct 28 13:38:01 2004
Subject: status information
In-Reply-To: <Pine.LNX.4.58.0410280813530.7845@linux.site>
References: <20041028115139.GA19778@openbios.org>
	 <m3654v9gbn.fsf@maxwell.lnxi.com>
	 <Pine.LNX.4.58.0410280813530.7845@linux.site>
Message-ID: <1098990045.12894.20.camel@exponential.lanl.gov>

On Thu, 2004-10-28 at 08:14, Ronald G. Minnich wrote:
> On Thu, 28 Oct 2004, Eric W. Biederman wrote:
> 
> > I will (hopefully) commit later today, but I have found one general
> > technique that will cut down the code size but a small amount.
> > In the chip_operations struct we have a name for debugging.
> > Since we are no longer printing that name there is no point in
> > keeping it.
> 
> hmm, this sounds like a lot of potential pain for a small gain. Can we 
> talk about this a bit first. 
> 

Some points I didn't make clear during the LNXI visit about the size 
problem are:

	1. Virtually no one is putting the kernel in the FLASH ROM,
	   people use CF instead. Every payload/bootloader we are
	   using can support that.
	2. The size of FLASH grows exponentially if there is no stupid
	   limitation such as address lines in DIP32 package. Currently
	   LinuxBIOS only grows linearly. 

So why can not we relax the 64kB limit of LinuxBIOS ? I do think 
removing the name of the device is a wrong direction.

ollie





From bari at onelabs.com  Thu Oct 28 13:45:01 2004
From: bari at onelabs.com (Bari Ari)
Date: Thu Oct 28 13:45:01 2004
Subject: VIA GPL Violation ?
In-Reply-To: <Pine.LNX.4.58.0410280811280.7845@linux.site>
References: <1098955883.1304.6.camel@raph.imag.fr> <Pine.LNX.4.58.0410280811280.7845@linux.site>
Message-ID: <418143C9.80306@onelabs.com>

Ronald G. Minnich wrote:

> 
> On Thu, 28 Oct 2004, Amaury Jacquot wrote:
> 
> 
>>hi guys
>>was looking through via arena, and found this file :
>>
>>http://www.viaarena.com/guides/WinCE/fastboot%20v2.03.zip
>>
>>problem is, running
>>
>>strings */BIOS_*.BIN | grep inux
>>
>>gives 2 mentions of LinuxBios for each binary bios file, which makes the
>>whole thing suspect...
>>
>>should via be hit with some GPL cluestick ?
> 
> 
> if you're sure and have the time, sounds good. 
> 
> I have also asked Cray for the LinuxBIOS source for the XD1 and received 
> no response as of yet. This is getting to be a problem.

This is not new for Via:

Via "violates" GNU GPL with Padlock
http://www.theinquirer.net/?article=15329

but they did comply after being informed
http://linuxdevices.com/news/NS4520757633.html

-Bari


From ollie at lanl.gov  Thu Oct 28 13:53:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu Oct 28 13:53:00 2004
Subject: VIA GPL Violation ?
In-Reply-To: <Pine.LNX.4.58.0410280811280.7845@linux.site>
References: <1098955883.1304.6.camel@raph.imag.fr>
	 <Pine.LNX.4.58.0410280811280.7845@linux.site>
Message-ID: <1098989595.12894.11.camel@exponential.lanl.gov>

On Thu, 2004-10-28 at 08:12, Ronald G. Minnich wrote:
> 
> I have also asked Cray for the LinuxBIOS source for the XD1 and received 
> no response as of yet. This is getting to be a problem.
> 

They use LinuxBIOS too ?

Ollie




From rminnich at lanl.gov  Thu Oct 28 14:04:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Thu Oct 28 14:04:01 2004
Subject: status information
In-Reply-To: <1098980402.12894.0.camel@exponential.lanl.gov>
References: <20041028115139.GA19778@openbios.org>  <m3654v9gbn.fsf@maxwell.lnxi.com>
 <1098980402.12894.0.camel@exponential.lanl.gov>
Message-ID: <Pine.LNX.4.58.0410281323440.7845@linux.site>


On Thu, 28 Oct 2004, Li-Ta Lo wrote:

> On Thu, 2004-10-28 at 06:29, Eric W. Biederman wrote:
> > Stefan Reinauer <stepan at openbios.org> writes:
> > 
> > > Hi,
> > 
> > 
> > > the "reference build" arima hdama seems to be too big when being
> > > compiled with gcc 3.3.1 or 3.3.3..
> > 
> > I will (hopefully) commit later today, but I have found one general
> > technique that will cut down the code size but a small amount.
> > In the chip_operations struct we have a name for debugging.
> > Since we are no longer printing that name there is no point in
> > keeping it.
> > 
> 
> 
> Why don't we just enlarge the size to, say, 128kB ??

YES!

Rather than remove debugging names, let's to ahead and move things around!
I've done this once and it worked. We need to fix the .lds for things. 

I have found the debugging names to be useful in the arium context, where 
i can browse memory and look for strings etc. We should be able to print 
these out at some points. 

So move the c_payload to 0xfffe0000 and you'll have tons of room. So why 
not do that? 

Please don't remove the debugging names, the gain is very small and I 
think that would be a mistake.

ron


From rminnich at lanl.gov  Thu Oct 28 14:08:27 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Thu Oct 28 14:08:27 2004
Subject: loadoptions problem for buildtarget via/epia-m
In-Reply-To: <BAY4-F17uAyHsjCGvse00028763@hotmail.com>
References: <BAY4-F17uAyHsjCGvse00028763@hotmail.com>
Message-ID: <Pine.LNX.4.58.0410281326360.7845@linux.site>

I'm very sorry, epia is still broken but is getting fixed.

ron



From rminnich at lanl.gov  Thu Oct 28 14:13:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Thu Oct 28 14:13:01 2004
Subject: VIA GPL Violation ?
In-Reply-To: <1098989595.12894.11.camel@exponential.lanl.gov>
References: <1098955883.1304.6.camel@raph.imag.fr>  <Pine.LNX.4.58.0410280811280.7845@linux.site>
 <1098989595.12894.11.camel@exponential.lanl.gov>
Message-ID: <Pine.LNX.4.58.0410281328000.7845@linux.site>


On Thu, 28 Oct 2004, Li-Ta Lo wrote:

> On Thu, 2004-10-28 at 08:12, Ronald G. Minnich wrote:
> > 
> > I have also asked Cray for the LinuxBIOS source for the XD1 and received 
> > no response as of yet. This is getting to be a problem.
> > 
> 
> They use LinuxBIOS too ?

so they tell me.

ron


From rsmith at bitworks.com  Thu Oct 28 14:17:12 2004
From: rsmith at bitworks.com (Richard Smith)
Date: Thu Oct 28 14:17:12 2004
Subject: status information
In-Reply-To: <1098990045.12894.20.camel@exponential.lanl.gov>
References: <20041028115139.GA19778@openbios.org>	 <m3654v9gbn.fsf@maxwell.lnxi.com>	 <Pine.LNX.4.58.0410280813530.7845@linux.site> <1098990045.12894.20.camel@exponential.lanl.gov>
Message-ID: <4181496D.5090301@bitworks.com>

Li-Ta Lo wrote:

> So why can not we relax the 64kB limit of LinuxBIOS ? I do think 
> removing the name of the device is a wrong direction.

Why is this there in the first place?

-- 
Richard A. Smith




From adilson at linuxembarcado.com.br  Thu Oct 28 14:32:00 2004
From: adilson at linuxembarcado.com.br (Adilson Oliveira)
Date: Thu Oct 28 14:32:00 2004
Subject: Starting with linuxbios
Message-ID: <41814E81.70403@linuxembarcado.com.br>

Hello guys.

I'm thinking about create (another one) Car-PC and I want to use 
linuxbios to improve the boot time.
Is there any place you can recomend I can read about the basics of this 
project?
I mean how it works, etc? Just to give me an outline before I start to 
dig into it?
BTW, I want to use miniITX boards as the Via EPIA.

Thanks.

Adilson.


From rminnich at lanl.gov  Thu Oct 28 14:49:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Thu Oct 28 14:49:00 2004
Subject: VIA GPL Violation ?
In-Reply-To: <20041028152201.GW15892@xiph.org>
References: <1098955883.1304.6.camel@raph.imag.fr> <m38y9rcaur.fsf@maxwell.lnxi.com>
 <1098966645.1304.9.camel@raph.imag.fr> <m3oein2etz.fsf@maxwell.lnxi.com>
 <Pine.LNX.4.58.0410280814440.7845@linux.site> <20041028152201.GW15892@xiph.org>
Message-ID: <Pine.LNX.4.58.0410281313100.7845@linux.site>


On Thu, 28 Oct 2004, Arc Riley wrote:

> Actually, no, all you have to do is aquire the software in binary form.  

yeah, that's what I was attempting to say. 

For example, we bought a Cray XD1 and asked for linuxbios source; no 
response yet.

ron


From nathanael at gnat.ca  Thu Oct 28 15:05:01 2004
From: nathanael at gnat.ca (Nathanael Noblet)
Date: Thu Oct 28 15:05:01 2004
Subject: Starting with linuxbios
In-Reply-To: <41814E81.70403@linuxembarcado.com.br>
References: <41814E81.70403@linuxembarcado.com.br>
Message-ID: <BAD357DA-291F-11D9-B3D4-0003931B4D6A@gnat.ca>

On Oct 28, 2004, at 12:54 PM, Adilson Oliveira wrote:

> Hello guys.
>
> I'm thinking about create (another one) Car-PC and I want to use 
> linuxbios to improve the boot time.
> Is there any place you can recomend I can read about the basics of 
> this project?
> I mean how it works, etc? Just to give me an outline before I start to 
> dig into it?
> BTW, I want to use miniITX boards as the Via EPIA.

The website is sorely out of date, and the source tree has just gone 
through a *major* overhaul. In that vein, the source for the epia 
version isn't functional (as I understand it right now). But will in a 
few weeks when it gets cleaned up. The website will be revamped when 
some of the volunteers (like myself) get to it. We've been really busy 
as well. I'm not nearly as knowledgeable in the arena here about the 
actual functioning of LinuxBIOS, but there are plenty here who are. I 
would suggest going through the mailing list archive as start. There 
was a great FAQ type submission a few months ago that helped me 
understand what was going on.

-- 
Nathanael D. Noblet
Gnat Solutions
204 - 131 Gorge Road E
Victoria, BC V9A 1L1

T/F 250.385.4613

http://www.gnat.ca/



From ollie at lanl.gov  Thu Oct 28 15:36:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu Oct 28 15:36:00 2004
Subject: status information
In-Reply-To: <Pine.LNX.4.58.0410281323440.7845@linux.site>
References: <20041028115139.GA19778@openbios.org>
	 <m3654v9gbn.fsf@maxwell.lnxi.com>
	 <1098980402.12894.0.camel@exponential.lanl.gov>
	 <Pine.LNX.4.58.0410281323440.7845@linux.site>
Message-ID: <1098997117.12894.29.camel@exponential.lanl.gov>

On Thu, 2004-10-28 at 13:25, Ronald G. Minnich wrote:
> > Why don't we just enlarge the size to, say, 128kB ??
> 
> YES!
> 
> Rather than remove debugging names, let's to ahead and move things around!
> I've done this once and it worked. We need to fix the .lds for things. 
> 

Last time I tried to do that it was not that simple. The .lds is a mix 
of "#include" and "#define" in the ldscript and depends on the config
too much.

Ollie


> I have found the debugging names to be useful in the arium context, where 
> i can browse memory and look for strings etc. We should be able to print 
> these out at some points. 
> 
> So move the c_payload to 0xfffe0000 and you'll have tons of room. So why 
> not do that? 
> 
> Please don't remove the debugging names, the gain is very small and I 
> think that would be a mistake.
> 
> ron
> 



From kfuchs at winternet.com  Thu Oct 28 15:41:01 2004
From: kfuchs at winternet.com (Ken Fuchs)
Date: Thu Oct 28 15:41:01 2004
Subject: Starting with linuxbios
Message-ID: <200410282101.i9SL1T19019700@tundra.winternet.com>

Adilson wrote:

>I'm thinking about create (another one) Car-PC and I want to use 
>linuxbios to improve the boot time.

>Is there any place you can recomend I can read about the basics of
>this project?

Although, AMD64 would be over-kill for a Car-PC, LinuxBIOS-AMD64.pdf
is probably the most up to date document on LinuxBIOS v2 (freebios2):

http://www.openbios.org/LinuxBIOS-AMD64.pdf

Sincerely,

Ken Fuchs <kfuchs at winternet.com>


From sxpert at esitcom.org  Thu Oct 28 15:56:01 2004
From: sxpert at esitcom.org (Amaury Jacquot)
Date: Thu Oct 28 15:56:01 2004
Subject: VIA GPL Violation ?
In-Reply-To: <418143C9.80306@onelabs.com>
References: <1098955883.1304.6.camel@raph.imag.fr> <Pine.LNX.4.58.0410280811280.7845@linux.site> <418143C9.80306@onelabs.com>
Message-ID: <41816225.7030501@esitcom.org>

Bari Ari wrote:

> This is not new for Via:
> 
> Via "violates" GNU GPL with Padlock
> http://www.theinquirer.net/?article=15329
> 
> but they did comply after being informed
> http://linuxdevices.com/news/NS4520757633.html

lemme guess ? they're like kids, have to be reminded every time ?

> 
> -Bari
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios



From YhLu at tyan.com  Thu Oct 28 16:05:01 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Oct 28 16:05:01 2004
Subject: Starting with linuxbios
Message-ID: <3174569B9743D511922F00A0C94314230665B7D2@TYANWEB>

What's the usage for the CAR-PC?

GPS navigation?

Regards

YH



-----Original Message-----
From: Nathanael Noblet [mailto:nathanael at gnat.ca] 
Sent: Thursday, October 28, 2004 1:27 PM
To: Adilson Oliveira
Cc: linuxbios at clustermatic.org
Subject: Re: Starting with linuxbios


On Oct 28, 2004, at 12:54 PM, Adilson Oliveira wrote:

> Hello guys.
>
> I'm thinking about create (another one) Car-PC and I want to use 
> linuxbios to improve the boot time.
> Is there any place you can recomend I can read about the basics of 
> this project?
> I mean how it works, etc? Just to give me an outline before I start to 
> dig into it?
> BTW, I want to use miniITX boards as the Via EPIA.

The website is sorely out of date, and the source tree has just gone 
through a *major* overhaul. In that vein, the source for the epia 
version isn't functional (as I understand it right now). But will in a 
few weeks when it gets cleaned up. The website will be revamped when 
some of the volunteers (like myself) get to it. We've been really busy 
as well. I'm not nearly as knowledgeable in the arena here about the 
actual functioning of LinuxBIOS, but there are plenty here who are. I 
would suggest going through the mailing list archive as start. There 
was a great FAQ type submission a few months ago that helped me 
understand what was going on.

-- 
Nathanael D. Noblet
Gnat Solutions
204 - 131 Gorge Road E
Victoria, BC V9A 1L1

T/F 250.385.4613

http://www.gnat.ca/

_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From kfuchs at winternet.com  Thu Oct 28 16:10:00 2004
From: kfuchs at winternet.com (Ken Fuchs)
Date: Thu Oct 28 16:10:00 2004
Subject: VIA GPL Violation ?
Message-ID: <200410282130.i9SLUUaM019837@tundra.winternet.com>

>On Thu, 28 Oct 2004, Arc Riley wrote:

>> Actually, no, all you have to do is acquire the software in binary
>> form.  

>yeah, that's what I was attempting to say. 

Actually, just asking for the software (binary or source) is enough.
They don't need to give it to _you_, if another third party has
already acquired the binary or source (containing GPL code).

Until the first public or _private_ release (binary or source) to a
third party, modifications to GPL code can be kept private, but once
any release of the code (binary or source) occurs, the full conditions
of the GPL must be met.

Sincerely,

Ken Fuchs <kfuchs at winternet.com>


From ollie at lanl.gov  Thu Oct 28 16:22:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu Oct 28 16:22:00 2004
Subject: status information
In-Reply-To: <4181496D.5090301@bitworks.com>
References: <20041028115139.GA19778@openbios.org>
	 <m3654v9gbn.fsf@maxwell.lnxi.com>
	 <Pine.LNX.4.58.0410280813530.7845@linux.site>
	 <1098990045.12894.20.camel@exponential.lanl.gov>
	 <4181496D.5090301@bitworks.com>
Message-ID: <1098996760.12894.23.camel@exponential.lanl.gov>

On Thu, 2004-10-28 at 13:33, Richard Smith wrote:
> Li-Ta Lo wrote:
> 
> > So why can not we relax the 64kB limit of LinuxBIOS ? I do think 
> > removing the name of the device is a wrong direction.
> 
> Why is this there in the first place?

Are you asking the 64KB limit? One reason is to prevent "bloating" in 
LinuxBIOS. The other reason is some chip (AMD8111?) can only access the 
top 64kB of flash after boot.

Ollie



From sxpert at esitcom.org  Thu Oct 28 16:30:03 2004
From: sxpert at esitcom.org (Amaury Jacquot)
Date: Thu Oct 28 16:30:03 2004
Subject: Starting with linuxbios
In-Reply-To: <3174569B9743D511922F00A0C94314230665B7D2@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B7D2@TYANWEB>
Message-ID: <4181694C.6060702@esitcom.org>

YhLu wrote:
> What's the usage for the CAR-PC?
> 
> GPS navigation?
> 
> Regards
> 
> YH
> 

interestingly enough, I have the same useage ( see http://www.navsys.org )
mebbe it's time for some dox to be written, a howto mebbe ?

> 
> -----Original Message-----
> From: Nathanael Noblet [mailto:nathanael at gnat.ca] 
> Sent: Thursday, October 28, 2004 1:27 PM
> To: Adilson Oliveira
> Cc: linuxbios at clustermatic.org
> Subject: Re: Starting with linuxbios
> 
> 
> On Oct 28, 2004, at 12:54 PM, Adilson Oliveira wrote:
> 
> 
>>Hello guys.
>>
>>I'm thinking about create (another one) Car-PC and I want to use 
>>linuxbios to improve the boot time.
>>Is there any place you can recomend I can read about the basics of 
>>this project?
>>I mean how it works, etc? Just to give me an outline before I start to 
>>dig into it?
>>BTW, I want to use miniITX boards as the Via EPIA.
> 
> 
> The website is sorely out of date, and the source tree has just gone 
> through a *major* overhaul. In that vein, the source for the epia 
> version isn't functional (as I understand it right now). But will in a 
> few weeks when it gets cleaned up. The website will be revamped when 
> some of the volunteers (like myself) get to it. We've been really busy 
> as well. I'm not nearly as knowledgeable in the arena here about the 
> actual functioning of LinuxBIOS, but there are plenty here who are. I 
> would suggest going through the mailing list archive as start. There 
> was a great FAQ type submission a few months ago that helped me 
> understand what was going on.
> 



From Stephen.Kimball at bench.com  Thu Oct 28 16:41:00 2004
From: Stephen.Kimball at bench.com (Stephen.Kimball at bench.com)
Date: Thu Oct 28 16:41:00 2004
Subject: LinuxBIOS debugging with an emulator
Message-ID: <9B124F08B3EFDA4F8813B05102DC719501A90276@nh-ex01.nh.bench.com>

> On Tue, 26 Oct 2004 Stephen.Kimball at bench.com wrote:
> > 
> > Can someone tell me what the starting sequence is with LinuxBIOS?
> > 
> > Reset jumps to crt0.s.  crt0.s calls auto.E.  auto.E is built using
> > romcc, so source-level debugging is not possible.  
>
> ah well :-)
>
> > The statement
> > locations can be found using the Lxxxx labels in linuxbios.map.
Then
> > hardwaremain is called. Hardwaremain is the first C function called.
>
> yep.
>
> > Crt0 and auto run out of FLASH.  Hardwaremain is the first function
> > called after LinuxBIOS is copied to RAM.
>
> sounds good so far.
>
> ron

It seems that LinuxBIOS copies itself to _RAMBASE, which is 0x4000.
Then it branches to 0x4000 into _start, which sets up the stack and
calls hardwaremain.  The address of hardwaremain from linuxbios_c.o is
wrong.  The address is not the Flash address and it's not the RAM
address.  Can someone explain how linuxbios_c.o is linked with RAM
addresses?  

Steve 


From ollie at lanl.gov  Thu Oct 28 17:02:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu Oct 28 17:02:00 2004
Subject: LinuxBIOS debugging with an emulator
In-Reply-To: <9B124F08B3EFDA4F8813B05102DC719501A90276@nh-ex01.nh.bench.com>
References: <9B124F08B3EFDA4F8813B05102DC719501A90276@nh-ex01.nh.bench.com>
Message-ID: <1099002233.12894.42.camel@exponential.lanl.gov>

On Thu, 2004-10-28 at 16:03, Stephen.Kimball at bench.com wrote:
> 
> It seems that LinuxBIOS copies itself to _RAMBASE, which is 0x4000.
> Then it branches to 0x4000 into _start, which sets up the stack and
> calls hardwaremain.  The address of hardwaremain from linuxbios_c.o is
> wrong.  The address is not the Flash address and it's not the RAM
> address.  Can someone explain how linuxbios_c.o is linked with RAM
> addresses?  
> 

What do you mean ? In the S2885 I built, the _RAMBASE is 0x4000 and 
hardwaremain is 0x5fe0 as you can get from the linuxbios_c.map. They
are both in RAM. If you use "objdump -drS linuxbios_c.o" you will
find the hardwaremain is at offset 0x1fe0 from the _RAMBASSE.

BTW, if you specify the -g option for gcc, you can use the -S option
in objdump to see the source code with the disassebmly (-d).

Ollie


> Steve 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 



From ollie at lanl.gov  Thu Oct 28 17:17:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu Oct 28 17:17:00 2004
Subject: loadoptions problem for buildtarget via/epia-m
In-Reply-To: <Pine.LNX.4.58.0410281326360.7845@linux.site>
References: <BAY4-F17uAyHsjCGvse00028763@hotmail.com>
	 <Pine.LNX.4.58.0410281326360.7845@linux.site>
Message-ID: <1099003169.12894.44.camel@exponential.lanl.gov>

On Thu, 2004-10-28 at 13:26, Ronald G. Minnich wrote:
> I'm very sorry, epia is still broken but is getting fixed.
> 

I will work on that. Do you know why most of the "pci" keyword
is marked in the mainboard Config.lb ?

Ollie

> ron
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 



From rminnich at lanl.gov  Thu Oct 28 17:22:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Thu Oct 28 17:22:01 2004
Subject: status information
In-Reply-To: <1098997117.12894.29.camel@exponential.lanl.gov>
References: <20041028115139.GA19778@openbios.org>  <m3654v9gbn.fsf@maxwell.lnxi.com>
  <1098980402.12894.0.camel@exponential.lanl.gov>  <Pine.LNX.4.58.0410281323440.7845@linux.site>
 <1098997117.12894.29.camel@exponential.lanl.gov>
Message-ID: <Pine.LNX.4.58.0410281644310.11174@linux.site>


On Thu, 28 Oct 2004, Li-Ta Lo wrote:

> Last time I tried to do that it was not that simple. The .lds is a mix 
> of "#include" and "#define" in the ldscript and depends on the config
> too much.

it was not simple but I got it to work ...

ron


From rminnich at lanl.gov  Thu Oct 28 17:26:10 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Thu Oct 28 17:26:10 2004
Subject: status information
In-Reply-To: <4181496D.5090301@bitworks.com>
References: <20041028115139.GA19778@openbios.org>  <m3654v9gbn.fsf@maxwell.lnxi.com>
  <Pine.LNX.4.58.0410280813530.7845@linux.site> <1098990045.12894.20.camel@exponential.lanl.gov>
 <4181496D.5090301@bitworks.com>
Message-ID: <Pine.LNX.4.58.0410281640380.11174@linux.site>


On Thu, 28 Oct 2004, Richard Smith wrote:

> Why is this there in the first place?

most chipsets come up with only the top 64KB of flash enabled. 

In the old days, we didn't turn that on until linuxbios was running. It's 
historical.

ron


From rminnich at lanl.gov  Thu Oct 28 17:31:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Thu Oct 28 17:31:00 2004
Subject: VIA GPL Violation ?
In-Reply-To: <41816225.7030501@esitcom.org>
References: <1098955883.1304.6.camel@raph.imag.fr> <Pine.LNX.4.58.0410280811280.7845@linux.site>
 <418143C9.80306@onelabs.com> <41816225.7030501@esitcom.org>
Message-ID: <Pine.LNX.4.58.0410281644570.11174@linux.site>


On Thu, 28 Oct 2004, Amaury Jacquot wrote:

> Bari Ari wrote:
> 
> > This is not new for Via:
> > 
> > Via "violates" GNU GPL with Padlock
> > http://www.theinquirer.net/?article=15329
> > 
> > but they did comply after being informed
> > http://linuxdevices.com/news/NS4520757633.html
> 
> lemme guess ? they're like kids, have to be reminded every time ?

it may be that it's different groups each time. Remember, via is a BIG 
company.

ron


From ebiederman at lnxi.com  Thu Oct 28 17:45:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Oct 28 17:45:01 2004
Subject: status information
In-Reply-To: <Pine.LNX.4.58.0410281640380.11174@linux.site>
References: <20041028115139.GA19778@openbios.org>
	<m3654v9gbn.fsf@maxwell.lnxi.com>
	<Pine.LNX.4.58.0410280813530.7845@linux.site>
	<1098990045.12894.20.camel@exponential.lanl.gov>
	<4181496D.5090301@bitworks.com>
	<Pine.LNX.4.58.0410281640380.11174@linux.site>
Message-ID: <m3u0seo31n.fsf@maxwell.lnxi.com>

"Ronald G. Minnich" <rminnich at lanl.gov> writes:

> On Thu, 28 Oct 2004, Richard Smith wrote:
> 
> > Why is this there in the first place?
> 
> most chipsets come up with only the top 64KB of flash enabled. 
> 
> In the old days, we didn't turn that on until linuxbios was running. It's 
> historical.

We have a hard limit that at least the romcc part of the codebase
needs to run below that so we can enable more than 64KiB of flash.

It is my intention once I get the minor details firmed up to reexamine
romcc and see what I can do size wise.  I have come close to
getting things smaller but there is some little glitch preventing
things from working :(

Eric


From ebiederman at lnxi.com  Thu Oct 28 17:50:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Oct 28 17:50:01 2004
Subject: status information
In-Reply-To: <Pine.LNX.4.58.0410280813530.7845@linux.site>
References: <20041028115139.GA19778@openbios.org>
	<m3654v9gbn.fsf@maxwell.lnxi.com>
	<Pine.LNX.4.58.0410280813530.7845@linux.site>
Message-ID: <m3wtxaqx83.fsf@maxwell.lnxi.com>

"Ronald G. Minnich" <rminnich at lanl.gov> writes:

> On Thu, 28 Oct 2004, Eric W. Biederman wrote:
> 
> > I will (hopefully) commit later today, but I have found one general
> > technique that will cut down the code size but a small amount.
> > In the chip_operations struct we have a name for debugging.
> > Since we are no longer printing that name there is no point in
> > keeping it.
> 
> hmm, this sounds like a lot of potential pain for a small gain. Can we 
> talk about this a bit first. 

Sure.    First here are two examples.
struct chip_opertations cpu_intel_socket_mPGA479M_control = {
	.name = "socket mPGA479M",
};

Killing the name for cpu sockets allows us to kill the whole
structure.

struct chip_operations northbridge_intel_e7501_ops = {
        .name      = "intel E7501 Northbridge",
	.enable_dev = enable_dev,
};


First note that all we did with the names was to print them when
we converted from the static to the dynamic tree.  Nothing
uses them anymore.  

Killing them is as simple as removing a structure member.  And
deleting a few lines of code.  Bloatwise strings appear to
be up towards the top of the list.

This is really a continuation of killing the static device tree.

If you like I will trade you gdb stubs for the currently useless
debugging string names. ;)  I just finished the code for that.
The conversations of the last couple of days inspired me. :)

Eric


From rminnich at lanl.gov  Thu Oct 28 17:54:05 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Thu Oct 28 17:54:05 2004
Subject: status information
In-Reply-To: <m3u0seo31n.fsf@maxwell.lnxi.com>
References: <20041028115139.GA19778@openbios.org> <m3654v9gbn.fsf@maxwell.lnxi.com>
 <Pine.LNX.4.58.0410280813530.7845@linux.site> <1098990045.12894.20.camel@exponential.lanl.gov>
 <4181496D.5090301@bitworks.com> <Pine.LNX.4.58.0410281640380.11174@linux.site>
 <m3u0seo31n.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.58.0410281711420.11174@linux.site>


On Thu, 28 Oct 2004, Eric W. Biederman wrote:

> We have a hard limit that at least the romcc part of the codebase
> needs to run below that so we can enable more than 64KiB of flash.

yah. But romcc does a good job. When I move c_payload to 0xfffe0000 there 
was a HUGE amount of room left for romcc ...

> It is my intention once I get the minor details firmed up to reexamine
> romcc and see what I can do size wise.  I have come close to getting
> things smaller but there is some little glitch preventing things from
> working :(

I think romcc is pretty darn good as is ... we just need to move c_payload 
(IMHO).

ron


From ebiederman at lnxi.com  Thu Oct 28 18:01:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Oct 28 18:01:01 2004
Subject: status information
In-Reply-To: <1098990045.12894.20.camel@exponential.lanl.gov>
References: <20041028115139.GA19778@openbios.org>
	<m3654v9gbn.fsf@maxwell.lnxi.com>
	<Pine.LNX.4.58.0410280813530.7845@linux.site>
	<1098990045.12894.20.camel@exponential.lanl.gov>
Message-ID: <m3sm7yqwk5.fsf@maxwell.lnxi.com>

Li-Ta Lo <ollie at lanl.gov> writes:

> On Thu, 2004-10-28 at 08:14, Ronald G. Minnich wrote:
> > On Thu, 28 Oct 2004, Eric W. Biederman wrote:
> > 
> > > I will (hopefully) commit later today, but I have found one general
> > > technique that will cut down the code size but a small amount.
> > > In the chip_operations struct we have a name for debugging.
> > > Since we are no longer printing that name there is no point in
> > > keeping it.
> > 
> > hmm, this sounds like a lot of potential pain for a small gain. Can we 
> > talk about this a bit first. 
> > 
> 
> Some points I didn't make clear during the LNXI visit about the size 
> problem are:
> 
> 	1. Virtually no one is putting the kernel in the FLASH ROM,
> 	   people use CF instead. Every payload/bootloader we are
> 	   using can support that.

With kexec finally in the kernel and a knowledge of what is needed
to keep kernel size under control and an availability of 1MiB flash
parts, it is my intention to start soon.  But it requires a moment
to breath.  What seems clear is that while we have hit a plateau with
a working set of bootloaders we need to do something better.

As for CF.  I guess I have only seen LANL doing that, and it
seems a little unsatisfactory.  There is no reason why beoboot
needs that much space for example.

> 	2. The size of FLASH grows exponentially if there is no stupid
> 	   limitation such as address lines in DIP32 package. Currently
> 	   LinuxBIOS only grows linearly. 

Hmm.  I don't have enough data points to support that yet. 

Currently romcc makes code that is 3x larger but more maintainable.
512KiB flash parts seem to be the norm for server boards.
Although I think I have sighted 1MiB parts in the wild.

Still my fallback image size has already moved from 64KiB to 128KiB.
And I really don't want to see it get much larger...

> So why can not we relax the 64kB limit of LinuxBIOS ? 

If we can still set an arbitrary limit when we rearrange the
code I don't have a problem.  For the current set of ports I don't
need to and I would rather trim a little fat then to push things
very far.  

One of the challenges is that to keep the flashing sane the fallback
image needs to fall nicely on flash block boundaries.  Which are
64KiB in the worst case.

> I do think removing the name of the device is a wrong direction.

It is wrong to remove the unused name of the chip?

Eric


From YhLu at tyan.com  Thu Oct 28 18:06:00 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Oct 28 18:06:00 2004
Subject: status information
Message-ID: <3174569B9743D511922F00A0C94314230665B7F1@TYANWEB>

For S2885, I can not compile that under LOGLEVEL=8. And I have to comment
out severl printk_debug in auto.c stage.

Before Eric do sth about romcc, I think remove name member in chip_operation
would be fine.

Regards

YH

-----Original Message-----
From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
Sent: Thursday, October 28, 2004 3:44 PM
To: Ronald G. Minnich
Cc: Stefan Reinauer; linuxbios at clustermatic.org
Subject: Re: status information

"Ronald G. Minnich" <rminnich at lanl.gov> writes:

> On Thu, 28 Oct 2004, Eric W. Biederman wrote:
> 
> > I will (hopefully) commit later today, but I have found one general
> > technique that will cut down the code size but a small amount.
> > In the chip_operations struct we have a name for debugging.
> > Since we are no longer printing that name there is no point in
> > keeping it.
> 
> hmm, this sounds like a lot of potential pain for a small gain. Can we 
> talk about this a bit first. 

Sure.    First here are two examples.
struct chip_opertations cpu_intel_socket_mPGA479M_control = {
	.name = "socket mPGA479M",
};

Killing the name for cpu sockets allows us to kill the whole
structure.

struct chip_operations northbridge_intel_e7501_ops = {
        .name      = "intel E7501 Northbridge",
	.enable_dev = enable_dev,
};


First note that all we did with the names was to print them when
we converted from the static to the dynamic tree.  Nothing
uses them anymore.  

Killing them is as simple as removing a structure member.  And
deleting a few lines of code.  Bloatwise strings appear to
be up towards the top of the list.

This is really a continuation of killing the static device tree.

If you like I will trade you gdb stubs for the currently useless
debugging string names. ;)  I just finished the code for that.
The conversations of the last couple of days inspired me. :)

Eric
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From rminnich at lanl.gov  Thu Oct 28 18:13:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Thu Oct 28 18:13:00 2004
Subject: status information
In-Reply-To: <m3sm7yqwk5.fsf@maxwell.lnxi.com>
References: <20041028115139.GA19778@openbios.org> <m3654v9gbn.fsf@maxwell.lnxi.com>
 <Pine.LNX.4.58.0410280813530.7845@linux.site> <1098990045.12894.20.camel@exponential.lanl.gov>
 <m3sm7yqwk5.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.58.0410281734270.11174@linux.site>


On Thu, 28 Oct 2004, Eric W. Biederman wrote:

> With kexec finally in the kernel 

good to hear :-)

Is this 2.6.9 or ...

thanks

ron


From bari at onelabs.com  Thu Oct 28 18:17:14 2004
From: bari at onelabs.com (Bari Ari)
Date: Thu Oct 28 18:17:14 2004
Subject: Starting with linuxbios
In-Reply-To: <3174569B9743D511922F00A0C94314230665B7D2@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B7D2@TYANWEB>
Message-ID: <41818295.2080608@onelabs.com>

YhLu wrote:

> What's the usage for the CAR-PC?
> 
> GPS navigation?

The telematics/Car-PC's we've been designing also have CDMA/GPRS, CAM, 
WiFi and WiMax soon, USB2.0, 1394, 10/100 ethernet, Bluetooth and 
Cardbus. The telematics/Car-PC's allow the driver and passengers to have 
real time navigation, voice over IP, and high speed satellite 
connectivity to the internet while the vehicle is in motion. The driver 
can be following the on screen maps while the kids in the back seat can 
be watching a Mpeg movie or playing their Xbox or Playstation2 network 
games. The telematics/Car-PC's will also allow for full speed video 
teleconferencing and several other data services while the vehicle is 
cruising down the interstate or stuck in city traffic.

-Bari


From adilson at linuxembarcado.com.br  Thu Oct 28 18:25:01 2004
From: adilson at linuxembarcado.com.br (Adilson Oliveira)
Date: Thu Oct 28 18:25:01 2004
Subject: Starting with linuxbios
In-Reply-To: <3174569B9743D511922F00A0C94314230665B7D2@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B7D2@TYANWEB>
Message-ID: <418182EE.7070503@linuxembarcado.com.br>

YhLu wrote:
> What's the usage for the CAR-PC?
> 
> GPS navigation?
> 

No, nothing like this fancy now. Maybe later but the idea is to monitor 
the car variables, ambient variables, control personalization features 
like lights, perhaps play digital music, DVDs, etc.

[]s

Adilson.


From adilson at linuxembarcado.com.br  Thu Oct 28 18:29:17 2004
From: adilson at linuxembarcado.com.br (Adilson Oliveira)
Date: Thu Oct 28 18:29:17 2004
Subject: Starting with linuxbios
In-Reply-To: <4181694C.6060702@esitcom.org>
References: <3174569B9743D511922F00A0C94314230665B7D2@TYANWEB> <4181694C.6060702@esitcom.org>
Message-ID: <41818349.6000908@linuxembarcado.com.br>

Amaury Jacquot wrote:
> YhLu wrote:
> 
>> What's the usage for the CAR-PC?
>>
>> GPS navigation?
>>
>> Regards
>>
>> YH
>>
> 
> interestingly enough, I have the same useage ( see http://www.navsys.org )
> mebbe it's time for some dox to be written, a howto mebbe ?
> 

Interesting stuff but *way* over what I have in mind for now :)

[]s

Adilson.



From rminnich at lanl.gov  Thu Oct 28 18:33:32 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Thu Oct 28 18:33:32 2004
Subject: status information
In-Reply-To: <m3sm7yqwk5.fsf@maxwell.lnxi.com>
References: <20041028115139.GA19778@openbios.org> <m3654v9gbn.fsf@maxwell.lnxi.com>
 <Pine.LNX.4.58.0410280813530.7845@linux.site> <1098990045.12894.20.camel@exponential.lanl.gov>
 <m3sm7yqwk5.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.58.0410281740050.11174@linux.site>


On Thu, 28 Oct 2004, Eric W. Biederman wrote:

> As for CF.  I guess I have only seen LANL doing that, and it
> seems a little unsatisfactory.  There is no reason why beoboot
> needs that much space for example.

the reason is that myrinet and other drivers need that much space. 

CF is our future until the flash parts hit at least 4 MB. 

ron


From YhLu at tyan.com  Thu Oct 28 18:37:44 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Oct 28 18:37:44 2004
Subject: Starting with linuxbios
Message-ID: <3174569B9743D511922F00A0C94314230665B7F7@TYANWEB>

That is too powerful, some kind of desktop replacement Laptop?

Regards

YH

-----Original Message-----
From: Bari Ari [mailto:bari at onelabs.com] 
Sent: Thursday, October 28, 2004 4:37 PM
To: YhLu
Cc: Nathanael Noblet; Adilson Oliveira; linuxbios at clustermatic.org
Subject: Re: Starting with linuxbios

YhLu wrote:

> What's the usage for the CAR-PC?
> 
> GPS navigation?

The telematics/Car-PC's we've been designing also have CDMA/GPRS, CAM, 
WiFi and WiMax soon, USB2.0, 1394, 10/100 ethernet, Bluetooth and 
Cardbus. The telematics/Car-PC's allow the driver and passengers to have 
real time navigation, voice over IP, and high speed satellite 
connectivity to the internet while the vehicle is in motion. The driver 
can be following the on screen maps while the kids in the back seat can 
be watching a Mpeg movie or playing their Xbox or Playstation2 network 
games. The telematics/Car-PC's will also allow for full speed video 
teleconferencing and several other data services while the vehicle is 
cruising down the interstate or stuck in city traffic.

-Bari


From adilson at linuxembarcado.com.br  Thu Oct 28 18:42:01 2004
From: adilson at linuxembarcado.com.br (Adilson Oliveira)
Date: Thu Oct 28 18:42:01 2004
Subject: Starting with linuxbios
In-Reply-To: <200410282101.i9SL1T19019700@tundra.winternet.com>
References: <200410282101.i9SL1T19019700@tundra.winternet.com>
Message-ID: <418183D5.5070006@linuxembarcado.com.br>

Ken Fuchs wrote:
> Adilson wrote:
> 
> 
>>I'm thinking about create (another one) Car-PC and I want to use 
>>linuxbios to improve the boot time.
> 
> 
>>Is there any place you can recomend I can read about the basics of
>>this project?
> 
> 
> Although, AMD64 would be over-kill for a Car-PC, LinuxBIOS-AMD64.pdf
> is probably the most up to date document on LinuxBIOS v2 (freebios2):
> 
> http://www.openbios.org/LinuxBIOS-AMD64.pdf

Thanks Ken.

To my porpouses a Via Epia has more than enough firepower but I'll take 
a look at this file.

[]s

Adilson.


From linuxbios at mikebell.org  Thu Oct 28 18:46:12 2004
From: linuxbios at mikebell.org (linuxbios at mikebell.org)
Date: Thu Oct 28 18:46:12 2004
Subject: status information
In-Reply-To: <Pine.LNX.4.58.0410281734270.11174@linux.site>
References: <20041028115139.GA19778@openbios.org> <m3654v9gbn.fsf@maxwell.lnxi.com> <Pine.LNX.4.58.0410280813530.7845@linux.site> <1098990045.12894.20.camel@exponential.lanl.gov> <m3sm7yqwk5.fsf@maxwell.lnxi.com> <Pine.LNX.4.58.0410281734270.11174@linux.site>
Message-ID: <20041028234908.GD2018@tinyvaio.nome.ca>

On Thu, Oct 28, 2004 at 05:34:58PM -0600, Ronald G. Minnich wrote:
> Is this 2.6.9 or ...

-mm only right now, I believe (don't recall it showing up on bkbits).
But I seem to recall that Andrew Morton is close to pushing it through
to Linus's tree.


From rminnich at lanl.gov  Thu Oct 28 18:51:40 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Thu Oct 28 18:51:40 2004
Subject: status information
In-Reply-To: <20041028234908.GD2018@tinyvaio.nome.ca>
References: <20041028115139.GA19778@openbios.org> <m3654v9gbn.fsf@maxwell.lnxi.com>
 <Pine.LNX.4.58.0410280813530.7845@linux.site> <1098990045.12894.20.camel@exponential.lanl.gov>
 <m3sm7yqwk5.fsf@maxwell.lnxi.com> <Pine.LNX.4.58.0410281734270.11174@linux.site>
 <20041028234908.GD2018@tinyvaio.nome.ca>
Message-ID: <Pine.LNX.4.58.0410281751130.11174@linux.site>


On Thu, 28 Oct 2004 linuxbios at mikebell.org wrote:

> -mm only right now, I believe (don't recall it showing up on bkbits).
> But I seem to recall that Andrew Morton is close to pushing it through
> to Linus's tree.

once it's in we're going to stop worrying about kmonte any more :-)

but kmonte is not the reason we use CF. Driver size of stuff like myrinet 
and infiniband and quadrics is. Our big clusters only have ethernet on 
1/16 of hte nodes. 

ron


From YhLu at tyan.com  Thu Oct 28 18:53:50 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Oct 28 18:53:50 2004
Subject: S2885 -- spare 4s in rebooting
Message-ID: <3174569B9743D511922F00A0C94314230665B7FA@TYANWEB>

So after comment out jmp __cpu_reset will save the time under fallback mode.
It will use mtrr init in auto.c

Regards

YH

-----Original Message-----
From: YhLu 
Sent: Wednesday, October 27, 2004 8:12 PM
To: ebiederman at lnxi.com
Cc: Ronald G. Minnich; linuxbios at clustermatic.org
Subject: RE: S2885 -- spare 4s in rebooting

Under normal mode, using jmp __cpu_reset, the stage is rather faster.

Copying LinuxBIOS to ram. <------- here take sometime ---skipped by
Soft2_reset
Jumping to LinuxBIOS. <------------------ skipped by Soft2_reset
LinuxBIOS-1.1.72.0_Fallback Tue Oct 26 18:48:45 PDT 2004 rebooting...----->



-----Original Message-----
From: YhLu 
Sent: Wednesday, October 27, 2004 11:00 AM
To: ebiederman at lnxi.com
Cc: Ronald G. Minnich; linuxbios at clustermatic.org
Subject: RE: S2885 -- spare 4s in rebooting

With cpu_reset

~ # reboot
INIT: Sending processes the TERM signal
INIT: Cmos information update
Getting settings
Stop port mapper
Shutdown syslog daemon
Shutdown klogd daemon
Sending all processes the TERM signal...
Sending all processes the KILL signal..
Please, stand by while rebooting the system ...
Restarting system.
Copying LinuxBIOS to ram. <------- here take sometime ---skipped by
Soft2_reset
Jumping to LinuxBIOS. <------------------ skipped by Soft2_reset
LinuxBIOS-1.1.72.0_Fallback Tue Oct 26 18:48:45 PDT 2004 rebooting...----->
skipped by soft2_reset

LinuxBIOS-1.1.72.0_Fallback Tue Oct 26 18:48:45 PDT 2004 starting...
Ram1.00
Ram1.01
Ram2.00
Ram2.01
Ram3
Initializing memory:  done
Initializing memory:  done
Clearing initial memory region:  done
Ram4
Copying LinuxBIOS to ram.
Jumping to LinuxBIOS.
LinuxBIOS-1.1.72.0_Fallback Tue Oct 26 18:48:45 PDT 2004 booting...
Finding PCI configuration type.
PCI: Using configuration type 1

-----Original Message-----
From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
Sent: Wednesday, October 27, 2004 10:16 AM
To: YhLu
Cc: Ronald G. Minnich; linuxbios at clustermatic.org
Subject: Re: S2885 -- spare 4s in rebooting

YhLu <YhLu at tyan.com> writes:

> Spare 4s for rebooting
>  
> I add some comments in s2885/auto.c.
>  
> In auto.c call soft2_reset directly instead of jmp to __cpu_reset

Hmm. That does seem to have some merit.  Where are you seeing the code
run slowly?  In particular I am wondering if this is an mtrr setup
problem or something else you are avoiding.

Eric
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From bari at onelabs.com  Thu Oct 28 18:56:01 2004
From: bari at onelabs.com (Bari Ari)
Date: Thu Oct 28 18:56:01 2004
Subject: Telematics PC's (was Re: Starting with linuxbios)
In-Reply-To: <3174569B9743D511922F00A0C94314230665B7F7@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B7F7@TYANWEB>
Message-ID: <4181897D.9030102@onelabs.com>

YhLu wrote:

> That is too powerful, some kind of desktop replacement Laptop?

They are in-dash PC's that act as application servers (PVR, 
Teleconferencing, VoIP) and as routers for all the wireless network 
services outside the vehicle and devices used in the vehicle (laptop, 
PDA, Xbox etc). LinuxBIOS is a definite must since you can't wait a 
minute or so for the PC to boot after you start the car.

-Bari


From ginlin at nexcom.com.tw  Thu Oct 28 22:27:00 2004
From: ginlin at nexcom.com.tw (Gin)
Date: Thu Oct 28 22:27:00 2004
Subject: fallback and normal image
In-Reply-To: <Pine.LNX.4.58.0410280808550.7845@linux.site>
Message-ID: <000101c4bd6a$49991a10$8e04010a@nexcom.com.tw>

I could build an image now. Thanks all. 
I am curious about how fallback image and normal image are used. It
looks like in the normal image, it always jumps to the Protected_start.
I don't think it should be the start when the system boots up since it
will be in real-mode. So which image should I use? 

Regards,
Gin

-



From stuge-linuxbios at cdy.org  Thu Oct 28 22:47:01 2004
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Thu Oct 28 22:47:01 2004
Subject: fallback and normal image
In-Reply-To: <000101c4bd6a$49991a10$8e04010a@nexcom.com.tw>
References: <Pine.LNX.4.58.0410280808550.7845@linux.site> <000101c4bd6a$49991a10$8e04010a@nexcom.com.tw>
Message-ID: <20041029040946.GC18682@foo.birdnet.se>

On Fri, Oct 29, 2004 at 11:49:25AM +0800, Gin wrote:
> I could build an image now. Thanks all. 
> I am curious about how fallback image and normal image are used. It
> looks like in the normal image, it always jumps to the Protected_start.
> I don't think it should be the start when the system boots up since it
> will be in real-mode. So which image should I use? 

Both. The fallback image tries to load the normal image but if that
fails it'll take over and continue with the fallback image.

For only a single image, use fallback.


//Peter


From zhushisongzhu at yahoo.com  Fri Oct 29 06:36:00 2004
From: zhushisongzhu at yahoo.com (zhu shi song)
Date: Fri Oct 29 06:36:00 2004
Subject: i845 ddr init pass but still problem
Message-ID: <20041029115809.458.qmail@web13201.mail.yahoo.com>

Now I can pass DDR SDRAM init process. But still there
are some problem, After copying linuxbios to ram, when
jmp *%edi, MB reset.
The key point to make it pass is set Reg 0xC7 = 08,
then reset to make it effective. 
If letting sdram work correctly ,it looks like some
work still to be done.

  zhu



		
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail 


From rminnich at lanl.gov  Fri Oct 29 10:27:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Fri Oct 29 10:27:00 2004
Subject: i845 ddr init pass but still problem
In-Reply-To: <20041029115809.458.qmail@web13201.mail.yahoo.com>
References: <20041029115809.458.qmail@web13201.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0410290949061.13175@linux.site>


On Fri, 29 Oct 2004, zhu shi song wrote:

> Now I can pass DDR SDRAM init process. But still there
> are some problem, After copying linuxbios to ram, when
> jmp *%edi, MB reset.

So dram is still wrong :-(

sorry

ron


From ollie at lanl.gov  Fri Oct 29 10:32:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Fri Oct 29 10:32:00 2004
Subject: Starting with linuxbios
In-Reply-To: <41818295.2080608@onelabs.com>
References: <3174569B9743D511922F00A0C94314230665B7D2@TYANWEB>
	 <41818295.2080608@onelabs.com>
Message-ID: <1099065110.12894.47.camel@exponential.lanl.gov>

On Thu, 2004-10-28 at 17:36, Bari Ari wrote:
> YhLu wrote:
> 
> > What's the usage for the CAR-PC?
> > 
> > GPS navigation?
> 
> The telematics/Car-PC's we've been designing also have CDMA/GPRS, CAM, 
> WiFi and WiMax soon, USB2.0, 1394, 10/100 ethernet, Bluetooth and 
> Cardbus. The telematics/Car-PC's allow the driver and passengers to have 
> real time navigation, voice over IP, and high speed satellite 
> connectivity to the internet while the vehicle is in motion. The driver 
> can be following the on screen maps while the kids in the back seat can 
> be watching a Mpeg movie or playing their Xbox or Playstation2 network 
> games. The telematics/Car-PC's will also allow for full speed video 
> teleconferencing and several other data services while the vehicle is 
> cruising down the interstate or stuck in city traffic.
> 

Wow !!

	1. What is WiMax ?
	2. How do you run Xbox or PS2 game ? Some kind of emu ?
	3. How much is that toy?

Ollie

> -Bari
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 



From rminnich at lanl.gov  Fri Oct 29 10:50:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Fri Oct 29 10:50:01 2004
Subject: removing .name from the .c files is a bad idea
Message-ID: <Pine.LNX.4.58.0410291001590.13175@linux.site>

1) it will save little space at all. Here are all the strings for the
   arima/hdama
	
Arima HDAMA mainboard
AMD 8111
NSC 87360
socket 940
AMD K8 Northbridge
Arima HDAMA mainboard
AMD 8111

It is 105 bytes. Compressed by itself with gzip -3 it is 99 bytes. that's
conservative because on a bigger binary the dictionary will be better and
it will probably get smaller. If we're that tight we're in big trouble and
it is time to move c_payload to 0xfffe0000, not fool around removing this
type of nit, which will only buy us a small amount of time. 

2) The string names could be printed as SPEW by the device tree code as it
   walks the tree, and aid comprehension.That code is not in yet but it is 
   trivial to write and should go in. 

If people are really that worried about it, I can add an option to
config.g and you can #ifdef to the .c files using that name. I don't see
the point but if you really need that 99 or so bytes I guess that you can
do that.

This issue brings up an important question. We have just made a 
far-reaching set of changes that had to be made -- but we impacted every 
port in V2. We need to start being careful about how global changes are 
made. 

With the current user base growing rapidly I think we're going to need to
create a formal process for this type of global change. This would be
(e.g.) a Configuration Review Board composed of stakeholders that would
vote up or down on changes. I think we are almost past the point where
people can make big changes such as this with no consultation. I try to
consult via the mailing list but I don't think that always works. Any
comments on this idea?

ron



From rminnich at lanl.gov  Fri Oct 29 10:58:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Fri Oct 29 10:58:01 2004
Subject: New developer: Mark Wilkinson
Message-ID: <Pine.LNX.4.58.0410291019590.13175@linux.site>

 Mark Wilkinson is now fixing up the epia tree.

ron


From ollie at lanl.gov  Fri Oct 29 11:11:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Fri Oct 29 11:11:01 2004
Subject: status information
In-Reply-To: <m3sm7yqwk5.fsf@maxwell.lnxi.com>
References: <20041028115139.GA19778@openbios.org>
	 <m3654v9gbn.fsf@maxwell.lnxi.com>
	 <Pine.LNX.4.58.0410280813530.7845@linux.site>
	 <1098990045.12894.20.camel@exponential.lanl.gov>
	 <m3sm7yqwk5.fsf@maxwell.lnxi.com>
Message-ID: <1099067604.12894.70.camel@exponential.lanl.gov>

On Thu, 2004-10-28 at 16:58, Eric W. Biederman wrote:
> As for CF.  I guess I have only seen LANL doing that, and it
> seems a little unsatisfactory.  There is no reason why beoboot
> needs that much space for example.
> 

I bet there are a lot of people using CF in the embedded world, they 
can't use Etherboot to fetch the kernel from the net as you do. We 
should not only think about HPC applications. People in embedded
market are in different enviroment and have different cost structure
than you.

> > I do think removing the name of the device is a wrong direction.
> 
> It is wrong to remove the unused name of the chip?
> 

It is not wrong to remove 'unused' name if it is actually 'unused'.
It is wrong to ignore other people's need and refuse to consider
alternatives. In my point of view, removing the .name is what those
CS people called "premature optimization".

I think the most important issue is you tried to use ldscript magic
to layout the rom image. But it is still somehow 'hardcoded'. If it
is really that magical, people should have no problem changing the
rom layout by editing their target/Config.lb. and put the c_payload
wherever they want.

Ollie



From rminnich at lanl.gov  Fri Oct 29 11:50:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Fri Oct 29 11:50:01 2004
Subject: status information
In-Reply-To: <1099067604.12894.70.camel@exponential.lanl.gov>
References: <20041028115139.GA19778@openbios.org>  <m3654v9gbn.fsf@maxwell.lnxi.com>
  <Pine.LNX.4.58.0410280813530.7845@linux.site>  <1098990045.12894.20.camel@exponential.lanl.gov>
  <m3sm7yqwk5.fsf@maxwell.lnxi.com> <1099067604.12894.70.camel@exponential.lanl.gov>
Message-ID: <Pine.LNX.4.58.0410291112180.13175@linux.site>


On Fri, 29 Oct 2004, Li-Ta Lo wrote:

> I bet there are a lot of people using CF in the embedded world, they 
> can't use Etherboot to fetch the kernel from the net as you do. We 
> should not only think about HPC applications. People in embedded
> market are in different enviroment and have different cost structure
> than you.

good point. The Sandia mini clusters use CF.

ron


From stepan at openbios.org  Fri Oct 29 12:03:01 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Fri Oct 29 12:03:01 2004
Subject: status information
In-Reply-To: <1098996760.12894.23.camel@exponential.lanl.gov>
References: <20041028115139.GA19778@openbios.org> <m3654v9gbn.fsf@maxwell.lnxi.com> <Pine.LNX.4.58.0410280813530.7845@linux.site> <1098990045.12894.20.camel@exponential.lanl.gov> <4181496D.5090301@bitworks.com> <1098996760.12894.23.camel@exponential.lanl.gov>
Message-ID: <20041029172519.GA21362@openbios.org>

* Li-Ta Lo <ollie at lanl.gov> [041028 22:52]:
> Are you asking the 64KB limit? One reason is to prevent "bloating" in 
> LinuxBIOS. The other reason is some chip (AMD8111?) can only access the 
> top 64kB of flash after boot.

We could declare some size limit per chipset if it has such a
limitation?

OTOH, 64k should be enough for the setup task. I would have expected
that long term this can be pushed even further down again...?!

Is there a rough estimation which part takes how much in a typical
LinuxBIOS (AMD64) port? Maybe it makes sense to go look at the biggest
chunks first.

Stefan



From rsmith at bitworks.com  Fri Oct 29 12:14:00 2004
From: rsmith at bitworks.com (Richard Smith)
Date: Fri Oct 29 12:14:00 2004
Subject: status information
In-Reply-To: <1099067604.12894.70.camel@exponential.lanl.gov>
References: <20041028115139.GA19778@openbios.org>	 <m3654v9gbn.fsf@maxwell.lnxi.com>	 <Pine.LNX.4.58.0410280813530.7845@linux.site>	 <1098990045.12894.20.camel@exponential.lanl.gov>	 <m3sm7yqwk5.fsf@maxwell.lnxi.com> <1099067604.12894.70.camel@exponential.lanl.gov>
Message-ID: <41827FB3.8000400@bitworks.com>

Li-Ta Lo wrote:

> On Thu, 2004-10-28 at 16:58, Eric W. Biederman wrote:
> 
>>As for CF.  I guess I have only seen LANL doing that, and it
>>seems a little unsatisfactory.  There is no reason why beoboot
>>needs that much space for example.

> I bet there are a lot of people using CF in the embedded world, they 
> can't use Etherboot to fetch the kernel from the net as you do. We 
> should not only think about HPC applications. People in embedded
> market are in different enviroment and have different cost structure
> than you.

I'm using a CF on our board.

> I think the most important issue is you tried to use ldscript magic
> to layout the rom image. But it is still somehow 'hardcoded'. If it
> is really that magical, people should have no problem changing the
> rom layout by editing their target/Config.lb. and put the c_payload
> wherever they want.

I've got a concern/question about moving the payload location.  Are we 
talking about the location in RAM?

My ADLO+BOCHS+vbios payload is 130kib.  So moving the payload to 
0x0e0000 in the ROM is going to cause me issues.

What exactly is the memory map of linuxBIOS?  I've kinda looked at the 
ldscript but since I've never needed to chage it I must admit that its 
mostly magic to me.

-- 
Richard A. Smith




From rminnich at lanl.gov  Fri Oct 29 12:20:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Fri Oct 29 12:20:00 2004
Subject: status information
In-Reply-To: <20041029172519.GA21362@openbios.org>
References: <20041028115139.GA19778@openbios.org> <m3654v9gbn.fsf@maxwell.lnxi.com>
 <Pine.LNX.4.58.0410280813530.7845@linux.site> <1098990045.12894.20.camel@exponential.lanl.gov>
 <4181496D.5090301@bitworks.com> <1098996760.12894.23.camel@exponential.lanl.gov>
 <20041029172519.GA21362@openbios.org>
Message-ID: <Pine.LNX.4.58.0410291138300.13175@linux.site>


On Fri, 29 Oct 2004, Stefan Reinauer wrote:

> OTOH, 64k should be enough for the setup task. I would have expected
> that long term this can be pushed even further down again...?!
> 
> Is there a rough estimation which part takes how much in a typical
> LinuxBIOS (AMD64) port? Maybe it makes sense to go look at the biggest
> chunks first.

last time I looked, romcc output (depending on board) was bumping in at 
24-36K and c_payload made up the rest. So on some ports it is getting 
tight. 


today, on arima, payload is 28K, and the romcc output is big enough that 
it won't fit in 64k. That was not the case yesterday :-)

ron


From YhLu at tyan.com  Fri Oct 29 12:25:01 2004
From: YhLu at tyan.com (YhLu)
Date: Fri Oct 29 12:25:01 2004
Subject: status information
Message-ID: <3174569B9743D511922F00A0C94314230665B855@TYANWEB>

If the kernel can be tailed to (1MByte - LinuxBIOS size(64K *2)), 
There is no need for Etherboot or others.

YH

-----Original Message-----
From: Ronald G. Minnich [mailto:rminnich at lanl.gov] 
Sent: Friday, October 29, 2004 10:13 AM
To: Li-Ta Lo
Cc: Eric W. Biederman; Stefan Reinauer; LinuxBIOS
Subject: Re: status information



On Fri, 29 Oct 2004, Li-Ta Lo wrote:

> I bet there are a lot of people using CF in the embedded world, they 
> can't use Etherboot to fetch the kernel from the net as you do. We 
> should not only think about HPC applications. People in embedded
> market are in different enviroment and have different cost structure
> than you.

good point. The Sandia mini clusters use CF.

ron
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From rminnich at lanl.gov  Fri Oct 29 12:27:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Fri Oct 29 12:27:01 2004
Subject: status information
In-Reply-To: <41827FB3.8000400@bitworks.com>
References: <20041028115139.GA19778@openbios.org>  <m3654v9gbn.fsf@maxwell.lnxi.com>
  <Pine.LNX.4.58.0410280813530.7845@linux.site>  <1098990045.12894.20.camel@exponential.lanl.gov>
  <m3sm7yqwk5.fsf@maxwell.lnxi.com> <1099067604.12894.70.camel@exponential.lanl.gov>
 <41827FB3.8000400@bitworks.com>
Message-ID: <Pine.LNX.4.58.0410291142330.13175@linux.site>


On Fri, 29 Oct 2004, Richard Smith wrote:

> I've got a concern/question about moving the payload location.  Are we talking
> about the location in RAM?

not at all! We're only talking about how the linuxbios code is set up in 
flash. This has nothing to do with RAM locations. 

The issue is this: right now, linubios compressed payload AND romcc object 
fit in the top 64k. There is no need to do this. They're not fitting 
anyway at this point. 

romcc object startup can turn on full flash access, so the linuxbios
compressed payload can be placed, not in the top 64k, but in the 
next-to-top 64k. The linuxbios image will then have 128k available to it, 
not just 64k. Then we can put all the debug prints we want into romcc 
code, which would be nice. 


> My ADLO+BOCHS+vbios payload is 130kib.  So moving the payload to 0x0e0000 in
> the ROM is going to cause me issues.

How big is your flash? 

ron


From rminnich at lanl.gov  Fri Oct 29 12:29:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Fri Oct 29 12:29:00 2004
Subject: status information
In-Reply-To: <3174569B9743D511922F00A0C94314230665B855@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B855@TYANWEB>
Message-ID: <Pine.LNX.4.58.0410291150420.13175@linux.site>


On Fri, 29 Oct 2004, YhLu wrote:

> If the kernel can be tailed to (1MByte - LinuxBIOS size(64K *2)), 
> There is no need for Etherboot or others.

yes, as a reminder, the very earliest linuxbios machines we did at LANL 
were L440gx machines with linuxbios and linux in flash. No etherboot, no 
file, etc. 

But linux grew a bit ...

ron


From rminnich at lanl.gov  Fri Oct 29 12:30:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Fri Oct 29 12:30:00 2004
Subject: status information
In-Reply-To: <Pine.LNX.4.58.0410291142330.13175@linux.site>
References: <20041028115139.GA19778@openbios.org>  <m3654v9gbn.fsf@maxwell.lnxi.com>
  <Pine.LNX.4.58.0410280813530.7845@linux.site>  <1098990045.12894.20.camel@exponential.lanl.gov>
  <m3sm7yqwk5.fsf@maxwell.lnxi.com> <1099067604.12894.70.camel@exponential.lanl.gov>
 <41827FB3.8000400@bitworks.com> <Pine.LNX.4.58.0410291142330.13175@linux.site>
Message-ID: <Pine.LNX.4.58.0410291152120.13175@linux.site>


On Fri, 29 Oct 2004, Ronald G. Minnich wrote:

> romcc object startup can turn on full flash access, so the linuxbios
> compressed payload can be placed, not in the top 64k, but in the 
> next-to-top 64k. The linuxbios image will then have 128k available to it, 
> not just 64k. Then we can put all the debug prints we want into romcc 
> code, which would be nice. 

I forgot to add: it could also be at 0xfffe8000, i.e. on a 32k boundary, 
and ... I've tested this and it works.

ron


From ollie at lanl.gov  Fri Oct 29 12:30:11 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Fri Oct 29 12:30:11 2004
Subject: status information
In-Reply-To: <41827FB3.8000400@bitworks.com>
References: <20041028115139.GA19778@openbios.org>
	 <m3654v9gbn.fsf@maxwell.lnxi.com>
	 <Pine.LNX.4.58.0410280813530.7845@linux.site>
	 <1098990045.12894.20.camel@exponential.lanl.gov>
	 <m3sm7yqwk5.fsf@maxwell.lnxi.com>
	 <1099067604.12894.70.camel@exponential.lanl.gov>
	 <41827FB3.8000400@bitworks.com>
Message-ID: <1099072381.12894.80.camel@exponential.lanl.gov>

On Fri, 2004-10-29 at 11:36, Richard Smith wrote:
> 
> I'm using a CF on our board.
> 
> > I think the most important issue is you tried to use ldscript magic
> > to layout the rom image. But it is still somehow 'hardcoded'. If it
> > is really that magical, people should have no problem changing the
> > rom layout by editing their target/Config.lb. and put the c_payload
> > wherever they want.
> 
> I've got a concern/question about moving the payload location.  Are we 
> talking about the location in RAM?
> 

No, we are talking about the ROM image layout no how they are copied to
the RAM. Currently, if you don't put the kernel in the ROM, most of the 
ROM space is 'unused'.

> My ADLO+BOCHS+vbios payload is 130kib.  So moving the payload to 
> 0x0e0000 in the ROM is going to cause me issues.
> 
> What exactly is the memory map of linuxBIOS?  I've kinda looked at the 
> ldscript but since I've never needed to chage it I must admit that its 
> mostly magic to me.

That is exactly my point. The way ldscript is done is too diffcult to 
understand, the different xxx_ROM_yyy options do not help neither.

Ollie




From rsmith at bitworks.com  Fri Oct 29 12:36:01 2004
From: rsmith at bitworks.com (Richard Smith)
Date: Fri Oct 29 12:36:01 2004
Subject: status information
In-Reply-To: <Pine.LNX.4.58.0410291142330.13175@linux.site>
References: <20041028115139.GA19778@openbios.org>  <m3654v9gbn.fsf@maxwell.lnxi.com>  <Pine.LNX.4.58.0410280813530.7845@linux.site>  <1098990045.12894.20.camel@exponential.lanl.gov>  <m3sm7yqwk5.fsf@maxwell.lnxi.com> <1099067604.12894.70.camel@exponential.lanl.gov> <41827FB3.8000400@bitworks.com> <Pine.LNX.4.58.0410291142330.13175@linux.site>
Message-ID: <418284D0.4050401@bitworks.com>

Ronald G. Minnich wrote:

> The issue is this: right now, linubios compressed payload AND romcc object 
> fit in the top 64k. There is no need to do this. They're not fitting 
> anyway at this point. 
> 
> romcc object startup can turn on full flash access, so the linuxbios
> compressed payload can be placed, not in the top 64k, but in the 
> next-to-top 64k. The linuxbios image will then have 128k available to it, 
> not just 64k. Then we can put all the debug prints we want into romcc 
> code, which would be nice. 
> 

So how is my stuff working then? Its way over 64k.  Guess I'm still 
confused.  Can you draw me a memory map?

>>My ADLO+BOCHS+vbios payload is 130kib.  So moving the payload to 0x0e0000 in
>>the ROM is going to cause me issues.
>  
> How big is your flash? 

512kib actually I have 2 of them for 1 meg but the second has to be 
muxed and currently unused.


-- 
Richard A. Smith




From bari at onelabs.com  Fri Oct 29 13:14:00 2004
From: bari at onelabs.com (Bari Ari)
Date: Fri Oct 29 13:14:00 2004
Subject: Starting with linuxbios
In-Reply-To: <1099065110.12894.47.camel@exponential.lanl.gov>
References: <3174569B9743D511922F00A0C94314230665B7D2@TYANWEB>	 <41818295.2080608@onelabs.com> <1099065110.12894.47.camel@exponential.lanl.gov>
Message-ID: <41828E38.20505@onelabs.com>

Li-Ta Lo wrote:

> 	1. What is WiMax ?

http://www.wimaxforum.org/

"WiMAX is a standards-based wireless technology that provides 
high-throughput broadband connections over long distances. WiMAX can be 
used for a number of applications, including "last mile" broadband 
connections, hotspot and cellular backhaul, and high-speed enterprise 
connectivity for businesses.

An implementation of the IEEE 802.16 standard, WiMAX provides 
metropolitan area network connectivity at speeds of up to 75 Mb/sec. 
WiMAX systems can be used to transmit signal as far as 30 miles. 
However, on the average a WiMAX base-station installation will likely 
cover between three to five miles."

> 	2. How do you run Xbox or PS2 game ? Some kind of emu ?

The games are played on their respective game consoles. You connect the 
consoles to the telematics/car-pc via 10/100 ethernet. The 
telematics/car-pc acts as a router between the game console and internet 
  via cdma/gprs, satellite and/or WiMax.


> 	3. How much is that toy?

T.B.D.

-Bari



From ollie at lanl.gov  Fri Oct 29 13:55:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Fri Oct 29 13:55:01 2004
Subject: Starting with linuxbios
In-Reply-To: <41828E38.20505@onelabs.com>
References: <3174569B9743D511922F00A0C94314230665B7D2@TYANWEB>
	 <41818295.2080608@onelabs.com>
	 <1099065110.12894.47.camel@exponential.lanl.gov>
	 <41828E38.20505@onelabs.com>
Message-ID: <1099077460.12894.82.camel@exponential.lanl.gov>

On Fri, 2004-10-29 at 12:38, Bari Ari wrote:
> 
> > 	2. How do you run Xbox or PS2 game ? Some kind of emu ?
> 
> The games are played on their respective game consoles. You connect the 
> consoles to the telematics/car-pc via 10/100 ethernet. The 
> telematics/car-pc acts as a router between the game console and internet 
>   via cdma/gprs, satellite and/or WiMax.
> 

Is that some kind of VNC/RDP ?

Ollie




From rminnich at lanl.gov  Fri Oct 29 14:00:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Fri Oct 29 14:00:00 2004
Subject: status information
In-Reply-To: <418284D0.4050401@bitworks.com>
References: <20041028115139.GA19778@openbios.org>  <m3654v9gbn.fsf@maxwell.lnxi.com>
  <Pine.LNX.4.58.0410280813530.7845@linux.site>  <1098990045.12894.20.camel@exponential.lanl.gov>
  <m3sm7yqwk5.fsf@maxwell.lnxi.com> <1099067604.12894.70.camel@exponential.lanl.gov>
 <41827FB3.8000400@bitworks.com> <Pine.LNX.4.58.0410291142330.13175@linux.site>
 <418284D0.4050401@bitworks.com>
Message-ID: <Pine.LNX.4.58.0410291316310.13175@linux.site>


On Fri, 29 Oct 2004, Richard Smith wrote:

> Ronald G. Minnich wrote:
> 
> > The issue is this: right now, linubios compressed payload AND romcc object
> > fit in the top 64k. There is no need to do this. They're not fitting anyway
> > at this point. romcc object startup can turn on full flash access, so the
> > linuxbios
> > compressed payload can be placed, not in the top 64k, but in the next-to-top
> > 64k. The linuxbios image will then have 128k available to it, not just 64k.
> > Then we can put all the debug prints we want into romcc code, which would be
> > nice. 


old-fashioned linuxbios


----------- (e.g.) 0xfff80000
| payload |
|         |
|         |
----------- 0xffff0000
| linux   |
| bios    |
----------|

V2:

--------------0xfff80000
| smith      |
| payload    |
--------------0xffff0000
| c_payload  |
| uncompress |
| to ram     |
|   ----     |
| auto.C     |
| compiled   |
|  code      |
--------------


So there are really two "payloads"

There is startup code -- now compiled by romcc -- that turns on ram and 
uncompresses the c_payload to ram. The RAM code then does final setup and 
uncompresses the "smith payload" or whatever (Etherboot, filo, linux, 
ADLO) to ram.


So I'm just saying do this.

--------------0xfff80000
| smith      |
| payload    |
--------------0xfffe0000
| c_payload  |
| uncompress |
| to ram     |
|------------|0xffff0000
| auto.C     |
| compiled   |
|  code      |
--------------


That's all you have to do to fix the issues with romcc getting too big.

ron


From YhLu at tyan.com  Fri Oct 29 14:42:00 2004
From: YhLu at tyan.com (YhLu)
Date: Fri Oct 29 14:42:00 2004
Subject: status information
Message-ID: <3174569B9743D511922F00A0C94314230665B885@TYANWEB>

If the ROMCC can handle function not as inline. You may don't need to
enlarge the 64K limit.
Current Auto.c compiled is some big. Esp the print_debug causes the problem

Regards

YH

-----Original Message-----
From: Ronald G. Minnich [mailto:rminnich at lanl.gov] 
Sent: Friday, October 29, 2004 12:22 PM
To: Richard Smith
Cc: ollie at lanl.gov; Eric W. Biederman; Stefan Reinauer; LinuxBIOS
Subject: Re: status information



On Fri, 29 Oct 2004, Richard Smith wrote:

> Ronald G. Minnich wrote:
> 
> > The issue is this: right now, linubios compressed payload AND romcc
object
> > fit in the top 64k. There is no need to do this. They're not fitting
anyway
> > at this point. romcc object startup can turn on full flash access, so
the
> > linuxbios
> > compressed payload can be placed, not in the top 64k, but in the
next-to-top
> > 64k. The linuxbios image will then have 128k available to it, not just
64k.
> > Then we can put all the debug prints we want into romcc code, which
would be
> > nice. 


old-fashioned linuxbios


----------- (e.g.) 0xfff80000
| payload |
|         |
|         |
----------- 0xffff0000
| linux   |
| bios    |
----------|

V2:

--------------0xfff80000
| smith      |
| payload    |
--------------0xffff0000
| c_payload  |
| uncompress |
| to ram     |
|   ----     |
| auto.C     |
| compiled   |
|  code      |
--------------


So there are really two "payloads"

There is startup code -- now compiled by romcc -- that turns on ram and 
uncompresses the c_payload to ram. The RAM code then does final setup and 
uncompresses the "smith payload" or whatever (Etherboot, filo, linux, 
ADLO) to ram.


So I'm just saying do this.

--------------0xfff80000
| smith      |
| payload    |
--------------0xfffe0000
| c_payload  |
| uncompress |
| to ram     |
|------------|0xffff0000
| auto.C     |
| compiled   |
|  code      |
--------------


That's all you have to do to fix the issues with romcc getting too big.

ron
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From bari at onelabs.com  Fri Oct 29 14:52:00 2004
From: bari at onelabs.com (Bari Ari)
Date: Fri Oct 29 14:52:00 2004
Subject: Starting with linuxbios
In-Reply-To: <1099077460.12894.82.camel@exponential.lanl.gov>
References: <3174569B9743D511922F00A0C94314230665B7D2@TYANWEB>	 <41818295.2080608@onelabs.com>	 <1099065110.12894.47.camel@exponential.lanl.gov>	 <41828E38.20505@onelabs.com> <1099077460.12894.82.camel@exponential.lanl.gov>
Message-ID: <4182A50C.7040905@onelabs.com>

Li-Ta Lo wrote:
> Is that some kind of VNC/RDP ?

In the case of game consoles the telematics computer just acts as a 
cdma/gprs or satellite modem/router/gateway that interfaces to game 
consoles via their network adapter. So just to be clear, there is a 
telematics computer that has all the (outside of vehicle) wireless 
services with the capability to have game consoles (like Xbox, PS2, 
Zodiac etc) connected to it via 10/100, Bluetooth etc.(inside the vehicle).

-Bari


From ollie at lanl.gov  Fri Oct 29 14:59:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Fri Oct 29 14:59:01 2004
Subject: Starting with linuxbios
In-Reply-To: <4182A50C.7040905@onelabs.com>
References: <3174569B9743D511922F00A0C94314230665B7D2@TYANWEB>
	 <41818295.2080608@onelabs.com>
	 <1099065110.12894.47.camel@exponential.lanl.gov>
	 <41828E38.20505@onelabs.com>
	 <1099077460.12894.82.camel@exponential.lanl.gov>
	 <4182A50C.7040905@onelabs.com>
Message-ID: <1099081307.12894.84.camel@exponential.lanl.gov>

On Fri, 2004-10-29 at 14:16, Bari Ari wrote:
> Li-Ta Lo wrote:
> > Is that some kind of VNC/RDP ?
> 
> In the case of game consoles the telematics computer just acts as a 
> cdma/gprs or satellite modem/router/gateway that interfaces to game 
> consoles via their network adapter. So just to be clear, there is a 
> telematics computer that has all the (outside of vehicle) wireless 
> services with the capability to have game consoles (like Xbox, PS2, 
> Zodiac etc) connected to it via 10/100, Bluetooth etc.(inside the vehicle).
> 

So you still need to have one Xbox/Ps2 on the car ?

Ollie

> -Bari
> 



From bari at onelabs.com  Fri Oct 29 15:12:00 2004
From: bari at onelabs.com (Bari Ari)
Date: Fri Oct 29 15:12:00 2004
Subject: Starting with linuxbios
In-Reply-To: <1099081307.12894.84.camel@exponential.lanl.gov>
References: <3174569B9743D511922F00A0C94314230665B7D2@TYANWEB>	 <41818295.2080608@onelabs.com>	 <1099065110.12894.47.camel@exponential.lanl.gov>	 <41828E38.20505@onelabs.com>	 <1099077460.12894.82.camel@exponential.lanl.gov>	 <4182A50C.7040905@onelabs.com> <1099081307.12894.84.camel@exponential.lanl.gov>
Message-ID: <4182A9D6.7060500@onelabs.com>

Li-Ta Lo wrote:
> So you still need to have one Xbox/Ps2 on the car ?

Yes. I can't imagine Sony or MS licensing anything for less then a 
bazillion $$ to be able to build compatible gaming hardware into a 
telematics unit or anything else.

-Bari


From rminnich at lanl.gov  Fri Oct 29 15:19:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Fri Oct 29 15:19:00 2004
Subject: status information
In-Reply-To: <3174569B9743D511922F00A0C94314230665B885@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B885@TYANWEB>
Message-ID: <Pine.LNX.4.58.0410291440540.13175@linux.site>


On Fri, 29 Oct 2004, YhLu wrote:

> If the ROMCC can handle function not as inline. You may don't need to
> enlarge the 64K limit.
> Current Auto.c compiled is some big. Esp the print_debug causes the problem

yes. 

The long term solution is to have all vendors set up working cache-as-ram, 
short term is harder and involves romcc. It would be good if more people 
could learn romcc innards and help with this difficult problem.

ron


From Stephen.Kimball at bench.com  Fri Oct 29 16:35:00 2004
From: Stephen.Kimball at bench.com (Stephen.Kimball at bench.com)
Date: Fri Oct 29 16:35:00 2004
Subject: LinuxBIOS debugging with an emulator
Message-ID: <9B124F08B3EFDA4F8813B05102DC719501A9027A@nh-ex01.nh.bench.com>

> On Thu, 2004-10-28 at 16:03, Stephen.Kimball at bench.com wrote:
> > 
> > It seems that LinuxBIOS copies itself to _RAMBASE, which is 0x4000.
> > Then it branches to 0x4000 into _start, which sets up the stack and
> > calls hardwaremain.  The address of hardwaremain from linuxbios_c.o
is
> > wrong.  The address is not the Flash address and it's not the RAM
> > address.  Can someone explain how linuxbios_c.o is linked with RAM
> > addresses?  
> > 
>
> What do you mean ? In the S2885 I built, the _RAMBASE is 0x4000 and 
> hardwaremain is 0x5fe0 as you can get from the linuxbios_c.map. They
> are both in RAM. If you use "objdump -drS linuxbios_c.o" you will
> find the hardwaremain is at offset 0x1fe0 from the _RAMBASSE.
> 
> BTW, if you specify the -g option for gcc, you can use the -S option
> in objdump to see the source code with the disassebmly (-d).
> 
> Ollie

In the amd/serenade I built, the _RAMBASE is 0x4000 and hardwaremain is
at 0x60B8 from the linuxbios_c.map.  Hardwaremain is at 0x20B8 in the
objdump.
That all make sense.  But if I step through the execution of _start from
0x4000 to the call to hardwaremain.  I see it branch to 0x5F70 and the
instructions at 0x5F70 match the hardwaremain in objdump.  So I think
it's really at 0x5F70 not 0x60B8.  It's only off by 0x148 bytes.

I bet your hardwaremain isn't at 0x5FE0.

Steve  


From rminnich at lanl.gov  Fri Oct 29 16:37:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Fri Oct 29 16:37:01 2004
Subject: FILO fixups
Message-ID: <Pine.LNX.4.58.0410291552300.13175@linux.site>

I've just finished fixups to filo that make it quite a bit faster. 

First, it used to scan the bus twice, the first time to do a count. That's 
slow, although it was a nice algorithm. But it only needed to find at most 
2 devices. 

Now it scans until the device is found and returns it. Even in the worst
case, the new pci scan is always faster than the old.

There are new options in addition to PCI_BRUTE_SCAN. 

PCI_BRUTE_SCAN means: 
scan everything ...

PCI_BRUTE_SCAN_START

... but start at this bus (VERY good on k8, as the scan of 0:19.* takes 
FOREVER).

PCI_BRUTE_SCAN_LIMIT = 2
... and end here -1(useful when you know that the busses don't range to 
256)

And the 'instant gratification' option:

IDE_HINT_BUS
IDE_HINT_DEV
IDE_HINT_FUNC

All three must be set or not set or you get a compile-time warning. IF all
three are set, FILO will probe the device and IF it is an ide controller
use that. If it's not an ide controller, filo will scan busses as usual.

This last option REALLY speeds things up

ron




From ollie at lanl.gov  Fri Oct 29 16:42:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Fri Oct 29 16:42:00 2004
Subject: FILO fixups
In-Reply-To: <Pine.LNX.4.58.0410291552300.13175@linux.site>
References: <Pine.LNX.4.58.0410291552300.13175@linux.site>
Message-ID: <1099087480.12894.86.camel@exponential.lanl.gov>

On Fri, 2004-10-29 at 15:59, Ronald G. Minnich wrote:
> I've just finished fixups to filo that make it quite a bit faster. 
> 
> First, it used to scan the bus twice, the first time to do a count. That's 
> slow, although it was a nice algorithm. But it only needed to find at most 
> 2 devices. 
> 

Since it appears nobody is maintaining FILO do you think we should put 
it in util directory in freebios2?

Ollie





From ollie at lanl.gov  Fri Oct 29 16:44:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Fri Oct 29 16:44:00 2004
Subject: LinuxBIOS debugging with an emulator
In-Reply-To: <9B124F08B3EFDA4F8813B05102DC719501A9027A@nh-ex01.nh.bench.com>
References: <9B124F08B3EFDA4F8813B05102DC719501A9027A@nh-ex01.nh.bench.com>
Message-ID: <1099087589.12894.88.camel@exponential.lanl.gov>

On Fri, 2004-10-29 at 15:57, Stephen.Kimball at bench.com wrote:
> > On Thu, 2004-10-28 at 16:03, Stephen.Kimball at bench.com wrote:
> > > 
> > > It seems that LinuxBIOS copies itself to _RAMBASE, which is 0x4000.
> > > Then it branches to 0x4000 into _start, which sets up the stack and
> > > calls hardwaremain.  The address of hardwaremain from linuxbios_c.o
> is
> > > wrong.  The address is not the Flash address and it's not the RAM
> > > address.  Can someone explain how linuxbios_c.o is linked with RAM
> > > addresses?  
> > > 
> >
> > What do you mean ? In the S2885 I built, the _RAMBASE is 0x4000 and 
> > hardwaremain is 0x5fe0 as you can get from the linuxbios_c.map. They
> > are both in RAM. If you use "objdump -drS linuxbios_c.o" you will
> > find the hardwaremain is at offset 0x1fe0 from the _RAMBASSE.
> > 
> > BTW, if you specify the -g option for gcc, you can use the -S option
> > in objdump to see the source code with the disassebmly (-d).
> > 
> > Ollie
> 
> In the amd/serenade I built, the _RAMBASE is 0x4000 and hardwaremain is
> at 0x60B8 from the linuxbios_c.map.  Hardwaremain is at 0x20B8 in the
> objdump.
> That all make sense.  But if I step through the execution of _start from
> 0x4000 to the call to hardwaremain.  I see it branch to 0x5F70 and the
> instructions at 0x5F70 match the hardwaremain in objdump.  So I think
> it's really at 0x5F70 not 0x60B8.  It's only off by 0x148 bytes.
> 
> I bet your hardwaremain isn't at 0x5FE0.
> 

Sorry I have no idea about this. The HDT we have can only trace the
ROMCC part.

Ollie

> Steve  
> 



From YhLu at tyan.com  Fri Oct 29 17:03:00 2004
From: YhLu at tyan.com (YhLu)
Date: Fri Oct 29 17:03:00 2004
Subject: FILO fixups
Message-ID: <3174569B9743D511922F00A0C94314230665B8B3@TYANWEB>

The filo is merged into Etherboot. And it will be released in 5.2.6 formally
I guess.

Regards

YH

-----Original Message-----
From: Li-Ta Lo [mailto:ollie at lanl.gov] 
Sent: Friday, October 29, 2004 3:05 PM
To: Ronald G. Minnich
Cc: LinuxBIOS
Subject: Re: FILO fixups

On Fri, 2004-10-29 at 15:59, Ronald G. Minnich wrote:
> I've just finished fixups to filo that make it quite a bit faster. 
> 
> First, it used to scan the bus twice, the first time to do a count. That's

> slow, although it was a nice algorithm. But it only needed to find at most

> 2 devices. 
> 

Since it appears nobody is maintaining FILO do you think we should put 
it in util directory in freebios2?

Ollie



_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From rminnich at lanl.gov  Fri Oct 29 17:14:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Fri Oct 29 17:14:00 2004
Subject: FILO fixups
In-Reply-To: <Pine.LNX.4.58.0410291552300.13175@linux.site>
References: <Pine.LNX.4.58.0410291552300.13175@linux.site>
Message-ID: <Pine.LNX.4.58.0410291635070.13175@linux.site>


On Fri, 29 Oct 2004, Ronald G. Minnich wrote:
> This last option REALLY speeds things up

linux is running in < 8 seconds. 

3 of those seconds are FILO waiting for me to type return or not. 

This is an arima hdama. Having the payload skip the bus probe is a win.

Of course, in the long term, we want all payloads reading the linuxbios 
table for pci bus, but this hack will do for now.

ron


From rminnich at lanl.gov  Fri Oct 29 17:14:16 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Fri Oct 29 17:14:16 2004
Subject: FILO fixups
In-Reply-To: <1099087480.12894.86.camel@exponential.lanl.gov>
References: <Pine.LNX.4.58.0410291552300.13175@linux.site>
 <1099087480.12894.86.camel@exponential.lanl.gov>
Message-ID: <Pine.LNX.4.58.0410291636470.13175@linux.site>


On Fri, 29 Oct 2004, Li-Ta Lo wrote:

> Since it appears nobody is maintaining FILO do you think we should put 
> it in util directory in freebios2?
> 

that's my plan.

ron


From rminnich at lanl.gov  Fri Oct 29 17:16:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Fri Oct 29 17:16:01 2004
Subject: FILO fixups
In-Reply-To: <3174569B9743D511922F00A0C94314230665B8B3@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B8B3@TYANWEB>
Message-ID: <Pine.LNX.4.58.0410291637220.13175@linux.site>


On Fri, 29 Oct 2004, YhLu wrote:

> The filo is merged into Etherboot. And it will be released in 5.2.6 formally
> I guess.

that's a plus and a minus for us. It's nice seeing FILO get pulled into
supported software like Etherboot. But we've had uneven luck building a
working etherboot here. And ETherboot still does far more than we want. 

I would need to put the same kinds of mods into etherboot, and then build 
etherboot in a way in which all the ethernet support is not compiled in. 
In other words, I want to compile an etherboot down to FILO!

It is simpler to just use FILO directly.

ron


From YhLu at tyan.com  Fri Oct 29 17:21:01 2004
From: YhLu at tyan.com (YhLu)
Date: Fri Oct 29 17:21:01 2004
Subject: FILO fixups
Message-ID: <3174569B9743D511922F00A0C94314230665B8B6@TYANWEB>

You can get filo only under Etherboot.

make bin/filo.zelf

or 

make bin/tg3--filo.zelf

Also I added something into the filo in Etherboot.

Regards

YH

-----Original Message-----
From: Ronald G. Minnich [mailto:rminnich at lanl.gov] 
Sent: Friday, October 29, 2004 3:39 PM
To: YhLu
Cc: Li-Ta Lo; LinuxBIOS
Subject: RE: FILO fixups



On Fri, 29 Oct 2004, YhLu wrote:

> The filo is merged into Etherboot. And it will be released in 5.2.6
formally
> I guess.

that's a plus and a minus for us. It's nice seeing FILO get pulled into
supported software like Etherboot. But we've had uneven luck building a
working etherboot here. And ETherboot still does far more than we want. 

I would need to put the same kinds of mods into etherboot, and then build 
etherboot in a way in which all the ethernet support is not compiled in. 
In other words, I want to compile an etherboot down to FILO!

It is simpler to just use FILO directly.

ron


From ebiederman at lnxi.com  Fri Oct 29 17:23:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Oct 29 17:23:01 2004
Subject: size status information
In-Reply-To: <Pine.LNX.4.58.0410291440540.13175@linux.site>
References: <3174569B9743D511922F00A0C94314230665B885@TYANWEB>
	<Pine.LNX.4.58.0410291440540.13175@linux.site>
Message-ID: <m3r7nhkut4.fsf_-_@maxwell.lnxi.com>

"Ronald G. Minnich" <rminnich at lanl.gov> writes:

> On Fri, 29 Oct 2004, YhLu wrote:
> 
> > If the ROMCC can handle function not as inline. You may don't need to
> > enlarge the 64K limit.
> > Current Auto.c compiled is some big. Esp the print_debug causes the problem
> 
> yes. 
> 
> The long term solution is to have all vendors set up working cache-as-ram, 
> short term is harder and involves romcc. It would be good if more people 
> could learn romcc innards and help with this difficult problem.

At the moment I would be happy for some bug reports.  That included
a small code sample the reduced problems.  Not that I have heard
of many bugs.

First remember that by turning the down the level of debugging size
can almost always be decreased in LinuxBIOS to a size we can test things
with.

So the things we can to do to keep size down.
1)  Use gcc-3.4 instead of gcc-3.3

    From my experience the Opteron platform has the largest and
    most complex code before memory initialization.  So using
    the arima hdama dual opteron board is a reasonable gauge on how
    large we are.  Building with gcc-3.4 and looking at current cvs
    the status is:

    $ ls -l linuxbios_payload.nrv2b
    rw-r--r--  1 eric eric 28930 Oct 29 16:30 linuxbios_payload.nrv2b

    $ size crt0.o
       text	   data	    bss	    dec	    hex	filename
      36121	      0	      0	  36121	   8d19	crt0.o

    36121 + 28930 = 65051
    65536 - 65051 = 485 

    $ ls -l linuxbios_payload.nrv2b 
    -rw-r--r--  1 eric eric 28393 Oct 29 16:28 linuxbios_payload.nrv2b
    
    $ size crt0.o
       text	   data	    bss	    dec	    hex	filename
      37033	      0	      0	  37033	   90a9	crt0.o

    37033 + 28393 = 65426
    65536 - 65426 = 110

    So even with gcc-3.4 I am running quite tight but it does still build.
    It is interesting that it takes nearly 1KiB for fallback.c

2) Kill unused strings.

3) Expand the space available for linuxbios_c.gz

4) Better tune the current 64bit support for size.  I think the size
   increase of the last few days has something to do with gcc's poor
   handling of 64bit integers.  Perhaps linuxbios_c needs to go native
   64bit on x86-64 capable machines.

5) Get non-inlining working usefully with romcc.

6) cache-as-ram support (long term).

Eric


From ebiederman at lnxi.com  Fri Oct 29 17:31:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Oct 29 17:31:01 2004
Subject: FILO fixups
In-Reply-To: <Pine.LNX.4.58.0410291636470.13175@linux.site>
References: <Pine.LNX.4.58.0410291552300.13175@linux.site>
	<1099087480.12894.86.camel@exponential.lanl.gov>
	<Pine.LNX.4.58.0410291636470.13175@linux.site>
Message-ID: <m3sm7xi1a1.fsf@maxwell.lnxi.com>

"Ronald G. Minnich" <rminnich at lanl.gov> writes:

> On Fri, 29 Oct 2004, Li-Ta Lo wrote:
> 
> > Since it appears nobody is maintaining FILO do you think we should put 
> > it in util directory in freebios2?
> > 
> 
> that's my plan.

Please let's give it's own namespace, just like freebios2 has.
Or at least could we start a util tree for these kinds of things.

I'd like to keep the parts that are independent of the LinuxBIOS
revision  a little separate so if we ever need to do something
like the freebios2 tree again they can happily live again.

Romcc and config.g and one or two other utilities are tightly tied
to the LinuxBIOS revisions so the make a lot of sense.

Eric


From ollie at lanl.gov  Fri Oct 29 17:40:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Fri Oct 29 17:40:00 2004
Subject: FILO fixups
In-Reply-To: <m3sm7xi1a1.fsf@maxwell.lnxi.com>
References: <Pine.LNX.4.58.0410291552300.13175@linux.site>
	 <1099087480.12894.86.camel@exponential.lanl.gov>
	 <Pine.LNX.4.58.0410291636470.13175@linux.site>
	 <m3sm7xi1a1.fsf@maxwell.lnxi.com>
Message-ID: <1099090959.5500.1.camel@exponential.lanl.gov>

On Fri, 2004-10-29 at 16:53, Eric W. Biederman wrote:
> "Ronald G. Minnich" <rminnich at lanl.gov> writes:
> 
> > On Fri, 29 Oct 2004, Li-Ta Lo wrote:
> > 
> > > Since it appears nobody is maintaining FILO do you think we should put 
> > > it in util directory in freebios2?
> > > 
> > 
> > that's my plan.
> 
> Please let's give it's own namespace, just like freebios2 has.
> Or at least could we start a util tree for these kinds of things.
> 
> I'd like to keep the parts that are independent of the LinuxBIOS
> revision  a little separate so if we ever need to do something
> like the freebios2 tree again they can happily live again.
> 
> Romcc and config.g and one or two other utilities are tightly tied
> to the LinuxBIOS revisions so the make a lot of sense.
> 

I think we should move most of the utils into its own util package. The 
config tool should be move to a new directory call "tools" in freebios2.

Ollie




From ebiederman at lnxi.com  Fri Oct 29 18:16:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Oct 29 18:16:01 2004
Subject: status information
In-Reply-To: <Pine.LNX.4.58.0410281751130.11174@linux.site>
References: <20041028115139.GA19778@openbios.org>
	<m3654v9gbn.fsf@maxwell.lnxi.com>
	<Pine.LNX.4.58.0410280813530.7845@linux.site>
	<1098990045.12894.20.camel@exponential.lanl.gov>
	<m3sm7yqwk5.fsf@maxwell.lnxi.com>
	<Pine.LNX.4.58.0410281734270.11174@linux.site>
	<20041028234908.GD2018@tinyvaio.nome.ca>
	<Pine.LNX.4.58.0410281751130.11174@linux.site>
Message-ID: <m3oeilhz7o.fsf@maxwell.lnxi.com>

"Ronald G. Minnich" <rminnich at lanl.gov> writes:

> On Thu, 28 Oct 2004 linuxbios at mikebell.org wrote:
> 
> > -mm only right now, I believe (don't recall it showing up on bkbits).
> > But I seem to recall that Andrew Morton is close to pushing it through
> > to Linus's tree.
> 
> once it's in we're going to stop worrying about kmonte any more :-)
> 
> but kmonte is not the reason we use CF. Driver size of stuff like myrinet 
> and infiniband and quadrics is. Our big clusters only have ethernet on 
> 1/16 of hte nodes. 

To be clear.  The syscall number is reserved in the stable tree.
The -mm tree is the current linux development tree.  So the code is
in.  The ramifications of how to integrate kexec on panic for
crash dumps are currently being worked through.  Once the implications
for implementation are understood kexec and the implementation is good
the code will land in the stable kernel.

So if  there is any feedback that needs to happen before the syscall
interface becomes immutable now is the time to give it.

As for size, the beoboot userland is one of the reasons why you are
still using CF.  But that can be tuned.

Eric


From ebiederman at lnxi.com  Fri Oct 29 20:10:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Oct 29 20:10:01 2004
Subject: status information
In-Reply-To: <Pine.LNX.4.58.0410291150420.13175@linux.site>
References: <3174569B9743D511922F00A0C94314230665B855@TYANWEB>
	<Pine.LNX.4.58.0410291150420.13175@linux.site>
Message-ID: <m3k6t9htx1.fsf@maxwell.lnxi.com>

"Ronald G. Minnich" <rminnich at lanl.gov> writes:

> On Fri, 29 Oct 2004, YhLu wrote:
> 
> > If the kernel can be tailed to (1MByte - LinuxBIOS size(64K *2)), 
> > There is no need for Etherboot or others.
> 
> yes, as a reminder, the very earliest linuxbios machines we did at LANL 
> were L440gx machines with linuxbios and linux in flash. No etherboot, no 
> file, etc. 
> 
> But linux grew a bit ...

The linux-tiny project seems to have gotten the growth under control.

Eric


From ebiederman at lnxi.com  Sat Oct 30 03:16:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Sat Oct 30 03:16:00 2004
Subject: Merge/Cleanup status
In-Reply-To: <m3r7nhkut4.fsf_-_@maxwell.lnxi.com>
References: <3174569B9743D511922F00A0C94314230665B885@TYANWEB>
	<Pine.LNX.4.58.0410291440540.13175@linux.site>
	<m3r7nhkut4.fsf_-_@maxwell.lnxi.com>
Message-ID: <m3lldofvn4.fsf_-_@maxwell.lnxi.com>

I have just committed another big bunch of code and I need to make
one more pass through the tree catch up other boards besides the
hdama to handle what I have introduced.  But things are cleaner more a
little smaller now, but with a little more functionality so I break
even on size.

- To reduce confuse rename the parts of linuxbios bios that run from
  ram linuxbios_ram instead of linuxbios_c and linuxbios_payload...
- Reordered the linker sections so the LinuxBIOS fallback image can take more the 64KiB on x86
- ROM_IMAGE_SIZE now will work when it is specified as larger than 64KiB.
- Tweaked the reset16.inc and reset16.lds to move the sanity check to see if everything will work.
- Start using romcc's built in preprocessor (This will simplify header compiler checks)
- Add helper functions for examining all of the resources
- Remove debug strings from chip.h
- Add llshell to src/arch/i386/llshell (Sometime later I can try it...)
- Add the ability to catch exceptions on x86
- Add gdb_stub support to x86
- Removed old cpu options
- Added an option so we can detect movnti support
- Remove some duplicate definitions from pci_ids.h
- Remove the 64bit resource code in amdk8/northbridge.c in preparation for making it generic
- Minor romcc bug fixes


ebiederman at lnxi.com (Eric W. Biederman) writes:

> So the things we can to do to keep size down.
> 1)  Use gcc-3.4 instead of gcc-3.3
      An updated size comparison for fallback gcc-3.3 vs gcc-3.4 on the arima
      hdama fallback image.

With gcc-3.3 I have:
----------------------------------------------------------------
$ size linuxbios_ram
   text	   data	    bss	    dec	    hex	filename
  40656	  39728	  58956	 139340	  2204c	linuxbios_ram

$ ls -l linuxbios_ram.nvr2b
-rw-r--r--  1 eric eric 28938 Oct 30 02:08 linuxbios_ram.nrv2b

$ ls -l linuxbios_ram.rom 
-rw-r--r--  1 eric eric 28938 Oct 30 02:08 linuxbios_ram.rom

$ size crt0.o
   text	   data	    bss	    dec	    hex	filename
  37033	      0	      0	  37033	   90a9	crt0.o

28938 + 37033 = 65971 or just over 65KiB

With gcc-3.4 I have:
-----------------------------------------------------------------
$ size linuxbios_ram

   text	   data	    bss	    dec	    hex	filename
  40448	  38268	  60652	 139368	  22068	linuxbios_ram

$ ls -l linuxbios_ram.nrv2b
-rw-r--r--  1 eric eric 28317 Oct 30 02:16 linuxbios_ram.nrv2b

$ ls -l linuxbios_ram.rom 
-rw-r--r--  1 eric eric 28317 Oct 30 02:16 linuxbios_ram.rom

$ size crt0.o
   text	   data	    bss	    dec	    hex	filename
  37033	      0	      0	  37033	   90a9	crt0.o

28317 + 37033 = 65350 or just under 65KiB

---------------------------------------------------------------------


So with this comparison I see the following.
28938 - 28317                     = 621 bytes or 2% more for gcc-3.3 in compressed size
(40656 + 39728) - (40448 + 38268) = 1668 bytes or 2% more for gcc-3.3 in uncompressed size

So switching to gcc-3.4 gives a 2% size reduction.  Not huge bug significant.


> 2) Kill unused strings.
     The member is removed from device.h and the dead strings just remain to
     be killed.
 
> 3) Expand the space available for linuxbios_c.gz
     Done.  linuxbios_ram can now occupy more space on x86.
> 
> 4) Better tune the current 64bit support for size.  I think the size
>    increase of the last few days has something to do with gcc's poor
>    handling of 64bit integers.  Perhaps linuxbios_c needs to go native
>    64bit on x86-64 capable machines.

     Some initial tuning has be done in particular some helper functions
     were introduced which noticeably bring the code size down.

> 5) Get non-inlining working usefully with romcc.
     Not really started but I have added functions:
     print_debug_hex8_(unsigned char value);
     print_debug_hex32_(unsigned int value);
     print_debug_(const char *str);

     Into arch/i386/lib/console.c so we can begin to experiment with
     this manually.  Once the manual case works it will be time to
     look at doing this automatically.

     In addition I modified the hdama build to let romcc preprocess
     the files itself without help from gcc.  Since that code works.
     (Well except for unsigned long constant expressions...)

> 6) cache-as-ram support (long term).
     Perhaps llshell.inc will make this easier to debug.
     I have added that into 
     src/arch/i386/llshell.inc for people to play with.

And the list of files I touched this round.

CVS: ----------------------------------------------------------------------
CVS: Enter Log.  Lines beginning with `CVS:' are removed automatically
CVS:
CVS: Committing in .
CVS:
CVS: Modified Files:
CVS:    src/arch/i386/boot/linuxbios_table.c
CVS:    src/arch/i386/init/ldscript.lb src/arch/i386/lib/Config.lb
CVS:    src/arch/i386/lib/c_start.S src/arch/ppc/init/ldscript.lb
CVS:    src/arch/ppc/lib/cpuid.c src/config/Config.lb
CVS:    src/config/Options.lb src/cpu/amd/model_fxx/Config.lb
CVS:    src/cpu/amd/mtrr/amd_mtrr.c src/cpu/amd/socket_940/Config.lb
CVS:    src/cpu/amd/socket_940/socket_940.c
CVS:    src/cpu/intel/model_f0x/Config.lb
CVS:    src/cpu/intel/model_f1x/Config.lb
CVS:    src/cpu/intel/model_f2x/Config.lb
CVS:    src/cpu/intel/model_f3x/Config.lb
CVS:    src/cpu/x86/16bit/entry16.inc src/cpu/x86/16bit/reset16.inc
CVS:    src/cpu/x86/16bit/reset16.lds src/cpu/x86/lapic/secondary.S
CVS:    src/cpu/x86/mtrr/earlymtrr.c src/cpu/x86/mtrr/mtrr.c
CVS:    src/devices/device.c src/devices/device_util.c
CVS:    src/devices/root_device.c src/include/delay.h
CVS:    src/include/device/device.h src/include/device/pci_ids.h
CVS:    src/include/device/resource.h
CVS:    src/mainboard/arima/hdama/Config.lb
CVS:    src/mainboard/arima/hdama/Options.lb
CVS:    src/mainboard/arima/hdama/mainboard.c
CVS:    src/northbridge/amd/amdk8/coherent_ht.c
CVS:    src/northbridge/amd/amdk8/northbridge.c src/ram/ramtest.c
CVS:    src/southbridge/amd/amd8111/amd8111.c
CVS:    src/superio/NSC/pc87360/superio.c
CVS:    targets/arima/hdama/Config.lb util/romcc/romcc.c
CVS: Added Files:
CVS:    src/arch/i386/llshell/llshell.inc
CVS:    src/arch/i386/llshell/readme.linuxbios
CVS:    src/config/linuxbios_ram.ld
CVS: Removed Files:
CVS:    src/config/linuxbios_c.ld
CVS: ----------------------------------------------------------------------


From ebiederman at lnxi.com  Sat Oct 30 03:20:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Sat Oct 30 03:20:01 2004
Subject: FILO fixups
In-Reply-To: <1099090959.5500.1.camel@exponential.lanl.gov>
References: <Pine.LNX.4.58.0410291552300.13175@linux.site>
	<1099087480.12894.86.camel@exponential.lanl.gov>
	<Pine.LNX.4.58.0410291636470.13175@linux.site>
	<m3sm7xi1a1.fsf@maxwell.lnxi.com>
	<1099090959.5500.1.camel@exponential.lanl.gov>
Message-ID: <m3fz3wfvj9.fsf@maxwell.lnxi.com>

Li-Ta Lo <ollie at lanl.gov> writes:

> I think we should move most of the utils into its own util package. The 
> config tool should be move to a new directory call "tools" in freebios2.

Sounds good. tools/utils I don't care, so long as the separate
package has it's own top level directory in cvs.

Eric


From ebiederman at lnxi.com  Sat Oct 30 03:26:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Sat Oct 30 03:26:01 2004
Subject: Starting with linuxbios
In-Reply-To: <BAD357DA-291F-11D9-B3D4-0003931B4D6A@gnat.ca>
References: <41814E81.70403@linuxembarcado.com.br>
	<BAD357DA-291F-11D9-B3D4-0003931B4D6A@gnat.ca>
Message-ID: <m3brekfv74.fsf@maxwell.lnxi.com>

Nathanael Noblet <nathanael at gnat.ca> writes:

> On Oct 28, 2004, at 12:54 PM, Adilson Oliveira wrote:
> 
> > Hello guys.
> >
> > I'm thinking about create (another one) Car-PC and I want to use linuxbios to
> > improve the boot time.
> > Is there any place you can recomend I can read about the basics of this
> > project?
> > I mean how it works, etc? Just to give me an outline before I start to dig
> > into it?
> > BTW, I want to use miniITX boards as the Via EPIA.
> 
> The website is sorely out of date, and the source tree has just gone through a
> *major* overhaul. In that vein, the source for the epia version isn't functional
> (as I understand it right now). But will in a few weeks when it gets cleaned
> up.

I don't think the code is quite that bad.  My impression is that it just
needs an hour or so for someone to swat of the obvious conversion glitches
and to try it.    Of course it would be easier if the final test was
someone who already working epia so they didn't need to worry about pulling
the flash chip if something went wrong.

>  The website will be revamped when some of the volunteers (like myself) get
> to it. We've been really busy as well. I'm not nearly as knowledgeable in the
> arena here about the actual functioning of LinuxBIOS, but there are plenty here
> who are. I would suggest going through the mailing list archive as start. There
> was a great FAQ type submission a few months ago that helped me understand what
> was going on.

Yes.  The mailing seems to be second only to the source code.  At least it stays
fairly uptodate. :)

Eric


From stepan at openbios.org  Sat Oct 30 10:42:00 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Sat Oct 30 10:42:00 2004
Subject: status information
In-Reply-To: <m3wtxaqx83.fsf@maxwell.lnxi.com>
References: <20041028115139.GA19778@openbios.org> <m3654v9gbn.fsf@maxwell.lnxi.com> <Pine.LNX.4.58.0410280813530.7845@linux.site> <m3wtxaqx83.fsf@maxwell.lnxi.com>
Message-ID: <20041030160434.GA5786@openbios.org>

* Eric W. Biederman <ebiederman at lnxi.com> [041029 00:44]:
> > hmm, this sounds like a lot of potential pain for a small gain. Can we 
> > talk about this a bit first. 
> 
> Sure.    First here are two examples.
> struct chip_opertations cpu_intel_socket_mPGA479M_control = {
> 	.name = "socket mPGA479M",
> };
> 
> Killing the name for cpu sockets allows us to kill the whole
> structure.

What was the original intention of the structure? It might be nice to
know how many sockets there are and what CPUs are in those sockets.. 
(ie some dmi kind of information)

> If you like I will trade you gdb stubs for the currently useless
> debugging string names. ;)  I just finished the code for that.
> The conversations of the last couple of days inspired me. :)

Hey.. this sounds cool! 

Stefan



From stepan at openbios.org  Sat Oct 30 12:22:00 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Sat Oct 30 12:22:00 2004
Subject: FILO fixups
In-Reply-To: <m3sm7xi1a1.fsf@maxwell.lnxi.com>
References: <Pine.LNX.4.58.0410291552300.13175@linux.site> <1099087480.12894.86.camel@exponential.lanl.gov> <Pine.LNX.4.58.0410291636470.13175@linux.site> <m3sm7xi1a1.fsf@maxwell.lnxi.com>
Message-ID: <20041030174500.GA9947@openbios.org>

* Eric W. Biederman <ebiederman at lnxi.com> [041030 00:53]:
> Please let's give it's own namespace, just like freebios2 has.
> Or at least could we start a util tree for these kinds of things.
 
That's what the util/extensions was intended for.

Stefan



From ebiederman at lnxi.com  Sat Oct 30 13:30:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Sat Oct 30 13:30:01 2004
Subject: status information
In-Reply-To: <20041030160434.GA5786@openbios.org>
References: <20041028115139.GA19778@openbios.org>
	<m3654v9gbn.fsf@maxwell.lnxi.com>
	<Pine.LNX.4.58.0410280813530.7845@linux.site>
	<m3wtxaqx83.fsf@maxwell.lnxi.com> <20041030160434.GA5786@openbios.org>
Message-ID: <m31xfgm41n.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at openbios.org> writes:

> * Eric W. Biederman <ebiederman at lnxi.com> [041029 00:44]:
> > > hmm, this sounds like a lot of potential pain for a small gain. Can we 
> > > talk about this a bit first. 
> > 
> > Sure.    First here are two examples.
> > struct chip_opertations cpu_intel_socket_mPGA479M_control = {
> > 	.name = "socket mPGA479M",
> > };
> > 
> > Killing the name for cpu sockets allows us to kill the whole
> > structure.
> 
> What was the original intention of the structure? It might be nice to
> know how many sockets there are and what CPUs are in those sockets.. 
> (ie some dmi kind of information)

We still have the cpu information via the device tree. As far as distinguishing
cpus from sockets that is mostly a matter of refinement.

The code is currently structured so you pull in support for which
cpus your socket supports.  Which is the intention of having a socket
directory.

When we started generating device structures directly almost all of
the chip specific logic when away.  But just a tiny bit was left
because there are something things that you do on a chip basis
rather than on a device basis.

struct chip is gone.  struct chip_control was replaced by struct
chip_operations.  Which has now been pruned down to just one
method, at least for now.

> > If you like I will trade you gdb stubs for the currently useless
> > debugging string names. ;)  I just finished the code for that.
> > The conversations of the last couple of days inspired me. :)
> 
> Hey.. this sounds cool! 

Done.  Check it out :)

Eric


From sagivy at 3vium.com  Sun Oct 31 04:17:00 2004
From: sagivy at 3vium.com (Sagiv Yefet)
Date: Sun Oct 31 04:17:00 2004
Subject: Kernel for linuxbios
Message-ID: <4A3D5F6DC9406A4DBE93D9BA8F07E4BB22D6C6@cronos.trivium>

I took your advise and try the 2.6.
I am using the initramfs_data.cpio.gz from the link you send me.

The mkelf command is:

./objdir/sbin/mkelfImage -t bzImage-i386
--kernel=/home/sagivy/bzImage-2.6. 	--command-line="rw
console=ttyS0,115200 root=/dev/ram0"
	--initrd=/home/sagivy/initramfs_data.cpio.gz 
	--output=/home/sagivy/bzImage2.6.8.elf

And here is the output:

Jumping to Linux                
Linux version 2.6.8 (root at hermes) (gcc version 3.3.3) #6 Mon Nov 17
21:49:23 IST

 2003     
BIOS-provided physical RAM map:                               
 BIOS-e820: 0000000000000000 - 0000000000000d54 (rese

 BIOS-e820: 0000000000000d54 - 00000000000a0000 (usable)

 BIOS-e820: 00000000000f0000 - 00000000000f0400 (reserved)

 BIOS-e820: 0000000000100000 - 0000000020000000 (usable)

0MB HIGHMEM available.                      
512MB LOWMEM available.                       
DMI not present.                
ACPI: Unable to locate RSDP                           
Built 1 zonelists                 
Kernel command line: rw console=ttyS0,115200 root=/dev/ram0

Initializing CPU#0                  
PID hash table entries: 4096 (order 12: 32768 bytes)

Detected 1603.740 MHz processor.                                
Using tsc for high-res timesource                                 
Console: colour VGA+ 80x25                          
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)..

Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)    
PCI: Using configuration type 1                          
Memory: 515700k/524288k available (1525k kernel code, 7824k reserved,
702k data, K8 Northbridge                               
Enumerating: AMD K8 CPU          
 228k init, 0k highmem)g: AMD 8111 Southbridge
Checking if this processor honours the WP bit even in supervisor mode...
Ok.               
Enumerating buses...                    
amdk8_scan_root_bus
Calibrating delay loop... 3162.11 BogoMIPSart scaning pci bus

Mount-cache hash table entries: 512 (order: 0, 4096 bytes)

PCI: 00:18.0 [1022/1100] enabled          
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)

PCI: 00:18.2 [1022/1102] enabled           
CPU: L2 Cache: 1024K (64 bytes/line)022/1103] ops                       
Enabling fast FPU save and restore... done.

HyperT rese
Enabling unmasked SIMD FPU exception support... done.for bus 1

PCI: 01:01.0 [10
Checking 'hlt' instruction... OK.              
PCI: 01:01.0 [1022
checking if image is initramfs... it is      
PCI: 01:02.0 [1022/7468] bus ops
Freeing initrd memory: 151k freedCI: 01:02.0 [1022/7468] enabled  
NET: Registered protocol family 16 01:02.1 [1022/7469] ops          
EISA bus registeredCI: 01:02.1 [1022/7
PCI: Using configuration type 1            
PCI: 01:02.2 [1022
mtrr: v2.0 (20020519)                     
Linux Plug and Play Support v0.97 (c) Adam Belay           
PCI: 01:02.3 [1022/746b] enabled    
PCI: Probing PCI hardware  
PCI: 01:02.5 [1022/746
PCI: IRQ 0 for device 0000:02:00.0 doesn't match PIRQ mask - try
pci=usepirqmask7463] ops                            
PCI: 02:00.2 [1022/7463] disabled         

PCI: IRQ 0 for device 0000:02:00.1 doesn't match PIRQ mask - try
pci=usepirqmaskPCI: 02:01.0 [1022/7462] disabled

PCI: 02:0a.0 

PCI: IRQ 0 for device 0000:02:0a.0 doesn't match PIRQ mask - try
pci=usepirqmask                          
PCI: 02:0b.0 [1002/4752] enabled                     

PCI: IRQ 0 for device 0000:02:0b.0 doesn't match PIRQ m

PCI: 02:0e.0 [14e                
PNP: 002e.7 disabled           
apm: BIOS not found. disabled           
VFS: Disk quotas dquot_6.5.1d                    
PNP: 0
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)              
scan_static_bus done                    
PC
isapnp: Scanning for PnP cards...=02                              
isapnp: No Plug & Play device found 0 new max: 2                      
Real Time Clock Driver v1.12ort scan link done          
Serial: 8250/16550 driver $Revision: 1.90 $ 48 ports, IRQ sharing
enabled    
PCI: pci_scan_bus returning with max=02                             
ttyS0 at I/O 0x3f8 (irq = bus:                    
AMD8111: not 100% native mode: will probe irqs later
AMD8111: 0000:01:02.1 (rev 03) UDMA133 controller
    ide0: BM-DMA at 0x2420-0x2427, BIOS settings: hda:pio, hdb:pio
    ide1: BM-DMA at 0x2428-0x242f, BIOS settings: hdc:pio, hdd:pio
ide-floppy driver 0.99.newide
mice: PS/2 mouse device common for all mice
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
EISA: Probing bus 0 at eisa0
NET: Registered protocol family 2
IP: routing cache hash table of 4096 buckets, 32Kbytes
TCP: Hash tables configured (established 131072 bind 65536)
NET: Registered protocol family 1
NET: Registered protocol family 17
NET: Registered protocol family 8
NET: Registered protocol family 20
Freeing unused kernel memory: 228k freed
Kernel panic: Attempted to kill init!
================ ==================
    This kernel uses initramfs
==================================
Unknown root filesystem type!

Sagiv.

-----Original Message-----
From: Dave Aubin [mailto:daubin at actuality-systems.com] 
Sent: Wednesday, October 13, 2004 2:47 PM
To: Sagiv Yefet; Stefan Reinauer
Cc: linuxbios at clustermatic.org
Subject: RE: Kernel for linuxbios

Sorry for the late response.  Are you using
Linux 2.6.*.  If so give initramfs a try.
Here is a link to aid you in how:

http://linuxfromscratch.org/pipermail/lfs-hackers/2004-June/001424.html

Dave
 

-----Original Message-----
From: linuxbios-admin at clustermatic.org
[mailto:linuxbios-admin at clustermatic.org] On Behalf Of Sagiv Yefet
Sent: Wednesday, October 13, 2004 8:10 AM
To: Stefan Reinauer
Cc: linuxbios at clustermatic.org
Subject: RE: Kernel for linuxbios

I tried to use initrd - same problem.

Sagiv 

-----Original Message-----
From: Stefan Reinauer [mailto:stepan at openbios.org]
Sent: Monday, October 11, 2004 11:21 AM
To: Sagiv Yefet
Cc: linuxbios at clustermatic.org
Subject: Re: Kernel for linuxbios

* Sagiv Yefet <sagivy at 3vium.com> [041011 11:06]:
> 
> I add the console support and there is output. Thanks.
> 
> My machine has no disks and I need initrd. So I took initrd from 
> Thinstation and build the elf file by the command :
> 
> RAMDISK: Couldn't find valid RAM disk image starting at 0.
> Freeing initrd memory: 11922k freed
> Kernel panic: VFS: Unable to mount root fs on 01:00
 
use initrd, not ramdisk!

Stefan


_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios




From yhlu at tyan.com  Sun Oct 31 10:58:00 2004
From: yhlu at tyan.com (Yinghai Lu)
Date: Sun Oct 31 10:58:00 2004
Subject: Merge/Cleanup status
In-Reply-To: <m3lldofvn4.fsf_-_@maxwell.lnxi.com>
Message-ID: <200410311557.i9VFvIL12759@nwn.definitive.org>

1. Using ROMCC to do propresser will help the size reduction?
2. what is usage for MOVNTI? It is for GDB....
3. How to use GDB to debug LinuxBIOS? Is it only for linuxbios_ram?
4. You will use llshell for crt0.s or auto.c debug?
5. Current romcc only take constant parameters for non inline function? It
that right?
6. Anyone has tried to compile LinuxBIOS under Suse 9.1?  what's the
recommended platform for LinuxBIOS compliation? It seems Suse 9.1 can not
compile Etherboot properly. I am always using RH9 to do the work. And just
found I can not compile LB for S2885, (size>65536), but I can do it in Suse
9.1 pro.

Regards

YH

-----Original Message-----
From: Eric W. Biederman [mailto:eric at lnxi.com] On Behalf Of Eric W.
Biederman
Sent: Saturday, October 30, 2004 1:39 AM
To: LinuxBIOS
Cc: Ronald G. Minnich; YhLu; Richard Smith; ollie at lanl.gov; Stefan Reinauer
Subject: Merge/Cleanup status


I have just committed another big bunch of code and I need to make
one more pass through the tree catch up other boards besides the
hdama to handle what I have introduced.  But things are cleaner more a
little smaller now, but with a little more functionality so I break
even on size.

- To reduce confuse rename the parts of linuxbios bios that run from
  ram linuxbios_ram instead of linuxbios_c and linuxbios_payload...
- Reordered the linker sections so the LinuxBIOS fallback image can take
more the 64KiB on x86
- ROM_IMAGE_SIZE now will work when it is specified as larger than 64KiB.
- Tweaked the reset16.inc and reset16.lds to move the sanity check to see if
everything will work.
- Start using romcc's built in preprocessor (This will simplify header
compiler checks)
- Add helper functions for examining all of the resources
- Remove debug strings from chip.h
- Add llshell to src/arch/i386/llshell (Sometime later I can try it...)
- Add the ability to catch exceptions on x86
- Add gdb_stub support to x86
- Removed old cpu options
- Added an option so we can detect movnti support
- Remove some duplicate definitions from pci_ids.h
- Remove the 64bit resource code in amdk8/northbridge.c in preparation for
making it generic
- Minor romcc bug fixes


ebiederman at lnxi.com (Eric W. Biederman) writes:

> So the things we can to do to keep size down.
> 1)  Use gcc-3.4 instead of gcc-3.3
      An updated size comparison for fallback gcc-3.3 vs gcc-3.4 on the
arima
      hdama fallback image.

With gcc-3.3 I have:
----------------------------------------------------------------
$ size linuxbios_ram
   text	   data	    bss	    dec	    hex	filename
  40656	  39728	  58956	 139340	  2204c	linuxbios_ram

$ ls -l linuxbios_ram.nvr2b
-rw-r--r--  1 eric eric 28938 Oct 30 02:08 linuxbios_ram.nrv2b

$ ls -l linuxbios_ram.rom 
-rw-r--r--  1 eric eric 28938 Oct 30 02:08 linuxbios_ram.rom

$ size crt0.o
   text	   data	    bss	    dec	    hex	filename
  37033	      0	      0	  37033	   90a9	crt0.o

28938 + 37033 = 65971 or just over 65KiB

With gcc-3.4 I have:
-----------------------------------------------------------------
$ size linuxbios_ram

   text	   data	    bss	    dec	    hex	filename
  40448	  38268	  60652	 139368	  22068	linuxbios_ram

$ ls -l linuxbios_ram.nrv2b
-rw-r--r--  1 eric eric 28317 Oct 30 02:16 linuxbios_ram.nrv2b

$ ls -l linuxbios_ram.rom 
-rw-r--r--  1 eric eric 28317 Oct 30 02:16 linuxbios_ram.rom

$ size crt0.o
   text	   data	    bss	    dec	    hex	filename
  37033	      0	      0	  37033	   90a9	crt0.o

28317 + 37033 = 65350 or just under 65KiB

---------------------------------------------------------------------


So with this comparison I see the following.
28938 - 28317                     = 621 bytes or 2% more for gcc-3.3 in
compressed size
(40656 + 39728) - (40448 + 38268) = 1668 bytes or 2% more for gcc-3.3 in
uncompressed size

So switching to gcc-3.4 gives a 2% size reduction.  Not huge bug
significant.


> 2) Kill unused strings.
     The member is removed from device.h and the dead strings just remain to
     be killed.
 
> 3) Expand the space available for linuxbios_c.gz
     Done.  linuxbios_ram can now occupy more space on x86.
> 
> 4) Better tune the current 64bit support for size.  I think the size
>    increase of the last few days has something to do with gcc's poor
>    handling of 64bit integers.  Perhaps linuxbios_c needs to go native
>    64bit on x86-64 capable machines.

     Some initial tuning has be done in particular some helper functions
     were introduced which noticeably bring the code size down.

> 5) Get non-inlining working usefully with romcc.
     Not really started but I have added functions:
     print_debug_hex8_(unsigned char value);
     print_debug_hex32_(unsigned int value);
     print_debug_(const char *str);

     Into arch/i386/lib/console.c so we can begin to experiment with
     this manually.  Once the manual case works it will be time to
     look at doing this automatically.

     In addition I modified the hdama build to let romcc preprocess
     the files itself without help from gcc.  Since that code works.
     (Well except for unsigned long constant expressions...)

> 6) cache-as-ram support (long term).
     Perhaps llshell.inc will make this easier to debug.
     I have added that into 
     src/arch/i386/llshell.inc for people to play with.

And the list of files I touched this round.

CVS: ----------------------------------------------------------------------
CVS: Enter Log.  Lines beginning with `CVS:' are removed automatically
CVS:
CVS: Committing in .
CVS:
CVS: Modified Files:
CVS:    src/arch/i386/boot/linuxbios_table.c
CVS:    src/arch/i386/init/ldscript.lb src/arch/i386/lib/Config.lb
CVS:    src/arch/i386/lib/c_start.S src/arch/ppc/init/ldscript.lb
CVS:    src/arch/ppc/lib/cpuid.c src/config/Config.lb
CVS:    src/config/Options.lb src/cpu/amd/model_fxx/Config.lb
CVS:    src/cpu/amd/mtrr/amd_mtrr.c src/cpu/amd/socket_940/Config.lb
CVS:    src/cpu/amd/socket_940/socket_940.c
CVS:    src/cpu/intel/model_f0x/Config.lb
CVS:    src/cpu/intel/model_f1x/Config.lb
CVS:    src/cpu/intel/model_f2x/Config.lb
CVS:    src/cpu/intel/model_f3x/Config.lb
CVS:    src/cpu/x86/16bit/entry16.inc src/cpu/x86/16bit/reset16.inc
CVS:    src/cpu/x86/16bit/reset16.lds src/cpu/x86/lapic/secondary.S
CVS:    src/cpu/x86/mtrr/earlymtrr.c src/cpu/x86/mtrr/mtrr.c
CVS:    src/devices/device.c src/devices/device_util.c
CVS:    src/devices/root_device.c src/include/delay.h
CVS:    src/include/device/device.h src/include/device/pci_ids.h
CVS:    src/include/device/resource.h
CVS:    src/mainboard/arima/hdama/Config.lb
CVS:    src/mainboard/arima/hdama/Options.lb
CVS:    src/mainboard/arima/hdama/mainboard.c
CVS:    src/northbridge/amd/amdk8/coherent_ht.c
CVS:    src/northbridge/amd/amdk8/northbridge.c src/ram/ramtest.c
CVS:    src/southbridge/amd/amd8111/amd8111.c
CVS:    src/superio/NSC/pc87360/superio.c
CVS:    targets/arima/hdama/Config.lb util/romcc/romcc.c
CVS: Added Files:
CVS:    src/arch/i386/llshell/llshell.inc
CVS:    src/arch/i386/llshell/readme.linuxbios
CVS:    src/config/linuxbios_ram.ld
CVS: Removed Files:
CVS:    src/config/linuxbios_c.ld
CVS: ----------------------------------------------------------------------



From ebiederman at lnxi.com  Sun Oct 31 11:43:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Sun Oct 31 11:43:01 2004
Subject: Merge/Cleanup status
In-Reply-To: <20041031172055.73105D000090@spam.llix.net>
References: <20041031172055.73105D000090@spam.llix.net>
Message-ID: <m34qka225u.fsf@maxwell.lnxi.com>

"Yinghai Lu" <yhlu at tyan.com> writes:

> 1. Using ROMCC to do propresser will help the size reduction?

Not directly.  But it does cleanup the header files and increase
the exposure to romcc.  There are a small handful of things
this make more maintainable.

> 2. what is usage for MOVNTI? It is for GDB....

Look at ramtest.c.  movnti is a non-teporal move (bypasses the cache).
In some cases it can noticeably increase store performance.  Last
I measured in the cases it mattered it increased store performance
by 3X.

> 3. How to use GDB to debug LinuxBIOS? Is it only for linuxbios_ram?
Correct.  Either an exception must be taken or a call to gdb_stub_breakpoint()
needs to be made.  At that point LinuxBIOS will stop and wait for
the debugger.  Assuming CONFIG_GDB_STUB is compiled in.  For details
on the gdb side, read up on the gdb remote serial protocol.

I'm not really a fan, I am still more productive with printf
debugging.  But implement ion exception handling support is a general
win.  And the support was easy to add.

> 4. You will use llshell for crt0.s or auto.c debug?

That is the idea.  Again I added it because it is available.  It would
not be hard to call out to it with an appropriate asm directive. 
If people find llshell useful.  

> 5. Current romcc only take constant parameters for non inline function? It
> that right?

There is something weird going on that affects the generated code, so
things don't work as smoothly as they should.

That said in theory function can be non-inline.

> 6. Anyone has tried to compile LinuxBIOS under Suse 9.1?  what's the
> recommended platform for LinuxBIOS compliation? It seems Suse 9.1 can not
> compile Etherboot properly. I am always using RH9 to do the work. And just
> found I can not compile LB for S2885, (size>65536), but I can do it in Suse
> 9.1 pro.

The goal is to have LinuxBIOS compiling as many places as possible.
As for recommendations we can call out specific revisions of the
tool chain that are known good but I won't call out distros.  

Size wise I know gcc-3.4 is about 2% better than gcc-3.3.

Interesting.  On the purely size issue you can bump ROM_IMAGE_SIZE a
little and see if it the build works.

As for etherboot I don't know what your compile failure is.  So I
don't know how to diagnose that.

Eric


From ginlin at nexcom.com.tw  Sun Oct 31 18:56:00 2004
From: ginlin at nexcom.com.tw (Gin)
Date: Sun Oct 31 18:56:00 2004
Subject: PXE support
In-Reply-To: <1098980769.12894.6.camel@exponential.lanl.gov>
Message-ID: <000201c4bfb0$cec0d5f0$8e04010a@nexcom.com.tw>

Hello,
It seems like linuxbios supports PXE. Can anyone tell me how it works if
you have experience with it? Thanks

Gin



From yhlu at tyan.com  Sun Oct 31 22:29:00 2004
From: yhlu at tyan.com (Yinghai Lu)
Date: Sun Oct 31 22:29:00 2004
Subject: Merge/Cleanup status
In-Reply-To: <m34qka225u.fsf@maxwell.lnxi.com>
Message-ID: <200411010328.iA13SHL14908@nwn.definitive.org>

> I'm not really a fan, I am still more productive with printf debugging.  

Yes, also post code to port 80 is useful before the console is setup.

Regards

YH