Re: Booting Linux using netboot and HD
On Fri, Apr 22, 2005 at 01:58:31PM -0700, beneo wrote: Does filo support ext3 file system? the intruduction say it supports ext2, but didn't say anything about ext3. If it doesn't support ext3, does it mean I have to re-install Linux to ext2? On Fri, Apr 22, 2005 at 04:09:53PM -0600, Ronald G. Minnich wrote: IIRC read-only ext3 can almost always be read by ext2 file system code. A cleanly unmounted ext3 filesystem is for all practical matters equivalent to an ext2 filesystem and will work fine with ext2 software. But if there are leftover entries in the journal, the ext2 code wont know what to do. //Peter ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Booting Linux using netboot and HD
On Fri, Apr 22, 2005 at 10:51:37AM -0700, Nathanael D. Noblet wrote: If you ask me, you have two possible problems. 1) LinuxBIOS isn't setting up the IDE controller properly so that your kernel can't find it I agree. or 2) Something in the moving the kernel and initrd to the tftp server/system didn't work. As you are trying to ultimately boot directly from the local machine, I would use FILO. You may also want to post the kernel message on boot (all/most of them) so that developers here can see if there is something they recognize as being in error. I won't be able to help you unless it is obvious. I just find setting up a FILO boot to be easier then the network kind, which is likely because I understand it better, and have done it more. This is probably the best plan for the long term, but since the payload works so well (Etherboot loads, gets IP, gets ELF image, and jumps to ELf image with kernel, which finds initrd) as it is I wouldn't change that part of the system until the first problem was solved. I really like FILO too, it's a neat payload! :) //Peter ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Booting Linux using netboot and HD
On Thu, Apr 21, 2005 at 06:46:51PM -0700, beneo wrote: Then my trouble starts, every time I get a Linux Kernel Panic during the boot. The message is like this. Loading ext3.o module Mounting /proc filesystem Creating block devices kmod: failed to exec /sbin/modprobe -s -k block-major-3, errno = 2 VFS: Cannot open root device hda2 or 03:02 Please append a correct root= boot option Kernel panic: VFS: Unable to mount root fs on 03:02 As you wrote, everything works until the kernel is about to mount the root filesystem, very good for a first attempt! :) The exact error is that the initrd is unable to load the driver for your IDE controller, errno=2 means File not found, and hence the kernel can not find hda2. I used a command like this to make the elf image. mkelfImage --command-line=root=/dev/hda2 rw console=ttyS0,115200n8 \ --kernel=/boot/vmlinuz-2.4.20-8smp --ramdisk=/boot/initrd-2.4.20-8smp.img \ --output=/root/elf/linuxImage I think my root parameter at the mkelfimag command is correct because I type mount command on the console when I have the AMI BIOS booting the linux from the HardDisk, it looks like this, [EMAIL PROTECTED] bin]# mount /dev/hda2 on / type ext3 (rw) none on /proc type proc (rw) usbdevfs on /proc/bus/usb type usbdevfs (rw) /dev/hda1 on /boot type ext3 (rw) If anybody tell me what I did wrong, I would be really appreciated. I suggest you try making an ELF image without an initrd and if neccessary compile a kernel with drivers for your hardware compiled in statically. This shouldn't be too difficult. On Fri, Apr 22, 2005 at 09:23:40AM -0700, Nathanael Noblet wrote: I would suggest skipping the netboot portion and use FILO. It will load a kernel directly from the filesystem, if you are planning on using that as that root system, no point in pulling your kernel from the network, when it is already on the system. Indeed, this is another option. But a new kernel is still neccessary since the one in the ELF image (/boot/initrd-2.4.20-8smp.img) came with neither ext3 nor IDE drivers. //Peter ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: LinuxBios support for the ELAN SC520
On Thu, Mar 10, 2005 at 01:56:38PM -0700, Ronald G. Minnich wrote: Not to be a pain, but to clarify, that's a PLCC package. QFP looks like this: Thank you. I have been getting that wrong since the package was invented. Sorry. No need to apologize. Anyone who wants to put this in the FAQ, be my guest :-) Done. How do I identify the BIOS chip on my mainboard? //Peter ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Geode GX1 and IRQ tables
On Wed, Mar 09, 2005 at 05:08:20PM -0800, ramesh bios wrote: Yes, I was, or actually, am doubtful as well. I would have thought, for sure, you can turn off the cs5530a's claim of reads on that address block. But so far I can't find any way to do that, and it doesn't seem like anyone else has either. Perhaps setting the ROM interface to subtractive decoding will help? F0 Index 5Bh, Decode Control Register 2, Bit 5 BIOS ROM Positive Decode: Selects PCI positive or subtractive decoding for accesses to the configured ROM space. 0 = Subtractive; 1 = Positive. ROM configuration is at F0 Index 52h[2:0]. It resets to 1. (Page 94 in the data sheet.) //Peter ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: LinuxBios support for the ELAN SC520
On Thu, Mar 10, 2005 at 09:22:00AM -0700, Dave Olsen wrote: Ronald G. Minnich wrote: - flash part is the standard QFP, not DIP. It is definitely a QFP Not to be a pain, but to clarify, that's a PLCC package. QFP looks like this: PQFP (Plastic Quad Flat Pack) http://www.lsilogic.com/images/lsi2004/products/asic/packaging/pqfp.jpg http://www.xilinx.com/xlnx/xweb/xil_publications_display.jsp?category=-19181 TQFP (Thin QFP) http://www.lsilogic.com/images/lsi2004/products/asic/packaging/tqfp.jpg http://www.xilinx.com/xlnx/xweb/xil_publications_display.jsp?category=-19186 VQFP (Very Thin QFP) http://www.xilinx.com/xlnx/xweb/xil_publications_display.jsp?category=-19173 PLCC has J-shaped leads ending under the black plastic while the QFPs have gull-wing leads that point away from the package. Flash ROM usually is DIP, PLCC or TSOP. All these package acronyms will get to you. :) //Peter ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Geode GX1 and IRQ tables
On Thu, Mar 10, 2005 at 03:01:56PM -0800, ramesh bios wrote: Oooh, looks interesting. I did not actually know what subtractive decoding is. Now I do. After talking to the local PCI guy, it means that the cs5530 will only claim the transaction if it doesn't see anyone else assert devsel# for some number of cycles. I will try this out soon. Thanks very much Peter. Welcome. If it doesn't work out, I guess the ROM size select could be (ab)used for some trickery if the location of the tables can be controlled. I.e. make sure it's below the top 64kb of ROM and use region size to switch between RAM and ROM. Hope the decode works out though, it's a lot cleaner. //Peter ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Documentation [was: new FSF campaign ..]
On Tue, Mar 01, 2005 at 10:36:35AM +0100, Peter Karlsson wrote: On Tue, 1 Mar 2005, Peter Stuge wrote: There are probably more sections that would be useful too. Technical jargon? I'm still a bit confused about what payload is and there's probably quite a few words/acronyms that are being used but it's hard to know exactly what they mean. Right. These all go to 2.1. Basics and terms.. I wrote a short summary which discusses payloads a little, perhaps it can help clear things out; http://www.clustermatic.org/pipermail/linuxbios/2005-January/010815.html I'm going to add that to the wiki in a minute. //Peter ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Fw: Re: Documentation [was: new FSF campaign ..]
On Tue, Mar 01, 2005 at 12:44:23PM +0100, Peter Karlsson wrote: LinuxBIOS (initialises hardware) - payload (etherboot,OpenBIOS, FILO etc.) (- operating system)? Exactly right. But with the right flash memory on the mainboard you can use the operating system (Linux) as payload directly. Ok, but that was just an example. Technical jargon explanation is still needed to get into linuxbios. For instance: http://www.clustermatic.org/pipermail/linuxbios/2003-March/002240.html This mail mentions SPD,VID,DID,I2C etc. Does everybody know what these mean? To get more people interested in linuxbios one has to lower the bars, and technical jargon is a major blocker (at least for me). I'm not sure I agree that the bar must be lowered. Much of the development going on in LinuxBIOS is _heavily_ technical and spans across quite a few different architectures. It's not right or useful to force developers to work and/or communicate below their capabilities, and certainly not in an open source project. I would hate it if someone tried to do that to me. I do believe however, that all the technical prerequisite knowledge should be listed, so that people can get up-to-speed on their own. I'll try to work for this and I think that the wiki is a great forum. And yes, I do know what i2c is, and I think I know what spd is (ram speed?) SPD is Serial Presence Detect, the name of an I2C bus between the northbridge and all RAM modules. Each RAM module has an EEPROM with more or less correct information about how memory initialization code should set up the memory controller for correct size and optimal performance. Quite frequently the information is busted. :( but vid did does not ring a bell. These are short for Vendor ID and Device ID. VID and DID (or PID, Product ID) are id numbers assigned by organizations such as PCI-SIG and USBIF to hardware manufacturers allowing software to identify hardware in a reliable manner. The ids are stored inside the device, whether it's PCI or USB. Also true for PCMCIA/CardBus. //Peter ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Documentation [was: new FSF campaign ..]
On Mon, Feb 28, 2005 at 10:12:33AM -0700, Ronald G. Minnich wrote: On Mon, 28 Feb 2005, Jamie Rollins wrote: I agree very strongly on this point. If linuxbios is going to move forward, it's public face needs to be very well presented, which at the moment, it is not. The linuxbios.org web site is very out of date. The page desperately needs a documentation section, and a better way to download the most recent source code other than through the CVS. volunteers? I've really got a day job that eats most of my waking hours. What is the official status regarding LANL support for LinuxBIOS? Does LANL support LinuxBIOS development through your, Ollie's and Greg's salaries, along with the other guys there that have contributed? I used to have more time for the web site but my free time is almost zero. I understand what that is like. :( Regarding what is needed, my personal impression is that there are a couple of quite varying areas of LinuxBIOS that would benefit from documentation. 1. Overview Describes what LinuxBIOS is, what it is not and what it would like to become. Historical information and development status goes here too. 2. Development 2.1. Basics and terms List of/links to external documentation which is relevant for working with various parts of LinuxBIOS. E.g. PCI spec.. And terms used frequently that have particular meaning, e.g. device. 2.2. High-level overview Shows the general flow for chip sources and how they work together in the complete mainboard source. This includes a look at the source tree directory structure. 2.3. Porting guide What you need to know to make LinuxBIOS run on a previously unknown mainboard. This includes documentation of the configuration file formats and a general list of things required for a new port. (Chip documentation for new chips, flash enable documentation for new boards with previously known chips, etcetera.) 3. Utilities romcc, flash_and_burn, getpir and all their friends. What are they all used for, why are they needed? There are probably more sections that would be useful too. I find myself being able to contribute to the overview and maybe some points about utilities, since I haven't actually used LinuxBIOS yet. Anything about development is of course also tightly tied to the source, which has been somewhat in flux lately (for the better, since the new design is excellent!) rendering most existing docs obsolete.. ..just some thoughts.. Feel free to add more! //Peter ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Build error on the EPIA-M
On Sun, Feb 27, 2005 at 03:40:44PM -0800, Adam Talbot wrote: Humm Ok, I will start talking it up with the sus people. I would go for CF-IDE-adapter instead. SO much simpler. //Peter ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Boot Windows Please!
On Thu, Jan 27, 2005 at 08:49:51AM -0700, Ronald G. Minnich wrote: On Thu, 27 Jan 2005, Peter Stuge wrote: [..] Hope this helps. looks like a great FAQ entry to me Feel free to post it anywhere you think appropriate! //Peter ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: linuxbios on geode gx1 with sst-39SF020A and CompactFlash [PMX:#]
On Tue, Jan 25, 2005 at 11:31:10PM -0800, ramesh bios wrote: I converted my bzImage using mkelfImage like so: --kernel=./bzImage.in --output=bzImage.elf --command-line=root=/dev/hdc2 console=tty0 console=ttyS0,38400 ro init=/sbin/init Which version of mkelfImage are you using? There have been some problems with particular versions combined with particular versions of the toolchain. //Peter ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Boot Windows Please!
On Wed, Jan 26, 2005 at 09:52:11PM -0800, Adam Talbot wrote: -Ron (Linuxbios team) Humm, had one of my strange ideas. Would it be possible to use the linuxbios kernel as the system kernel?? So instead of calling a new kernel through FILO or booting from etherboot, could I just have Linux bios call INIT, like a normal kernel. I am looking to get the best possible boot time. 1 kernel loads MUCH faster then 2 kernels. You thoughts?? That's how LinuxBIOS was initially designed. LinuxBIOS in itself is only minimal code for initializing a mainboard with peripherals just enough for a Linux kernel to take over and to the rest. LinuxBIOS does not contain a kernel per se. After the initialization, LinuxBIOS jumps to a payload and while there has been discussion about stacking payloads that's currently not in practice. The payload was originally intended to be a Linux kernel stored in flash. Flash ROM grow rate was anticipated optimistically however, today there are not many mainboards that actually have enough flash ROM room for a kernel. 512KB can be seen here-and-there and a few boards come with 1MB. Recent kernels really want that MB, and then you'll only have room for 3-400 KB of initial ramdisk, which could be too small too, depending on the application. So, other payloads are used; the two major ones are FILO and Etherboot. FILE loads a kernel from a filesystem on an IDE device and Etherboot loads a kernel from the network or from a filesystem on an IDE device. If you're using FILO there is no Linux kernel until FILO loads it, and the kernel loaded by FILO (or Etherboot) can absolutely be the one you want to run in your system. Just set it up with the correct root and init commandline so that it can start init. Another option is to chain two kernels after each other, this is useful for loading a system kernel from some place that FILO or Etherboot can not reach, but which a Linux kernel can. Imagine all sorts of strange storage ranging from local JFS to unusual network systems and beyond. This uses the kexec feature in 2.6, where a kernel can execute another kernel. Hope this helps. //Peter ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: linuxbios on geode gx1 with sst-39SF020A and CompactFlash [PMX:#]
On Tue, Jan 18, 2005 at 10:47:38PM -0800, ramesh bios wrote: I noticed you mentioned reading the nsc reference drivers to get further understanding. Are these available somewhere? NSC offered the BLDT, BootLoader Development Toolkit, without an agreement of exclusivity and without licensing fees. The BLDT was a stripped down version of the XpressROM, which was NSCs in-house BIOS for embedded systems. And that in turn was a subset of Insyde Software's full Geode BIOS. The BLDT had code for initializing RAM, VGA and more, but pretty much no interrupt services at all. All of it is in assembler, and it gives an interesting glimpse of what commercial BIOS development is like. I'm glad I don't do that for a living. :) I'm guessing that's the reference code Christer looked at, the BLDT has useful comments here and there in the code and comes with some general documentation as well. Unfortunately I can't say if AMD still makes it available. NSC had a developer site where you just had to register to get an account, and it could be downloaded from there. //Peter ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Geode in Wyse Winterms
On Tue, Jan 18, 2005 at 08:19:47AM -0600, Bari Ari wrote: Anyone ever get the VSA ROM to work with LinuxBIOS? I don't think so. I had a document describing how to set up VSA that I acquired outside of NDA (download from NSC website) with which one could have made a VSM loader for LinuxBIOS, but we don't really like binary proprietary, plus the PDF is on a hard drive that doesn't start. :( //Peter ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: POST cards [was: speaker beeper]
On Fri, Jan 14, 2005 at 09:53:15AM -0700, Ronald G. Minnich wrote: On Fri, 14 Jan 2005, Peter Stuge wrote: Ouch! Does anyone know what the problem is? No Also, do you recall which models any of those mainboards were? every model I've had with a 3V pci bus. Aha, a 5V PCI card will likely cause problems if plugged into a 3V bus, although that's not supposed to be possible thanks to the differently keyed connectors. Of course a bad POST card can key as a Universal board even if it only runs off 5V, but that's not all there is to it. To be at least a little future proof (who knows how long PCI will live) I fully intend to make it a real Universal board that works equally well in 5V and 3V systems, without any configuration required. This is possible within the PCI specification. I still think a POST card with a Basic Stamp on it might be the best bet. Any particular reason to specifically choose a BASIC Stamp rather than e.g. a PIC? Has all email to/from the list been coming through correctly the last 12 hours? I'm not sure if I got some duplicates and delayed messages? //Peter -- Please don't Cc me when you're posting to a list that I'm on. Thanks! ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: linuxbios on geode gx1.....
On Fri, Jan 14, 2005 at 11:08:39AM -0700, Ronald G. Minnich wrote: On Fri, 14 Jan 2005, Adam Sulmicki wrote: of curiosity. How much do you guesstimate it would increase cost of the PIC if they add added built-in ethernet to it? $0.50 ? (not really sure if Geode cpu has build in ethernet or not). I keep wondering if they did delete ethernet so as to make it not compete with more expensive platforms. I find the removal of ethenet very odd. Neither GX1 nor Geode have ever had ethernet built-in. If you want ethernet it goes on the external PCI bus. NatSemi has been known to offer good package deals for sets of Geode+DP838xx+support chips however. Insyde BIOS licenses aren't exactly free however, and for a consumer device that would indeed be the path of least resistance. You can get custom modifications done for a fee too. (Or, just port LinuxBIOS.. :) //Peter ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Off-Topic - Really Inexpensive Computer[was: linuxbios on geode gx1.....]
On Fri, Jan 14, 2005 at 08:49:51PM -0600, Bari Ari wrote: Why even consider x86? Didn't someone mention Windows? //Peter ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: PICmicro summary [was: POST cards]
On Fri, Jan 14, 2005 at 11:08:04AM -0700, Ronald G. Minnich wrote: On Fri, 14 Jan 2005, Li-Ta Lo wrote: What is BASIC Stamp and what is PIC ? very nice small devices that are a full CPU with I/Os, and in the case of basic stamp, a basic interpreter built in. Specifically the PIC devices are the PICmicro Microcontroller products from Microchip, not to be confused with the AMD PIC mentioned in another thread. One of the newer PICmicro devices that I like in the smallest-but-still-quite-useful range is the PIC16F688; http://microchip.com/stellent/idcplg?IdcService=SS_GET_PAGEnodeId=1335dDocName=en010215 35 instructions, couple of thousand instructions program memory, 5 MIPS, 256 bytes RAM, 256 bytes EEPROM, up to 12 IO pins multiplexed with serial TX/RX and interrupt pin, timers, internal tuned 8MHz oscillator, low power modes, etc. etc. They come in lots of shapes and sizes but the entire 16F family is the same core architecture, if you know one you pretty much know them all. They also have the 18F family, which is optimized for C compilers. I tend to only do assembler on the 16F's. Fun to toy with and easy to use. :) Program (burner can be built for just a few $) it, connect a power source, and away it goes. //Peter ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: POST cards [was: speaker beeper]
On Thu, Jan 13, 2005 at 08:07:00AM -0700, Ronald G. Minnich wrote: On Thu, 13 Jan 2005, Peter Stuge wrote: What are good features for a POST card besides being a Universal board? (dual voltage) you have to make sure that it won't keep a machine from turning on. I have 5V post cards that when put in some mainboards won't allow them to power up. Ouch! Does anyone know what the problem is? Also, do you recall which models any of those mainboards were? I've seen memory on POST cards, giving scrollback of the last 32 seen codes, but I'm not sure how useful that is.. very useful to me anyway. Right, for bringing up a board/BIOS I agree it's useful. :) I just thought about the hw store I'm making it for, they only need them for their tech people handling returns. I figure why not add a few neat features to it as well, since they were considering making large batches and offering them for sale to anyone else. On Thu, Jan 13, 2005 at 08:07:15AM -0700, Ronald G. Minnich wrote: actually, a very handy thing would be a post card with a serial port ... That's a good idea! On Thu, Jan 13, 2005 at 09:55:41AM -0700, Ronald G. Minnich wrote: On Thu, 13 Jan 2005, Bari Ari wrote: With a serial port for output? yeah. A BASIC Stamp ought to be able to do the deed. I'll probably just put a PIC there for the serial port and any other peripheral stuff. Thanks for the ideas! //Peter ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Is 440BX ported to Linuxbios v2?
On Thu, Jan 13, 2005 at 10:54:59PM +0100, Svante Signell wrote: I found the BIOS chip brand and version: Its a Winbond W290C020-90 (84400M282325601VA). Any suppliers available somehere? Farnell has an equivalent part in stock at the very fair price of 46,43 SEK (USD 7) for single quantities. I can't seem to reproduce a working direct link, but go to http://se.farnell.com/ and search for 4376146, it should come up with the AT29C020-90PI from Atmel. It has some extra bells and whistles compared to the Winbond, but it will do the job just fine. If for some reason that doesn't work out, you could contact Memec in Stockholm and ask for the SST39SF020A-70-4C-PH or anything else they suggest/stock with similar parameters. If you don't represent a company they may not want to do business with you directly but in that case I have good connections with them and would be happy to help you get some flash parts. They usually have a minimum order value of 1000 SEK, but they might have good programmer products for sale as well. I checked ELFA and Bejoken too; ELFA has no suitable part, Bejoken has one which would work although it's not a perfect match. It's a Macronix 512kb part (4Mbit) - but their web order is down right now so I can't find the pricing. http://www.bejoken.se/bejokenweb/item/iteminfo.asp?ItemId=252521 (ELFA and Bejoken both retail electronic components here in Sweden.) Is it large enough to host LinuxBIOS? My dual-CPU MSI-6120 MOBO You could check if pin 1 (adress line 18) is connected anywhere, in that case you could plug a 4Mbit part into the socket instead of the 2Mbit originally there, improving the odds of fitting LinuxBIOS and the kernel into the flash quite a bit. But even with 512kb the kernel still requires an effort to get the size down. has on-board dual channel Adaptec 7895 SCSI support. Does V1 support this? No, but Ollie Lho's recent success with x86emu running VGA BIOSes means it's certainly within reach for V2. I'm not sure if it will have the same high priority once VGA support is worker, however. //Peter ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Running with VGA
On Thu, Jan 13, 2005 at 09:18:00PM -0700, Li-Ta Lo wrote: The only problem is how do we do a non-recursive broad first tree traversal? If recursion is the only problem and RAM is up then plain iteration and a manual stack could work. //Peter ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Is 440BX ported to Linuxbios v2?
On Wed, Jan 12, 2005 at 10:38:57AM +0100, Svante Signell wrote: Where can I purchase a replacement BIOS chip? Placed in a socket on the main board is a 2x16 pin DIL labeled: 686 AMI BIOS 1995 CS 9. Please remove the shiny sticker and check how the actual package is marked. You're looking for thin letters and numbers engraved on top of the black plastic. Look for 29F020 or something similar. //Peter ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Memtest+
On Wed, Dec 29, 2004 at 04:58:57PM -0500, Dave Aubin wrote: Has no one else hit this? One idea I have being a PIC lover is To use some LED's on the mother board and make a serial protocol Over the LED's, much like a software UART for a PIC. Anyone have an input on this? That will work just fine, but watch out for running the GPIO serial bus too fast for the PIC. (With GPIO I'm referring to pins driving the LEDs on the target system, not a PIC GPIO port.) If simplex is fun enough, you could use a single GPIO pin and connect that to RX on the PIC, connect TX on the PIC to a MAX232 and plug that into a regular serial port on a PC running a terminal emulator. All the PIC has to do then is read from RCREG and send everything back out through TXREG. Any PIC with a USART in async mode should do for this. For duplex (etherboot/filo menu) you may need a separate GPIO pin for flow control, the usual serial start/stop bit handshake may not be very reliable without a hardware UART on the target system. The easy solution is to use a synchronous serial interface instead; add a clock signal driven by the target. This also overcomes any problems caused by the PIC baud rate generator being controllable only with relatively low precision. The 16F87x series have both an MSSP and a USART; the MSSP could be used in SPI Slave mode for duplex communication with the target system, and the USART for talking to the PC running the terminal emulator. One thing to keep in mind is that SPI always transmits data in both directions, this means that the serial port wont be 8-bit clean unless you make a small protocol to indicate when data actually is available, this wastes twice the bandwidth, but may still be good enough. A USB device with a 16C745 or possibly 18F2550 if they can be sourced is tempting, but that also requires writing some kind of driver for the USB device, or figuring out how an existing USB-serial adapter works and reimplementing that. Too much work. Plus the 16C7x5 only do low-speed USB. Hope it works out though! //Peter ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: off-topic: PIC and ETRAX [was: Memtest+]
On Thu, Dec 30, 2004 at 02:25:47PM -0500, Dave Aubin wrote: Nice read Peter, thank you for the info:) No problem! Would be nice to use some voltage reference differencing Instead of using a Max 232, but the Max is probably a cleaner approach. The MAX232 is pretty common for connecting both PIC and AVR devices to RS-232 equipment. It just needs a few external capacitors, which is nice. A nerdy aside, I heard the 18F4550 and 18F2550 can run up to 12MIPs from a 4MHz crystal, they've got a whopping 16K of flash, and they have a Full-Speed USB v2.0 hardware. Yep. And 2kb RAM. Check out the data sheet page 11 and chapter 2. http://ww1.microchip.com/downloads/en/DeviceDoc/39632b.pdf Now if I could only run Linux on a PIC;) Linux? That's for the ETRAX, made by Axis. Check out http://developer.axis.com/ Everything-is-included Linux chip with 10/100 and both NOR and NAND flash for boot as well as storage. They've ported the GNU toolchain too. I'm still waiting for some project where I can use the MCM and end up with a few extra boards. :) //Peter ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: fallback and normal image
On Fri, Oct 29, 2004 at 11:49:25AM +0800, Gin wrote: I could build an image now. Thanks all. I am curious about how fallback image and normal image are used. It looks like in the normal image, it always jumps to the Protected_start. I don't think it should be the start when the system boots up since it will be in real-mode. So which image should I use? Both. The fallback image tries to load the normal image but if that fails it'll take over and continue with the fallback image. For only a single image, use fallback. //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: epia m vga + memcpy failed
On Tue, Sep 07, 2004 at 08:15:47PM -0400, [EMAIL PROTECTED] wrote: That message is from the original freebios. I was thinking that shadowing is not corretly set up and that maybe the segment is write-protected. After setting up shadowing, the chipset my turn on write protection by default, anyway. I don't know how to turn write protection off specifically for the C0 segment. So far, the only reference that I can find about write protection is in the Pentium developer's manual. It says to have bit 16 of CR0 be zero to turn off write protection. That's controlled by the descriptor table flags for the particular descriptor in use. (cs/ds/es) Trying to write to protected memory would cause a page fault that LB probably doesn't recover from. (Are PF:s handled at all?) //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: EPIA-M build problem for freebios2
On Tue, Sep 07, 2004 at 07:48:38PM -0700, Dmitry Borisov wrote: Hi Ron - did ya'll get a chance to work on this at all? no, sorry, will try this week :-) ron C'mon Ron, You just lazy. Jump on it ! Dmitry/ Dmitry, I believe most readers on the list do understand that this was just a joke, but you could've afforded a smiley anyway. I'm just glad that LANL employees are back in the LB business since they have a lot of useful knowledge and experience with the project! //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Soldered flash part recommendations
On Fri, Sep 03, 2004 at 03:55:42PM -0400, Jeremy Jackson wrote: Has anyone run across a prototyping socket for a TSOP? Yes. Emulation Technology has test sockets for TSOP packages. http://www.emulation.com/catalog/off-the-shelf_solutions/sockets/tsop/ I got a quote for single pieces at $15 or so a while back from a local distributor here in Sweden. //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Linux from NTLDR
On Fri, Jul 30, 2004 at 04:07:58PM +0100, Matt Jarvis wrote: A cursory google throws up loads of stuff about doing this : http://www.devhood.com/tutorials/tutorial_details.aspx?tutorial_id=313 http://jaeger.morpheus.net/linux/ntldr.html Personally I would use grub, but each to their own... Without reading any of the above, this is what I do: # in Linux dd if=/dev/hda of=/boot/bootsect.lix bs=512 count=1 cat EOF /etc/lilo.conf lba32 boot=/boot/bootsect.lix root=/dev/hda2 read-only image=/usr/src/linux-2.6.7/arch/i386/boot/bzImage label=lix267 EOF lilo # then copy /boot/bootsect.lix to wherever Windows thinks is C:\ # and add this line to C:\boot.ini in the appropriate section. C:\bootsect.lix=Linux I can see how using GRUB would be especially beneficial under these circumstances but I much prefer LILO anyway. Call me old-fashioned if you like. :) //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Filo Error Help
On Tue, Jul 13, 2004 at 11:35:01AM -0400, David Aubin wrote: Thank yo for the image, but oddly it fails exactly the same way Found initrd block 0 crc error I'm using reiserfs, I'll try ext2. I'm really running out of ideas. For the initrd? I believe only ext2, minix, cramfs and perhaps one other filesystem is actually supported for initrd:s. //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Difference between Linxubios native's Elfboot and Linuxbios native's Filo
On Fri, Jun 04, 2004 at 06:01:56PM +0200, Mathieu Deschamps wrote: What I'am gaining with Linuxbios experience I'll try to give back in somehow i could, don't you feel this ?. I agree! :) I think the lbcc script can be very useful! We had hoped to hash these issues out at the linuxbios summit but were unable to bring that meeting to fruition. Short form: I would ask all involved not to take actions that could lead to consequences we will all regret. I hope this doesn't have to become a big problem, we should be able to just talk about it and straighten any issues out. It has been done online before. Just my EUR .02. :) //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: testbios and the system timer
On Thu, Jun 03, 2004 at 03:32:58PM -0500, Richard Smith wrote:
Peter Stuge wrote:
On Thu, Jun 03, 2004 at 03:56:29AM -0500, Richard Smith wrote:
timer. In numerious locations my Vbios is writing a 0x00 to IO 0x43 and
then does 2 reads from 0x40. So its latching the value of counter 0 and
then reading it out.
Right, it also sets counter mode 0, zero detection interrupt. Are
there any hints of the code actually using the interrupt anywhere?
Um... I don't know. What would I look for?
Someone writing a segment/offset pair to :0020. (I.e. installing
an interrupt handler for IRQ0/INT8.)
I don't thing so but that does explain why linux whines about too
many timer interrutps occurring.
Yes, if the io accesses are let through the emulator to the real
hardware, that's certainly the reason.
You could probably test this, I did some quick testing and it looks
like Linux sets the timer divisor so that timer 0 runs at 1kHz.
Verify this (grep 0: /proc/interrupts sleep grep) followed by
a timed run of testbios. If there are extra interrupts on IRQ 0, the
real hardware was touched.
[..]
Looking at the delay routine is just confusing.
I agree.
There's a comment that says 4 bx counts equals .4290 * 4 or 2uS.
So that tells me the VBios thinks the system timer must be running
at 2.386 Mhz rather than the 1.19318 Mhz my PC hardware book claims.
1193180Hz doesn't change, that's the 4.77MHz clock divided by four,
your hardware book is correct. I used Ralf Brown's interrupt/port
list to refresh my own memory.
All this tells me that I don't understand timer access in a modern
system. The code as written just dosen't seem like it would work on a
4.77 Mhz XT.
It may not neccessarily do so. The M1 is a PCI bus chip, right? I
can easily imagine that ATI didn't make the video BIOS XT compatible
for a graphics controller targeted at newer/mobile/embedded systems.
[..snip..]
This will only skip the jump (and do the BX decrement) if ax is
zero. For ax to be zero the result of the 2's complement
subtraction must be zero or the when the 2 reads are the same
number. But I just don't see how this would happen repeatably
at .6us per ISA IO.
Hmm. Let's have another look at the code.
Ok. Pseudocode:
procedure delay(someunit) {
bx=someunit
dx=read_timer()
do {
ax=read_timer()
ax=-(ax-dx)
if(ax==0)
bx=bx-(bx mod 2)-2
} while(axbx)
}
It doesn't make a whole lot of sense, but eventually the loop will
end, since -(the_original_timer-current_timer) always gets compared
with the requested delay. If the (16bit) timer wraps, bx is
decreased but that's not really neccessary for the loop to ever end.
Conclusion; it not a very precise delay, it's just a suitably short
delay. :)
Ate the timer reads really and ISA IO?
At least they used to be, port accesses on 486/Pentium took forever
and that's when I last did stuff like this and payed any attention
to how long it took. :)
I guess if those reads are happening much faster then it would work.
Where does the timer live now? int the northbridge perhpas? Thats
could be the issue. If the northbridge responded to the IO it
would happen at cpu clock rates and all would be well.
Sure, it's part of the northbridge, but all sorts of buses are there,
I'd just put the timer where it has always been, on an ISA bus, to
minimize breakage. Although, lately I guess ISA isn't included in
chipsets, at least externally. LPC is handy for things like this and
of course runs a lot faster at 33MHz.
//Peter
___
Linuxbios mailing list
[EMAIL PROTECTED]
http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Difference between Linxubios native's Elfboot and Linuxbios native's Filo
On Fri, Jun 04, 2004 at 04:06:41PM -0600, ron minnich wrote: I hope this doesn't have to become a big problem, we should be able to just talk about it and straighten any issues out. It has been done online before. We'll all cool off over the weekend and work it out next week. Sounds good. Kick back and enjoy a can or two of insert favorite beverage here in the sun, if you happen to live near some summer. :) thanks No problem. Hope you all have a nice weekend! //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: testbios and the system timer
On Thu, Jun 03, 2004 at 03:56:29AM -0500, Richard Smith wrote: timer. In numerious locations my Vbios is writing a 0x00 to IO 0x43 and then does 2 reads from 0x40. So its latching the value of counter 0 and then reading it out. Right, it also sets counter mode 0, zero detection interrupt. Are there any hints of the code actually using the interrupt anywhere? I'm guesing that what it uses for delays. Indeed. It's the only way I know for measuring ms without rdtsc. The delay routine is written such that it polls for a rollover to mark the increment of 838.1 ns. For this to happen the latch values must be equal. In a system where the cpu instructions are running much faster than one timer clock cycle I guess would not be much of a problem. 838.1ns is one tick, not a complete 16-bit rollover, right? What I don't understand though was how this ever was reliable. [..] Consider the following: [..asm..] Am I missing somthing? The resolution could be lowered.. Are there any writes to 0x40 setting a divisor? If not, then the snippet will simply not be reliable down to the exact iteration. Since the code uses jb to detect when to stop looping the count doesn't have to be an exact match. Even if an extra tick passes, the loop will still end. I don't think the timing is critical in any other way than that it should be as short as possible to keep the user happy, but with a minimum limit decided by hardware. //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: USB Boot
On Tue, Jun 01, 2004 at 09:42:20PM -0700, YhLu wrote: OHCI usb boot ok now. Agree with Eric, congratulations! :) But it is some slow, only 173KB/S, Full speed should be 12Mbps/8 = 1500KB/s Actually not. 12Mbps is the speed on the USB wire and each of the protocols in the stack and in the application causes some overhead, as you know. I don't know much specifically about USB storage but I'd guesstimate the maximum possible throughput somewhere between 1000kb/s and 1400kb/s. The simplest optimization is to increase the block transfer size to always try to transfer full 64kb, if that hasn't been done already. Great to have a complete USB boot solution anyway! //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Using DATA I/O to burn flash
On Tue, May 11, 2004 at 02:10:56PM +0200, Stefan Reinauer wrote: What format is this image? The LinuxBIOS image itself is just a raw 1:1 image of what needs to be burned to the flash chip. No headers, no bells, no whistles. Often called binary in the programming software I've seen. //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Boot PC from Compact Flash
On Tue, Apr 27, 2004 at 10:19:24PM -0700, manisha s wrote: Hi All, I m new to this mailing list. I want to boot my laptop from 128Mb Compact Flash(CF) Card. On laptop i have already RedHat 9 with kernel version 2.4.22. This has little to do with LinuxBIOS I'm afraid. I downloaded the pebble linux distribution and successsfully downloaded (wrote) this on to the CF. The CF card is available as /dev/sdb on the linux through CF card reader/writer. Your CF reader probably connects via USB and the usb-storage layer in Linux presents it as a SCSI device. I changed /etc/grub.conf file so as to include the CF card title Pebble(Pebble) root (hd0,1) kernel /mnt/pebble/boot/vmlinuz-2.4.22-pebble ro root=/dev/sdb1 title Red Hat Linux (2.4.22) root (hd0,1) kernel /boot/vmlinuz-2.4.22 ro root=/dev/hda2 initrd /boot/initrd-2.4.22.img should i copy the vmlinuz-2.4.22-pebble to /boot directory? GRUB does not include a USB stack. It can not load the kernel from CF. should i change other than this? plz shed some light on this issue? If you really want to boot from the CF, get a 2.5 IDE-CF adapter, search this mailing list archive for URL. If you want to know whether LinuxBIOS could run on your laptop, which unfortunately is unlikely due to the high degree of customization common in laptop mainboards, you should send us lspci -v output. //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: PVR with LinuxBIOS. What board is recommended? Some questions
On Tue, Apr 27, 2004 at 12:02:23AM +0200, Jochen Roemling wrote: Brian Maly wrote: you can do (1) kernel on DoC, use (2) FILO to boot a kernel off the HD, or (3) etherboot to load the kernel from the network. Okay, this is still not quite understood: Currently there are a number of options to the DiskOnChip. LinuxBIOS in itself is quite small, in the tens of KBs. LinuxBIOS initializes hardware and then hands over to a payload. LinuxBIOS and the payload both have to fit in the flash ROM on the mainboard. The payload needs to be in a specific format. The payload can contain a kernel or a bootloader such as FILO or Etherboot or even some other software, e.g. the baremetal toolkit even if it hasn't been mentioned for a while. Both FILO and Etherboot support loading a kernel from various media. FILO is popular for loading a kernel from IDE media, ie. harddisk, CD-ROM, CompactFlash-in-IDE-adapter, etc. Etherboot is the best choice for loading the kernel from the network. FILO and Etherboot are also quite small, also in the tens of KBs. A kernel is the opposite - large. In order to use a kernel for payload there has to be room in the flash memory part on the mainboard and unfortunately this usually isn't the case. 2 Megabit parts are very common these days and 2Mbit == 256Kbyte, so no kernel in there. 4 Megabit parts are becoming popular and with 512Kbyte of room a kernel is feasible, but not really a full-blown one. Rather this would require a two kernel monte where the first kernel loads a fuller-featured kernel from somewhere. This required Eric Biederman's kexec() patch in earlier 2.4, I'm not sure if kexec() is integrated in later 2.4 and 2.6. The DOC was initially used as a trick to get more storage space from the flash ROM - as you might have found, the DOC replaces the flash ROM and allows windowed (aka paged) access to all of the DOC memory through a small window. This works well, but the catch is that only 512 bytes are available for the very first code to be executed when the CPU is reset, and these 512 bytes of code have to initialize the system RAM. This has proved to be difficult at best with current systems. And what about this Etherboot: Can I use some ordinary BootROM? I don't think so. This means, the code on the DoC simulates a BootROM and then does dhcp, tftp and the like? I gues I have to seek out for more documentation. Etherboot was initially developed as a bootrom project targeted at boot ROMs on networking cards. Etherboot has turned out to be very usable for other purposes as well, such as LinuxBIOS. :) Arima/hdama or most of the Tyan's. Tyan may give you a better selection because more motherboards are supported. This assumes you want to dish out some $$$ for an opteron. No, definitely not. I thought about a more consumer-like board with an Athlon or Celeron. SiS630 sounded like a good choise, but the only boards I could find was a Gigabyte GA-6SMZ7, which is nowhere in the stores. Same with the ASUS CUSI. And this EPIA pops up everywhere on PVR pages, but it has only 2 PCI slots... very dificult to decide... Check out the entire EPIA line, I think there are models that combine passive cooling with TV-out, which is why it's popular for TV-things. There has been success with video initialization of the VGA on EPIA boards too, as I recall. However this was in the old version 1 branch and all current development efforts are going into the version 2 branch - each mainboard being moved over in turn. I believe the good people at LANL are working on completing the EPIA support right now. My humble suggestion would be to try to find a suitable EPIA board and use LinuxBIOS with FILO as the payload, and use a CF+IDE-adapter for kernel and system storage. I haven't done any work to support the suggestion, but still it seems and feels like the shortest path to your goal, especially since Ron+Ollie+Greg at LANL and others are working on finalizing EPIA support in v2. :) Hope this helps! (Oh, and feel free to edit this short writeup and put it on the web somewhere to serve as some kind of status report..) //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: tyan s2880 build broken?
On Mon, Apr 26, 2004 at 03:13:51PM -0700, YhLu wrote: I talked to lsi again, and they will do sth. Great news, even if we haven't seen the results. Thanks a lot! :) //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: flash_n_burn rom utils, /dev/bios ... resquest
On Tue, Apr 20, 2004 at 04:37:37PM -0700, Ian Zimmerman wrote: Mathieu I'd rather like to make a backup copy of my bios in another Mathieu chip and then to cold plug this copy to work with Linuxbios. Mathieu Has anyone felt this worry . Same here. I feel that the reliance on hotplugging flash chips has limited linuxbios audience to hard-core metal hackers. While it is obviously true that a number of people in the audience are worried about hotplugging the BIOS ROM I don't think it has a very negative impact yet - LinuxBIOS is getting closer and closer to a very stable release but in order to get there, more hard-core hackers are needed anyway to contribute support for various system components such as CPUs, chipsets etc. Also, any BIOS software probably isn't targeted even at power users - more so at system integrators and/or retailers, who are in a much better financial position for getting pro BIOS tools such as a standalone programmer. On the other hand, there's always the possibility of getting a BIOS-saviour, or even a cheaper model standalone programmer at $200. (They're usually not really good until up at $400-$500 though.) //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: EPIA-M IRQ cvs update [PMX:#]
On Mon, Apr 19, 2004 at 06:10:59PM -0600, ron minnich wrote: I've asked sourceforge about LANL paying them some amount per year for premium service, which would mean you guys would get instant turnaround on checkouts. They've never replied to me on this question. I think they're missing an opportunity with this idea ... Is the turnaround for Savannah equally bad? Do they offer everything that's available at sf.net? (Hasn't this been discussed before?) //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Can I execute a linuxbios image from linux?
On Fri, Apr 02, 2004 at 07:36:32PM +0200, Svante Signell wrote: for my hardware. The crucial thing is whether the BIOS chip is socketed or not. We'll see, at least I know the size is 2Mbit, since the latest BIOS binary (A6120IMS.200) supported by MSI is 261144kbyte. Does anybody have experience with removing a soldered chip on a motherboard without destroying anything? Sure, both PLCC and DIL packages can be desoldered without any problems as long as it's possible/easy to access the chip physically on the board. (A PLCC ROM tucked in close to e.g. a PCI slot is more problematic..) After desoldering the ROM, it's quite possible to fit a socket there instead. shameless plug If you want professional help with this I'll gladly assist. I'm in Malmö. /plug //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: PCI card bios accessibility
Hi! On Wed, Mar 03, 2004 at 06:55:32PM -0800, Tina Declerck wrote: - Does the Linux BIOS do discovery on PCI slots for the existance of cards? Yes, LinuxBIOS enumerates PCI buses behind hosts and bridges. - Will it use PCI configuration space to locate the Basic Address Register (BAR) to locate bios on a PCI card and load it? There is initial work being done with VGA cards and progress indicates that this may actually be possible to do even though LinuxBIOS runs in protected mode and currently doesn't (want to) provide legacy BIOS services. (i.e. int15h et.al.) Specifically, this is regarding a 3ware RAID card. Right. Other peripheral cards vary in their behavior/requirements but I personally think that a kernel driver should be able to do all neccessary hardware initialization beyond PCI configuration. Providing a BIOS onboard a storage controller would be useful primarily for booting legacy operating systems off the connected storage. (Bonus: Hardware becomes architecture independent - runs on anything with a PCI bus.) DISCLAIMER: The information contained in this electronic mail transmission is intended by 3ware for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged and should not be disseminated without prior approval from 3ware I like 3ware and your products in general (just ordered a 7506-4), but I'm afraid that this kind of disclaimer is useless at best, counterproductive at worst - especially in open source environments. Regards, //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: IP get via Etherboot and IP get dhcpcd
On Wed, Feb 25, 2004 at 05:10:44PM -0800, YhLu wrote: Eric, I put the the dhcpcd in the initrd. After boot system with LinuxBIOS + Etherboot + elf ( with the initrd). I found the IP got by Etherboot and dhcpcd is different. I may only used fixed option in dhcpd.conf to make it get the same addr? One explanation would be that Etherboot uses BOOTP while dhcpcd uses DHCP. Try making Etherboot speak DHCP as well. Otherwise maybe you can set up a fake dhcpcd-eth*.info file with the IP, but I doubt dhcpd will approve the request for that same address unless you use a really short lease time. //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: LinuxBIOS....on desktop PCs?
On Wed, Feb 11, 2004 at 10:28:45AM -0700, ron minnich wrote: On Wed, 11 Feb 2004, Peter Stuge wrote: Do you know the LinuxBIOS status on it? Is it different from plain EPIA? it's the 6000 I think, a variant of the -M Yes, EPIA-CL6000E is what I'm looking at. (www.viavpsd.com - Mainboards - Mini ITX - EPIA CL) There's also an EPIA-ME6000 but that doesn't seem to have dual NICs. I figure the numbers just describe the CPU, 5000=533MHz Eden, 6000=600MHz Eden, 800=800MHz C3 and 1=1GHz C3 Nehemiah, where 533 and 600 are fanless. So I guess this means a new port.. -cl that is. Or maybe enough is similar between the three variants that -cl will actually work with one of the two existing ports? //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: stdarg.h and -nostdinc
On Wed, Feb 11, 2004 at 12:45:32PM -0500, Tarl Neustaedter wrote: More likely reflex; posting to the general list leaves your email address exposed on the web for spammers to find and add to their lists. The ~130 spams I receive every day have sharpened my reflexes into almost never sending emails to public aliases. Start using statistical spam filters. I use bogofilter and dropped the daily spam count from close to the hundreds to one or two! I trained it with 200+ MB of spam and ~2GB of ham when I started out though, so it may take a while for anyone starting out fresh to get those results, I like it a lot just the same! :) For Windows clients, there's K9 (keir.net/k9.html) which is a POP proxy implementing the same algoritm as bogofilter. //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: vga emulator new version
On Thu, Feb 05, 2004 at 10:20:05AM -0700, Li-Ta Lo wrote: It is done. We have AGP 8x and HW 3D acceleration now. We can even run tuxracer ;-). Great work! Does it automagically work with many different cards? :p //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: EPIA + SST39SF020A
On Tue, Jan 27, 2004 at 05:10:21PM +, Surjan Singh wrote: Just wanted to highlight a website I found that actually sells the same BIOS chips that are used in the bog standard EPIA board I'd just order them from Memec, a global SST sales agent. (I believe Unique Memec is the right place.) //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: çå¤: K8 northbridge f1 behaviour.
On Fri, Jan 09, 2004 at 08:27:55AM -0700, ron minnich wrote: [..] the 8111 is the pci connection. register 3e.b in 8111 is set to 0xf, which should pass vga i/o to the pci bus. the vga card, using Ollie's 'userio' program, does not respond to byte accesses to 0x3cc or 0x3d4. Under normal bios, all these register settings are the same and ... the card responds. It seems you've solved this now, according to the later success report. Excellent news indeed! :) I would've suggested a modified POST card or logic analyzer to see if the writes made it to the bus. This is somewhat more of a LAN approach to diagnostics, but might have helped anyway. LAN bridges also tend to just make packets disappear mysteriously. What was the problem, anyway? //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: serial programming
On Sat, Dec 13, 2003 at 10:52:20PM -0700, ron minnich wrote: On Sun, 14 Dec 2003, Peter Stuge wrote: I'm not quite sure about the status of the EPIA port in the version 2 CVS tree, but it's there and there's been work put into it so it should probably compile and work just fine. EPIA is fine in V2, not perfect but FAR better than EPIA in v1. We want to clean up EPIA completely, then fix up EPIA-M, but there have been some distractions (SC '03). Ah, yes, that's right. I can't wait until I actually have the time to sit down and do something with LinuxBIOS, last time was over two years ago, there's been an amazing evolution of the code. I can easily imagine running LinuxBIOS 3 or 4 on _MANY_ systems in another year or two. It seems vendors (like Tyan) are picking up too, which is great. Just don't take over all of their competent people over at LANL, at least not until there's support for all of their boards in the tree.. :) Just a short note to celebrate your success. :) //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: sis645dx
On Fri, Nov 14, 2003 at 12:05:12AM -0800, Erdem Guven wrote: Hi, I want to run linuxbios on a sis645dx board. I think there is no support for this chipset. Can someone give me some advice about: - compatibility with sis630 or other supported chipsets No idea about this one. - Is it a good option to copy necessary parts from original bios and past into linuxbios? Absolutely not, since the original BIOS is not likely something you have the right to duplicate, and even less put under the GPL. Please don't send us code (disassembly) from it either. You are however more than welcome to contribute fresh code that you've written yourself and put under the GPL, that will get the chipset running. Look at the existing code for SiS chipsets and start comparing datasheets, would be my suggestion to get it to work. //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: LinuxBIOS and ISA slot on PCChips M787CL M/B
On Fri, Nov 14, 2003 at 08:10:13AM -0700, ron minnich wrote: On Fri, 14 Nov 2003 [EMAIL PROTECTED] wrote: I am migrating LinuxBIOS from vt5426 to PCChips M787CL( NB: VT8601 ,SB: VT82C686B),and I want to use ISA slot.I think that LinuxBIOS doesn't need to initialize ISA slot, the devices on ISA bus should work,but I am wrong.So does LinuxBIOS need to initialize the ISA slot? You actually can't do much with that slot. ISA is a mess. There is no way for linuxbios to do anything because there are no configuration registers to read in ISA to help configure. So I am not sure what you should do. The slot can't be configured, but the ISA bridge is on the PCI bus and thus configurable. If it's configured appropriately at least the ISA bus will be active. Whatever card is put in there will need further configuration however, and that's not really standardized. There are two common ways that I know of to do it, but neither is very good. One is scanning for extension ROMs, card ROMs may need a full PC BIOS. The other is ISA PnP that uses a couple of reserved ports for allocating resources to the cards. Linux can do Plug-and-Play configuration in kernel and in userspace. //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: SC1200 and framebuffer under 2.4.22 without having vga-bios or VSA-bios is up
On Tue, Oct 28, 2003 at 04:53:08PM -0600, Bari Ari wrote: Just heard that AMD is doing away with the VSA nonsense on all the Geodes and opening up all the register specs for what used to be only controlled via the VSA binaries. Excellent! Even if they're doing it only on new Geodes the information could still be useful for older ones, since many parts are probably still the same. //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: AMD64: Something's missing?
On Wed, Oct 22, 2003 at 05:31:46AM -0500, Evan Langlois wrote: The boot image in this case would be a proprietary piece of software for real-time network filtering. The algorythm for which is patented technology. A user-input encryption key doesn't make sense as the box is stand-alone and does not have an operator. A simple encryption at least stops someone from removing the drive (or flash disk) from the system and reverse engineering it. Granted, they can get the key from the ROM, but if they have to disassemble the ROM to do it, it might slow things down. Maybe by a day. It would at least be better protection than a non-encrypted system being booted by the PC BIOS. IMHO it's hardly worth the effort. A skilled individual would probably not need more than a single day to bypass it, while it will take several working days to create. Instead, use dedicated hardware for decrypting, and require it to be present at boot. (Smart cards come to mind.) iSecure - CyberWarfare Defense www.dDoS.com Ehrm.. This email is intended for the addressee only. The material may be privileged and may contain confidential information. If you have received this email in error, please notify Melior, Inc. immediately by email and delete the original. Thank you Please do not send expressly confidential email to public mailing lists. Thanks in advance for reconfiguring your mail system. :) //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: AMD64: Something's missing?
On Wed, Oct 22, 2003 at 07:55:56PM +0200, Evan Langlois wrote: The smart-card suggestion someone posed might be an idea. I like the Schlumberger (now: Axalto) Cryptoflex[1] (NB not Cyberflex) cards a lot. I have a few e-gate 32K[2] cards that I'm playing with here, I'm using the USB token, but i was told they can be used in serial card readers as well. I use them with OpenSC[3] and OpenCT. //Peter [1] http://www.cryptoflex.com/ [2] http://www.reflexreaders.com/Products/e-gate/e-gate.html [3] http://www.opensc.org/ ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: AMD64: Something's missing?
Hi everyone. This has a lot of basic stuff probably already well known on the list, but I figured it might help someone. Felt like documenting a little. :) On Mon, Oct 20, 2003 at 11:10:54PM +0100, Terry Blunt wrote: I *very* much like the idea of having as much of my system as possible open-source, and I'm also keen on the fast start-up the website suggests However, I'm concerend at the possibility of trying to re-flash my bios, making a mistake and finding I have an unusable motherboard. This is a very valid concern. Later on a rom-o-matic could be set up where you just pick your motherboard and desired configuration using a web form and then download a new BIOS image with instructions for flashing it onto your motherboard. If you flash an image which isn't for your specific board, the system will not start (at all!) and you will have to remove and reprogram the flash memory chip outside your computer. (Messy for end users, done several times a day by developers.) Flash memory chips soldered directly to the mainboard is not uncommon, so people really have to beware. Can someone help me get a clearer understanding of what is involved? A legacy BIOS does lots of stuff at boot, and then finally tries to find an operating system bootloader in the MBR (Master Boot Record, sector 0) of the first hard disk. (Subject to configuration in the BIOS setup menus, CD-ROM, floppy, second hard disk etc..) There are two common bootloaders for Linux written for the legacy BIOS; LILO and GRUB. I prefer LILO, maybe because I'm too stupid to see the beauty of GRUB. LILO is installed to the hard disk by running /sbin/lilo in a Linux system. Usually this is done from a distribution installation floppy or CDROM. Before LILO can be installed, you have to tell it where on your harddisk the Linux kernel you want it to load is, often done automatically by installers. (Config file: /etc/lilo.conf) /sbin/lilo will store the physical location(s) of the kernel (it can be scattered throughout the disk because of how filesystems work) so that LILO can read all these pieces at boot without knowing how the filesystem works. LILO then jumps to the kernel. The kernel does early setup, including switching text modes and getting the CPU out of the hideous 8086 (popular CPU back in 1979 or so) compatibility mode that all x86-compatible CPUs start up in. When the kernel is done initializing subsystems, it executes /sbin/init, which forks according to /etc/inittab. LinuxBIOS differs in many ways but for this purpose I'll only mention the bootloader, because it's the most obvious high-level difference. (Low-level differences are numerous and very good, however!) LinuxBIOS is designed to live with a bootloader, or payload, in flash. Originally a Linux kernel was intended to be used as the bootloader, and while this is cool and works very well, motherboard manufacturers don't currently ship boards with large enough flash memory chips for this to be viable in the mainstream. Instead, a couple of other payloads are used/developed. EtherBoot, FILO and 9load come to my mind right now. Sorry about those I forgot. (BarebonesTK?) EtherBoot can boot lots of things from the network or an IDE hard disk. FILO can boot from IDE hard disk, IDE CDROM, floppy, and maybe more? 9load I don't know much about except that it is used to load the plan9 kernel. Short-term, I think LinuxBIOS+FILO will be the most common OSS BIOS, mainly because of the limited size of flash memory. Hopefully, when vendors realize that people want to buy motherboards with LinuxBIOS+Linux, they'll put larger flash on them. (The board would still be cheaper, since there's no license fee to pay for the proprietary BIOS.) Hope this helps. :) //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: LinuxBIOS high level overview [was: AMD64: Something's missing?]
On Tue, Oct 21, 2003 at 10:26:01PM +0200, Evan Langlois wrote: I don't know much about FILO. I should have included the URL where it lives: http://te.to/~ts1/filo/ Sorry about that. Can anyone comment on its compatibility with the LILO graphical features (displaying graphical menus/splash screens), and is there any support available for encrypted filesystems? Graphics may not be up when FILO runs, LinuxBIOS does not have a waterproof way of initializing all graphics controllers yet. (See list archives, search for VGABIOS.) Assuming FILO works like LILO, and doesn't know about filesystems, I'm assuming encryption would be difficult, and it might therefore be best to chain-load another boot-loader, but I'd want the encryption keys to be in the ROM to make it as difficult as possible to get to them. Encryption keys should be in the user IMHO, but this is another discussion entirely. The ROM is anyway very easy to get information from, assuming the system boots from it. (There's limited use of a disconnected ROM though..) Encryption in the BIOS itself may be a positive feature, not just for corporate users that want to protect their IP, but laptop users and such (in which case the key would be asked for on boot) that don't want sensitive information leaking out just because a laptop was stolen. Yep, this is a good idea. See http://www.nah6.nl/products/secure-notebook/ //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Windows-based terminals - what can be done?
On Tue, Sep 23, 2003 at 05:04:37PM -0400, Thomas Fritz wrote: I have access to a few WBTs at a surplus place, and I've dug up the specs on them: Cyrix Pentium clone - 266MHz up to 128MB SDRAM ports: PS/2 keyb/mouse, 2 USB 1.1, 2 serial, 1 parallel, 10/100 ethernet, and sound in/out the chipset(s) include a SuperIO 97317, and a CS5530 (which handles the soundblaster compatible sound and presumably the video). Expect this to be a GX1+5530, or maybe even a Geode (SCx2xx) system. LinuxBIOS is running on both those platforms and there is some kind of support for the 97317 in the freebios tree, but findgrep yields nothing in freebios2, I guess it simply hasn't been ported over yet. The board has an Award BIOS little square-like ROM, This is probably a regular flash ROM in a PLCC package. and a larger 8MB ROM which holds Windows CE. What kind of ROM is this, exactly? Can you peel off the label and read what's printed on the chip(s)? There are also various places on the board which could have had various optional features, but there is no IDE, floppy, etc...but I think if I solder on a PCI slot where it belongs I could hack some more funtionality onto it for testing. The CS5530 and SCx2xx (which have the 5530 integrated) have IDE, but there may just not be a connector for it. The IDE pins may also be multiplexed away for some other use in this particular system. I've been thinking of how to go about hacking this thing, and the easiest method I'd like to try first: Burning a new ROM to replace the Windows CE version. I doubt this thing would be easy to flash the BIOS, if it even had that capability. Maybe, maybe not. With a little luck the HW designers have wired the flash memory to always be writable, given the right software commands of course. I'm not looking for graphics, a text screen will be more than sufficient. Either should be possible. On this, I have two questions: What's my chances for success (educated guesses?), and has anyone done something similar? I'd say you'll succeed given time, you will have to learn the quirks of this particular system and then likely make a port of freebios2 to it. These two processes are usually concurrent. If it's an SCx2xx system, check out the nano stuff in the freebios tree, and port it to freebios2. :) //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: NS Geode GX1 + CS5530 +PC 97317 superio
On Mon, Sep 22, 2003 at 10:15:40PM +0530, [EMAIL PROTECTED] wrote: Hi , How do I extract the VGA BIOS from the Insyde ExpressROM??the same way as in case of the EPIA will work? ANd in that case ... how can we find out IF it uses some calls that are implemented in the underlying XpressROM BIOS ?? XpressROM is a minimalist BIOS sold by Insyde. XpressLOADER is another name for the BLDT, available from either Insyde or NSC. (I believe it's still NSC.) BLDT is the Boot Loader Development Toolkit and contains some building blocks for making a BIOS similar to the XpressROM but lacking a few features that may or may not be critical. ACPI and various legacy BIOS services e.g. The BLDT is (was) available free of charge and IIRC you're even allowed to develop open source software after reading it. Don't take my word for this though. See if you can get hold of the BLDT, I think it'll make things a lot easier than dealing with XpressROM, especially when what you really want to do is run LinuxBIOS. :) //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: NS Geode GX1 + CS5530 +PC 97317 superio
On Tue, Sep 23, 2003 at 09:18:48PM -0400, Gregg C Levine wrote: -Original Message- XpressLOADER is another name for the BLDT, available from either Insyde or NSC. (I believe it's still NSC.) Perhaps. But NSC's webpage insists that they have indeed sold the entire line to AMD, and that presumably included software tools, and even development support. Right, I had known this if I hadn't been sending emails after a long day of powerfail recovery and stress. Thanks for refreshing my memory though! :) //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: about VGA support in voyager2 board
On Wed, Aug 27, 2003 at 04:14:42PM +0900, SONE Takeshi wrote: you need to confirm that int #5 is a VSA interrupt of some sort. I don't know what VSA is, but int 6 is the Invalid Opcode Exception, VSA is the name of a NSC system to allow for software implementations of legacy hardware. VSMs (Virtual System Modules) load themselves e.g. from option ROM or part of the BIOS and tell VSA that IO reads and writes to this-and-that address should be trapped, and sent to the VSM for proper handling instead. E.g. audio and USB require a VSM on SCx2xx/GX1+CS5530 systems, which I believe the voyager2 is. Unfortunately I don't remember if VSA can be used to trap interrupts as well, but I agree with Ron and Mr. Takeshi that this is likely the VGA BIOS scribbling over the interrupt table, if that's located at 400h. //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Information about BIOS and the boot process
On Fri, Mar 28, 2003 at 11:50:03PM +0530, Deepak Kotian wrote: Thanks Ron. The documentation would do a lot of good to many in the forum for the new comers (including me) Lot of queries should get resolved automatically. The cvs seems to have support of lot of motherboards now, but I guess, the knowledge/experience seems to be with the one who have supported those boards only. If the implementator of LinuxBIOS for the respective motherboard spends even 8/10 hours to produce a document of his flow or Design, it would benefit a lot. 8-10 hours is a lot of time, unfortunately. [..snip..] These are just suggestions, there may be better way or means to do it though. I've suggested setting up a wiki in another similar situation where relatively few and busy people had specific knowledge about the system design. I'm pretty sure it will work out well. PhpWiki looks nice, at http://phpwiki.sf.net/ but I didn't get it to run immediately when I tried setting it up. I have a slightly unusual configuration running however so it might just be my bad. My $0.02. //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: semi-ot: sis900 lan support
On Thu, Mar 27, 2003 at 08:29:48PM +0100, Alessio Sangalli wrote: Steve Gehlbach wrote: I tried a 954MB (ls -lh) file on pcchips 787cl+ (sis900, via C3, 320Mb ram), and it took 22:20 using scp, no compression. Since I have a 10baseT network, using ssh, and other traffic, this seems about right (700+ kb/sec). Kernel is 2.4.18, sis900 driver v1.08.02. Is it possible to force the network at 10Mbps even if there is a 100Mbps capable cable? Sure: mii-tool -F 10baseT-HD eth0 (for half duplex) mii-tool -h for more options. //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: CT vga - newbie quests
On Thu, Jan 23, 2003 at 10:19:19PM -0500, John van Vlaaderen wrote: Thanks Peter, but... maybe i should have said: ...In relation to LinuxBIOS... We know what X and a vgabios are -- what I am asking about are references on this mailing list to writing X into a vgabios -- maybe VIA -- using code from the bochs vgabios -- or something like that -- along w/ Xfree86 XFree86 v4 have some provisions for using a VGA BIOS. If you have a VGA BIOS in the system you can get XFree86 running. (Although not at the highest possible speed with the highest possible resolution or colour depth.) Framebuffers are new to me, never really thot about them, I am looking of DirectFB right now and it really seems like an acceleration process, so I am wondering why it keeps appearing in LinuxBIOS mailing lists. Many people are used to having a standard keyboard and a monitor attached to their computer system, a console. Because VGA BIOSes often rely heavily on legacy BIOS services (sorry, should've mentioned this part yesterday) these VGA BIOSes cannot be utilized in LinuxBIOS (yet) because LinuxBIOS doesn't provide these legacy BIOS services (interrupt services, int 15h etc. Search Ralph Brown's interrupt.lst for the keyword BIOS. :) yet. There is work underway to add needed parts from the Bochs project's GPL legacy BIOS to LinuxBIOS, which would also allow all VGA BIOSes to work. The VGA BIOS and the framebuffer driver serve the same purpose, to activate the monitor connected to the graphics adapter in the system. This is more relevant in some cases than other. For a GPL desktop system you'd want it. For a cluster node you couldn't care less. The VGA BIOS has an advantage over the framebuffer in that it will be initialized somewhat earlier, on the other hand I suspect that much of LinuxBIOS's hard work will already be done when the VGA BIOS gets initialized so LinuxBIOS debugging will still be best made through the serial port. The VGA BIOS is also closed source, of course, which is to it's disadvantage. What is envisioned for getting X running from LinuxBIOS ?? Clusters obviously have no need for them, but there are huge hungry embedded people out there. I would like to join the fray with some useful information. If all you want is X and don't care about the Linux text console, you'll need either a VGA BIOS or a native graphics chipset driver in the X server. If all you have is the VGA BIOS the X server will have pretty poor performance. Only part of the need is being kewl, the more important issue becomes getting proprietary code out of the PC completely, as dictated by the GNU religion, and gaining support among the youth. It's coming. It's just taking some time. The PC architecture is about 20 years worth of kludges on top of each other. //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: CT vga - newbie quests
On Fri, Jan 24, 2003 at 01:14:53PM -0500, John van Vlaaderen wrote: I am writing a glossary right now and I need to know the difference between: vgabios, framebuffer and X Wow, ok, not that this is the best place, but ok. LinuxBIOS is currently mostly operational on what's commonly referred to as the PC platform. The last standardized graphics controller on this platform was the VGA. (Video Graphics Array) This VGA card had a BIOS that would initialize the card when the main system BIOS traversed all expansion cards looking for any BIOSes on them. The VGA BIOS knows the details of how to program the graphics card. The VGA BIOS is closely tied to every single hardware. Different graphics chipset - different VGA BIOS. Graphics chipset makers are often reluctant to release detailed programming information for their chipsets, but a VGA BIOS is always included with the card. So if LinuxBIOS can make use of the VGA BIOS it is trivial to use the computer screen e.g. for startup debugging. 'framebuffer' has a couple of different meanings. One is the video memory on the graphics card. Another is the Linux drivers for accessing the said memory. Writing a Linux framebuffer driver requires the same detailed programming information as for a VGA BIOS. Framebuffer drivers aren't all that common, it has become sort of a niche, used frequently for Set-Top-Box and other embedded systems. (Reference: DirectFB.) Think of the framebuffer drivers as a VGA BIOS in Linux for Linux, it allows Linux to know all (or at least a lot) about the graphics controller in the system. X is usually short for X-Windows which is the windowing system providing core GUI functionality in almost all available Unix systems. When open source people say X or X server they're often talking about XFree86, an open source X-Windows server. The X server also needs detailed knowledge about graphics chipsets, in order to provide and perform the desired functions in an efficient manner. Short summary: The VGA BIOS, a framebuffer driver and the X server all need detailed info on programming the graphics controller. They differ in whom they provide services for. The VGA BIOS provides services mainly meant for MS-DOS and other classical textmode applications like LILO and Linux itself. The framebuffer driver provides services mainly meant for Linux and is also a part of Linux. The X server provides services to X clients and/or the window manager. All programs run in X are X clients. Hope this clears it up. //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: CT vga - newbie quests
On Fri, Jan 24, 2003 at 01:14:53PM -0500, John van Vlaaderen wrote: Hello - confused newbie here !! The linuxbios chat, I can follow but I am very intrigued by the vgabios since it will help linux on the nanofront and advance my own thinman model *** I am writing a glossary right now and I need to know the difference between: vgabios, framebuffer and X I wonder why you didn't google for these first, btw. Would've given you a big part of what I wrote in the other mail. //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Option Parameters for Linuxbios.
On Sun, Jan 12, 2003 at 03:29:52AM +0100, Peter Stuge wrote: On Sat, Jan 11, 2003 at 12:48:06PM -0500, steven james wrote: biosbase 0x The BIOS image will begin at the biosbase address in the CPU's memory space imagephysaddr or stage1physaddr Doh, forget I wrote stage1physaddr there. Sorry. //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Help NS Geode experts
On Thu, Jan 02, 2003 at 12:40:37PM -, James Finnie wrote: I currently use the /dev/bios work for flashing BIOS in a production evironment on a GX1+5530A platform. It works great. It may not work out of the box for SC2200/SC1200 (I have no experience on these platforms), but it would be well worth getting it working - it supports a large number of different flash parts and provides a great interface. Sounds like Adam has already done the hard bit! One issue might be that most SCx2xx-platforms probably wire up the flash CE and WE differently, and they need to be enabled before any writing to the flash will work. Register hunt, anyone? OTOH, if you're working on flashing LinuxBIOS on a platform you might already have access to the neccessary documentation, it's needed for tweaking the configuration as well. //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: LinuxBios on SC2200 board from National
On Sat, Dec 14, 2002 at 04:19:12PM +0530, Yogesh Desai wrote: ** Proprietary ** Please refrain from sending confidential, proprietary or similar emails to public mailing lists. It makes it unclear whether we are allowed to read your email and answer your question(s). Please also note that emails sent to public mailing lists usually end up archived somewhere. We have SC2200 board from National and being trying with ExpressROM biose code given by National. Will it be advisable to boot the board with LinuxBios and still use all the pheripheral interfaces and displays. Please help Judging from this you want us to read and reply so here goes: Christer Weinigel has implemented support for the SCx2xx Geodes in LinuxBIOS. Check out the nano platform in the source tree. Some of the features in the Geode depend on VSA helper ROMs however and there is currently no VSA support in LinuxBIOS. In effect this means that you can't use XpressGRAPHICS or XpressAUDIO (yet). The kernel framebuffer driver from NatSemi will work just fine without XpressGRAPHICS though - it's just legacy VGA emulation that doesn't work. XpressAUDIO is required for the NatSemi Linux OSS driver to work, so no sound will be available. There has been talk about implementing support for VSA2 in LinuxBIOS and some discussion on licensing issues for the VSA ROM blobs included with the BLDT (aka XpressLOADER) but no code has been written yet. This might partly be because we're out of documentation and maybe partly because noone has really needed it yet. //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: LinuxBios on SC2200 board from National
On Sat, Dec 14, 2002 at 06:13:33PM +0100, Stefan Reinauer wrote: * Peter Stuge [EMAIL PROTECTED] [021214 16:04]: The kernel framebuffer driver from NatSemi will work just fine without XpressGRAPHICS though - it's just legacy VGA emulation that doesn't work. Which version of the fb driver did you use? I did not get any light on the screen with the 2 versions I tried, neither on TV out nor on VGA out. With the original Award BIOS (not XpressROM) it works. I haven't tried it myself but it was my understanding that it would work, I believe I've read success stories on this list.. But I might be wrong. My own experience is from the BLDT mostly if not always including XpressGRAPHICS, and even then the kernel framebuffer wouldn't work if I set the video RAM size to anything but 4MB. That might be something worth checking out for you. Any other setting led to black output or stray green pixels here and there. There has been talk about implementing support for VSA2 in LinuxBIOS and some discussion on licensing issues for the VSA ROM blobs included with the BLDT (aka XpressLOADER) but no code has been written yet. This might partly be because we're out of documentation and maybe partly because noone has really needed it yet. The documentation would probably not be a problem, but the question is whether the code that allows loading VSA modules is not NatSemi IP. The one in XpressROM and the BLDT surely is, but I don't think they can claim rights to someone else's work if they've granted access to the relevant documentation.. //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: National Semiconductor Geode GX1 ?
On Sat, Nov 30, 2002 at 12:30:35PM +0100, Christer Weinigel wrote: IIRC, the VSA2 BIOS requires a few INT 15H services to work, so with Bochs in LinuxBIOS it should be possible to just do as you say. The exact procedure is documented in some NatSemi document that I don't know if I have access to anymore. I've seen references to int 15h function 4358h (VSA Init Callbacks) and the two documents titled VSA/BIOS Porting Guide and Virtual System Architecture BIOS Porting Guide seem to be what you're referring to. How about the licensing? I think the VSA BIOS freely available from NatSemi if one gets the XPressROM kit from them, but what does the GPL say about calling a binary object? In my mind there is no linking done if a GPL:ed application contains a binary blob which it uncompresses into memory and then jumps to an address within the blob, but people were quite anal retentive about GPL:ed applications using the Qt toolkit a few years ago, so there could be trouble. I've seen Linux kernel drivers that contain blobs, usually some microcode for some chip on the card, and are licensed under GPL. The binary blob can have a separate license however. See e.g. the license for tc990image in http://support.3com.com/infodeli/tools/nic/linux/3c990-24-1.0.0a.tar.gz in the file 3c990.c. (This is a NIC with some IPSEC helper functions.) //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Geode Kernel Config
On Tue, Nov 26, 2002 at 06:45:45PM -0500, Adam Bezanson wrote: Hi, I've got an Eval card from National Semi that contains the SC1200. I'd like to try LinuxBios on it. I've downloaded both the 2.4.18 and 2.4.19 kernels to start with. What patches do I need to apply to the kernel? Is there a config file I can use to configure the kernel, or should I do it manually? You'll have to set up a new mainboard directory for the evaluation board configuration where lots of details about the board have to be entered. It isn't all that hard but wading through the data sheet to learn the architecture and all of the registers took me a while. //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: DOC ATA Modules EPIA DOC
On Mon, Nov 04, 2002 at 10:20:28PM -0700, Ronald G. Minnich wrote: Just cut the appropriate bus line? nope. then you can't write control registers. On Tue, Nov 05, 2002 at 12:35:28PM +, Justin Cormack wrote: Just cut the appropriate bus line? No, but you can buy CF with a write protect switch (with some difficulty). It cam up once before on this list I think. Of course. I do remember that there was a write protect jumper on those SST ADC:s however, it just controlled some ADC logic I guess. I even made our prototype adapter but managed to forget this anyway. :) //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: DOC ATA Modules EPIA DOC
On Mon, Nov 04, 2002 at 06:39:16PM -0500, Nicholas Mistry wrote: I am looking finding alternatives to having a physical harddrive in my machine, i was wondering if anyone here has experience w/ either of the following. My goal is to boot LinuxBIOS out of flash, and then Linux off a Solid State Devices. Probably a very common solution while mobo makers stay at 2Mb flash. ATA-Disk Module SST58SM128 http://www.sst.com/products.xhtml/mass_storage/58/SST58SM128 or similar from Apacer http://www.apacer.com/product/flash/index_adc_adm.html I've used an SST ADC with great success. Worked swell. Currently i am using CF w/ an ATA - IDE adapter. I have not found a way to write protect my CF data. Just cut the appropriate bus line? I am still looking into the DOC option for the EPIA motherboard, via has not replied to any of my requests as to what type of chips are supported on the DOC PAD on the EPIA-800e motherboard. Anyone know more about this? This would be nice, hopefully they run with one of the usable DOCs. :) //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: copy extended memory.
On Sun, Oct 27, 2002 at 07:05:58PM -0500, Adam Sulmicki wrote: you can find nice example how to use it in linux sources (some file in linux/arch/i386/boot, head.S IIRC) Using it is the easy part, I had to implement it. Fortunately that project got dropped before I tore all my hair off. :) For example the description in Phoenix's user manual is just plain wrong :/ It will describe an single GDT entry, but it will not say how many entries and what is meaning of each entry. http://www.phoenix.com/resources/userman.pdf Some resource, huh? Good thing we have RB. And don't forget the 32-bit opcodes when in pmode. Isn't that dependent on D/B flag in appropriate GDT entry? So if I set 16 b it D/B flag in the CS entry, I still should be able to use 16 bit code, even if in 32 bit mode. Yes! This is, of course, absolutely correct. I just wasn't familiar enough with the descriptor flags. Now I actually know enough to make my own DOS extender. :) (Well, probably not, but a little closer.) I haven't found a complete descriptor description so I'll post an attempt here. It's basically just different parts of 386intel.txt put together. (That file sure isn't very well structured. Much like the architecture itself I guess. :) DESC STRUC lim_0_15DW 0 ; limit bits (0..15) bas_0_15DW 0 ; base bits (0..15) bas_16_23 DB 0 ; base bits (16..23) access DB 0 ; access byte ; access := P DPL RES1 TYPE [A] ; P:1 Segment present (eg. for swapping to disk) ; DPL:2 Descriptor Privilege Level ; RES1:1 Means this is an application (as opposed to system) segment #if RES1.value ; TYPE:3 Indicates what kind of segment this is and the intended use ; A:1 Accessed bit, set by CPU when the segment is used #else ; TYPE:4 Indicates what kind of segment this is and the intended use #endif granDB 0 ; granularity byte ; gran := G (B|D|X) O AVL lim_16_19 ; G:1 0=byte granularity, 1=page(4k) granularity #if RES1.value #if IS_DATA_SEGMENT ; B:1 Big segment (affects segment bounds) #else ; D:1 Default, determines default operand-size for code segments #endif /* IS_DATA_SEGMENT */ #else ; X:1 unknown, unused? #endif /* RES1.value */ ; O:1 unknown, used for protection? ; AVL:1 Available for use by systems programmers ; lim_16_19:4 limit bits (16..19) bas_24_31 DB 0 ; base bits (24..31) DESC ENDS //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: The DoC problem
On Sun, Sep 08, 2002 at 08:24:35PM -0600, Ronald G Minnich wrote: Anybody have a good idea in the long term about how to solve the DoC mess. Maybe put the DoC on the ISA bus? Will require a special LinuxBIOS PCB but only when you really want/need DoC.. M-Systems has an AN on this, I think it's #71 or #91 but I'm not sure. //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
