Re: [LinuxBIOS] Intel refactoring and microcode updates
On Fri, Jan 11, 2008 at 05:27:48PM -0800, ron minnich wrote: > note that on V3, we have the neat ability to put microcode in LAR, > and find it there on boot. > > So we might have another top level directory: /microcode > > And then you can figure out, long after the bios is built, which > microcode updates you want to support. A good deal indeed. //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] AMD SimNOW (program) fails to run
On Fri, Jan 11, 2008 at 02:01:22PM -0800, Andon Tschauschev wrote: > info: creating device #8 "AweSim Processor" > FixIt: Error: Unable to allocate processor model memory. > Aborted .. > mmap(0x54, 2147483648, > PROT_NONE,MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = -1 > ENOMEM (Cannot allocate memory) > mmap(NULL, 2147483648, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, > -1, 0) = -1 ENOMEM (Cannot allocate memory) It seems you're out of RAM. Add another gig or two (swap worst case) to the system and try again. //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] LinuxBIOSv3 Config files
On Fri, Jan 11, 2008 at 06:13:31PM +0100, Stefan Reinauer wrote: > >So will oldconfig read from stdin also for options specified in > >.config ? If so, this is still no the winner. > > nope. oldconfig only asks options not available in .config Then this should work: while :;do echo;done|make oldconfig //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] LinuxBIOSv3 Config files
On Fri, Jan 11, 2008 at 07:59:17AM -0800, ron minnich wrote: > > If you want "yes" for all unspecified options: > > > > make oldconfig < /usr/bin/yes > > Now, Uwe, we just came full circle. I said something like that a > few messages ago and Jordan yelled at me :-) So will oldconfig read from stdin also for options specified in .config ? If so, this is still no the winner. Linux make help does not seem to have a target that combines oldconfig and defconfig in the desired way. :\ //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] Intel refactoring and microcode updates
On Fri, Jan 11, 2008 at 09:42:00AM -0500, Corey Osgood wrote: > Peter Stuge wrote: > > I think we need to make it configurable. > > I don't like that. With a factory bios, you expect the correct > microcode update for your CPU to be present, no matter what CPU you > put in a socket. (Actually no, not always.) > We should be able to do the same. I agree, but we should also try to be even more flexible. I think we should allow inclusion of 0<=n<=all microcode updates. Definately an advanced option, but still. //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] [PATCH] v3: add a check for a termination member
On Fri, Jan 11, 2008 at 03:07:11AM +0100, Carl-Daniel Hailfinger wrote: > > In practice, the marker is the most efficient method, but it is a > > bit of an abomination IMO. :p > > Big question: Is v3 a matter of pride or speed or userfriendliness? > I haven't decided yet. ;-) All of the above, to me at least. > > How do we handle the integrity issue when a single flash block > > that contains the start of a lar file is erased at runtime? (Thus > > breaking a link in the list.) > > If we really do erases at LB runtime, the person waiting for the > erase surely has the time to rebuild the index/cache (which will > probably need a fraction of the time needed for erase). No matter who is erasing, the reality is that the marker is not foolproof; for that to happen, power will have to fail exactly after 8 bytes of magic have been written to a sector I think that the run-time index should always be created once we hit the marker. But we should try to avoid ever hitting the marker in the first place. Perhaps by introducing certain requirements for the "open-ended" special filenames that we currently have, ie. segment0 and any others. On Thu, Jan 10, 2008 at 08:08:57PM -0800, ron minnich wrote: > For the other discussion, iterate over the flash to find all the > headers is taking 2-3 seconds. Sorry, that's just too long. Fully agreed. > We need the terminator in LAR; iterate over all of FLASH even once > is just not going to work. We should try to redesign so that it never happens in the common case. For the corrupted flash case I think the best we can accomplish is the runtime index, which will have to cost a bit of time, but at least it will only be once per boot rather than once per file lookup. Maybe it's not possible to redesign so that we can avoid the scan in the common case. Then I would start looking at aligning members and increasing 16 byte steps to maybe 4k or so. //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] Intel refactoring and microcode updates
On Thu, Jan 10, 2008 at 09:34:28PM -0500, Corey Osgood wrote: > > How many different cores could you put in even the most popular > > socket, three? > > LGA775 currently has 19 (and may have more I don't know about). > Using some rough math, I get a rounded-down size of 186KB (really > is quite a bit more) for its updates, and that would go into both > normal and fallback images. I think we need to make it configurable. //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] LinuxBIOSv3 Config files
On Thu, Jan 10, 2008 at 12:18:14PM -0700, Jordan Crouse wrote: > it really should be a feature that kconfig offers. It's make defconfig in Linux. //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] different versions of the GA-M57SLI-S4 (PLCC vs SPI)
On Thu, Jan 10, 2008 at 12:31:31AM +0100, Harald Gutmann wrote: > > The switch mod can be simplified to use existing pads and no pins > > have to be lifted from the flash chips anymore. > > > > 1. Remove R509. > > 2. Populate R89 and R130 with 10k or 100k pull-up 0402 resistors. > > 3. Solder the switch common to Q4-3 and switch between Q4-1 and Q5-1. > > Confirmed. But not with SMD Resistors. Great, thanks for the confirmation! > First I removed the R509. > As there are connections from R89 Left to U5 VCC; from R89 Right to > U9 CS#; from R130 Left to U5 CS# and from R130 Right to U9 VCC I > soldered normal 100k resistors between U5 VCC and U9 CS# and > between U5 CS# and U9 VCC. > > Here are two photos of my new mod: > http://img141.imageshack.us/img141/8866/dscf1791ob2.jpg > http://img104.imageshack.us/img104/2579/dscf1792nn2.jpg Looks good! > I know, that these cables to the sockel are not really fine, but i > had no other solution for mounting the sockel on the mainboard and > it works fine! As long as it works, it is good enough. :) //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] different versions of the GA-M57SLI-S4 (PLCC vs SPI)
On Thu, Jan 10, 2008 at 10:04:43AM -0500, Ward Vandewege wrote: > Actually, if you're interested in SMT soldering, check out this > '101' video: > > http://www.curiousinventor.com/guides/Surface_Mount_Soldering/101 > > There is some very helpful information in there! Indeed! I definately recommend this even if you actually don't own a soldering iron yet, but have thought about buying one, and certainly if you already own one. :) //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] Please add support for MX25L8005 and MX25L3205D
On Thu, Jan 10, 2008 at 03:16:16PM +0100, Carl-Daniel Hailfinger wrote: > It seems we can't support any flash chip bigger than 512 kByte on a > board using IT8716F SPI translation without a LOT of effort. Please explain further? //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] [PATCH] v3: add a check for a termination member
On Sat, Jan 05, 2008 at 08:52:49PM -0800, ron minnich wrote: > On Jan 5, 2008 5:11 PM, Peter Stuge <[EMAIL PROTECTED]> wrote: > > On Sat, Jan 05, 2008 at 02:44:55PM -0800, ron minnich wrote: > > > NOT finding a file should be efficient. > > > > Yes. > > > > Where do the delay come from? Can anyone measure the LPC? > > I will try to measure for you but remember it is running uncached. > Each and every access is a full LPC cycle, which is not really fast. True. It is definately LPC access time causing this. On Sun, Jan 06, 2008 at 05:17:31PM +0100, Carl-Daniel Hailfinger wrote: > IIRC the PCEngines alix.1c has parallel flash Nope. Both the soldered-on flash and obviously the LPC port are LPC. > for all boards with LPC-to-SPI translation through a IT8716F Super > I/O chip, the following applies: > My calculations suggest that for optimal reads (4 bytes at a 4 byte > boundary) with the IT8716F SPI translation function, we need (1 byte > opcode + 3 bytes addr + 4 bytes data)* 8 = 64 clock cycles on the SPI > bus alone. With a maximum of 33 MHz for the SPI clock on that particular > chip (MUST verify that the chip is set to 33 MHz and not 16 MHz!), this > optimal read takes 2 usec. Smaller reads take at least 1.25 usec. On top > of the pure SPI bus time we have to add the time to transmit and receive > that data over LPC. Say 5 us per byte. That's rather slow for us, yes. On Mon, Jan 07, 2008 at 10:40:02AM +0100, Carl-Daniel Hailfinger wrote: > Well, we can't use CPU cache, but we can abuse CAR memory as cache I like this. > 1. Explicit "stop searching here" marker. Maybe. But I do not think this is very clean.. On Mon, Jan 07, 2008 at 08:40:31AM -0800, ron minnich wrote: > I would rather not walk all of empty space ever at any time. I think the cost of one walk is ok for the flexibility gained. > I like the end marker best. I think the runtime-created index is much more fun. It also keeps the lar format very clean. In practice, the marker is the most efficient method, but it is a bit of an abomination IMO. :p How do we handle the integrity issue when a single flash block that contains the start of a lar file is erased at runtime? (Thus breaking a link in the list.) That re-introduces the walking cost if we want to be able to find any files beyond the erased block. Maybe both run-time indexing and marker is good? But then there's no point in the marker. So only build the index when a hole is encountered. //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] PATCH: lx car that returns from disable_car
On Tue, Jan 08, 2008 at 04:54:29PM -0700, Marc Jones wrote:
> How about this?
> Marc
>
> --
> Marc Jones
> Senior Firmware Engineer
> (970) 226-9684 Office
> mailto:[EMAIL PROTECTED]
> http://www.amd.com/embeddedprocessors
> Add hlt() back into the die() function and update the comments.
>
> Signed-off-by: Marc Jones <[EMAIL PROTECTED]>
Acked-by: Peter Stuge <[EMAIL PROTECTED]>
>
>
> Index: LinuxBIOSv3/lib/console.c
> ===
> --- LinuxBIOSv3.orig/lib/console.c2008-01-08 16:32:28.0 -0700
> +++ LinuxBIOSv3/lib/console.c 2008-01-08 16:48:52.0 -0700
> @@ -83,30 +83,37 @@
> }
>
> /**
> - * Halt and loop due to a fatal error.
> - * There have been several iterations of this function.
> + * Halt and loop due to a fatal error.
> + * There have been several iterations of this function.
> * The first simply did a hlt(). Doing a hlt() can make jtag debugging
> - * very difficult as one can not break into a hlt instruction on some CPUs.
> - * Second was to do a console_tx_byte of a NULL character.
> - * A number of concerns were raised about doing this idea.
> - * Third idea was to do an inb from port 0x80, the POST port. That design
> - * makes us very CPU-specific.
> + * very difficult as one can not break into a hlt instruction on some CPUs.
> + * Second was to do a console_tx_byte of a NULL character.
> + * A number of concerns were raised about doing this idea.
> + * Third idea was to do an inb from port 0x80, the POST port. That design
> + * makes us very CPU-specific.
> * The fourth idea was just POSTING the same
> - * code over and over. That would erase the most recent POST code,
> - * hindering diagnosis.
> + * code over and over. That would erase the most recent POST code,
> + * hindering diagnosis.
> *
> - * For now, for lack of a good alternative,
> - * we will continue to call console_tx_byte. We call with a NULL since
> - * it will clear any FIFOs in the path and won't clutter up the output,
> - * since NULL doesn't print a visible character on most terminal
> - * emulators.
> + * For now, for lack of a better alternative,
> + * we will call console_tx_byte ten times and then halt.
> + * Some CPU JTAG debbuggers might have problems but it is the right thing
> + * to do. We call with a NULL since it will clear any FIFOs in the path and
> + * won't clutter up the output, since NULL doesn't print a visible character
> + * on most terminal emulators.
> *
> * @param str A string to print for the error
> *
> */
> void die(const char *str)
> {
> + int i;
> +
> printk(BIOS_EMERG, str);
> - while (1)
> - console_tx_byte(0, (void *)0);
> +
> + while (1) {
> + for (i = 0; i < 10; i++)
> + console_tx_byte(0, (void *)0);
> + hlt();
> + }
> }
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] AMD SimNOW question
On Tue, Jan 08, 2008 at 05:38:55PM -0500, Marc Karasek wrote: > If you do a svn co svn:// it tries to do a dns lookup, which fails > behind a proxy server :-(. I have not been able to find any info > on setting svn up to use a proxy when doing svn:// type checkouts. svn:// is a plain TCP connection. Is it a SOCKS proxy? An HTTP proxy of course may not be able to help. //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] [PATCH] v2: rewrite AMD K* CAR code
On Tue, Jan 08, 2008 at 02:00:11PM -0800, ron minnich wrote: > Actually, if you all want to commit this, I can try it on the sis > board this week. I think it looks good, please try it on hardware. My alix and LPC dongle was stolen in Berlin otherwise I'd help test. (Yes, laptop too.) //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] Fwd: Possible stack protect solutions (RESEND)
On Thu, Jan 03, 2008 at 09:30:06AM -0800, ron minnich wrote: > Add the ability to extend CFLAGS as needed for several new distros > Signed-off-by: Ronald G. Minnich <[EMAIL PROTECTED]> Acked-by: Peter Stuge <[EMAIL PROTECTED]> > Index: targets/buildtarget > === > --- targets/buildtarget (revision 3031) > +++ targets/buildtarget (working copy) > @@ -53,4 +53,25 @@ > export PYTHONPATH=$config_dir > $PYTHON $config_py $config_lb $lbpath > > +# now start checking for distro-specific breakage. > +## This check is for the no stack protector mess. > +EXTRA_CFLAGS= > + > +if [ -z "$CC" ]; then > + CC=gcc > +fi > + > +$CC -fno-stack-protector -S -xc /dev/null -o .$$.tmp > + > +if [ $? -eq 0 ]; then > + EXTRA_CFLAGS=-fno-stack-protector > +fi > + > +rm -rf .$$.tmp > + > +for i in $build_dir/Makefile.settings $build_dir/*/Makefile.settings > +do > + echo CFLAGS+=$EXTRA_CFLAGS >>$i > +done > + > exit $? -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] r3034 - in trunk/LinuxBIOSv2/src: config devices
On Sun, Jan 06, 2008 at 02:27:40AM +0100, Torsten Duwe wrote: > > What about all the boards that this affects? > > All boards that might have CONSOLE_VGA and not PCI_ROM_RUN > currently wouldn't compile, so all compiling boards have both, or no > VGA console. Right, thanks for clarifying. //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] r3034 - in trunk/LinuxBIOSv2/src: config devices
On Sun, Jan 06, 2008 at 02:10:54AM +0100, [EMAIL PROTECTED] wrote: > Author: duwe > Date: 2008-01-06 02:10:54 +0100 (Sun, 06 Jan 2008) > New Revision: 3034 What about all the boards that this affects? //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] [PATCH] v3: add a check for a termination member
On Sat, Jan 05, 2008 at 02:44:55PM -0800, ron minnich wrote: > NOT finding a file should be efficient. Yes. Where do the delay come from? Can anyone measure the LPC? //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] empty payload
On Fri, Jan 04, 2008 at 04:59:54PM -0800, ron minnich wrote: > I am wondering about making it part of v3 tree. Just make an > emptypayload directory. This would make testing easier. > > I don't know, comments? It will eventually become the panic room, right? ;) //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] Lightning talk at FSCONS 2007
On Thu, Dec 27, 2007 at 08:12:47PM -0500, [EMAIL PROTECTED] wrote: > So how did the Lightning talk at FSCONS 2007 in Gothenburg go? The talk went pretty well, but it took a little bit longer than it should have. The demo did not work at first. I suspect the cable length between my LPC dongle and the CPU board. The cable I made (10cm) worked fine for me, until I went to Gothenburg. :( They threw in a short-short talk while I was messing with the demo board, resetting it over and over. Finally it worked. > Do you have any video's for us Peter?? Sorry, no, I haven't seen any videos from FSCONS yet. I'll let you guys know as soon as I see something posted. (No pun intended.) //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] Unable to flash the K8Upgrade-VM800 Bios
On Wed, Dec 26, 2007 at 08:41:14PM +0530, Kiran Patil wrote: > Hello All and Merry Christmas, The same to you. > Diff of Original Bios and latest read Bios: > -- > [EMAIL PROTECTED]:/home/kiran/bios_files# diff Dec26_Bios Pc_Bios > Binary files Dec26_Bios and Pc_Bios differ So how do they differ? Can you tell if any writes to the flash chip worked - including the erase? You can use xxd to get a hex dump of the files, and then do diff -u on those. //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] Linuxbiosv1
Hi Cimino, On Fri, Dec 21, 2007 at 06:24:07PM +0100, Cimino Vittorio wrote: > LinuxBIOS-1.0.0 ven dic 21 20:47:26 CET 2007 starting... v1 is really old, and not supported any more. I suggest working with v2 instead. //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] Linux Bios Development
Hello Kiran, On Fri, Dec 21, 2007 at 12:24:06PM +0530, Kiran Patil wrote: > We have MSI K9N Neo and MSI K9N Ultra mother boards with socketed > bios. > > What is best way to learn and implement fast. > - First fix LinuxBios v3 to run qemu on our hardware > - Second to start of with understanding the code with real > hardware in hand > > Please guide us on how to get in to project with fast track. I think the second option is better, to start by building LB for the hardware you have. Yes, v3 is exciting, but many good things can be learned from v2, plus it works today. :) //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] VIA EPIA MII 10k stability questions
Hej Lars! On Thu, Dec 20, 2007 at 02:52:31PM +0100, Lars Randers wrote: > I've been dabbling with this board and the writeups for about a > week to little avail, so I'd like to hear from anyone who have this > board running stable with LB, and preferably with VGA enabled. I have a 6k which was fairly stable with VGA until the capacitors blew, but I did not use all features on the board. > I can't seem to build the bios successfully with the > Config.vga.filo.lb configs. Hm, I also seem to recall that the sample config didn't work. But I think it was fairly easy to sort out. What errors do you encounter? > I have also been investigating spurrious interrupts with the CF > slot when running Linux (Centos 4.5 - 2.6.9 kernel) This is a hardware problem with the Ricoh chip. > and the strange LAN lockup, which seems to be related to a DMA > issue in the southbridge chip. AFAIK this is also a hardware problem. > Should I just trash the board and look for a more stable platform? If you have options, that may not be a bad idea. > It's a nice platform, low power and all, but if it's hopelessly > flawed in design it's out. Any input on the issue welcome! What other boards are your candidates? > Furthermore I'm struggeling to get the Linux kernel to boot through > the initrd without ending up in a panic. I know it's not a LB > issue, but as I said, I'd like to get in contact with anyone who has > any knowledge into the problem. I don't like initrds much. As it stands you will need one solely for the purpose of resetting the Ricoh chip, but I would prefer to hack those few lines of code into FILO instead, so that the initrd can be skipped. > The wiki is incomplete in this respect and I certainly wouldn't > mind donating some of my time in return updating it if I could > get it working. Well, you should be able to find other pages about how to make an initrd. It will also very greatly with distributions, which makes generic advice somewhat difficult to produce. Why do you want the initrd in the first place? :) Is it some other reason than resetcf? //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] problem about dram init
On Thu, Dec 20, 2007 at 10:34:15PM +0800, aaron lwe wrote: > //Until you can successfully run memtest86 as a payload and it reports > //zero errors, RAM has not yet been configured correctly. > > OK, I get it. Thanks. > Memtest86 reports errors at memory address > 1MB, 5MB, 9MB, 13MB, 17MB, ... not sure what's wrong. Many addresses around there or only exactly 1MB, 5MB etc? > corey's original patch couldn't pass ram_check, and I have no idea > why. Probably some small differences between your board and his, which is causing timing problems between the memory controller and RAM. :( //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] problem about dram init
On Thu, Dec 20, 2007 at 04:49:32PM +0800, aaron lwe wrote: > I've configured the via cn700 dram controller .. > Unexpected Exception: 6 @ 10:1bfee821 - Halting .. > can I say ram is initialized right? No. ram_check() is a useless metric. Until you can successfully run memtest86 as a payload and it reports zero errors, RAM has not yet been configured correctly. I think Corey got things going on the CN700, are you working from his patch? //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] Possible stack protect solutions
On Wed, Dec 19, 2007 at 10:53:44AM -0700, Jordan Crouse wrote: > So I leave it to the community - which solution do we prefer? I like fixing it in LB. We already know Config.lb is not optimal, but I don't think it will ever be replaced in v2 so may as well carry on with it. //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] cmos.layout field meanings.
On Wed, Dec 19, 2007 at 01:03:51PM -0800, Steve Isaacs wrote: > The bits I'm most interested in at this time are the ones that > payloads such as FILO, etherboot may depend upon. Anybody have > any clues? Sorry, best to just dig into the code. At least FILO is easy to grep. //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] SMBIOS tables or alternate.
On Tue, Dec 18, 2007 at 01:39:19PM -0800, Steve Isaacs wrote: > Because of a need to be compatible with other systems I'm seeing a > requirement to support SMBIOS tables. I did some quick searching > and didn't find much regarding this subject on the LinuxBIOS web > site or the source code. LB does not try to support legacy stuff like this by design. (LB does not try to be "BIOS compatible" if you will.) > From an application perspective this is important information. The > same application needs to run on platforms having different BIOSes > -- some commercial, some LinuxBIOS. The hardware type and version > information is important for maintaining and deploying the > application. Because of this, the application needs a consistent > mechanism for retrieving the information I listed above. > > Any suggestions or alternatives? Yes, I suggest using an alternative. There isn't really much ready-made though. Can you explain in more detail what information it is your application needs, that is so far unavailable? //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] Patch file for Fedora 8 compile problems
On Tue, Dec 18, 2007 at 03:58:48PM -0500, Marc Karasek wrote: > How about my awk script I sent out that uses the output from ld > --help to see if buildid is and option. The awk script behavior may be a problem, depending on how it is called from buildtarget. See my other message with the simple grep suggestion. A patch would be great! :) //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] [Fwd: Re: Patch file for Fedora 8 compile problems]
On Mon, Dec 17, 2007 at 02:55:35PM -0500, Marc Karasek wrote:
> That would work, but this brings up a rather interesting point.
> What are we todo about all the other Distros?
> At some point (if not already) they will also face a similar issue.
As Uwe hinted, this of course has nothing to do with a distribution
but rather a specific package.
Long term, we work with upstream for that package.
Short term, I like Ron's test at buildtarget time, and saving that in
a Make.buildparam.or.whatever in the freshly created build directory.
On Mon, Dec 17, 2007 at 03:16:40PM -0500, Marc Karasek wrote:
> So how about this
>
> (ld --help) | awk '{for (i=1;i<=NF;i++) if ($i ~ /build-id/){n++} }; END
> {print n}'
>
> This will return a 1 if it finds the string build-id in the ld help.
Almost, it seems to output the number of times the string is found.
I suggest ld --help|grep -q build-id instead, which may even be
slightly easier to work with in a script.
//Peter
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] AMD Geode LX on Lippert Roadrunner LX800
Hi again, On Sun, Dec 16, 2007 at 09:41:28PM -0600, Simpson, Matthew wrote: > I am subscribed to the list for [EMAIL PROTECTED] Ok! > I'll try one of those others and see how far I get. Please report back. :) > I am interested in increasing the boot time of this little board. I > am running FC7 on it with a tweeked-out 2.6.23 kernel. Oh. Then you may be optimizing the wrong thing, also look into how much time the boot-time scripts need. That is the first thing I look at to reduce the boot time, usually quite a lot of time is spent there, because the boot scripts are usually made to be very general, while in an embedded system you can use one simple script instead. (I just replace the boot, sysinit and default scripts that are called by init.) //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] AMD Geode LX on Lippert Roadrunner LX800
Hi Matthew, (are you subscribed to the list or should we always cc you and [EMAIL PROTECTED]) On Sat, Dec 15, 2007 at 08:19:26PM -0600, Simpson, Matthew wrote: > Is this supported? No. But I guess it is rather similar to a few other LX800 boards that are supported. > What target do I choose? I think amd/norwich, pcengines/alix1c or maybe amd/db800 would be good starting points. (What about amd/rumba?) > Here is the info about this board, used for embedded systems: > > Board: Lippert Roadrunner LX800 .. > BIOS chip: SST 49LF004B (Bios Savior supports this) Sure, the flash is rarely a major problem. > Output of lspci: .. > The data sheet and technical manual can be found at: .. Board manufacturers never publish all the information that is needed in order to fully support a mainboard. The technical documentation is never technical enough for boot firmware development. For a board like this, in particular this means information about PCI device and expansion slot IRQ routing, as well as the proper pin/ball multiplexing configuration required to match how the board has been designed. Possibly there are also some magic GPIO signals that the firmware needs to work the right way to make the system function. This is all known only by the board designers. Usually it can be learned from a little investigation of the board, along with trial and error. The factory BIOS can also help. (Boot it and read the relevant settings.) AMD is also working with the LinuxBIOS project (maybe you've already seen some posts by Marc, Jordan or Libo) so the only thing we may need is some information from Lippert, and sometimes board manufacturers will gladly help with this information. :) I would start out with trying to boot another LX800 target, to see if there's any response at all. It may get you pretty far. //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] patch to lib/lar.c and include/lar.h
On Sat, Dec 15, 2007 at 06:00:43PM -0800, ron minnich wrote: > Support a return from disable_car is a very difficult proposition. Aye. > The intent is that I can do this: > ret = execute_in_place(&archive, "normal/initram/segment0", main_ram_working); > or similar and thus chain from initram to the second part of main, > with a new stack and working dram. I don't like the patch as is. It is now becoming non-obvious from function names and parameter names what the code flow is. This is a problem in v2 that I would like us to be careful to not introduce also in v3. > - * run_address is passed the address of a function taking no parameters and > + * run_address is passed the address of a function taking a single void * > parameter > * jumps to it, returning the result. > * @param v the address to call as a function. > * returns value returned by the function. > */ > > -int run_address(void *f) > +int run_address(void *f, void *param) Please fix up the doxygen comments completely. Note that all parameters in the doxygen comment are incorrect. > @@ -263,9 +263,10 @@ > * Given a file name in the LAR , search for it, and execute it in place. > * @param archive A descriptor for current archive. > * @param filename filename to find > + * @param param void * parameter > * returns 0 on success, -1 otherwise > */ > -int execute_in_place(const struct mem_file *archive, const char *filename) > +int execute_in_place(const struct mem_file *archive, const char *filename, > void *param) The name 'param' is really not transparent and the doxygen comment is not clear enough about how this param will be used - ie. that it is just passed on as a parameter to the function that actually executes the file. Generally speaking I think this arrangement is pretty ugly. (Passing a parameter several layers into the code.) In this instance I do think it's a pretty good solution, because it is actually fairly simple, especially considering the alternatives. I guess I am proposing that we make the parameter names and possibly also some function names less generic, because this is something that will be used exclusively during one specific phase transition. Good or bad? //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] Tyan s1894
On Sat, Dec 15, 2007 at 03:21:28PM -0600, Jason Green wrote: > I am new to LinuxBIOS mailing list. I have a few old boards I want > to try out. I dunno if it's compatible with this or not. > > http://www.tyan.com/archive/products/html/tigercub100.html Maybe it's similar enough to the s1846 that the 1846 port works as is? Or maybe it could at least be a good start for a s1894 port? //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] Getting started with LinuxBIOS on a MSI K9N Neo-F (MS-7260).
On Mon, Dec 17, 2007 at 03:38:41AM +0100, Carsten Koch wrote: > Would anyone be ready to send me one or two pre-flashed chips? Sure thing. See if the original porter (Uwe IIRC) has a working .rom. //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] [PATCH] AMD Barcelona(family 10) support 1 of 4
On Thu, Dec 13, 2007 at 10:34:48AM -0800, ron minnich wrote: > > > I also didn't understand why the type change from uint32_t to > > > u32 was important. > > > > Just trying to follow the LB guidelines. Maybe I should have left > > it alone. > > no, you did the right thing. Would be great to split this up into one whitespace patch, one u32 patch and finally one (maybe even more?) barcelona patch. //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] patch to lib/console.c
On Wed, Dec 12, 2007 at 04:46:32PM -0800, ron minnich wrote: > well, is the banner enough to flush all the fifo's? I thought they > got pretty big nowadays. Anyone know? 16550 and compatible still only have 14/16/18/whatever bytes. EHCI debug port is unbuffered. .. are there more? //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] TOPSEARCH TS-M-8V01C
On Wed, Dec 12, 2007 at 02:04:17PM +0100, Cimino Vittorio wrote: > LinuxBiosV3 (latest snapshot) Look like v2. There's no support for via hardware in v3 yet either. > SouthBridge : VT8231 > NorthBridge : VT8601 .. > This can be a VIA/EPIA compatible Motherboard. Unfortunately it's not enough for a board to use the same major components to make it compatible. > When system start LinuxBios don't find the memory. Right, because the boards either aren't compatible, or because our RAM init code for the chipset is not generic enough. > Slot 00 is empty > Slot 01 is empty > Slot 02 is empty > Slot 03 is empty No RAM. > Copying LinuxBIOS to RAM. So this is of course nonsense. > Jumping to LinuxBIOS. And this will indeed hang since the CPU will only be fetching bogus instructions after the jump. Please do help work on the RAM init if you can. It would be great to make it more generic if that is possible. Note that this is usually the single most difficult part of LB. But if you can help, that would be much appreciated! :) //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] LinuxBIOS 'flashrom' on Geode LX + CS5536
On Sun, Dec 09, 2007 at 11:15:45PM +0200, Martin-Éric Racine wrote: > As far as I can tell, 'flashrom' would need to read some register > (DIVIL_BALLS - see AMD document 3328G_cs5536_db.pdf page 365) .. > Is the LinuxBIOS 'flashrom' currently incapable of doing this Well, it doesn't do it. But it does have msr read/write functions, so it should not be too difficult to add. I don't know what is needed when flash is not on LPC though. Does flashrom have to care where it is? //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] Expand linuxbiosv3 support
On Fri, Dec 07, 2007 at 10:51:30PM -0500, Corey Osgood wrote: > > -HOST_CFLAGS= > > +HOST_CFLAGS=$(STACKPROTECT) > > With quotes around $(STACKPROTECT), lzma finishes, but mkelfimage > fails: Why is mkelfImage called wtih $HOST_CFLAGS or any other CFLAGS? //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] USB floppy boot
Hello, On Sun, Dec 09, 2007 at 12:26:21AM -0800, Baski wrote: > I have a tiny kernel (not linux) and GRUB in a floppy disk. How can > I make it to boot using linuxbios? A few things need to be considered: * How does the kernel try to find the system information that is usually exported by the BIOS in quite old-fashioned ways? At a minimum, the kernel needs to know how much memory is in the system. LB does not offer the same methods as a BIOS to learn this. * Does the kernel use other BIOS interrupt services? LB does not offer any. * How large is your kernel? If it can fit with LB in the boot flash (which is between 256kb and 1MB) you don't need the floppy at all. * Is the floppy a requirement? Currently no other payload than a full kernel (Linux or other) with it's own floppy drivers can read from the floppy drive. //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] Support for Intel Little Valley
Hi, Michael. On Thu, Dec 06, 2007 at 12:35:40PM -0800, Michael Ost wrote: > We are considering building a product around Intel's Little Valley > mini-ITX motherboard, model D201GLY. Would we be able to use > linuxbios on it? SiS662+SiS964L - neither have existing support. The southbridge SiS966 is supported, maybe it's close enough to be usable. > If development is required, are there folks who do that kind of > programming that we could work with? Yes. The problem is usually to find documentation from the chipset vendor, but we've recentlyreceived nice contributions to the project from SiS themselves so maybe that will not be a big problem here. :) > PS: If Ron Minnich is still active in this group He sure is. //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] LinuxBIOS on Compaq ProLiant 1850R?
On Thu, Dec 06, 2007 at 10:35:34AM +0100, Dijk, Michiel van [FDS] wrote: > > Yep, let's do it. Does the board have a socketed BIOS so you can > > hot-swap it to have a backup chip stored away safely? > > The BIOS is a socketed chip yes (a PLCC, don't know what type). > I need a replacement chip first so I can back-up the original. If you can identify the current chip model we can suggest other compatible models. > > Please send the output of 'lspci -tvnn' and 'superiotool -dV' from > > your board (run it as root). Also, please run the 'getpir' tool and > > send us the irq_tables.c file which is generated by the tool. > > We can make a patch with that information then, if you're willing to > > test it on your hardware. > > Ok, I will do that. Please give me some time to install Linux on the > system (running FreeNAS = FreeBSD 6.2 at the moment). > Would it be possible to use a LiveCD as well, or should I just > install a full distro? LiveCD will work just fine, as long as you can run those utilities. lspci is included on many liveCDs, superiotool and getpir are not, so you'll have to build those yourself. > > Do you absolutely need the SCSI? > > I would prefer IDE, but since the manual of the server says IDE > harddisks are not supported... I don't know if that's a BIOS > problem or a hardware problem. lspci output should answer this. //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] alix and Artec LPC dongle [was: LPC.1A adapter?]
On Thu, Dec 06, 2007 at 06:24:25AM +0100, Peter Stuge wrote: > GND 9 10 VCC3 in > > 441103-alix1c: > 1-13 2-3 3-5 4-7 5-9 6-11 8-1 9-2/4/6/8/10/12/17 10-nc -15/18 > > Note that the above cable can supply power to the LPC dongle. Note that it can not. Sorry. I am too tired. I left 10 not connected specifically to avoid the problem, since I think I'll usually be powering the LPC dongle from USB. The dongle needs 200ms or so to boot, so it has to be powered up before the target board. I like pulling the power when trying a newly flashed LB so dongle has to get power from somewhere else. //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] alix and Artec LPC dongle [was: LPC.1A adapter?]
On Wed, Dec 05, 2007 at 05:17:19PM -0500, Ward Vandewege wrote: > The alix.2/3 manual mentions that port J11/J16 can be used for an > alternate flash rom via an LPC adapter. The alix.1 manual describes > the same on port J16. > > The PC Engines adapter LPC.1A is mentioned in this context, but I > can't find any documentation about it, not even on their website. It's on the website but not linked, so you have to guess the filename. > Ron, which adapter do you use? Would the one that comes with the > programmable LPC dongle by the Artec Group work? Yes, Artec's LPC dongle works with the alix1c. I'm using the previous product revision 441103 but there's no reason the current revision 441104 should not work equally well or better. (Allow longer cabling.) It needs a cable with pins connected the right way, but no other components are needed. I hacked the proper cable up by cutting up an old floppy cable and pressing a 10-pin header onto one end. This is my wiring diagram: alix1c J16 LCLK0 1 2 GND LAD0 3 4 GND LAD1 5 6 GND LAD2 7 8 GND LAD3 9 10 GND LFRAME# 11 12 GND PCIRST# 13 14 NC CSEXT 15 16 VCC5 GND 17 18 VCC3 SERIRQ 19 20 LDRQ# 441103 J3 PCIRST 1 2 LAD0 LAD1 3 4 LAD2 LAD3 5 6 LFRAME# R330GND 7 8 PCICLK1 GND 9 10 VCC3 in 441103-alix1c: 1-13 2-3 3-5 4-7 5-9 6-11 8-1 9-2/4/6/8/10/12/17 10-nc -15/18 441103 pin 9 connects to any one of the alix1c pins, not all of them. The last one, -15/18 means that pins 15 and 18 on the alix1c end should be connected together, but not to any pin on the dongle end, in order to pull CSEXT to 3.3V and tell alix to boot from LPC flash. (Too bad CSEXT isn't active low, then it would just have been a jumper on the header on the board. Oh well. :) The alix1c docs don't say if CSEXT is 5V or 3V so I played it safe and tried 3V first, which works. My cable length is ca. 10cm. The LPC dongle docs say that cables should be kept to just a few cm but 10cm works fine for me. Note that the above cable can supply power to the LPC dongle. Pay attention to JMP4 on the dongle or the alix power supply will be connected to the USB host power supply that the dongle is connected to. May or may not be a big deal depending on the power supply designs. //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] different versions of the GA-M57SLI-S4 (PLCC vs SPI)
On Wed, Dec 05, 2007 at 02:07:38PM +0100, Rudolf Marek wrote: > Hi all, > Adding ACPI support which should at least do poweroff properly or > deliver power button event is > quite simple. Maybe I can write some howto to wiki? Please do. //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] ADLO & biosdecode
Hello Jun, On Wed, Dec 05, 2007 at 12:54:42PM +0900, Jun Koi wrote: > If I use the original QEMU BIOS, at least biosdecode reports BIOS32 > Service Dir + PCI IRQ table + ACPI. > > So why LinuxBIOS removes those information? This is on purpose. One motivation for LB is that most if not all interfaces that are associated with the term BIOS should be deprecated. LB does not strive to be BIOS compatible by design. Instead of offering callbacks, LB wants a linear program flow during boot, where initialization hands over to a payload, which hands over to the operating system, which then, in fact, operates the system. This is a slightly new concept also for operating systems, since they are used to relying on the BIOS at least for some things, but we are making (admittedly pretty slow so far) progress. //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] [PATCH] v3: fix typo in util/lar/lar.h
On Wed, Dec 05, 2007 at 03:30:16AM +0100, Carl-Daniel Hailfinger wrote: > util/lar/lar.h was accidentially changed to point to the wrong > other header. > > Signed-off-by: Carl-Daniel Hailfinger <[EMAIL PROTECTED]> This would qualify as trivial. :) Acked-by: Peter Stuge <[EMAIL PROTECTED]> //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] [PATCH] v3: duplicate less code
On Wed, Dec 05, 2007 at 02:56:26AM +0100, Carl-Daniel Hailfinger wrote: > To reduce code duplication, make sure STAGE2_OBJ does not contain > any object already mentioned in STAGE0_OBJ. > This saves 386 bytes in qemu stage2 (~240 bytes after LZMA compression). > > Build tested and runtime tested in Qemu. > > Signed-off-by: Carl-Daniel Hailfinger <[EMAIL PROTECTED]> Acked-by: Peter Stuge <[EMAIL PROTECTED]> -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] flashrom on ASUS P3B-F with M29F002 or 39SF020A
On Tue, Dec 04, 2007 at 06:00:48PM +0100, Heino Goldenstein wrote: > I like to play with an ASUS P3B-F lingering around. Cool! > Neither the original (M29F002) nor an replacement Flashchip > (39SF020A) is recognized. According the documentation this should > be supported. .. > The result of probe_jedec seems flaky. > > Either I do something wrong or there is a bug. > Is there any advise how to resolve this? The mainboard probably needs some extra tricks to let the write enable signal through to the flash chip. It is needed also to identify the flash chip. :\ Some Asus boards had a tricky SMBus mux thing going on. Maybe that is what's causing problems here too? //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] [PATCH] v3: fix absolute calls from initram
On Tue, Dec 04, 2007 at 03:39:58AM +0100, Carl-Daniel Hailfinger wrote: > - ret = execute_in_place(&archive, "normal/initram.o/segment0"); > + ret = execute_in_place(&archive, "normal/initram/segment0"); This seems to have snuck in from another patch? //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] Qemu compile for LinuxBIOSV2
On Mon, Dec 03, 2007 at 01:04:53PM -0500, Marc Karasek wrote: > BTW: Is this patch associated with the thread about qemu and the > compilers? No, that thread is all about v3 growing pains. //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] State of the buildrom
On Mon, Dec 03, 2007 at 10:41:11AM -0700, Jordan Crouse wrote: > > How about one environment variable that points to another file > > with options? > > Oh, I like it. Lets make this happen. See mainboard() at line 1333 in util/newconfig/config.g. Does buildrom want to replace/amend Options.lb as well, or is it just Config.lb? Are we simply looking for a second call to doconfigfile() if a particular environment variable has been set? //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] Infamous __stack_chk_fail problem.
On Mon, Dec 03, 2007 at 08:34:00AM -0800, Steve Isaacs wrote: > I believe that like it or not if you want LinuxBIOS to be widely > accepted it must be able to demonstrate repeatability. Excellent point! I agree with you completely. We should definately look at automating the build process and even build environment, because it is a sensitive component in the build process, and we should make LB smart enough to build with a build environment other than the one that starts with /usr/bin/gcc. However - I want it to remain optional rather than a requirement, so that the entry level stays as low as possible for as many as possible. But one does not, and should not, exclude the other! :) //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] State of the buildrom
On Mon, Dec 03, 2007 at 09:15:37AM -0700, Jordan Crouse wrote: > There just isn't any good way to change v2 config files without > lots of pain > Not that we really have a great story for v3 either, .. > really a generic way to override config without editing text files > would be the most ideal. How about one environment variable that points to another file with options? This could probably be added pretty easily to the v2 config python thing, as well as v3. //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] LinuxBIOS on Compaq ProLiant 1850R?
On Mon, Dec 03, 2007 at 10:45:01AM -0500, Corey Osgood wrote: > > SCSI: Symbios LSI 53C876 (on-board) > > You'd have to extract the original option rom from the bios for > this, then prepend it to linuxbios. Explore around the wiki a bit, > there's a build guide for another board with a SCSI option rom, or > else it's the same process as for a VGA rom. The option rom on it's own won't do much good. LB itself doesn't care about it and can't use the INT 13h hooks that the option rom installs. (Plus they are only installed in the emulator, so payloads can't use them either.) Depending on the payload, you may not need to care about the option rom however. Ideally the Linux driver does not require the option rom to have run to drive the controller. Anyway, to boot a system on a SCSI disk you will need room for a Linux kernel in flash. (This is called LAB, suggest to use the LB companion buildrom to create the rom image.) //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] different versions of the GA-M57SLI-S4 (PLCC vs SPI)
On Sat, Dec 01, 2007 at 07:46:14PM -0500, Richard Smith wrote:
> CS# from the IT8716F is routed up to R509 which is a zero ohm
> resistor.
> If this resistor is in place then CS is hardwired to CS# on U5
> which is the SPI chip that's loaded. If you pull R509 then the CS#
> to both chips are free to be selected by (unloaded) Q2,Q43,Q4, and
> Q5 + resistors but I don't have the configuration mapped out.
They would be part of Gigabyte's patented hardware BIOS failover
technology I suppose.
Q4-3 and Q5-3 are both connected to the superio side of R509, so the
emitter if using PNP transistors.
Traces from Q4-1 and Q5-1 both run toward the flash chips so they
would be the collector.
Q4-2 and Q5-2 the base, with R91 before Q4 and R90 before Q5. The
other side of R91 goes to R389 which then goes to Q43-2. The other
side of R90 goes to R86 which then goes to Q2-2.
There are some vias on the traces between R{90,91} and Q{4,5} so they
are connected to something else as well. (But what?) There are also
vias on traces between R{86,389} and Q{2,43}.
Q43 and Q4 are driven at the same time, through R389 and R91
respectively. I wonder what the purpose of Q43 and Q2 is.
The pinout does indeed match e.g. a BC847 PNP transistor in SOT23
package.
R89 is between Q4-1 (U5-CS#?) and a power net, so would be the
pull-up for when Q4 is not driven to select U5.
There is certainly a corresponding resistor for Q5-1 but there's only
a via from the Q5-1 trace so it would have to be tested. My guess is
R130 (directly south of R129) since it's other end goes to U9-CS#.
> It does not look like there is any easy way to re-enable switching
> between the SPI chips since you have to load several missing parts.
The switch mod can be simplified to use existing pads and no pins
have to be lifted from the flash chips anymore.
1. Remove R509.
2. Populate R89 and R130 with 10k or 100k pull-up 0402 resistors.
3. Solder the switch common to Q4-3 and switch between Q4-1 and Q5-1.
Of course this assumes that soldering 0402 resistors is considered
simple, which isn't likely true unless you're good at SMT soldering.
> I'll probably just end up soldering on a 2nd chip and then wiring
> the CS# pins up to a switch like the other mods did.
Of course there could be some timer thingy to do failover, but I
think manual control is best. I think the spring-loaded switch is
as useful as any mechanism in this case.
//Peter
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] Qemu compile for LinuxBIOSV2
On Fri, Nov 30, 2007 at 02:53:03PM -0500, Marc Karasek wrote: > When I try to compile v2 with a filo.elf payload I get the : > > collect2: ld terminated with signal 11 [Segmentation fault] The linker plain crashes. Try vanilla upstream gcc and binutils packages. //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] SPI flash
On Wed, Nov 28, 2007 at 07:14:08PM -0500, Richard Smith wrote: > If I can I'd also like to upgrade the SPI flash part to as big as > the chipset will support and if thats still not big enough to hold > my kernel+rootfs then change to a USB nand drive. I'm waiting for sales information for 32Mbit flash, and will try to get the moq down a bit from 1k so I can order some. Winbond list a 64Mbit product too, but it isn't available yet. Does anyone know how big memory area is decoded to LPC by the mcp55? //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] [PATCH] buildrom: add preliminary gpxe support
On Fri, Nov 30, 2007 at 12:16:16AM -0500, Ward Vandewege wrote: > Peter and I talked to the friendly folks at #etherboot. They were > interested in re-adding LinuxBIOS support but are a bit short of > time. If someone wants to help out, that would be great; As far as adding support for LB-specific things FILO has all the neccessary bits already. A bigger problem is that gPXE currently does not have the BIOS completely abstracted, so that needs to be done first. :\ //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] [PATCH] LAR verison field
On Fri, Nov 30, 2007 at 02:55:30AM +0100, Stefan Reinauer wrote: > > > Space reservation? What is this about? > > > > No-one will ever need more than 64 bytes. > > If we add a field "header size" we know how many bytes we have to > skip without the need to know how to parse all of the header. Yep, this is good. > Please don't add reserved fields. thats really ugly and lack of > design. Fair enough. //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] [PATCH] LAR verison field
On Fri, Nov 30, 2007 at 12:43:51AM +0100, Stefan Reinauer wrote: > > Together with reserving space at the end of the header. > > Space reservation? What is this about? Some extra bytes for future use, the more bytes the longer before we need to change the format. I think 64 would be more than enough. No-one will ever need more than 64 bytes. //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] [PATCH] LAR verison field
On Thu, Nov 29, 2007 at 05:41:52PM +0100, Stefan Reinauer wrote: > > Alex, can you repost an updated patch? I want to verify that patch > > against a suggestion of Peter Stuge from > > > > Date: Thu, 30 Aug 2007 00:06:50 +0200 > > > > Message-ID: <[EMAIL PROTECTED]> > > What is that suggestion? http://marc.info/?l=linuxbios&m=118842524813075&w=2 Feature flags. //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] [PATCH] Remove Bitworks IMS
On Thu, Nov 29, 2007 at 02:34:18AM +0100, Uwe Hermann wrote: > I'm relatively sure the dual-bios solution will not work in this > case, as it's software-controlled (but other may have more > information). Correct, any BIOS failsafe in software is out of play once LB is in the flash chip. IIRC Gigabyte had some patents on a hardware failsafe as well, but it may not always be populated. //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] [PATCH] LAR verison field
On Thu, Nov 29, 2007 at 02:30:14AM +0100, Alex Beregszaszi wrote: > > > this adds a 32bit version field after the magic. > > > > > Signed-off-by: Alex Beregszaszi <[EMAIL PROTECTED]> > > > > Acked-by: Stefan Reinauer <[EMAIL PROTECTED]> > > > > Please commit. > > Are we still in favor of this? If yes I will commit it tomorrow. If there are no NAKs go for it! Please include the new rev in the final message in the patch thread for better traceability. //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] [BUILDROM] Move to memtest86 version 3.4
On Wed, Nov 28, 2007 at 04:14:56PM -0700, Jordan Crouse wrote: > [BUILDROM] Move to memetest86 version 3.4 > > Memtest86 version 3.4 has some fun new tricks, like understanding > multiple CPUs. Also use the correct name in the config.in - its > memtest86, not the similar but different memtest86+ > > Signed-off-by: Jordan Crouse <[EMAIL PROTECTED]> Acked-by: Peter Stuge <[EMAIL PROTECTED]> -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] [BUILDROM] Download and prepend the VGA VBIOS for the ga-2761gxdk
On Wed, Nov 28, 2007 at 04:18:11PM -0700, Jordan Crouse wrote: > [BUILDROM] Download and prepend the VGA VBIOS for the ga-2761gxdk > > First try at downloading and prepending the VGA VBIOS for the ga-2761gxdk > board stored on linuxbios.org. This should be generic enough to extend > to other platforms when the time comes. > > Signed-off-by: Jordan Crouse <[EMAIL PROTECTED]> Acked-by: Peter Stuge <[EMAIL PROTECTED]> -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] [BUILDROM] Add targets for mconf and lxdialog
On Wed, Nov 28, 2007 at 04:13:49PM -0700, Jordan Crouse wrote: > [BUILDROM] Add targets for mconf and lxdialog > > There isn't any need to be running make for mconf and lxdialog every > time we run menuconfig - we invoke the power of Make and add the two > utilities as dependencies. > > Signed-off-by: Jordan Crouse <[EMAIL PROTECTED]> Acked-by: Peter Stuge <[EMAIL PROTECTED]> -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] r64 - in buildrom-devel: config/platforms packages/linuxbios packages/linuxbios/patches
On Wed, Nov 28, 2007 at 07:49:12PM +0100, [EMAIL PROTECTED] wrote: > a patch against LinuxBIOS to allow the Serengeti-Cheetah platform > to come up on its emulated self in the SimNow simulator. Should this go into LB proper? //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] Can't compile flashrom
On Tue, Nov 27, 2007 at 08:23:07PM -0800, Russell Whitaker wrote: > It's not libpci.a, it's a missing zlib package. It contains libz > and libz.so. In the Makefile the flags passed to the linker are > " -lpci -lz" Does the zlib package really contain a file called libz ? Where? Anyway, libz.so is the shared library and is no good here, you need a libz.a because flashrom is statically linked. (The -static option.) //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] Micro-ATX Via CN700 + VT8237R plus
On Wed, Nov 28, 2007 at 12:43:39AM +, Forest Dean Feighner wrote: > Looks like the BIOS is Award BIOS 512KB (4Mbit) Flash ROM. > I guess that will limit my options in terms of payload. You could replace the flash chip with one that has more room. //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] flashrom support for AMD CS5536
On Wed, Nov 28, 2007 at 10:34:51AM -, Alan Alexander wrote: > Do you think it's worth changing the code to perform the entire > chip erase via a sequence of block erases instead Yes, definately. > This e-mail (including any attachments) is intended only for the > recipient(s) named above. It may contain confidential or privileged > information Does your company really send confidential or privileged information via plain text email? You may want to look into securing your communications. //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] Can't compile flashrom
On Tue, Nov 27, 2007 at 05:19:01PM -0700, Shocky wrote: > Thanks, I knew there had to be a command that would do this. This > just deepens the mystery further. nm tells me that within > /usr/lib/libpci.a access.o defines the external symbol > "0760 T pci_alloc". So if nm can see it, why can't ld see it? What if you link with the archive manually: ld -o flashrom file1.o file2.o /usr/lib/libpci.a (ie don't use -lpci) //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] patch: lx northbridge use spd_read_byte and add debug prints
On Tue, Nov 27, 2007 at 08:24:15AM -0800, ron minnich wrote:
> .. banner
Could this be made more generic/common for more boards?
> +/**
> + * Halt and Catch Fire. Print an error, then loop, sending NULLs on serial
> port,
> + * to ensure the message is visible.
> + *
> + */
> +
> +void hcf(void)
> +{
> + printk(BIOS_EMERG, "DIE\r\n");
> + /* this guarantees we flush the UART fifos (if any) and also
> + * ensures that things, in general, keep going so no debug output
> + * is lost
> + */
> + while (1)
> + printk(BIOS_EMERG, "\r");
> +}
Could this be a common die() instead?
//Peter
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] v3: convert stage2 to multi-segment LAR
On Tue, Nov 27, 2007 at 09:44:18AM -0700, Jordan Crouse wrote: > For the filename, we could figure out a good way to add it to the > .comment section of the ELF - that could open up a new world of > passing information to LAR via the .o without the command line. > Or am I super double guilty for invoking black magic? FILO explicitly gets rid of all ELF notes during build, except the name/version for elfboot, with a reference to gcc producing many junk notes. Another thought: While it's probably quite possible to send stuff from .c to larball - is this really something we want to do? Should non-code information in .c really have to be in the larball? Or, put a bit differently, should the file in the larball really need to have information from a .c that is not code? //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] v3: convert stage2 to multi-segment LAR
On Tue, Nov 27, 2007 at 09:33:29AM -0700, Jordan Crouse wrote: > So call it what it is - a useful option to LAR to cut out the > objcopy middleman. Which is fine. I'm happy with that. It's even a bit better since the objcopy would destroy the entry point. > Also, I would abandon the use of .o naming in the LAR - that will > drive others (like me) off course thinking an object file is living > in the LAR, which is not the case. The "object file" is now a subdirectory in the lar - blah.o/segment0 Perhaps too subtle in a new archive format? I think it's OK as long as we have good docs for lar explaining why we've created it and how it is supposed to work. //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] alix1c for v3 update
On Tue, Nov 27, 2007 at 08:02:02AM -0800, ron minnich wrote:
> +++ mainboard/pcengines/alix1c/stage1.c (working copy)
>
> +#define SERIAL_DEV W83627HF_SP1
> +#define SERIAL_IOBASE 0x3f8
> +++ mainboard/pcengines/alix1c/dts(working copy)
> @@ -37,5 +37,9 @@
> pcipath = "0xf,1";
> enabled;
> };
> + superio {
> + /config/("superio/winbond/w83627hf");
> + com1enable = "1";
> + };
Why is the port needed in stage1.c?
I would like it to be tied either to the superio (preferably) or in
the dts, if there is positively no other place to put it.
//Peter
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] [PATCH] v3: convert stage2 to multi-segment LAR
On Tue, Nov 27, 2007 at 10:33:51AM +0100, Stefan Reinauer wrote: > > Convert stage2 handling from binary blob to multi-segment LAR > > which is created by parsing the ELF file linuxbios.stage2.o. > > I can't believe this is the workaround for not being able to put a > "jmp _entry" in front of the code. Come again? By the way, have we asked gcc/binutils people about suggested ways to do what we want? Maybe they know something we don't? //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] r523 - in LinuxBIOSv3: arch/x86 lib mainboard/adl/msm800sev mainboard/amd/norwich mainboard/artecgroup/dbe61 mainboard/emulation/qemu-x86 mainboard/pcengines/alix1c
On Tue, Nov 27, 2007 at 03:38:43PM +0100, [EMAIL PROTECTED] wrote: > As added benefit, we obsolete a lot of code without introducing > new code. This is sweet. It would be great to get rid of that obsolete code sooner rather than later now that it isn't needed anymore, when it's fresh in memory. //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] USB 2.0 Controller without debug port
On Thu, Nov 22, 2007 at 03:49:01PM +0100, Wander Winkelhorst wrote: > I have a VIA SP13000 motherboard that wasn't listed and doesn't > have the debug port capability: > > lspci -n: > :00:10.4 0c03: 1106:3104 (rev 86) > > I hope this helps! Thanks, I added this to the wiki. One big reason for the page was to get an idea for how common the debug port is. So far we are not always forced to rely on it, but it is valuable information to have. //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] patch: alix1c support for v3
On Mon, Nov 26, 2007 at 10:17:55PM +, Uwe Hermann wrote: > On Sun, Nov 25, 2007 at 07:07:42PM -0800, ron minnich wrote: > > try again. > > Yep, works now. Committed as r521 with some coding style fixes etc. I will give this a go before FSCONS. I want to demo v3 for sure. //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] [PATCH] Remove Bitworks IMS
On Mon, Nov 26, 2007 at 07:31:14PM -0500, Richard Smith wrote: > What 440bx based boards now work? tyan/s1846 //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] patch: post code standard
On Mon, Nov 26, 2007 at 03:02:00PM -0800, ron minnich wrote: > comments welcome. I would very much like this file to have the codes in chronological order. Maybe put global stuff like FATAL_ERROR first? //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] patch: prepare v3 tree for new way of doing initram
On Mon, Nov 26, 2007 at 02:53:51PM -0800, ron minnich wrote: > I would appreciate comments on this, I like this very much. > and I wonder if we shouldn't just drop the "binary blob" initram > immediately. I don't see a need for it at this point. Go for it. //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] GIGABYTE GA-2761GXDK
On Sat, Nov 24, 2007 at 07:37:42PM -0800, ron minnich wrote: > it's a beautiful board and this is really pretty exciting! Very nice board indeed! //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] "Trivial" patches
On Tue, Nov 20, 2007 at 07:57:51PM +0100, Uwe Hermann wrote: > On Tue, Nov 20, 2007 at 07:40:26PM +0100, Carl-Daniel Hailfinger wrote: > > OK, can we decide on what should be (not) allowed, preferably as > > regexp for the diff? > > Please don't over-engineer this. I am with Uwe. Let's use common sense and respect our peers. //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] alix1c
On Sat, Nov 17, 2007 at 09:14:46PM -0500, Tom Sylla wrote: > > Does anyone know what can be done to appease the hardware into > > _not_ shutting down even though pwrbtn is held pressed from boot? > > See this: > http://www.linuxbios.org/pipermail/linuxbios/2007-October/025978.html > and its thread. Thanks for even digging it up for me! > LB is programming the power button to shut down after 4 seconds. If > you don't want it to shut down *don't do that* :) Check. :) I think I will add a new option for this. //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] alix1c
On Thu, Nov 15, 2007 at 09:44:50PM -0800, ron minnich wrote: > > The board shows the POST for about a second and then powers off. > > take the jumper off the power pins, It is delivered with the jumper > on. Hahaha! Lovely! =) Thanks. I did not think about this at all because it does not behave the same way with the onboard BIOS. Does anyone know what can be done to appease the hardware into _not_ shutting down even though pwrbtn is held pressed from boot? //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] FILO with the USB
On Sat, Nov 17, 2007 at 01:39:33PM -0800, Vlad wrote: > There are at least two "super-BIOS" implementations that rely on a > tiny Linux kernel loaded from Flash ROM: Good point. For LAB I believe Stefan wants to include more drivers in order to avoid having to rebuild/reflash the BIOS when the SCSI controller burns and the system needs to rescue-boot from something else. //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
[LinuxBIOS] alix1c
Limited success.
LinuxBIOS-2.0.0.0Fallback Fri Nov 16 05:46:41 CET 2007 booting...
I added a POST code and a while(1) near the end of hardwaremain.c
after this message. The board shows the POST for about a second and
then powers off.
If I move the while(1) to after init_timer() it pauses on POST 11 for
a second or so, then shows some other codes quickly, then 80 and
then power off, even though init_timer() seems to be do {} while(0)
on the alix1c. This is also the behavior I get with a fresh checkout.
//Peter
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] [PATCH 1/2] v3: improve printk documentation
On Thu, Nov 15, 2007 at 06:13:41PM +0100, Carl-Daniel Hailfinger wrote: > Improve printk documentation to match code realities. Nak, for some hunks. At some point I hope that LB printk will end up in the kernel message buffer. Then, we are able to handle anything from time zero, so let's not remove any printks. The tidying is good though! //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] IRQ question
Hi, On Thu, Nov 15, 2007 at 11:05:57AM +0800, Feng, Libo wrote: > A simple question: But a very good one! > when talking about IRQ, you mean one of the 256 interrupt vectors > within x86, No, these are never called IRQs, but they are often called interrupts, and IRQs are also often called interrupts. Usually not in the same context though. > or one of the pins of APIC, or one of the pins of 8259? Yes, this is it. Whether it's APIC or PIC depends on the board and configuration, but IRQ is about the physical signals or at the least something relating to the interrupt controllers. > I always got confused by it. Quite alright. :) //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] alix2/alix3 ?
On Tue, Nov 13, 2007 at 09:46:39PM -0800, ron minnich wrote: > I would guess that all the we need do are extend the IRQ tables. Some of the ball muxing probably changed a bit too. Do you correspond with Pascal? > We're still fighting irq issues on the alix 1.c, I am on travel > but will try again when I get back. I should get mine today and will try it out and send a report. Busy day though. //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] Intel 865 GBF motherboard support
On Tue, Nov 13, 2007 at 06:40:44AM -0800, Rams Rambo wrote: > I would be interested to know if your supporting for my Intel > mother board? Unfortunately we do not. Not yet at least. > If none of these support will there be new version would be > released which could possibly support Intel 865 GBF mother boards. There has been some work done on the 865 chipset, but it still requires some (much?) work. I don't know if there is a timeframe, I think the people who started working on it (Joe, right?) are working on something else at the moment. //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] r2967 - trunk/util/flashrom
On Tue, Nov 13, 2007 at 05:45:22PM +0100, [EMAIL PROTECTED] wrote:
> + if (buf[7] != 0x22) {
> + printf("Enabling Geode MSR to write to flash.\n");
> + buf[7] = 0x22;
I don't know. Maybe I'm just reading the data book wrong. Please hit
me over the head again in that case.
It says bit 5=1 (0x20) and bit 0=0 => Unpredictable behavior occurs.
0x02 is write-allocate. Why do we want to do that?
0x21 on the other hand, is uncacheable+write-serialize and sounds
more like what we want.
> + fd_msr = open("/dev/cpu/0/msr", O_WRONLY);
Anyway, I imagine that this will be needed for more chips. How do you
feel about moving the MSR:ing to a handy helper?
//Peter
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] [PATCH] Drop Bitworks IMS board
On Tue, Nov 13, 2007 at 03:47:07PM +0100, Uwe Hermann wrote: > Drop the unfinished, non-working Bitworks IMS board. Richard? Ok with you? //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] [PATCH] flashrom: Fix ATMEL 29C020 detection
On Tue, Nov 13, 2007 at 03:08:45PM +0100, Carl-Daniel Hailfinger wrote: > Fix ATMEL 29C020 detection with flashrom. Acked-by: Peter Stuge <[EMAIL PROTECTED]> -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] FSCONS 2007
On Tue, Nov 13, 2007 at 10:11:07AM +0100, Uwe Hermann wrote: > http://fscons.org/node/138 They're getting a brief intro and bio from me for that page. //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
