[LinuxBIOS] New version of ROM posting app

[Jon Smirl]

I put two new posting apps, a vm86 version and emu86 version out on:
bk://mesa3d.bkbits.net/rom

Get klibc from:
http://kernel.org/pub/linux/libs/klibc/

Install it somewhere and build it. You need to make a link to the
kernel source in the top level klibc directory. In this directory make
a link from the klibc-xxx directory to klibc.

Both projects will then build.
v86bios uses vm86 to run the rom
post uses emu86

Use an environment variable to pick the card to be acted on:
export DEVPATH=/bus/pci/devices/0000:01:00.0

vm86 is 20K non-debug
emu86 is 40K non-debug

Currently they don't use Ben's VGA arbiter which isn't ready yet. When
finished these app will automatically be triggered on driver load as
part of the hotplug process.

The source to vm86 is from the linux BIOS project where is has been
worked on to make it substantially smaller. I like to keep everyone on
the same source code base if possible.

Once we get these cleaned up and working I'm hoping to get them added
to the klibc project. Once in klibc, klibc is schedule to go into the
kernel sooner or later.

They are both partially working but fail part way through the posting
process. I've been playing with them a couple of days and I can't
figure out why they are failing. They are both failing for different
reasons. Can anyone help?

[Gregg C Levine]

Hello from Gregg C Levine
While I appreciate the offer of the application, as I am eager to test
nearly everything new for the primary Linux BIOS project, I have one
or two questions.

Question One, Is this the same emu86, that is a project on BerliOS?
It's at http://emu86.berlios.de Also where is this vm86 available?

Question Two, I have bitkeeper installed, and it can reach itself,
that is the company's site. But how can I retrieve the code stored at
bk://mesa3d.bkbits.net/rom? I try feeding the string to bk command,
and I get an odd command back.

Has anyone on the list used bitkeeper before, other then yourself? I
am afraid I am more use to CVS, then BK.
-------------------
Gregg C Levine [e-mail]
------------------------------------------------------------
"The Force will be with you...Always." Obi-Wan Kenobi
"Use the Force, Luke."  Obi-Wan Kenobi
> -----Original Message-----
> From: [e-mail]

[mailto:[e-mail]]
> On Behalf Of Jon Smirl
> Sent: Saturday, March 26, 2005 2:36 PM
> To: Jesse Barnes; Kendall Bennett; Benjamin Herrenschmidt;
> [e-mail]
> Subject: [LinuxBIOS] New version of ROM posting app
>
> I put two new posting apps, a vm86 version and emu86 version out on:
> bk://mesa3d.bkbits.net/rom
>
> Get klibc from:
> http://kernel.org/pub/linux/libs/klibc/
>
> Install it somewhere and build it. You need to make a link to the
> kernel source in the top level klibc directory. In this directory

make
> a link from the klibc-xxx directory to klibc.
>
> Both projects will then build.
> v86bios uses vm86 to run the rom
> post uses emu86
>
> Use an environment variable to pick the card to be acted on:
> export DEVPATH=/bus/pci/devices/0000:01:00.0
>
> vm86 is 20K non-debug
> emu86 is 40K non-debug
>
> Currently they don't use Ben's VGA arbiter which isn't ready yet.

When
> finished these app will automatically be triggered on driver load as
> part of the hotplug process.
>
> The source to vm86 is from the linux BIOS project where is has been
> worked on to make it substantially smaller. I like to keep everyone

on
> the same source code base if possible.
>
> Once we get these cleaned up and working I'm hoping to get them

added
> to the klibc project. Once in klibc, klibc is schedule to go into

the
> kernel sooner or later.
>
> They are both partially working but fail part way through the

posting
> process. I've been playing with them a couple of days and I can't
> figure out why they are failing. They are both failing for different
> reasons. Can anyone help?
>
> LinuxBIOS mailing list
> [e-mail]
> http://www.openbios.org/mailman/listinfo/linuxbios

[Jon Smirl]

On Sat, 26 Mar 2005 20:03:40 -0500, Gregg C Levine
 wrote:
> Hello from Gregg C Levine
> While I appreciate the offer of the application, as I am eager to test
> nearly everything new for the primary Linux BIOS project, I have one
> or two questions.
>
> Question One, Is this the same emu86, that is a project on BerliOS?
> It's at http://emu86.berlios.de Also where is this vm86 available?

It is the emu86 that is contained in the linusbios project.
linuxbios/src/devices/emulator

There are about 100 variations on emu86 floating around.
> Question Two, I have bitkeeper installed, and it can reach itself,
> that is the company's site. But how can I retrieve the code stored at
> bk://mesa3d.bkbits.net/rom? I try feeding the string to bk command,
> and I get an odd command back.

bk clone bk://mesa3d.bkbits.net/rom target_dir
> Has anyone on the list used bitkeeper before, other then yourself? I
> am afraid I am more use to CVS, then BK.

The Linux kernel is developed using bitkeeper.  Instead of copying
kernel images from kernel.org you can use this to keep up to date with
the latest changes.

bk clone  bk://linux.bkbits.net/linux-2.5 target_dir

After you have the initial tree down, to get updates
cd target_dir
bk pull

You can get bitkeeper here:
http://www.bitkeeper.com/Products.BK_Pro.Downloads.html
It is a free download.

[Patrick Mauritz]

Am Samstag, den 26.03.2005, 20:16 -0500 schrieb Jon Smirl:
> You can get bitkeeper here:
> http://www.bitkeeper.com/Products.BK_Pro.Downloads.html
> It is a free download.

free as in "you may download it, but never ever mess with us, compete
with us - while we define what our competition is, or even think about
complaining about problems (or mcvoy might send some nastygrams your way
- at least that part of the deal is not a legal issue)"

a client-only bk tool, which might just be enough under a different
license (BSD-L iirc, though they were talking/joking about a "no whining
license") was released about a week ago at
http://www.bitkeeper.com/press/2005-03-17.html

patrick mauritz

[Jon Smirl]

On Sun, 27 Mar 2005 08:44:46 +0200, Patrick Mauritz
 wrote:
> Am Samstag, den 26.03.2005, 20:16 -0500 schrieb Jon Smirl:
> > You can get bitkeeper here:
> > http://www.bitkeeper.com/Products.BK_Pro.Downloads.html
> > It is a free download.
>
> free as in "you may download it, but never ever mess with us, compete
> with us - while we define what our competition is, or even think about
> complaining about problems (or mcvoy might send some nastygrams your way
> at least that part of the deal is not a legal issue)"
>
> a client-only bk tool, which might just be enough under a different
> license (BSD-L iirc, though they were talking/joking about a "no whining
> license") was released about a week ago at
> http://www.bitkeeper.com/press/2005-03-17.html

If bitkeeper is really a problem send me an email and I will send you
a tar ball.

[Gregg C Levine]

Hello from Gregg C Levine
First off all, thank you for the BK advice. That was what I was
missing. I actually didn't think that the clone command applied to
everything that BK is used for, just for themselves. (Don't ask why!)

However, the next question is which version of the library are you
using? I chose the most recent, and before that: I chose version 0.198
as well, but it is failing with the included headers from the Linux
kernel, I'll post a copy of the script blurb here:
strip --strip-all -R .comment -R .note shared/ipconfig
ar cru libipconfig.a main.o netdev.o packet.o bootp_proto.o
dhcp_proto.o
make[1]: Leaving directory `/usr/src/klibc-0.198/ipconfig'
make[1]: Entering directory `/usr/src/klibc-0.198/nfsmount'
gcc -Wp,-MD,./.main.o.d -mregparm=3 -DREGPARM=3 -march=i386 -Os -g
-falign-functions=0 -falign-jumps=0 -falign-loops=0  -nostdinc
-iwithprefix include -D__KLIBC__ -DBITSIZE=32 -I../include/arch/i386
-I../include/bits32 -I../include -I../linux/include
-I../linux/include2 -I../linux/include -Wstrict-prototypes -Wall -I.
-c -o main.o main.c
In file included from main.c:16:
../linux/include/linux/nfs_mount.h:26: error: field `old_root' has
incomplete type
../linux/include/linux/nfs_mount.h:40: error: field `root' has
incomplete type
make[1]: *** [main.o] Error 1
make[1]: Leaving directory `/usr/src/klibc-0.198/nfsmount'
make: *** [all] Error 2

Ironically the release before that one, 0.190 gets through everything,
but crashes to a halt inside the ash directory. And 0.181 builds the
library, but complains about some trivial data, or a trivial error.

Whereas the currently stable release 1.0 gets all of the way through
building stuff until it reaches this point:
cp -f shared/ipconfig shared.g
strip --strip-all -R .comment -R .note shared/ipconfig
ar cru libipconfig.a main.o netdev.o packet.o bootp_proto.o
dhcp_proto.o
make[1]: Leaving directory `/usr/src/klibc-1.0/ipconfig'
make[1]: Entering directory `/usr/src/klibc-1.0/nfsmount'
gcc -Wp,-MD,./.main.o.d -march=i386 -Os -g -fomit-frame-pointer
-falign-functions=0 -falign-jumps=0 -falign-loops=0 -m32 -nostdinc
-iwithprefix include -D__KLIBC__ -I../include/arch/i386
-I../include/bits32 -I../include -I../linux/include
-I../linux/include2 -I../linux/include -mregparm=3 -D_REGPARM=3
-Wstrict-prototypes -Wall -I. -c -o main.o main.c
In file included from main.c:16:
../linux/include/linux/nfs_mount.h:26: error: field `old_root' has
incomplete type
../linux/include/linux/nfs_mount.h:40: error: field `root' has
incomplete type
make[1]: *** [main.o] Error 1
make[1]: Leaving directory `/usr/src/klibc-1.0/nfsmount'
make: *** [all] Error 2

-----
All of this is being built using the tools with Slackware-10.1, binary
utilities are at 2..19 and the gcc release version 3.3.4. Also the
kernel is at 2.4.29.

If you would like to know why I chose the Slackware distribution, it's
because I have found that one to be relatively easy to use for setting
up new systems, including work stations, and servers.

What is strange is why the two versions have the exactly the same
errors. Do you think I should send those two complaints to the list
which covers the activities of the library?
-------------------
Gregg C Levine [e-mail]
------------------------------------------------------------
"The Force will be with you...Always." Obi-Wan Kenobi
"Use the Force, Luke."  Obi-Wan Kenobi
> -----Original Message-----
> From: Jon Smirl [mailto:[e-mail]]
> Sent: Saturday, March 26, 2005 8:16 PM
> To: Gregg C Levine
> Cc: [e-mail]
> Subject: Re: [LinuxBIOS] New version of ROM posting app
>
> On Sat, 26 Mar 2005 20:03:40 -0500, Gregg C Levine
>  wrote:
> > Hello from Gregg C Levine
> > While I appreciate the offer of the application, as I am eager to

test
> > nearly everything new for the primary Linux BIOS project, I have

one
> > or two questions.
> >
> > Question One, Is this the same emu86, that is a project on

BerliOS?
> > It's at http://emu86.berlios.de Also where is this vm86 available?
>
> It is the emu86 that is contained in the linusbios project.
> linuxbios/src/devices/emulator
>
> There are about 100 variations on emu86 floating around.
> > Question Two, I have bitkeeper installed, and it can reach itself,
> > that is the company's site. But how can I retrieve the code stored

at
> > bk://mesa3d.bkbits.net/rom? I try feeding the string to bk

command,
> > and I get an odd command back.
>
> bk clone bk://mesa3d.bkbits.net/rom target_dir
> > Has anyone on the list used bitkeeper before, other then yourself?

I
> > am afraid I am more use to CVS, then BK.
>
> The Linux kernel is developed using bitkeeper.  Instead of copying
> kernel images from kernel.org you can use this to keep up to date

with
> the latest changes.
>
> bk clone  bk://linux.bkbits.net/linux-2.5 target_dir
>
> After you have the initial tree down, to get updates
> cd target_dir
> bk pull
>
> You can get bitkeeper here:
> http://www.bitkeeper.com/Products.BK_Pro.Downloads.html
> It is a free download.

[Jon Smirl]

On Sun, 27 Mar 2005 12:58:44 -0500, Gregg C Levine > All of this is
being built using the tools with Slackware-10.1, binary
> utilities are at 2..19 and the gcc release version 3.3.4. Also the
> kernel is at 2.4.29.

klibc and the rom reset program are both targeted at the 2.6 kernel.
The rom program requires a recent 2.6 kernel to work.

I'm not sure if klib supports the 2.4 kernel. klib is very closely
tied to the kernel source.

2.4 is in maintenance mode. All new development is being done on 2.6.

I don't use slackware but one most distributions you can do:
bk clone bk://linux.bkbits.net/linux-2.5 target_dir
set up your config
make
make installl

Then when you boot you can choose what kernel to use.

[Jon Smirl]

Also, I know the reset program doesn't work. I need some help figuring
out why it doesn't work.  It is failing on all the video cards I have.

After about the fifth INT 1A it exits and doesn't complete the reset.

[Jon Smirl]

Also, I know the reset program doesn't work. I need some help figuring
out why it doesn't work.  It is failing on all the video cards I have.

After about the fifth INT 1A it exits and doesn't complete the reset.

There are three primary applications for the program:
1) using an x86 board in a non-x86 machine
2) display wall systems where the host machine may have 16 video boards in it.
3) Multihead X using multiple cards

[Li-Ta Lo]

On Sat, 2005-03-26 at 14:36 -0500, Jon Smirl wrote:
> Currently they don't use Ben's VGA arbiter which isn't ready yet. When
> finished these app will automatically be triggered on driver load as
> part of the hotplug process.
>
> The source to vm86 is from the linux BIOS project where is has been
> worked on to make it substantially smaller. I like to keep everyone on
> the same source code base if possible.
>
> Once we get these cleaned up and working I'm hoping to get them added
> to the klibc project. Once in klibc, klibc is schedule to go into the
> kernel sooner or later.
>
> They are both partially working but fail part way through the posting
> process. I've been playing with them a couple of days and I can't
> figure out why they are failing. They are both failing for different
> reasons. Can anyone help?

Which version of x86emu are you using? The larger one from XF86 or the 
reduced version from Paulo?

I didn't follow the discussion on LKML about integrating the emulator,
what was the conclusion. Got O.K. from Linus?

[Jon Smirl]

On Sat, 26 Mar 2005 23:15:08 -0700, Li-Ta Lo  wrote:
> On Sat, 2005-03-26 at 14:36 -0500, Jon Smirl wrote:
> > Currently they don't use Ben's VGA arbiter which isn't ready yet. When
> > finished these app will automatically be triggered on driver load as
> > part of the hotplug process.
> >
> > The source to vm86 is from the linux BIOS project where is has been
> > worked on to make it substantially smaller. I like to keep everyone on
> > the same source code base if possible.
> >
> > Once we get these cleaned up and working I'm hoping to get them added
> > to the klibc project. Once in klibc, klibc is schedule to go into the
> > kernel sooner or later.
> >
> > They are both partially working but fail part way through the posting
> > process. I've been playing with them a couple of days and I can't
> > figure out why they are failing. They are both failing for different
> > reasons. Can anyone help?
>
> Which version of x86emu are you using? The larger one from XF86 or the
> reduced version from Paulo?

The one from linux BIOS cvs:
linuxbios/src/devices/emulator/x86emu
> I didn't follow the discussion on LKML about integrating the emulator,
> what was the conclusion. Got O.K. from Linus?

The emulator is going to run in user space. When the driver loads it
uses a hotplug event to trigger the posting app.

Linux is being changed currently to support early user space. Early
user space is active as soon as it is feasible. It runs things from
initramfs. The video driver and the reset program will be on the
initramfs. When the hardware is detected the driver will be loaded.
The driver will then trigger hotplug which will cause the reset. This
will occur as early in the boot process as possible. Much earlier than
current user space.

Klibc is the C library for initramfs. The plan is to integrate it into
the kernel tree even though it runs in user space. The reset app would
then go into that part of the tree.

Many other parts of the kernel are being moved to this model where
large piece of the driver run in user space. Another example is iSCSI
support.

Note that the reset program needs to run on a recent kernel. Check
/sys/bus/pci/devices/0000:01:00.0/rom and make sure it is there. If
not you need a more recent kernel.
>

[Li-Ta Lo]

On Sun, 2005-03-27 at 02:15 -0500, Jon Smirl wrote:
> On Sat, 26 Mar 2005 23:15:08 -0700, Li-Ta Lo  wrote:
> > On Sat, 2005-03-26 at 14:36 -0500, Jon Smirl wrote:
> > > Currently they don't use Ben's VGA arbiter which isn't ready yet. When
> > > finished these app will automatically be triggered on driver load as
> > > part of the hotplug process.
> > >
> > > The source to vm86 is from the linux BIOS project where is has been
> > > worked on to make it substantially smaller. I like to keep everyone on
> > > the same source code base if possible.
> > >
> > > Once we get these cleaned up and working I'm hoping to get them added
> > > to the klibc project. Once in klibc, klibc is schedule to go into the
> > > kernel sooner or later.
> > >
> > > They are both partially working but fail part way through the posting
> > > process. I've been playing with them a couple of days and I can't
> > > figure out why they are failing. They are both failing for different
> > > reasons. Can anyone help?
> >
> > Which version of x86emu are you using? The larger one from XF86 or the
> > reduced version from Paulo?
>
> The one from linux BIOS cvs:
> linuxbios/src/devices/emulator/x86emu

Actually, the code on the LinuxBIOS cvs may be the reduced version by 
Paulo, depending on when you check it out. Paulo's version has some
bug such that it may fail to init the hardware. I did commited some
fix to the CVS I got from him. But there are some fixed not commited
dur to the CVS -> TLA transition.
> > I didn't follow the discussion on LKML about integrating the emulator,
> > what was the conclusion. Got O.K. from Linus?
>
> The emulator is going to run in user space. When the driver loads it
> uses a hotplug event to trigger the posting app.
>
> Linux is being changed currently to support early user space. Early
> user space is active as soon as it is feasible. It runs things from
> initramfs. The video driver and the reset program will be on the
> initramfs. When the hardware is detected the driver will be loaded.
> The driver will then trigger hotplug which will cause the reset. This
> will occur as early in the boot process as possible. Much earlier than
> current user space.
>
> Klibc is the C library for initramfs. The plan is to integrate it into
> the kernel tree even though it runs in user space. The reset app would
> then go into that part of the tree.
>
> Many other parts of the kernel are being moved to this model where
> large piece of the driver run in user space. Another example is iSCSI
> support.
>
> Note that the reset program needs to run on a recent kernel. Check
> /sys/bus/pci/devices/0000:01:00.0/rom and make sure it is there. If
> not you need a more recent kernel.

How recent should that be? 2.6.11?

Did you try to link the emulator with GLIBC than klibc? Do they have the
same behavior?

Ollie

[Jon Smirl]

On Mon, 28 Mar 2005 11:05:08 -0700, Li-Ta Lo  wrote:
> > > Which version of x86emu are you using? The larger one from XF86 or the
> > > reduced version from Paulo?
> >
> > The one from linux BIOS cvs:
> > linuxbios/src/devices/emulator/x86emu
>
> Actually, the code on the LinuxBIOS cvs may be the reduced version by
> Paulo, depending on when you check it out. Paulo's version has some
> bug such that it may fail to init the hardware. I did commited some
> fix to the CVS I got from him. But there are some fixed not commited
> dur to the CVS -> TLA transition.

What I used is in the current CVS repository:
:pserver:[e-mail]:/cvsroot/freebios
> > Note that the reset program needs to run on a recent kernel. Check
> > /sys/bus/pci/devices/0000:01:00.0/rom and make sure it is there. If
> > not you need a more recent kernel.
>
> How recent should that be? 2.6.11?

2.6.11 is fine. I think it went in around 2.6.9.
> Did you try to link the emulator with GLIBC than klibc? Do they have the
> same behavior?

I haven't tried the emulator with glibc vs klibc. But I have tried
several other programs against both without problem. Problems with
klibc are usually in the form of not being able to compile against it.
Actual bugs in the code are pretty rare now.
> Ollie

[Paulo Marques]

Jon Smirl wrote:
> On Mon, 28 Mar 2005 11:05:08 -0700, Li-Ta Lo  wrote:
> > > > Which version of x86emu are you using? The larger one from XF86 or the
> > > > reduced version from Paulo?
> > >
> > > The one from linux BIOS cvs:
> > > linuxbios/src/devices/emulator/x86emu
> >
> > Actually, the code on the LinuxBIOS cvs may be the reduced version by
> > Paulo, depending on when you check it out. Paulo's version has some
> > bug such that it may fail to init the hardware. I did commited some
> > fix to the CVS I got from him. But there are some fixed not commited
> > dur to the CVS -> TLA transition.
>
> What I used is in the current CVS repository:
> :pserver:[e-mail]:/cvsroot/freebios

I just went there to check out the versions.

The version in "freebios" is the large version whereas the version in 
"freebios2" is the reduced version.

The large version still has the "#define xorl(a,b)   ((a) && !(b)) || 
(!(a) && (b))" bug in line 100 in ops2.c. This macro needs an extra 
parenthesis to avoid priority issues.

The reduced version, on top of this bug, still has the XCHG AX,BX bug. 
To fix it manually, edit line 2230 in ops.c and change:

M.x86.R_EAX = *reg16;

to

M.x86.R_AX = *reg16;

This bug cleared the top 16 bits of EAX when doing a XCHG AX,BX 
instruction. In the BIOS Ollie tested with, this produced a division by 
zero later in the code.

It also has the "write destination on CMP" bug.

I can send a proper patch against this version to fix all this, but if 
the version in the arch repository is already updated, then there is no 
need for it.

[Li-Ta Lo]

On Mon, 2005-03-28 at 19:44 +0100, Paulo Marques wrote:
> Jon Smirl wrote:
> > On Mon, 28 Mar 2005 11:05:08 -0700, Li-Ta Lo  wrote:
> > > > > Which version of x86emu are you using? The larger one from XF86 or the
> > > > > reduced version from Paulo?
> > > >
> > > > The one from linux BIOS cvs:
> > > > linuxbios/src/devices/emulator/x86emu
> > >
> > > Actually, the code on the LinuxBIOS cvs may be the reduced version by
> > > Paulo, depending on when you check it out. Paulo's version has some
> > > bug such that it may fail to init the hardware. I did commited some
> > > fix to the CVS I got from him. But there are some fixed not commited
> > > dur to the CVS -> TLA transition.
> >
> > What I used is in the current CVS repository:
> > :pserver:[e-mail]:/cvsroot/freebios
>
> I just went there to check out the versions.

Can you go to

http://www.openbios.org/cgi-bin/viewarch.cgi

to check the version in the TLA ?

[Jon Smirl]

On Mon, 28 Mar 2005 15:28:20 -0700, Li-Ta Lo  wrote:
> Can you go to
>
> http://www.openbios.org/cgi-bin/viewarch.cgi
>
> to check the version in the TLA ?

Different output but same failure. This looks like a problem with the
BIOS emulation not with the emu86.

[Li-Ta Lo]

On Mon, 2005-03-28 at 17:57 -0500, Jon Smirl wrote:
> On Mon, 28 Mar 2005 15:28:20 -0700, Li-Ta Lo  wrote:
> > Can you go to
> >
> > http://www.openbios.org/cgi-bin/viewarch.cgi
> >
> > to check the version in the TLA ?
>
> Different output but same failure. This looks like a problem with the
> BIOS emulation not with the emu86.

Paulo,

Can you send him (and me) your most updated version?
The message

updating int vector 0x0
    c000:00a3: 63 ILLEGAL X86 OPCODE!
    halt_sys: file ops.c, line 93

means the emulator is have a NULL pointer reference.

BTW, what vga cards are you using?

[Jon Smirl]

On Mon, 28 Mar 2005 16:14:54 -0700, Li-Ta Lo  wrote:
> On Mon, 2005-03-28 at 17:57 -0500, Jon Smirl wrote:
> > On Mon, 28 Mar 2005 15:28:20 -0700, Li-Ta Lo  wrote:
> > > Can you go to
> > >
> > > http://www.openbios.org/cgi-bin/viewarch.cgi
> > >
> > > to check the version in the TLA ?
> >
> > Different output but same failure. This looks like a problem with the
> > BIOS emulation not with the emu86.
>
> Paulo,
>
> Can you send him (and me) your most updated version?
> The message
>     updating int vector 0x0
>     c000:00a3: 63 ILLEGAL X86 OPCODE!
>     halt_sys: file ops.c, line 93
>
> means the emulator is have a NULL pointer reference.
>
> BTW, what vga cards are you using?

ATI Radeon 9000
ATI Rage128
S3 based one

They are all failing.
>

[Li-Ta Lo]

On Mon, 2005-03-28 at 18:29 -0500, Jon Smirl wrote:
> On Mon, 28 Mar 2005 16:14:54 -0700, Li-Ta Lo  wrote:
> > On Mon, 2005-03-28 at 17:57 -0500, Jon Smirl wrote:
> > > On Mon, 28 Mar 2005 15:28:20 -0700, Li-Ta Lo  wrote:
> > > > Can you go to
> > > >
> > > > http://www.openbios.org/cgi-bin/viewarch.cgi
> > > >
> > > > to check the version in the TLA ?
> > >
> > > Different output but same failure. This looks like a problem with the
> > > BIOS emulation not with the emu86.
> >
> > Paulo,
> >
> > Can you send him (and me) your most updated version?
> > The message
> >     updating int vector 0x0
> >     c000:00a3: 63 ILLEGAL X86 OPCODE!
> >     halt_sys: file ops.c, line 93
> >
> > means the emulator is have a NULL pointer reference.
> >
> > BTW, what vga cards are you using?
>
> ATI Radeon 9000
> ATI Rage128
> S3 based one

I always had problem with those old S3 cards. Can you try some recent 
Nvidia cards?

[Jon Smirl]

On Mon, 28 Mar 2005 16:14:54 -0700, Li-Ta Lo  wrote:
> On Mon, 2005-03-28 at 17:57 -0500, Jon Smirl wrote:
> > On Mon, 28 Mar 2005 15:28:20 -0700, Li-Ta Lo  wrote:
> > > Can you go to
> > >
> > > http://www.openbios.org/cgi-bin/viewarch.cgi
> > >
> > > to check the version in the TLA ?
> >
> > Different output but same failure. This looks like a problem with the
> > BIOS emulation not with the emu86.
>
> Paulo,
>
> Can you send him (and me) your most updated version?
> The message
>     updating int vector 0x0
>     c000:00a3: 63 ILLEGAL X86 OPCODE!
>     halt_sys: file ops.c, line 93
>
> means the emulator is have a NULL pointer reference.
>
> BTW, what vga cards are you using?

ATI Radeon 9000
ATI Rage128
S3 based one

They are all failing.
>

[Paulo Marques]

Li-Ta Lo wrote:
> On Mon, 2005-03-28 at 19:44 +0100, Paulo Marques wrote:
> > Jon Smirl wrote:
> > > On Mon, 28 Mar 2005 11:05:08 -0700, Li-Ta Lo  wrote:
> > > > > > Which version of x86emu are you using? The larger one from XF86 or the
> > > > > > reduced version from Paulo?
> > > > >
> > > > > The one from linux BIOS cvs:
> > > > > linuxbios/src/devices/emulator/x86emu
> > > >
> > > > Actually, the code on the LinuxBIOS cvs may be the reduced version by
> > > > Paulo, depending on when you check it out. Paulo's version has some
> > > > bug such that it may fail to init the hardware. I did commited some
> > > > fix to the CVS I got from him. But there are some fixed not commited
> > > > dur to the CVS -> TLA transition.
> > >
> > > What I used is in the current CVS repository:
> > > :pserver:[e-mail]:/cvsroot/freebios
> >
> > I just went there to check out the versions.
>
> Can you go to
>
> http://www.openbios.org/cgi-bin/viewarch.cgi
>
> to check the version in the TLA ?

The version there is the large version and it still has the "#define 
xorl" bug in ops2.c...

[Stefan Reinauer]

* Paulo Marques  [050329 13:33]:
> > to check the version in the TLA ?
>
> The version there is the large version and it still has the "#define 
> xorl" bug in ops2.c...

There's the other one in the
[e-mail]--devel/freebios--devel--2.0 tree, not sure if
that is what Ollie meant.

[Paulo Marques]

Li-Ta Lo wrote:
> [...]
> > > What I used is in the current CVS repository:
> > > :pserver:[e-mail]:/cvsroot/freebios
> >
> > I just went there to check out the versions.
>
> Can you go to
>
> http://www.openbios.org/cgi-bin/viewarch.cgi
>
> to check the version in the TLA ?

Oops, if I go to:

freebios->devel->2.0->patch-13 -> util/vgabios/x86emu/src/x86emu

the version there is the reduced one, but still has the nasty "XCHG 
AX,BX" bug (and the "destination written on CMP" bug too).

Ollie, can you explain to Jon how to make the kind of logs you produced 
to test the reduced version? If he could send me a log of the problem it 
would be much easier to try to track it down.

Anyway, attached is my latest source (only the .c files). These can be 
replaced over a reduced version. I think that only ops.c, ops2.c and 
prim_ops.c have differences from any other reduced version out there.

I believe there is still a lot of room for code size reduction in there, 
but we must agree on two issues before I start improving on the code again:

- where is the "official" repository?

- does the reduced version behave like the large version, and if this 
is the case, can we make the reduced version the current official one?

A few more logs from different boards to test with the log tester might 
help us settle this last question. Having more logs will also help me 
develop more on the emulator and be able to test against known working 
versions to make sure there are no regressions.

As for the repository, I really don't care where it is, as long there is 
one official one instead of 3 or 4 like we have now. Even more, if you 
think is ok for me to hack on the emulator and then just send the new 
version to the linuxbios mailing list and to Kendall, so that whoever 
wants it might update their repositories, that is fine by me, also.

[Richard Smith]

> but we must agree on two issues before I start improving on the code again:
> where is the "official" repository?

linubios just cut over from sourceforge CVS to TLA on openbios.org. 
CVS is deprecated should now be read only.  So the "official" tree is
whats in TLA.

http://wiki.linuxbios.org/index.php/Download_freebios_v2

Has all the details.  Note if you find any details that are incorrect
let us know as we are still getting the transfer fully worked out.

[Jon Smirl]

On Mon, 28 Mar 2005 11:05:08 -0700, Li-Ta Lo  wrote:

I get the same result from all three test versions you sent.

running file ../bios.fil
No size specified. defaulting to 32k
No base specified. defaulting to 0xc0000
No initial code segment specified. defaulting to 0xc000
No initial instruction pointer specified. defaulting to 0x0003
updating int vector 0x1a
updating int vector 0x1a
updating int vector 0x1a
int1a vector at 0
eax=0x9 ecx=0xde01 eflags=0x44
updating int vector 0x0
c000:00a3: 63 ILLEGAL X86 OPCODE!
halt_sys: file ops.c, line 93
halted

Here is a trace from an old vm86 program that works:
Maybe INT15 isn't hooked up in yours?

PCI says configuration type 1
PCI probing configuration type 1

Probing for devices on PCI bus 0:
bus: 0 card: 0 func 0 reg0: 0x25788086 bc 0x6, sub 0x0, if 0x0, hdr 0x0
bus: 0 card: 1 func 0 reg0: 0x25798086 bc 0x6, sub 0x4, if 0x0, hdr 0x1
Pci-Pci Bridge found; primary: 0x0 secondary: 0x1
bus: 0 card: 29 func 0 reg0: 0x24d28086 bc 0xc, sub 0x3, if 0x0, hdr 0x80
bus: 0 card: 29 func 1 reg0: 0x24d48086 bc 0xc, sub 0x3, if 0x0, hdr 0x0
bus: 0 card: 29 func 2 reg0: 0x24d78086 bc 0xc, sub 0x3, if 0x0, hdr 0x0
bus: 0 card: 29 func 3 reg0: 0x24de8086 bc 0xc, sub 0x3, if 0x0, hdr 0x0
bus: 0 card: 30 func 0 reg0: 0x244e8086 bc 0x6, sub 0x4, if 0x0, hdr 0x1
Pci-Pci Bridge found; primary: 0x0 secondary: 0x2
bus: 0 card: 31 func 0 reg0: 0x24d08086 bc 0x6, sub 0x1, if 0x0, hdr 0x80
bus: 0 card: 31 func 1 reg0: 0x24db8086 bc 0x1, sub 0x1, if 0x8a, hdr 0x0
bus: 0 card: 31 func 2 reg0: 0x24d18086 bc 0x1, sub 0x1, if 0x8f, hdr 0x0
bus: 0 card: 31 func 3 reg0: 0x24d38086 bc 0xc, sub 0x5, if 0x0, hdr 0x0

Probing for devices on PCI bus 1:
bus: 1 card: 0 func 0 reg0: 0x49661002 bc 0x3, sub 0x0, if 0x0, hdr 0x80
Display found
bus: 1 card: 0 func 1 reg0: 0x496e1002 bc 0x3, sub 0x80, if 0x0, hdr 0x0
Display found

Probing for devices on PCI bus 2:
bus: 2 card: 0 func 0 reg0: 0x165314e4 bc 0x2, sub 0x0, if 0x0, hdr 0x0
bus: 2 card: 2 func 0 reg0: 0x8019104c bc 0xc, sub 0x0, if 0x10, hdr 0x0
bus: 2 card: 3 func 0 reg0: 0x50441002 bc 0x3, sub 0x0, if 0x0, hdr 0x0
Display found
bus: 2 card: 12 func 0 reg0: 0x100e8086 bc 0x2, sub 0x0, if 0x0, hdr 0x0
Max buses in system: 3
Min PCI mem address: 0x20020200
writing: 0x80000 to 0x8000083c
writing: 0x2b00083 to 0x80010004
writing: 0xfea00001 to 0x80010030
ax: 0x100
RomBase: 0xfea00000
writing: 0xfea00001 to 0x80010030
data segment in BIOS: 0x164, type: 0x0 BIOS length: 0xd000
writing: 0xfea00000 to 0x80010030
int 0x1a received: ax:0xb109
int 0x1a: ax=0xb109 bx=0x100 cx=0x0 dx=0x0 di=0x14
Slot=0x80010000
reading: 0xde01 from 0x80010014
ax=0x9 cx=0xde01 flags=0xb0246
int 0x15 received: ax:0x4e08
int 0x42 received: ax:0x7
int 0x42: ax:0x7 bx:0x200 cx:0x0 dx:0x3c2
int 0x6d received: ax:0x3
calling card BIOS at: 0xc000:1ea0
int 0x6d received: ax:0x3
calling card BIOS at: 0xc000:1ea0
int 0x6d received: ax:0x1301
calling card BIOS at: 0xc000:1ea0
int 0x1a received: ax:0xb102
int 0x1a: ax=0xb102 bx=0x7 cx=0x691 dx=0x1106 di=0x6b60
ax=0x8602 bx=0x7 flags=0x30047
int 0x1a received: ax:0xb102
int 0x1a: ax=0xb102 bx=0x7 cx=0x305 dx=0x1106 di=0x6b60
ax=0x8602 bx=0x7 flags=0x30247
int 0x1a received: ax:0xb109
int 0x1a: ax=0xb109 bx=0x0 cx=0x0 dx=0x0 di=0x0
Slot=0x80010000
ax=0x8709 cx=0x0 flags=0x30247
writing: 0x80000 to 0x8000083c
writing: 0x2b00087 to 0x80010104
writing: 0x1 to 0x80010130
ax: 0x101
writing: 0xffffffff to 0x80010130
reading: 0x0 from 0x80010130
bios size: 0x0
writing: 0x0 to 0x80010130
biosSize: 0x0
reading: 0xf4000008 from 0x80010010
writing: 0xffffffff to 0x80010010
reading: 0xfc000008 from 0x80010010
writing: 0xf4000008 to 0x80010010
size: 0x4000000
RomBase: 0xf4000000
writing: 0xf4000001 to 0x80010130
writing: 0x0 to 0x80010130
int 0x42 received: ax:0x7
int 0x42: ax:0x7 bx:0x7be cx:0x900 dx:0x3c2
int 0x6d received: ax:0x3
calling card BIOS at: 0xc000:13a6
int 0x6d received: ax:0x1301
calling card BIOS at: 0xc000:13a6
writing: 0xa0000 to 0x8000f03c
writing: 0x2900083 to 0x80021804
writing: 0xfe800001 to 0x80021830
ax: 0x218
RomBase: 0xfe800000
writing: 0xfe800001 to 0x80021830
data segment in BIOS: 0x16c, type: 0x0 BIOS length: 0xc000
writing: 0xfe800000 to 0x80021830
int 0x1a received: ax:0xb109
int 0x1a: ax=0xb109 bx=0x218 cx=0x0 dx=0x0 di=0x14
Slot=0x80021800
reading: 0xce01 from 0x80021814
ax=0x9 cx=0xce01 flags=0xb0246
int 0x42 received: ax:0x7
int 0x42: ax:0x7 bx:0x990 cx:0x200 dx:0x3c2
int 0x6d received: ax:0x3
calling card BIOS at: 0xc000:13a6
int 0x10 received: ax:0x4f02
int 0x10: ax:0x4f02 bx:0x100 cx:0x205 dx:0xce12
calling card BIOS at: 0xc000:13a6
int 0x10 received: ax:0x3
int 0x10: ax:0x3 bx:0x8d18 cx:0x3c00000 dx:0xce59
calling card BIOS at: 0xc000:13a6
int 0x6d received: ax:0x1301
calling card BIOS at: 0xc000:13a6
writing: 0xa0000 to 0x8000f03c
writing: 0x0 to 0x8000083c
writing: 0x2b00080 to 0x80010004
writing: 0xfea00000 to 0x80010030
writing: 0x2b00087 to 0x80010104
writing: 0x0 to 0x80010130
writing: 0x2900083 to 0x80021804
writing: 0xfe800000 to 0x80021830

[Jon Smirl]

On Mon, 28 Mar 2005 11:05:08 -0700, Li-Ta Lo  wrote:

I get the same result from all three test versions you sent.

running file ../bios.fil
No size specified. defaulting to 32k
No base specified. defaulting to 0xc0000
No initial code segment specified. defaulting to 0xc000
No initial instruction pointer specified. defaulting to 0x0003
updating int vector 0x1a
updating int vector 0x1a
updating int vector 0x1a
int1a vector at 0
eax=0x9 ecx=0xde01 eflags=0x44
updating int vector 0x0
c000:00a3: 63 ILLEGAL X86 OPCODE!
halt_sys: file ops.c, line 93
halted

Here is a trace from an old vm86 program that works:
Maybe INT15 isn't hooked up in yours?

PCI says configuration type 1
PCI probing configuration type 1

Probing for devices on PCI bus 0:
bus: 0 card: 0 func 0 reg0: 0x25788086 bc 0x6, sub 0x0, if 0x0, hdr 0x0
bus: 0 card: 1 func 0 reg0: 0x25798086 bc 0x6, sub 0x4, if 0x0, hdr 0x1
Pci-Pci Bridge found; primary: 0x0 secondary: 0x1
bus: 0 card: 29 func 0 reg0: 0x24d28086 bc 0xc, sub 0x3, if 0x0, hdr 0x80
bus: 0 card: 29 func 1 reg0: 0x24d48086 bc 0xc, sub 0x3, if 0x0, hdr 0x0
bus: 0 card: 29 func 2 reg0: 0x24d78086 bc 0xc, sub 0x3, if 0x0, hdr 0x0
bus: 0 card: 29 func 3 reg0: 0x24de8086 bc 0xc, sub 0x3, if 0x0, hdr 0x0
bus: 0 card: 30 func 0 reg0: 0x244e8086 bc 0x6, sub 0x4, if 0x0, hdr 0x1
Pci-Pci Bridge found; primary: 0x0 secondary: 0x2
bus: 0 card: 31 func 0 reg0: 0x24d08086 bc 0x6, sub 0x1, if 0x0, hdr 0x80
bus: 0 card: 31 func 1 reg0: 0x24db8086 bc 0x1, sub 0x1, if 0x8a, hdr 0x0
bus: 0 card: 31 func 2 reg0: 0x24d18086 bc 0x1, sub 0x1, if 0x8f, hdr 0x0
bus: 0 card: 31 func 3 reg0: 0x24d38086 bc 0xc, sub 0x5, if 0x0, hdr 0x0

Probing for devices on PCI bus 1:
bus: 1 card: 0 func 0 reg0: 0x49661002 bc 0x3, sub 0x0, if 0x0, hdr 0x80
Display found
bus: 1 card: 0 func 1 reg0: 0x496e1002 bc 0x3, sub 0x80, if 0x0, hdr 0x0
Display found

Probing for devices on PCI bus 2:
bus: 2 card: 0 func 0 reg0: 0x165314e4 bc 0x2, sub 0x0, if 0x0, hdr 0x0
bus: 2 card: 2 func 0 reg0: 0x8019104c bc 0xc, sub 0x0, if 0x10, hdr 0x0
bus: 2 card: 3 func 0 reg0: 0x50441002 bc 0x3, sub 0x0, if 0x0, hdr 0x0
Display found
bus: 2 card: 12 func 0 reg0: 0x100e8086 bc 0x2, sub 0x0, if 0x0, hdr 0x0
Max buses in system: 3
Min PCI mem address: 0x20020200
writing: 0x80000 to 0x8000083c
writing: 0x2b00083 to 0x80010004
writing: 0xfea00001 to 0x80010030
ax: 0x100
RomBase: 0xfea00000
writing: 0xfea00001 to 0x80010030
data segment in BIOS: 0x164, type: 0x0 BIOS length: 0xd000
writing: 0xfea00000 to 0x80010030
int 0x1a received: ax:0xb109
int 0x1a: ax=0xb109 bx=0x100 cx=0x0 dx=0x0 di=0x14
Slot=0x80010000
reading: 0xde01 from 0x80010014
ax=0x9 cx=0xde01 flags=0xb0246
int 0x15 received: ax:0x4e08
int 0x42 received: ax:0x7
int 0x42: ax:0x7 bx:0x200 cx:0x0 dx:0x3c2
int 0x6d received: ax:0x3
calling card BIOS at: 0xc000:1ea0
int 0x6d received: ax:0x3
calling card BIOS at: 0xc000:1ea0
int 0x6d received: ax:0x1301
calling card BIOS at: 0xc000:1ea0
int 0x1a received: ax:0xb102
int 0x1a: ax=0xb102 bx=0x7 cx=0x691 dx=0x1106 di=0x6b60
ax=0x8602 bx=0x7 flags=0x30047
int 0x1a received: ax:0xb102
int 0x1a: ax=0xb102 bx=0x7 cx=0x305 dx=0x1106 di=0x6b60
ax=0x8602 bx=0x7 flags=0x30247
int 0x1a received: ax:0xb109
int 0x1a: ax=0xb109 bx=0x0 cx=0x0 dx=0x0 di=0x0
Slot=0x80010000
ax=0x8709 cx=0x0 flags=0x30247
writing: 0x80000 to 0x8000083c
writing: 0x2b00087 to 0x80010104
writing: 0x1 to 0x80010130
ax: 0x101
writing: 0xffffffff to 0x80010130
reading: 0x0 from 0x80010130
bios size: 0x0
writing: 0x0 to 0x80010130
biosSize: 0x0
reading: 0xf4000008 from 0x80010010
writing: 0xffffffff to 0x80010010
reading: 0xfc000008 from 0x80010010
writing: 0xf4000008 to 0x80010010
size: 0x4000000
RomBase: 0xf4000000
writing: 0xf4000001 to 0x80010130
writing: 0x0 to 0x80010130
int 0x42 received: ax:0x7
int 0x42: ax:0x7 bx:0x7be cx:0x900 dx:0x3c2
int 0x6d received: ax:0x3
calling card BIOS at: 0xc000:13a6
int 0x6d received: ax:0x1301
calling card BIOS at: 0xc000:13a6
writing: 0xa0000 to 0x8000f03c
writing: 0x2900083 to 0x80021804
writing: 0xfe800001 to 0x80021830
ax: 0x218
RomBase: 0xfe800000
writing: 0xfe800001 to 0x80021830
data segment in BIOS: 0x16c, type: 0x0 BIOS length: 0xc000
writing: 0xfe800000 to 0x80021830
int 0x1a received: ax:0xb109
int 0x1a: ax=0xb109 bx=0x218 cx=0x0 dx=0x0 di=0x14
Slot=0x80021800
reading: 0xce01 from 0x80021814
ax=0x9 cx=0xce01 flags=0xb0246
int 0x42 received: ax:0x7
int 0x42: ax:0x7 bx:0x990 cx:0x200 dx:0x3c2
int 0x6d received: ax:0x3
calling card BIOS at: 0xc000:13a6
int 0x10 received: ax:0x4f02
int 0x10: ax:0x4f02 bx:0x100 cx:0x205 dx:0xce12
calling card BIOS at: 0xc000:13a6
int 0x10 received: ax:0x3
int 0x10: ax:0x3 bx:0x8d18 cx:0x3c00000 dx:0xce59
calling card BIOS at: 0xc000:13a6
int 0x6d received: ax:0x1301
calling card BIOS at: 0xc000:13a6
writing: 0xa0000 to 0x8000f03c
writing: 0x0 to 0x8000083c
writing: 0x2b00080 to 0x80010004
writing: 0xfea00000 to 0x80010030
writing: 0x2b00087 to 0x80010104
writing: 0x0 to 0x80010130
writing: 0x2900083 to 0x80021804
writing: 0xfe800000 to 0x80021830

[LinuxBIOS] Re: New version of ROM posting app

[Jon Smirl]

On Sat, 26 Mar 2005 14:36:22 -0500, Jon Smirl  wrote:
> I put two new posting apps, a vm86 version and emu86 version out on:
> bk://mesa3d.bkbits.net/rom

Still doesn't work but I am making progress. I had forgotten that my
user space program needs to route VGA until the kernel support is
there. I've added VGA routing support temporarily.

[Gregg C Levine]

Hello (again) from Gregg C Levine
Jon, is your BK repository offline? Early this morning I needed to
resynch my cloned posting with yours, following your excellent
instructions, (CF. Also on March 26, 2005), and I received a
"Connection timed out error" message.

However, the same thing happens with regards to the clone made
following the instructions from the company, so I'm thinking its my
ISP acting up.

When you get a chance can you create a tar file of your ROM posting
app? If you want to send it to me as an FTP transfer, rather then as
an attachment, I've got an FTP server running here, it can accept
uploads. Write me off list with the details you'll need, and I'll do
the same.
-------------------
Gregg C Levine [e-mail]
------------------------------------------------------------
"The Force will be with you...Always." Obi-Wan Kenobi
"Use the Force, Luke."  Obi-Wan Kenobi
> -----Original Message-----
> From: [e-mail]

[mailto:[e-mail]]
> On Behalf Of Jon Smirl
> Sent: Saturday, March 26, 2005 2:36 PM
> To: Jesse Barnes; Kendall Bennett; Benjamin Herrenschmidt;
> [e-mail]
> Subject: [LinuxBIOS] New version of ROM posting app
>
> I put two new posting apps, a vm86 version and emu86 version out on:
> bk://mesa3d.bkbits.net/rom
>
> Get klibc from:
> http://kernel.org/pub/linux/libs/klibc/
>
> Install it somewhere and build it. You need to make a link to the
> kernel source in the top level klibc directory. In this directory

make
> a link from the klibc-xxx directory to klibc.
>
> Both projects will then build.
> v86bios uses vm86 to run the rom
> post uses emu86
>
> Use an environment variable to pick the card to be acted on:
> export DEVPATH=/bus/pci/devices/0000:01:00.0
>
> vm86 is 20K non-debug
> emu86 is 40K non-debug
>
> Currently they don't use Ben's VGA arbiter which isn't ready yet.

When
> finished these app will automatically be triggered on driver load as
> part of the hotplug process.
>
> The source to vm86 is from the linux BIOS project where is has been
> worked on to make it substantially smaller. I like to keep everyone

on
> the same source code base if possible.
>
> Once we get these cleaned up and working I'm hoping to get them

added
> to the klibc project. Once in klibc, klibc is schedule to go into

the
> kernel sooner or later.
>
> They are both partially working but fail part way through the

posting
> process. I've been playing with them a couple of days and I can't
> figure out why they are failing. They are both failing for different
> reasons. Can anyone help?
>
> LinuxBIOS mailing list
> [e-mail]
> http://www.openbios.org/mailman/listinfo/linuxbios

[Jon Smirl]

bkbits.net is offline probably due to the spat between ODSL and
Bitmover.  I think some people are mad and keep taking it down.

I will have to move it to a sourceforge cvs project. I'll post after
it is moved.

On 4/13/05, Gregg C Levine  wrote:
> Hello (again) from Gregg C Levine
> Jon, is your BK repository offline? Early this morning I needed to
> resynch my cloned posting with yours, following your excellent
> instructions, (CF. Also on March 26, 2005), and I received a
> "Connection timed out error" message.
>
> However, the same thing happens with regards to the clone made
> following the instructions from the company, so I'm thinking its my
> ISP acting up.
>
> When you get a chance can you create a tar file of your ROM posting
> app? If you want to send it to me as an FTP transfer, rather then as
> an attachment, I've got an FTP server running here, it can accept
> uploads. Write me off list with the details you'll need, and I'll do
> the same.
> Gregg C Levine [e-mail]
>
> "The Force will be with you...Always." Obi-Wan Kenobi
> "Use the Force, Luke." Obi-Wan Kenobi
> > -----Original Message-----
> > From: [e-mail]
>
> [mailto:[e-mail]]
> > On Behalf Of Jon Smirl
> > Sent: Saturday, March 26, 2005 2:36 PM
> > To: Jesse Barnes; Kendall Bennett; Benjamin Herrenschmidt;
> > [e-mail]
> > Subject: [LinuxBIOS] New version of ROM posting app
> >
> > I put two new posting apps, a vm86 version and emu86 version out on:
> > bk://mesa3d.bkbits.net/rom
> >
> > Get klibc from:
> > http://kernel.org/pub/linux/libs/klibc/
> >
> > Install it somewhere and build it. You need to make a link to the
> > kernel source in the top level klibc directory. In this directory
>
> make
> > a link from the klibc-xxx directory to klibc.
> >
> > Both projects will then build.
> > v86bios uses vm86 to run the rom
> > post uses emu86
> >
> > Use an environment variable to pick the card to be acted on:
> > export DEVPATH=/bus/pci/devices/0000:01:00.0
> >
> > vm86 is 20K non-debug
> > emu86 is 40K non-debug
> >
> > Currently they don't use Ben's VGA arbiter which isn't ready yet.
>
> When
> > finished these app will automatically be triggered on driver load as
> > part of the hotplug process.
> >
> > The source to vm86 is from the linux BIOS project where is has been
> > worked on to make it substantially smaller. I like to keep everyone
>
> on
> > the same source code base if possible.
> >
> > Once we get these cleaned up and working I'm hoping to get them
>
> added
> > to the klibc project. Once in klibc, klibc is schedule to go into
>
> the
> > kernel sooner or later.
> >
> > They are both partially working but fail part way through the
>
> posting
> > process. I've been playing with them a couple of days and I can't
> > figure out why they are failing. They are both failing for different
> > reasons. Can anyone help?
> >
> > LinuxBIOS mailing list
> > [e-mail]
> > http://www.openbios.org/mailman/listinfo/linuxbios

[Gregg C Levine]

Hello from Gregg C Levine
Jon, this time the command worked. I was able to have my BitKeeper
client clone your applications to my local directory. I was even able
to build them correctly.

Which was the purpose of my original message. For some reason
yesterday, I was not able to build them correctly, and decided to
repeat the processes.

I strongly suggest you should copy the contents to an CVS server
someplace, especially since we don't know when the next outage is
planned for bkbits.net, it could be later today, or tomorrow, or not
at all.
-------------------
Gregg C Levine [e-mail]
------------------------------------------------------------
"The Force will be with you...Always." Obi-Wan Kenobi
"Use the Force, Luke."  Obi-Wan Kenobi
> -----Original Message-----
> From: [e-mail]

[mailto:[e-mail]]
> On Behalf Of Jon Smirl
> Sent: Wednesday, April 13, 2005 1:47 PM
> To: Gregg C Levine
> Cc: [e-mail]
> Subject: Re: [LinuxBIOS] New version of ROM posting app
>
> bkbits.net is offline probably due to the spat between ODSL and
> Bitmover.  I think some people are mad and keep taking it down.
>
> I will have to move it to a sourceforge cvs project. I'll post after
> it is moved.
>
> On 4/13/05, Gregg C Levine  wrote:
> > Hello (again) from Gregg C Levine
> > Jon, is your BK repository offline? Early this morning I needed to
> > resynch my cloned posting with yours, following your excellent
> > instructions, (CF. Also on March 26, 2005), and I received a
> > "Connection timed out error" message.
> >
> > However, the same thing happens with regards to the clone made
> > following the instructions from the company, so I'm thinking its

my
> > ISP acting up.
> >
> > When you get a chance can you create a tar file of your ROM

posting
> > app? If you want to send it to me as an FTP transfer, rather then

as
> > an attachment, I've got an FTP server running here, it can accept
> > uploads. Write me off list with the details you'll need, and I'll

do
> > the same.
> > Gregg C Levine [e-mail]
> >
> > "The Force will be with you...Always." Obi-Wan Kenobi
> > "Use the Force, Luke." Obi-Wan Kenobi
> > > -----Original Message-----
> > > From: [e-mail]
> >
> > [mailto:[e-mail]]
> > > On Behalf Of Jon Smirl
> > > Sent: Saturday, March 26, 2005 2:36 PM
> > > To: Jesse Barnes; Kendall Bennett; Benjamin Herrenschmidt;
> > > [e-mail]
> > > Subject: [LinuxBIOS] New version of ROM posting app
> > >
> > > I put two new posting apps, a vm86 version and emu86 version out

on:
> > > bk://mesa3d.bkbits.net/rom
> > >
> > > Get klibc from:
> > > http://kernel.org/pub/linux/libs/klibc/
> > >
> > > Install it somewhere and build it. You need to make a link to

the
> > > kernel source in the top level klibc directory. In this

directory
> > make
> > > a link from the klibc-xxx directory to klibc.
> > >
> > > Both projects will then build.
> > > v86bios uses vm86 to run the rom
> > > post uses emu86
> > >
> > > Use an environment variable to pick the card to be acted on:
> > > export DEVPATH=/bus/pci/devices/0000:01:00.0
> > >
> > > vm86 is 20K non-debug
> > > emu86 is 40K non-debug
> > >
> > > Currently they don't use Ben's VGA arbiter which isn't ready

yet.
> > When
> > > finished these app will automatically be triggered on driver

load as
> > > part of the hotplug process.
> > >
> > > The source to vm86 is from the linux BIOS project where is has

been
> > > worked on to make it substantially smaller. I like to keep

everyone
> > on
> > > the same source code base if possible.
> > >
> > > Once we get these cleaned up and working I'm hoping to get them
> >
> > added
> > > to the klibc project. Once in klibc, klibc is schedule to go

into
> > the
> > > kernel sooner or later.
> > >
> > > They are both partially working but fail part way through the
> >
> > posting
> > > process. I've been playing with them a couple of days and I

can't
> > > figure out why they are failing. They are both failing for

different
> > > reasons. Can anyone help?
> > >
> > > LinuxBIOS mailing list
> > > [e-mail]
> > > http://www.openbios.org/mailman/listinfo/linuxbios
>
> LinuxBIOS mailing list
> [e-mail]
> http://www.openbios.org/mailman/listinfo/linuxbios