[LinuxBIOS] Epia-M compilation fails

[Bu Bacoo]

Hello

After preparing epia-m build ( ./buildtarget via/epia-m/ ), I move to
via/epia-m/epia-m and run 'make'. I get this error during linkage:

.... cut.....
gcc -m32 -nostdlib -r -o linuxbios_ram.o c_start.o vt8235_lpc.o
uart8250_console.o vt8235.o vt8235_ide.o mainboard.o vt8235_usb.o
vt8235_nic.o model_centaur_init.o
linuxbios.a/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/libgcc.a
gcc -m32 -nostdlib -nostartfiles -static -o linuxbios_ram -T
/home/bubak/epia/bios/LinuxBIOSv2/src/config/linuxbios_ram.ld
linuxbios_ram.o
linuxbios_ram.o(.text+0x8bc): In function `vga_fixup':
: undefined reference to `setup_realmode_idt'
linuxbios_ram.o(.text+0x8cd): In function `vga_fixup':
: undefined reference to `do_vgabios'
linuxbios_ram.o(.text+0x8e0): In function `vga_fixup':
: undefined reference to `vga_enable_console'
collect2: ld returned 1 exit status
make[1]: *** [linuxbios_ram] Error 1
make[1]: Leaving directory
`/home/bubak/epia/bios/LinuxBIOSv2/targets/via/epia-m/epia-m/normal'
make: *** [normal/linuxbios.rom] Error 1

Any ideas please?

Thanks, Bu

[Jonathan McDowell]

On Fri, Oct 07, 2005 at 10:37:43PM +0200, Bu Bacoo wrote:
> After preparing epia-m build ( ./buildtarget via/epia-m/ ), I move to
> via/epia-m/epia-m and run 'make'. I get this error during linkage:
>
> .... cut.....
> gcc -m32 -nostdlib -r -o linuxbios_ram.o c_start.o vt8235_lpc.o
> uart8250_console.o vt8235.o vt8235_ide.o mainboard.o vt8235_usb.o
> vt8235_nic.o model_centaur_init.o
> linuxbios.a/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/libgcc.a
> gcc -m32 -nostdlib -nostartfiles -static -o linuxbios_ram -T
> /home/bubak/epia/bios/LinuxBIOSv2/src/config/linuxbios_ram.ld
> linuxbios_ram.o
> linuxbios_ram.o(.text+0x8bc): In function `vga_fixup':
> : undefined reference to `setup_realmode_idt'
> linuxbios_ram.o(.text+0x8cd): In function `vga_fixup':
> : undefined reference to `do_vgabios'
> linuxbios_ram.o(.text+0x8e0): In function `vga_fixup':
> : undefined reference to `vga_enable_console'
> collect2: ld returned 1 exit status
> make[1]: *** [linuxbios_ram] Error 1
> make[1]: Leaving directory
> `/home/bubak/epia/bios/LinuxBIOSv2/targets/via/epia-m/epia-m/normal'
> make: *** [normal/linuxbios.rom] Error 1
>
> Any ideas please?

The VGA support won't compile; does "./buildtarget via/epia-m/Config.lb"
get any further for you?

I'm still periodically updating the list of targets that build with a
default SVN checkout at:

http://the.earth.li/~noodles/lb/

J.

[Bu Bacoo]

No, it doesn't help. I checked your list of targets and there epia-m looks
to compile fine. Clean dir, I did:

svn co svn://openbios.org/repos/trunk/LinuxBIOSv2
....
Checked out revision 2051.

cd /home/bubak/epia/bios/LinuxBIOSv2/targets
./buildtarget via/epia-m/Config.lb > build.txt 2> build2.txt
cd via/epia-m/epia-m/
make > make.txt 2> make2.txt

Outputs are attached. Same VGA problems

After this, I've run yours ./test-build-all.sh. Very same output for
via-epia-m. And it doesn't look to me, that it uses some external libs
regarding VGA support, does it?

Btw, ehn I checked the build-all log, much less targets were build, then on
your side :-(
(logs are attached)

Any ideas?

Thanks, Bu

gcc --version
gcc (GCC) 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8)

glibc 2.3.5-r1

On 10/8/05, Jonathan McDowell  wrote:
> On Fri, Oct 07, 2005 at 10:37:43PM +0200, Bu Bacoo wrote:
> > After preparing epia-m build ( ./buildtarget via/epia-m/ ), I move to
> > via/epia-m/epia-m and run 'make'. I get this error during linkage:
> >
> > .... cut.....
> > gcc -m32 -nostdlib -r -o linuxbios_ram.o c_start.o vt8235_lpc.o
> > uart8250_console.o vt8235.o vt8235_ide.o mainboard.o vt8235_usb.o
> > vt8235_nic.o model_centaur_init.o
> > linuxbios.a/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/libgcc.a
> > gcc -m32 -nostdlib -nostartfiles -static -o linuxbios_ram -T
> > /home/bubak/epia/bios/LinuxBIOSv2/src/config/linuxbios_ram.ld
> > linuxbios_ram.o
> > linuxbios_ram.o(.text+0x8bc): In function `vga_fixup':
> > : undefined reference to `setup_realmode_idt'
> > linuxbios_ram.o(.text+0x8cd): In function `vga_fixup':
> > : undefined reference to `do_vgabios'
> > linuxbios_ram.o(.text+0x8e0): In function `vga_fixup':
> > : undefined reference to `vga_enable_console'
> > collect2: ld returned 1 exit status
> > make[1]: *** [linuxbios_ram] Error 1
> > make[1]: Leaving directory
> > `/home/bubak/epia/bios/LinuxBIOSv2/targets/via/epia-m/epia-m/normal'
> > make: *** [normal/linuxbios.rom] Error 1
> >
> > Any ideas please?
>
> The VGA support won't compile; does "./buildtarget via/epia-m/Config.lb"
> get any further for you?
>
> I'm still periodically updating the list of targets that build with a
> default SVN checkout at:
>
> http://the.earth.li/~noodles/lb/
>
> J.

[Bu Bacoo]

On a Fedora box with gcc-3.4.4 I 've succeed. Goin' to check other gcc on
that gentoo box...

Bu

On 10/8/05, Bu Bacoo  wrote:
> No, it doesn't help. I checked your list of targets and there epia-m looks
> to compile fine. Clean dir, I did:
>
> svn co svn://openbios.org/repos/trunk/LinuxBIOSv2
> ....
> Checked out revision 2051.
>
> cd /home/bubak/epia/bios/LinuxBIOSv2/targets
> ./buildtarget via/epia-m/Config.lb > build.txt 2> build2.txt
> cd via/epia-m/epia-m/
> make > make.txt 2> make2.txt
>
> Outputs are attached. Same VGA problems
>
> After this, I've run yours ./test-build-all.sh. Very same output for
> via-epia-m. And it doesn't look to me, that it uses some external libs
> regarding VGA support, does it?
>
> Btw, ehn I checked the build-all log, much less targets were build, then
> on your side :-(
> (logs are attached)
>
> Any ideas?
>
> Thanks, Bu
>
> gcc --version
> gcc (GCC) 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8)
>
> glibc 2.3.5-r1
>
> On 10/8/05, Jonathan McDowell  wrote:
> > On Fri, Oct 07, 2005 at 10:37:43PM +0200, Bu Bacoo wrote:
> > > After preparing epia-m build ( ./buildtarget via/epia-m/ ), I move to
> > > via/epia-m/epia-m and run 'make'. I get this error during linkage:
> > >
> > > .... cut.....
> > > gcc -m32 -nostdlib -r -o linuxbios_ram.o c_start.o vt8235_lpc.o
> > > uart8250_console.o vt8235.o vt8235_ide.o mainboard.o vt8235_usb.o
> > > vt8235_nic.o model_centaur_init.o
> > > linuxbios.a /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/libgcc.a
> > > gcc -m32 -nostdlib -nostartfiles -static -o linuxbios_ram -T
> > > /home/bubak/epia/bios/LinuxBIOSv2/src/config/linuxbios_ram.ld
> > > linuxbios_ram.o
> > > linuxbios_ram.o(.text+0x8bc): In function `vga_fixup':
> > > : undefined reference to `setup_realmode_idt'
> > > linuxbios_ram.o(.text+0x8cd): In function `vga_fixup':
> > > : undefined reference to `do_vgabios'
> > > linuxbios_ram.o(.text+0x8e0): In function `vga_fixup':
> > > : undefined reference to `vga_enable_console'
> > > collect2: ld returned 1 exit status
> > > make[1]: *** [linuxbios_ram] Error 1
> > > make[1]: Leaving directory
> > > `/home/bubak/epia/bios/LinuxBIOSv2/targets/via/epia-m/epia-m/normal'
> > > make: *** [normal/linuxbios.rom] Error 1
> > >
> > > Any ideas please?
> >
> > The VGA support won't compile; does "./buildtarget via/epia-m/Config.lb"
> > get any further for you?
> >
> > I'm still periodically updating the list of targets that build with a
> > default SVN checkout at:
> >
> > http://the.earth.li/~noodles/lb/ http://the.earth.li/%7Enoodles/lb/
> >
> > J.

[Nick Barker]

> After preparing epia-m build ( ./buildtarget via/epia-m/ ), I move to
> via/epia-m/epia-m and run 'make'. I get this error during linkage:
>
> .... cut.....
> gcc -m32 -nostdlib -r -o linuxbios_ram.o c_start.o vt8235_lpc.o
> uart8250_console.o vt8235.o vt8235_ide.o mainboard.o vt8235_usb.o
> vt8235_nic.o model_centaur_init.o
> linuxbios.a /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/libgcc.a
> gcc -m32 -nostdlib -nostartfiles -static -o linuxbios_ram -T
> /home/bubak/epia/bios/LinuxBIOSv2/src/config/linuxbios_ram.ld
> linuxbios_ram.o
> linuxbios_ram.o(.text+0x8bc): In function `vga_fixup':
> : undefined reference to `setup_realmode_idt'
> linuxbios_ram.o(.text+0x8cd): In function `vga_fixup':
> : undefined reference to `do_vgabios'
> linuxbios_ram.o(.text+0x8e0): In function `vga_fixup':
> : undefined reference to `vga_enable_console'
> collect2: ld returned 1 exit status
> make[1]: *** [linuxbios_ram] Error 1
> make[1]: Leaving directory
> `/home/bubak/epia/bios/LinuxBIOSv2/targets/via/epia-m/epia-m/normal'
> make: *** [normal/linuxbios.rom] Error 1
>
> Any ideas please?

It seems that someone has been over enthusiastic about pruning what might
be considered to be old code out of the code base. The above references are
in a file 'vgabios.c' which once belonged in the src/pc80 directory. Its
companion file 'vgachip.h' is also missing.

This was the code that ran the VGA bios in real mode, and I understand
that this solution has been dropped in favour of running the vga bios
through an emulator. However the code to do this has not yet appeared in the
epia-m target.

I think the emulator is a great idea, but I'm not sure how VIA-ble it is
on the VIA epia-m (or epia for that matter):

- the EPIA 600Mhz processor is a small and slow processor

- the EPIA-M VGA BIOS is big and complicated. I think most of the
complexity has to do with the vt1622/vt1623 TV encoder attached to the VGA
chip and which controls which outputs are enabled.

- running in real mode (once upon a time when Linuxbios2 was working on
epia-m) the VGA BIOS would take 3 to 4 seconds to initialise. Thats full
speed 16 bit code = a lot of work. However that is acceptable in terms of
overall boot time.

- running the vga bios through a year old testbios takes somewhere in the
order of  30 seconds (not actually timed it). I appreciate that a lot of
effort has gone into improving the efficiency of the emulator, but even if
it is twice as efficicient then we are talking 15 seconds or so to emulate
the bios. I dont think that this is acceptable as a linuxbios boot time.

Thus I speculate that the epia-m targets are going to need the original
real mode VGA Bios initialisation.

I have just started working on Linuxbios and the epia-m target again, and
intend coming up with a fully functional version within the next 2 to 3
weeks. During that time I will explore the above issues more thoroughly.
What I suspect might happen is that the vgabios.c file is moved into the
src/mainboard/via/epia-m directory so that it becomes a target specific file
rather than pollute the src/pc80 directory.

Even with that file restored into the epia-m directory, however, the
target is still broken - it does a partial boot but gets stuck somewhere
allocating PCI resources. Again I intend to resolve these issues.

Hope this helps
  Nick Barker

[Richard Smith]

> running the vga bios through a year old testbios takes somewhere in the
>
> order of  30 seconds (not actually timed it). I appreciate that a lot of
> effort has gone into improving the efficiency of the emulator, but even if
> it is twice as efficicient then we are talking 15 seconds or so to emulate
> the bios. I dont think that this is acceptable as a linuxbios boot time.

Nick,

Were the debugging printfs in the In's and out's active?  If so that
_really_ slows it down.  Try it with them commented out.

In most cases VGA biosen are not bounded by execution speed but rather
by the small delays peppered through the code.  VGA bioses spend a lot
of time spinning waiting for bits to toggle.  In many of these cases
the 3 to 4x slowdown you get from the emulator dosn't matter.

The old testbios you are using also suffers from some timer issues. 
Depending on how the bios does the access it my read the timer
directly and then wait for the timer value to be > x.  If any kind of
printf is active in the emulator during these reads the time has a
high likelyhood of "wrapping."

What I found with one bios I was working with was that the timer
checks were wapping and the time routines would only exit when the
wapped value ended up being larger than the compare value.  This
caused my bios exectution time to be up in the order that you are
seeing.

30 seconds for testbios is way too long something else is up.

[Ronald G Minnich]

Hi nick, our experience with the emulator is that we have yet to see it 
run slower than real mode. Can you give it one more try?

I guess we can put the old support back if we really have to, but i'd 
like to avoid it. The old 'drop to x86 mode' support always worried me a 
bit.

Even your "slow" processor should run the emulation quite quickly.

ron

[Stefan Reinauer]

* Ronald G Minnich  [051013 15:39]:
> I guess we can put the old support back if we really have to, but i'd 
> like to avoid it. The old 'drop to x86 mode' support always worried me a 
> bit.

Using vm86 mode might be a way out of the misery. XFree86/Xorg does this on
x86 machines. I've looked into how they did it, and it looks rather
simple, except they're using a system call to switch to vm86 mode.

Stefan

[Ronald G Minnich]

Stefan Reinauer wrote:
> Ronald G Minnich  [051013 15:39]:
> > I guess we can put the old support back if we really have to, but i'd 
> > like to avoid it. The old 'drop to x86 mode' support always worried me a 
> > bit.
>
> Using vm86 mode might be a way out of the misery. XFree86/Xorg does this on
> x86 machines. I've looked into how they did it, and it looks rather
> simple, except they're using a system call to switch to vm86 mode.
>
> Stefan

I looked at that years ago as well. I would rather we just get Nicks' 
problem solved via emulation.

ron

[Richard Smith]

> > Using vm86 mode might be a way out of the misery. XFree86/Xorg does this on
> > x86 machines. I've looked into how they did it, and it looks rather
> > simple, except they're using a system call to switch to vm86 mode.
> I looked at that years ago as well. I would rather we just get Nicks'
> problem solved via emulation.

Nicks problems are things that we know should not be problems so we
need to fix them.  The epia based boards are nice sweet little boards
and it would be great starter platforms for people so having a
procedure that "just works" would be really useful.

I'm considering buying one so I may get my wish. *grin*

For a start he needs to test with the most recent version of the
emulator to see if the problems persist.

Whats the status of the "in-code" emulator vs the standalone testbios?
 Have they been synced recently or merged into a single tree?

[Ronald G Minnich]

Richard Smith wrote:
> Whats the status of the "in-code" emulator vs the standalone testbios?
>  Have they been synced recently or merged into a single tree?

Ollie?

ron

[Nick Barker]

Ok got to the stage where Epia-m is booting linux, though with lots of
things broken and running only to the serial port (i.e. no vga yet).

I have a couple of issues:

To get the code to run the cpu initialisation sequences I've had to change
the epia-m Config.lb from

...

chip cpu/via/model_centaur

...

to

...
   device apic_cluster 0 on
    chip cpu/via/model_centaur
    	device apic 0 on end
    end
   end

This is so that the code in the northbridge has appropriate device
structures to work with. Now this processor does not have a lapic, so this
construct seems bizare to me. Is there a more appropriate construct where no
lapic is present?

A quick grep shows that there are several other motherboards which use the
same style of configuartion in their Config.lb and their northbridge code.
Do these need changing as well?

Additionally 'src/arch/i386/lib/cpu.c' needs changing to support the case
where no lapic is present:

in function cpu_initialize there needs to be a conditional around some lines
as follows:

#if CONFIG_SMP || CONFIG_IOAPIC
    if (cpu->path.u.apic.apic_id != lapicid()) {
    	printk_err("CPU .....
            // return without setting ...
      } else {
#endif

and a similar condition around the closing brace a few lines later

Nick Barker

[Ronald G Minnich]

Nick Barker wrote:
> Ok got to the stage where Epia-m is booting linux, though with lots of
> things broken and running only to the serial port (i.e. no vga yet).

Nick, nice work!

as to your Config.lb requests, I'm fried from the LB summit but will try 
to take a look next week.

There's lots of stuff to relay from the summit, I hope somebody else 
will summarize as I am almost too tired to type, but if not, I will try 
to write it up over the weekend. It was the best technical meeting I've 
been to in quite some time -- lots of info. Lots of good people, and 
great discussions. Quite fun. A very busy 2.5 days!

I ought to mention this one thing: we have developed a procedure for 
commits now. It involves third-party review. Please everyone, no commits 
until the writeup is posted and we all have partners to review our 
commits. Signed-off-by: is coming soon.

Also, will those of you who have .pdf files for various hardware bits, 
please check the following:
- is it allowed for you to send the document to a 3rd party, i.e.
    the document is NOT NDA, and is NOT labelled in such a way that
    you can not redistributed it
- If so, can you help us by getting the documents to us, so we can
    post on the wiki in a documents section?
- if not, please, let's compile the URLs

We want to build a 'document data base' to make it easy for other 
users/developers to know how code was created. It will probably have 
parallel structure to the src tree (e.g. src/superio/winbond/w83xyz.pdf) 
for convenience.

thanks

ron

[Jun OKAJIMA]

Great!.
But, how long it takes to boot?
Two or three secs booting will be possible soon?
I have been waiting for long time for this kind of stuff.
( and VGA support also!)

--- Okajima, Jun. Tokyo, Japan.
> Ok got to the stage where Epia-m is booting linux, though with lots of
> things broken and running only to the serial port (i.e. no vga yet).
>
> I have a couple of issues:
>
> To get the code to run the cpu initialisation sequences I've had to change
> the epia-m Config.lb from
>
> ...
>
> chip cpu/via/model_centaur
>
> ...
>
> to
>
> ...
>   device apic_cluster 0 on
>    chip cpu/via/model_centaur
>    	device apic 0 on end
>    end
>   end
>
> This is so that the code in the northbridge has appropriate device
> structures to work with. Now this processor does not have a lapic, so this
> construct seems bizare to me. Is there a more appropriate construct where no
> lapic is present?
>
> A quick grep shows that there are several other motherboards which use the
> same style of configuartion in their Config.lb and their northbridge code.
> Do these need changing as well?
>
> Additionally 'src/arch/i386/lib/cpu.c' needs changing to support the case
> where no lapic is present:
>
> in function cpu_initialize there needs to be a conditional around some lines
> as follows:
>
> #if CONFIG_SMP || CONFIG_IOAPIC
>    if (cpu->path.u.apic.apic_id != lapicid()) {
>    	printk_err("CPU .....
>            // return without setting ...
>      } else {
> #endif
>
> and a similar condition around the closing brace a few lines later
>
> Nick Barker

[Jonathan McDowell]

On Fri, Oct 14, 2005 at 05:51:59PM +0100, Nick Barker wrote:
> Ok got to the stage where Epia-m is booting linux, though with lots of
> things broken and running only to the serial port (i.e. no vga yet).

Is your code for this available somewhere btw? VGA support isn't
important to me at present.

J.