coreboot

coreboot@coreboot.org

11 participants
39712 discussions

Re: epia m vga + memcpy update
by Li-Ta Lo 13 Sep '04

13 Sep '04

On Mon, 2004-09-13 at 11:54, Egbert Eich wrote: > Stefan Reinauer writes: > > * Li-Ta Lo <ollie(a)lanl.gov> [040909 18:26]: > > > Did they do anything on the "core" x86emu? Last time I checked, > > > XF86 4.4.0 has almost the same x86emu as testbios. > > > > Yes. But not only the x86 emulation itself is interesting, but also the > > legacy bios emulation around it. There are so many branches and forks > > out there, we _have_ to do something to unite them, otherwise we cannot > > reach our goal in this area. Nobody knows what the others are really > > doing. > > > > I am going to set up an GNU Arch repository on openbios.org asap so we > > can set a starting point for development. > > > > We need some clarification on what parts belong in this repository, and > > which ones don't. Like, where do the PCI access functions go, logically, > > in this picture? > > > > In the Scitech repository there are already two things: the CPU emulator > and the PC environment. Both reside in separate directories. > The directory structure needs to be changed (in a smart way so that > resyncing with scitech isn't an issue and the emulator can be used > separately) and the PC environment needs to be cleaned up and enhanced. > In your X.org CVS log, you said you resync with Scitech's code. Is it the 0.8 from their ftp site or something else ? Ollie

1 0

Re: epia m vga + memcpy update
by Stefan Reinauer 13 Sep '04

13 Sep '04

* Egbert Eich <eich(a)suse.de> [040913 19:54]: > In the Scitech repository there are already two things: the CPU emulator > and the PC environment. Both reside in separate directories. > The directory structure needs to be changed (in a smart way so that > resyncing with scitech isn't an issue and the emulator can be used > separately) and the PC environment needs to be cleaned up and enhanced. How open is scitech to a restructure of their work? We could simplify things a lot. Last time I looked at x86emu I had major problems getting the different type definitions together ... > Right now I'm in the midst of a release cycle (Stefan knows what that > means) but I hope to find some time afterwards. Good luck :-) I have plenty of things on my todo list, too. I will create a repository within the next 1-2 weeks, so until after 9.2 we can start with major spring/winter cleanup ;) Stefan

1 0

Re: epia m vga + memcpy update
by Richard Smith 13 Sep '04

13 Sep '04

Egbert Eich wrote: > > This is probally where the difference matters most for things like > > vbios. support of the legacy bios calls. VGA card bioses are really > > fragile. One wrong return value and its off the trolly or hung in some > > sort of loop. > > Yes, however we have been pretty lucky so far. > The only real issues arose with 'embedded BIOSes' like on laptops. > These video BIOSes sometimes try to call fynctions in the system BIOS > which behave strangely themselves (like try to switch to protected mode). Oh its far worse than that. They actually have special extensions that the OEM has to support so that they can do special stuff for TV out or LCD panel type detection. And of course this is all Mfg specific and only the info only acessable under NDA. > I would prefer to do this stuff myself as Jon is mostly working on > top of my old code. I would rather use the code from X.Org as a basis > for enhancements as it had more public exposure and testing. Ok. So you want to seed the repository with the stuff from X.org and let everyone else re-implemnt thier stuff on top of that and then feedback what changes they had to make?

1 0

RE: mkelfImage
by Dave Aubin 13 Sep '04

13 Sep '04

Hi, I recall getting that. You want to use Eric's 2.5 flavor. I've attached it here: Dave ________________________________ From: linuxbios-admin(a)clustermatic.org [mailto:linuxbios-admin@clustermatic.org] On Behalf Of Dave Belt Sent: Monday, September 13, 2004 2:35 PM To: linuxbios(a)clustermatic.org Subject: mkelfImage There appear to be a couple versions of mkelfImage floating around and I've heard reports of varying degrees of reliability with them. Could anyone enlighten me on differences here? We're trying to boot Linux via Etherboot and are getting the following: Welcome to elfboot, the open sourced starter. January 2002, Eric Biederman. Version 1.3 Loading Etherboot version: 5.2.2 ROM segment 0x2e81 length 0x7938 reloc 0x00020000 CPU 1664 Mhz Etherboot 5.2.2 (GPL) http://etherboot.org Tagged ELF for [3C90X] get_memsizes | linuxbios Relocating _text from: [000244e0,00034330) to [efef01b0,eff00000) Probing pci nic... [3c905b-tpo100] 3C90X Driver 2.00 Copyright 1999 LightSys Technology Services, Inc. Portions Copyright 1999 Steve Smith Provided with ABSOLUTELY NO WARRANTY. ------------------------------------------------------------------------ ------- MAC Address = 00:10:5A:A2:5A:82 Connectors present: 10Base-T / 100Base-TX. Searching for server (DHCP)... Me: 192.168.123.3, Server: 192.168.123.254, Gateway 192.168.123.254 Loading 192.168.123.254:vmlinuz.elf (ELF)... done Issuing RESET: elf_start | breakpoint = 0x0002ee44 Has anyone seen this before? Is this a problem with our Linux kernel or is the problem with Etherboot? Thanks in advance.

1 0

mkelfImage
by Dave Belt 13 Sep '04

13 Sep '04

There appear to be a couple versions of mkelfImage floating around and I've heard reports of varying degrees of reliability with them. Could anyone enlighten me on differences here? We're trying to boot Linux via Etherboot and are getting the following: Welcome to elfboot, the open sourced starter. January 2002, Eric Biederman. Version 1.3 Loading Etherboot version: 5.2.2 ROM segment 0x2e81 length 0x7938 reloc 0x00020000 CPU 1664 Mhz Etherboot 5.2.2 (GPL) http://etherboot.org Tagged ELF for [3C90X] get_memsizes | linuxbios Relocating _text from: [000244e0,00034330) to [efef01b0,eff00000) Probing pci nic... [3c905b-tpo100] 3C90X Driver 2.00 Copyright 1999 LightSys Technology Services, Inc. Portions Copyright 1999 Steve Smith Provided with ABSOLUTELY NO WARRANTY. ------------------------------------------------------------------------ ------- MAC Address = 00:10:5A:A2:5A:82 Connectors present: 10Base-T / 100Base-TX. Searching for server (DHCP)... Me: 192.168.123.3, Server: 192.168.123.254, Gateway 192.168.123.254 Loading 192.168.123.254:vmlinuz.elf (ELF)... done Issuing RESET: elf_start | breakpoint = 0x0002ee44 Has anyone seen this before? Is this a problem with our Linux kernel or is the problem with Etherboot? Thanks in advance.

1 0

Re: epia m vga + memcpy update
by Li-Ta Lo 13 Sep '04

13 Sep '04

On Mon, 2004-09-13 at 11:44, Egbert Eich wrote: > > Cool. I'm going to route this info back to Jon Smirl who seems to be in > > charge of the DRI x86emu stuff hopefully he can merge in any > > improvements from his stuff. > > > > I would prefer to do this stuff myself as Jon is mostly working on > top of my old code. I would rather use the code from X.Org as a basis > for enhancements as it had more public exposure and testing. Are you working on the core instruction emulation or something else like the PCI BIOS you mentioned ? Ollie

1 0

Re: epia m vga + memcpy update
by Richard Smith 13 Sep '04

13 Sep '04

Egbert Eich wrote: > > But testbios dosen't work on an ASUS P2B booting LB or COTS and my > > modified ATI vbios. Nor does LB+ADLO+BOCHS with the original M1 vbios. > > X with InitPrimary works both under COTS and LB but that was using > > using the orginal M1 bios not my "fixed" version. > > The X version has eveloved quite a lot and is a lot smarter now as the > version of vbios that it originally forked off. Where does the smartest version now live? X.org or whats in Xfree86 4.4? > > IO range requested by the card and the Legacy VGA ranges. Currently > > testbios lets the vbios access any port it wishes. The X emu must be > > doing this or the ATI M1 bios would not work. > > Currently the emulator in X doesn't do this either. > It intercepts certain port accesses like 0x43 and 0x5c and attempts to > emulate the action behind it. Also it tries to intercept PCI accesses, > however this is only true if they happen 32bit wise. So it just handles the timer. Well it does it better than testbios. Seems a sync would be a good thing. How hard is that currently? Do you have to pull the entire xc tree down?

1 0

Re: epia m vga + memcpy update
by Li-Ta Lo 13 Sep '04

13 Sep '04

On Mon, 2004-09-13 at 02:08, Egbert Eich wrote: > Li-Ta Lo writes: > > > > Did they do anything on the "core" x86emu? Last time I checked, > > XF86 4.4.0 has almost the same x86emu as testbios. > > Any XF86 stuff may be outdated. > Then, what is the most updated thing? X.org ? > > > > BTW, I think a fork of x86emu is inevitable. If we want to move > > testbios into LinuxBIOS, we have to remove all OS/libc dependence > > from the emulator. > > > > A fork would be crazy. x86emu is hard enough to maintain as it is: > the main sources are hosted by scitech somewhere deep down under > then it is also living in the X.Org tree in extras/ where the stuff > that's maintained elsewhere exists. > Scitech has this stupid version control system called 'Perforce'. > I have been unable to commit my stuff back there although > Kendall Bennett and I have tired hard to make write access work for > me. > > Removing OS/libc dependences is a valid proposal which should be persued > in the main version. > I would like to move hosting someplace else. I could host it on > freedesktop.org - although it is not primarily desktop related. > I have not done it so far for lack of time, however if somebody > would volunteer to help we could get started on this. > Since we (LinuxBIOS) are pretty much depending on x86emu for initializing the VGA and probably other "obscured" device, I am willing to help. Ollie

1 0

building romimage for tyan s2850 mainboard
by Sagiv Yefet 12 Sep '04

12 Sep '04

I am trying to build and run a romimage for tyan s2850: Hardware: No disks Superio : w83627hf Ethernet: broadcom Southbridge: 8111 It looks like the default mainboard configuration. In order to start I wanted to build only the normal image. Only to see some output in the console. I made the following changes in Config.lb: * put the romimage "fallback" statement in comment. * FALLBACK_SIZE =0. * HAVE_FALLBACK_BOOT = 0 * remove "fallback from build: buildrom ./linuxbios.rom ROM_SIZE "normal" * Use filo boot. I built the romimage, burn it and the console doesn't show output. The problem is not in the cable. What am I doing wrong ? Thanks, Sagiv

2 1

about linux, linuxbios and bootup times
by linuxg33k 10 Sep '04

10 Sep '04

Hi everyone. I'm a new member, I joined the list to learn more about the Linuxbios project. A question for anyone that can point me in the right direction to information: Q: I read everything on linuxbios.org as well as googled until i got a nosebleed, but i can't find any real world examples of linuxbios + linuxdistro setups. I am looking right now to purchase a linux bios compatable mobo based on the list from linuxbios.org to play around with, but what i was wondering is, just how can linuxbios speed up the boot process of a linux based system? Pardon my newbieness, but I have never had a bios be anything more than a fraction of the total bootup time on any linux system, so does linuxbios have the capability to litterally boot a linux system to cli login prompt of any distro within seconds or not? I realize it's a general question, assume I'm running debian base install ( no x, no desktop environment, boot staright to command line), most of the bootup process is taken up by the bootup scripts checking the hardware and starting up various services (I probably have too many and unoptimized i'm sure but thats another issue alltogether). From everything that I have read, I am understanding that basically its a faster bios that jumps to the distros bootloader when done? Or does this redefine the bootup process where the linuxbios is the bootloader and upon coming to life jumps straight to the distro kernel? If it jumps to the distro bootloader surely the time savings are a few seconds at best? If linuxbios takes over some of the bootloader functions, how does this affect a typicall install if at all? Sorry for the overgeneralized questions, I just need a few answers here, even if vague to help me create a knowledge sandbox into which i can then drill down to proper understanding. By the way, i read an article recently of an interview with the president of Tyan. According to the interview Tyan will be shipping all motherboards with Linuxbios. I have no idea if they are using the real deal from cvs, or forking it, or what, but goddamn that really cool stuff. I'm hoping some of the answers to my question will mean that linux on the desktop has a bright future vis a vis Tyan at least. If anyone wants a copy of it, email me and I will attach the html document - I knew they would take it down as indeed they have. Thanks aforehand!!!! - Rob

5 5

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot