OpenBIOS

openbios@openbios.org

4297 discussions

(some help) Fw: [AROS-Dev] i386/native status
by Jaime Dias 01 Mar '00

01 Mar '00

hi, sorry in advance, but we have only one person on aros team (www.aros.org) that is handle the x86 port, and it apears some trouble now, it's not polite to invite developers on other projects, but i read this list for a while and maybe there is someone who here who could help us in this issue. port aros to x86 is very important for the project, thats why i am posting this mail. (ggi on gfx handle side and openbios on how treat the hardware and gfx on other side) > > But we still don't have the most important (and easy to write > indeed) thing - ide.hidd (ide.device scsi.device....) so we are anable to > start system - we can add dos.library to residentlist but it will not see > any drives. Besides vga.hidd is either buggy or missing some methods so it > can't work propertly at this moment. It do draw point but it don't show a > window (on the other hand it can open screen and alloc colors propertly). > > The most important thing we are missing is TIME (true for me). My last > update was due to my 1.5 week long vacation. Sitting whole nights > (well.. not whole - only to 5 AM) at my PC, fighting with bugs and reading > the hardware books - that's how I spend this time. I know many more than > one month ago but now what I need is time. Without it I can't work. > > > Tell me what the bus.hidd should do and then I'll try to write it. I have > many hardware references at home so I can work (time, time, > time....). irq.hidd would be very easy to write (most of it is placed now > in exec.library, just look at config/i386-native/exec/irq.S and other .S > files) but what we need is ready and well-described idea of it. > > > If you could find something about DMA mode in all new harddrives it would > be great... One could help Frederic with ide.device - working alone is > much slower. > sorry bother, jaime dias - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

Re: AW: [OpenBIOS] Aladdin V chipset
by dave＠denial.force9.co.uk 01 Mar '00

01 Mar '00

Burl Nyswonger <burl(a)watchguard.com> wrote: > 2) high-level (ie: C and Forth) -- It would be nice if there > could be some way to abstract the chipset "advanced" features > into the OpenFirmware device tree. If not, this is still > where I think the "performance" related chipset initialization > should happen. Ugh, no. I spent some time moving the PCI optimisation from the kernel to userspace (see http://linux.powertweak.com). Moving this to BIOS space would not make much sense. The BIOS should contain enough code to get the system into a sane enough state to boot a kernel, and nothing more. Another problem with PCI tweaking, is that some options are motherboard specific. You have no way of detecting if that option is going to work. When a motherboard manufacturer licenses a BIOS from a vendor, they get source with #defines to tell them how certain parts of the board work. How the data/address lines are decoded for example.. Asides from the mobo manufacturer, no-one is going to know how a memory bank has been wired on their board, so they won't know the order in which certain things have to be performed. The only way you can offer this to users is in a 'try and see' approach. Such a tactic does NOT belong in BIOS land. regards, -- Dave. - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

STPC BIOS sources posted
by Jeff Garzik 01 Mar '00

01 Mar '00

free bios hackers-- Johan Rydberg has kindly allowed me to posted his GPL's STPC BIOS sources. The code is early work and incomplete, but may be useful to people here... I have been hacking on this instead of OpenBIOS lately, as it seems easier to use these stpc source to create a BIOS for the i430FX. Download from http://gtf.org/garzik/bios/ Jeff (copied to linux-kernel as there has been quite a bit of interest in BIOS sources there too) -- Jeff Garzik | Rule 1: Building 1024 | There is no cabal. MandrakeSoft, Inc. | - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

Aladdin V chipset
by Burl Nyswonger 01 Mar '00

01 Mar '00

I have begun to hack on OpenBIOS and am looking to add support for x86 and the Aladdin V chipset (ie: Super Socket7, Asus P5A, etc...). If anyone else has started work on this, or plans to, it would be nice to talk. -- Burl. - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

6 11

Re: [OpenBIOS] PCI enumeration?
by dave＠denial.force9.co.uk 29 Feb '00

29 Feb '00

Chong Chee Yong <catz(a)silvermoon.com.sg> wrote: > > (this is all defined in the PCI spec) To scan the PCI bus, you > > basically iterate through each slot, reading the device and vendor ids. > > If the slot is empty you get a nonexistent value (either 0 or 0xffff I > > think). There can also be bridges on the PCI bus, so you must > > recursively descending into those, and scan their devices, as well. > > Haven't read the PCI bridges specs, but it seems that it is possible > for two unconnected PCI bus since the algorithm suggested in revision 2.2 > Chapter 6.1 is to scan all possible slots. I believe that this (or something similar) has been implemented on some newer Compaq servers. There are a number of workarounds in the kernel PCI code. If someone has access to one of these, an lspci -xxx output would make interesting reading. regards, -- Dave. - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

piix4e "minimal" setup
by Ronald G. Minnich 29 Feb '00

29 Feb '00

any hints on what to do just to get timer interrupts going are most welcome :-) geez, this is getting close! ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

linuxbios: getting there
by Ronald G. Minnich 29 Feb '00

29 Feb '00

I'm now in linux main. I was right at trap_init then the WinDB debugger program exploded. I love it. ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

Re: [OpenBIOS] Aladdin V chipset
by Ronald G. Minnich 29 Feb '00

29 Feb '00

On Mon, 28 Feb 2000, Burl Nyswonger wrote: > > when you say super socket 7 chipsets -- does this include AMD? > > edwin > I meant "Super Socket 7 boards" in general -- ie: the Asus P5 series, Acer > boards (obviously), etc... When I say "Aladdin V Chipset", I am referring OK, this brings up an interesting issue for the OpenBIOS community. At least one Socket 7 motherboard will support either alpha or pentium in the socket. So it's the same motherboard with a different processor. All startup tasks for the motherboard are pretty much the same. I had an interesting set of discussions with vendors at extreme linux last week. There's a lot of interest in linuxbios -- from Alpha motherboards too (the alpha bios'es all have sucked very badly -- dec never got it right). As things stand openbios is too pentium-specific. So I'd like to propose an idea. 1) get into protected mode early 2) get rid of as much assembly as possible there's a lot that can move to C so we change the layout a bit. It's still early in the game, we can do this. A possible layout: bios/arch/i386/{poweron.s,protected_mode.s,memory.s,motherboard.c,boot.c} bios/arch/alpha/{poweron.s,protected_mode.s,memory.s,motherboard.c,boot.c} bios/payload/{your c files here} poweron.s is the very first set of things you do on poweron -- should be a few instructions. protected_mode.s bumps you into protected mode. On the pentium this is a few instructions. memory.s turns on memory -- this is *much* easier on the pentium in protected mode. memory.s should set up a stack and jump to C code. Motherboard.c does anything that has to be done to further use the motherboard. Boot.c gunzips the payload (either a bios-compatible code or Linux or FreeBSD or whatever) and jumps to it. I'm talking to a commercial company that is going to do something like this -- they don't want much assembly long-term, so they're recrafting openbios. I don't think most people want to do assembly. If we do this, we're not just for pentiums any more. That would be wonderful! Any interest? ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

7 11

PCI enumeration?
by Brian Hurt 29 Feb '00

29 Feb '00

Is anyone else out there working on adding PCI enumeration to OpenBIOS? Any one have any pointers to code I can theft, er, reuse? I'm looking at the function pci_scan_bus() in the linux source code (drivers/pci/pci.c), but that looks like it just reads the results of an already-enummerated PCI bus. Help would be greatly appreciated. Brian - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

5 7

Cool project
by Daniel Haglund 28 Feb '00

28 Feb '00

Hi! I just read about your project. Really cool! Ofcourse you wan't to boot linux as fast as possible. My friend David and I have spent a few hours surfing around for a BIOS able to boot FAST. We'd like to use it for the fuel injection system we're building for my car. The computer should not only control fuel delivery and ignition but also play mp3. Preferably controlled using Sony's CD-changer protocol, but that is far away. Anyway, if you BIOS is able boot linux / rtlinux fast it would be great! That's all we need. We don't want the slow code BIOS manifacturers put in for DOS and other stuff. I'll check your news page to see your progress. Keep up the good work. Daniel Haglund dhaglund(a)mail.uccs.edu - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

Jump to page: