Re: Booting Linux using netboot and HD
On Fri, Apr 22, 2005 at 10:20:36AM -0700, Nathanael Noblet wrote: [..FILO..] > >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. > > Not so, according to his first email, the linux install (RH 9 I think) > booted fine from the local system prior to LinuxBIOS installation. I was thinking that Red Hat might always use some kind of initrd that loads modules and without it those drivers had to be in the kernel. I actually don't remember whether FILO can deal with initrd:s as well. > Obviously LinuxBIOS seems to be working, unless his problem is that the > IDE controller is not detected or interrupts are off (not right). This could very well be the problem, Beneo, could you post the complete output you get from starting the system with LinuxBIOS? > Thus the installed kernel should be able to boot again without > modification using FILO. If FILO does initrd:s, yep. On Fri, Apr 22, 2005 at 10:40:32AM -0700, beneo wrote: > I have one more question on the comment Peter made, > >Peter Wrote: > > 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. > > My question is, if initd-2.4.20-8smp.img doesn't understand ext3 and > don't have IDE driver, why I can boot everything from HD using AMI > BIOS? The initd-2.4.20-8smp.img is the same for both LinuxBIOS boot > and AMI BIOS boot. Sorry, I copied-and-pasted the wrong filename, it should have been the kernel file /boot/vmlinuz-2.4.20-8smp, not the initrd file. The initrd has modules for ext3 and the IDE driver, they aren't in the kernel. I guess both drivers load with AMI BIOS but the IDE driver doesn't load with LinuxBIOS. This actually indicates that the IDE controller wasn't initialized properly by LinuxBIOS, just as Nathanael wrote. Try compiling a fresh kernel with support for your IDE chipset, make an ELF image out of it, boot the target system and send all of the output from the boot to the list. I'm afraid any IDE driver messages that could help find the problem will get lost if an initrd tries to load the driver as a module. > I assume after ramdisk loaded, Kernel would rely on Linux IDE > driver and no longer make any BIOS hard drive service call, right? Yep, that's correct. But the IDE driver can be included in the kernel from the beginning too, that way it will try to load much sooner and you'll be certain not to miss any messages from the driver being caught and hidden by klogd on the initrd. //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: 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 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: 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 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: 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 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: 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
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
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: 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 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: 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: 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_PAGE&nodeId=1335&dDocName=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: 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: 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: 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: 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 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: 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: POST cards [was: speaker beeper]
On Wed, Jan 12, 2005 at 09:11:32PM -0700, Eric W. Biederman wrote: > I keep having problems with not having a 5V 32bit PCI slot or an > ISA slot... What are good features for a POST card besides being a Universal board? (dual voltage) I will probably be designing one for a customer later this spring, and while they have a few feature demands I think this list can offer good ideas as well. :) I've seen memory on POST cards, giving scrollback of the last 32 seen codes, but I'm not sure how useful that is.. //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: 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: 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: 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: P4 powerup register value
On Thu, Sep 30, 2004 at 03:59:10AM -0700, zhu shi song wrote: > When p4 power up , what's the value and meaning of the > registers such as ebx, edx etc? > Who know the information, need help. Hmm? eax, ebx, ecx and edx are the 32 bit standard registers that have been around since the 386. I believe they don't have any meaning at power on. Their values, if defined, would be listed in a programming manual for the P4. (Or the 386.) //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: 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: 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: [PROPOSAL] extended payload handling
On Tue, Jun 08, 2004 at 12:14:56PM -0700, Frank wrote: > I am not trying to flame or put down LB. I'm just trying to > point out it's shortcomings. Thanks! I think you'll be glad to see that a lot has changed since your last visit, no thanks to me though. :) Since you're familiar with the problem I assume you've also had your share of x86 bugs and un/misdocumented "features" - which also have had some effect on LB structure, since noone really knew about the horrors in some of the mainboards/chips/configurations out there. //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 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: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(ax 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 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: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 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: 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: 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: Open bios dev/bios bug report
On Thu, Apr 22, 2004 at 04:42:48PM +0200, Mathieu Deschamps wrote: > > > > > I want to make /dev/bios work because LinuxBIOS flash utils just > > > write whereas /dev/bios is IMO a elegant way to read/write/>? to > > > many bios. > > > > If you're going to do that why not just use MTD? > > If it works it is pretty ideal. > > short answer: True this is the final goal. > > other answer: This because of I gave myself several milestone before > getting a LinuxBios booting my littlish kernel on DOC for embedded > station. MTD is for all Memory Technology Devices - not just DOC. See http://www.linux-mtd.infradead.org/ and then enable it in your nearest kernel. :) //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. If you want professional help with this I'll gladly assist. I'm in Malmö. //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: 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: 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: LinuxBIOS....on desktop PCs?
On Wed, Feb 11, 2004 at 08:10:55AM -0700, ron minnich wrote: > there is a variant epia mobo which would make an ideal > router/filter/whatever, it has two enet ports. Do you know the LinuxBIOS status on it? Is it different from plain EPIA? I'm going to use it (it's the EPIA-CL) for a project in a few days, but I need to deliver ASAP so I wont have much time to tinker, although I could make a few tests, and it would be neat to ship it with LinuxBIOS! :) (It would of course be even neater if it shipped to me with LinuxBIOS, but that's the next step.) //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: serial programming
On Sat, Dec 13, 2003 at 08:39:44PM -0800, Parit Wattanasin wrote: > hi, I'm new for LinuxBIOS. I have problem about my > mainboard(VIA-EPIA) Now I'm use LinuxBIOS but I want > to customized it to chang payload from etherboot with > my program about serial port(now this mainboard use > serial console) how can I'change it(my program use > assembly). Thank you for answer The payload can be exchanged from Etherboot to another self-contained ELF file simply by recompiling LinuxBIOS. 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. The best bet is to check the mailing list archives for information, and then grab the CVS code, or a snapshot, and make your own build. While making your own build you can also take out all serial port activity not needed for your application, of course. //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Romcc Ramblings...
On Thu, Dec 04, 2003 at 11:22:08PM -0700, Eric W. Biederman wrote: > > > > > > I would think it would hurt since x86 lets you use those little > > > sub-registers (puddle arithmetic), so using bigger registers reduces > > > the number of registers available. > > > > Yes, being able to use this from romcc would severely lower register > > pressure I assume. Neither romcc nor the code compiled with it takes > > care of this at the moment though. > > I tried this at one point. And the problem is that there > is not a instruction sequence to move to/from the byte registers > from a normal 32bit register. Hmm, there's movzx and movsx for moving to 32 bit, but from 32 to 8 is worse for esi, edi and ebp. 32->16 works fine of course. I could be missing something though. :) //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: 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: 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 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?
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: 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: 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: 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: 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: Does anyone has text console or framebuffer working on SC1200 without VGA-BIOS ?
On Tue, Sep 23, 2003 at 10:19:56PM +0200, Bernd Mödeker wrote: > > Anyway, can you check and see if there is a vga enable? there almost > > always is in these chipsets. > The vga device is enabled. If I use devmem I can read the vendor and device > ID and the enabled VGA device. PCI function 4 for this vga device is > enabled. So the elpin vga bios should be able to read this ID's too. Maybe the BLDT and/or some revenging of the VGA VSM could point to the right bits. Also see Christer Weinigel's work in the nano port, although I don't remember if he had graphics up on it. I seem to recall it used the SC2200 which has an LCD driver as it's speciality. //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: 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 Sat, Mar 29, 2003 at 12:40:17PM +0500, [EMAIL PROTECTED] wrote: > Thanks Greg, > > I think, that is very good overview about the flow. > It may be good idea to continue this flow on this thread or > somewhere else. > I think,One cannot expect Greg to do all the documentation as Peter > said 8-10 hours is a lot of time. May be out of the > many implementors in this forum, if one contributes by giving > more details about any one of these files in detail of one's own > choice ,basically significance,flow about it and Do's and Dont's,etc > and any experiences. Probably a structure needs to be proposed as well > and rest should fall in place for documentation at least. > If not 8 hours by one person, atleast an hour can be contributed > may not be an issue. There has been a lot of good information sent to the mailing list but unfortunately it can be hard to find in the archives because of the low S/N ratio. Please don't get me wrong though, I think this list is very nice, I'm just saying that I've thought to myself "that's good documentation, it should be saved somewhere" a couple of times when reading some emails with stuff that's completely trivial to several readers, but quite valuable to myself and other (relative to complete) newbies. //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: Ram initialization and small c.
On Tue, Mar 04, 2003 at 11:25:18AM -0500, Jeremy Jackson wrote: > Another idea on the subject: > > On some chipsets, the entire range of supported processors have MMX and > maybe SSE/SSE2. MMX gives 8 extra 64 bit registers (nobody uses > floating-point in LinuxBIOS, right?) that can be used as 32bit. They > can't be used as address/index/base, but only for data. See the MOVD > instruction. Likewise, st0..st7 in the FPU could be used as a stack-like 8x64bit data storage, IIRC. I seem to remember that Pentium MMX CPUs share st* space with MMX registers however, so for those platforms one of them will have to do. //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: giving the user a boot option
On Sat, Feb 01, 2003 at 12:10:25PM -0800, Steve M. Gehlbach wrote: > > > Maybe I'm missing something here, but I don't understand how you do > > > this. > > > Grub and lilo require a legacy BIOS. > > > > LinuxBIOS + ADLO + BOCHS BIOS + ( LILO | GRUB ) > > Seems like a lot of complexity, and I am kind of a zealot against real mode. > Has anyone considered writing the disk/video interface for Grub, to replace > the BIOS calls? The tiara project has done this. Made a version of grub that didn't need the legacy BIOS that is. http://sourceforge.net/projects/utcboot/ //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: C&T 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: C&T 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: C&T 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: 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: Option Parameters for Linuxbios.
Hi, I've been confused by these commands and options too. Below are some suggested namechanges followed by some reasoning about documentation in general. 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 > > rambase 0x0800 > Once RAM is set up, the C portion of LinuxBIOS will be uncompressed and > loaded to rambase in system memory. cportionramaddr or stage2ramaddr > > option XIP_ROM_BASE=0x > > same as biosbase XIP_IMAGE_PHYS_ADDR Why is there both a command and an option for this? And what is XIP? > > option XIP_ROM_SIZE=0x1 > > The rom size for LinuxBIOS is this size (a 64K blockmany cases) XIP_IMAGE_SIZE # if this accounts for the payload or XIP_LINUXBIOS_SIZE # if not Reading some Config files this doesn't seem to be the whole story, caching is mentioned. What's up? > > option STACK_SIZE=0x2000 > > This is the size of RAM allocated for the stack used by the C code C_STACK_SIZE # for cportionramaddr or STAGE2_STACK_SIZE # for stage2ramaddr Already pretty good the way it is but adding the context should help. > > option ZKERNEL_START=0xfff4 > > This is where the payload (such as etherboot) will be located in the > memory space (as part of the flash). PAYLOAD_PHYS_ADDR Does LinuxBIOS require this to be aligned in any way? > > option ZKERNEL_MASK=0x3ed > > Near as I can tell, this is just a legacy now. Great, then it can be removed. :) What has it been used for? I'd be happy to make these changes. What about general documentation, e.g. regarding current LinuxBIOS structure? I know I've read about the different parts of LinuxBIOS somewhere but it might have been here on the mailing list. I'm thinking of the stage1/stage2 names I used above, is it a good idea to establish a stage 1 and a stage 2 (or similar) of LinuxBIOS or should it just continue to be "in assembly" and "in C" ? Also, I would very much like a complete documenatation of the Config files, I'm thinking about doing something along the lines of a Capabilities or Options file that specifies all possible (used) options for that particular directory, along with sane default values where possible. It might only apply to mainboards but would be useful for learning the structure, when porting to new mainboards and for the web Config creator. Thoughts? //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Geode debugging
On Sat, Jan 11, 2003 at 03:40:12AM -0500, Adam Sulmicki wrote: > > And once LinuxBIOS has VSA2, just plug the BLDT .rom-files into it and > > you're done. > > umm isn't that like a step backward? from a binary-only bios back to > binary only modules? Well, at least the VSA2 implementation is open source. :) Problem is that the VSA2 modules aren't distributed in source form, anywhere. They are however distributed under some royalty-free license in binary form, which will do just fine for most users wanting the functionality. Compare with 3Com 3CR990 with specially licensed binary image (firmware for 3com chip) inside driver.. //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Geode debugging
On Fri, Jan 10, 2003 at 06:43:30PM -0500, Adam Bezanson wrote: > Anyone know what is typically used for debugging a Geode > x200 based design? By this I mean a JTAG/BDM or ICE for > debugging say, LinuxBIOS and the Linux Kernel/Linux device drivers. > I think this would be needed to support audio (VSA/SMM support) > since getting it working without an ICE of some kind would be > next to impossible. > I can't really find any info on the web about it > other then here: http://www.fs2.com > they make an ISA-GEODE but it only seems to support GX2 based > processors. My humble opinion is that implementing VSA2 wouldn't be that difficult with access to the right docs and previous knowledge about the platform. And once LinuxBIOS has VSA2, just plug the BLDT .rom-files into it and you're done. //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 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: 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: National Semiconductor Geode GX1 ?
On Sun, Dec 01, 2002 at 10:05:21AM -0700, Ronald G. Minnich wrote: > I see no problem with putting vsa2 to rom. I just don't know how to use > it :-) E.g. via int 10h, or outb(0x220,..).. VSA (and 2) is used to provide the old software interface to the new hardware that works in quite different (better, hopefully) ways. When int 10h is called, or port 0x220 or 0x92 is accessed, an smint (system management interrupt, found on mobile CPUs for suspending and so on) is generated and the "low level" OS driver ends up talking to software instead of hardware. Practical and economic, when you grasp the concept. Some VSA things are complete functions (xpressaudio, no sound will be heard without the xpressaudio VSA ROM) while others are only one way to access that particular feature (video BIOS, the framebuffer driver works as well which means that the video BIOS isn't strictly needed although nice for boot debugging) and yet others may be simple, optional, addons. //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: More details on the Eden support
On Fri, Nov 01, 2002 at 02:12:28PM -0500, GNUOrder wrote: > > The main point of my question, though, was if anyone was aware of another > > way to program the flash short of unsoldering it. I wasn't aware of any, > > and maybe it seemed like a silly question, but if the mobo mfrs would start > > using the LPC interface flash, and put a header on the mobo to access it, > > you could program it from a PC-LPT interface with a specially wired cable > > (plus a few R's and D's). This has been done on the Xbox and the software > > is available on the net. > > LinuxBIOS and kernel on the xbox? Where do I get a copy. I may have to pick > up a used xbox. I dont think we would get the kind of help with porting > linuxbios to that than we have other platforms. :) The Xbox BIOS is actually somewhat documented on http://xbox-linux.sf.net/ And there's the $55k (I believe) reward for making an open source Xbox BIOS. Might compensate for the lack of documentation? :) Anyway, it's fairly easy to get hold of an "alternative" Xbox BIOS that allows you to run any software you want on your Xbox, not just stuff signed by MS. This other BIOS image can be put either into the TSOP40 memory soldered to the Xbox mainboard, or in a LPC memory that is connected to the LPC bus in the Xbox. You also need to pull down a signal on the mainboard to ground to make it boot from the LPC bus instead of the legacy ROM bus. I do believe that most flash memory chips are reprogrammable using the JEDEC commands, documented in any compliant flash memory data sheet. That does however involve writing to the chip and that's usually where the problem is, write-enable signals aren't always wired to the flash memory chips on mainboards and when they are they're connected to some GPIO port on the chipset. In some cases the memory controller also needs to be set to allow ROM writes, by flipping the right bit in the chipset PCI config space, otherwise it'll just block any write requests to the relevant address region. For the LPC programmer and friends, check out http://www.warmcat.com/milksop/ //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: copy extended memory.
On Sat, Oct 26, 2002 at 08:32:48AM -0400, Adam Sulmicki wrote: > > hello, > can anyone point me to an documenation on bios's > interrupt 15, ah=87. It is 'copy extended memory'. This is such a bitch. I simply could not get this to work and I didn't have proper tools to debug what was going on. Here's what RB says anyway: B-1587--- INT 15 - SYSTEM - COPY EXTENDED MEMORY AH = 87h CX = number of words to copy (max 8000h) ES:SI -> global descriptor table (see #0393) Return: CF set on error CF clear if successful AH = status (see #0392) Notes: copy is done in protected mode with interrupts disabled by the default BIOS handler; many 386 memory managers perform the copy with interrupts enabled this function is incompatible with the OS/2 compatibility box SeeAlso: AH=88h,AH=89h,INT 1F/AH=90h (Table 0392) Values for extended-memory copy status: 00hsource copied into destination 01hparity error 02hinterrupt error 03haddress line 20 gating failed 80hinvalid command (PC,PCjr) 86hunsupported function (XT,PS30) Format of global descriptor table: Offset SizeDescription (Table 0393) 00h 16 BYTEs zeros (used by BIOS) 10hWORDsource segment length in bytes (2*CX-1 or greater) 12h 3 BYTEs 24-bit linear source address, low byte first 15hBYTEsource segment access rights (93h) 16hWORDzero 18hWORDdestination segment length in bytes (2*CX-1 or greater) 1Ah 3 BYTEs 24-bit linear destination address, low byte first 1DhBYTEdestination segment access rights (93h) 1Eh 18 BYTEs zeros (used by BIOS) It should all be pretty straight forward. The 16 bytes at 00h and the 18 bytes at 1Eh are probably best used by BIOS to set up it's own segments for usage during the copy. And don't forget the 32-bit opcodes when in pmode. //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Re[2]: AW: DOC vs. IDE
On Thu, Oct 24, 2002 at 04:17:47PM -0500, Richard A. Smith wrote: > Suposedly there are some IDE low level raw access IOCTLS that can > send commands directly to the IDE controller but I've not > investigated it yet. Check out "IDE Taskfile Access" CONFIG_IDE_TASK_IOCTL in 2.4.19. //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Is linuxbios GPL ?
On Mon, Sep 30, 2002 at 01:40:19PM +0100, Antony Stone wrote: > On Monday 30 September 2002 1:08 pm, Christopher Bergeron wrote: > > > Is the linuxbios code GPL? > > Yes. It says so in the file COPYING distributed with the source code. [..snip..] > However, all that said, I'm not aware of any instance where the GPL has > been tested in court (or even "out of court" as they say) against a > company accused of taking GPL code and developing closed source products > from it. Try XVID vs Sigma Designs, http://xvid.org/ and http://www.sigmadesigns.com/ //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Modern GPU programming
Hi!
I found this on the sourceforge page about xbox-linux. It briefly discusses
the capabilities of a modern graphics processing unit, specifically the
nVidia model found in Xboxes. It also shows how to set up 80x25 text mode
on these chips. This should be useful information for the LinuxBIOS project
as well.
http://xbox-linux.sourceforge.net/articles.php?aid=2002181091439
Basically it contains this code:
void crtcout(unsigned char reg, unsigned char data) {
/* a single 16 bit access might also work */
_asm {
mov al, reg
mov ebx, 0xFD6013d4
mov [ebx], al
mov al, data
mov 1[ebx], al
}
}
void settextmode() {
crtcout(0x00, 0x5F);
crtcout(0x01, 0x4F);
crtcout(0x04, 0x54);
crtcout(0x05, 0x80);
crtcout(0x07, 0x1F);
crtcout(0x10, 0x9C);
crtcout(0x17, 0xA3);
}
crtcout() uses MMIO to access the CRTC registers since legacy IO is disabled
in the Xbox. The MMIO memory region is programmed into the GPU by the BIOS.
(0xFD00 with vanilla Xbox kernel) However, the offset of the CRTC in
this memory region is "magic" and probably only known by the chipset
manufacturer, unless reverse engineered. The web page also mentions the
need to set up a font on that particular hardware, however most PC graphics
cards should already have a font onboard, right?
Anyway, I thought this might be of interest to members of this list.
//Peter
___
Linuxbios mailing list
[EMAIL PROTECTED]
http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Framebuffer or standard VGA ?
On Wed, Sep 11, 2002 at 08:55:21AM +0100, Antony Stone wrote: > > 1. there's a standard way for the motherboard Bios to initialise _any_ > graphics card, so it can initialise a new one it's never heard of before (and > presumably LinuxBios could do the same), or: This is the case. The way you reset a VGA card is to far call the real mode address 0xc000:3. This is what the system BIOS does pretty early on, before saying anything to anyone looking at the screen. Try starting debug.exe in MS-DOS and enter a 100 call c000:3 retn g q > Is there a flaw somewhere in my reasoning ? Unfortunately, yes. The problem is that video BIOSes run in real mode and tend to rely on legacy system BIOS services. These _can_ be rewritten but noone on this list is very interested in doing so because it is a LOT of work that might never be worthwhile anyway. On the other hand, if it DOES get written it might also be used for booting other, legacy, operating systems like MS-DOS or maybe older Windows systems, both of these cases have been mentioned on the list, but I do not believe either has very high priority. Why need for textmode? Why not just use the framebuffer? Try playing with the old package SVGATextMode too. //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Framebuffer or standard VGA ?
On Tue, Sep 10, 2002 at 11:22:58PM -0700, Steve M. Gehlbach wrote: > > > Maybe someone knows if alphanumeric mode setup is via the standard VGA > > > register set on most modern VGA cards. > > > > > > > I am afraid your are wrong. For modern VGA cards, there is actually no > > alphanumeric mode. These alphanumeric mode were simulated by BIOS or > > drivers. The worst thing, if you have no documents about these extended > > registers, you have no way to drive the clock gen for Dot clock, Hsync, > > Vsync. > > Are you saying that it is not possible to use a text console with Linux > (vgacon.c) with modern VGA cards (BIOS mode 3)? Only framebuffer? Or are you > saying that without extra information (ie, the BIOS or the manuals) you > can't init it into mode 3? I don't understand your answer. > > I thought most vga cards were register compatible with the legacy VGA > register set, only that there were a lot of other (sometimes secret) things > to setup. Is this wrong? That's Ollie's point AFAICS. > Fortunately regular vga cards are not very important to me, actually, I am > really most interested in integrated chipsets, such as the stpc and the via > apollo ple133 northbridge, both of which are legacy VGA register > compatible. In this case, when the chips really ARE VGA compatible, of course you can program the neccessary registers with appropriate values and get the expected results. You could try this for all graphics chips, just for fun. With a little luck it will work better than we expect. You will want to dump the VGA registers on a running system, and of course you're interested in 0x3c0, 0-0x14@0x3c0:0x3c0, 0x3c3, 0-4@0x3c4:0x3c5, 0x3c6-0x3c9, 0-8@0x3ce:0x3cf and 0-0x14@0x3d4:0x3d5. One number above is just the port, a-b@x:y means registers a through b at port y after index is written to port x. Good luck with this. :) //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
