From bios at lists.actweb.info  Sat Jul  1 01:41:32 2006
From: bios at lists.actweb.info (bios at lists.actweb.info)
Date: Sat,  1 Jul 2006 00:41:32 +0100 (BST)
Subject: [LinuxBIOS] cant detect bios with flash software {Scanned}
In-Reply-To: <20060630201647.GA18776@coresystems.de>
Message-ID: <1151710892.31382@actweb.info>

:) IT WORKED :)

THANK YOU VERY VERY VERY MUCH :)

sucseval read of original bios (didnt write to it!!) and then write to RD1

have jsut swapped original bios with replacement bios chip, and will write the bios image to that as well.

The original bios will be packed away for save keeping, and ill work on the RD1 bios, and the replacement bios :)

I take it that if it read ok, then thats the file working, or is the writing process diferant? if it is, ill insert the original and try writing for you, jsut to confirm it works, if not, then id say thats a sucesful addition to the source :)


again many thanks

Matt


Stefan Reinauer wrote ..
> * Stefan Reinauer <stepan at coresystems.de> [060630 21:49]:
> > > Im not sure what u mean by verifing that the image starts 25 a6???
> are
> > > you talking about an image file taken from the BIOS using VIAs flash
> > > utility?
> >  
> > I thought that might be the vendor and device id. In fact it is 8c and
> > 00, as it is a 256kb part
> 
> Ok, can you please check out revision 2336. I checked in some untested
> support for your flash part.
> 
> Can you try the following:
> 
> 
> Please be careful which chip you use at a time. If you mess the order up
> you will most likely render your system unusable ...
> 
> 
> 1. make a copy of your bios:
> 
>    switch to the EFST, then do:
> 
>     ./flashrom -r legacybios.bin
> 
> 
> 2. write the copy to your bios savior
> 
>    switch to the bios savior (Winbond W49F002U)
> 
>     ./flashrom -w legacybios.bin
> 
> 3. Verify the copy in the bios savior
> 
>     ./flashrom -v legacybios.bin
> 
> 
> 4. Overwrite the EMST flash to see if the new flashbios version works
> 
>    switch to the EMST again!
> 
>     dd if=/dev/zero of=nullbios.bin bs=256k count=1
>     ./flashbios -w nullbios.bin
>     ./flashbios -v nullbios.bin
> 
>    (it should say "verified" here!!!!)
> 
>    then you can write the original bios back to the EMST so you have
>    two valid copies for playing later.
> 
>    ./flashbios -w legacybios.bin
>    ./flashbios -v legacybios.bin   
> 
> 
> Please post the results here..
> 
> 
> -- 
> coresystems GmbH ??? Brahmsstr. 16 ??? D-79104 Freiburg i. Br.
>       Tel.: +49 761 7668825 ??? Fax: +49 761 7664613
> Email: info at coresystems.de  ??? http://www.coresystems.de/
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> MailScanner thanks ACTweb Computers for their support.

From bios at lists.actweb.info  Sat Jul  1 02:43:01 2006
From: bios at lists.actweb.info (bios at lists.actweb.info)
Date: Sat,  1 Jul 2006 01:43:01 +0100 (BST)
Subject: [LinuxBIOS] LB Post codes
In-Reply-To: <20060630201647.GA18776@coresystems.de>
Message-ID: <1151714580.2679@actweb.info>

Hi,

From rminnich at lanl.gov  Sat Jul  1 04:17:04 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Fri, 30 Jun 2006 20:17:04 -0600
Subject: [LinuxBIOS] LB Post codes
In-Reply-To: <1151714580.2679@actweb.info>
References: <1151714580.2679@actweb.info>
Message-ID: <44A5DB20.4010708@lanl.gov>

bios at lists.actweb.info wrote:
> Hi,
> 
> From what ive read on the LB site, LB uses post codes quitre a bit, but i cant find a list of the codes ANYWARE :(

ah, yes, well, uh, that's my fault.

> Ive just tried LB on a VIA-EPAI-PD10000 board using the EPAI-M LB config (i dont have a serial cable connected at present, going to grab one tomorow!)
> using my post card i get the following sequance displayed : 10/80/05 (all hex)

best thing to do is grep -i post in src ... yuck! sorry.

ron



From stepan at coresystems.de  Sat Jul  1 12:47:23 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sat, 1 Jul 2006 12:47:23 +0200
Subject: [LinuxBIOS] LB Post codes
In-Reply-To: <44A5DB20.4010708@lanl.gov>
References: <1151714580.2679@actweb.info> <44A5DB20.4010708@lanl.gov>
Message-ID: <20060701104723.GA14170@coresystems.de>

* Ronald G Minnich <rminnich at lanl.gov> [060701 04:17]:
> bios at lists.actweb.info wrote:
> > Hi,
> > 
> > From what ive read on the LB site, LB uses post codes quitre a bit,
> > but i cant find a list of the codes ANYWARE :(
> 
> ah, yes, well, uh, that's my fault.
> 
> > Ive just tried LB on a VIA-EPAI-PD10000 board using the EPAI-M LB
> > config (i dont have a serial cable connected at present, going to
> > grab one tomorow!) using my post card i get the following sequance
> > displayed : 10/80/05 (all hex)
> 
> best thing to do is grep -i post in src ... yuck! sorry.

Should we make a list of those in the wiki and try to get them
straightened out in the different ports a bit? Or do we keep this
as a pool of "implementor's freedom"?


-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From stepan at coresystems.de  Sat Jul  1 13:00:22 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sat, 1 Jul 2006 13:00:22 +0200
Subject: [LinuxBIOS] cant detect bios with flash software {Scanned}
In-Reply-To: <1151710892.31382@actweb.info>
References: <20060630201647.GA18776@coresystems.de>
	<1151710892.31382@actweb.info>
Message-ID: <20060701110022.GB14170@coresystems.de>

* bios at lists.actweb.info <bios at lists.actweb.info> [060701 01:41]:
> sucseval read of original bios (didnt write to it!!) and then write to
> RD1

ok, that's the easy part. 

> The original bios will be packed away for save keeping, and ill work
> on the RD1 bios, and the replacement bios :)

so you have 3 bios chips in a whole?

> I take it that if it read ok, then thats the file working, or is the
> writing process diferant? if it is, ill insert the original and try
> writing for you, jsut to confirm it works, if not, then id say thats a
> sucesful addition to the source :)

Yes, the write process is the actually complicated part. Reading is
mostly trivial. If you want, go ahead and try writing it - It _should_
work, according to the data sheet about the chip. Since you have a
working copy in the bios savior, its not dangerous. 

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From stepan at coresystems.de  Sat Jul  1 13:02:14 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sat, 1 Jul 2006 13:02:14 +0200
Subject: [LinuxBIOS] LB Post codes
In-Reply-To: <1151714580.2679@actweb.info>
References: <20060630201647.GA18776@coresystems.de>
	<1151714580.2679@actweb.info>
Message-ID: <20060701110214.GC14170@coresystems.de>



* bios at lists.actweb.info <bios at lists.actweb.info> [060701 02:43]:
> From what ive read on the LB site, LB uses post codes quitre a bit,
> but i cant find a list of the codes ANYWARE :(
> Ive just tried LB on a VIA-EPAI-PD10000 board using the EPAI-M LB
> config (i dont have a serial cable connected at present, going to grab
> one tomorow!)

Getting the system up without serial cable is really hard to impossible
I guess..

The post codes are not really used in LinuxBIOS as far as I can say.

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From yinghailu at gmail.com  Sat Jul  1 14:31:56 2006
From: yinghailu at gmail.com (yhlu)
Date: Sat, 1 Jul 2006 05:31:56 -0700
Subject: [LinuxBIOS] LB Post codes
In-Reply-To: <20060701110214.GC14170@coresystems.de>
References: <20060630201647.GA18776@coresystems.de>
	<1151714580.2679@actweb.info> <20060701110214.GC14170@coresystems.de>
Message-ID: <2ea3fae10607010531v3d8d2752p58f8ec7b78264728@mail.gmail.com>

that is right. the post code is only useful before we get the output
from serial port.

YH

On 7/1/06, Stefan Reinauer <stepan at coresystems.de> wrote:
>
>
> * bios at lists.actweb.info <bios at lists.actweb.info> [060701 02:43]:
> > From what ive read on the LB site, LB uses post codes quitre a bit,
> > but i cant find a list of the codes ANYWARE :(
> > Ive just tried LB on a VIA-EPAI-PD10000 board using the EPAI-M LB
> > config (i dont have a serial cable connected at present, going to grab
> > one tomorow!)
>
> Getting the system up without serial cable is really hard to impossible
> I guess..
>
> The post codes are not really used in LinuxBIOS as far as I can say.
>
> --
> coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
>       Tel.: +49 761 7668825 ? Fax: +49 761 7664613
> Email: info at coresystems.de  ? http://www.coresystems.de/
>
> --
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios



From bios at lists.actweb.info  Sat Jul  1 21:48:37 2006
From: bios at lists.actweb.info (bios at lists.actweb.info)
Date: Sat,  1 Jul 2006 20:48:37 +0100 (BST)
Subject: [LinuxBIOS] LB on PD10000
In-Reply-To: <mailman.1.1151748001.12797.linuxbios@linuxbios.org>
Message-ID: <1151783317.32574@actweb.info>

Ok, found a serial cable :)

Booting up the EPIA-PD1000 I get the following via serial terminal :-

0

LinuxBIOS-1.1.8.0Fallback Sat Jul  1 01:02:23 BST 2006 starting...
 Enabling mainboard devices
 Enabling shadow ram
vt8623 init starting


and thats as far as it gets :(
Is there a setting to get a more verbose output?
or can anyone give me any pointers just from this? (LOL)

As i understand it the vt8623 is the video chip, does this meen that my via video bios grab didnt work properly?
Is there an alternative to using the via video bios grabbed from the via bios?
Also as another idea, do u actually NEED the vt8623 to be initalised? if you dont need vga output? if not how do u disable it?


Thanks

Matt

From bios at lists.actweb.info  Sun Jul  2 02:24:25 2006
From: bios at lists.actweb.info (bios at lists.actweb.info)
Date: Sun,  2 Jul 2006 01:24:25 +0100 (BST)
Subject: [LinuxBIOS] lb on pd10000
In-Reply-To: <mailman.1.1151748001.12797.linuxbios@linuxbios.org>
Message-ID: <1151799865.16270@actweb.info>

Hi folks,

Ok, ive had a play around with the code for LB to see if i can find where its failing and have found the following :-

in file : src/northbridge/via/vt8623/raminit.c

I added a couple of line to show were in the file its crashing :-

        /* setup cpu */
        pci_write_config8(north,0x50,0xc8);
        pci_write_config8(north,0x51,0xde);
        pci_write_config8(north,0x52,0xcf);
        pci_write_config8(north,0x53,0x88);
        pci_write_config8(north,0x55,0x04);
        print_debug("vt8623 init step 2\r\n");
/*
    DRAM MA Map Type  Device 0  Offset 58

    Determine memory addressing based on the module's memory technology and
    arrangement.  See Table 4-9 of Intel's 82443GX datasheet for details.

    Bank 1/0 MA map type   58[7-5]
    Bank 1/0 command rate  58[4]
    Bank 3/2 MA map type   58[3-1]
    Bank 3/2 command rate  58[0]


    Read SPD byte 17, Number of banks on SDRAM device.
*/
        print_debug("vt8623 init step 3\r\n");
        c = 0;
        b = smbus_read_byte(0xa0,17);
        print_debug("vt8623 init step 4\r\n");
        print_val("Detecting Memory\r\nNumber of Banks ",b);
        print_debug("vt8623 init step 5\r\n");
        if( b != 2 ){            // not 16 Mb type

/*
    Read SPD byte 3, Number of row addresses.
*/


At line 103 (aprox, as ive added some lines for debug as u can see)
the print_debug("vt8623 init step 3\r\n"); statment works ok
BUT I NEVER GET THE 'step 4' debug statments outputting
so i can assume (and PLEASE correct me if im wrong, or if u recon the lines ive added are the cause)
the the bad line is :

 b = smbus_read_byte(0xa0,17);


Ok, after finding this line, i hunted for the source for smbus_read_byte which i belive is in :
src/southbridge/via/vt8231/vt8231_early_smbus.c
(am i corect in thinking this??????)
Im not sure because i edited the file starting at line 151 and added in my debug lines as follows :-

static int smbus_read_byte(unsigned device, unsigned address)
{
        print_debug("smbus_read_byte start\r\n");
        unsigned char global_control_register;
        unsigned char global_status_register;
        unsigned char byte;

        print_debug("smbus_read_byte step 2\r\n");
        if (smbus_wait_until_ready() < 0) {
                outb(inb(SMBUS_IO_BASE + SMBHSTSTAT), SMBUS_IO_BASE + SMBHSTSTA$
                if (smbus_wait_until_ready() < 0) {
                        return -2;
                }
        }
        print_debug("smbus_read_byte step 3\r\n");

        /* setup transaction */
        /* disable interrupts */
        outb(inb(SMBUS_IO_BASE + SMBHSTCTL) & 0xfe, SMBUS_IO_BASE + SMBHSTCTL);
        print_debug("smbus_read_byte step 4\r\n");
        /* set the device I'm talking too */
        outb(((device & 0x7f) << 1) | 1, SMBUS_IO_BASE + SMBXMITADD);
        print_debug("smbus_read_byte step 5\r\n");
        /* set the command/address... */
        outb(address & 0xFF, SMBUS_IO_BASE + SMBHSTCMD);
        print_debug("smbus_read_byte step 6\r\n");
        /* set up for a byte data read */
        outb((inb(SMBUS_IO_BASE + SMBHSTCTL) & 0xe3) | (0x2 << 2), SMBUS_IO_BAS$
        print_debug("smbus_read_byte step 7\r\n");

        /* clear any lingering errors, so the transaction will run */
        outb(inb(SMBUS_IO_BASE + SMBHSTSTAT), SMBUS_IO_BASE + SMBHSTSTAT);
        print_debug("smbus_read_byte step 8\r\n");

        /* clear the data byte... */
        outb(0, SMBUS_IO_BASE + SMBHSTDAT0);
        print_debug("smbus_read_byte step 9\r\n");

        /* start a byte read, with interrupts disabled */
        outb((inb(SMBUS_IO_BASE + SMBHSTCTL) | 0x40), SMBUS_IO_BASE + SMBHSTCTL$
        print_debug("smbus_read_byte step 10\r\n");
        /* poll for it to start */
        if (smbus_wait_until_active() < 0) {
                return -4;
        }
        print_debug("smbus_read_byte step 11\r\n");

        /* poll for transaction completion */
        if (smbus_wait_until_done() < 0) {
                return -3;
        }

        print_debug("smbus_read_byte step 12\r\n");
        /* Ignore the Host Busy & Command Complete ? */
        global_status_register = inb(SMBUS_IO_BASE + SMBHSTSTAT) & ~((1 << 1) |$
        print_debug("smbus_read_byte step 13\r\n");

        /* read results of transaction */
        byte = inb(SMBUS_IO_BASE + SMBHSTDAT0);
        print_debug("smbus_read_byte step 14\r\n");

        if (global_status_register != 0) {
                return -1;
        }
        print_debug("smbus_read_byte step 15\r\n");
        return byte;
}



Unfortunatly NOTHING EXTRA was displayed via the serial port :(
So, first, is this the write file that im editing to find were the problem is occuring?
second, if so, why didnt i get at leaste the first print_debug before anything else was run in the routine?
if its not the correct file, which file should i edit?
Is this all necisarry, or has someone else already done all this, and got a solution :)

One last thing, am i correct in thinking that simply going into src/targets/via/epia-m/epia-m/ and running 'make clean', 'make'
is enough to recompile all the routines (including the southbridge stuff)?


Matt

From samuel.thibault at ens-lyon.org  Mon Jul  3 00:06:52 2006
From: samuel.thibault at ens-lyon.org (Samuel Thibault)
Date: Mon, 3 Jul 2006 00:06:52 +0200
Subject: [LinuxBIOS] Accessibility of LinuxBios
Message-ID: <20060702220652.GP4414@bouh.residence.ens-lyon.fr>

Hi,

BIOSes is an area where accessibility is approximately non-existent.
Asking vendors to support hardware speech syntheses and braille devices
is quite dreamwork. I tried to convince accessibility people to release
basic drivers with BSD licenses so that vendors might integrate them,
but they just refused that, arguing that vendors will not make any
effort to integrate them, and there will always be bugs (which are hard
to debug/fix/integrate/... with vendor BIOSes).

LinuxBios, however, can be a great opportunity to have an accessible
BIOS.

So what can be done? If I understood well, LinuxBios is a linux kernel
-based bios. Does that mean that it has the notion of process, or does
it run only in kernel mode? (which is sufficient for taking advantage of
linux drivers).

Samuel



From stepan at coresystems.de  Mon Jul  3 01:11:05 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 3 Jul 2006 01:11:05 +0200
Subject: [LinuxBIOS] Accessibility of LinuxBios
In-Reply-To: <20060702220652.GP4414@bouh.residence.ens-lyon.fr>
References: <20060702220652.GP4414@bouh.residence.ens-lyon.fr>
Message-ID: <20060702231105.GB17504@coresystems.de>

* Samuel Thibault <samuel.thibault at ens-lyon.org> [060703 00:06]:
> BIOSes is an area where accessibility is approximately non-existent.
> Asking vendors to support hardware speech syntheses and braille devices
> is quite dreamwork. I tried to convince accessibility people to release
> basic drivers with BSD licenses so that vendors might integrate them,
> but they just refused that, arguing that vendors will not make any
> effort to integrate them, and there will always be bugs 
 
Maybe this code could be encapsulated, similar to how VGA
bios or network boot is handled. On the other hand, this would cut off
quite some of the bringup from "visibility"

> LinuxBios, however, can be a great opportunity to have an accessible
> BIOS.
> 
> So what can be done? If I understood well, LinuxBios is a linux kernel
> -based bios. Does that mean that it has the notion of process, or does
> it run only in kernel mode? (which is sufficient for taking advantage of
> linux drivers).

LinuxBIOS initializes the machine just far enough so that it can run a
Linux kernel from flash memory, hence the name. This in-flash Linux can
run normal userspace programs as well as load another kernel from a
hard disk or any other supported medium. 

usually we can say: the main information exchange with LinuxBIOS (before
the kernel is started) is not via VGA but via serial, which i believe is
in theory usable with a braille terminal connected to another machine. 
(Is this correct?)

The interaction part is all happening while Linux is loaded (ie. from flash)
so we could use a local braille terminal at this point by using all the
Linux utilities. 

One question is: how big is the Linux code to support one/some/many/all
braille terminals and can we fit this in a 512kB/1MB flash part.
The answer mostly depends on your needs.

Regards
Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From samuel.thibault at ens-lyon.org  Mon Jul  3 01:26:22 2006
From: samuel.thibault at ens-lyon.org (Samuel Thibault)
Date: Mon, 3 Jul 2006 01:26:22 +0200
Subject: [LinuxBIOS] Accessibility of LinuxBios
In-Reply-To: <20060702231105.GB17504@coresystems.de>
References: <20060702220652.GP4414@bouh.residence.ens-lyon.fr>
	<20060702231105.GB17504@coresystems.de>
Message-ID: <20060702232622.GB4028@implementation>

Hi,

Great to have so fast a reply :)

Stefan Reinauer, le Mon 03 Jul 2006 01:11:05 +0200, a ?crit :
> * Samuel Thibault <samuel.thibault at ens-lyon.org> [060703 00:06]:
> > BIOSes is an area where accessibility is approximately non-existent.
> > Asking vendors to support hardware speech syntheses and braille devices
> > is quite dreamwork. I tried to convince accessibility people to release
> > basic drivers with BSD licenses so that vendors might integrate them,
> > but they just refused that, arguing that vendors will not make any
> > effort to integrate them, and there will always be bugs 
>  
> Maybe this code could be encapsulated, similar to how VGA
> bios or network boot is handled.

Indeed, except that it relies on serial or USB support, which might not
be easy to ship in a so encapsulated way.

> On the other hand, this would cut off quite some of the bringup from
> "visibility"

I'm sorry, my poor english couldn't understand that :)

> > LinuxBios, however, can be a great opportunity to have an accessible
> > BIOS.
> > 
> > So what can be done? If I understood well, LinuxBios is a linux kernel
> > -based bios. Does that mean that it has the notion of process, or does
> > it run only in kernel mode? (which is sufficient for taking advantage of
> > linux drivers).
> 
> LinuxBIOS initializes the machine just far enough so that it can run a
> Linux kernel from flash memory, hence the name. This in-flash Linux can
> run normal userspace programs as well as load another kernel from a
> hard disk or any other supported medium. 

Oh, great. That means that we can run the usual screen reader called
brltty, or any other such reader.

> usually we can say: the main information exchange with LinuxBIOS (before
> the kernel is started) is not via VGA but via serial, which i believe is
> in theory usable with a braille terminal connected to another machine. 
> (Is this correct?)

Yes. Minicom is quite accessible, so that's fine.

> The interaction part is all happening while Linux is loaded (ie. from flash)
> so we could use a local braille terminal at this point by using all the
> Linux utilities. 

Yup.

> One question is: how big is the Linux code to support one/some/many/all
> braille terminals and can we fit this in a 512kB/1MB flash part.
> The answer mostly depends on your needs.

Devices usually depend on serial or USB support, plus the /dev/vcsa
interface for reading the console's content.

Samuel



From stepan at coresystems.de  Mon Jul  3 01:41:49 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 3 Jul 2006 01:41:49 +0200
Subject: [LinuxBIOS] Accessibility of LinuxBios
In-Reply-To: <20060702232622.GB4028@implementation>
References: <20060702220652.GP4414@bouh.residence.ens-lyon.fr>
	<20060702231105.GB17504@coresystems.de>
	<20060702232622.GB4028@implementation>
Message-ID: <20060702234148.GA19676@coresystems.de>

* Samuel Thibault <samuel.thibault at ens-lyon.org> [060703 01:26]:
> > Maybe this code could be encapsulated, similar to how VGA
> > bios or network boot is handled.
> 
> Indeed, except that it relies on serial or USB support, which might not
> be easy to ship in a so encapsulated way.
 
Serial support is easy. USB is more of a problem as it needs a complete
usb stack at bios time.

> > On the other hand, this would cut off quite some of the bringup from
> > "visibility"
> 
> I'm sorry, my poor english couldn't understand that :)
 
Sorry for the confusion. Transforming sentences from german to english
to french is sometimes hard :) 

What I was trying to say is: If you plug it in all code that is executed
before the plugin gets started gets lost.

> Devices usually depend on serial or USB support, plus the /dev/vcsa
> interface for reading the console's content.

mostly due to the fact that new braille terminals mostly use usb rather
than serial this would be the way to go, trying to get the required
system as small as possible (ie uclibc, minimal kernel etc)

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From samuel.thibault at ens-lyon.org  Mon Jul  3 01:46:58 2006
From: samuel.thibault at ens-lyon.org (Samuel Thibault)
Date: Mon, 3 Jul 2006 01:46:58 +0200
Subject: [LinuxBIOS] Accessibility of LinuxBios
In-Reply-To: <20060702234148.GA19676@coresystems.de>
References: <20060702220652.GP4414@bouh.residence.ens-lyon.fr>
	<20060702231105.GB17504@coresystems.de>
	<20060702232622.GB4028@implementation>
	<20060702234148.GA19676@coresystems.de>
Message-ID: <20060702234657.GA4113@implementation>

Stefan Reinauer, le Mon 03 Jul 2006 01:41:49 +0200, a ?crit :
> * Samuel Thibault <samuel.thibault at ens-lyon.org> [060703 01:26]:
> > > On the other hand, this would cut off quite some of the bringup from
> > > "visibility"
> > 
> > I'm sorry, my poor english couldn't understand that :)
>  
> Sorry for the confusion. Transforming sentences from german to english
> to french is sometimes hard :) 
> 
> What I was trying to say is: If you plug it in all code that is executed
> before the plugin gets started gets lost.

Ok, makes sense. We indeed would like output as early as possible.

> > Devices usually depend on serial or USB support, plus the /dev/vcsa
> > interface for reading the console's content.
> 
> mostly due to the fact that new braille terminals mostly use usb rather
> than serial

Indeed. There are some hardware speech synthesis too, but they often
only require i/o ports access, serial access, or maybe parallel port
access.

Samuel



From bari at onelabs.com  Mon Jul  3 02:40:32 2006
From: bari at onelabs.com (Bari Ari)
Date: Sun, 02 Jul 2006 19:40:32 -0500
Subject: [LinuxBIOS] USB Support <WAS Re:  Accessibility of LinuxBios>
In-Reply-To: <20060702234148.GA19676@coresystems.de>
References: <20060702220652.GP4414@bouh.residence.ens-lyon.fr>	<20060702231105.GB17504@coresystems.de>	<20060702232622.GB4028@implementation>
	<20060702234148.GA19676@coresystems.de>
Message-ID: <44A86780.9070601@onelabs.com>

Stefan Reinauer wrote:
> * Samuel Thibault <samuel.thibault at ens-lyon.org> [060703 01:26]:
>   
>>> Maybe this code could be encapsulated, similar to how VGA
>>> bios or network boot is handled.
>>>       
>> Indeed, except that it relies on serial or USB support, which might not
>> be easy to ship in a so encapsulated way.
>>     
>  
> Serial support is easy. USB is more of a problem as it needs a complete
> usb stack at bios time.
>   
I remember discussing with the LinuxBIOS list a year or two ago, the 
issue of what to do when chipsets drop having any serial ports.

We are currently working on mainboard designs that will not have any 
serial ports with chipsets that don't have any serial ports. What did we 
decide to do with LinuxBIOS, since the future is now?

-Bari



From yinghailu at gmail.com  Mon Jul  3 03:31:06 2006
From: yinghailu at gmail.com (yhlu)
Date: Sun, 2 Jul 2006 18:31:06 -0700
Subject: [LinuxBIOS] USB Support <WAS Re: Accessibility of LinuxBios>
In-Reply-To: <44A86780.9070601@onelabs.com>
References: <20060702220652.GP4414@bouh.residence.ens-lyon.fr>
	<20060702231105.GB17504@coresystems.de>
	<20060702232622.GB4028@implementation>
	<20060702234148.GA19676@coresystems.de> <44A86780.9070601@onelabs.com>
Message-ID: <2ea3fae10607021831t1a0fc16r2b4010467d0e3a49@mail.gmail.com>

two ways
1. Eric said that the EHCI that may not need buffer for some debug function.
2. use cpu cache for ohci or uhci buffer for packet.

YH

On 7/2/06, Bari Ari <bari at onelabs.com> wrote:
> Stefan Reinauer wrote:
> > * Samuel Thibault <samuel.thibault at ens-lyon.org> [060703 01:26]:
> >
> >>> Maybe this code could be encapsulated, similar to how VGA
> >>> bios or network boot is handled.
> >>>
> >> Indeed, except that it relies on serial or USB support, which might not
> >> be easy to ship in a so encapsulated way.
> >>
> >
> > Serial support is easy. USB is more of a problem as it needs a complete
> > usb stack at bios time.
> >
> I remember discussing with the LinuxBIOS list a year or two ago, the
> issue of what to do when chipsets drop having any serial ports.
>
> We are currently working on mainboard designs that will not have any
> serial ports with chipsets that don't have any serial ports. What did we
> decide to do with LinuxBIOS, since the future is now?
>
> -Bari
>
> --
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>



From pdegler at rumms.uni-mannheim.de  Mon Jul  3 08:46:23 2006
From: pdegler at rumms.uni-mannheim.de (Philipp Degler)
Date: Mon, 3 Jul 2006 08:46:23 +0200
Subject: [LinuxBIOS] Kernel will not boot
In-Reply-To: <20060328144740.GA12187@openbios.org>
References: <200603281624.49589.pdegler@rumms.uni-mannheim.de>
	<20060328144740.GA12187@openbios.org>
Message-ID: <200607030846.23420.pdegler@rumms.uni-mannheim.de>

filo now finds hda 
-> found reason in "LinuxBIOSv2/src/southbridge/amd/amd8111/amd8111_ide.c"

after commenting several lines :
	//if (conf->ide1_enable) {
                /* Enable secondary ide interface */
                word |= (1<<0);
                printk_debug("IDE1 ");
        //}
        //if (conf->ide0_enable) {
                /* Enable primary ide interface */
                word |= (1<<1);
                printk_debug("IDE0 ");
        //}

ide was initialized and filo could boot from hda.

Well I think the problem is that I don't know how to fill the chip_info 
structure correctly. I tried it by altering Config.lb
	...
	chip southbridge/amd/amd8111
		....
		register "ide0_enable" = "1"
	end
	...
but this did not help. Only by commenting out the if statements I was able to 
init ide.

thx 
phil


On Tuesday 28 March 2006 16:47, you wrote:
> * Philipp Degler <pdegler at rumms.uni-mannheim.de> [060328 16:24]:
> > I tried various payloads to boot the system. Filo could not find my hda
> > saying
>
> for filo disable PCI, that should make it work. It expects ide to sit on
> bus 0 which is normally not the case in linuxbios.
>
> > floating bus. Etherboot loads OK and gets a kernel elf image via tftp but
> > kernel is not loading. Do you have an idea what could be the problem?
> > Maybe some PCI-Devices not initialized correctly?
>
> Have you specified console=ttyS0 as a kernel parameter? Otherwise you
> will not see anything when the kernel starts.
>
> >From the log you sent it looks like the kernel is loaded and executed
>
> but does not talk.
>
> What format is the kernel image? (bzimage?)
>
> > [e1000-82541gi]Ethernet addr: 00:D0:68:09:EC:FE
> > Searching for server (DHCP)...
> > ...Me: xxx.xxx.xxx.xxx, Server: 134.155.45.16, Gateway xxx.xxx.xxx.xxx
> > Loading xxx.xxx.xxx.xxx:/htxlinux.0 ...
> > (ELF)...
> > .........................................................................
> >....................................
> > .........................................................................
> >..........................................................................
> >........
> > .........................................................................
> >..........................................................................
> >........
> > .........................................................................
> >..........................................................................
> >........
> > .........................................................................
> >..........................................................................
> >........
> > ...................................................................done
> > Firmware type: LinuxBIOS



From stepan at coresystems.de  Mon Jul  3 10:34:14 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 3 Jul 2006 10:34:14 +0200
Subject: [LinuxBIOS] USB Support <WAS Re:  Accessibility of LinuxBios>
In-Reply-To: <44A86780.9070601@onelabs.com>
References: <20060702220652.GP4414@bouh.residence.ens-lyon.fr>
	<20060702231105.GB17504@coresystems.de>
	<20060702232622.GB4028@implementation>
	<20060702234148.GA19676@coresystems.de>
	<44A86780.9070601@onelabs.com>
Message-ID: <20060703083414.GB8445@coresystems.de>

* Bari Ari <bari at onelabs.com> [060703 02:40]:
> I remember discussing with the LinuxBIOS list a year or two ago, the 
> issue of what to do when chipsets drop having any serial ports.
> 
> We are currently working on mainboard designs that will not have any 
> serial ports with chipsets that don't have any serial ports. What did we 
> decide to do with LinuxBIOS, since the future is now?

What ports do they have? Any JTAG or similar?

Maybe its possible to hack up a "dumb serial over usb" driver that 
does not offer a protocol stack but simply pushes characters?


-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From stepan at coresystems.de  Mon Jul  3 10:35:49 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 3 Jul 2006 10:35:49 +0200
Subject: [LinuxBIOS] USB Support <WAS Re: Accessibility of LinuxBios>
In-Reply-To: <2ea3fae10607021831t1a0fc16r2b4010467d0e3a49@mail.gmail.com>
References: <20060702220652.GP4414@bouh.residence.ens-lyon.fr>
	<20060702231105.GB17504@coresystems.de>
	<20060702232622.GB4028@implementation>
	<20060702234148.GA19676@coresystems.de>
	<44A86780.9070601@onelabs.com>
	<2ea3fae10607021831t1a0fc16r2b4010467d0e3a49@mail.gmail.com>
Message-ID: <20060703083549.GC8445@coresystems.de>

* yhlu <yinghailu at gmail.com> [060703 03:31]:
> 2. use cpu cache for ohci or uhci buffer for packet.

Don't they circumvent the CPU to access the memory?

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From ebiederman at lnxi.com  Mon Jul  3 11:56:32 2006
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon, 03 Jul 2006 03:56:32 -0600
Subject: [LinuxBIOS] USB Support <WAS Re: Accessibility of LinuxBios>
In-Reply-To: <20060703083549.GC8445@coresystems.de> (Stefan Reinauer's
	message of "Mon, 3 Jul 2006 10:35:49 +0200")
References: <20060702220652.GP4414@bouh.residence.ens-lyon.fr>
	<20060702231105.GB17504@coresystems.de>
	<20060702232622.GB4028@implementation>
	<20060702234148.GA19676@coresystems.de> <44A86780.9070601@onelabs.com>
	<2ea3fae10607021831t1a0fc16r2b4010467d0e3a49@mail.gmail.com>
	<20060703083549.GC8445@coresystems.de>
Message-ID: <m34pxzc8q7.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at coresystems.de> writes:

> * yhlu <yinghailu at gmail.com> [060703 03:31]:
>> 2. use cpu cache for ohci or uhci buffer for packet.
>
> Don't they circumvent the CPU to access the memory?

Depends on the cpu.  As I recall Intel cpus flush data to memory
for all of their cache coherence, so I don't think it would work
there.  I think AMD is some better in this regard, but I would be
surprised if it worked.  It makes sense to research it though.

So if we have to use DMA it looks like we are out of luck until
after memory is initialized.  Ouch!.

So sending some really simply usb commands out the EHCI debug port
looks really interesting.  If that works it is also very interesting
for debugging kernels on modern hardware as well.

Eric



From marco at suse.de  Mon Jul  3 12:56:56 2006
From: marco at suse.de (Marco Skambraks)
Date: Mon, 3 Jul 2006 12:56:56 +0200 (CEST)
Subject: [LinuxBIOS] Accessibility of LinuxBios
In-Reply-To: <20060702231105.GB17504@coresystems.de>
References: <20060702220652.GP4414@bouh.residence.ens-lyon.fr>
	<20060702231105.GB17504@coresystems.de>
Message-ID: <Pine.LNX.4.61.0607031227330.437@skammel>

hi Stefan  und Samuel,

the problem with the braille support in bios is
that the modern PCs don't have a seriel-port maybe an on-board 
pin-connector

that's why more an more braille-display manufactories switch to 
usb-connection
so, we need usb-serial-converter support in bios
another problem is that the braille-display-protocoll is not a standard
each manufactory use their own protocoll
in some cases the protocoll is dependent on the model

and they also use different usb-serial-converters

the braille-driver is only one part
a second part is a very small and simple screenrading mechainism
to genrate a proper output

I think first it would be helpful to have bios access from the console 
with a small tool to adjust bios settings like
boot from CD or enable/disable hardware

maybe there is already a way to do this

best regards 

marco


On Mon, 3 Jul 2006, Stefan Reinauer wrote:

> * Samuel Thibault <samuel.thibault at ens-lyon.org> [060703 00:06]:
> > BIOSes is an area where accessibility is approximately non-existent.
> > Asking vendors to support hardware speech syntheses and braille devices
> > is quite dreamwork. I tried to convince accessibility people to release
> > basic drivers with BSD licenses so that vendors might integrate them,
> > but they just refused that, arguing that vendors will not make any
> > effort to integrate them, and there will always be bugs 
>  
> Maybe this code could be encapsulated, similar to how VGA
> bios or network boot is handled. On the other hand, this would cut off
> quite some of the bringup from "visibility"
> 
> > LinuxBios, however, can be a great opportunity to have an accessible
> > BIOS.
> > 
> > So what can be done? If I understood well, LinuxBios is a linux kernel
> > -based bios. Does that mean that it has the notion of process, or does
> > it run only in kernel mode? (which is sufficient for taking advantage of
> > linux drivers).
> 
> LinuxBIOS initializes the machine just far enough so that it can run a
> Linux kernel from flash memory, hence the name. This in-flash Linux can
> run normal userspace programs as well as load another kernel from a
> hard disk or any other supported medium. 
> 
> usually we can say: the main information exchange with LinuxBIOS (before
> the kernel is started) is not via VGA but via serial, which i believe is
> in theory usable with a braille terminal connected to another machine. 
> (Is this correct?)
> 
> The interaction part is all happening while Linux is loaded (ie. from flash)
> so we could use a local braille terminal at this point by using all the
> Linux utilities. 
> 
> One question is: how big is the Linux code to support one/some/many/all
> braille terminals and can we fit this in a 512kB/1MB flash part.
> The answer mostly depends on your needs.
> 
> Regards
> Stefan
> 
> -- 
> coresystems GmbH o Brahmsstr. 16 o D-79104 Freiburg i. Br.
>       Tel.: +49 761 7668825 o Fax: +49 761 7664613
> Email: info at coresystems.de  o http://www.coresystems.de/
> 

------------------------------------------------------------
Marco Skambraks, Product Manager           
SUSE LINUX Products GmbH,  Maxfeldstr. 5,  D-90409 Nuernberg
T:   +49 (0) 911 74053-0
Fax: +49 (0) 911 74053-483             marco.skambraks at suse.com
------------------------------------------------------------
** life is hard and then you die **



From rminnich at lanl.gov  Mon Jul  3 15:55:01 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 03 Jul 2006 07:55:01 -0600
Subject: [LinuxBIOS] LB Post codes
In-Reply-To: <20060701104723.GA14170@coresystems.de>
References: <1151714580.2679@actweb.info> <44A5DB20.4010708@lanl.gov>
	<20060701104723.GA14170@coresystems.de>
Message-ID: <44A921B5.50300@lanl.gov>

Stefan Reinauer wrote:

> Should we make a list of those in the wiki and try to get them
> straightened out in the different ports a bit? Or do we keep this
> as a pool of "implementor's freedom"?

we should try to straighten it out. I went through this a few years ago, 
and it was cleaned up for a bit, but new hardware broke it again ...

ron



From rminnich at lanl.gov  Mon Jul  3 16:02:50 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 03 Jul 2006 08:02:50 -0600
Subject: [LinuxBIOS] LB on PD10000
In-Reply-To: <1151783317.32574@actweb.info>
References: <1151783317.32574@actweb.info>
Message-ID: <44A9238A.7000804@lanl.gov>

bios at lists.actweb.info wrote:
> Ok, found a serial cable :)
> 
> Booting up the EPIA-PD1000 I get the following via serial terminal :-
> 
> 0
> 
> LinuxBIOS-1.1.8.0Fallback Sat Jul  1 01:02:23 BST 2006 starting...
>  Enabling mainboard devices
>  Enabling shadow ram
> vt8623 init starting

set the
option DEFAULT_CONSOLE_LOGLEVEL = 11
option MAXIMUM_CONSOLE_LOGLEVEL = 11

in your

/LinuxBIOSv2/targets/via/ep100d or whatever. It will get verbose.


this message is unrelated to video.

tanks

ron



From rminnich at lanl.gov  Mon Jul  3 16:06:31 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 03 Jul 2006 08:06:31 -0600
Subject: [LinuxBIOS] lb on pd10000
In-Reply-To: <1151799865.16270@actweb.info>
References: <1151799865.16270@actweb.info>
Message-ID: <44A92467.3080400@lanl.gov>

bios at lists.actweb.info wrote:
> Hi folks,
> 
> Ok, ive had a play around with the code for LB to see if i can find where its failing and have found the following :-
> 
> in file : src/northbridge/via/vt8623/raminit.c
> 
> I added a couple of line to show were in the file its crashing :-
> 
>         /* setup cpu */
>         pci_write_config8(north,0x50,0xc8);
>         pci_write_config8(north,0x51,0xde);
>         pci_write_config8(north,0x52,0xcf);
>         pci_write_config8(north,0x53,0x88);
>         pci_write_config8(north,0x55,0x04);
>         print_debug("vt8623 init step 2\r\n");

well, you are becoming a linuxbios hacker, I think :-)

>  b = smbus_read_byte(0xa0,17);

this is kinda weird. On a via chip the lockups always occur on the 
northbridge, not on spd ...

> Ok, after finding this line, i hunted for the source for smbus_read_byte which i belive is in :
> src/southbridge/via/vt8231/vt8231_early_smbus.c
> (am i corect in thinking this??????)

probably ... I think so.


look in the generated auto.inc in the build directory and you'll see 
where that function came from. This is the best I can do right now, 
worry. The ctags stuff does not extend to the romcc files.

> One last thing, am i correct in thinking that simply going into src/targets/via/epia-m/epia-m/ and running 'make clean', 'make'
> is enough to recompile all the routines (including the southbridge stuff)?

yes.

ron



From rminnich at lanl.gov  Mon Jul  3 16:07:30 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 03 Jul 2006 08:07:30 -0600
Subject: [LinuxBIOS] USB Support <WAS Re:  Accessibility of LinuxBios>
In-Reply-To: <44A86780.9070601@onelabs.com>
References: <20060702220652.GP4414@bouh.residence.ens-lyon.fr>	<20060702231105.GB17504@coresystems.de>	<20060702232622.GB4028@implementation>
	<20060702234148.GA19676@coresystems.de>
	<44A86780.9070601@onelabs.com>
Message-ID: <44A924A2.5030100@lanl.gov>

Bari Ari wrote:

> We are currently working on mainboard designs that will not have any 
> serial ports with chipsets that don't have any serial ports. What did we 
> decide to do with LinuxBIOS, since the future is now?

I would most rather do what we're doing on OLPC: linux in flash, since 
linux works well with usb.

ron



From stepan at coresystems.de  Mon Jul  3 16:44:26 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 3 Jul 2006 16:44:26 +0200
Subject: [LinuxBIOS] USB Support <WAS Re:  Accessibility of LinuxBios>
In-Reply-To: <44A924A2.5030100@lanl.gov>
References: <20060702220652.GP4414@bouh.residence.ens-lyon.fr>
	<20060702231105.GB17504@coresystems.de>
	<20060702232622.GB4028@implementation>
	<20060702234148.GA19676@coresystems.de>
	<44A86780.9070601@onelabs.com> <44A924A2.5030100@lanl.gov>
Message-ID: <20060703144426.GB25612@coresystems.de>

* Ronald G Minnich <rminnich at lanl.gov> [060703 16:07]:
> Bari Ari wrote:
> 
> >We are currently working on mainboard designs that will not have any 
> >serial ports with chipsets that don't have any serial ports. What did we 
> >decide to do with LinuxBIOS, since the future is now?
> 
> I would most rather do what we're doing on OLPC: linux in flash, since 
> linux works well with usb.

No doubt. 

But it does not solve the solution of the "how do we do ram
bringup without serial interface", so we need to think of something in
this area.

* HDT / JTAG 
* dumb buffer free usb serial support
* (bonkers) building a bios savior with a writeable and 
  remote readable part which allows us to have a "serial 
  console" with simple memory writes.

Stefan


-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From stepan at coresystems.de  Mon Jul  3 16:47:40 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 3 Jul 2006 16:47:40 +0200
Subject: [LinuxBIOS] lb on pd10000
In-Reply-To: <44A92467.3080400@lanl.gov>
References: <1151799865.16270@actweb.info> <44A92467.3080400@lanl.gov>
Message-ID: <20060703144740.GA25994@coresystems.de>

* Ronald G Minnich <rminnich at lanl.gov> [060703 16:06]:
> bios at lists.actweb.info wrote:
> > in file : src/northbridge/via/vt8623/raminit.c
> > 
> > I added a couple of line to show were in the file its crashing :-
> > 
> >         /* setup cpu */
> >         pci_write_config8(north,0x50,0xc8);
> >         pci_write_config8(north,0x51,0xde);
> >         pci_write_config8(north,0x52,0xcf);
> >         pci_write_config8(north,0x53,0x88);
> >         pci_write_config8(north,0x55,0x04);
> >         print_debug("vt8623 init step 2\r\n");
> 
> well, you are becoming a linuxbios hacker, I think :-)
> 
> >  b = smbus_read_byte(0xa0,17);
 
> this is kinda weird. On a via chip the lockups always occur on the 
> northbridge, not on spd ...
 
maybe it is a late or early hang. ie. the code is already some
instructions further but the machine hung before the serial buffer could
be emptied. 


-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From bios at lists.actweb.info  Mon Jul  3 17:32:30 2006
From: bios at lists.actweb.info (bios at lists.actweb.info)
Date: Mon,  3 Jul 2006 16:32:30 +0100 (BST)
Subject: [LinuxBIOS] lb on pd10000 {Scanned}
In-Reply-To: <20060703144740.GA25994@coresystems.de>
Message-ID: <1151940750.24950@actweb.info>

Stefan Reinauer wrote ..
> * Ronald G Minnich <rminnich at lanl.gov> [060703 16:06]:
> > bios at lists.actweb.info wrote:
> > > in file : src/northbridge/via/vt8623/raminit.c
> > > 
> > > I added a couple of line to show were in the file its crashing :-
> > > 
> > >         /* setup cpu */
> > >         pci_write_config8(north,0x50,0xc8);
> > >         pci_write_config8(north,0x51,0xde);
> > >         pci_write_config8(north,0x52,0xcf);
> > >         pci_write_config8(north,0x53,0x88);
> > >         pci_write_config8(north,0x55,0x04);
> > >         print_debug("vt8623 init step 2\r\n");
> > 
> > well, you are becoming a linuxbios hacker, I think :-)
> > 
> > >  b = smbus_read_byte(0xa0,17);
>  
> > this is kinda weird. On a via chip the lockups always occur on the 
> > northbridge, not on spd ...
>  
> maybe it is a late or early hang. ie. the code is already some
> instructions further but the machine hung before the serial buffer could
> be emptied. 
> 

Ok, sounds posible, is there a way to tell if this is happening?
is the 'print_debug_hex8' routine the one that chucks the post codes out? if so, is this buffered? e.g. rather than just sending to the serial console could i set calls to this routine up as well and output via the post card?, to allow pin pointing the problem?

ok, the other question is, could this have anything to do with the memory being 'DDR-400 CL3' x 512Mb? as i remember seeing a coment in one of the files about asuming there was 266 memory in the machine, and that the code dosnt allow for clocking down, does it allow for clocking up? jsut an idea?

Also what excatly does the smbus hold? is there a datasheet anyware that states what each register within it actually means? and if this is for one particular board, is it posible to read the data from linux while booted to the original bios, and then hard code the data, instead of trying to read it real-time? doing this may allow me to skip a couple of smbus calls and see if its something else causing the problem?


Thanks again for all your help

Matt



> 
> -- 
> coresystems GmbH ??? Brahmsstr. 16 ??? D-79104 Freiburg i. Br.
>       Tel.: +49 761 7668825 ??? Fax: +49 761 7664613
> Email: info at coresystems.de  ??? http://www.coresystems.de/
> 

From rminnich at lanl.gov  Mon Jul  3 18:00:12 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 03 Jul 2006 10:00:12 -0600
Subject: [LinuxBIOS] lb on pd10000 {Scanned}
In-Reply-To: <1151940750.24950@actweb.info>
References: <1151940750.24950@actweb.info>
Message-ID: <44A93F0C.80707@lanl.gov>

under factory bios, dump all the northbridge registers you are trying to 
set.

Then, try to get an idea of what you are trying to set them to under LB. 
I bet it's timing.

ron



From bari at onelabs.com  Mon Jul  3 18:04:31 2006
From: bari at onelabs.com (Bari Ari)
Date: Mon, 03 Jul 2006 11:04:31 -0500
Subject: [LinuxBIOS] USB Support <WAS Re:  Accessibility of LinuxBios>
In-Reply-To: <20060703083414.GB8445@coresystems.de>
References: <20060702220652.GP4414@bouh.residence.ens-lyon.fr>
	<20060702231105.GB17504@coresystems.de>
	<20060702232622.GB4028@implementation>
	<20060702234148.GA19676@coresystems.de>
	<44A86780.9070601@onelabs.com>
	<20060703083414.GB8445@coresystems.de>
Message-ID: <44A9400F.3030308@onelabs.com>

Stefan Reinauer wrote:
> * Bari Ari <bari at onelabs.com> [060703 02:40]:
>   
>> I remember discussing with the LinuxBIOS list a year or two ago, the 
>> issue of what to do when chipsets drop having any serial ports.
>>
>> We are currently working on mainboard designs that will not have any 
>> serial ports with chipsets that don't have any serial ports. What did we 
>> decide to do with LinuxBIOS, since the future is now?
>>     
>
> What ports do they have? Any JTAG or similar?
>   
JTAG/HDT, USB, and PCIe.

-Bari



From rminnich at lanl.gov  Mon Jul  3 18:02:29 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 03 Jul 2006 10:02:29 -0600
Subject: [LinuxBIOS] USB Support <WAS Re:  Accessibility of LinuxBios>
In-Reply-To: <20060703144426.GB25612@coresystems.de>
References: <20060702220652.GP4414@bouh.residence.ens-lyon.fr>
	<20060702231105.GB17504@coresystems.de>
	<20060702232622.GB4028@implementation>
	<20060702234148.GA19676@coresystems.de>
	<44A86780.9070601@onelabs.com> <44A924A2.5030100@lanl.gov>
	<20060703144426.GB25612@coresystems.de>
Message-ID: <44A93F95.7050707@lanl.gov>

Stefan Reinauer wrote:
> * Ronald G Minnich <rminnich at lanl.gov> [060703 16:07]:
> 
>>Bari Ari wrote:
>>
>>
>>>We are currently working on mainboard designs that will not have any 
>>>serial ports with chipsets that don't have any serial ports. What did we 
>>>decide to do with LinuxBIOS, since the future is now?
>>
>>I would most rather do what we're doing on OLPC: linux in flash, since 
>>linux works well with usb.
> 
> 
> No doubt. 
> 
> But it does not solve the solution of the "how do we do ram
> bringup without serial interface", so we need to think of something in
> this area.
> 
> * HDT / JTAG 

best.

> * dumb buffer free usb serial support

yes, but ... how hard is that? From what I have seen, hard, but I guess 
we have to do it.

The problem with usb serial is that so much has to work correctly before 
it will work at all. IIRC some of the dongles require you to download a 
program into them before the work. Once we lose serial, we lost the 
ability to put out diag info with a simple outb to a port. We have to 
partake of the USB train wreck to get anything out at all.

ron



From bios at lists.actweb.info  Mon Jul  3 18:44:46 2006
From: bios at lists.actweb.info (bios at lists.actweb.info)
Date: Mon,  3 Jul 2006 17:44:46 +0100 (BST)
Subject: [LinuxBIOS] lb on pd10000 {Scanned}
In-Reply-To: <44A93F0C.80707@lanl.gov>
Message-ID: <1151945086.29502@actweb.info>

Ok, now you have proved that im no good at this kinda stuff, can you point me in the direction of some information as to how to dump the northbridge registers, and what the registers mean?
Also is this north or a south problem, the the system apears to hang only after it enters the code from the south files?
Or could it be that the settings passed to the north before the crash are the cause?

Thanks

Matt
(sorry for being daft over this!!!!!)

Ronald G Minnich wrote ..
> under factory bios, dump all the northbridge registers you are trying to
> set.
???????????????????????????????????????????????????????????????????????????
LOL
> 
> Then, try to get an idea of what you are trying to set them to under LB.
> I bet it's timing.
> 
> ron
> 

From bari at onelabs.com  Mon Jul  3 19:47:05 2006
From: bari at onelabs.com (Bari Ari)
Date: Mon, 03 Jul 2006 12:47:05 -0500
Subject: [LinuxBIOS] USB Support <WAS Re:  Accessibility of LinuxBios>
In-Reply-To: <44A924A2.5030100@lanl.gov>
References: <20060702220652.GP4414@bouh.residence.ens-lyon.fr>	<20060702231105.GB17504@coresystems.de>	<20060702232622.GB4028@implementation>
	<20060702234148.GA19676@coresystems.de>
	<44A86780.9070601@onelabs.com> <44A924A2.5030100@lanl.gov>
Message-ID: <44A95819.7010408@onelabs.com>

Ronald G Minnich wrote:
> Bari Ari wrote:
>
>> We are currently working on mainboard designs that will not have any 
>> serial ports with chipsets that don't have any serial ports. What did 
>> we decide to do with LinuxBIOS, since the future is now?
>
> I would most rather do what we're doing on OLPC: linux in flash, since 
> linux works well with usb.
That is the plan, LinuxBIOS in Flash. And since we're all AMD based, RAM 
setup is easier.

While I was at Computex Taipei last month everyone at the Intel suite 
seemed baffled that Intel would turn down so much business in embedded 
by not supporting LinuxBIOS. Then again Intel has made a few bad turns 
the last few years.

-Bari



From bari at onelabs.com  Mon Jul  3 19:53:29 2006
From: bari at onelabs.com (Bari Ari)
Date: Mon, 03 Jul 2006 12:53:29 -0500
Subject: [LinuxBIOS] USB Support <WAS Re:  Accessibility of LinuxBios>
In-Reply-To: <44A924A2.5030100@lanl.gov>
References: <20060702220652.GP4414@bouh.residence.ens-lyon.fr>	<20060702231105.GB17504@coresystems.de>	<20060702232622.GB4028@implementation>
	<20060702234148.GA19676@coresystems.de>
	<44A86780.9070601@onelabs.com> <44A924A2.5030100@lanl.gov>
Message-ID: <44A95999.4020705@onelabs.com>

Ronald G Minnich wrote:
> Bari Ari wrote:
>
>> We are currently working on mainboard designs that will not have any 
>> serial ports with chipsets that don't have any serial ports. What did 
>> we decide to do with LinuxBIOS, since the future is now?
>
> I would most rather do what we're doing on OLPC: linux in flash, since 
> linux works well with usb.
Linux kernel in flash for real fast power-on to boot is the plan. 
"Instant on" for set-top-box and thin/media client applications. No 
legacy ports: serial, parallel, PATA, PS2.

-Bari



From rminnich at lanl.gov  Mon Jul  3 20:45:32 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 03 Jul 2006 12:45:32 -0600
Subject: [LinuxBIOS] lb on pd10000 {Scanned}
In-Reply-To: <1151945086.29502@actweb.info>
References: <1151945086.29502@actweb.info>
Message-ID: <44A965CC.5080208@lanl.gov>

bios at lists.actweb.info wrote:
> Ok, now you have proved that im no good at this kinda stuff, can you point me in the direction of some information as to how to dump the northbridge registers, and what the registers mean?

you're quite good at this kind of stuff. I suck at explaining things.

is you do this under linux:
lspci -xxx -s 0:0.0

you'll get a full north dump. Try to figure out how your code is setting 
registers vs. how they are set. Use the manual to decode the bits.


> Also is this north or a south problem, the the system apears to hang only after it enters the code from the south files?

I am almost certain it is a north problem. The via northbridges have 
proven to be tought to program, esp. since in some cases we put in 
nominally correct values and the chip locks up.


> Or could it be that the settings passed to the north before the crash are the cause?

could be.

thanks

ron



From rminnich at lanl.gov  Mon Jul  3 20:47:52 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 03 Jul 2006 12:47:52 -0600
Subject: [LinuxBIOS] USB Support <WAS Re:  Accessibility of LinuxBios>
In-Reply-To: <44A95819.7010408@onelabs.com>
References: <20060702220652.GP4414@bouh.residence.ens-lyon.fr>	<20060702231105.GB17504@coresystems.de>	<20060702232622.GB4028@implementation>
	<20060702234148.GA19676@coresystems.de>
	<44A86780.9070601@onelabs.com> <44A924A2.5030100@lanl.gov>
	<44A95819.7010408@onelabs.com>
Message-ID: <44A96658.6020101@lanl.gov>

Bari Ari wrote:

> While I was at Computex Taipei last month everyone at the Intel suite 
> seemed baffled that Intel would turn down so much business in embedded 
> by not supporting LinuxBIOS. Then again Intel has made a few bad turns 
> the last few years.

yes, it is very puzzling. I wish it could get fixed.

ron



From yinghailu at gmail.com  Mon Jul  3 21:22:19 2006
From: yinghailu at gmail.com (yhlu)
Date: Mon, 3 Jul 2006 12:22:19 -0700
Subject: [LinuxBIOS] USB Support <WAS Re: Accessibility of LinuxBios>
In-Reply-To: <44A924A2.5030100@lanl.gov>
References: <20060702220652.GP4414@bouh.residence.ens-lyon.fr>
	<20060702231105.GB17504@coresystems.de>
	<20060702232622.GB4028@implementation>
	<20060702234148.GA19676@coresystems.de> <44A86780.9070601@onelabs.com>
	<44A924A2.5030100@lanl.gov>
Message-ID: <2ea3fae10607031222h2e382886sc67292609bf8d967@mail.gmail.com>

so you will not get debug info on linuxbios stage. and some later stge
of Linux kernel you will get some out put even later than from vga
console.

YH

On 7/3/06, Ronald G Minnich <rminnich at lanl.gov> wrote:
> Bari Ari wrote:
>
> > We are currently working on mainboard designs that will not have any
> > serial ports with chipsets that don't have any serial ports. What did we
> > decide to do with LinuxBIOS, since the future is now?
>
> I would most rather do what we're doing on OLPC: linux in flash, since
> linux works well with usb.
>
> ron
>
> --
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>



From bari at onelabs.com  Mon Jul  3 22:30:34 2006
From: bari at onelabs.com (Bari Ari)
Date: Mon, 03 Jul 2006 15:30:34 -0500
Subject: [LinuxBIOS] OLPC Developers
Message-ID: <44A97E6A.3090302@onelabs.com>

We just got two developer OLPC mainboards in. Who else is here working 
on LinuxBIOS for OLPC besides Ollie and Ron?

We are willing to help on testing/developing BIOS, but will probably do 
most of our work on mesh networking and codec's.

-Bari



From rminnich at lanl.gov  Mon Jul  3 22:45:33 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 03 Jul 2006 14:45:33 -0600
Subject: [LinuxBIOS] USB Support <WAS Re: Accessibility of LinuxBios>
In-Reply-To: <2ea3fae10607031222h2e382886sc67292609bf8d967@mail.gmail.com>
References: <20060702220652.GP4414@bouh.residence.ens-lyon.fr>	
	<20060702231105.GB17504@coresystems.de>	
	<20060702232622.GB4028@implementation>	
	<20060702234148.GA19676@coresystems.de>
	<44A86780.9070601@onelabs.com>	 <44A924A2.5030100@lanl.gov>
	<2ea3fae10607031222h2e382886sc67292609bf8d967@mail.gmail.com>
Message-ID: <44A981ED.6000400@lanl.gov>

yhlu wrote:
> so you will not get debug info on linuxbios stage. and some later stge
> of Linux kernel you will get some out put even later than from vga
> console.

yes, but ... that's how it goes. Very few people want to see linuxbios 
anyway.

Many years ago I did an experiment, and was able to set things up so 
that linuxbios log buffer was picked up by the kernel, so you could do a 
dmesg and see linuxbios messages. I think this might be useful to revive.

I just don't see us putting a fully capable usb stack into linuxbios, it 
will not work as well as the linux usb stack.

ron



From rminnich at lanl.gov  Mon Jul  3 22:46:40 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 03 Jul 2006 14:46:40 -0600
Subject: [LinuxBIOS] OLPC Developers
In-Reply-To: <44A97E6A.3090302@onelabs.com>
References: <44A97E6A.3090302@onelabs.com>
Message-ID: <44A98230.4070808@lanl.gov>

Bari Ari wrote:
> We just got two developer OLPC mainboards in. Who else is here working 
> on LinuxBIOS for OLPC besides Ollie and Ron?

Richard Smith is.

I will post my lb instructions to this list.

ron



From arturo.mann at gmail.com  Tue Jul  4 01:54:37 2006
From: arturo.mann at gmail.com (Arturo Mann)
Date: Mon, 3 Jul 2006 18:54:37 -0500
Subject: [LinuxBIOS] Tyan S2892
Message-ID: <601d22e40607031654u7dbf119i8eec3aac54fae088@mail.gmail.com>

Hallo there,
I used my Pentium4 to build a LinuxBIOS image based on the jun30th snapshot,
using FILO to boot directly into GRUB.
Now, my problem is, that the Tyan is currently bricked, and yes, even a
replacement bios from BIOSMAN did not do the trick
I do not want to send the Mainboard into warranty just yet.
I have my linuxbios.rom, and a brand new, shiny SST49LF080A chip to put the
image into.
However, since the Tyan is bricked, I cannot program with it's own flashing
mechanism using the flashrom utility included in LinuxBios.
I currently have a nice little Abit KV85 mainboard, which, in combination
with uniflash and DOS is supported, however, uniflash
cannot write the LinuxBIOS ELF image, and flashrom does not like this
mainboard. Please advise on how to continue,
ps. I have access to a TopMAX universal programmer.
Thanks,

-- 
------------------------
---- Stop the DRM! www.defectivebydesign.org ----

---- Stop the TCPA from taking away OUR freedom! www.againsttcpa.com/  -----
---- Arturo Mann, arturo.mann at gmail.com ----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060703/e985d85d/attachment.html>

From stuge-linuxbios at cdy.org  Tue Jul  4 02:34:52 2006
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Tue, 4 Jul 2006 02:34:52 +0200
Subject: [LinuxBIOS] Tyan S2892
In-Reply-To: <601d22e40607031654u7dbf119i8eec3aac54fae088@mail.gmail.com>
References: <601d22e40607031654u7dbf119i8eec3aac54fae088@mail.gmail.com>
Message-ID: <20060704003452.6098.qmail@cdy.org>

On Mon, Jul 03, 2006 at 06:54:37PM -0500, Arturo Mann wrote:
> ps. I have access to a TopMAX universal programmer.

Big PS there. :)

TopMAX lists support for "Flash EPROM  256 Kbit to 32 Mbit 28Fxxx,
29Fxxx, 29Cxxx, 29BVxxx, 29LVxxx, 29Wxxx,  49Fxxx series(2.7, 3.3,
5.0, or 12 Volt)" so your LF may also be supported.

If you have a PLCC adapter for the programmer and the TopMAX software
running on another system you're all set. If not, I guess your
options are to build a DIP->PLCC adapter yourself or make flashrom
work on your Abit board. The former is easy enough if TopMAX are
communicative, the latter may be easy if Abit haven't done any tricks
when connecting the flash chip to the chipset. (Some board makers
connect the flash write signals to random GPIO pins and don't tell
anyone which..)


//Peter



From arturo.mann at gmail.com  Tue Jul  4 03:08:31 2006
From: arturo.mann at gmail.com (Arturo Mann)
Date: Mon, 3 Jul 2006 20:08:31 -0500
Subject: [LinuxBIOS] Tyan S2892
In-Reply-To: <20060704003452.6098.qmail@cdy.org>
References: <601d22e40607031654u7dbf119i8eec3aac54fae088@mail.gmail.com>
	<20060704003452.6098.qmail@cdy.org>
Message-ID: <601d22e40607031808o5b6df5fbv7614ae322ad8304e@mail.gmail.com>

Yeah, I agree on the PS. :)
I have access to the topMAX with another box, yes. <evil grin> :)
However, do I need to take as a "bad sign" that UniFlash cannot
verify the programmed LinuxBIOS ELF? Or is it just a sign that
UniFlash cannot handle that sort of program?
Oh, btw, the ABIT is PLCC it just seems to be unable to program with
uniflash
(or past 512KiB With the standard 1024KiB Tyan Flash)


On 7/3/06, Peter Stuge <stuge-linuxbios at cdy.org> wrote:
>
> On Mon, Jul 03, 2006 at 06:54:37PM -0500, Arturo Mann wrote:
> > ps. I have access to a TopMAX universal programmer.
>
> Big PS there. :)
>
> TopMAX lists support for "Flash EPROM  256 Kbit to 32 Mbit 28Fxxx,
> 29Fxxx, 29Cxxx, 29BVxxx, 29LVxxx, 29Wxxx,  49Fxxx series(2.7, 3.3,
> 5.0, or 12 Volt)" so your LF may also be supported.
>
> If you have a PLCC adapter for the programmer and the TopMAX software
> running on another system you're all set. If not, I guess your
> options are to build a DIP->PLCC adapter yourself or make flashrom
> work on your Abit board. The former is easy enough if TopMAX are
> communicative, the latter may be easy if Abit haven't done any tricks
> when connecting the flash chip to the chipset. (Some board makers
> connect the flash write signals to random GPIO pins and don't tell
> anyone which..)
>
>
> //Peter
>
> --
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>



-- 
------------------------
---- Stop the DRM! www.defectivebydesign.org ----

---- Stop the TCPA from taking away OUR freedom! www.againsttcpa.com/  -----
---- Arturo Mann, arturo.mann at gmail.com ----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060703/f5580f4f/attachment.html>

From stuge-linuxbios at cdy.org  Tue Jul  4 05:03:54 2006
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Tue, 4 Jul 2006 05:03:54 +0200
Subject: [LinuxBIOS] Tyan S2892
In-Reply-To: <601d22e40607031808o5b6df5fbv7614ae322ad8304e@mail.gmail.com>
References: <601d22e40607031654u7dbf119i8eec3aac54fae088@mail.gmail.com>
	<20060704003452.6098.qmail@cdy.org>
	<601d22e40607031808o5b6df5fbv7614ae322ad8304e@mail.gmail.com>
Message-ID: <20060704030354.7817.qmail@cdy.org>

On Mon, Jul 03, 2006 at 08:08:31PM -0500, Arturo Mann wrote:
> Yeah, I agree on the PS. :)
> I have access to the topMAX with another box, yes. <evil grin> :)

And also a DIP->PLCC adapter so you can use it for the SST part?
If you have one or can make one this is your best bet. I'd recommend
using the standalone programmer if at all possible.


> However, do I need to take as a "bad sign" that UniFlash cannot
> verify the programmed LinuxBIOS ELF? Or is it just a sign that
> UniFlash cannot handle that sort of program?
> Oh, btw, the ABIT is PLCC it just seems to be unable to program with
> uniflash
> (or past 512KiB With the standard 1024KiB Tyan Flash)

I'm not an expert on uniflash but it could have limits on flash size
or require some particular checksumming algorithm to be used on the
binary file and have a checksum in a special byte offset to consider
the flash image valid, or maybe it checks this checksum on write
verification so verify fails unless the checksum is correct, etc.
Note that this is only speculation and wild guesses.

If uniflash or the Abit board is limited to 512KiB ROMs verification
will (should) always fail - so maybe this is a matter of the chipset
not decoding more than 512KiB to the LPC bus. This feels more likely
than crazy, damaged code in uniflash.


//Peter



From arturo.mann at gmail.com  Tue Jul  4 05:28:21 2006
From: arturo.mann at gmail.com (Arturo Mann)
Date: Mon, 3 Jul 2006 22:28:21 -0500
Subject: [LinuxBIOS] Tyan S2892
In-Reply-To: <20060704030354.7817.qmail@cdy.org>
References: <601d22e40607031654u7dbf119i8eec3aac54fae088@mail.gmail.com>
	<20060704003452.6098.qmail@cdy.org>
	<601d22e40607031808o5b6df5fbv7614ae322ad8304e@mail.gmail.com>
	<20060704030354.7817.qmail@cdy.org>
Message-ID: <601d22e40607032028p289a2750hbe3ed682d2e9da76@mail.gmail.com>

The problem is not quite the actual ABIT motherboard, remember,
both the ABIT and Tyan use PLCC chips.
The problem is that I think Uniflash is not quite meant to flash LinuxBios
or ELF files,
and it writes it, but every sector comes out as "BAD" in validation, and
well, yeah, push comes to shove,
the motherboard does not boot either with that program.
I will flash with the topMAX and see if the program is good for the
Mainboard, unless you lot can tell me
about some sort of checksumming routine to make sure the linuxBios flash is
actually a valid chunk of flash?
BTW, is there anyone who has a VGA Bios for an ATi Rage 8mb XL (like on the
Tyan), since my original bios is f****ed
i can't get it out of there. :(


On 7/3/06, Peter Stuge <stuge-linuxbios at cdy.org> wrote:
>
> On Mon, Jul 03, 2006 at 08:08:31PM -0500, Arturo Mann wrote:
> > Yeah, I agree on the PS. :)
> > I have access to the topMAX with another box, yes. <evil grin> :)
>
> And also a DIP->PLCC adapter so you can use it for the SST part?
> If you have one or can make one this is your best bet. I'd recommend
> using the standalone programmer if at all possible.
>
>
> > However, do I need to take as a "bad sign" that UniFlash cannot
> > verify the programmed LinuxBIOS ELF? Or is it just a sign that
> > UniFlash cannot handle that sort of program?
> > Oh, btw, the ABIT is PLCC it just seems to be unable to program with
> > uniflash
> > (or past 512KiB With the standard 1024KiB Tyan Flash)
>
> I'm not an expert on uniflash but it could have limits on flash size
> or require some particular checksumming algorithm to be used on the
> binary file and have a checksum in a special byte offset to consider
> the flash image valid, or maybe it checks this checksum on write
> verification so verify fails unless the checksum is correct, etc.
> Note that this is only speculation and wild guesses.
>
> If uniflash or the Abit board is limited to 512KiB ROMs verification
> will (should) always fail - so maybe this is a matter of the chipset
> not decoding more than 512KiB to the LPC bus. This feels more likely
> than crazy, damaged code in uniflash.
>
>
> //Peter
>
> --
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>



-- 
------------------------
---- Stop the DRM! www.defectivebydesign.org ----

---- Stop the TCPA from taking away OUR freedom! www.againsttcpa.com/  -----
---- Arturo Mann, arturo.mann at gmail.com ----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060703/81457188/attachment.html>

From samuel.thibault at ens-lyon.org  Tue Jul  4 09:57:22 2006
From: samuel.thibault at ens-lyon.org (Samuel Thibault)
Date: Tue, 4 Jul 2006 09:57:22 +0200
Subject: [LinuxBIOS] Accessibility of LinuxBios
In-Reply-To: <Pine.LNX.4.61.0607031227330.437@skammel>
References: <20060702220652.GP4414@bouh.residence.ens-lyon.fr>
	<20060702231105.GB17504@coresystems.de>
	<Pine.LNX.4.61.0607031227330.437@skammel>
Message-ID: <20060704075722.GA4323@implementation.homeland.net>

Marco Skambraks, le Mon 03 Jul 2006 12:56:56 +0200, a ?crit :
> another problem is that the braille-display-protocoll is not a standard
> each manufactory use their own protocoll
> in some cases the protocoll is dependent on the model
> 
> and they also use different usb-serial-converters
> 
> the braille-driver is only one part
> a second part is a very small and simple screenrading mechainism
> to genrate a proper output

Indeed, but LinuxBIOS is a way to boot a linux kernel right from the
mainboard, so you can then run usual screen readers (brltty/suseb/...).

> I think first it would be helpful to have bios access from the console 
> with a small tool to adjust bios settings like
> boot from CD or enable/disable hardware
> 
> maybe there is already a way to do this

This is another interesting approach indeed, which might interest many
more people.

Samuel



From smithbone at gmail.com  Wed Jul  5 16:58:04 2006
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 5 Jul 2006 09:58:04 -0500
Subject: [LinuxBIOS] OLPC Developers
In-Reply-To: <44A98230.4070808@lanl.gov>
References: <44A97E6A.3090302@onelabs.com> <44A98230.4070808@lanl.gov>
Message-ID: <8a0c36780607050758s2740fe0bwdb9e9c3d40f541c0@mail.gmail.com>

On 7/3/06, Ronald G Minnich <rminnich at lanl.gov> wrote:

> Bari Ari wrote:
> > We just got two developer OLPC mainboards in. Who else is here working
> > on LinuxBIOS for OLPC besides Ollie and Ron?
>
> Richard Smith is.
>
> I will post my lb instructions to this list.

I've received mine today.  I plan to work on getting the linux JTAG
tools to work with the serial flash.


-- 
Richard A. Smith



From rminnich at lanl.gov  Wed Jul  5 17:06:31 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 05 Jul 2006 09:06:31 -0600
Subject: [LinuxBIOS] Accessibility of LinuxBios
In-Reply-To: <20060704075722.GA4323@implementation.homeland.net>
References: <20060702220652.GP4414@bouh.residence.ens-lyon.fr>	<20060702231105.GB17504@coresystems.de>	<Pine.LNX.4.61.0607031227330.437@skammel>
	<20060704075722.GA4323@implementation.homeland.net>
Message-ID: <44ABD577.8000208@lanl.gov>

Samuel Thibault wrote:

>>I think first it would be helpful to have bios access from the console 
>>with a small tool to adjust bios settings like
>>boot from CD or enable/disable hardware
>>
>>maybe there is already a way to do this
> 
> 
> This is another interesting approach indeed, which might interest many
> more people.
> 
> Samuel
> 


I think the right way to do this, as always, is to make linux the thing 
you interface with at power-on or reset, and you load Linux from FLASH 
from. Most BIOSes are bad OS designs -- for the latest bad design, read 
the EFI manual, and reflect on the fact that it does far less than Unix 
V6 did 30 years ago, and somehow manages to do a lot less in 1400 pages 
of documentation. But with Linux as the BIOS, you've got a good OS as 
your bios, and you can do all kinds of neat things.

ron



From rus.cahimb at gmail.com  Wed Jul  5 20:21:13 2006
From: rus.cahimb at gmail.com (rum vodka)
Date: Wed, 5 Jul 2006 23:51:13 +0530
Subject: [LinuxBIOS] LinuxBIOS Support for motherboard from GIGABYTE
Message-ID: <cdc8c4430607051121l2a8395fcuaedd10d73093a0ef@mail.gmail.com>

Hi Everyone,

Just stumbled upon www.linuxbios.org while "digg"ing for news.
I would like to know if there is LinuxBIOS support for the following config:

CPU : AMD Athlon 6400
MOTHERBOARD : GA-K8N51GMF-9 from GIGABYTE
I/O Control : Winbond W83627

Chipset :

NorthBridge : nVIDIA GeForce 6100
SouthBridge : nVIDIA nForce 430

output of lspci -vvv follows :
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

00:00.0 RAM memory: nVidia Corporation C51 Host Bridge (rev a2)
        Subsystem: Giga-byte Technology Unknown device 5000
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Capabilities: [44] HyperTransport: Slave or Primary Interface
                Command: BaseUnitID=0 UnitCnt=15 MastHost- DefDir- DUL-
                Link Control 0: CFlE+ CST- CFE- <LkFail- Init+ EOC- TXO-
<CRCErr=0 IsocEn- LSEn+ ExtCTL- 64b-
                Link Config 0: MLWI=16bit DwFcIn- MLWO=16bit DwFcOut-
LWI=16bit DwFcInEn- LWO=16bit DwFcOutEn-
                Link Control 1: CFlE+ CST- CFE- <LkFail- Init+ EOC- TXO-
<CRCErr=0 IsocEn+ LSEn+ ExtCTL- 64b-
                Link Config 1: MLWI=16bit DwFcIn- MLWO=16bit DwFcOut-
LWI=8bit DwFcInEn- LWO=8bit DwFcOutEn-
                Revision ID: 1.03
                Link Frequency 0: 1.0GHz
                Link Error 0: <Prot- <Ovfl- <EOC- CTLTm-
                Link Frequency Capability 0: 200MHz+ 300MHz+ 400MHz+ 500MHz+
600MHz+ 800MHz+ 1.0GHz+ 1.2GHz- 1.4GHz- 1.6GHz- Vend-
                Feature Capability: IsocFC+ LDTSTOP+ CRCTM- ECTLT- 64bA-
UIDRD-
                Link Frequency 1: 800MHz
                Link Error 1: <Prot- <Ovfl- <EOC- CTLTm-
                Link Frequency Capability 1: 200MHz+ 300MHz+ 400MHz+ 500MHz+
600MHz+ 800MHz+ 1.0GHz+ 1.2GHz- 1.4GHz- 1.6GHz- Vend-
                Error Handling: PFlE+ OFlE+ PFE- OFE- EOCFE- RFE- CRCFE-
SERRFE- CF- RE- PNFE- ONFE- EOCNFE- RNFE- CRCNFE- SERRNFE-
                Prefetchable memory behind bridge Upper: 00-00
                Bus Number: 00
        Capabilities: [e0] HyperTransport: MSI Mapping

00:00.1 RAM memory: nVidia Corporation C51 Memory Controller 0 (rev a2)
        Subsystem: Giga-byte Technology Unknown device 5000
        Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
        Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR+ <PERR-

00:00.2 RAM memory: nVidia Corporation C51 Memory Controller 1 (rev a2)
        Subsystem: Giga-byte Technology Unknown device 5000
        Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-

00:00.3 RAM memory: nVidia Corporation C51 Memory Controller 5 (rev a2)
        Subsystem: Giga-byte Technology Unknown device 5000
        Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-

00:00.4 RAM memory: nVidia Corporation C51 Memory Controller 4 (rev a2)
        Subsystem: Giga-byte Technology Unknown device 5000
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0

00:00.5 RAM memory: nVidia Corporation C51 Host Bridge (rev a2)
        Subsystem: Giga-byte Technology Unknown device 5000
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Capabilities: [44] #00 [00fe]
        Capabilities: [fc] #00 [0000]

00:00.6 RAM memory: nVidia Corporation C51 Memory Controller 3 (rev a2)
        Subsystem: Giga-byte Technology Unknown device 5000
        Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
        Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-

00:00.7 RAM memory: nVidia Corporation C51 Memory Controller 2 (rev a2)
        Subsystem: Giga-byte Technology Unknown device 5000
        Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-

00:05.0 VGA compatible controller: nVidia Corporation C51 PCI Express Bridge
(rev a2) (prog-if 00 [VGA])
        Subsystem: Giga-byte Technology Unknown device d000
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin A routed to IRQ 11
        Region 0: Memory at f2000000 (32-bit, non-prefetchable) [size=16M]
        Region 1: Memory at e0000000 (64-bit, prefetchable) [size=256M]
        Region 3: Memory at f3000000 (64-bit, non-prefetchable) [size=16M]
        [virtual] Expansion ROM at 30000000 [disabled] [size=128K]
        Capabilities: [48] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [50] Message Signalled Interrupts: 64bit+ Queue=0/0
Enable-
                Address: 0000000000000000  Data: 0000

00:09.0 RAM memory: nVidia Corporation MCP51 Host Bridge (rev a2)
        Subsystem: Giga-byte Technology Unknown device 5001
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Capabilities: [44] HyperTransport: Slave or Primary Interface
                Command: BaseUnitID=9 UnitCnt=15 MastHost- DefDir- DUL-
                Link Control 0: CFlE+ CST- CFE- <LkFail- Init+ EOC- TXO-
<CRCErr=0 IsocEn+ LSEn+ ExtCTL- 64b-
                Link Config 0: MLWI=8bit DwFcIn- MLWO=8bit DwFcOut- LWI=8bit
DwFcInEn- LWO=8bit DwFcOutEn-
                Link Control 1: CFlE- CST- CFE- <LkFail+ Init- EOC+ TXO+
<CRCErr=0 IsocEn- LSEn- ExtCTL- 64b-
                Link Config 1: MLWI=8bit DwFcIn- MLWO=8bit DwFcOut- LWI=8bit
DwFcInEn- LWO=8bit DwFcOutEn-
                Revision ID: 1.03
                Link Frequency 0: 800MHz
                Link Error 0: <Prot- <Ovfl- <EOC- CTLTm-
                Link Frequency Capability 0: 200MHz+ 300MHz+ 400MHz+ 500MHz+
600MHz+ 800MHz+ 1.0GHz+ 1.2GHz- 1.4GHz- 1.6GHz- Vend-
                Feature Capability: IsocFC+ LDTSTOP+ CRCTM- ECTLT- 64bA-
UIDRD-
                Link Frequency 1: 200MHz
                Link Error 1: <Prot- <Ovfl- <EOC- CTLTm-
                Link Frequency Capability 1: 200MHz- 300MHz- 400MHz- 500MHz-
600MHz- 800MHz- 1.0GHz- 1.2GHz- 1.4GHz- 1.6GHz- Vend-
                Error Handling: PFlE+ OFlE+ PFE- OFE- EOCFE- RFE- CRCFE-
SERRFE- CF- RE- PNFE- ONFE- EOCNFE- RNFE- CRCNFE- SERRNFE-
                Prefetchable memory behind bridge Upper: 00-00
                Bus Number: 00
        Capabilities: [e0] HyperTransport: MSI Mapping

00:0a.0 ISA bridge: nVidia Corporation MCP51 LPC Bridge (rev a2)
        Subsystem: Giga-byte Technology Unknown device 5001
        Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0

00:0a.1 SMBus: nVidia Corporation MCP51 SMBus (rev a2)
        Subsystem: Giga-byte Technology Unknown device 0264
        Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Interrupt: pin A routed to IRQ 5
        Region 4: I/O ports at 1c00 [size=64]
        Region 5: I/O ports at 1c80 [size=64]
        Capabilities: [44] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:0a.2 RAM memory: nVidia Corporation MCP51 Memory Controller 0 (rev a2)
        Subsystem: Giga-byte Technology Unknown device 0264
        Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-

00:0b.0 USB Controller: nVidia Corporation MCP51 USB Controller (rev a2)
(prog-if 10 [OHCI])
        Subsystem: Giga-byte Technology Unknown device 5004
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0 (750ns min, 250ns max)
        Interrupt: pin A routed to IRQ 16
        Region 0: Memory at f5108000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: [44] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:0b.1 USB Controller: nVidia Corporation MCP51 USB Controller (rev a2)
(prog-if 20 [EHCI])
        Subsystem: Giga-byte Technology Unknown device 5004
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0 (750ns min, 250ns max)
        Interrupt: pin B routed to IRQ 17
        Region 0: Memory at f5104000 (32-bit, non-prefetchable) [size=256]
        Capabilities: [44] Debug port
        Capabilities: [80] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:0d.0 IDE interface: nVidia Corporation MCP51 IDE (rev a1) (prog-if 8a
[Master SecP PriP])
        Subsystem: Giga-byte Technology Unknown device b000
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0 (750ns min, 250ns max)
        Region 4: I/O ports at f000 [size=16]
        Capabilities: [44] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:0e.0 IDE interface: nVidia Corporation MCP51 Serial ATA Controller (rev
a1) (prog-if 85 [Master SecO PriO])
        Subsystem: Giga-byte Technology Unknown device b002
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0 (750ns min, 250ns max)
        Interrupt: pin A routed to IRQ 16
        Region 0: I/O ports at 09f0 [size=8]
        Region 1: I/O ports at 0bf0 [size=4]
        Region 2: I/O ports at 0970 [size=8]
        Region 3: I/O ports at 0b70 [size=4]
        Region 4: I/O ports at d800 [size=16]
        Region 5: Memory at f5107000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: [44] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [b0] Message Signalled Interrupts: 64bit+ Queue=0/2
Enable-
                Address: 0000000000000000  Data: 0000
        Capabilities: [cc] HyperTransport: MSI Mapping

00:0f.0 IDE interface: nVidia Corporation MCP51 Serial ATA Controller (rev
a1) (prog-if 85 [Master SecO PriO])
        Subsystem: Giga-byte Technology Unknown device b002
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0 (750ns min, 250ns max)
        Interrupt: pin A routed to IRQ 17
        Region 0: I/O ports at 09e0 [size=8]
        Region 1: I/O ports at 0be0 [size=4]
        Region 2: I/O ports at 0960 [size=8]
        Region 3: I/O ports at 0b60 [size=4]
        Region 4: I/O ports at c400 [size=16]
        Region 5: Memory at f5106000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: [44] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [b0] Message Signalled Interrupts: 64bit+ Queue=0/2
Enable-
                Address: 0000000000000000  Data: 0000
        Capabilities: [cc] HyperTransport: MSI Mapping

00:10.0 PCI bridge: nVidia Corporation MCP51 PCI Bridge (rev a2) (prog-if 01
[Subtractive decode])
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=32
        I/O behind bridge: 0000a000-0000afff
        Memory behind bridge: f5000000-f50fffff
        Prefetchable memory behind bridge: fff00000-000fffff
        Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- <SERR- <PERR-
        BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B-
        Capabilities: [b8] #0d [0000]
        Capabilities: [8c] HyperTransport: MSI Mapping

00:10.1 Audio device: nVidia Corporation MCP51 High Definition Audio (rev
a2)
        Subsystem: Giga-byte Technology Unknown device a102
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0 (500ns min, 1250ns max)
        Interrupt: pin B routed to IRQ 19
        Region 0: Memory at f5100000 (32-bit, non-prefetchable) [size=16K]
        Capabilities: [44] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [50] Message Signalled Interrupts: 64bit+ Queue=0/0
Enable-
                Address: 0000000000000000  Data: 0000
        Capabilities: [6c] HyperTransport: MSI Mapping

00:14.0 Bridge: nVidia Corporation MCP51 Ethernet Controller (rev a1)
        Subsystem: Giga-byte Technology Unknown device e000
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0 (250ns min, 5000ns max)
        Interrupt: pin A routed to IRQ 18
        Region 0: Memory at f5105000 (32-bit, non-prefetchable) [size=4K]
        Region 1: I/O ports at b000 [size=8]
        Capabilities: [44] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable+ DSel=0 DScale=0 PME-

00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
HyperTransport Technology Configuration
        Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Capabilities: [80] HyperTransport: Host or Secondary Interface
                !!! Possibly incomplete decoding
                Command: WarmRst+ DblEnd-
                Link Control: CFlE- CST- CFE- <LkFail- Init+ EOC- TXO-
<CRCErr=0
                Link Config: MLWI=16bit MLWO=16bit LWI=16bit LWO=16bit
                Revision ID: 1.02

00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
Address Map
        Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-

00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM
Controller
        Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-

00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
Miscellaneous Control
        Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-

01:0e.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host
Controller (rev 80) (prog-if 10 [OHCI])
        Subsystem: Giga-byte Technology GA-7VT600-1394 Motherboard
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping+ SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 32 (8000ns max), Cache Line Size 08
        Interrupt: pin A routed to IRQ 20
        Region 0: Memory at f5000000 (32-bit, non-prefetchable) [size=2K]
        Region 1: I/O ports at a000 [size=128]
        Capabilities: [50] Power Management version 2
                Flags: PMEClk- DSI- D1- D2+ AuxCurrent=0mA
PME(D0-,D1-,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

--
regards
Ram
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060705/d0092d10/attachment.html>

From ward at gnu.org  Thu Jul  6 03:28:25 2006
From: ward at gnu.org (Ward Vandewege)
Date: Wed, 5 Jul 2006 21:28:25 -0400
Subject: [LinuxBIOS] some more tyan/s2881 questions
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203094BD5@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094BD5@ssvlexmb2.amd.com>
Message-ID: <20060706012825.GA23856@localdomain>

Hi YH,

Have you made any progress on this? Not being able to control the fans is the
last thing that is stopping us from deploying LinuxBIOS. I'm worried that the
fans will wear out because they come on at full speed after boot, and I can't
control them under LinuxBIOS (except if I boot the proprietary BIOS once, and
then don't unplug the power to the machine before booting in LinuxBIOS).

Any help would be _greatly_ appreciated...

Thanks,
Ward.

On Thu, Apr 20, 2006 at 04:59:52PM -0700, Lu, Yinghai wrote:
> I have inited the hw sensors in LinuxBIOS for s2881. So you could use
> lmsensor to check the FAN speed. The config file is on Tyan web.
> 
> For the Fan control, there should more some reg setting...to reduce the
> FAN speed winbond and adm1027...
> 
> YH
> 
> 
> 
> 
> !DSPAM:444820c0151711016910990!
> 
-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator



From Sergio.Garcia at ydilo.com  Thu Jul  6 14:51:35 2006
From: Sergio.Garcia at ydilo.com (=?iso-8859-1?Q?Sergio_Garc=EDa_Murillo?=)
Date: Thu, 6 Jul 2006 14:51:35 +0200
Subject: [LinuxBIOS] Booting from a ethernet over ata device
Message-ID: <352C352C4F01744CA872F922FD797A0F01B06C@ydlmail01.people-com.com>

Hi all

I have just discovered the project and I was wondering if it could support the ethernet over ata protocol so it could boot up from a net drive.
AFAIK it would require a 2.6 kernel which I don't know if there are plans to support it soon. 
But I think it could bring some new interesting possibilities.

Greetings and great job

---------------------------------------------------------------- 
Sergio Garc?a Murillo
Research & Development
.y dilo 
    Advanced Voice Solutions

--------------------------------------------------------------------------------------
This message and any files transmitted with it are confidential and intended solely 
for the use of the individual or entity to whom they are addressed. No confidentiality 
or privilege is waived or lost by any wrong transmission. 
If you have received this message in error, please immediately destroy it and kindly 
notify the sender by reply email.
You must not, directly or indirectly, use, disclose, distribute, print, or copy any 
part of this message if you are not the intended recipient. Opinions, conclusions and 
other information in this message that do not relate to the official business of 
Ydilo Advanced Voice Solutions, S.A. shall be understood as neither given nor endorsed by it. 
--------------------------------------------------------------------------------------



From jrydberg at gnu.org  Thu Jul  6 11:59:39 2006
From: jrydberg at gnu.org (Johan Rydberg)
Date: Thu, 06 Jul 2006 11:59:39 +0200
Subject: [LinuxBIOS] FYI: Free UEFI implementation not possible?
Message-ID: <87odw3njec.fsf@night.trouble.net>


I asked the FSF copyright clerks about the possibility for FSF to
become an adopting member of UEFI.  This does not seem to be the case,
though.  Which more or less rules out a free UEFI implementation.

-------------- next part --------------
An embedded message was scrubbed...
From: "Jonas Jacobson via RT" <copyright-clerk at fsf.org>
Subject: [gnu.org #294922] Legal status of UEFI? 
Date: Wed, 05 Jul 2006 15:53:00 -0400
Size: 2706
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060706/970f879d/attachment.mht>

From rminnich at lanl.gov  Thu Jul  6 15:44:09 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Thu, 06 Jul 2006 07:44:09 -0600
Subject: [LinuxBIOS] Booting from a ethernet over ata device
In-Reply-To: <352C352C4F01744CA872F922FD797A0F01B06C@ydlmail01.people-com.com>
References: <352C352C4F01744CA872F922FD797A0F01B06C@ydlmail01.people-com.com>
Message-ID: <44AD13A9.2050604@lanl.gov>

Sergio Garc?a Murillo wrote:
> Hi all
> 
> I have just discovered the project and I was wondering if it could support the ethernet over ata protocol so it could boot up from a net drive.
> AFAIK it would require a 2.6 kernel which I don't know if there are plans to support it soon. 

we've been using linux 2.6 to boot over the network for several years. 
Works fine!

thanks,

ron



From danmez at gmail.com  Thu Jul  6 18:11:56 2006
From: danmez at gmail.com (Dan Mezynski)
Date: Thu, 6 Jul 2006 12:11:56 -0400
Subject: [LinuxBIOS] Problem Using SimNow Simulator
Message-ID: <7b7e71620607060911v2ef188b3y2e8c4a12c7f4435@mail.gmail.com>

I'm trying to get started with LinuxBios by using the AMD SimNow hardware
simulator to run LinuxBios on a Serenade board. Once we have success with
simulations, we will try it on real hardware.  The Serenade board is one
of the standard predefined boards that comes with the simulator. Once I
compile
serenade.rom and reference this file as the rom device connected to the
8111(replacing the AMI BIOS file), I reboot but don't get too far into the
new
Linuxbios, I expected to see recognizable postcodes, such as 0x13 from
c_start.S then 0x80, 0x39, 0x40 etc from hardwaremain(), but port 80 only
toggles
between 00 and 0x10. I try to single step from 0xfffffff0 (or 0xfffbfff0)
but
dont see code that looks like c_start.S. Does something come before this?

I must have built serenade.rom improperly: I did the following,
buildtarget amd/serenade
doneloaded filo.elf
edited serenade/Config.lb to refer to the filo.elf as a payload
make

Any ideas would be appreciated.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060706/4da0e9fa/attachment.html>

From yinghai.lu at amd.com  Thu Jul  6 19:08:17 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Thu, 6 Jul 2006 10:08:17 -0700
Subject: [LinuxBIOS] Problem Using SimNow Simulator
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4207004041@ssvlexmb2.amd.com>

I have tried LinuxBIOS with Serengeti_cheetah ( rev F Opteron) on
SimNow, and it works well.

 

I will try that with Serengeti_leopard later...

 

YH

 

________________________________

From: linuxbios-bounces at linuxbios.org
[mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Dan Mezynski
Sent: Thursday, July 06, 2006 9:12 AM
To: linuxbios at linuxbios.org
Subject: [LinuxBIOS] Problem Using SimNow Simulator

 



I'm trying to get started with LinuxBios by using the AMD SimNow
hardware
simulator to run LinuxBios on a Serenade board. Once we have success
with
simulations, we will try it on real hardware.  The Serenade board is one
of the standard predefined boards that comes with the simulator. Once I
compile
serenade.rom and reference this file as the rom device connected to the
8111(replacing the AMI BIOS file), I reboot but don't get too far into
the new
Linuxbios, I expected to see recognizable postcodes, such as 0x13 from
c_start.S then 0x80, 0x39, 0x40 etc from hardwaremain(), but port 80
only toggles
between 00 and 0x10. I try to single step from 0xfffffff0 (or
0xfffbfff0) but
dont see code that looks like c_start.S. Does something come before
this?

I must have built serenade.rom improperly: I did the following,
buildtarget amd/serenade
doneloaded filo.elf
edited serenade/Config.lb to refer to the filo.elf as a payload
make

Any ideas would be appreciated.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060706/b3503a4e/attachment.html>

From danmez at gmail.com  Fri Jul  7 00:21:09 2006
From: danmez at gmail.com (Dan Mezynski)
Date: Thu, 6 Jul 2006 18:21:09 -0400
Subject: [LinuxBIOS] Problem Using SimNow Simulator
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4207004041@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4207004041@ssvlexmb2.amd.com>
Message-ID: <7b7e71620607061521j3badb43ag21a204377bb1addf@mail.gmail.com>

It's nice to hear you have used SimNow to run LinuxBios on cheetah.

I guess my message title was a bit miss leading, I'm not having problems
with SimNow itself.  In Fact I can run the AMI bios, single step thru it and
even boot Fedora Core 5 linux on the simulated Serenade board in SimNow.
The trouble is when I try to run the LinuxBios that I compiled, since this
serenade board already exists in the LinuxBios configs, I would have thought
I could select it(thru buildtarget) and it would work, but I must have
missed something in the basic build procedure.

I'll try to ask a couple clear questions:
*  Are the first few instructions executed after a reset(hard or soft) in
the source file s_start.S?
*  Do I need to explicitly do something to configure for VGA
initializations, or is that done since I'm using this existing serenade
setup?

On 7/6/06, Lu, Yinghai <yinghai.lu at amd.com> wrote:
>
>  I have tried LinuxBIOS with Serengeti_cheetah ( rev F Opteron) on SimNow,
> and it works well.
>
>
>
> I will try that with Serengeti_leopard later?
>
>
>
> YH
>
>
>  ------------------------------
>
> *From:* linuxbios-bounces at linuxbios.org [mailto:
> linuxbios-bounces at linuxbios.org] *On Behalf Of *Dan Mezynski
> *Sent:* Thursday, July 06, 2006 9:12 AM
> *To:* linuxbios at linuxbios.org
> *Subject:* [LinuxBIOS] Problem Using SimNow Simulator
>
>
>
>
>
> I'm trying to get started with LinuxBios by using the AMD SimNow hardware
> simulator to run LinuxBios on a Serenade board. Once we have success with
> simulations, we will try it on real hardware.  The Serenade board is one
> of the standard predefined boards that comes with the simulator. Once I
> compile
> serenade.rom and reference this file as the rom device connected to the
> 8111(replacing the AMI BIOS file), I reboot but don't get too far into the
> new
> Linuxbios, I expected to see recognizable postcodes, such as 0x13 from
> c_start.S then 0x80, 0x39, 0x40 etc from hardwaremain(), but port 80 only
> toggles
> between 00 and 0x10. I try to single step from 0xfffffff0 (or 0xfffbfff0)
> but
> dont see code that looks like c_start.S. Does something come before this?
>
> I must have built serenade.rom improperly: I did the following,
> buildtarget amd/serenade
> doneloaded filo.elf
> edited serenade/Config.lb to refer to the filo.elf as a payload
> make
>
> Any ideas would be appreciated.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060706/771bd3d6/attachment.html>

From yinghai.lu at amd.com  Fri Jul  7 00:28:41 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Thu, 6 Jul 2006 15:28:41 -0700
Subject: [LinuxBIOS] Problem Using SimNow Simulator
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A420700404F@ssvlexmb2.amd.com>

1.	after your build you image, please find the crt0.s in the
fallback dir.
2.	No.

 

YH

 

________________________________

From: Dan Mezynski [mailto:danmez at gmail.com] 
Sent: Thursday, July 06, 2006 3:21 PM
To: Lu, Yinghai
Cc: linuxbios at linuxbios.org
Subject: Re: [LinuxBIOS] Problem Using SimNow Simulator

 

It's nice to hear you have used SimNow to run LinuxBios on cheetah.

I guess my message title was a bit miss leading, I'm not having problems
with SimNow itself.  In Fact I can run the AMI bios, single step thru it
and even boot Fedora Core 5 linux on the simulated Serenade board in
SimNow.   The trouble is when I try to run the LinuxBios that I
compiled, since this serenade board already exists in the LinuxBios
configs, I would have thought I could select it(thru buildtarget) and it
would work, but I must have missed something in the basic build
procedure.

I'll try to ask a couple clear questions:  
*  Are the first few instructions executed after a reset(hard or soft)
in the source file s_start.S? 
*  Do I need to explicitly do something to configure for VGA
initializations, or is that done since I'm using this existing serenade
setup?

On 7/6/06, Lu, Yinghai <yinghai.lu at amd.com> wrote:

I have tried LinuxBIOS with Serengeti_cheetah ( rev F Opteron) on
SimNow, and it works well.

 

I will try that with Serengeti_leopard later...

 

YH

 

________________________________

From: linuxbios-bounces at linuxbios.org
[mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Dan Mezynski
Sent: Thursday, July 06, 2006 9:12 AM
To: linuxbios at linuxbios.org
Subject: [LinuxBIOS] Problem Using SimNow Simulator

 



I'm trying to get started with LinuxBios by using the AMD SimNow
hardware
simulator to run LinuxBios on a Serenade board. Once we have success
with
simulations, we will try it on real hardware.  The Serenade board is one
of the standard predefined boards that comes with the simulator. Once I
compile
serenade.rom and reference this file as the rom device connected to the
8111(replacing the AMI BIOS file), I reboot but don't get too far into
the new
Linuxbios, I expected to see recognizable postcodes, such as 0x13 from
c_start.S then 0x80, 0x39, 0x40 etc from hardwaremain(), but port 80
only toggles
between 00 and 0x10. I try to single step from 0xfffffff0 (or
0xfffbfff0) but
dont see code that looks like c_start.S. Does something come before
this?

I must have built serenade.rom improperly: I did the following,
buildtarget amd/serenade
doneloaded filo.elf
edited serenade/Config.lb to refer to the filo.elf as a payload
make

Any ideas would be appreciated.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060706/f62e667d/attachment.html>

From zhushisongzhu at yahoo.com  Fri Jul  7 10:50:48 2006
From: zhushisongzhu at yahoo.com (zhu shi song)
Date: Fri, 7 Jul 2006 01:50:48 -0700 (PDT)
Subject: [LinuxBIOS] how to use ramdisk as rootfs
In-Reply-To: <mailman.857.1152224473.6425.linuxbios@linuxbios.org>
Message-ID: <20060707085048.97817.qmail@web36909.mail.mud.yahoo.com>

Dear Lists,
   I can boot my EPIA using Linuxbios.  But I want to
use RAM disk as root file system.  How can I do with
it?
   tks
   zhu

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 



From stepan at coresystems.de  Fri Jul  7 12:08:47 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Fri, 7 Jul 2006 12:08:47 +0200
Subject: [LinuxBIOS] how to use ramdisk as rootfs
In-Reply-To: <20060707085048.97817.qmail@web36909.mail.mud.yahoo.com>
References: <mailman.857.1152224473.6425.linuxbios@linuxbios.org>
	<20060707085048.97817.qmail@web36909.mail.mud.yahoo.com>
Message-ID: <20060707100847.GA20731@coresystems.de>

* zhu shi song <zhushisongzhu at yahoo.com> [060707 10:50]:
> Dear Lists,
>    I can boot my EPIA using Linuxbios.  But I want to
> use RAM disk as root file system.  How can I do with
> it?
 
Use an initial ramdisk (initrd). You can specify it in the bootloader
(ie filo) as initrd=/path/to/initrd in the kernel command line, or
use mkelfImage to produce a single binary from kernel and initrd so it
can be flashed to rom as part of LinuxBIOS.

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From stepan at coresystems.de  Fri Jul  7 15:25:19 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Fri, 7 Jul 2006 15:25:19 +0200
Subject: [LinuxBIOS]  USB Support
Message-ID: <20060707132519.GA24501@coresystems.de>

* Ronald G Minnich <rminnich at lanl.gov> [060703 22:45]:
> yes, but ... that's how it goes. Very few people want to see linuxbios 
> anyway.
 
We do. But after our job is done, it should not be visible, indeed.

> Many years ago I did an experiment, and was able to set things up so 
> that linuxbios log buffer was picked up by the kernel, so you could do a 
> dmesg and see linuxbios messages. I think this might be useful to revive.

Do you have a pointer on this one? It indeed sounds very useful.

> I just don't see us putting a fully capable usb stack into linuxbios, it 
> will not work as well as the linux usb stack.

Not a USB stack. That would be crap, and it would not work. 

Eric pointed this out and I did not even notice what he was saying:

EHCI has a workaround method called the "USB2 Debug port for legacy
free machines"

This debug port can be used by simple inb/outb sequences, not more
complex than serial io.

According to this document

http://www.intel.com/technology/usb/download/DebugDeviceSpec_R090.pdf

what you need is a debug device, which mostly looks like a usb style 
null modem cable. No idea where to get this hardware though.



-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From stepan at coresystems.de  Fri Jul  7 16:18:25 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Fri, 7 Jul 2006 16:18:25 +0200
Subject: [LinuxBIOS] USB Support
In-Reply-To: <20060707132519.GA24501@coresystems.de>
References: <20060707132519.GA24501@coresystems.de>
Message-ID: <20060707141825.GA31098@coresystems.de>

* Stefan Reinauer <stepan at coresystems.de> [060707 15:25]:
> Eric pointed this out and I did not even notice what he was saying:
> 
> EHCI has a workaround method called the "USB2 Debug port for legacy
> free machines"
> 
> This debug port can be used by simple inb/outb sequences, not more
> complex than serial io.
> 
> According to this document
> 
> http://www.intel.com/technology/usb/download/DebugDeviceSpec_R090.pdf
> 
> what you need is a debug device, which mostly looks like a usb style 
> null modem cable. No idea where to get this hardware though.

D'uh - it reads any usb 2 to usb 2 data link cable can be used for this
purpose. Such cables are available for ~ 10$

Also: This is at least supported by the ICH4 and newer Intel EHCI
controllers. I wonder whether AMD or others support it as well?

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From jdegood at atl.lmco.com  Fri Jul  7 16:37:22 2006
From: jdegood at atl.lmco.com (John DeGood)
Date: Fri, 07 Jul 2006 10:37:22 -0400
Subject: [LinuxBIOS] USB Support
In-Reply-To: <20060707141825.GA31098@coresystems.de>
References: <20060707132519.GA24501@coresystems.de>
	<20060707141825.GA31098@coresystems.de>
Message-ID: <44AE71A2.8090606@atl.lmco.com>

Stefan Reinauer wrote:
> Also: This is at least supported by the ICH4 and newer Intel EHCI
> controllers. I wonder whether AMD or others support it as well?

ALI and nVidia are also mentioned as supporting the optional EHCI Debug Device
in this patch:

  http://lkml.org/lkml/2005/1/8/93

John



From ollie at lanl.gov  Fri Jul  7 17:21:57 2006
From: ollie at lanl.gov (ollie)
Date: Fri, 07 Jul 2006 09:21:57 -0600
Subject: [LinuxBIOS] USB Support
In-Reply-To: <20060707141825.GA31098@coresystems.de>
References: <20060707132519.GA24501@coresystems.de>
	<20060707141825.GA31098@coresystems.de>
Message-ID: <1152285717.8553.1.camel@logarithm.lanl.gov>

On Fri, 2006-07-07 at 16:18 +0200, Stefan Reinauer wrote:
> * Stefan Reinauer <stepan at coresystems.de> [060707 15:25]:
> > Eric pointed this out and I did not even notice what he was saying:
> > 
> > EHCI has a workaround method called the "USB2 Debug port for legacy
> > free machines"
> > 
> > This debug port can be used by simple inb/outb sequences, not more
> > complex than serial io.
> > 
> > According to this document
> > 
> > http://www.intel.com/technology/usb/download/DebugDeviceSpec_R090.pdf
> > 
> > what you need is a debug device, which mostly looks like a usb style 
> > null modem cable. No idea where to get this hardware though.
> 
> D'uh - it reads any usb 2 to usb 2 data link cable can be used for this
> purpose. Such cables are available for ~ 10$
> 

What's on the other end of the cable? Just the usual USB port? What 
software we need (minicom)?

Ollie





From russ at ashlandhome.net  Fri Jul  7 18:14:28 2006
From: russ at ashlandhome.net (Russell Whitaker)
Date: Fri, 7 Jul 2006 09:14:28 -0700 (PDT)
Subject: [LinuxBIOS] how to use ramdisk as rootfs
In-Reply-To: <20060707100847.GA20731@coresystems.de>
References: <mailman.857.1152224473.6425.linuxbios@linuxbios.org>
	<20060707085048.97817.qmail@web36909.mail.mud.yahoo.com>
	<20060707100847.GA20731@coresystems.de>
Message-ID: <Pine.LNX.4.63.0607070858020.3093@bigred.russwhit.org>



On Fri, 7 Jul 2006, Stefan Reinauer wrote:

> * zhu shi song <zhushisongzhu at yahoo.com> [060707 10:50]:
>> Dear Lists,
>>    I can boot my EPIA using Linuxbios.  But I want to
>> use RAM disk as root file system.  How can I do with
>> it?
>
> Use an initial ramdisk (initrd). You can specify it in the bootloader
> (ie filo) as initrd=/path/to/initrd in the kernel command line, or
> use mkelfImage to produce a single binary from kernel and initrd so it
> can be flashed to rom as part of LinuxBIOS.
>
Check out www.linux-live.org

It has a series of scripts to run everything from cdrom or usb, and a
script to transfer everything to ram. Both files and dirs are compressed.

There are two distros now using these scripts:
     www.slax.org
     www.zenlive.tuxfamily.org

russ



From stuge-linuxbios at cdy.org  Fri Jul  7 19:52:34 2006
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Fri, 7 Jul 2006 19:52:34 +0200
Subject: [LinuxBIOS] USB Support
In-Reply-To: <1152285717.8553.1.camel@logarithm.lanl.gov>
	<20060707141825.GA31098@coresystems.de>
References: <20060707132519.GA24501@coresystems.de>
	<20060707141825.GA31098@coresystems.de>
	<1152285717.8553.1.camel@logarithm.lanl.gov>
	<20060707132519.GA24501@coresystems.de>
	<20060707141825.GA31098@coresystems.de>
Message-ID: <20060707175234.28138.qmail@cdy.org>

This is a nice idea.

On Fri, Jul 07, 2006 at 04:18:25PM +0200, Stefan Reinauer wrote:
> > what you need is a debug device, which mostly looks like a usb
> > style null modem cable. No idea where to get this hardware
> > though.
> 
> D'uh - it reads any usb 2 to usb 2 data link cable can be used for
> this purpose. Such cables are available for ~ 10$

Where did you read this?

I doubt they will work, unless the manufacturers were exceedingly
clever and actually implemented the DEBUG_MODE feature in the
device..

I agree with your first observation that this will be a special
device, because of the DEBUG_MODE feature described in the spec as
well as the 8 byte limits on transfer size.


On Fri, Jul 07, 2006 at 09:21:57AM -0600, ollie wrote:
> What's on the other end of the cable? Just the usual USB port? What
> software we need (minicom)?

The spec only deals with the end of the debug device that connects to
the target system. I guess implementors are free to choose whatever
USB interface they wish to expose to the host ("remote" in the spec)
system as long as it has one max 8-byte bulk in endpoint and one max
8-byte bulk out endpoint.

I'm not sure if this requirement is compatible with the CDC spec that
USB-serial adapters implement, but it would indeed be very handy if
minicom+the kernel USB-serial driver could be used with the host end
of the debug device.

It's quite possible that the device requires a special application,
but in any case such an application would be trivial to hack up.
I think the hard part is to find or make the hardware. Or maybe not
so hard if you have a proven USB2 HS platform and are comfortable
with tweaking USB descriptors. All I have handy is USB2 FS. :(


//Peter



From stepan at coresystems.de  Fri Jul  7 20:10:52 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Fri, 7 Jul 2006 20:10:52 +0200
Subject: [LinuxBIOS] USB Support
In-Reply-To: <20060707175234.28138.qmail@cdy.org>
References: <20060707132519.GA24501@coresystems.de>
	<20060707141825.GA31098@coresystems.de>
	<1152285717.8553.1.camel@logarithm.lanl.gov>
	<20060707132519.GA24501@coresystems.de>
	<20060707141825.GA31098@coresystems.de>
	<20060707175234.28138.qmail@cdy.org>
Message-ID: <20060707181052.GC3871@coresystems.de>

* Peter Stuge <stuge-linuxbios at cdy.org> [060707 19:52]:
> This is a nice idea.
> 
> On Fri, Jul 07, 2006 at 04:18:25PM +0200, Stefan Reinauer wrote:
> > > what you need is a debug device, which mostly looks like a usb
> > > style null modem cable. No idea where to get this hardware
> > > though.
> > 
> > D'uh - it reads any usb 2 to usb 2 data link cable can be used for
> > this purpose. Such cables are available for ~ 10$
> 
> Where did you read this?
> 
> I doubt they will work, unless the manufacturers were exceedingly
> clever and actually implemented the DEBUG_MODE feature in the
> device..

You are right. The cable would need to implement the DEBUG_MODE feature.

I read over page 5 of
http://www.intel.com/technology/magazine/computing/it09021.pdf
and it actually says so.

The question is now: what devices/cables can be used for this purpose.
Or is it maybe trivial to build such a device yourself in a low
quantity?
 
> I'm not sure if this requirement is compatible with the CDC spec that
> USB-serial adapters implement, but it would indeed be very handy if
> minicom+the kernel USB-serial driver could be used with the host end
> of the debug device.

That would indeed be great! 

> It's quite possible that the device requires a special application,
> but in any case such an application would be trivial to hack up.

Or just a small dummy serial driver so minicom or whatever could be
used.

> I think the hard part is to find or make the hardware. Or maybe not
> so hard if you have a proven USB2 HS platform and are comfortable
> with tweaking USB descriptors. All I have handy is USB2 FS. :(
 
The idea is probably to get a cost effective solution, otherwise a lot
of volunteers might get locked out of joining the project.

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From fourstar10_2000 at yahoo.com  Fri Jul  7 20:37:59 2006
From: fourstar10_2000 at yahoo.com (steve yannalfo)
Date: Fri, 7 Jul 2006 11:37:59 -0700 (PDT)
Subject: [LinuxBIOS] VGA Help (hangs on emulator)
Message-ID: <20060707183800.74120.qmail@web38910.mail.mud.yahoo.com>

I know it is friday and we are all tired....

I have a VGA device off amd8132 channel B
Trying VGA but LB hangs on the emulator.....
It looks like the VGA image is OK and loading... but,
 Any help would be appreciated.... 
-----------------------------------------------------------------------
LB output....

PCI: 42:01.0 10 <- [0x00f0000000 - 0x00f7ffffff] prefmem
PCI: 42:01.0 14 <- [0x0000004000 - 0x00000040ff] io
PCI: 42:01.0 18 <- [0x00fc000000 - 0x00fc00ffff] mem
PCI: 42:01.0 30 <- [0x00fff80000 - 0x00fff9ffff] romem
...
Setting up local apic... apic_id: 1 done.
CPU #1 Initialized
All AP CPUs stopped
PCI: 00:18.0 init
PCI: 40:00.0 init
PCI: 40:00.1 init
PCI: 40:01.0 init
PCI: 42:01.0 init
rom address for PCI: 42:01.0 = fff80000
copying VGA ROM Image from 0xfff80000 to 0xc0000, 0xf000 bytes
entering emulator
<hangs here>
-----------------------------------------------------------------------------
My Config.lb....

chip southbridge/amd/amd8132
    device pci 0.0 on end            # Channel A
    device pci 0.1 on end 
    device pci 1.0 on                    # Channel B
        chip drivers/pci/onboard
            device pci 1.0 on end
            register "rom_address" = "0xfff80000"    #  start of video bios = rom_addres = 4G - 512K
        end
    end
    device pci 1.1 on end

-------------------------------------------------------------
my mptables.c part....

//----- "VGA        42:01.0 ----- ATI FIreGL 9000
smp_write_intsrc(mc,mp_INT,MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, bus_8132_2, (1<<2) |0, apicid_8132_2, 19);

-----------------------------------------------------------
Data from original BIOS

12:01.0 VGA compatible controller: ATI Technologies Inc Radeon R250 Lf [FireGL 9000] (rev 02) (prog-if 00 [VGA])
    Subsystem: ATI Technologies Inc Radeon R250 Lf [FireGL 9000]
    Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B-
    Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
    Latency: 255 (2000ns min), Cache Line Size 08
    Interrupt: pin A routed to IRQ 5
    Region 0: Memory at d0000000 (32-bit, prefetchable) [size=128M]
    Region 1: I/O ports at 5c00 [size=256]
    Region 2: Memory at dfdf0000 (32-bit, non-prefetchable) [size=64K]
    [virtual] Expansion ROM at dfd00000 [disabled] [size=128K]
    Capabilities: [50] Power Management version 2
        Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
        Status: D0 PME-Enable- DSel=0 DScale=0 PME-
---------------------------------------------
VGA Rom part starts w/ 0x55aa
size =  61440
---------------------------------------------
#VGA Console
default CONFIG_CONSOLE_VGA=1
default CONFIG_PCI_ROM_RUN=1
----------------------------------------------
etherboot...
# for btext console support
CFLAGS+=    -DCONSOLE_BTEXT
# for direct PC kbd support
CFLAGS+=    -DCONSOLE_PC_KBD
------------------------------------------------


 		
---------------------------------
Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2?/min or less.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060707/556ef2d9/attachment.html>

From yinghai.lu at amd.com  Fri Jul  7 20:46:55 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Fri, 7 Jul 2006 11:46:55 -0700
Subject: [LinuxBIOS] VGA Help (hangs on emulator)
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4207004059@ssvlexmb2.amd.com>

Can you try some other VGA cards? Such as nvidia...

 

YH

 

 

 

________________________________

From: linuxbios-bounces at linuxbios.org [mailto:linuxbios-bounces at linuxbios.org] On Behalf Of steve yannalfo
Sent: Friday, July 07, 2006 11:38 AM
To: linuxbios at linuxbios.org
Subject: [LinuxBIOS] VGA Help (hangs on emulator)

 

I know it is friday and we are all tired....

I have a VGA device off amd8132 channel B
Trying VGA but LB hangs on the emulator.....
It looks like the VGA image is OK and loading... but,
Any help would be appreciated.... 
-----------------------------------------------------------------------
LB output....

PCI: 42:01.0 10 <- [0x00f00000000 - 0x00f7ffffff] prefmem
PCI: 42:01.0 14 <- [0x0000004000 - 0x00000040ff] io
PCI: 42:01.0 18 <- [0x00fc000000 - 0x00fc00ffff] mem
PCI: 42:01.0 30 <- [0x00fff80000 - 0x00fff9ffff] romem
...
Setting up local apic... apic_id: 1 done.
CPU #1 Initialized
All AP CPUs stopped
PCI: 00:18.0 init
PCI: 40:00.0 init
PCI: 40:00.1 init
PCI: 40:01.0 init
PCI: 42:01.0 init
rom address for PCI: 42:01.0 = fff80000
copying VGA ROM Image from 0xfff80000 to 0xc0000, 0xf000 bytes
entering emulator
<hangs here>
-----------------------------------------------------------------------------
My Config.lb....

chip southbridge/amd//amd8132
    device pci 0.0 on end            # Channel A
    device pci 0.1 on end 
    device pci 1.0 on                    # Channel B
        chip drivers/pci/onboard
            device pci 1.0 on end
            register "rom_address" = "0xfff80000"    #  start of video bios = rom_addres = 4G - 512K
        end
    end
    device pci 1.1 on end

-------------------------------------------------------------
my mptables.c part....

//----- "VGA        42:01.0 ----- ATI FIreGL 9000
smp_write_intsrc(mc,mp_INT,MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, bus_8132_2, (1<<2) |0, apicid_8132_2, 19);

-----------------------------------------------------------
Data from original BIOS

12:01.0 VGA compatible controller: ATI Technologies Inc Radeon R250 Lf [FireGL 9000] (rev 02) (prog-if 00 [VGA])
    Subsystem: ATI Technologies Inc Radeon R250 Lf [FireGL 9000]
    Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B-
    Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
    Latency: 255 (2000ns min), Cache Line Size 08
    Interrupt: pin A routed to IRQ 5
    Region 0: Memory at d0000000 (32-bit, prefetchable) [size=128M]
    Region 1: I/O ports at 5c00 [size=256]
    Region 2: Memory at dfdf0000 (32-bit, non-prefetchable) [size=64K]
    [virtual] Expansion ROM at dfd00000 [disabled] [size=128K]
    Capabilities: [50] Power Management version 2
        Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
        Status: D0 PME-Enable- DSel=0 DScale=0 PME-
---------------------------------------------
VGA Rom part starts w/ 0x55aa
size =  61440
----------------------------------------------
#VGA Console
default CONFIG_CONSOLE_VGA=1
default CONFIG_PCI_ROM_RUN=1
----------------------------------------------
etherboot...
# for btext console support
CFLAGS+=    -DCONSOLE_BTEXT
# for direct PC kbd support
CFLAGS+=    -DCONSOLE_PC_KBD
------------------------------------------------

  

________________________________

Yahoo! Messenger with Voice. Make PC-to-Phone Calls <http://us.rd.yahoo.com/mail_us/taglines/postman1/*http:/us.rd.yahoo.com/evt=39663/*http:/voice.yahoo.com>  to the US (and 30+ countries) for 2?/min or less.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060707/b2739356/attachment.html>

From fourstar10_2000 at yahoo.com  Fri Jul  7 23:02:23 2006
From: fourstar10_2000 at yahoo.com (steve yannalfo)
Date: Fri, 7 Jul 2006 14:02:23 -0700 (PDT)
Subject: [LinuxBIOS]  VGA Help (hangs on emulator)
Message-ID: <20060707210223.33511.qmail@web38911.mail.mud.yahoo.com>

Is the FallBack Image able to use VGA?

in Config.lb...
 rom_image "normal"
    optiion ROM_SIZE is the romsize - vgabios

but, there is no option ROM_SIZE in rom_image "fallback"

does this mean we have to get a complete boot... then reboot to get VGA?

Thank You.

 __________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060707/bd1de2d0/attachment.html>

From bari at onelabs.com  Fri Jul  7 23:14:41 2006
From: bari at onelabs.com (Bari Ari)
Date: Fri, 07 Jul 2006 16:14:41 -0500
Subject: [LinuxBIOS] USB Support
In-Reply-To: <20060707181052.GC3871@coresystems.de>
References: <20060707132519.GA24501@coresystems.de>	<20060707141825.GA31098@coresystems.de>	<1152285717.8553.1.camel@logarithm.lanl.gov>	<20060707132519.GA24501@coresystems.de>	<20060707141825.GA31098@coresystems.de>	<20060707175234.28138.qmail@cdy.org>
	<20060707181052.GC3871@coresystems.de>
Message-ID: <44AECEC1.1020409@onelabs.com>

Stefan Reinauer wrote:
> * Peter Stuge <stuge-linuxbios at cdy.org> [060707 19:52]:
>   
>> This is a nice idea.
>>
>> On Fri, Jul 07, 2006 at 04:18:25PM +0200, Stefan Reinauer wrote:
>>     
>>>> what you need is a debug device, which mostly looks like a usb
>>>> style null modem cable. No idea where to get this hardware
>>>> though.
>>>>         
>>> D'uh - it reads any usb 2 to usb 2 data link cable can be used for
>>> this purpose. Such cables are available for ~ 10$
>>>       
>> Where did you read this?
>>
>> I doubt they will work, unless the manufacturers were exceedingly
>> clever and actually implemented the DEBUG_MODE feature in the
>> device..
>>     
>
> You are right. The cable would need to implement the DEBUG_MODE feature.
>
> I read over page 5 of
> http://www.intel.com/technology/magazine/computing/it09021.pdf
> and it actually says so.
>
> The question is now: what devices/cables can be used for this purpose.
> Or is it maybe trivial to build such a device yourself in a low
> quantity?
>  
>   
>> I'm not sure if this requirement is compatible with the CDC spec that
>> USB-serial adapters implement, but it would indeed be very handy if
>> minicom+the kernel USB-serial driver could be used with the host end
>> of the debug device.
>>     
>
> That would indeed be great! 
>
>   
>> It's quite possible that the device requires a special application,
>> but in any case such an application would be trivial to hack up.
>>     
>
> Or just a small dummy serial driver so minicom or whatever could be
> used.
>
>   
>> I think the hard part is to find or make the hardware. Or maybe not
>> so hard if you have a proven USB2 HS platform and are comfortable
>> with tweaking USB descriptors. All I have handy is USB2 FS. :(
>>     
>  
> The idea is probably to get a cost effective solution, otherwise a lot
> of volunteers might get locked out of joining the project.
>
> Stefan
>   
Let me know what it actually needs (if it needs to be custom) and I'll 
see about manufacturing them in low volumes (100's, k's) for cheap.

-Bari



From ward at gnu.org  Fri Jul  7 23:16:47 2006
From: ward at gnu.org (Ward Vandewege)
Date: Fri, 7 Jul 2006 17:16:47 -0400
Subject: [LinuxBIOS] VGA Help (hangs on emulator)
In-Reply-To: <20060707183800.74120.qmail@web38910.mail.mud.yahoo.com>
References: <20060707183800.74120.qmail@web38910.mail.mud.yahoo.com>
Message-ID: <20060707211647.GA26877@localdomain>

On Fri, Jul 07, 2006 at 11:37:59AM -0700, steve yannalfo wrote:
> I know it is friday and we are all tired....
> 
> I have a VGA device off amd8132 channel B
> Trying VGA but LB hangs on the emulator.....
> It looks like the VGA image is OK and loading... but,

Anton Borisov has just released some tools to extract VGA images from BIOS
ROM images. I've just updated the FAQ:

  http://www.linuxbios.org/index.php/FAQ#How_to_retrieve_a_good_video_bios

You might want to try that to make sure your image is ok.

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator



From yinghai.lu at amd.com  Fri Jul  7 23:20:14 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Fri, 7 Jul 2006 14:20:14 -0700
Subject: [LinuxBIOS] VGA Help (hangs on emulator)
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A420700405E@ssvlexmb2.amd.com>

One copy (vga rom), and It is used by fallback and nomal booting.

 

YH

________________________________

From: linuxbios-bounces at linuxbios.org
[mailto:linuxbios-bounces at linuxbios.org] On Behalf Of steve yannalfo
Sent: Friday, July 07, 2006 2:02 PM
To: linuxbios at linuxbios.org
Subject: [LinuxBIOS] VGA Help (hangs on emulator)

 

Is the FallBack Image able to use VGA?

in Config.lb...
 rom_image "normal"
    optiion ROM_SIZE is the romsize - vgabios

but, there is no option ROM_SIZE in rom_image "fallback"

does this mean we have to get a complete boot... then reboot to get VGA?

Thank You.

 __________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060707/ef2bc5f7/attachment.html>

From yinghai.lu at amd.com  Fri Jul  7 23:24:27 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Fri, 7 Jul 2006 14:24:27 -0700
Subject: [LinuxBIOS] VGA Help (hangs on emulator)
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A420700405F@ssvlexmb2.amd.com>

Addon card do need that. The LinuxBIOS will find the rom on that card.

YH

-----Original Message-----
From: linuxbios-bounces at linuxbios.org
[mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Ward Vandewege
Sent: Friday, July 07, 2006 2:17 PM
To: steve yannalfo
Cc: linuxbios at linuxbios.org
Subject: Re: [LinuxBIOS] VGA Help (hangs on emulator)

On Fri, Jul 07, 2006 at 11:37:59AM -0700, steve yannalfo wrote:
> I know it is friday and we are all tired....
> 
> I have a VGA device off amd8132 channel B
> Trying VGA but LB hangs on the emulator.....
> It looks like the VGA image is OK and loading... but,

Anton Borisov has just released some tools to extract VGA images from
BIOS
ROM images. I've just updated the FAQ:

 
http://www.linuxbios.org/index.php/FAQ#How_to_retrieve_a_good_video_bios

You might want to try that to make sure your image is ok.

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator

-- 
linuxbios mailing list
linuxbios at linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios






From ward at gnu.org  Fri Jul  7 23:41:00 2006
From: ward at gnu.org (Ward Vandewege)
Date: Fri, 7 Jul 2006 17:41:00 -0400
Subject: [LinuxBIOS] VGA Help (hangs on emulator)
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A420700405F@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A420700405F@ssvlexmb2.amd.com>
Message-ID: <20060707214100.GA27153@localdomain>

On Fri, Jul 07, 2006 at 02:24:27PM -0700, Lu, Yinghai wrote:
> Addon card don't need that. The LinuxBIOS will find the rom on that card.

Ah, yes of course, I assumed an embedded vga card. I'll add that to the
FAQ...

Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator



From tom.sylla at amd.com  Fri Jul  7 23:48:42 2006
From: tom.sylla at amd.com (Tom Sylla)
Date: Fri, 07 Jul 2006 15:48:42 -0600
Subject: [LinuxBIOS] USB Support
In-Reply-To: <44AECEC1.1020409@onelabs.com>
References: <20060707132519.GA24501@coresystems.de>
	<20060707141825.GA31098@coresystems.de>
	<1152285717.8553.1.camel@logarithm.lanl.gov>
	<20060707132519.GA24501@coresystems.de>
	<20060707141825.GA31098@coresystems.de>
	<20060707175234.28138.qmail@cdy.org>
	<20060707181052.GC3871@coresystems.de> <44AECEC1.1020409@onelabs.com>
Message-ID: <44AED6BA.6070904@amd.com>

Bari Ari wrote:
> Let me know what it actually needs (if it needs to be custom) and I'll 
> see about manufacturing them in low volumes (100's, k's) for cheap.

WinDBG has recently added support for USB2 debugging support. I haven't 
seen it explicitly stated by Microsoft anywhere, but it seems to use the 
"debug port" defined by EHCI. Here is a post:

http://www.osronline.com/article.cfm?id=456

The debug cable mentioned can be purchased from Mouser for $75:

http://www.mouser.com/index.cfm?handler=displayproduct&lstdispproductid=950546

or here for 80:

http://shop.semiconductorstore.com/iwwida.pvx?;item?item_no=NET20DC%20%20%20%20%20%20%20%201?comp=SYM

A little more info here:

http://advdbg.com/blogs/advdbg_system/articles/64.aspx

For debug targets with their own *device* controller, you may not even 
need the dongle.





From stuge-linuxbios at cdy.org  Sun Jul  9 05:23:02 2006
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Sun, 9 Jul 2006 05:23:02 +0200
Subject: [LinuxBIOS] USB Support
In-Reply-To: <44AED6BA.6070904@amd.com>
References: <20060707132519.GA24501@coresystems.de>
	<20060707141825.GA31098@coresystems.de>
	<1152285717.8553.1.camel@logarithm.lanl.gov>
	<20060707132519.GA24501@coresystems.de>
	<20060707141825.GA31098@coresystems.de>
	<20060707175234.28138.qmail@cdy.org>
	<20060707181052.GC3871@coresystems.de>
	<44AECEC1.1020409@onelabs.com> <44AED6BA.6070904@amd.com>
Message-ID: <20060709032302.30951.qmail@cdy.org>

On Fri, Jul 07, 2006 at 03:48:42PM -0600, Tom Sylla wrote:
> The debug cable mentioned can be purchased from Mouser for $75:
> 
> http://www.mouser.com/index.cfm?handler=displayproduct&lstdispproductid=950546
> 
> or here for 80:
> 
> http://shop.semiconductorstore.com/iwwida.pvx?;item?item_no=NET20DC%20%20%20%20%20%20%20%201?comp=SYM

Perfect.


> For debug targets with their own *device* controller, you may not even 
> need the dongle.

No, but that also means that the debugging code will differ between
firmware implementations. A NET20DC or other debug device
implementing the spec has the benefit of a standardized simple
interface on both ends.


//Peter



From bari at onelabs.com  Sun Jul  9 06:46:55 2006
From: bari at onelabs.com (Bari Ari)
Date: Sat, 08 Jul 2006 23:46:55 -0500
Subject: [LinuxBIOS] USB Support
In-Reply-To: <44AED6BA.6070904@amd.com>
References: <20060707132519.GA24501@coresystems.de>
	<20060707141825.GA31098@coresystems.de>
	<1152285717.8553.1.camel@logarithm.lanl.gov>
	<20060707132519.GA24501@coresystems.de>
	<20060707141825.GA31098@coresystems.de>
	<20060707175234.28138.qmail@cdy.org>
	<20060707181052.GC3871@coresystems.de>
	<44AECEC1.1020409@onelabs.com> <44AED6BA.6070904@amd.com>
Message-ID: <44B08A3F.1080302@onelabs.com>

Tom Sylla wrote:
> Bari Ari wrote:
>> Let me know what it actually needs (if it needs to be custom) and 
>> I'll see about manufacturing them in low volumes (100's, k's) for cheap.
>
> WinDBG has recently added support for USB2 debugging support. I 
> haven't seen it explicitly stated by Microsoft anywhere, but it seems 
> to use the "debug port" defined by EHCI. Here is a post:
>
> http://www.osronline.com/article.cfm?id=456
>
> The debug cable mentioned can be purchased from Mouser for $75:
>
>
The orphaned page at PLX on the USB debug cable is at:
http://www.plxtech.com/products/NET2000/NET20DC/default.asp

The NET20DC's don't seem to be in stock anywhere. I wonder if they are 
out of production since the page is active yet orphaned on their 
website. The search function on the PLX website also returns nothing on 
the NET20DC.

-Bari



From smithbone at gmail.com  Mon Jul 10 00:41:39 2006
From: smithbone at gmail.com (Richard Smith)
Date: Sun, 9 Jul 2006 17:41:39 -0500
Subject: [LinuxBIOS] [PATCH] Change payload buildrule to 'cp -f'
Message-ID: <8a0c36780607091541v5f6ee07dua9ff3311574abbc0@mail.gmail.com>

mkelfimage creates read only output.  This causes the build script to
error with a permission denied when it tries to overwrite a payload
created by mkelfimage.

Eric Biederman requested that we mod the script rather than change the
output of mkelfimage upstream.

-- 
Richard A. Smith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: make_payload_rule_use_cp-f.patch
Type: application/octet-stream
Size: 323 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060709/82c3e506/attachment.obj>

From zhushisongzhu at yahoo.com  Mon Jul 10 12:04:43 2006
From: zhushisongzhu at yahoo.com (zhu shi song)
Date: Mon, 10 Jul 2006 03:04:43 -0700 (PDT)
Subject: [LinuxBIOS] how to use ramdisk as rootfs
In-Reply-To: <Pine.LNX.4.63.0607070858020.3093@bigred.russwhit.org>
Message-ID: <20060710100443.12978.qmail@web36901.mail.mud.yahoo.com>

I must concern two requirements:
(1) I boot my linux from IDE CF card whose capacity is
no more than 128M Bytes.
(2) my ram is large enough(above 1G) for the size of
the whole root file system.
  In the past ,when I use linux-2.4 kernel, I use
initrd-dyn method and can use one tar.gz file just
like initrd transferred to kernel as parameter. The
kernel can uncompress the tar.gz file and mount it on
ramdisk as rootfs.  Unfortunately, initrd-dyn can't
support linux-2.6 kernel.  Can I convert my tar.gz
file to cpio format as initramfs and make kernel
uncompress it and mount it as rootfs on ramdisk
automatically?  I'm not so familiar with either initrd
or initramfs, where can I find more and clear info
about these topics?
  tks
  zhu
  





--- Russell Whitaker <russ at ashlandhome.net> wrote:

> 
> 
> On Fri, 7 Jul 2006, Stefan Reinauer wrote:
> 
> > * zhu shi song <zhushisongzhu at yahoo.com> [060707
> 10:50]:
> >> Dear Lists,
> >>    I can boot my EPIA using Linuxbios.  But I
> want to
> >> use RAM disk as root file system.  How can I do
> with
> >> it?
> >
> > Use an initial ramdisk (initrd). You can specify
> it in the bootloader
> > (ie filo) as initrd=/path/to/initrd in the kernel
> command line, or
> > use mkelfImage to produce a single binary from
> kernel and initrd so it
> > can be flashed to rom as part of LinuxBIOS.
> >
> Check out www.linux-live.org
> 
> It has a series of scripts to run everything from
> cdrom or usb, and a
> script to transfer everything to ram. Both files and
> dirs are compressed.
> 
> There are two distros now using these scripts:
>      www.slax.org
>      www.zenlive.tuxfamily.org
> 
> russ
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 



From stepan at coresystems.de  Mon Jul 10 13:08:55 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 10 Jul 2006 13:08:55 +0200
Subject: [LinuxBIOS] [PATCH] Change payload buildrule to 'cp -f'
In-Reply-To: <8a0c36780607091541v5f6ee07dua9ff3311574abbc0@mail.gmail.com>
References: <8a0c36780607091541v5f6ee07dua9ff3311574abbc0@mail.gmail.com>
Message-ID: <20060710110855.GA18114@coresystems.de>

* Richard Smith <smithbone at gmail.com> [060710 00:41]:
> mkelfimage creates read only output.  This causes the build script to
> error with a permission denied when it tries to overwrite a payload
> created by mkelfimage.
> 
> Eric Biederman requested that we mod the script rather than change the
> output of mkelfimage upstream.
 
Eric,

I would say that this misses the point of write permissions. What's the
reason for mkelfImage setting its results read-only in the first place? 
No other payloads have such a behavior. Can you please explain your
decision a little bit? From the outside this definitely looks like
the issue needs to be fixed in mkelfImage. 

 Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From ebiederman at lnxi.com  Mon Jul 10 13:35:48 2006
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon, 10 Jul 2006 05:35:48 -0600
Subject: [LinuxBIOS] [PATCH] Change payload buildrule to 'cp -f'
In-Reply-To: <20060710110855.GA18114@coresystems.de> (Stefan Reinauer's
	message of "Mon, 10 Jul 2006 13:08:55 +0200")
References: <8a0c36780607091541v5f6ee07dua9ff3311574abbc0@mail.gmail.com>
	<20060710110855.GA18114@coresystems.de>
Message-ID: <m3ac7hofor.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at coresystems.de> writes:

> * Richard Smith <smithbone at gmail.com> [060710 00:41]:
>> mkelfimage creates read only output.  This causes the build script to
>> error with a permission denied when it tries to overwrite a payload
>> created by mkelfimage.
>> 
>> Eric Biederman requested that we mod the script rather than change the
>> output of mkelfimage upstream.
>  
> Eric,
>
> I would say that this misses the point of write permissions. What's the
> reason for mkelfImage setting its results read-only in the first place? 
> No other payloads have such a behavior. Can you please explain your
> decision a little bit? From the outside this definitely looks like
> the issue needs to be fixed in mkelfImage. 

As best as I can recall of the original decision making process.

A common use of mkelfImage has been to put a bootable ELF image
in /tftpboot.  In that scenario someone may be downloading the
image when you are updating it.  Therefore to correctly update
the file, you must first write to a new filename and then move
it to the new filename.  Which gives you atomic update permissions.

The goal was to catch issues where people did not do that.

That is exactly what was caught here.

If the problem was one where what you are updating needs to
be writable I would agree that it is not a build script issue.
However since you don't need write permissions and are just stomping
on the file we are doing the wrong thing in the build.

Show me a case where you actually need write permissions and I will
be sympathetic.

While I think it can be argued that mkelfImage is wrong I think
the case is that our build process is even more incorrect.

Is there ever a case where writing to an active executable does the
correct thing?

Eric



From rminnich at lanl.gov  Mon Jul 10 16:22:36 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 10 Jul 2006 08:22:36 -0600
Subject: [LinuxBIOS] how to use ramdisk as rootfs
In-Reply-To: <20060710100443.12978.qmail@web36901.mail.mud.yahoo.com>
References: <20060710100443.12978.qmail@web36901.mail.mud.yahoo.com>
Message-ID: <44B262AC.9050503@lanl.gov>

you can build  cpio archive and use it as an initrd.

ron



From smithbone at gmail.com  Mon Jul 10 19:05:32 2006
From: smithbone at gmail.com (Richard Smith)
Date: Mon, 10 Jul 2006 12:05:32 -0500
Subject: [LinuxBIOS] how to use ramdisk as rootfs
In-Reply-To: <20060710100443.12978.qmail@web36901.mail.mud.yahoo.com>
References: <Pine.LNX.4.63.0607070858020.3093@bigred.russwhit.org>
	<20060710100443.12978.qmail@web36901.mail.mud.yahoo.com>
Message-ID: <8a0c36780607101005w22b71071s9e137340611ea353@mail.gmail.com>

> support linux-2.6 kernel.  Can I convert my tar.gz
> file to cpio format as initramfs and make kernel
> uncompress it and mount it as rootfs on ramdisk
> automatically?  I'm not so familiar with either initrd
> or initramfs, where can I find more and clear info
> about these topics?


There is a little bit of info about initramfs in the kernel tree.

/Documentation/filesystems/ramfs-rootfs-initramfs.txt

-- 
Richard A. Smith



From rminnich at lanl.gov  Mon Jul 10 20:05:34 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 10 Jul 2006 12:05:34 -0600
Subject: [LinuxBIOS] how to use ramdisk as rootfs
In-Reply-To: <44B262AC.9050503@lanl.gov>
References: <20060710100443.12978.qmail@web36901.mail.mud.yahoo.com>
	<44B262AC.9050503@lanl.gov>
Message-ID: <44B296EE.7050602@lanl.gov>

Ronald G Minnich wrote:
> you can build  cpio archive and use it as an initrd.
> 
> ron
> 

here is the script I currently use. Pretend your prototype file system 
is in root_dir

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: MAKE_CPIO
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060710/0f69d70c/attachment.ksh>

From rminnich at lanl.gov  Mon Jul 10 20:05:59 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 10 Jul 2006 12:05:59 -0600
Subject: [LinuxBIOS] how to use ramdisk as rootfs
In-Reply-To: <8a0c36780607101005w22b71071s9e137340611ea353@mail.gmail.com>
References: <Pine.LNX.4.63.0607070858020.3093@bigred.russwhit.org>	<20060710100443.12978.qmail@web36901.mail.mud.yahoo.com>
	<8a0c36780607101005w22b71071s9e137340611ea353@mail.gmail.com>
Message-ID: <44B29707.20802@lanl.gov>

Richard Smith wrote:
>>support linux-2.6 kernel.  Can I convert my tar.gz
>>file to cpio format as initramfs and make kernel
>>uncompress it and mount it as rootfs on ramdisk
>>automatically?  I'm not so familiar with either initrd
>>or initramfs, where can I find more and clear info
>>about these topics?
> 
> 
> 
> There is a little bit of info about initramfs in the kernel tree.
> 
> /Documentation/filesystems/ramfs-rootfs-initramfs.txt
> 

I don't recommend initramfs -- just make a cpio initrd. Current 
initramfs support is bug-ridden.

ron



From ebiederman at lnxi.com  Mon Jul 10 20:25:42 2006
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon, 10 Jul 2006 12:25:42 -0600
Subject: [LinuxBIOS] how to use ramdisk as rootfs
In-Reply-To: <44B29707.20802@lanl.gov> (Ronald G. Minnich's message of "Mon,
	10 Jul 2006 12:05:59 -0600")
References: <Pine.LNX.4.63.0607070858020.3093@bigred.russwhit.org>
	<20060710100443.12978.qmail@web36901.mail.mud.yahoo.com>
	<8a0c36780607101005w22b71071s9e137340611ea353@mail.gmail.com>
	<44B29707.20802@lanl.gov>
Message-ID: <m31wste2qh.fsf@maxwell.lnxi.com>

Ronald G Minnich <rminnich at lanl.gov> writes:

> Richard Smith wrote:
>>>support linux-2.6 kernel.  Can I convert my tar.gz
>>>file to cpio format as initramfs and make kernel
>>>uncompress it and mount it as rootfs on ramdisk
>>>automatically?  I'm not so familiar with either initrd
>>>or initramfs, where can I find more and clear info
>>>about these topics?
>> 
>> 
>> 
>> There is a little bit of info about initramfs in the kernel tree.
>> 
>> /Documentation/filesystems/ramfs-rootfs-initramfs.txt
>> 
>
> I don't recommend initramfs -- just make a cpio initrd. Current 
> initramfs support is bug-ridden.

To be clear a cpio format initrd is referred to as an initramfs.  There
are no real implementation differences between the in kernel and
initrd styles the only question is where does the cpio archive come
from, and how is the cpio archive built.

Since the in kernel cpio archive builder has issues it does make sense
to avoid it.

Eric



From smithbone at gmail.com  Mon Jul 10 20:45:40 2006
From: smithbone at gmail.com (Richard Smith)
Date: Mon, 10 Jul 2006 13:45:40 -0500
Subject: [LinuxBIOS] [PATCH] Change payload buildrule to 'cp -f'
In-Reply-To: <m3ac7hofor.fsf@maxwell.lnxi.com>
References: <8a0c36780607091541v5f6ee07dua9ff3311574abbc0@mail.gmail.com>
	<20060710110855.GA18114@coresystems.de>
	<m3ac7hofor.fsf@maxwell.lnxi.com>
Message-ID: <8a0c36780607101145l218f4701n3389465c9f7b53ce@mail.gmail.com>

> A common use of mkelfImage has been to put a bootable ELF image
> in /tftpboot.  In that scenario someone may be downloading the
> image when you are updating it.  Therefore to correctly update
> the file, you must first write to a new filename and then move
> it to the new filename.  Which gives you atomic update permissions.

Ah... Thanks for the clarification.

> The goal was to catch issues where people did not do that.

> That is exactly what was caught here.

Not quite.  This was just for a normal fallback build for the in-flash
kernel using a payload directive in the config file.

> If the problem was one where what you are updating needs to
> be writable I would agree that it is not a build script issue.
> However since you don't need write permissions and are just stomping
> on the file we are doing the wrong thing in the build.

Stefan.  I think Eric's right and the build script needs the tweak
regardless of the output of mkelfimage.  If the users umask is set
restrictive then the same problem would occur.
I noticed in the makefile that there are a few other cp's that
probably need to be cp -f as well.

Ok to commit?

-- 
Richard A. Smith



From jheim at math.wisc.edu  Tue Jul 11 03:44:02 2006
From: jheim at math.wisc.edu (John Heim)
Date: Mon, 10 Jul 2006 20:44:02 -0500
Subject: [LinuxBIOS] mobo suggestions?
Message-ID: <44B30262.3090100@math.wisc.edu>

Hi,

I'm blind and I want to try linuxbios to see if that will allow me to 
access the BIOS on a computer. I would like to try to build myself a new 
PC and I was wondering if anybody has a suggestion for a motherboard. On 
the web site, there's a list of mobos that linuxbios is known to work on 
but they seem to be server motherboards.  I just want something that I 
can use for a desktop workstation.





From rminnich at lanl.gov  Mon Jul 10 22:55:29 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 10 Jul 2006 14:55:29 -0600
Subject: [LinuxBIOS] mobo suggestions?
In-Reply-To: <44B30262.3090100@math.wisc.edu>
References: <44B30262.3090100@math.wisc.edu>
Message-ID: <44B2BEC1.2000404@lanl.gov>

John Heim wrote:
> Hi,
> 
> I'm blind and I want to try linuxbios to see if that will allow me to 
> access the BIOS on a computer. I would like to try to build myself a new 
> PC and I was wondering if anybody has a suggestion for a motherboard. On 
> the web site, there's a list of mobos that linuxbios is known to work on 
> but they seem to be server motherboards.  I just want something that I 
> can use for a desktop workstation.
> 
> 
> 

we have not done desktops for a while. I wonder if an AMD GX2-based 
system might be good for you-- how much compute power are you looking for?

ron



From dhendrix at google.com  Tue Jul 11 01:08:31 2006
From: dhendrix at google.com (David Hendricks)
Date: Mon, 10 Jul 2006 16:08:31 -0700
Subject: [LinuxBIOS] Booting from a ethernet over ata device
In-Reply-To: <352C352C4F01744CA872F922FD797A0F01B06C@ydlmail01.people-com.com>
References: <352C352C4F01744CA872F922FD797A0F01B06C@ydlmail01.people-com.com>
Message-ID: <ec9b26620607101608q67daed8fjea9eaa8b13b1a6be@mail.google.com>

You may want to check to see if ethernet over ata is supported in Etherboot.
If you can make an Etherboot image with support for this, then you can use
that Etherboot image as a LinuxBIOS payload.

Good luck and check back with this list if you have difficulties.

On 7/6/06, Sergio Garc?a Murillo <Sergio.Garcia at ydilo.com> wrote:
>
> Hi all
>
> I have just discovered the project and I was wondering if it could support
> the ethernet over ata protocol so it could boot up from a net drive.
> AFAIK it would require a 2.6 kernel which I don't know if there are plans
> to support it soon.
> But I think it could bring some new interesting possibilities.
>
> Greetings and great job
>
> ----------------------------------------------------------------
> Sergio Garc?a Murillo
> Research & Development
> .y dilo
>     Advanced Voice Solutions
>
>
> --------------------------------------------------------------------------------------
> This message and any files transmitted with it are confidential and
> intended solely
> for the use of the individual or entity to whom they are addressed. No
> confidentiality
> or privilege is waived or lost by any wrong transmission.
> If you have received this message in error, please immediately destroy it
> and kindly
> notify the sender by reply email.
> You must not, directly or indirectly, use, disclose, distribute, print, or
> copy any
> part of this message if you are not the intended recipient. Opinions,
> conclusions and
> other information in this message that do not relate to the official
> business of
> Ydilo Advanced Voice Solutions, S.A. shall be understood as neither given
> nor endorsed by it.
>
> --------------------------------------------------------------------------------------
>
> --
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060710/7ce53c2a/attachment.html>

From drew.lundsten at ccpu.com  Tue Jul 11 01:36:40 2006
From: drew.lundsten at ccpu.com (Drew Lundsten)
Date: Mon, 10 Jul 2006 16:36:40 -0700
Subject: [LinuxBIOS] Issues facing IHVs supporting LinuxBIOS
Message-ID: <C499405203244F4F8ECC637C6A8F498B04F8EC5E@sd-exchange>

I've been lurking for a couple of months and like what I see. I am also
interested in some recent comments disparaging EFI, as well as recent
posts (apparently) from hardware vendors asking how to support LinuxBIOS
on their platforms. After reading through the FAQ again and not finding
answers to my questions, I now turn to the list:
 
1) What legal conditions, or obligations to make derived source code
available, are placed on independent hardware vendors offering LinuxBIOS
support for their hardware?
 
2) What's up with Intel, and why, for instance, can't an IHV use their
BIOS guides to support LinuxBIOS? Is it strictly a question of access
(via IBL or hardcover - "orange cover") to such guides, and IHVs with
access to these guides are free to distribute their product with
LinuxBIOS, subject to bugginess resulting from mediocre/nonexistent
Intel support?
 
2b) I see Intel's 7520 chipset is actually supported, and that's rather
recent - is this an anomaly, or the end of the line for Intel support?
 
3) Is there a list of IHVs who DO ship product on LinuxBIOS?
 
For an IHV developing embedded hardware that's just going to run Linux
unattended anyway, it seems LinuxBIOS would be a natural choice and a
tremendous cost savings; at the same time, the power profile of Intel's
new architecture is well-suited to this niche. I'm trying to figure out
why more commercial vendors aren't on this bandwagon.
 
Thanks for your input,
 
Drew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060710/17d3d5b5/attachment.html>

From rminnich at lanl.gov  Tue Jul 11 03:59:33 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 10 Jul 2006 19:59:33 -0600
Subject: [LinuxBIOS] Issues facing IHVs supporting LinuxBIOS
In-Reply-To: <C499405203244F4F8ECC637C6A8F498B04F8EC5E@sd-exchange>
References: <C499405203244F4F8ECC637C6A8F498B04F8EC5E@sd-exchange>
Message-ID: <44B30605.1090209@lanl.gov>

Drew Lundsten wrote:
> I've been lurking for a couple of months and like what I see. I am also 
> interested in some recent comments disparaging EFI, as well as recent 
> posts (apparently) from hardware vendors asking how to support LinuxBIOS 
> on their platforms. After reading through the FAQ again and not finding 
> answers to my questions, I now turn to the list:
>  
> 1) What legal conditions, or obligations to make derived source code 
> available, are placed on independent hardware vendors offering LinuxBIOS 
> support for their hardware?

GPL. That's it;

>  
> 2) What's up with Intel, and why, for instance, can't an IHV use their 
> BIOS guides to support LinuxBIOS? 


The information you need is no longer easily available. Intel has a 
stated policy (at least in meetings) that the will not support 
linuxbios, period. As to reasons, you'll have to ask them.


> 2b) I see Intel's 7520 chipset is actually supported, and that's rather 
> recent - is this an anomaly, or the end of the line for Intel support?

I have no idea.

>  
> 3) Is there a list of IHVs who DO ship product on LinuxBIOS?

not at present. There are some, they just aren't documented.

ron





From zhushisongzhu at yahoo.com  Tue Jul 11 11:43:24 2006
From: zhushisongzhu at yahoo.com (zhu shi song)
Date: Tue, 11 Jul 2006 02:43:24 -0700 (PDT)
Subject: [LinuxBIOS] how to use ramdisk as rootfs
In-Reply-To: <m31wste2qh.fsf@maxwell.lnxi.com>
Message-ID: <20060711094324.92559.qmail@web36903.mail.mud.yahoo.com>

In the past I used obsolete libc for kernel2.6. Where
can I get initrd with little footprint suitable for
kernel 2.6 diskless boot?  Now I'm testing  my old
rootfs using initrd as ramdisk rootfs.

    tks
    zhu

--- "Eric W. Biederman" <ebiederman at lnxi.com> wrote:

> Ronald G Minnich <rminnich at lanl.gov> writes:
> 
> > Richard Smith wrote:
> >>>support linux-2.6 kernel.  Can I convert my
> tar.gz
> >>>file to cpio format as initramfs and make kernel
> >>>uncompress it and mount it as rootfs on ramdisk
> >>>automatically?  I'm not so familiar with either
> initrd
> >>>or initramfs, where can I find more and clear
> info
> >>>about these topics?
> >> 
> >> 
> >> 
> >> There is a little bit of info about initramfs in
> the kernel tree.
> >> 
> >>
>
/Documentation/filesystems/ramfs-rootfs-initramfs.txt
> >> 
> >
> > I don't recommend initramfs -- just make a cpio
> initrd. Current 
> > initramfs support is bug-ridden.
> 
> To be clear a cpio format initrd is referred to as
> an initramfs.  There
> are no real implementation differences between the
> in kernel and
> initrd styles the only question is where does the
> cpio archive come
> from, and how is the cpio archive built.
> 
> Since the in kernel cpio archive builder has issues
> it does make sense
> to avoid it.
> 
> Eric
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 



From zhushisongzhu at yahoo.com  Tue Jul 11 11:44:32 2006
From: zhushisongzhu at yahoo.com (zhu shi song)
Date: Tue, 11 Jul 2006 02:44:32 -0700 (PDT)
Subject: [LinuxBIOS] how to use ramdisk as rootfs
In-Reply-To: <m31wste2qh.fsf@maxwell.lnxi.com>
Message-ID: <20060711094432.78164.qmail@web36910.mail.mud.yahoo.com>

My existing rootfs is some obsolete for kernel2.6.
Where can I get initrd with little footprint suitable
for kernel 2.6 diskless boot?  Now I'm testing  my old
rootfs using initrd as ramdisk rootfs.

    tks
    zhu

--- "Eric W. Biederman" <ebiederman at lnxi.com> wrote:

> Ronald G Minnich <rminnich at lanl.gov> writes:
> 
> > Richard Smith wrote:
> >>>support linux-2.6 kernel.  Can I convert my
> tar.gz
> >>>file to cpio format as initramfs and make kernel
> >>>uncompress it and mount it as rootfs on ramdisk
> >>>automatically?  I'm not so familiar with either
> initrd
> >>>or initramfs, where can I find more and clear
> info
> >>>about these topics?
> >> 
> >> 
> >> 
> >> There is a little bit of info about initramfs in
> the kernel tree.
> >> 
> >>
>
/Documentation/filesystems/ramfs-rootfs-initramfs.txt
> >> 
> >
> > I don't recommend initramfs -- just make a cpio
> initrd. Current 
> > initramfs support is bug-ridden.
> 
> To be clear a cpio format initrd is referred to as
> an initramfs.  There
> are no real implementation differences between the
> in kernel and
> initrd styles the only question is where does the
> cpio archive come
> from, and how is the cpio archive built.
> 
> Since the in kernel cpio archive builder has issues
> it does make sense
> to avoid it.
> 
> Eric
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 



From smithbone at gmail.com  Tue Jul 11 14:58:59 2006
From: smithbone at gmail.com (Richard Smith)
Date: Tue, 11 Jul 2006 07:58:59 -0500
Subject: [LinuxBIOS] how to use ramdisk as rootfs
In-Reply-To: <20060711094432.78164.qmail@web36910.mail.mud.yahoo.com>
References: <m31wste2qh.fsf@maxwell.lnxi.com>
	<20060711094432.78164.qmail@web36910.mail.mud.yahoo.com>
Message-ID: <8a0c36780607110558x2e5ef80bqc462d7426dbe43d5@mail.gmail.com>

On 7/11/06, zhu shi song <zhushisongzhu at yahoo.com> wrote:

> My existing rootfs is some obsolete for kernel2.6.
> Where can I get initrd with little footprint suitable
> for kernel 2.6 diskless boot?  Now I'm testing  my old
> rootfs using initrd as ramdisk rootfs.

http://buildroot.uclibc.org/


-- 
Richard A. Smith



From jheim at math.wisc.edu  Wed Jul 12 01:17:01 2006
From: jheim at math.wisc.edu (John Heim)
Date: Tue, 11 Jul 2006 18:17:01 -0500
Subject: [LinuxBIOS] mobo suggestions?
In-Reply-To: <44B2BEC1.2000404@lanl.gov>
References: <44B30262.3090100@math.wisc.edu> <44B2BEC1.2000404@lanl.gov>
Message-ID: <44B4316D.6050209@math.wisc.edu>


> we have not done desktops for a while. I wonder if an AMD GX2-based 
> system might be good for you-- how much compute power are you looking for?


Not that much. Right now my Windows machine is a a 800 Mhz machine with 
256Mb RAM. It serves me fine except that I can't access the BIOS and I 
just want to build a new PC just to do it -- you know, being blind and 
all. I thought I'd go for something fairly up-to-date but I don't want 
to spend too much money. But the point of this project is not to save 
money. I just want to build a really nice PC.


I have several linux machines but the one I use the most is a 150 Mhz 
machine. The linux screen reader works in character mode so I don't need 
much power.  But I would like to make my new machine bual-boot.





From rminnich at lanl.gov  Tue Jul 11 21:22:36 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 11 Jul 2006 13:22:36 -0600
Subject: [LinuxBIOS] mobo suggestions?
In-Reply-To: <44B4316D.6050209@math.wisc.edu>
References: <44B30262.3090100@math.wisc.edu> <44B2BEC1.2000404@lanl.gov>
	<44B4316D.6050209@math.wisc.edu>
Message-ID: <44B3FA7C.9000102@lanl.gov>

I'd go with a tyan s2885 mobo to start -- has graphics, we know that 
linuxbios can bring up 8x AGP cards on it, supported in linuxbios.

ron



From dhendrix at google.com  Tue Jul 11 22:45:27 2006
From: dhendrix at google.com (David Hendricks)
Date: Tue, 11 Jul 2006 13:45:27 -0700
Subject: [LinuxBIOS] mobo suggestions?
In-Reply-To: <44B4316D.6050209@math.wisc.edu>
References: <44B30262.3090100@math.wisc.edu> <44B2BEC1.2000404@lanl.gov>
	<44B4316D.6050209@math.wisc.edu>
Message-ID: <ec9b26620607111345p74ce42a6g26ebdd64d05a6107@mail.google.com>

Dual boot? That might be a problem. I know Windows 2000 has been booted with
LinuxBIOS, but I can't remember any Windows XP success stories.

On 7/11/06, John Heim <jheim at math.wisc.edu> wrote:
>
> I have several linux machines but the one I use the most is a 150 Mhz
> machine. The linux screen reader works in character mode so I don't need
> much power.  But I would like to make my new machine bual-boot.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060711/15c92ad2/attachment.html>

From bg.anil at gmail.com  Wed Jul 12 16:58:04 2006
From: bg.anil at gmail.com (Anil B G)
Date: Wed, 12 Jul 2006 20:28:04 +0530
Subject: [LinuxBIOS] Build issue for khepri target
Message-ID: <8b0974ca0607120758tf0dd21fj2fa979f9da18e6bc@mail.gmail.com>

 Hi,
  I am new to LinuxBIOS. I downloaded the latest snapshot of LinuxBIOSv2 and
tried building it for a couple of boards (newisys/intel etc).
I was able to build it for intel but when I tried to build it for
newisys/khepri I got the following error:

gcc -o buildrom /home/anil/LinuxBios/LinuxBIOSv2/util/buildrom/buildrom.c
./buildrom linuxbios.strip linuxbios.rom payload 0x20000 0x20000
payload (77000) + linuxbios (131072) size larger than ROM (131072) size!
make[1]: *** [linuxbios.rom] Error 1
make[1]: Leaving directory
`/home/anil/LinuxBios/LinuxBIOSv2/targets/newisys/khepri/khepri/fallback'
make: *** [fallback/linuxbios.rom] Error 1
I disabled the fallback option and then was able to get the khepri.rom whose
size was 384K. I am using the FILO as the payload.
Is the size of 384K fine? Has any one used LinuxBIOSv2 on khepri? Would
appreciate any help.
Pls. let me know if any addl. info is reqd.

The gcc version is 3.4.3

Regards
Anil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060712/7be8d06f/attachment.html>

From stepan at coresystems.de  Wed Jul 12 17:40:43 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Wed, 12 Jul 2006 17:40:43 +0200
Subject: [LinuxBIOS] [PATCH] Change payload buildrule to 'cp -f'
In-Reply-To: <8a0c36780607101145l218f4701n3389465c9f7b53ce@mail.gmail.com>
References: <8a0c36780607091541v5f6ee07dua9ff3311574abbc0@mail.gmail.com>
	<20060710110855.GA18114@coresystems.de>
	<m3ac7hofor.fsf@maxwell.lnxi.com>
	<8a0c36780607101145l218f4701n3389465c9f7b53ce@mail.gmail.com>
Message-ID: <20060712154043.GA25605@coresystems.de>

* Richard Smith <smithbone at gmail.com> [060710 20:45]:
> Stefan.  I think Eric's right and the build script needs the tweak
> regardless of the output of mkelfimage.  If the users umask is set
> restrictive then the same problem would occur.
> I noticed in the makefile that there are a few other cp's that
> probably need to be cp -f as well.
> 
> Ok to commit?

commited.

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From yinghai.lu at amd.com  Wed Jul 12 19:13:46 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Wed, 12 Jul 2006 10:13:46 -0700
Subject: [LinuxBIOS] Build issue for khepri target
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4207004075@ssvlexmb2.amd.com>

Please change FALLBACK_SIZE in MB Config.lb to 

#default FALLBACK_SIZE=0x40000    

 

YH

 

________________________________

From: linuxbios-bounces at linuxbios.org
[mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Anil B G
Sent: Wednesday, July 12, 2006 7:58 AM
To: linuxbios at linuxbios.org
Subject: [LinuxBIOS] Build issue for khepri target

 

Hi,

  I am new to LinuxBIOS. I downloaded the latest snapshot of LinuxBIOSv2
and tried building it for a couple of boards (newisys/intel etc).

I was able to build it for intel but when I tried to build it for
newisys/khepri I got the following error:

 

gcc -o buildrom
/home/anil/LinuxBios/LinuxBIOSv2/util/buildrom/buildrom.c
./buildrom linuxbios.strip linuxbios.rom payload 0x20000 0x20000
payload (77000) + linuxbios (131072) size larger than ROM (131072) size!

make[1]: *** [linuxbios.rom] Error 1
make[1]: Leaving directory
`/home/anil/LinuxBios/LinuxBIOSv2/targets/newisys/khepri/khepri/fallback
'
make: *** [fallback/linuxbios.rom] Error 1

I disabled the fallback option and then was able to get the khepri.rom
whose size was 384K. I am using the FILO as the payload.

Is the size of 384K fine? Has any one used LinuxBIOSv2 on khepri? Would
appreciate any help.

Pls. let me know if any addl. info is reqd.

 

The gcc version is 3.4.3

 

Regards

Anil

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060712/024fba3f/attachment.html>

From fourstar10_2000 at yahoo.com  Wed Jul 12 22:28:11 2006
From: fourstar10_2000 at yahoo.com (steve yannalfo)
Date: Wed, 12 Jul 2006 13:28:11 -0700 (PDT)
Subject: [LinuxBIOS] Missing Bridge Resources
Message-ID: <20060712202811.50930.qmail@web38906.mail.mud.yahoo.com>

Well, LB looks and boots well, but... I can't see my ethernet devices...

>>>>>>>>LB detects and set resources for the bridges::::

PCI: 00:01.1 cmd <- 141
PCI: 00:02.0 cmd <- 142
PCI: 00:02.1 cmd <- 142
PCI: 00:04.0 cmd <- 143
PCI: 00:04.1 cmd <- 143
PCI: 00:06.0 cmd <- 141
PCI: 00:07.0 cmd <- 143
PCI: 00:08.0 cmd <- 143
PCI: 00:09.0 bridge ctrl <- 0003
PCI: 00:09.0 cmd <- 140
PCI: 00:0a.0 cmd <- 143
PCI: 00:0b.0 bridge ctrl <- 0003
PCI: 00:0b.0 cmd <- 140
PCI: 00:0c.0 bridge ctrl <- 0003
PCI: 00:0c.0 cmd <- 140
PCI: 00:0d.0 bridge ctrl <- 0003
PCI: 00:0d.0 cmd <- 140
PCI: 00:0e.0 bridge ctrl <- 0003
PCI: 00:0e.0 cmd <- 140
PCI: 00:18.1 cmd <- 140
PCI: 00:18.2 cmd <- 140
PCI: 00:18.3 cmd <- 140
PCI: 00:19.0 cmd <- 140
PCI: 00:19.1 cmd <- 140
PCI: 00:19.2 cmd <- 140
PCI: 00:19.3 cmd <- 140
.
.
.
PCI: 00:09.0 1c <- [0x000000f000 - 0x000000efff] bus 1 io
PCI: 00:09.0 24 <- [0x00fff00000 - 0x00ffefffff] bus 1 prefmem
PCI: 00:09.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 1 mem
PCI: 00:0b.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 2 io
PCI: 00:0b.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 2 prefmem
PCI: 00:0b.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 2 mem
PCI: 00:0c.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 3 io
PCI: 00:0c.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 3 prefmem
PCI: 00:0c.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 3 mem
PCI: 00:0d.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 4 io
PCI: 00:0d.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 4 prefmem
PCI: 00:0d.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 4 mem
PCI: 00:0e.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 5 io
PCI: 00:0e.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 5 prefmem
PCI: 00:0e.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 5 mem

--------------------------------------------------------------
>>>>>>>>but Linux Doesnt see them...

PCI: Bridge: 0000:00:09.0
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:0b.0
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:0c.0
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:0d.0
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:0e.0
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: disabled.
IA32 emulation $Id: sys_ia32.c,v 1.32 2002/03/24 13:02:28 ak Exp $
Initializing Cryptographic API
io scheduler noop registered
io scheduler cfq registered
pcie_portdrv_probe->Dev[005d:10de] has invalid IRQ. Check vendor BIOS
assign_interrupt_mode Found MSI capability
pcie_portdrv_probe->Dev[005d:10de] has invalid IRQ. Check vendor BIOS
assign_interrupt_mode Found MSI capability
pcie_portdrv_probe->Dev[005d:10de] has invalid IRQ. Check vendor BIOS
assign_interrupt_mode Found MSI capability
pcie_portdrv_probe->Dev[005d:10de] has invalid IRQ. Check vendor BIOS
assign_interrupt_mode Found MSI capability
-------------------------------------------------------------------

>>>>>>>>>"lspci" sees the ethernet device..... and the bridges...

00:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev a2)
00:0a.0 Ethernet controller: nVidia Corporation CK804 Ethernet Controller (rev a3)
00:0b.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
00:0c.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
00:0d.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
00:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
----------------------------
>>>>>>>but I cant hook into ck804 ethernet device "a.0" or see devices on the other-side of the bridges.
----------------------------
Do I have to modify my resource.map?

Any Info?

Thank you.
steve.


 __________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060712/9e090229/attachment.html>

From yinghai.lu at amd.com  Thu Jul 13 00:04:47 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Wed, 12 Jul 2006 15:04:47 -0700
Subject: [LinuxBIOS] Missing Bridge Resources
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4207004080@ssvlexmb2.amd.com>

Try to disable the pcie support in your kernel...

 

YH

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060712/15c46aaa/attachment.html>

From tylerapohl at gmail.com  Thu Jul 13 07:54:47 2006
From: tylerapohl at gmail.com (Tyler Pohl)
Date: Wed, 12 Jul 2006 22:54:47 -0700
Subject: [LinuxBIOS] by linuxbios baord
Message-ID: <503ab0210607122254ra4e9bbco9c8419770d1c9cc9@mail.gmail.com>

Can someone tell me where I could buy a inexpensive motherboard with
linuxbios support.  Maybe even linuxbios preinstalled.  I wouldn't mind
giving my money to help the cause which is why i am asking.  Thank You
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060712/a6f72472/attachment.html>

From a.borisov at tesv.tmb.ru  Thu Jul 13 08:10:01 2006
From: a.borisov at tesv.tmb.ru (Anton Borisov)
Date: Thu, 13 Jul 2006 10:10:01 +0400
Subject: [LinuxBIOS] by linuxbios baord
In-Reply-To: <503ab0210607122254ra4e9bbco9c8419770d1c9cc9@mail.gmail.com>
References: <503ab0210607122254ra4e9bbco9c8419770d1c9cc9@mail.gmail.com>
Message-ID: <20060713101001.0a802cfb.a.borisov@tesv.tmb.ru>

On Wed, 12 Jul 2006 22:54:47 -0700
"Tyler Pohl" <tylerapohl at gmail.com> wrote:

> Can someone tell me where I could buy a inexpensive motherboard with
> linuxbios support.  Maybe even linuxbios preinstalled.  I wouldn't mind
> giving my money to help the cause which is why i am asking.  Thank You

	Desired CPU power?

-Anton



From uwe at hermann-uwe.de  Thu Jul 13 10:25:54 2006
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Thu, 13 Jul 2006 10:25:54 +0200
Subject: [LinuxBIOS] LinuxBIOS vs. FreeBIOS vs. OpenBIOS?
Message-ID: <20060713082554.GA22671@aragorn>

Hi,

I'm currently reading all available documentation to get into LinuxBIOS.
But I'm wondering how it's related with the other projects such as
OpenBIOS and FreeBIOS.

OpenBIOS is not a "competitor" in the strict sense, it's a layer above
LinuxBIOS as I understand it, and can be used as payload for LinuxBIOS,
right?

FreeBIOS seems pretty dead (last update 2003?). Was it an alternative
project which is now unmaintained, was it the same as LinuxBIOS (name
change), or have both projects merged?


TIA, Uwe.
-- 
Uwe Hermann 
http://www.hermann-uwe.de
http://www.it-services-uh.de  | http://www.crazy-hacks.org 
http://www.holsham-traders.de | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060713/5efe5c34/attachment.sig>

From little.martin at inode.at  Thu Jul 13 11:02:57 2006
From: little.martin at inode.at (Morly)
Date: Thu, 13 Jul 2006 11:02:57 +0200
Subject: [LinuxBIOS] Mainboard-Configuration
Message-ID: <44B60C41.5010708@inode.at>

Hello!

First, I really like the idea and the work around linuxbios.

For my PhD research in new medical solutions I need a very special
PC-configuration:
The PC must be absolutely silent and, however, be powerful.
The next point is, that the PC should use as less boot time
as possible. This is why I think about a linuxbios - compatible
board. Due the mainboard will be put in a small case, I can
just use mini- or micro atx boards. The only boards in this
size I could determine are VIA-EPIA boards. Unfortunately,
they are too slow for my applications.

For passive cooling and long battery usage  I thought about a
Turion or Sempron CPU.

So in one sentence, I am looking for an mini or micro atx
board, compatible with AMD Turion (Sempron), which
supports linuxbios.

Is there anyone who can help me?

Many thanks,
greetings,
Morly






From marcelocoelho at gmail.com  Thu Jul 13 11:20:37 2006
From: marcelocoelho at gmail.com (Marcelo Coelho)
Date: Thu, 13 Jul 2006 10:20:37 +0100
Subject: [LinuxBIOS] Mainboard-Configuration
In-Reply-To: <44B60C41.5010708@inode.at>
References: <44B60C41.5010708@inode.at>
Message-ID: <20c6f18e0607130220j23004ae8h68166346fbe70c8d@mail.gmail.com>

Actually there are a lot more cpu's available to do that. You can use
a pentium-m on such a board (there are boards mini-itx that supports
them), you can use a athlon64 low power (there are athlon64, socket
939, that consumes 35W, so just some watts more in comparison with
pentium-m) and also opteron64, socket 940, that consumes 30W.

There is also an epia board that has dual cpu instead of only one.

The support from linuxbios for these systems, has to be answered by
another guy, sorry!




2006/7/13, Morly <little.martin at inode.at>:
> Hello!
>
> First, I really like the idea and the work around linuxbios.
>
> For my PhD research in new medical solutions I need a very special
> PC-configuration:
> The PC must be absolutely silent and, however, be powerful.
> The next point is, that the PC should use as less boot time
> as possible. This is why I think about a linuxbios - compatible
> board. Due the mainboard will be put in a small case, I can
> just use mini- or micro atx boards. The only boards in this
> size I could determine are VIA-EPIA boards. Unfortunately,
> they are too slow for my applications.
>
> For passive cooling and long battery usage  I thought about a
> Turion or Sempron CPU.
>
> So in one sentence, I am looking for an mini or micro atx
> board, compatible with AMD Turion (Sempron), which
> supports linuxbios.
>
> Is there anyone who can help me?
>
> Many thanks,
> greetings,
> Morly
>
>
>
>
> --
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>



From stepan at coresystems.de  Thu Jul 13 13:40:55 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 13 Jul 2006 13:40:55 +0200
Subject: [LinuxBIOS] Mainboard-Configuration
In-Reply-To: <44B60C41.5010708@inode.at>
References: <44B60C41.5010708@inode.at>
Message-ID: <20060713114055.GA31231@coresystems.de>

* Morly <little.martin at inode.at> [060713 11:02]:
> So in one sentence, I am looking for an mini or micro atx
> board, compatible with AMD Turion (Sempron), which
> supports linuxbios.

One that comes close to what you need might be this one:

        http://www.win-ent.com/MB-06047.htm

It features an Opteron CPU and so might need some thoughts 
about passive cooling. Also it is not supported by LinuxBIOS 
yet, but probably not hard to get it to work.

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From fourstar10_2000 at yahoo.com  Thu Jul 13 16:12:59 2006
From: fourstar10_2000 at yahoo.com (steve yannalfo)
Date: Thu, 13 Jul 2006 07:12:59 -0700 (PDT)
Subject: [LinuxBIOS] Mainboard-Configuration
Message-ID: <20060713141259.29076.qmail@web38913.mail.mud.yahoo.com>

I have the configuration scripts for the win-ent mb06047. I havent got the vga working yet... but all else works good.

steve

 		
---------------------------------
Yahoo! Music Unlimited - Access over 1 million songs.Try it free. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060713/d4b416dd/attachment.html>

From fourstar10_2000 at yahoo.com  Thu Jul 13 16:15:21 2006
From: fourstar10_2000 at yahoo.com (steve yannalfo)
Date: Thu, 13 Jul 2006 07:15:21 -0700 (PDT)
Subject: [LinuxBIOS] Missing Bridge Resources
Message-ID: <20060713141521.82275.qmail@web38915.mail.mud.yahoo.com>

  Try to disable the pcie support in your kernel

YH
I tried removing pcie in kernel... same problem.
steve


 		
---------------------------------
Yahoo! Music Unlimited - Access over 1 million songs.Try it free. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060713/b56beb8e/attachment.html>

From bari at onelabs.com  Thu Jul 13 17:31:58 2006
From: bari at onelabs.com (Bari Ari)
Date: Thu, 13 Jul 2006 10:31:58 -0500
Subject: [LinuxBIOS] Mainboard-Configuration
In-Reply-To: <20060713114055.GA31231@coresystems.de>
References: <44B60C41.5010708@inode.at> <20060713114055.GA31231@coresystems.de>
Message-ID: <44B6676E.5080701@onelabs.com>

Stefan Reinauer wrote:
> It features an Opteron CPU and so might need some thoughts 
> about passive cooling. Also it is not supported by LinuxBIOS 
> yet, but probably not hard to get it to work.
It just needs an enclosure built from an AL extrusion like this:

http://www.onelabs.com/image1234.html

-Bari



From tylerapohl at gmail.com  Thu Jul 13 17:44:54 2006
From: tylerapohl at gmail.com (Tyler Pohl)
Date: Thu, 13 Jul 2006 08:44:54 -0700
Subject: [LinuxBIOS] linuxbios board
Message-ID: <503ab0210607130844h7f9508f2lc75b46bbf5d903dc@mail.gmail.com>

I am looking for a via epia board with linux bios pre installed.  I don't
care much about the speed or anything else i just want linuxbios on the
board and maybe a cf slot would be nice.

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060713/8d02d783/attachment.html>

From rminnich at lanl.gov  Thu Jul 13 17:49:02 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Thu, 13 Jul 2006 09:49:02 -0600
Subject: [LinuxBIOS] by linuxbios baord
In-Reply-To: <503ab0210607122254ra4e9bbco9c8419770d1c9cc9@mail.gmail.com>
References: <503ab0210607122254ra4e9bbco9c8419770d1c9cc9@mail.gmail.com>
Message-ID: <44B66B6E.2060203@lanl.gov>

Tyler Pohl wrote:
> Can someone tell me where I could buy a inexpensive motherboard with 
> linuxbios support.  Maybe even linuxbios preinstalled.  I wouldn't mind 
> giving my money to help the cause which is why i am asking.  Thank You
> 

I appreciate your sentiment.

cwlinux.com used to sell mobos with linuxbios installed. I have not 
talked to them for some time, however, so you would have to check.
cwlinux.com

We really need a vendor page at linuxbios.org

ron




From bari at onelabs.com  Thu Jul 13 18:41:10 2006
From: bari at onelabs.com (Bari Ari)
Date: Thu, 13 Jul 2006 11:41:10 -0500
Subject: [LinuxBIOS] by linuxbios baord
In-Reply-To: <44B66B6E.2060203@lanl.gov>
References: <503ab0210607122254ra4e9bbco9c8419770d1c9cc9@mail.gmail.com>
	<44B66B6E.2060203@lanl.gov>
Message-ID: <44B677A6.2090802@onelabs.com>

Ronald G Minnich wrote:
> We really need a vendor page at linuxbios.org
>
> ron
>   
If vendors submit links, I'll add them to the Products page at 
linuxbios.org.

-Bari



From dhendrix at google.com  Thu Jul 13 19:12:03 2006
From: dhendrix at google.com (David Hendricks)
Date: Thu, 13 Jul 2006 10:12:03 -0700
Subject: [LinuxBIOS] LinuxBIOS vs. FreeBIOS vs. OpenBIOS?
In-Reply-To: <20060713082554.GA22671@aragorn>
References: <20060713082554.GA22671@aragorn>
Message-ID: <ec9b26620607131012i187e8497oca7f3310875b6e1f@mail.google.com>

LinuxBIOSv1 and FreeBIOS shared the same source base. I think it's safe to
say that LinuxBIOSv2 is FreeBIOS's successor. OpenBIOS is a free
implementation of the Open Firmware specification and can be used as a
LinuxBIOS payload. It's not a competing project and in fact the project
maintainer, Stefan Reinauer, has long been and still is a maintainer of
LinuxBIOS.

On 7/13/06, Uwe Hermann <uwe at hermann-uwe.de > wrote:
>
> Hi,
>
> I'm currently reading all available documentation to get into LinuxBIOS.
> But I'm wondering how it's related with the other projects such as
> OpenBIOS and FreeBIOS.
>
> OpenBIOS is not a "competitor" in the strict sense, it's a layer above
> LinuxBIOS as I understand it, and can be used as payload for LinuxBIOS,
> right?
>
> FreeBIOS seems pretty dead (last update 2003?). Was it an alternative
> project which is now unmaintained, was it the same as LinuxBIOS (name
> change), or have both projects merged?
>
>
> TIA, Uwe.
> --
> Uwe Hermann
> http://www.hermann-uwe.de<http://www.google.com/url?sa=D&q=http%3A%2F%2Fwww.hermann-uwe.de>
> http://www.it-services-uh.de<http://www.google.com/url?sa=D&q=http%3A%2F%2Fwww.it-services-uh.de>  |
> http://www.crazy-hacks.org
> <http://www.google.com/url?sa=D&q=http%3A%2F%2Fwww.crazy-hacks.org>
> http://www.holsham-traders.de<http://www.google.com/url?sa=D&q=http%3A%2F%2Fwww.holsham-traders.de>|
> http://www.unmaintained-free-software.org<http://www.google.com/url?sa=D&q=http%3A%2F%2Fwww.unmaintained-free-software.org>
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (GNU/Linux)
>
> iD8DBQFEtgOSXdVoV3jWIbQRAgVQAJ4smELO6ZuhbBZUfY5JWYQBhvneJgCfbBFV
> gg89oKGcbb66Bpt2r6ImUkc=
> =vbBN
> -----END PGP SIGNATURE-----
>
>
> --
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios<http://www.google.com/url?sa=D&q=http%3A%2F%2Fwww.openbios.org%2Fmailman%2Flistinfo%2Flinuxbios>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060713/d307d123/attachment.html>

From rminnich at lanl.gov  Thu Jul 13 19:15:22 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Thu, 13 Jul 2006 11:15:22 -0600
Subject: [LinuxBIOS] Mainboard-Configuration
In-Reply-To: <20060713141259.29076.qmail@web38913.mail.mud.yahoo.com>
References: <20060713141259.29076.qmail@web38913.mail.mud.yahoo.com>
Message-ID: <44B67FAA.2040708@lanl.gov>

steve yannalfo wrote:
> I have the configuration scripts for the win-ent mb06047. I havent got 
> the vga working yet... but all else works good.
> 
> steve
> 
> ------------------------------------------------------------------------
> Yahoo! Music Unlimited - Access over 1 million songs. Try it free. 
> <http://pa.yahoo.com/*http://us.rd.yahoo.com/evt=36035/*http://music.yahoo.com/unlimited/ 
>  >
> 
please send me diffs when you are done

ron



From rminnich at gmail.com  Thu Jul 13 19:26:03 2006
From: rminnich at gmail.com (ron minnich)
Date: Thu, 13 Jul 2006 10:26:03 -0700
Subject: [LinuxBIOS] LinuxBIOS vs. FreeBIOS vs. OpenBIOS?
In-Reply-To: <ec9b26620607131012i187e8497oca7f3310875b6e1f@mail.google.com>
References: <20060713082554.GA22671@aragorn>
	<ec9b26620607131012i187e8497oca7f3310875b6e1f@mail.google.com>
Message-ID: <13426df10607131026k774514a4x50fbdb4382645485@mail.gmail.com>

One very slight corredion. The very first linuxbios, for about the first 6
months, was actually derived from openbios. Stefan wrote openbios
and it could actually boot from power on on certain platforms. We wanted to
move to a more C-based code base and Johan Rydberg offered
freebios up, after Jim Garzik pointed us at it.

So there have actually been three versions of linuxbios.
1. openbios-based (v?)
2. freebios-derived (v1)
3. fairly comprehensive rewite (v2)

There are still one or two bits of linuxbios v2 that trace back to v?, I
believe.

ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060713/3c9b7a93/attachment.html>

From uwe at hermann-uwe.de  Thu Jul 13 22:24:25 2006
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Thu, 13 Jul 2006 22:24:25 +0200
Subject: [LinuxBIOS] LinuxBIOS vs. FreeBIOS vs. OpenBIOS?
In-Reply-To: <13426df10607131026k774514a4x50fbdb4382645485@mail.gmail.com>
References: <20060713082554.GA22671@aragorn>
	<ec9b26620607131012i187e8497oca7f3310875b6e1f@mail.google.com>
	<13426df10607131026k774514a4x50fbdb4382645485@mail.gmail.com>
Message-ID: <20060713202425.GA20333@aragorn>

Hi,

On Thu, Jul 13, 2006 at 10:26:03AM -0700, ron minnich wrote:
> So there have actually been three versions of linuxbios.
> 1. openbios-based (v?)
> 2. freebios-derived (v1)
> 3. fairly comprehensive rewite (v2)

Thanks a lot for the infos.


Cheers, Uwe.
-- 
Uwe Hermann 
http://www.hermann-uwe.de
http://www.it-services-uh.de  | http://www.crazy-hacks.org 
http://www.holsham-traders.de | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060713/17663d0e/attachment.sig>

From uwe at hermann-uwe.de  Thu Jul 13 22:29:36 2006
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Thu, 13 Jul 2006 22:29:36 +0200
Subject: [LinuxBIOS] GA-6BXC support
Message-ID: <20060713202936.GB20333@aragorn>

Hi,

I have access to an old GA-6BXC motherboard
(http://www.gigabyte.com.tw/Products/Motherboard/Products_Spec.aspx?ProductID=1445)
which I'll probably use for my first steps with LinuxBIOS.

I see that FreeBIOSv1 had support for this motherboard, but not v2. Is
there some technical reason for this? I'll probably try v1 first, but
I'd like to move to v2 sooner or later. Should I get another motherboard
or can I try to port the code to v2? How much effort does that require,
usually?


Thanks, Uwe.
-- 
Uwe Hermann 
http://www.hermann-uwe.de
http://www.it-services-uh.de  | http://www.crazy-hacks.org 
http://www.holsham-traders.de | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060713/479d6c60/attachment.sig>

From tyson at irobot.com  Thu Jul 13 22:52:47 2006
From: tyson at irobot.com (Tyson Sawyer)
Date: Thu, 13 Jul 2006 16:52:47 -0400
Subject: [LinuxBIOS] GA-6BXC support
In-Reply-To: <20060713202936.GB20333@aragorn>
References: <20060713202936.GB20333@aragorn>
Message-ID: <44B6B29F.7050704@irobot.com>

Uwe Hermann wrote:
> Hi,
> 
> I have access to an old GA-6BXC motherboard
> (http://www.gigabyte.com.tw/Products/Motherboard/Products_Spec.aspx?ProductID=1445)
> which I'll probably use for my first steps with LinuxBIOS.
> 
> I see that FreeBIOSv1 had support for this motherboard, but not v2. Is
> there some technical reason for this?

The looser that did that work dropped off the planet and hasn't been 
heard from for quite some time. ;-)

> I'll probably try v1 first,

Be careful.  The ram init is hard coded to support only 2 ram 
configurations.  I don't recall what other limitations may exist.  That 
is some VERY old work from a much earlier time in LinuxBios history.

> but
> I'd like to move to v2 sooner or later. Should I get another motherboard
> or can I try to port the code to v2? How much effort does that require,
> usually?

You might be better off with v2 but using some of the v1 code as a 
reference.

Cheers!
Ty


-- 
Tyson D Sawyer                     iRobot Corporation
Lead Systems Engineer              Government & Industrial Robotics
tsawyer at irobot.com                 Robots for the Real World
781-418-3329                       http://www.irobot.com



From rminnich at lanl.gov  Thu Jul 13 22:55:57 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Thu, 13 Jul 2006 14:55:57 -0600
Subject: [LinuxBIOS] GA-6BXC support
In-Reply-To: <20060713202936.GB20333@aragorn>
References: <20060713202936.GB20333@aragorn>
Message-ID: <44B6B35D.9050407@lanl.gov>

Uwe Hermann wrote:
> Hi,
> 
> I have access to an old GA-6BXC motherboard
> (http://www.gigabyte.com.tw/Products/Motherboard/Products_Spec.aspx?ProductID=1445)
> which I'll probably use for my first steps with LinuxBIOS.
> 
> I see that FreeBIOSv1 had support for this motherboard, but not v2. Is
> there some technical reason for this? I'll probably try v1 first, but
> I'd like to move to v2 sooner or later. Should I get another motherboard
> or can I try to port the code to v2? How much effort does that require,
> usually?
> 


It probably won't be a lot, modulo the steep linuxbios V2 learning curve.

ron



From smithbone at gmail.com  Thu Jul 13 23:14:00 2006
From: smithbone at gmail.com (Richard Smith)
Date: Thu, 13 Jul 2006 16:14:00 -0500
Subject: [LinuxBIOS] GA-6BXC support
In-Reply-To: <44B6B29F.7050704@irobot.com>
References: <20060713202936.GB20333@aragorn> <44B6B29F.7050704@irobot.com>
Message-ID: <8a0c36780607131414x2f33efc3tcdc004979dea7fa@mail.gmail.com>

> The looser that did that work dropped off the planet and hasn't been
> heard from for quite some time. ;-)
>

But a 2nd looser picked it the codebase  and continued on.

> > I'll probably try v1 first,
>
> Be careful.  The ram init is hard coded to support only 2 ram
> configurations.  I don't recall what other limitations may exist.  That
> is some VERY old work from a much earlier time in LinuxBios history.

You missed all my re-work then.   I reworked the 440bx ram init code.
It _should_ work for whatever you plug in.

That was all done for the Bitworks/IMS board which was a custom board
we made but its essentially a stock 440bx reference design.  So I
suggest you start there.    Its been a _long_ while since I've looked
at the code but I'll try to help.

As for V2.. I have a set of patches that adds all the framework for
440bx into V2.  Its gets as far as trying to read the SPD. But for
some reason I get back all zeros.  We don't use any of that anymore so
I stopped working on it.

I still have the hardware though and I'd love to have to work on V2.
There are lots of 440bx boards out there. I just don't have the time.
I'll send you the patches if you want to play with them.  If you can
get ram up then the rest shoud knock out pretty quickly.

-- 
Richard A. Smith



From danmez at gmail.com  Fri Jul 14 00:17:43 2006
From: danmez at gmail.com (Dan Mezynski)
Date: Thu, 13 Jul 2006 18:17:43 -0400
Subject: [LinuxBIOS] Problem Using SimNow Simulator
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A420700404F@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A420700404F@ssvlexmb2.amd.com>
Message-ID: <7b7e71620607131517r447dd2edqb48e113c8d8f7b0@mail.gmail.com>

Thanks for the info YH, it still just loops for ever, it's stuck in crt0.s
it puts out 0x10 to port 80 then seemingly resets.

I tried the quartet board, it does better, it gets well into hardwaremain(),
but it does not display anything to the console.  It seems that text should
be visable(the printk messages) after it calls console_init(), is this
correct?

But there are different versions of console.c, console_init(), which one is
used for AMD?  How do I get the printk text to be visable?

Thanks!
--Dan


On 7/6/06, Lu, Yinghai <yinghai.lu at amd.com> wrote:
>
>
>    1. after your build you image, please find the crt0.s in the
>    fallback dir.
>    2. No.
>
>
>
> YH
>
>
>  ------------------------------
>
> *From:* Dan Mezynski [mailto:danmez at gmail.com]
> *Sent:* Thursday, July 06, 2006 3:21 PM
> *To:* Lu, Yinghai
> *Cc:* linuxbios at linuxbios.org
> *Subject:* Re: [LinuxBIOS] Problem Using SimNow Simulator
>
>
>
> It's nice to hear you have used SimNow to run LinuxBios on cheetah.
>
> I guess my message title was a bit miss leading, I'm not having problems
> with SimNow itself.  In Fact I can run the AMI bios, single step thru it and
> even boot Fedora Core 5 linux on the simulated Serenade board in SimNow.
> The trouble is when I try to run the LinuxBios that I compiled, since this
> serenade board already exists in the LinuxBios configs, I would have thought
> I could select it(thru buildtarget) and it would work, but I must have
> missed something in the basic build procedure.
>
> I'll try to ask a couple clear questions:
> *  Are the first few instructions executed after a reset(hard or soft) in
> the source file s_start.S?
> *  Do I need to explicitly do something to configure for VGA
> initializations, or is that done since I'm using this existing serenade
> setup?
>
> On 7/6/06, *Lu, Yinghai* <yinghai.lu at amd.com> wrote:
>
> I have tried LinuxBIOS with Serengeti_cheetah ( rev F Opteron) on SimNow,
> and it works well.
>
>
>
> I will try that with Serengeti_leopard later?
>
>
>
> YH
>
>
>  ------------------------------
>
> *From:* linuxbios-bounces at linuxbios.org [mailto:
> linuxbios-bounces at linuxbios.org] *On Behalf Of *Dan Mezynski
> *Sent:* Thursday, July 06, 2006 9:12 AM
> *To:* linuxbios at linuxbios.org
> *Subject:* [LinuxBIOS] Problem Using SimNow Simulator
>
>
>
>
>
> I'm trying to get started with LinuxBios by using the AMD SimNow hardware
> simulator to run LinuxBios on a Serenade board. Once we have success with
> simulations, we will try it on real hardware.  The Serenade board is one
> of the standard predefined boards that comes with the simulator. Once I
> compile
> serenade.rom and reference this file as the rom device connected to the
> 8111(replacing the AMI BIOS file), I reboot but don't get too far into the
> new
> Linuxbios, I expected to see recognizable postcodes, such as 0x13 from
> c_start.S then 0x80, 0x39, 0x40 etc from hardwaremain(), but port 80 only
> toggles
> between 00 and 0x10. I try to single step from 0xfffffff0 (or 0xfffbfff0)
> but
> dont see code that looks like c_start.S. Does something come before this?
>
> I must have built serenade.rom improperly: I did the following,
> buildtarget amd/serenade
> doneloaded filo.elf
> edited serenade/Config.lb to refer to the filo.elf as a payload
> make
>
> Any ideas would be appreciated.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060713/533f28f5/attachment.html>

From a.borisov at tesv.tmb.ru  Fri Jul 14 07:09:05 2006
From: a.borisov at tesv.tmb.ru (Anton Borisov)
Date: Fri, 14 Jul 2006 09:09:05 +0400
Subject: [LinuxBIOS] linuxbios board
In-Reply-To: <503ab0210607130844h7f9508f2lc75b46bbf5d903dc@mail.gmail.com>
References: <503ab0210607130844h7f9508f2lc75b46bbf5d903dc@mail.gmail.com>
Message-ID: <20060714090905.483f8221.a.borisov@tesv.tmb.ru>

On Thu, 13 Jul 2006 08:44:54 -0700
"Tyler Pohl" <tylerapohl at gmail.com> wrote:

> I am looking for a via epia board with linux bios pre installed.  I don't
> care much about the speed or anything else i just want linuxbios on the
> board and maybe a cf slot would be nice.

	There were discussions about EPIA-M, -MII, -MS quite recently (for a period of 6 months). In 99% of all cases these boards ought to work.

-Anton



From rohit.venkatachalam at wipro.com  Fri Jul 14 12:50:23 2006
From: rohit.venkatachalam at wipro.com (rohit.venkatachalam at wipro.com)
Date: Fri, 14 Jul 2006 16:20:23 +0530
Subject: [LinuxBIOS] Build problem
Message-ID: <ACECBCCF77262F48BAAE49E651BE88840122F412@blr-m3-msg.wipro.com>


Hi I am new to LinuxBIOS. I am using LinuxBIOSv2 .I am trying to build a
rom image for the khepri board from newisys. I do the following for the
build -


#cd LinuxBIOSv2/targets/
#./buildtarget newisys/khepri
#cd newisys/khepri/khepri
#make

I get the following error -

linuxbios_ram.o(.text+0x853c): In function `start_cpu':
: undefined reference to `_secondary_start'
collect2: ld returned 1 exit status
make[1]: *** [linuxbios_ram] Error 1

I am using gnu gcc 3.4.3

Can someone help me with this ASAP?

Rohit.






The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.

WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.

www.wipro.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060714/1e1ba5d2/attachment.html>

From little.martin at inode.at  Fri Jul 14 14:17:54 2006
From: little.martin at inode.at (Morly)
Date: Fri, 14 Jul 2006 14:17:54 +0200
Subject: [LinuxBIOS] Mainboard-Configuration
In-Reply-To: <20060713114055.GA31231@coresystems.de>
References: <44B60C41.5010708@inode.at> <20060713114055.GA31231@coresystems.de>
Message-ID: <44B78B72.40401@inode.at>

Sounds really good,
unfortunately I need at least one PCI Slot,
one serial port, usb 2.0, and maybe one parallel port
(could be realized with an usb-parallel adabter)
The mb-06047 only has one pci-express

Any other suggestions?

Thanks,
Morly

Stefan Reinauer wrote:
> * Morly <little.martin at inode.at> [060713 11:02]:
>   
>> So in one sentence, I am looking for an mini or micro atx
>> board, compatible with AMD Turion (Sempron), which
>> supports linuxbios.
>>     
>
> One that comes close to what you need might be this one:
>
>         http://www.win-ent.com/MB-06047.htm
>
> It features an Opteron CPU and so might need some thoughts 
> about passive cooling. Also it is not supported by LinuxBIOS 
> yet, but probably not hard to get it to work.
>
> Stefan
>
>   



From bg.anil at gmail.com  Fri Jul 14 17:14:37 2006
From: bg.anil at gmail.com (Anil B G)
Date: Fri, 14 Jul 2006 20:44:37 +0530
Subject: [LinuxBIOS] Build issue for khepri target
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4207004075@ssvlexmb2.amd.com>
References: <AcalxONaajaZDNAYRC67LCCtPUYeyAAEXUJQ>
	<6F7DA19D05F3CF40B890C7CA2DB13A4207004075@ssvlexmb2.amd.com>
Message-ID: <8b0974ca0607140814w7fc97eecvebc70be685aff30b@mail.gmail.com>

  Hi,

Thanks for the help. I changed the option FALLBACK_SIZE=262144 in the
targets/newisys/khepri/Config.lb and I was able to build the khepri.rom file
of size 512K. Would be nice to document the same somewhere.

I also managed to try loading the same on a khepri board that I could lay my
hands on.
However the system did not boot . Is there a way to enable some beep() or
something similar early on to know that the
processor has started executing the LinuxBIOS code. I do not have a scope or
other hardware that I could use to probe.
There was some output on the serial but that from the service processor that
my khepri board has.
 Any pointers?

 Regards
Anil


On 7/12/06, Lu, Yinghai <yinghai.lu at amd.com> wrote:
>
>   Please change FALLBACK_SIZE in MB Config.lb <http://config.lb/> to
>
> #default FALLBACK_SIZE=0x40000
>
>
>
> YH
>
>
>  ------------------------------
>
> *From:* linuxbios-bounces at linuxbios.org [mailto:
> linuxbios-bounces at linuxbios.org] *On Behalf Of *Anil B G
> *Sent:* Wednesday, July 12, 2006 7:58 AM
> *To:* linuxbios at linuxbios.org
> *Subject:* [LinuxBIOS] Build issue for khepri target
>
>
>
> Hi,
>
>   I am new to LinuxBIOS. I downloaded the latest snapshot of LinuxBIOSv2
> and tried building it for a couple of boards (newisys/intel etc).
>
> I was able to build it for intel but when I tried to build it for
> newisys/khepri I got the following error:
>
>
>
> gcc -o buildrom /home/anil/LinuxBios/LinuxBIOSv2/util/buildrom/buildrom.c
> ./buildrom linuxbios.strip linuxbios.rom payload 0x20000 0x20000
> payload (77000) + linuxbios (131072) size larger than ROM (131072) size!
> make[1]: *** [linuxbios.rom] Error 1
> make[1]: Leaving directory
> `/home/anil/LinuxBios/LinuxBIOSv2/targets/newisys/khepri/khepri/fallback'
> make: *** [fallback/linuxbios.rom] Error 1
>
> I disabled the fallback option and then was able to get the khepri.romwhose size was 384K. I am using the FILO as the payload.
>
> Is the size of 384K fine? Has any one used LinuxBIOSv2 on khepri? Would
> appreciate any help.
>
> Pls. let me know if any addl. info is reqd.
>
>
>
> The gcc version is 3.4.3
>
>
>
> Regards
>
> Anil
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060714/9f458333/attachment.html>

From smithbone at gmail.com  Fri Jul 14 17:19:30 2006
From: smithbone at gmail.com (Richard Smith)
Date: Fri, 14 Jul 2006 10:19:30 -0500
Subject: [LinuxBIOS] Build problem
In-Reply-To: <ACECBCCF77262F48BAAE49E651BE88840122F412@blr-m3-msg.wipro.com>
References: <ACECBCCF77262F48BAAE49E651BE88840122F412@blr-m3-msg.wipro.com>
Message-ID: <8a0c36780607140819n43593bb5y74c4879ea0b6c29c@mail.gmail.com>

>
> Hi I am new to LinuxBIOS. I am using LinuxBIOSv2 .I am trying to build a rom

Welcome.

>
> #cd LinuxBIOSv2/targets/
> #./buildtarget newisys/khepri
> #cd newisys/khepri/khepri
> #make
>
> I get the following error -
>
> linuxbios_ram.o(.text+0x853c): In function `start_cpu':
> : undefined reference to `_secondary_start'
> collect2: ld returned 1 exit status
> make[1]: *** [linuxbios_ram] Error 1
>

I don't have your hardware but I just tried the build and it worked
fine for me.  I got all the way to the payload error which is the last
step.

#define DISCLAMER_I_AM_NOT_AN_SMP_EXPERT

_secondary_start looks to me to be code that will start up the other
cpus in SMP.  Its assmembly that lives
'src/cpu/x86/lapic/secondary.S'.

'src/cpu/x86/lapic/lapic_cpu_init.c' copies that code into a area below 1M.

Unless this is your truly first attempt to build this then you should
do is a fresh check out into a new directory and re-try.  I've had
buildproblems with unresolved symbols in the past that were fixed by
clean checkouts.  The linuxbios build system is pretty complex and
sometimes it can get confused.

If you still have the problem after that then save the build info to a
file and grep through it looking for where secondary.S is assembled
and make sure it's making it into your linker statements.

-- 
Richard A. Smith



From rminnich at lanl.gov  Fri Jul 14 17:35:55 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Fri, 14 Jul 2006 09:35:55 -0600
Subject: [LinuxBIOS] Build issue for khepri target
In-Reply-To: <8b0974ca0607140814w7fc97eecvebc70be685aff30b@mail.gmail.com>
References: <AcalxONaajaZDNAYRC67LCCtPUYeyAAEXUJQ>	<6F7DA19D05F3CF40B890C7CA2DB13A4207004075@ssvlexmb2.amd.com>
	<8b0974ca0607140814w7fc97eecvebc70be685aff30b@mail.gmail.com>
Message-ID: <44B7B9DB.5030400@lanl.gov>

Anil B G wrote:
> Hi,
>  
> Thanks for the help. I changed the option FALLBACK_SIZE=262144 in the 
> targets/newisys/khepri/Config.lb and I was able to build the khepri.rom 
> file  of size 512K. Would be nice to document the same somewhere. 
>  

yes. It's an obsolete mobo, and what I'd rather start doing is culling 
the old non-available mobos from the tree at some point. How do we do this?

It's been over 2 years since I worked with these boards (I did not like 
them at all),  so my memory on how to use it is very shady.

thanks

ron



From yinghai.lu at amd.com  Fri Jul 14 18:19:33 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Fri, 14 Jul 2006 09:19:33 -0700
Subject: [LinuxBIOS] Build issue for khepri target
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A420700408D@ssvlexmb2.amd.com>

Did you connect serial console? You should get some sth from the serial
port.

 

YH

 

________________________________

From: Anil B G [mailto:bg.anil at gmail.com] 
Sent: Friday, July 14, 2006 8:15 AM
To: Lu, Yinghai
Cc: linuxbios at linuxbios.org
Subject: Re: [LinuxBIOS] Build issue for khepri target

 

Hi,

 

Thanks for the help. I changed the option FALLBACK_SIZE=262144 in the
targets/newisys/khepri/Config.lb and I was able to build the khepri.rom
file  of size 512K. Would be nice to document the same somewhere.  

 

I also managed to try loading the same on a khepri board that I could
lay my hands on. 

However the system did not boot . Is there a way to enable some beep()
or something similar early on to know that the 

processor has started executing the LinuxBIOS code. I do not have a
scope or other hardware that I could use to probe.

There was some output on the serial but that from the service processor
that my khepri board has.

 Any pointers?

 

Regards

Anil

 

On 7/12/06, Lu, Yinghai <yinghai.lu at amd.com> wrote: 

Please change FALLBACK_SIZE in MB Config.lb <http://config.lb/>  to 

#default FALLBACK_SIZE=0x40000    

 

YH

 

________________________________

From: linuxbios-bounces at linuxbios.org
[mailto:linuxbios-bounces at linuxbios.org ] On Behalf Of Anil B G
Sent: Wednesday, July 12, 2006 7:58 AM
To: linuxbios at linuxbios.org
Subject: [LinuxBIOS] Build issue for khepri target

 

Hi,

  I am new to LinuxBIOS. I downloaded the latest snapshot of LinuxBIOSv2
and tried building it for a couple of boards (newisys/intel etc). 

I was able to build it for intel but when I tried to build it for
newisys/khepri I got the following error:

 

gcc -o buildrom
/home/anil/LinuxBios/LinuxBIOSv2/util/buildrom/buildrom.c
./buildrom linuxbios.strip linuxbios.rom payload 0x20000 0x20000 
payload (77000) + linuxbios (131072) size larger than ROM (131072) size!

make[1]: *** [linuxbios.rom] Error 1
make[1]: Leaving directory
`/home/anil/LinuxBios/LinuxBIOSv2/targets/newisys/khepri/khepri/fallback
' 
make: *** [fallback/linuxbios.rom] Error 1

I disabled the fallback option and then was able to get the khepri.rom
whose size was 384K. I am using the FILO as the payload. 

Is the size of 384K fine? Has any one used LinuxBIOSv2 on khepri? Would
appreciate any help.

Pls. let me know if any addl. info is reqd.

 

The gcc version is 3.4.3

 

Regards

Anil

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060714/4ee5c420/attachment.html>

From smithbone at gmail.com  Fri Jul 14 18:23:46 2006
From: smithbone at gmail.com (Richard Smith)
Date: Fri, 14 Jul 2006 11:23:46 -0500
Subject: [LinuxBIOS] Build issue for khepri target
In-Reply-To: <44B7B9DB.5030400@lanl.gov>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4207004075@ssvlexmb2.amd.com>
	<8b0974ca0607140814w7fc97eecvebc70be685aff30b@mail.gmail.com>
	<44B7B9DB.5030400@lanl.gov>
Message-ID: <8a0c36780607140923s61c5f146qfe8d6ffda5cb6207@mail.gmail.com>

>
> yes. It's an obsolete mobo, and what I'd rather start doing is culling
> the old non-available mobos from the tree at some point. How do we do this?
>
> It's been over 2 years since I worked with these boards (I did not like
> them at all),  so my memory on how to use it is very shady.

I think thats a mistake.  These are the motherboards that are going to
start showing up on e-bay and other surplus channels. That puts them
in the realm of the home hobbiest and students who want to mess with
this.   Remember that just yesterday got a question about V2 support
for a 440bx board.

Perhaps we can just re-organize the targets tree to indicate whats
current and not current?

-- 
Richard A. Smith



From uwe at hermann-uwe.de  Fri Jul 14 18:25:59 2006
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Fri, 14 Jul 2006 18:25:59 +0200
Subject: [LinuxBIOS] Build issue for khepri target
In-Reply-To: <44B7B9DB.5030400@lanl.gov>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4207004075@ssvlexmb2.amd.com>
	<8b0974ca0607140814w7fc97eecvebc70be685aff30b@mail.gmail.com>
	<44B7B9DB.5030400@lanl.gov>
Message-ID: <20060714162559.GA27862@aragorn>

Hi,

On Fri, Jul 14, 2006 at 09:35:55AM -0600, Ronald G Minnich wrote:
> yes. It's an obsolete mobo, and what I'd rather start doing is culling 
> the old non-available mobos from the tree at some point. How do we do this?

Pleas don't. Such "obsolete" hardware is often used to test stuff,
e.g. to get started with LinuxBIOS without investing too
much money or risking breaking "good" hardware.

Mark them as "old" or "deprecated" or something, but please leave the
support for such hardware in the code.


Thanks, Uwe.
-- 
Uwe Hermann 
http://www.hermann-uwe.de
http://www.it-services-uh.de  | http://www.crazy-hacks.org 
http://www.holsham-traders.de | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060714/e63a4654/attachment.sig>

From rminnich at lanl.gov  Fri Jul 14 18:33:15 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Fri, 14 Jul 2006 10:33:15 -0600
Subject: [LinuxBIOS] Build issue for khepri target
In-Reply-To: <8a0c36780607140923s61c5f146qfe8d6ffda5cb6207@mail.gmail.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4207004075@ssvlexmb2.amd.com>	
	<8b0974ca0607140814w7fc97eecvebc70be685aff30b@mail.gmail.com>	
	<44B7B9DB.5030400@lanl.gov>
	<8a0c36780607140923s61c5f146qfe8d6ffda5cb6207@mail.gmail.com>
Message-ID: <44B7C74B.30506@lanl.gov>

Richard Smith wrote:
>>
>> yes. It's an obsolete mobo, and what I'd rather start doing is culling
>> the old non-available mobos from the tree at some point. How do we do 
>> this?
>>
>> It's been over 2 years since I worked with these boards (I did not like
>> them at all),  so my memory on how to use it is very shady.
> 
> 
> I think thats a mistake.  These are the motherboards that are going to
> start showing up on e-bay and other surplus channels. That puts them
> in the realm of the home hobbiest and students who want to mess with
> this.   Remember that just yesterday got a question about V2 support
> for a 440bx board.
> 
> Perhaps we can just re-organize the targets tree to indicate whats
> current and not current?
> 

I guess we'll just leave it as is.

you make a good point.

ron



From stepan at coresystems.de  Fri Jul 14 18:54:35 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Fri, 14 Jul 2006 18:54:35 +0200
Subject: [LinuxBIOS] Build issue for khepri target
In-Reply-To: <8b0974ca0607140814w7fc97eecvebc70be685aff30b@mail.gmail.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4207004075@ssvlexmb2.amd.com>
	<8b0974ca0607140814w7fc97eecvebc70be685aff30b@mail.gmail.com>
Message-ID: <20060714165435.GC6933@coresystems.de>

* Anil B G <bg.anil at gmail.com> [060714 17:14]:
> I also managed to try loading the same on a khepri board that I could lay my
> hands on.
> However the system did not boot . Is there a way to enable some beep() or
> something similar early on to know that the
> processor has started executing the LinuxBIOS code. I do not have a scope or
> other hardware that I could use to probe.
> There was some output on the serial but that from the service
> processor that my khepri board has.

The Sun Fire V20z AKA Newisys 2100 AKA Newisys Khepri has a very nice
PPC based service processor that can grab the serial output as well as
the port80 post code.

Type "platform" after logging in to the service CPU with ssh.

There's also a trick to become root on the SP itself. If you put the
machine serial port to be grabbed by the SP, the SP serial port will be
sent to the physical serial connector and you get a ppcboot screen..

Unfortunately the Newisys 2100 I have is running linuxbios.org now, so 
I dont really dare reflashing it remotely. ;-)

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From yinghai.lu at amd.com  Fri Jul 14 23:50:22 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Fri, 14 Jul 2006 14:50:22 -0700
Subject: [LinuxBIOS] ADLO
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4207004093@ssvlexmb2.amd.com>

I clean the ADLO for LBv2. (we don't need VGA rom, and pirqtable etc.
LinuxBIOS already have that)

but got unknown device for HD.

Can test that in your platform?

Later 
1. we can put acpi tables and irqtables at [0xf9000, 0xfcc00), let
loader.s not to overwrite that. ( need to update tables.c, and loader.s)
2. prepare the e820 table and put that on some positon at [0xf9000,
0xfcc00) for bochs. ( need to update linuxbios_table.c)

Thanks

Yinghai Lu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ADLO.tar.bz2
Type: application/octet-stream
Size: 69952 bytes
Desc: ADLO.tar.bz2
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060714/b5773b1f/attachment.obj>

From smithbone at gmail.com  Sat Jul 15 00:14:08 2006
From: smithbone at gmail.com (Richard Smith)
Date: Fri, 14 Jul 2006 17:14:08 -0500
Subject: [LinuxBIOS] ADLO
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4207004093@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4207004093@ssvlexmb2.amd.com>
Message-ID: <8a0c36780607141514n7f37685m1bbd999601a02bdc@mail.gmail.com>

On 7/14/06, Lu, Yinghai <yinghai.lu at amd.com> wrote:

> I clean the ADLO for LBv2. (we don't need VGA rom, and pirqtable etc.
> LinuxBIOS already have that)

Woah.  It lives.  real_mode will never die. *grin*

> but got unknown device for HD.
>
> Can test that in your platform?
>

Will do.

-- 
Richard A. Smith



From bg.anil at gmail.com  Mon Jul 17 05:34:18 2006
From: bg.anil at gmail.com (Anil B G)
Date: Mon, 17 Jul 2006 09:04:18 +0530
Subject: [LinuxBIOS] Build issue for khepri target
In-Reply-To: <20060714165435.GC6933@coresystems.de>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4207004075@ssvlexmb2.amd.com>
	<8b0974ca0607140814w7fc97eecvebc70be685aff30b@mail.gmail.com>
	<20060714165435.GC6933@coresystems.de>
Message-ID: <8b0974ca0607162034i546a394en34acd4e12d372f2a@mail.gmail.com>

Hi,
  Thanks for the response. But my concern is how do I get output of
LinuxBIOS on the serial. Can I disable the service processor output by doing
a platform after logging into the SP?
I am not sure if the LinuxBIOS code itself is running. Is there a way to
confirm that, other than checking the serial?

Regards
Anil

On 7/14/06, Stefan Reinauer <stepan at coresystems.de> wrote:
>
> * Anil B G <bg.anil at gmail.com> [060714 17:14]:
> > I also managed to try loading the same on a khepri board that I could
> lay my
> > hands on.
> > However the system did not boot . Is there a way to enable some beep()
> or
> > something similar early on to know that the
> > processor has started executing the LinuxBIOS code. I do not have a
> scope or
> > other hardware that I could use to probe.
> > There was some output on the serial but that from the service
> > processor that my khepri board has.
>
> The Sun Fire V20z AKA Newisys 2100 AKA Newisys Khepri has a very nice
> PPC based service processor that can grab the serial output as well as
> the port80 post code.
>
> Type "platform" after logging in to the service CPU with ssh.
>
> There's also a trick to become root on the SP itself. If you put the
> machine serial port to be grabbed by the SP, the SP serial port will be
> sent to the physical serial connector and you get a ppcboot screen..
>
> Unfortunately the Newisys 2100 I have is running linuxbios.org now, so
> I dont really dare reflashing it remotely. ;-)
>
> Stefan
>
> --
> coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
>      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
> Email: info at coresystems.de  ? http://www.coresystems.de/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060717/75a3f3eb/attachment.html>

From stepan at coresystems.de  Mon Jul 17 10:36:17 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 17 Jul 2006 10:36:17 +0200
Subject: [LinuxBIOS] Build issue for khepri target
In-Reply-To: <8b0974ca0607162034i546a394en34acd4e12d372f2a@mail.gmail.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4207004075@ssvlexmb2.amd.com>
	<8b0974ca0607140814w7fc97eecvebc70be685aff30b@mail.gmail.com>
	<20060714165435.GC6933@coresystems.de>
	<8b0974ca0607162034i546a394en34acd4e12d372f2a@mail.gmail.com>
Message-ID: <20060717083617.GA9498@coresystems.de>

* Anil B G <bg.anil at gmail.com> [060717 05:34]:
> Hi,
>   Thanks for the response. But my concern is how do I get output of LinuxBIOS
> on the serial. Can I disable the service processor output by doing a platform
> after logging into the SP?

do you get service processor output on the serial interface at all?

Please refer to the manual of the service processor

> I am not sure if the LinuxBIOS code itself is running. Is there a way to
> confirm that, other than checking the serial?
 
Whats wrong with checking the serial [output|connection|whatever]?


Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From bg.anil at gmail.com  Mon Jul 17 17:07:47 2006
From: bg.anil at gmail.com (Anil B G)
Date: Mon, 17 Jul 2006 20:37:47 +0530
Subject: [LinuxBIOS] Build issue for khepri target
In-Reply-To: <20060717083617.GA9498@coresystems.de>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4207004075@ssvlexmb2.amd.com>
	<8b0974ca0607140814w7fc97eecvebc70be685aff30b@mail.gmail.com>
	<20060714165435.GC6933@coresystems.de>
	<8b0974ca0607162034i546a394en34acd4e12d372f2a@mail.gmail.com>
	<20060717083617.GA9498@coresystems.de>
Message-ID: <8b0974ca0607170807k71203399k2bf6b07c741deaa2@mail.gmail.com>

Hi,
  I only get the output of the SP on the serial interface.
Regards
Anil


On 7/17/06, Stefan Reinauer <stepan at coresystems.de> wrote:
>
> * Anil B G <bg.anil at gmail.com> [060717 05:34]:
> > Hi,
> >   Thanks for the response. But my concern is how do I get output of
> LinuxBIOS
> > on the serial. Can I disable the service processor output by doing a
> platform
> > after logging into the SP?
>
> do you get service processor output on the serial interface at all?
>
> Please refer to the manual of the service processor
>
> > I am not sure if the LinuxBIOS code itself is running. Is there a way to
> > confirm that, other than checking the serial?
>
> Whats wrong with checking the serial [output|connection|whatever]?
>
>
> Stefan
>
> --
> coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
>      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
> Email: info at coresystems.de  ? http://www.coresystems.de/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060717/ad439559/attachment.html>

From stepan at coresystems.de  Mon Jul 17 18:17:53 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 17 Jul 2006 18:17:53 +0200
Subject: [LinuxBIOS] Build issue for khepri target
In-Reply-To: <8b0974ca0607170807k71203399k2bf6b07c741deaa2@mail.gmail.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4207004075@ssvlexmb2.amd.com>
	<8b0974ca0607140814w7fc97eecvebc70be685aff30b@mail.gmail.com>
	<20060714165435.GC6933@coresystems.de>
	<8b0974ca0607162034i546a394en34acd4e12d372f2a@mail.gmail.com>
	<20060717083617.GA9498@coresystems.de>
	<8b0974ca0607170807k71203399k2bf6b07c741deaa2@mail.gmail.com>
Message-ID: <20060717161753.GA20551@coresystems.de>

* Anil B G <bg.anil at gmail.com> [060717 17:07]:
> Hi,
>   I only get the output of the SP on the serial interface.

log in to the sp and do "platform console"


-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From info at coresystems.de  Tue Jul 18 19:29:55 2006
From: info at coresystems.de (LinuxBIOS information)
Date: Tue, 18 Jul 2006 19:29:55 +0200
Subject: [LinuxBIOS] LinuxBIOS r2338 build changes
Message-ID: <E1G2tON-0006qx-Uj@khepri.openbios.org>

Dear LinuxBIOS readers!

This is the automated build check service of LinuxBIOS.

The developer "stepan" checked in revision 2338 to
the LinuxBIOS source repository and caused the following 
changes:

Change Log:
sorry for the inconvenience. this is a test commit.breaking a build is intentional. It will be fixed in a bit.

Build Log:
 Compilation of agami:aruma has been broken

If something broke during this checkin please be a pain 
in stepan's neck until the issue is fixed.

If this issue is not fixed within 24h the revision will 
be backed out.

   Yours truely,
     LinuxBIOS automatic build system





From stepan at coresystems.de  Tue Jul 18 20:38:03 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Tue, 18 Jul 2006 20:38:03 +0200
Subject: [LinuxBIOS] Build issue for khepri target
In-Reply-To: <8b0974ca0607181014k5edfa49dmccedbf0bb37b1157@mail.gmail.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4207004075@ssvlexmb2.amd.com>
	<8b0974ca0607140814w7fc97eecvebc70be685aff30b@mail.gmail.com>
	<20060714165435.GC6933@coresystems.de>
	<8b0974ca0607162034i546a394en34acd4e12d372f2a@mail.gmail.com>
	<20060717083617.GA9498@coresystems.de>
	<8b0974ca0607170807k71203399k2bf6b07c741deaa2@mail.gmail.com>
	<20060717161753.GA20551@coresystems.de>
	<8b0974ca0607181014k5edfa49dmccedbf0bb37b1157@mail.gmail.com>
Message-ID: <20060718183803.GA9579@coresystems.de>


what does "platform get console" tell you? 

It should say something like:
$ platform get console
Rear Panel Enabled Speed Pruning Log Trigger
SP Console Yes     19200 No      244 KB
^^^^^^^^^^^^^^^^^^

You need to configure the
console on the SP with the "platform set console" command.

platform set console {--serial|-s} sp [{{--enable|-e}|{--disable|-d}}] [{{--prune|-p}|{--noprune|-n}}]
         [{--speed|-S} {1200|2400|4800|9600|19200|38400|57600|115200}] [{--log|-l} size] [{-h|--help}]
 or
platform set console {--serial|-s} platform [{-h|--help}]
{-S|--speed} {1200|2400|4800|9600|19200|38400|57600|115200}
                    Select the port speed for the platform console.
                    BIOS, the platform OS and the console must
                    all be configured for the same speed
                    Cannot be used with: -s=platform

{-d|--disable}      Indicate that the platform console monitor is
                    inactive
                    Cannot be used with: -e -s=platform

{-e|--enable}       Indicate that the platform console monitor is active
                    Cannot be used with: -d -s=platform

{-p|--prune}        Indicate that the platform console log is to be
                    cleaned of ANSI sequences and pruned of
                    duplicated information
                    Cannot be used with: -n -s=platform

{-s|--serial} {sp|platform}
                    Specify whether the serial port is connected to the
                    platform COMA port, or the SP serial console
                    Cannot be used with: -e [platform] -d [platform] -p
                    [platform] -n [platform] -S [platform] -l [platform]


* Anil B G <bg.anil at gmail.com> [060718 19:14]:
> Hi Stefan,
>   I logged into the SP and tried platform console etc. but I was not really
> sure how that would help me.
> That would only change the settings of the Linux thats loaded and on a reboot
> the PPCboot would again spew messages on the serial.
> I guess I am missing something here, but cannot really visualise how to get the
> output of LinuxBIOS on the serial.
> One way perhaps would be to disable the SP at the hardware level (if that is
> possible).
>  
> Please let me know if it is possible to disable serial by trying "platform
> console" on the SP.
>  
> Regards
> Anil
> 
>  
> On 7/17/06, Stefan Reinauer <stepan at coresystems.de> wrote:
> 
>     * Anil B G <bg.anil at gmail.com> [060717 17:07]:
>     > Hi,
>     >   I only get the output of the SP on the serial interface.
> 
>     log in to the sp and do "platform console"
> 
> 
>     --
>     coresystems GmbH   Brahmsstr. 16   D-79104 Freiburg i. Br.
>          Tel.: +49 761 7668825   Fax: +49 761 7664613
>     Email: info at coresystems.de    http://www.coresystems.de/
> 
> 

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From info at coresystems.de  Tue Jul 18 20:45:59 2006
From: info at coresystems.de (LinuxBIOS information)
Date: Tue, 18 Jul 2006 20:45:59 +0200
Subject: [LinuxBIOS] LinuxBIOS r2339 build changes
Message-ID: <E1G2uZz-0007iH-Qn@khepri.openbios.org>

Dear LinuxBIOS readers!

This is the automated build check service of LinuxBIOS.

The developer "stepan" checked in revision 2339 to
the LinuxBIOS source repository and caused the following 
changes:

Change Log:
fixing aruma build as suggested by mail ;-)

Build Log:
 Compilation of agami:aruma has been fixed.

If something broke during this checkin please be a pain 
in stepan's neck until the issue is fixed.

If this issue is not fixed within 24h the revision will 
be backed out.

   Yours truely,
     LinuxBIOS automatic build system





From bg.anil at gmail.com  Wed Jul 19 18:02:49 2006
From: bg.anil at gmail.com (Anil B G)
Date: Wed, 19 Jul 2006 21:32:49 +0530
Subject: [LinuxBIOS] Build issue for khepri target
In-Reply-To: <20060718183803.GA9579@coresystems.de>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4207004075@ssvlexmb2.amd.com>
	<8b0974ca0607140814w7fc97eecvebc70be685aff30b@mail.gmail.com>
	<20060714165435.GC6933@coresystems.de>
	<8b0974ca0607162034i546a394en34acd4e12d372f2a@mail.gmail.com>
	<20060717083617.GA9498@coresystems.de>
	<8b0974ca0607170807k71203399k2bf6b07c741deaa2@mail.gmail.com>
	<20060717161753.GA20551@coresystems.de>
	<8b0974ca0607181014k5edfa49dmccedbf0bb37b1157@mail.gmail.com>
	<20060718183803.GA9579@coresystems.de>
Message-ID: <8b0974ca0607190902x6181cdbcrf86b0aeb3326baa5@mail.gmail.com>

 Hi,
  I have captured the output of serial (COM A), that comes from the SP.
However, I am unable to disable the same and get the output of LinuxBIOS on
the serial

=======================================================================================



Starting OpenBSD Secure Shell server: sshd.

localhost login: root
Password:
localhost # platform get consi ole
Error. The requested service is not available.
localhost # platform
platform: Error. Unknown subcommand.
Usage: platform console {-h|--help}
       platform get console {-h|--help}
       platform get hostname {-h|--help}
       platform get mac {-h|--help}
       platform get power state {-h|--help}
       platform get product-id {-h|--help}
       platform get os state {-h|--help}
       platform set console {-h|--help}
       platform set os state boot {-h|--help}
       platform set os state reboot {-h|--help}
       platform set os state shutdown {-h|--help}
       platform set os state update-bios {-h|--help}
       platform set power state {-h|--help}
localhost # platform get consil  ole
Rear Panel
Platform COMA
localhost # platform set console -d
Error. Invalid parameter(s).
localhost # platform set consi ole -help
platform set console {--serial|-s} sp [{{--enable|-e}|{--disable|-d}}]
         [{{--prune|-p}|{--noprune|-n}}] [{--speed|-S}
         {1200|2400|4800|9600|19200|38400|57600|115200}] [{--log|-l} size]
         [{-h|--help}]
 or
platform set console {--serial|-s} platform [{-h|--help}]
{-S|--speed} {1200|2400|4800|9600|19200|38400|57600|115200}
                    Select the port speed on the SP to use to connect to the
                    platform console.  BIOS, the platform OS and the SP must
all
                    be configured for the same speed.  This setting does not
                    affect the platform configuration
                    Cannot be used with: -s=platform
{-d|--disable}      Indicate that the platform console monitor is inactive
                    Cannot be used with: -e -s=platform
{-e|--enable}       Indicate that the platform console monitor is active
                    Cannot be used with: -d -s=platform
{-h|--help}         Print the usage message.
{-l|--log} size     Select the trigger size in KB for console log rotation.
                    Minimum 64KB, Maximum 1024KB
                    Cannot be used with: -s=platform
{-n|--noprune}      Indicate that the platform console log should be the raw
                    console data
                    Cannot be used with: -p -s=platform
{-p|--prune}        Indicate that the platform console log is to be cleaned
of
                    ANSI sequences and pruned of duplicated information
                    Cannot be used with: -n -s=platform
{-s|--serial} {sp|platform}
                    Specify whether the serial port is connected to the
platform
                    COMA port, or the SP serial console
                    Cannot be used with: -e [platform] -d [platform] -p
[platform] -n [platform] -S [platform] -l [platform]

localhost #

========================================================================================


On 7/19/06, Stefan Reinauer <stepan at coresystems.de> wrote:
>
>
> what does "platform get console" tell you?
>
> It should say something like:
> $ platform get console
> Rear Panel Enabled Speed Pruning Log Trigger
> SP Console Yes     19200 No      244 KB
> ^^^^^^^^^^^^^^^^^^
>
> You need to configure the
> console on the SP with the "platform set console" command.
>
> platform set console {--serial|-s} sp [{{--enable|-e}|{--disable|-d}}]
> [{{--prune|-p}|{--noprune|-n}}]
>         [{--speed|-S} {1200|2400|4800|9600|19200|38400|57600|115200}]
> [{--log|-l} size] [{-h|--help}]
> or
> platform set console {--serial|-s} platform [{-h|--help}]
> {-S|--speed} {1200|2400|4800|9600|19200|38400|57600|115200}
>                    Select the port speed for the platform console.
>                    BIOS, the platform OS and the console must
>                    all be configured for the same speed
>                    Cannot be used with: -s=platform
>
> {-d|--disable}      Indicate that the platform console monitor is
>                    inactive
>                    Cannot be used with: -e -s=platform
>
> {-e|--enable}       Indicate that the platform console monitor is active
>                    Cannot be used with: -d -s=platform
>
> {-p|--prune}        Indicate that the platform console log is to be
>                    cleaned of ANSI sequences and pruned of
>                    duplicated information
>                    Cannot be used with: -n -s=platform
>
> {-s|--serial} {sp|platform}
>                    Specify whether the serial port is connected to the
>                    platform COMA port, or the SP serial console
>                    Cannot be used with: -e [platform] -d [platform] -p
>                    [platform] -n [platform] -S [platform] -l [platform]
>
>
> * Anil B G <bg.anil at gmail.com> [060718 19:14]:
> > Hi Stefan,
> >   I logged into the SP and tried platform console etc. but I was not
> really
> > sure how that would help me.
> > That would only change the settings of the Linux thats loaded and on a
> reboot
> > the PPCboot would again spew messages on the serial.
> > I guess I am missing something here, but cannot really visualise how to
> get the
> > output of LinuxBIOS on the serial.
> > One way perhaps would be to disable the SP at the hardware level (if
> that is
> > possible).
> >
> > Please let me know if it is possible to disable serial by trying
> "platform
> > console" on the SP.
> >
> > Regards
> > Anil
> >
> >
> > On 7/17/06, Stefan Reinauer <stepan at coresystems.de> wrote:
> >
> >     * Anil B G <bg.anil at gmail.com> [060717 17:07]:
> >     > Hi,
> >     >   I only get the output of the SP on the serial interface.
> >
> >     log in to the sp and do "platform console"
> >
> >
> >     --
> >     coresystems GmbH   Brahmsstr. 16   D-79104 Freiburg i. Br.
> >          Tel.: +49 761 7668825   Fax: +49 761 7664613
> >     Email: info at coresystems.de    http://www.coresystems.de/
> >
> >
>
> --
> coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
>      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
> Email: info at coresystems.de  ? http://www.coresystems.de/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060719/53dcfdd2/attachment.html>

From stepan at coresystems.de  Wed Jul 19 18:06:39 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Wed, 19 Jul 2006 18:06:39 +0200
Subject: [LinuxBIOS] Build issue for khepri target
In-Reply-To: <8b0974ca0607190902x6181cdbcrf86b0aeb3326baa5@mail.gmail.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4207004075@ssvlexmb2.amd.com>
	<8b0974ca0607140814w7fc97eecvebc70be685aff30b@mail.gmail.com>
	<20060714165435.GC6933@coresystems.de>
	<8b0974ca0607162034i546a394en34acd4e12d372f2a@mail.gmail.com>
	<20060717083617.GA9498@coresystems.de>
	<8b0974ca0607170807k71203399k2bf6b07c741deaa2@mail.gmail.com>
	<20060717161753.GA20551@coresystems.de>
	<8b0974ca0607181014k5edfa49dmccedbf0bb37b1157@mail.gmail.com>
	<20060718183803.GA9579@coresystems.de>
	<8b0974ca0607190902x6181cdbcrf86b0aeb3326baa5@mail.gmail.com>
Message-ID: <20060719160639.GA27180@coresystems.de>

* Anil B G <bg.anil at gmail.com> [060719 18:02]:
> Hi,
>   I have captured the output of serial (COM A), that comes from the SP.
> However, I am unable to disable the same and get the output of LinuxBIOS on the
> serial
 

try "platform get console" ... it seems you mistyped the name several
times. the sp does not like backspace, so it prints the error you see.

> ===============================================================================
> ========
>  
>  
> 
> Starting OpenBSD Secure Shell server: sshd.
>  
> localhost login: root
> Password:
> localhost # platform get consi   ole
> Error. The requested service is not available.
> localhost # platform
> platform: Error. Unknown subcommand.
> Usage: platform console {-h|--help}
>        platform get console {-h|--help}
>        platform get hostname {-h|--help}
>        platform get mac {-h|--help}
>        platform get power state {-h|--help}
>        platform get product-id {-h|--help}
>        platform get os state {-h|--help}
>        platform set console {-h|--help}
>        platform set os state boot {-h|--help}
>        platform set os state reboot {-h|--help}
>        platform set os state shutdown {-h|--help}
>        platform set os state update-bios {-h|--help}
>        platform set power state {-h|--help}
> localhost # platform get consil      ole
> Rear Panel
> Platform COMA
> localhost # platform set console -d
> Error. Invalid parameter(s).
> localhost # platform set consi   ole -help
> platform set console {--serial|-s} sp [{{--enable|-e}|{--disable|-d}}]
>          [{{--prune|-p}|{--noprune|-n}}] [{--speed|-S}
>          {1200|2400|4800|9600|19200|38400|57600|115200}] [{--log|-l} size]
>          [{-h|--help}]
>  or
> platform set console {--serial|-s} platform [{-h|--help}]
> {-S|--speed} {1200|2400|4800|9600|19200|38400|57600|115200}
>                     Select the port speed on the SP to use to connect to the
>                     platform console.  BIOS, the platform OS and the SP must
> all
>                     be configured for the same speed.  This setting does not
>                     affect the platform configuration
>                     Cannot be used with: -s=platform
> {-d|--disable}      Indicate that the platform console monitor is inactive
>                     Cannot be used with: -e -s=platform
> {-e|--enable}       Indicate that the platform console monitor is active
>                     Cannot be used with: -d -s=platform
> {-h|--help}         Print the usage message.
> {-l|--log} size     Select the trigger size in KB for console log rotation.
>                     Minimum 64KB, Maximum 1024KB
>                     Cannot be used with: -s=platform
> {-n|--noprune}      Indicate that the platform console log should be the raw
>                     console data
>                     Cannot be used with: -p -s=platform
> {-p|--prune}        Indicate that the platform console log is to be cleaned of
>                     ANSI sequences and pruned of duplicated information
>                     Cannot be used with: -n -s=platform
> {-s|--serial} {sp|platform}
>                     Specify whether the serial port is connected to the
> platform
>                     COMA port, or the SP serial console
>                     Cannot be used with: -e [platform] -d [platform] -p
> [platform] -n [platform] -S [platform] -l [platform]
>  
> localhost #
>  
> ===============================================================================
> =========
> 
> 
> On 7/19/06, Stefan Reinauer <stepan at coresystems.de> wrote:
> 
> 
>     what does "platform get console" tell you?
> 
>     It should say something like:
>     $ platform get console
>     Rear Panel Enabled Speed Pruning Log Trigger
>     SP Console Yes     19200 No      244 KB
>     ^^^^^^^^^^^^^^^^^^
> 
>     You need to configure the
>     console on the SP with the "platform set console" command.
> 
>     platform set console {--serial|-s} sp [{{--enable|-e}|{--disable|-d}}]
>     [{{--prune|-p}|{--noprune|-n}}]
>             [{--speed|-S} {1200|2400|4800|9600|19200|38400|57600|115200}]
>     [{--log|-l} size] [{-h|--help}]
>     or
>     platform set console {--serial|-s} platform [{-h|--help}]
>     {-S|--speed} {1200|2400|4800|9600|19200|38400|57600|115200}
>                        Select the port speed for the platform console.
>                        BIOS, the platform OS and the console must
>                        all be configured for the same speed
>                        Cannot be used with: -s=platform
> 
>     {-d|--disable}      Indicate that the platform console monitor is
>                        inactive
>                        Cannot be used with: -e -s=platform
> 
>     {-e|--enable}       Indicate that the platform console monitor is active
>                        Cannot be used with: -d -s=platform
> 
>     {-p|--prune}        Indicate that the platform console log is to be
>                        cleaned of ANSI sequences and pruned of
>                        duplicated information
>                        Cannot be used with: -n -s=platform
> 
>     {-s|--serial} {sp|platform}
>                        Specify whether the serial port is connected to the
>                        platform COMA port, or the SP serial console
>                        Cannot be used with: -e [platform] -d [platform] -p
>                        [platform] -n [platform] -S [platform] -l [platform]
> 
> 
>     * Anil B G <bg.anil at gmail.com> [060718 19:14]:
>     > Hi Stefan,
>     >   I logged into the SP and tried platform console etc. but I was not
>     really
>     > sure how that would help me.
>     > That would only change the settings of the Linux thats loaded and on a
>     reboot
>     > the PPCboot would again spew messages on the serial.
>     > I guess I am missing something here, but cannot really visualise how to
>     get the
>     > output of LinuxBIOS on the serial.
>     > One way perhaps would be to disable the SP at the hardware level (if that
>     is
>     > possible).
>     >
>     > Please let me know if it is possible to disable serial by trying
>     "platform
>     > console" on the SP.
>     >
>     > Regards
>     > Anil
>     >
>     >
>     > On 7/17/06, Stefan Reinauer <stepan at coresystems.de> wrote:
>     >
>     >     * Anil B G < bg.anil at gmail.com> [060717 17:07]:
>     >     > Hi,
>     >     >   I only get the output of the SP on the serial interface.
>     >
>     >     log in to the sp and do "platform console"
>     >
>     >
>     >     --
>     >     coresystems GmbH   Brahmsstr. 16   D-79104 Freiburg i. Br.
>     >          Tel.: +49 761 7668825   Fax: +49 761 7664613
>     >     Email: info at coresystems.de    http://www.coresystems.de/
>     >
>     >
> 
>     --
>     coresystems GmbH   Brahmsstr. 16   D-79104 Freiburg i. Br.
>          Tel.: +49 761 7668825   Fax: +49 761 7664613
>     Email: info at coresystems.de    http://www.coresystems.de/
> 
> 

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From info at coresystems.de  Wed Jul 19 18:26:14 2006
From: info at coresystems.de (LinuxBIOS information)
Date: Wed, 19 Jul 2006 18:26:14 +0200
Subject: [LinuxBIOS] LinuxBIOS r2342 build changes
Message-ID: <E1G3EsI-0004ni-0q@khepri.openbios.org>

Dear LinuxBIOS readers!

This is the automated build check service of LinuxBIOS.

The developer "stepan" checked in revision 2342 to
the LinuxBIOS source repository and caused the following 
changes:

Change Log:
move mptable to 960k to 1Mhttps://openbios.org/roundup/linuxbios/issue55This patch is a little bit enhanced, it keeps the ppc table consistent,which Yinghai's original patch did not.

Build Log:
 Compilation of advantech:som_gx533c has been broken Compilation of amd:rumba has been broken Compilation of densitron:dpx114 has been broken Compilation of digitallogic:adl855pc has been broken Compilation of digitallogic:msm586seg has been broken Compilation of eaglelion:5bcm has been broken Compilation of emulation:qemu-i386 has been broken Compilation of lippert:frontrunner has been broken Compilation of olpc:rev_a has been broken Compilation of technologic:ts5300 has been broken Compilation of via:epia has been broken Compilation of via:epia-m has been broken

If something broke during this checkin please be a pain 
in stepan's neck until the issue is fixed.

If this issue is not fixed within 24h the revision will 
be backed out.

   Yours truely,
     LinuxBIOS automatic build system





From info at coresystems.de  Wed Jul 19 19:35:14 2006
From: info at coresystems.de (LinuxBIOS information)
Date: Wed, 19 Jul 2006 19:35:14 +0200
Subject: [LinuxBIOS] LinuxBIOS r2343 build changes
Message-ID: <E1G3Fx4-0005r0-Gi@khepri.openbios.org>

Dear LinuxBIOS readers!

This is the automated build check service of LinuxBIOS.

The developer "stepan" checked in revision 2343 to
the LinuxBIOS source repository and caused the following 
changes:

Change Log:
this code is for writing the mp table, so only execute it whenwe actually have one.

Build Log:
 Compilation of advantech:som_gx533c has been fixed. Compilation of amd:rumba has been fixed. Compilation of densitron:dpx114 has been fixed. Compilation of digitallogic:adl855pc has been fixed. Compilation of digitallogic:msm586seg has been fixed. Compilation of eaglelion:5bcm has been fixed. Compilation of emulation:qemu-i386 has been fixed. Compilation of lippert:frontrunner has been fixed. Compilation of olpc:rev_a has been fixed. Compilation of technologic:ts5300 has been fixed. Compilation of via:epia has been fixed. Compilation of via:epia-m has been fixed.

If something broke during this checkin please be a pain 
in stepan's neck until the issue is fixed.

If this issue is not fixed within 24h the revision will 
be backed out.

   Yours truely,
     LinuxBIOS automatic build system





From danmez at gmail.com  Thu Jul 20 00:00:50 2006
From: danmez at gmail.com (Dan Mezynski)
Date: Wed, 19 Jul 2006 18:00:50 -0400
Subject: [LinuxBIOS] can't see printk messages
Message-ID: <7b7e71620607191500u302df2bdv2d81eb0e80749313@mail.gmail.com>

I am trying to run LB on the AMD quartet board, it gets into hardwaremain()
before it gets hung and at that time it puts ff to port 80, which is good
in one way since at least I can see the postcodes up to that point.
but it does not display anything to the console.
The printk messages such as "Copying LinuxBios to ram" are not
visable. I am running in
the SImNow simulator, and I believe someone said it does not need
extra steps to initialize VGA.

How do I get the printk text messages to be visable?

Any suggestions would be greatly appreciated!!!

Thanks,
Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060719/99ae0f8d/attachment.html>

From uwe at hermann-uwe.de  Thu Jul 20 01:51:33 2006
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Thu, 20 Jul 2006 01:51:33 +0200
Subject: [LinuxBIOS] GA-6BXC support
In-Reply-To: <8a0c36780607131414x2f33efc3tcdc004979dea7fa@mail.gmail.com>
References: <20060713202936.GB20333@aragorn> <44B6B29F.7050704@irobot.com>
	<8a0c36780607131414x2f33efc3tcdc004979dea7fa@mail.gmail.com>
Message-ID: <20060719235133.GA16596@aragorn>

Hi,

On Thu, Jul 13, 2006 at 04:14:00PM -0500, Richard Smith wrote:
> That was all done for the Bitworks/IMS board which was a custom board
> we made but its essentially a stock 440bx reference design.  So I
> suggest you start there.    Its been a _long_ while since I've looked
> at the code but I'll try to help.
 
OK, so I've installed a Linux on the computer, and fixed some unrelated
hardware issues. Then, I burnt my first BIOS, in the truest sense of the
word. I practised removing and inserting the BIOS chip a few times
yesterday, and it seems I inserted it the wrong way the last time before
I went to bed (I _do_ know how to insert it correctly, usually).

Today I started the PC in order to install the LinuxBIOS software and
tools, but nothing happened. Soon I noticed that the BIOS was pretty
darn hot, the label on the BIOS was literally melting. Yay!

I have ordered a replacement BIOS. I hope that's the only part that
died and the rest of the board is ok.

 
> I still have the hardware though and I'd love to have to work on V2.
> There are lots of 440bx boards out there. I just don't have the time.
> I'll send you the patches if you want to play with them.

Yes, please do. It'll probably take a while until I get v1, then v2,
working, though.

I have a W49F002U and a AM-29F040B chip to work with. Both seem to be
supported, and both are rewritable (so I can flash them multiple times),
correct?

I also have a 32pin ZIF socket, but I'm afraid it's useless for this
board. It's bigger than the BIOS chip, and the space is so limited,
I'd have to rip away 2-3 PCI sockets and other mainboard parts to
be able to insert it.
So I'll probably try without the ZIF socket, and pray that I don't
get fried in the process ;)


Cheers, Uwe.
-- 
Uwe Hermann 
http://www.hermann-uwe.de
http://www.it-services-uh.de  | http://www.crazy-hacks.org 
http://www.holsham-traders.de | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060720/1af25c8f/attachment.sig>

From smithbone at gmail.com  Thu Jul 20 05:33:04 2006
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 19 Jul 2006 22:33:04 -0500
Subject: [LinuxBIOS] GA-6BXC support
In-Reply-To: <20060719235133.GA16596@aragorn>
References: <20060713202936.GB20333@aragorn> <44B6B29F.7050704@irobot.com>
	<8a0c36780607131414x2f33efc3tcdc004979dea7fa@mail.gmail.com>
	<20060719235133.GA16596@aragorn>
Message-ID: <8a0c36780607192033v1d25d86dp165efdeaa6465df6@mail.gmail.com>

>
> I have ordered a replacement BIOS. I hope that's the only part that
> died and the rest of the board is ok.

You should be ok.  Typically that just frys the part thats in
backwards.  Do you have access to a oscope?  If so then watch the chip
select line in the bios socket  you should see several transitions
(typically 8) when you hit reset.  If you get those then your
motherboard is probably still ok.

> > There are lots of 440bx boards out there. I just don't have the time.
> > I'll send you the patches if you want to play with them.
>
> Yes, please do. It'll probably take a while until I get v1, then v2,
> working, though.

I'll update my framework to the latest SVN rev and push it up this weekend.

Don't spend too much time on V1.  Its a deadend street.  Once we fix
the SPD data issue from the RAM with what I already have the rest of
V2 should knock out really quickly.

Sweet.  I'm stoked that someone is going to work on this.

> I have a W49F002U and a AM-29F040B chip to work with. Both seem to be
> supported, and both are rewritable (so I can flash them multiple times),
> correct?

Correct.  You can re-flash them many times.  I've yet to exhaust a
flash parts erase-write cycles under even heavy development work.  You
have to have some really repetitive program hitting it over and over
to reach that >100k cycle number.

What size part was in the mainboard to begin with?  A 2Mbit or 4Mbit
part?   If its a 2Mbit part the you can use a 4Mbit part but you may
need to duplicate the data in the upper 256k of the part since you
don't really know if the extra address line at the socked is grounded
or floating.  If it was a 4Mbit part then you should be able to use a
2Mbit part as long as you have the size correct (2Mbit) in the config
file.

One thing you do need to pay attention to is the speed of the parts
you are using.  I know for a fact that 90nS or faster should work.
However there has been at least one report on the list where some one
had what looked (based on datasheet) like a compatible replacement but
did not work.  I don't remember what platform it was on.

I've personaly used loads of both ST and AM 90nS 29F040B's with the
Bitworks/IMS board so I'm quite sure the 440BX works fine with both of
those mfgs.

-- 
Richard A. Smith



From costa at gamic.com  Thu Jul 20 13:38:59 2006
From: costa at gamic.com (Marco Costa)
Date: Thu, 20 Jul 2006 13:38:59 +0200
Subject: [LinuxBIOS] ASUS K8N
Message-ID: <jj64p3-ent.ln1@legba.gamic.com>

Hi,

I run a search on the mailing list, but found no mention of it: does anybody know if the ASUS K8N (without any qualifiers like Deluxe or so) will work with linuxbios?

Thank you in advance.

Marco




From yinghai.lu at amd.com  Thu Jul 20 18:27:19 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Thu, 20 Jul 2006 09:27:19 -0700
Subject: [LinuxBIOS] ASUS K8N
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A42070040B4@ssvlexmb2.amd.com>

It is using NVIDIA nForce3 250.

You'd better to find one with Nvidia Nforce 4 or Ck804.

YH 

-----Original Message-----
From: linuxbios-bounces at linuxbios.org
[mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Marco Costa
Sent: Thursday, July 20, 2006 4:39 AM
To: linuxbios at openbios.org
Subject: [LinuxBIOS] ASUS K8N

Hi,

I run a search on the mailing list, but found no mention of it: does
anybody know if the ASUS K8N (without any qualifiers like Deluxe or so)
will work with linuxbios?

Thank you in advance.

Marco


-- 
linuxbios mailing list
linuxbios at linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios







From bg.anil at gmail.com  Thu Jul 20 19:55:59 2006
From: bg.anil at gmail.com (Anil B G)
Date: Thu, 20 Jul 2006 23:25:59 +0530
Subject: [LinuxBIOS] Build issue for khepri target
In-Reply-To: <20060719160639.GA27180@coresystems.de>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4207004075@ssvlexmb2.amd.com>
	<20060714165435.GC6933@coresystems.de>
	<8b0974ca0607162034i546a394en34acd4e12d372f2a@mail.gmail.com>
	<20060717083617.GA9498@coresystems.de>
	<8b0974ca0607170807k71203399k2bf6b07c741deaa2@mail.gmail.com>
	<20060717161753.GA20551@coresystems.de>
	<8b0974ca0607181014k5edfa49dmccedbf0bb37b1157@mail.gmail.com>
	<20060718183803.GA9579@coresystems.de>
	<8b0974ca0607190902x6181cdbcrf86b0aeb3326baa5@mail.gmail.com>
	<20060719160639.GA27180@coresystems.de>
Message-ID: <8b0974ca0607201055k938b4b4q7dbe1dd2bfeb61ec@mail.gmail.com>

Hi,
  Here is the output of what I tried:
======================================================

platform get console
Rear Panel
Platform COMA
localhost # platform set console -d
Error. Invalid parameter(s).
localhost # platform set console --disable
Error. Invalid parameter(s).
localhost # platform set console --help
platform set console {--serial|-s} sp [{{--enable|-e}|{--disable|-d}}]
         [{{--prune|-p}|{--noprune|-n}}] [{--speed|-S}
         {1200|2400|4800|9600|19200|38400|57600|115200}] [{--log|-l} size]
         [{-h|--help}]
 or
platform set console {--serial|-s} platform [{-h|--help}]
{-S|--speed} {1200|2400|4800|9600|19200|38400|57600|115200}
                    Select the port speed on the SP to use to connect to the
                    platform console.  BIOS, the platform OS and the SP must
all
                    be configured for the same speed.  This setting does not
                    affect the platform configuration
                    Cannot be used with: -s=platform
{-d|--disable}      Indicate that the platform console monitor is inactive
                    Cannot be used with: -e -s=platform
{-e|--enable}       Indicate that the platform console monitor is active
                    Cannot be used with: -d -s=platform
{-h|--help}         Print the usage message.
{-l|--log} size     Select the trigger size in KB for console log rotation.
                    Minimum 64KB, Maximum 1024KB
                    Cannot be used with: -s=platform
{-n|--noprune}      Indicate that the platform console log should be the raw
                    console data
                    Cannot be used with: -p -s=platform
{-p|--prune}        Indicate that the platform console log is to be cleaned
of
                    ANSI sequences and pruned of duplicated information
                    Cannot be used with: -n -s=platform
{-s|--serial} {sp|platform}
                    Specify whether the serial port is connected to the
platform
                    COMA port, or the SP serial console
                    Cannot be used with: -e [platform] -d [platform] -p
[platform] -n [platform] -S [platform] -l [platform]

localhost #
======================================================



On 7/19/06, Stefan Reinauer <stepan at coresystems.de> wrote:
>
> * Anil B G <bg.anil at gmail.com> [060719 18:02]:
> > Hi,
> >   I have captured the output of serial (COM A), that comes from the SP.
> > However, I am unable to disable the same and get the output of LinuxBIOS
> on the
> > serial
>
>
> try "platform get console" ... it seems you mistyped the name several
> times. the sp does not like backspace, so it prints the error you see.
>
> >
> ===============================================================================
> > ========
> >
> >
> >
> > Starting OpenBSD Secure Shell server: sshd.
> >
> > localhost login: root
> > Password:
> > localhost # platform get consi   ole
> > Error. The requested service is not available.
> > localhost # platform
> > platform: Error. Unknown subcommand.
> > Usage: platform console {-h|--help}
> >        platform get console {-h|--help}
> >        platform get hostname {-h|--help}
> >        platform get mac {-h|--help}
> >        platform get power state {-h|--help}
> >        platform get product-id {-h|--help}
> >        platform get os state {-h|--help}
> >        platform set console {-h|--help}
> >        platform set os state boot {-h|--help}
> >        platform set os state reboot {-h|--help}
> >        platform set os state shutdown {-h|--help}
> >        platform set os state update-bios {-h|--help}
> >        platform set power state {-h|--help}
> > localhost # platform get consil      ole
> > Rear Panel
> > Platform COMA
> > localhost # platform set console -d
> > Error. Invalid parameter(s).
> > localhost # platform set consi   ole -help
> > platform set console {--serial|-s} sp [{{--enable|-e}|{--disable|-d}}]
> >          [{{--prune|-p}|{--noprune|-n}}] [{--speed|-S}
> >          {1200|2400|4800|9600|19200|38400|57600|115200}] [{--log|-l}
> size]
> >          [{-h|--help}]
> >  or
> > platform set console {--serial|-s} platform [{-h|--help}]
> > {-S|--speed} {1200|2400|4800|9600|19200|38400|57600|115200}
> >                     Select the port speed on the SP to use to connect to
> the
> >                     platform console.  BIOS, the platform OS and the SP
> must
> > all
> >                     be configured for the same speed.  This setting does
> not
> >                     affect the platform configuration
> >                     Cannot be used with: -s=platform
> > {-d|--disable}      Indicate that the platform console monitor is
> inactive
> >                     Cannot be used with: -e -s=platform
> > {-e|--enable}       Indicate that the platform console monitor is active
> >                     Cannot be used with: -d -s=platform
> > {-h|--help}         Print the usage message.
> > {-l|--log} size     Select the trigger size in KB for console log
> rotation.
> >                     Minimum 64KB, Maximum 1024KB
> >                     Cannot be used with: -s=platform
> > {-n|--noprune}      Indicate that the platform console log should be the
> raw
> >                     console data
> >                     Cannot be used with: -p -s=platform
> > {-p|--prune}        Indicate that the platform console log is to be
> cleaned of
> >                     ANSI sequences and pruned of duplicated information
> >                     Cannot be used with: -n -s=platform
> > {-s|--serial} {sp|platform}
> >                     Specify whether the serial port is connected to the
> > platform
> >                     COMA port, or the SP serial console
> >                     Cannot be used with: -e [platform] -d [platform] -p
> > [platform] -n [platform] -S [platform] -l [platform]
> >
> > localhost #
> >
> >
> ===============================================================================
> > =========
> >
> >
> > On 7/19/06, Stefan Reinauer <stepan at coresystems.de> wrote:
> >
> >
> >     what does "platform get console" tell you?
> >
> >     It should say something like:
> >     $ platform get console
> >     Rear Panel Enabled Speed Pruning Log Trigger
> >     SP Console Yes     19200 No      244 KB
> >     ^^^^^^^^^^^^^^^^^^
> >
> >     You need to configure the
> >     console on the SP with the "platform set console" command.
> >
> >     platform set console {--serial|-s} sp
> [{{--enable|-e}|{--disable|-d}}]
> >     [{{--prune|-p}|{--noprune|-n}}]
> >             [{--speed|-S}
> {1200|2400|4800|9600|19200|38400|57600|115200}]
> >     [{--log|-l} size] [{-h|--help}]
> >     or
> >     platform set console {--serial|-s} platform [{-h|--help}]
> >     {-S|--speed} {1200|2400|4800|9600|19200|38400|57600|115200}
> >                        Select the port speed for the platform console.
> >                        BIOS, the platform OS and the console must
> >                        all be configured for the same speed
> >                        Cannot be used with: -s=platform
> >
> >     {-d|--disable}      Indicate that the platform console monitor is
> >                        inactive
> >                        Cannot be used with: -e -s=platform
> >
> >     {-e|--enable}       Indicate that the platform console monitor is
> active
> >                        Cannot be used with: -d -s=platform
> >
> >     {-p|--prune}        Indicate that the platform console log is to be
> >                        cleaned of ANSI sequences and pruned of
> >                        duplicated information
> >                        Cannot be used with: -n -s=platform
> >
> >     {-s|--serial} {sp|platform}
> >                        Specify whether the serial port is connected to
> the
> >                        platform COMA port, or the SP serial console
> >                        Cannot be used with: -e [platform] -d [platform]
> -p
> >                        [platform] -n [platform] -S [platform] -l
> [platform]
> >
> >
> >     * Anil B G <bg.anil at gmail.com> [060718 19:14]:
> >     > Hi Stefan,
> >     >   I logged into the SP and tried platform console etc. but I was
> not
> >     really
> >     > sure how that would help me.
> >     > That would only change the settings of the Linux thats loaded and
> on a
> >     reboot
> >     > the PPCboot would again spew messages on the serial.
> >     > I guess I am missing something here, but cannot really visualise
> how to
> >     get the
> >     > output of LinuxBIOS on the serial.
> >     > One way perhaps would be to disable the SP at the hardware level
> (if that
> >     is
> >     > possible).
> >     >
> >     > Please let me know if it is possible to disable serial by trying
> >     "platform
> >     > console" on the SP.
> >     >
> >     > Regards
> >     > Anil
> >     >
> >     >
> >     > On 7/17/06, Stefan Reinauer <stepan at coresystems.de> wrote:
> >     >
> >     >     * Anil B G < bg.anil at gmail.com> [060717 17:07]:
> >     >     > Hi,
> >     >     >   I only get the output of the SP on the serial interface.
> >     >
> >     >     log in to the sp and do "platform console"
> >     >
> >     >
> >     >     --
> >     >     coresystems GmbH   Brahmsstr. 16   D-79104 Freiburg i. Br.
> >     >          Tel.: +49 761 7668825   Fax: +49 761 7664613
> >     >     Email: info at coresystems.de    http://www.coresystems.de/
> >     >
> >     >
> >
> >     --
> >     coresystems GmbH   Brahmsstr. 16   D-79104 Freiburg i. Br.
> >          Tel.: +49 761 7668825   Fax: +49 761 7664613
> >     Email: info at coresystems.de    http://www.coresystems.de/
> >
> >
>
> --
> coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
>      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
> Email: info at coresystems.de  ? http://www.coresystems.de/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060720/0b76a255/attachment.html>

From little.martin at inode.at  Thu Jul 20 20:44:42 2006
From: little.martin at inode.at (Morly)
Date: Thu, 20 Jul 2006 20:44:42 +0200
Subject: [LinuxBIOS] Mainboard-Configuration
In-Reply-To: <20060713114055.GA31231@coresystems.de>
References: <44B60C41.5010708@inode.at> <20060713114055.GA31231@coresystems.de>
Message-ID: <44BFCF1A.5030302@inode.at>

Hello, once more!

I got the suggestion of a board named win-ent - MB-06047.
Unfortunately I don't get any answer of the European shop.
(I am from Austria!)
But now I know that I can also use Opteron Processors, the ones with
30W.
So does anyone know a mini or micro atx board ready for
linuxbios?
(a board with vga onboard, rs232, maybe parallel, usb 2.0
a pci slot)

Many thanks,
Morly



2006/7/13, Morly <little.martin at inode.at>:
> Hello!
>
> First, I really like the idea and the work around linuxbios.
>
> For my PhD research in new medical solutions I need a very special
> PC-configuration:
> The PC must be absolutely silent and, however, be powerful.
> The next point is, that the PC should use as less boot time
> as possible. This is why I think about a linuxbios - compatible
> board. Due the mainboard will be put in a small case, I can
> just use mini- or micro atx boards. The only boards in this
> size I could determine are VIA-EPIA boards. Unfortunately,
> they are too slow for my applications.
>
> For passive cooling and long battery usage  I thought about a
> Turion or Sempron CPU.
>
> So in one sentence, I am looking for an mini or micro atx
> board, compatible with AMD Turion (Sempron), which
> supports linuxbios.
>
> Is there anyone who can help me?
>
> Many thanks,
> greetings,
> Morly
>
>
>
>
> -- 
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>



From keithwwyse at ukonline.co.uk  Thu Jul 20 21:12:03 2006
From: keithwwyse at ukonline.co.uk (keithwwyse at ukonline.co.uk)
Date: Thu, 20 Jul 2006 20:12:03 +0100
Subject: [LinuxBIOS] Foxconn BIOS won't boot Linux
Message-ID: <1153422723.44bfd5832dc2c@webmail.ukonline.net>

Hi all
Following your instructions regarding requesting assistance with the
compatability of LinuxBIOS with different mainboards here are the specifications.
I have an AMD Athlon XP2400+ in a Foxconn 741M01C-GX-6L as a desktop machine

This is the output of 'lspci -vvv'

00:00.0 Host bridge: Silicon Integrated Systems [SiS] 741/741GX/M741 Host (rev 0 3)
        Subsystem: Foxconn International, Inc. Unknown device 0c4d
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step
ping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort
- <MAbort+ >SERR- <PERR-
        Latency: 32
        Region 0: Memory at e8000000 (32-bit, non-prefetchable) [size=64M]
        Capabilities: [c0] AGP version 3.5
                Status: RQ=32 Iso- ArqSz=2 Cal=3 SBA+ ITACoh- GART64- HTrans- 64
bit- FW- AGP3+ Rate=x4,x8
                Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate=<n
one>

00:01.0 PCI bridge: Silicon Integrated Systems [SiS] SiS AGP Port (virtual PCI-t
o-PCI bridge) (prog-if 00 [Normal decode])
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step
ping- SERR+ FastB2B-
        Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
        Latency: 99
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=32
        I/O behind bridge: 0000d000-0000dfff
        Memory behind bridge: ec000000-ec0fffff
        Prefetchable memory behind bridge: d8000000-e7ffffff
        Secondary status: 66MHz+ FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort+ <SERR- <PERR-
        BridgeCtl: Parity- SERR+ NoISA+ VGA+ MAbort- >Reset- FastB2B-

00:02.0 ISA bridge: Silicon Integrated Systems [SiS] SiS963 [MuTIOL Media IO] (r
ev 25)
        Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Step
ping- SERR- FastB2B-
        Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort
- <MAbort- >SERR- <PERR-
        Latency: 0

00:02.1 SMBus: Silicon Integrated Systems [SiS] SiS961/2 SMBus Controller
        Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Step
ping- SERR- FastB2B-
        Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort
- <MAbort- >SERR- <PERR-
        Interrupt: pin B routed to IRQ 0
        Region 4: I/O ports at 10c0 [size=32]

00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (prog-if 80 [
Master])
        Subsystem: Foxconn International, Inc. Unknown device 0c4d
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step
ping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort
- <MAbort- >SERR- <PERR-
        Latency: 128
        Interrupt: pin ? routed to IRQ 16
        Region 4: I/O ports at 4000 [size=16]
        Capabilities: [58] Power Management version 2
                Flags: PMEClk- DSI- D1- D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot
-,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:03.0 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev
 0f) (prog-if 10 [OHCI])
        Subsystem: Foxconn International, Inc. Unknown device 0c4d
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step
ping- SERR- FastB2B-
        Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort
- <MAbort- >SERR- <PERR-
        Latency: 32 (20000ns max), Cache Line Size 08
        Interrupt: pin A routed to IRQ 18
        Region 0: Memory at ec126000 (32-bit, non-prefetchable) [size=4K]

00:03.1 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev
 0f) (prog-if 10 [OHCI])
        Subsystem: Foxconn International, Inc. Unknown device 0c4d
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step
ping- SERR- FastB2B-
        Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort
- <MAbort- >SERR- <PERR-
        Latency: 32 (20000ns max), Cache Line Size 08
        Interrupt: pin B routed to IRQ 19
        Region 0: Memory at ec120000 (32-bit, non-prefetchable) [size=4K]

00:04.0 Ethernet controller: Silicon Integrated Systems [SiS] SiS900 PCI Fast Et
hernet (rev 91)
        Subsystem: Foxconn International, Inc. Unknown device 0c4d
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step
ping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort
- <MAbort- >SERR- <PERR-
        Latency: 32 (13000ns min, 2750ns max)
        Interrupt: pin A routed to IRQ 20
        Region 0: I/O ports at e000 [size=256]
        Region 1: Memory at ec122000 (32-bit, non-prefetchable) [size=4K]
        [virtual] Expansion ROM at 50000000 [disabled] [size=128K]
        Capabilities: [40] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot
+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:09.0 Multimedia audio controller: C-Media Electronics Inc CM8738 (rev 10)
        Subsystem: C-Media Electronics Inc CMI8738/C3DX PCI Audio Device
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step
ping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort
- <MAbort- >SERR- <PERR-
        Latency: 32 (500ns min, 6000ns max)
        Interrupt: pin A routed to IRQ 5
        Region 0: I/O ports at e400 [size=256]
        Capabilities: [c0] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot
-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:0a.0 USB Controller: NEC Corporation USB (rev 43) (prog-if 10 [OHCI])
        Subsystem: Belkin Root Hub
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step
ping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort
- <MAbort- >SERR- <PERR-
        Latency: 32 (250ns min, 10500ns max), Cache Line Size 08
        Interrupt: pin A routed to IRQ 20
        Region 0: Memory at ec123000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: [40] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot
+,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:0a.1 USB Controller: NEC Corporation USB (rev 43) (prog-if 10 [OHCI])
        Subsystem: Belkin Root Hub
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step
ping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort
- <MAbort- >SERR- <PERR-
        Latency: 32 (250ns min, 10500ns max), Cache Line Size 08
        Interrupt: pin B routed to IRQ 16
        Region 0: Memory at ec124000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: [40] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot
+,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:0a.2 USB Controller: NEC Corporation USB 2.0 (rev 04) (prog-if 20 [EHCI])
        Subsystem: Belkin Root Hub
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Step
ping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort
- <MAbort- >SERR- <PERR-
        Latency: 32 (4000ns min, 8500ns max), Cache Line Size 10
        Interrupt: pin C routed to IRQ 17
        Region 0: Memory at ec125000 (32-bit, non-prefetchable) [size=256]
        Capabilities: [40] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot
+,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

01:00.0 VGA compatible controller: ATI Technologies Inc Radeon R300 ND [Radeon 9
700 Pro] (prog-if 00 [VGA])
        Subsystem: ATI Technologies Inc Unknown device 0002
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step
ping+ SERR- FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort
- <MAbort- >SERR- <PERR-
        Latency: 32 (2000ns min), Cache Line Size 08
        Interrupt: pin A routed to IRQ 10
        Region 0: Memory at d8000000 (32-bit, prefetchable) [size=128M]
        Region 1: I/O ports at d000 [size=256]
        Region 2: Memory at ec030000 (32-bit, non-prefetchable) [size=64K]
        [virtual] Expansion ROM at ec000000 [disabled] [size=128K]
        Capabilities: [58] AGP version 3.0
                Status: RQ=256 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 6
4bit- FW+ AGP3+ Rate=x4,x8
                Command: RQ=1 ArqSz=0 Cal=0 SBA+ AGP- GART64- 64bit- FW- Rate=<n
one>
        Capabilities: [50] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot
-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

01:00.1 Display controller: ATI Technologies Inc Radeon R300 [Radeon 9700 Pro] (
Secondary)
        Subsystem: ATI Technologies Inc Unknown device 0003
        Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Step
ping+ SERR- FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort
- <MAbort- >SERR- <PERR-
        Region 0: Memory at e0000000 (32-bit, prefetchable) [disabled] [size=128 M]
        Region 1: Memory at ec020000 (32-bit, non-prefetchable) [disabled] [size
=64K]
        Capabilities: [50] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot
-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

I afraid I don't know what the SuperIO chip on the mainboard is; how can I
identify this? Both the northbridge and southbridge are noted in the lspci output.
There are two DIL chips; LRTS6121A and ICS CA530347A 0507 952703BF  Is this what
you need? Sorry

This seems to be the mainboard which matches the one I have most closely;
http://www.foxconnchannel.com/Product/motherboard_detail.aspx?ID=en-us0000129

The problem with this mainboard is that it doesn't seem to like Linux boot
systems. I have the Gentoo 2006.0 LiveCD Installer, and have installed this onto
hda, but the system will not boot giving a non system disk error message. I've
also contacted EdLUG about this as well.
I was hoping that if LinuxBIOS is compatible, I can flash it to the memory and
it will be able to boot the system.

Thanks for all your help
Keith

----------------------------------------------
This mail sent through http://www.ukonline.net



From bari at onelabs.com  Thu Jul 20 23:52:23 2006
From: bari at onelabs.com (Bari Ari)
Date: Thu, 20 Jul 2006 16:52:23 -0500
Subject: [LinuxBIOS] Foxconn BIOS won't boot Linux
In-Reply-To: <1153422723.44bfd5832dc2c@webmail.ukonline.net>
References: <1153422723.44bfd5832dc2c@webmail.ukonline.net>
Message-ID: <44BFFB17.4040406@onelabs.com>

keithwwyse at ukonline.co.uk wrote:
> Hi all
> Following your instructions regarding requesting assistance with the
> compatability of LinuxBIOS with different mainboards here are the specifications.
> I have an AMD Athlon XP2400+ in a Foxconn 741M01C-GX-6L as a desktop machine
>
> This is the output of 'lspci -vvv'
>
> 00:00.0 Host bridge: Silicon Integrated Systems [SiS] 741/741GX/M741 Host (rev 0 3)
>         Subsystem: Foxconn International, Inc. Unknown device 0c4d
>   
Foxconn BIOS? Is it actually an Award or Phoenix BIOS?
> The problem with this mainboard is that it doesn't seem to like Linux boot
> systems. I have the Gentoo 2006.0 LiveCD Installer, and have installed this onto
> hda, but the system will not boot giving a non system disk error message. I've
> also contacted EdLUG about this as well.
> I was hoping that if LinuxBIOS is compatible, I can flash it to the memory and
> it will be able to boot the system.
>   
The SIS 735 was the latest SIS supported. That was 4 yrs ago and in V1.

The 741 would be an interesting LinuxBIOS port since this device 
supports the Geode NX.

-Bari



From rminnich at lanl.gov  Fri Jul 21 01:37:03 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Thu, 20 Jul 2006 17:37:03 -0600
Subject: [LinuxBIOS] ultra 40 linuxbios
Message-ID: <44C0139F.5020403@lanl.gov>

well, I've got this sun ultra 40, nice box, sun-designed mobo, lots of 
clever stuff.

And, for some reason, they did not put on a serial port.

Thus proving that it is possible to be too clever. Oh well, now the fun 
begins. I guess it will get worse from here on out.

Please, mobo vendors, just put on the serial port. USB is not an option.

ron



From acassis at gmail.com  Fri Jul 21 01:51:33 2006
From: acassis at gmail.com (Alan Carvalho de Assis)
Date: Thu, 20 Jul 2006 17:51:33 -0600
Subject: [LinuxBIOS] Flashrom support to VIA VT8235
Message-ID: <37367b3a0607201651k27262d1do2e41fd6e331d6b5d@mail.gmail.com>

Hi,
I am trying to get flashrom work with my MB, a PM800, it use a VIA
VT8235 0430CE 23811913461 chipset.

Flashrom don't detect this chipset, because it IS NOT 0x1106:0x3177 as
expected by flash_enable.c, then I add 0x1106:0x3227 (VT8235 ISA
Bridge of my board) to it call "enable_flash_vt8235".

When I executed it at first time I received this warning:

"Enabling flash write on VT8235...tried to set 0x44 to 0x54 on VT8235
failed (WARNING ONLY)"

BUT every time I execute it now I just receive:
"Enabling flash write on VT8235...OK"

I want your opinion, is flashrom detecting my chipset or no?

Best regards,

-- 
------------------------------------------------------------
|                     Alan Carvalho de Assis                |
------------------------------------------------------------
--
N?o importa o que os outros ir?o pensar,
A cura para a infelicidade ? a felicidade



From rminnich at lanl.gov  Fri Jul 21 01:58:26 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Thu, 20 Jul 2006 17:58:26 -0600
Subject: [LinuxBIOS] Flashrom support to VIA VT8235
In-Reply-To: <37367b3a0607201651k27262d1do2e41fd6e331d6b5d@mail.gmail.com>
References: <37367b3a0607201651k27262d1do2e41fd6e331d6b5d@mail.gmail.com>
Message-ID: <44C018A2.9000903@lanl.gov>

Alan Carvalho de Assis wrote:
> Hi,
> I am trying to get flashrom work with my MB, a PM800, it use a VIA
> VT8235 0430CE 23811913461 chipset.
> 
> Flashrom don't detect this chipset, because it IS NOT 0x1106:0x3177 as
> expected by flash_enable.c, then I add 0x1106:0x3227 (VT8235 ISA
> Bridge of my board) to it call "enable_flash_vt8235".
> 
> When I executed it at first time I received this warning:
> 
> "Enabling flash write on VT8235...tried to set 0x44 to 0x54 on VT8235
> failed (WARNING ONLY)"
> 
> BUT every time I execute it now I just receive:
> "Enabling flash write on VT8235...OK"
> 
> I want your opinion, is flashrom detecting my chipset or no?
> 
> Best regards,
> 

it's still hard to say. can you send an lspci to us? Also, what other 
output do you get from flashrom and from flashrom -V?

ron



From dhendrix at google.com  Fri Jul 21 02:01:24 2006
From: dhendrix at google.com (David Hendricks)
Date: Thu, 20 Jul 2006 17:01:24 -0700
Subject: [LinuxBIOS] ultra 40 linuxbios
In-Reply-To: <44C0139F.5020403@lanl.gov>
References: <44C0139F.5020403@lanl.gov>
Message-ID: <ec9b26620607201701h53d6ce97w389649f551ed7951@mail.google.com>

...and yet they somehow forgot to mention "Needs a serial port" on their
"Perspectives" page (
http://www.sun.com/desktop/workstation/ultra40/perspectives.jsp ).

On 7/20/06, Ronald G Minnich <rminnich at lanl.gov> wrote:
>
> well, I've got this sun ultra 40, nice box, sun-designed mobo, lots of
> clever stuff.
>
> And, for some reason, they did not put on a serial port.
>
> Thus proving that it is possible to be too clever. Oh well, now the fun
> begins. I guess it will get worse from here on out.
>
> Please, mobo vendors, just put on the serial port. USB is not an option.
>
> ron
>
> --
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060720/f9efd53f/attachment.html>

From bari at onelabs.com  Fri Jul 21 02:29:19 2006
From: bari at onelabs.com (Bari Ari)
Date: Thu, 20 Jul 2006 19:29:19 -0500
Subject: [LinuxBIOS] ultra 40 linuxbios
In-Reply-To: <44C0139F.5020403@lanl.gov>
References: <44C0139F.5020403@lanl.gov>
Message-ID: <44C01FDF.70907@onelabs.com>

Ronald G Minnich wrote:
> well, I've got this sun ultra 40, nice box, sun-designed mobo, lots of 
> clever stuff.
>
> And, for some reason, they did not put on a serial port.
>
> Thus proving that it is possible to be too clever. Oh well, now the fun 
> begins. I guess it will get worse from here on out.
>
> Please, mobo vendors, just put on the serial port. USB is not an option.
>
> ron
>
>   
The legacy of PC serial, parallel, IDE, floppy and PCI is fading away 
quickly. They were fine in their day, but slow by todays standards. They 
also used lots of board space since they were so wide.

As painful as it may be to let go. We just need to get USB support up 
for LinuxBIOS debug.

-Bari



From rminnich at gmail.com  Fri Jul 21 05:44:02 2006
From: rminnich at gmail.com (ron minnich)
Date: Thu, 20 Jul 2006 21:44:02 -0600
Subject: [LinuxBIOS] ultra 40 linuxbios
In-Reply-To: <44C01FDF.70907@onelabs.com>
References: <44C0139F.5020403@lanl.gov> <44C01FDF.70907@onelabs.com>
Message-ID: <13426df10607202044v14997a31l23453f02aeb996b2@mail.gmail.com>

On 7/20/06, Bari Ari <bari at onelabs.com> wrote:
>
>
> As painful as it may be to let go. We just need to get USB support up
> for LinuxBIOS debug.




ok, where do I start? I know you discussed this earlier but ... where do I
start pulling on the string to make usb debug work? I guess we have to solve
this. I'm just disappointed to have to be solving it just now :-)

I still think if they'd just put a serial header on these things, it would
sure help. There's always a superio and it's really only 3 little wires.

ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060720/ac7be8ba/attachment.html>

From a.borisov at tesv.tmb.ru  Fri Jul 21 06:41:23 2006
From: a.borisov at tesv.tmb.ru (Anton Borisov)
Date: Fri, 21 Jul 2006 08:41:23 +0400
Subject: [LinuxBIOS] Mainboard-Configuration
In-Reply-To: <44BFCF1A.5030302@inode.at>
References: <44B60C41.5010708@inode.at> <20060713114055.GA31231@coresystems.de>
	<44BFCF1A.5030302@inode.at>
Message-ID: <20060721084123.7cb18ac5.a.borisov@tesv.tmb.ru>

On Thu, 20 Jul 2006 20:44:42 +0200
Morly <little.martin at inode.at> wrote:

> I got the suggestion of a board named win-ent - MB-06047.
> Unfortunately I don't get any answer of the European shop.
> (I am from Austria!)

	They reply not very fast enough. But they do. I've asked sale price, if you're interested - drop an email to my box.


-Anton



From costa at gamic.com  Fri Jul 21 10:23:57 2006
From: costa at gamic.com (Marco Costa)
Date: Fri, 21 Jul 2006 10:23:57 +0200
Subject: [LinuxBIOS] ASUS K8N
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A42070040B4@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A42070040B4@ssvlexmb2.amd.com>
Message-ID: <uhf6p3-obk.ln1@legba.gamic.com>

Lu, Yinghai wrote:
> It is using NVIDIA nForce3 250.
> 
> You'd better to find one with Nvidia Nforce 4 or Ck804.
> 
> YH 

Do you think that K8N4-E Deluxe will work? 

Thanks again!

Marco




From indrek.kruusa at artecdesign.ee  Fri Jul 21 11:27:05 2006
From: indrek.kruusa at artecdesign.ee (Indrek Kruusa)
Date: Fri, 21 Jul 2006 12:27:05 +0300
Subject: [LinuxBIOS] [PATCH] GX2/OLPC hacked for Geode LX
Message-ID: <44C09DE9.5030109@artecdesign.ee>

Hi!

I have a small Geode LX + CS5536 board (433MHz, 128MB DDR, UART2 as serial).

With the help of those changes in GX2/OLPC target (patch attached) I 
have managed to boot it at least (it still doesn't load VSA nor boot any 
payload). The changes should be mostly marked with comment '// GX3' to 
ease further development.

This is really ugly hack...sorry guys. But some day I hope there will be 
correct LX support with separate target. I can't provide any timetable 
though nor say how much I can work on it.

But hey... linuxbios rules and I am keen to help.


thanks,
Indrek

-------------- next part --------------
A non-text attachment was scrubbed...
Name: olpc_patch_for_geode_lx.patch
Type: text/x-patch
Size: 28428 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060721/abb6a147/attachment.patch>

From bg.anil at gmail.com  Fri Jul 21 16:24:58 2006
From: bg.anil at gmail.com (Anil B G)
Date: Fri, 21 Jul 2006 19:54:58 +0530
Subject: [LinuxBIOS] Code flow of LinuxBIOS
Message-ID: <8b0974ca0607210724v49d7b6e7j46bdf0cbd3137f20@mail.gmail.com>

Hi,
 I was just trying to understand the code flow of LinuxBIOS on x86
architecture. I understood that on a power on (cold boot), there is a wait
for power good.
Later there is a transition from real mode to protected mode (32 bit).
The file that makes the transition is entry32.inc of src/cpu/x86/32bit
directory.
After this point I was not able to make able to make much progress as to
which part of the code is executed.
Any help in this regard will be helpful.
I did check through the available documentation in documentation directory
of the source tree, but
would appreciate if there are any pointers at the code level.

Regards
Anil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060721/e654fa6c/attachment.html>

From stepan at coresystems.de  Fri Jul 21 16:34:31 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Fri, 21 Jul 2006 16:34:31 +0200
Subject: [LinuxBIOS] Code flow of LinuxBIOS
In-Reply-To: <8b0974ca0607210724v49d7b6e7j46bdf0cbd3137f20@mail.gmail.com>
References: <8b0974ca0607210724v49d7b6e7j46bdf0cbd3137f20@mail.gmail.com>
Message-ID: <20060721143431.GA25317@coresystems.de>

* Anil B G <bg.anil at gmail.com> [060721 16:24]:
>  I was just trying to understand the code flow of LinuxBIOS on x86
> architecture.
> I understood that on a power on (cold boot), there is a wait for power good.
> Later there is a transition from real mode to protected mode (32 bit).
> The file that makes the transition is entry32.inc of src/cpu/x86/32bit
> directory.
> After this point I was not able to make able to make much progress as to which
> part of the code is executed.
> Any help in this regard will be helpful.

I wrote a small text about this when we started v2. It's obsolete in
some parts but it might help here and there. See the attachment.

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/
-------------- next part --------------
Ok, 

I think I got it now, except some minor things. I would like to add this
explanation to my LinuxBIOS document. Please help me advance it with
some expert comments, since I feel rather like a novice in this part of
the code. Has there been anyone describing this in detail, while
still being understandable? I remember seeing something a long time ago
for v1, but I couldnt find it in the archives anymore.

It seems that my current approach, leaving everything up to failover.c
untouched, might not be the best way to go. From early_mtrr.inc on we
have XIP acceleration available, thus it seems that we hook in after
this point, and do everything afterwards in gcc, creating an extra hunk
with an extra .lds file to pack it all into. 


reset16.[inc|lds]
-----------------
 Description:
  * code placed at reset vector (0xfffffff0)
  * jump to _start in entry16.inc
  * jump to protected_start in entry32.inc (what is this good for??)

 Comments:
  reset16.lds supports ROMBASEs smaller than 0xffff0000. reset16.inc does
  not. Do we ever need anything else on x86 based systems? If not, I
  suggest to drop the conditionals.
  It seems to me that the second jump is later done by entry16.inc, and
  the reset vector is never reached. Is it used by something else?

entry16.[inc|lds]
-----------------
 Description:
  * linker script provides 16bit versions of the addresses (?)
  * switch to protected mode.
  * jump to __protected_start in entry32.inc
 
 Comments:
  Can someone enlighten me on the restriction comments here? given that 
  we are always on a standard x86 system, we are always above
  0xffff0000?

entry32.[inc|lds]
-----------------
 Description:
  * linker script is a noop.
  * sets up all segment registers to the same value. (ROM_CODE_SEG)
  * falls through to bist32.inc

 Comments:
  there's two entry points here, protected_start and __protected_start.
  Are they both needed? protected_start seems to do the same thing as
  the end of entry16.inc.
  The comment states that we do something with memory here. It seems
  this is wrong, since we are far before enabling memory.

bist32.inc
----------
 Description:
  * Checks EAX for BIST failures.
  * if everything is ok, falls through (skipping next 
    files that put code in different sections: reset16.inc,
    cpu_reset.inc, id.inc) On K8 this goes to early_mtrr.inc

early_mtrr.inc
--------------
 Description:
  * set up variable and fixed mtrrs.
  * set up XIP

 Comments:
  Will this hurt C-A-R? Can we somehow derive the XIP addresses from the
  information that we know, making XIP more solid?

failover.c
----------
 Description:
  * romcc generated code
  * if normal boot, we jump into normal image.
  * if cpu reset, we jump into __cpu_reset, which jumps into 
    __main (Where is this one? crt0.base? auto.inc?)
  * if we're running on the second CPU, we jump into normal/fallback
    image (???)
  * if no problems appeared, jump into normal image
  * otherwise fall through (to auto.c ??)

 Comments:
  What's HAVE_REGPARM_SUPPORT? There's a lot of conditions in this file.
  I did not follow all the branches yet. Maybe someone can explain more?
  it seems that __cpu_reset jumps into __main - does this mean the dram
  init survives a cpu reset?


> -------------- part 1: creating init code -----------------------------
>  1) compile romcc
>  2) create option table
>  3) process and compile romcc based code
>  4) create crt0.o from romcc based code
> 
> -------------- part 2: creating payload -------------------------------
>  5) compile all drivers
>  6) compile all objects
>  7) compile static device tree
>  8) link objects and static tree --> linuxbios.a
>  9) create linuxbios_c from start.o, drivers and linuxbios.a
>  a) create linuxbios_payload from linuxbios_c (with or w/o nrv2b)
> 
> -------------- part 3: final image ------------------------------------
>  b) create "linuxbios" from crt0.o (including linuxbios_payload via
>     linker script arch/i386/config/ldscript.lb)
>  c) create romimage linuxbios.rom from "linuxbios" with buildrom



From rminnich at gmail.com  Fri Jul 21 17:07:16 2006
From: rminnich at gmail.com (ron minnich)
Date: Fri, 21 Jul 2006 09:07:16 -0600
Subject: [LinuxBIOS] ultra 40 linuxbios
In-Reply-To: <13426df10607202044v14997a31l23453f02aeb996b2@mail.gmail.com>
References: <44C0139F.5020403@lanl.gov> <44C01FDF.70907@onelabs.com>
	<13426df10607202044v14997a31l23453f02aeb996b2@mail.gmail.com>
Message-ID: <13426df10607210807u65be99c9p26fdcf4cff61a629@mail.gmail.com>

Another comment on serial that I recalled last night. On any pc-compatible
machine, from power on reset, a simple outb('0', 0x3f8) will get you output.
Having to put a  whole usb stack in there and get it working, for the same
effect -- UGH!

:-)

ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060721/df80636b/attachment.html>

From stepan at coresystems.de  Fri Jul 21 17:14:59 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Fri, 21 Jul 2006 17:14:59 +0200
Subject: [LinuxBIOS] ultra 40 linuxbios
In-Reply-To: <13426df10607210807u65be99c9p26fdcf4cff61a629@mail.gmail.com>
References: <44C0139F.5020403@lanl.gov> <44C01FDF.70907@onelabs.com>
	<13426df10607202044v14997a31l23453f02aeb996b2@mail.gmail.com>
	<13426df10607210807u65be99c9p26fdcf4cff61a629@mail.gmail.com>
Message-ID: <20060721151459.GA29472@coresystems.de>

* ron minnich <rminnich at gmail.com> [060721 17:07]:
> Another comment on serial that I recalled last night. On any pc-compatible
> machine, from power on reset, a simple outb('0', 0x3f8) will get you output.
> Having to put a  whole usb stack in there and get it working, for the same
> effect -- UGH!
 
Which is not really true in all cases. The SuperIO chip might very well
need initialization.

What scares me more than the USB stack (because I believe this is doable
in less than 100 lines for this very purpose of just using the _debug_
mode of EHCI) is that we need to see all PCI devices. This is pretty
much the same problem that keeps us from just plugging in a 10$/? PCI
Serial card: Slot's behind the bridge and we might not see it early
enough.

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From rminnich at lanl.gov  Fri Jul 21 18:07:10 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Fri, 21 Jul 2006 10:07:10 -0600
Subject: [LinuxBIOS] Code flow of LinuxBIOS
In-Reply-To: <8b0974ca0607210724v49d7b6e7j46bdf0cbd3137f20@mail.gmail.com>
References: <8b0974ca0607210724v49d7b6e7j46bdf0cbd3137f20@mail.gmail.com>
Message-ID: <44C0FBAE.2080505@lanl.gov>

Anil B G wrote:
> Hi,
>  I was just trying to understand the code flow of LinuxBIOS on x86 
> architecture.
> I understood that on a power on (cold boot), there is a wait for power good.
> Later there is a transition from real mode to protected mode (32 bit).
> The file that makes the transition is entry32.inc of src/cpu/x86/32bit 
> directory.
> After this point I was not able to make able to make much progress as to 
> which part of the code is executed.
> Any help in this regard will be helpful.
> I did check through the available documentation in documentation 
> directory of the source tree, but
> would appreciate if there are any pointers at the code level.
>  
> Regards
> Anil
> 
build a target and cd into the directory and type 'make documentation'. 
not perfect but it can help.

ron



From rminnich at lanl.gov  Fri Jul 21 18:08:27 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Fri, 21 Jul 2006 10:08:27 -0600
Subject: [LinuxBIOS] ultra 40 linuxbios
In-Reply-To: <20060721151459.GA29472@coresystems.de>
References: <44C0139F.5020403@lanl.gov>
	<44C01FDF.70907@onelabs.com>	<13426df10607202044v14997a31l23453f02aeb996b2@mail.gmail.com>	<13426df10607210807u65be99c9p26fdcf4cff61a629@mail.gmail.com>
	<20060721151459.GA29472@coresystems.de>
Message-ID: <44C0FBFB.70804@lanl.gov>

Stefan Reinauer wrote:
> * ron minnich <rminnich at gmail.com> [060721 17:07]:
> 
>>Another comment on serial that I recalled last night. On any pc-compatible
>>machine, from power on reset, a simple outb('0', 0x3f8) will get you output.
>>Having to put a  whole usb stack in there and get it working, for the same
>>effect -- UGH!
> 
>  
> Which is not really true in all cases. The SuperIO chip might very well
> need initialization.

very true ...

> 
> What scares me more than the USB stack (because I believe this is doable
> in less than 100 lines for this very purpose of just using the _debug_
> mode of EHCI) 

that's encouraging :-)

I guess we just gotta write it.

ron



From stepan at coresystems.de  Fri Jul 21 18:13:08 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Fri, 21 Jul 2006 18:13:08 +0200
Subject: [LinuxBIOS] ultra 40 linuxbios
In-Reply-To: <44C0FBFB.70804@lanl.gov>
References: <44C0139F.5020403@lanl.gov> <44C01FDF.70907@onelabs.com>
	<13426df10607202044v14997a31l23453f02aeb996b2@mail.gmail.com>
	<13426df10607210807u65be99c9p26fdcf4cff61a629@mail.gmail.com>
	<20060721151459.GA29472@coresystems.de> <44C0FBFB.70804@lanl.gov>
Message-ID: <20060721161308.GA32650@coresystems.de>

* Ronald G Minnich <rminnich at lanl.gov> [060721 18:08]:
> >What scares me more than the USB stack (because I believe this is doable
> >in less than 100 lines for this very purpose of just using the _debug_
> >mode of EHCI) 
> 
> that's encouraging :-)
> 
> I guess we just gotta write it.

Ugly is: The only cable that works we know of is not available anymore.
So if we start to solder something we dont really know which part is
wrong, the code or the cable.. But some people on this list might know
an answer to this one.

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From stepan at coresystems.de  Fri Jul 21 18:29:51 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Fri, 21 Jul 2006 18:29:51 +0200
Subject: [LinuxBIOS] LinuxBIOS Summit Europe 2006
Message-ID: <20060721162951.GA31959@coresystems.de>

Dear LinuxBIOS community,

after the LinuxBIOS summit in Santa Fe last October was a very good 
success, we are looking forward to have a LinuxBIOS summit again this
year. 

To make it easier for those who could not attend last year we are
planning to have the summit in Germany.

Topics will roughly cover the development news since last year, the
goals for LinuxBIOS in the future and of course having a good time
together.

We currently have two possible dates. The earlier would be October 1st 
to October 3rd. The Later would be somewhen in early December.

Please mail me (private mail) whether you are interested to join the
summit and which date you would prefer (October or December). So we can
do further planning.

Thanks and have a nice weekend,

Stefan


-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From rminnich at lanl.gov  Fri Jul 21 18:32:13 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Fri, 21 Jul 2006 10:32:13 -0600
Subject: [LinuxBIOS] ultra 40 linuxbios
In-Reply-To: <20060721161308.GA32650@coresystems.de>
References: <44C0139F.5020403@lanl.gov>
	<44C01FDF.70907@onelabs.com>	<13426df10607202044v14997a31l23453f02aeb996b2@mail.gmail.com>	<13426df10607210807u65be99c9p26fdcf4cff61a629@mail.gmail.com>	<20060721151459.GA29472@coresystems.de>
	<44C0FBFB.70804@lanl.gov> <20060721161308.GA32650@coresystems.de>
Message-ID: <44C1018D.6050802@lanl.gov>

Stefan Reinauer wrote:
> * Ronald G Minnich <rminnich at lanl.gov> [060721 18:08]:
> 
>>>What scares me more than the USB stack (because I believe this is doable
>>>in less than 100 lines for this very purpose of just using the _debug_
>>>mode of EHCI) 
>>
>>that's encouraging :-)
>>
>>I guess we just gotta write it.
> 
> 
> Ugly is: The only cable that works we know of is not available anymore.
> So if we start to solder something we dont really know which part is
> wrong, the code or the cable.. But some people on this list might know
> an answer to this one.
> 
> Stefan
> 

I can test on OLPC. We're booting into ash out of linuxbios into a 
minimal environment. We can build a linux with no usb and test simple 
programs that drive it.

maybe.

ron



From acassis at gmail.com  Fri Jul 21 21:41:01 2006
From: acassis at gmail.com (Alan Carvalho de Assis)
Date: Fri, 21 Jul 2006 13:41:01 -0600
Subject: [LinuxBIOS] Flashrom support to VIA VT8235
In-Reply-To: <44C11EDB.60402@lanl.gov>
References: <37367b3a0607201651k27262d1do2e41fd6e331d6b5d@mail.gmail.com>
	<44C018A2.9000903@lanl.gov>
	<37367b3a0607211034n6212209ei16f65fe7d743c8c5@mail.gmail.com>
	<44C11EDB.60402@lanl.gov>
Message-ID: <37367b3a0607211241m3dec5038w4d2e832e6e9712e1@mail.gmail.com>

Hi Ron,
I ignored this lspci info, because on the chip solded in MB is impress:

         V/A
      VT8235
0430CE CHINA
  23B1913461

What is correct? The name impressed on chip or the info returned by lspci ?

Thank you,

Alan

On 7/21/06, Ronald G Minnich <rminnich at lanl.gov> wrote:
> it's an 8237, not an 8235 ... doyou have a data book?
>
> ron
>


-- 
------------------------------------------------------------
|                     Alan Carvalho de Assis                |
------------------------------------------------------------
--
N?o importa o que os outros ir?o pensar,
A cura para a infelicidade ? a felicidade



From rminnich at lanl.gov  Fri Jul 21 21:45:56 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Fri, 21 Jul 2006 13:45:56 -0600
Subject: [LinuxBIOS] Flashrom support to VIA VT8235
In-Reply-To: <37367b3a0607211241m3dec5038w4d2e832e6e9712e1@mail.gmail.com>
References: <37367b3a0607201651k27262d1do2e41fd6e331d6b5d@mail.gmail.com>	<44C018A2.9000903@lanl.gov>	<37367b3a0607211034n6212209ei16f65fe7d743c8c5@mail.gmail.com>	<44C11EDB.60402@lanl.gov>
	<37367b3a0607211241m3dec5038w4d2e832e6e9712e1@mail.gmail.com>
Message-ID: <44C12EF4.40205@lanl.gov>

Alan Carvalho de Assis wrote:
> Hi Ron,
> I ignored this lspci info, because on the chip solded in MB is impress:
> 
>          V/A
>       VT8235
> 0430CE CHINA
>   23B1913461
> 
> What is correct? The name impressed on chip or the info returned by lspci ?
>

lspci. The name on the chip is not trustworthy.

ron



From bari at onelabs.com  Fri Jul 21 22:35:44 2006
From: bari at onelabs.com (Bari Ari)
Date: Fri, 21 Jul 2006 15:35:44 -0500
Subject: [LinuxBIOS] USB Host to Host Debug Dongle/Cable
Message-ID: <44C13AA0.3020108@onelabs.com>

SemiconductorStore.com has several of the the USB debug cables currently 
in stock for $80:

http://shop.semiconductorstore.com/iwwida.pvx?;item?item_no=NET20DC%20%20%20%20%20%20%20%201?comp=SYM 


They say that PLX is still processing orders for them as well.

-Bari



From anish.mailing.list at gmail.com  Fri Jul 21 23:11:28 2006
From: anish.mailing.list at gmail.com (Anish Patel)
Date: Fri, 21 Jul 2006 17:11:28 -0400
Subject: [LinuxBIOS] Problems with 2 identical drives
Message-ID: <44C14300.90905@gmail.com>

Hello all,
    we are working on linux bios for a board of ours and are having 
trouble seeing 2 SATA drives when they are identical.
we have tried 2 different sata drives and that works fine, and it also 
works fine with the 2 identical drives and factory BIOS.
please advise.


Anish Patel




From rminnich at lanl.gov  Fri Jul 21 23:14:45 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Fri, 21 Jul 2006 15:14:45 -0600
Subject: [LinuxBIOS] USB Host to Host Debug Dongle/Cable
In-Reply-To: <44C13AA0.3020108@onelabs.com>
References: <44C13AA0.3020108@onelabs.com>
Message-ID: <44C143C5.2040301@lanl.gov>

Bari Ari wrote:
> SemiconductorStore.com has several of the the USB debug cables currently 
> in stock for $80:
> 
> http://shop.semiconductorstore.com/iwwida.pvx?;item?item_no=NET20DC%20%20%20%20%20%20%20%201?comp=SYM 
> 
> 
> They say that PLX is still processing orders for them as well.

yes, but ... depending on obsolete hardware for future debug strategy is 
not a good plan.

ron



From busry2 at cox.net  Sat Jul 22 00:30:26 2006
From: busry2 at cox.net (Brent Usry)
Date: Fri, 21 Jul 2006 15:30:26 -0700
Subject: [LinuxBIOS]  USB Support <WAS Re:  Accessibility of LinuxBios>
Message-ID: <000501c6ad15$436a3470$4c67c148@LIFEBOOK>

I have a Fry's fm 7770 http://www.fryssupport.net/fs7770.cfm
That I was going to put linux on anyway. I had been trying to put fedora on  for a few installs and it would not boot so I was messing with the bios and now I can not get the monitor to stay on at all and it reboots when I turn it off and it is having alot of problems. All I want is to get that Virus (Windows completely off) fix the bios and get on with a nice long life with linux. Will the linuxbios project work on my pc?
Thanks
Brent Usry
brent at usry.com
www.paranoidrandrants.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060721/d62a116c/attachment.html>

From dpd at alphalink.com.au  Sat Jul 22 01:28:10 2006
From: dpd at alphalink.com.au (Denis Dowling)
Date: Sat, 22 Jul 2006 09:28:10 +1000
Subject: [LinuxBIOS] USB Host to Host Debug Dongle/Cable
In-Reply-To: <44C143C5.2040301@lanl.gov>
References: <44C13AA0.3020108@onelabs.com> <44C143C5.2040301@lanl.gov>
Message-ID: <44C1630A.30002@alphalink.com.au>

There are a couple of other "ports" on a PC that could be used for 
initial debugging. I have used a spare IDE channel as a general 8 bit IO 
port. In fact you can address up to 8 different ports per channel. A 
simple outb(b, 0x170) gets reflected on the port. This is dead easy to 
interface with. Connect a logic analyser or a small circuit and then 
just write to the port. Does not help if the IDE sits out on the PCI bus 
though.

Another thought would be to tap the SMBus signals. These are routed to 
all memory DIMMS. With some careful soldering you can tap the signals 
off the DIMM to a logic analyser. The code can then just write to an 
unised i2c address.

Regards,
Denis.

Ronald G Minnich wrote:
> Bari Ari wrote:
>   
>> SemiconductorStore.com has several of the the USB debug cables currently 
>> in stock for $80:
>>
>> http://shop.semiconductorstore.com/iwwida.pvx?;item?item_no=NET20DC%20%20%20%20%20%20%20%201?comp=SYM 
>>
>>
>> They say that PLX is still processing orders for them as well.
>>     
>
> yes, but ... depending on obsolete hardware for future debug strategy is 
> not a good plan.
>
> ron
>
>   




From dhendrix at google.com  Sat Jul 22 03:13:01 2006
From: dhendrix at google.com (David Hendricks)
Date: Fri, 21 Jul 2006 18:13:01 -0700
Subject: [LinuxBIOS] LinuxBIOS Summit Europe 2006
In-Reply-To: <20060721162951.GA31959@coresystems.de>
References: <20060721162951.GA31959@coresystems.de>
Message-ID: <ec9b26620607211813w5bf1fd06ta7c6ad68b364c868@mail.google.com>

I probably will not be able to attend due to school. Will it be possible to
record the conference and distribute in XviD or something? I'm willing to
donate a signifficant amount of money for a nice digital camcorder.

On 7/21/06, Stefan Reinauer <stepan at coresystems.de> wrote:
>
> Dear LinuxBIOS community,
>
> after the LinuxBIOS summit in Santa Fe last October was a very good
> success, we are looking forward to have a LinuxBIOS summit again this
> year.
>
> To make it easier for those who could not attend last year we are
> planning to have the summit in Germany.
>
> Topics will roughly cover the development news since last year, the
> goals for LinuxBIOS in the future and of course having a good time
> together.
>
> We currently have two possible dates. The earlier would be October 1st
> to October 3rd. The Later would be somewhen in early December.
>
> Please mail me (private mail) whether you are interested to join the
> summit and which date you would prefer (October or December). So we can
> do further planning.
>
> Thanks and have a nice weekend,
>
> Stefan
>
>
> --
> coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
>       Tel.: +49 761 7668825 ? Fax: +49 761 7664613
> Email: info at coresystems.de  ? http://www.coresystems.de/
>
> --
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060721/426f2eae/attachment.html>

From yinghailu at gmail.com  Sat Jul 22 04:00:18 2006
From: yinghailu at gmail.com (yhlu)
Date: Fri, 21 Jul 2006 19:00:18 -0700
Subject: [LinuxBIOS] ASUS K8N
In-Reply-To: <uhf6p3-obk.ln1@legba.gamic.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A42070040B4@ssvlexmb2.amd.com>
	<uhf6p3-obk.ln1@legba.gamic.com>
Message-ID: <2ea3fae10607211900o15a4f40aj6c51df02cf3d2957@mail.gmail.com>

It is using NVIDIA nForce3 too.

YH

On 7/21/06, Marco Costa <costa at gamic.com> wrote:
> Lu, Yinghai wrote:
> > It is using NVIDIA nForce3 250.
> >
> > You'd better to find one with Nvidia Nforce 4 or Ck804.
> >
> > YH
>
> Do you think that K8N4-E Deluxe will work?
>
> Thanks again!
>
> Marco
>
>
> --
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>



From yinghailu at gmail.com  Sat Jul 22 04:06:45 2006
From: yinghailu at gmail.com (yhlu)
Date: Fri, 21 Jul 2006 19:06:45 -0700
Subject: [LinuxBIOS] Code flow of LinuxBIOS
In-Reply-To: <44C0FBAE.2080505@lanl.gov>
References: <8b0974ca0607210724v49d7b6e7j46bdf0cbd3137f20@mail.gmail.com>
	<44C0FBAE.2080505@lanl.gov>
Message-ID: <2ea3fae10607211906h940c5a0mc288df4c5391ebb2@mail.gmail.com>

yes, just find the crt0.s in the build dir.

YH

On 7/21/06, Ronald G Minnich <rminnich at lanl.gov> wrote:
> Anil B G wrote:
> > Hi,
> >  I was just trying to understand the code flow of LinuxBIOS on x86
> > architecture.
> > I understood that on a power on (cold boot), there is a wait for power good.
> > Later there is a transition from real mode to protected mode (32 bit).
> > The file that makes the transition is entry32.inc of src/cpu/x86/32bit
> > directory.
> > After this point I was not able to make able to make much progress as to
> > which part of the code is executed.
> > Any help in this regard will be helpful.
> > I did check through the available documentation in documentation
> > directory of the source tree, but
> > would appreciate if there are any pointers at the code level.
> >
> > Regards
> > Anil
> >
> build a target and cd into the directory and type 'make documentation'.
> not perfect but it can help.
>
> ron
>
> --
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>



From dhendrix at google.com  Sat Jul 22 04:07:40 2006
From: dhendrix at google.com (David Hendricks)
Date: Fri, 21 Jul 2006 19:07:40 -0700
Subject: [LinuxBIOS] ASUS K8N
In-Reply-To: <2ea3fae10607211900o15a4f40aj6c51df02cf3d2957@mail.gmail.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A42070040B4@ssvlexmb2.amd.com>
	<uhf6p3-obk.ln1@legba.gamic.com>
	<2ea3fae10607211900o15a4f40aj6c51df02cf3d2957@mail.gmail.com>
Message-ID: <ec9b26620607211907j1d03f926l6210482fefd56a86@mail.google.com>

I'm guessing that you are using an nForce3 board for a socket 754 processor.
The MSI K8N-Neo3 has a CK804 with a 754 pin socket, if that helps. I believe
there was even someone from MSI at the last LinuxBIOS summit, so at least
they have a clue :-)

On 7/21/06, yhlu <yinghailu at gmail.com> wrote:
>
> It is using NVIDIA nForce3 too.
>
> YH
>
> On 7/21/06, Marco Costa <costa at gamic.com> wrote:
> > Lu, Yinghai wrote:
> > > It is using NVIDIA nForce3 250.
> > >
> > > You'd better to find one with Nvidia Nforce 4 or Ck804.
> > >
> > > YH
> >
> > Do you think that K8N4-E Deluxe will work?
> >
> > Thanks again!
> >
> > Marco
> >
> >
> > --
> > linuxbios mailing list
> > linuxbios at linuxbios.org
> > http://www.openbios.org/mailman/listinfo/linuxbios
> >
>
> --
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060721/233c61b8/attachment.html>

From bari at onelabs.com  Sat Jul 22 06:48:05 2006
From: bari at onelabs.com (Bari Ari)
Date: Fri, 21 Jul 2006 23:48:05 -0500
Subject: [LinuxBIOS] USB Host to Host Debug Dongle/Cable
In-Reply-To: <44C143C5.2040301@lanl.gov>
References: <44C13AA0.3020108@onelabs.com> <44C143C5.2040301@lanl.gov>
Message-ID: <44C1AE05.5030207@onelabs.com>

Ronald G Minnich wrote:
> yes, but ... depending on obsolete hardware for future debug strategy 
> is not a good plan.
I'm still checking with PLX. If it's no longer produced, I may build 
some. There is not much to them. Just a USB Host to Host bridge.

-Bari



From bari at onelabs.com  Sat Jul 22 06:57:23 2006
From: bari at onelabs.com (Bari Ari)
Date: Fri, 21 Jul 2006 23:57:23 -0500
Subject: [LinuxBIOS] USB Host to Host Debug Dongle/Cable
In-Reply-To: <44C1630A.30002@alphalink.com.au>
References: <44C13AA0.3020108@onelabs.com> <44C143C5.2040301@lanl.gov>
	<44C1630A.30002@alphalink.com.au>
Message-ID: <44C1B033.2090308@onelabs.com>

Denis Dowling wrote:
> There are a couple of other "ports" on a PC that could be used for 
> initial debugging. I have used a spare IDE channel as a general 8 bit IO 
> port. In fact you can address up to 8 different ports per channel. A 
> simple outb(b, 0x170) gets reflected on the port. This is dead easy to 
> interface with. Connect a logic analyser or a small circuit and then 
> just write to the port. Does not help if the IDE sits out on the PCI bus 
> though.
>   
The problem here is that IDE is going the way of the serial port as 
well. Maybe a SATA debug module is a way to go. I could spin a simple 
FPGA based card for output.
> Another thought would be to tap the SMBus signals. These are routed to 
> all memory DIMMS. With some careful soldering you can tap the signals 
> off the DIMM to a logic analyser. The code can then just write to an 
> unised i2c address
A debug card could also be designed the same form factor as a memory 
dimm. It could be placed into an unused memory slot to debug via the 
SMbus. This is easier than the SATA method to build.

copyright c 2006, patent pending

-Bari



From stepan at coresystems.de  Sat Jul 22 07:53:44 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sat, 22 Jul 2006 07:53:44 +0200
Subject: [LinuxBIOS] LinuxBIOS Summit Europe 2006
In-Reply-To: <ec9b26620607211813w5bf1fd06ta7c6ad68b364c868@mail.google.com>
References: <20060721162951.GA31959@coresystems.de>
	<ec9b26620607211813w5bf1fd06ta7c6ad68b364c868@mail.google.com>
Message-ID: <20060722055344.GA563@coresystems.de>

* David Hendricks <dhendrix at google.com> [060722 03:13]:
> I probably will not be able to attend due to school. Will it be possible to
> record the conference and distribute in XviD or something? I'm willing to
> donate a signifficant amount of money for a nice digital camcorder.

Great idea! 

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From stepan at coresystems.de  Sat Jul 22 08:03:22 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sat, 22 Jul 2006 08:03:22 +0200
Subject: [LinuxBIOS] USB Host to Host Debug Dongle/Cable
In-Reply-To: <44C1B033.2090308@onelabs.com>
References: <44C13AA0.3020108@onelabs.com> <44C143C5.2040301@lanl.gov>
	<44C1630A.30002@alphalink.com.au> <44C1B033.2090308@onelabs.com>
Message-ID: <20060722060322.GC1243@coresystems.de>

* Bari Ari <bari at onelabs.com> [060722 06:57]:
> Denis Dowling wrote:
> A debug card could also be designed the same form factor as a memory 
> dimm. It could be placed into an unused memory slot to debug via the 
> SMbus. This is easier than the SATA method to build.
 
Instead of just building a "post card", could such a card hold 
a serial port or something?

> copyright c 2006, patent pending

So we're shot if we continue to talk about this? ;-)

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From stepan at coresystems.de  Sat Jul 22 09:01:41 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sat, 22 Jul 2006 09:01:41 +0200
Subject: [LinuxBIOS] a slight change to startup and elf images
In-Reply-To: <447EF52D.2080204@lanl.gov>
References: <447EF52D.2080204@lanl.gov>
Message-ID: <20060722070140.GA3743@coresystems.de>

* Ronald G Minnich <rminnich at lanl.gov> [060601 16:09]:
> Right now, we use mkelfimage to set up parameter blocks for linux. There 
> is a lot of code to do this, and I am running out of room on OLPC. I 
> need to build tiny elf images with on executable code in them (other 
> than your kernel, of course).
> 
> I have modified mkelfimage so that it produces an elfimage with only 3 
> segments: command line, kernel, initrd. With this option, you can build 
> a very simple elfimage with just those three things.
> 
> There is the issue of setting up %esi for 386 linux. I am considering 
> the following convention:
> 
> architecture-independent part (src/boot/)
> For the first PT_LOAD elf segment, assume it is the command line. Set a 
> variable, command_line, to the load address of this segment.
> 
> architecture-dependent, e.g. 386 (src/cpu/boot.c)
> set %esi to command_line.
> 
> If you are using normal mkelfimage, this is a no-op: esi setting is 
> ignored. If you are using mkelfimage with my option (e.g. OLPC), this 
> address will be used as the command line pointer.
> 
> I can't see a problem, any comments?

Is this part of the official version? Or should we put a version in the
LB tree? OR just a patch?


-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From ben at hewson-venieri.com  Sat Jul 22 14:49:20 2006
From: ben at hewson-venieri.com (Ben Hewson)
Date: Sat, 22 Jul 2006 13:49:20 +0100
Subject: [LinuxBIOS] EPIA 5000 motherboard
Message-ID: <44C21ED0.6020100@hewson-venieri.com>

I have recently downloaded from the repository, the latest LinuxBios
code. I have compiled this for the via/epia target to use filo as the
payload.
I have flashed the bios and everything verifies. However when I try to
boot the system it appears to be dead.
I am monitoring the serial output, but can't see any output. I have also
checked the serial output with a scope with no luck either.
Are there any know problems with the epia 5000 motherboard ?
Is there a known working version in the repository ?

I guess my next step will be to get hold of a POST card, but this will
probably take a few days at best.

Many thanks for any help.

Ben



From smithbone at gmail.com  Sun Jul 23 04:15:02 2006
From: smithbone at gmail.com (Richard Smith)
Date: Sat, 22 Jul 2006 21:15:02 -0500
Subject: [LinuxBIOS] USB Host to Host Debug Dongle/Cable
In-Reply-To: <44C143C5.2040301@lanl.gov>
References: <44C13AA0.3020108@onelabs.com> <44C143C5.2040301@lanl.gov>
Message-ID: <8a0c36780607221915k4e0ef142r178521c120f44482@mail.gmail.com>

>
> yes, but ... depending on obsolete hardware for future debug strategy is
> not a good plan.
>

I've been looking over the spec sheets and I think the larger problem
is not the external hardware or even the USB stack.

We have a somewhat unique situation in that its a Host-to-Host
connection and we control both sides of the cable.  At the bottom rung
USB is just a special packet of data with some preable and a checksum.
 Nothing says we have to do things the "USB" way.

I see having the target send control packets with the serial bytes in
them.  Are any of our debug prints greater than say 50 characters or
so?  Max control packet is 64 bytes and both sides must support that
since they are hosts.

I see having the target just spit OUTs with the debug data in them.

The debug host computer would need to put the USB bridge into some
sort of raw mode where you would just read the packets and dump them
to the screen.  Perhaps we could make some sort of software serial
device driver that could be opened by minicom or some other terminal
software.

None of that really concerns me.  Its fuzzy but I see a path.

What concerns me is a topic that Stefan already brought up.  Talking
to the USB bridge on the target.  AFAICT you have to have ram working
to use an [OUE]HCI controller.  You set up the base address on a 4k
RAM boundary, then the frame counter, then stuff the data your want to
send in ram and hit the go bit.

How are we going to do that when RAM is not up?

Can CAR make that work?  I don't know a lot about CAR but something
tells me the USB bridge can't fetch from inside the cache.

So even if USB can be made to fly I don't think it will serve our needs.

Stefan mentioned that a simple pci serial port adapter wouldn't really
work since you have to go through the serial bus to find it.

What about making a PCI card that ignored spec and always positively
decoded port 80 or 90 or what ever we picked.  Then you could stick it
in and data would come out whenever outs to that port happened.

I like Bari's idea of a DIMM module that sat on the SMbus. Thats cool.
 Getting the SMbus to work sometimes is a pain though.

If most new motherboards comming out now don't have serial ports on
them then how are the mfg's debugging the boards?  JTAG?  If so then I
think we better start learning how to do JTAG.  Of course the mfgs may
drop the jtag interface on a production run.

Its a tough issue.  But one we are going to have to solve.

-- 
Richard A. Smith



From bari at onelabs.com  Sun Jul 23 04:42:30 2006
From: bari at onelabs.com (Bari Ari)
Date: Sat, 22 Jul 2006 21:42:30 -0500
Subject: [LinuxBIOS] USB Host to Host Debug Dongle/Cable
In-Reply-To: <20060722060322.GC1243@coresystems.de>
References: <44C13AA0.3020108@onelabs.com> <44C143C5.2040301@lanl.gov>
	<44C1630A.30002@alphalink.com.au> <44C1B033.2090308@onelabs.com>
	<20060722060322.GC1243@coresystems.de>
Message-ID: <44C2E216.4080708@onelabs.com>

Stefan Reinauer wrote:
> * Bari Ari <bari at onelabs.com> [060722 06:57]:
>   
>> Denis Dowling wrote:
>> A debug card could also be designed the same form factor as a memory 
>> dimm. It could be placed into an unused memory slot to debug via the 
>> SMbus. This is easier than the SATA method to build.
>>     
>  
> Instead of just building a "post card", could such a card hold 
> a serial port or something?
>   
Good idea!  With the right level control a SMbus to USB or serial 
adapter could be used with the SMbus lines cabled to a module with the 
same mechanicals as a dimm or sodimm module with contacts for the SMbus.

I2C Bus to USB or serial adapters
http://www.mcc-us.com/catalog.htm#I2C%20Bus%20Host%20Adapters

I2C/SPI Host Adapter
http://www.totalphase.com/products/aardvark/

I2C Bus to USB or serial adapters
http://www.telos.info/products/

QBridge-I2C-USB
http://www.qprotos.com/index.html

SMBus Specs:
http://www.smbus.org/specs/

SMbus info:
http://www.interfacebus.com/Design_Connector_Smbus.html

-Bari



From smithbone at gmail.com  Sun Jul 23 04:56:31 2006
From: smithbone at gmail.com (Richard Smith)
Date: Sat, 22 Jul 2006 21:56:31 -0500
Subject: [LinuxBIOS] USB Host to Host Debug Dongle/Cable
In-Reply-To: <8a0c36780607221915k4e0ef142r178521c120f44482@mail.gmail.com>
References: <44C13AA0.3020108@onelabs.com> <44C143C5.2040301@lanl.gov>
	<8a0c36780607221915k4e0ef142r178521c120f44482@mail.gmail.com>
Message-ID: <8a0c36780607221956k6bcae62bx708670007d448087@mail.gmail.com>

>
> I like Bari's idea of a DIMM module that sat on the SMbus. Thats cool.
>  Getting the SMbus to work sometimes is a pain though.

Ooops looks like that was Denis's idea.  Sorry Denis.

-- 
Richard A. Smith



From bari at onelabs.com  Sun Jul 23 05:13:02 2006
From: bari at onelabs.com (Bari Ari)
Date: Sat, 22 Jul 2006 22:13:02 -0500
Subject: [LinuxBIOS] USB Host to Host Debug Dongle/Cable
In-Reply-To: <20060722060322.GC1243@coresystems.de>
References: <44C13AA0.3020108@onelabs.com> <44C143C5.2040301@lanl.gov>
	<44C1630A.30002@alphalink.com.au> <44C1B033.2090308@onelabs.com>
	<20060722060322.GC1243@coresystems.de>
Message-ID: <44C2E93E.5090202@onelabs.com>

Stefan Reinauer wrote:
> * Bari Ari <bari at onelabs.com> [060722 06:57]:
>   
>> Denis Dowling wrote:
>> A debug card could also be designed the same form factor as a memory 
>> dimm. It could be placed into an unused memory slot to debug via the 
>> SMbus. This is easier than the SATA method to build.
>>     
>  
> Instead of just building a "post card", could such a card hold 
> a serial port or something?
>   
This adapter even has Linux tools:
USB-I2C/SPI/GPIO Interface Adapter
http://www.diolan.com/i2c/u2c12.html

with a probe like this that slides into the dimm socket:
http://www.busboards.com/products/memory/ddrii/ddrii400dc/ddriidc.jpg
http://www.busboards.com/products/memory/ddrii/ddrii400dc/index.html

-Bari



From bari at onelabs.com  Sun Jul 23 05:42:44 2006
From: bari at onelabs.com (Bari Ari)
Date: Sat, 22 Jul 2006 22:42:44 -0500
Subject: [LinuxBIOS] USB Host to Host Debug Dongle/Cable
In-Reply-To: <8a0c36780607221915k4e0ef142r178521c120f44482@mail.gmail.com>
References: <44C13AA0.3020108@onelabs.com> <44C143C5.2040301@lanl.gov>
	<8a0c36780607221915k4e0ef142r178521c120f44482@mail.gmail.com>
Message-ID: <44C2F034.1030702@onelabs.com>

Richard Smith wrote:
> If most new motherboards comming out now don't have serial ports on
> them then how are the mfg's debugging the boards?  JTAG?  If so then I
> think we better start learning how to do JTAG.  Of course the mfgs may
> drop the jtag interface on a production run.
>
> Its a tough issue.  But one we are going to have to solve.
>
The chipset dev boards come with serial ports and several other debug 
connectors. The dev boards don't easily get into public hands though.

-Bari



From smithbone at gmail.com  Sun Jul 23 05:51:43 2006
From: smithbone at gmail.com (Richard Smith)
Date: Sat, 22 Jul 2006 22:51:43 -0500
Subject: [LinuxBIOS] USB Host to Host Debug Dongle/Cable
In-Reply-To: <44C2F034.1030702@onelabs.com>
References: <44C13AA0.3020108@onelabs.com> <44C143C5.2040301@lanl.gov>
	<8a0c36780607221915k4e0ef142r178521c120f44482@mail.gmail.com>
	<44C2F034.1030702@onelabs.com>
Message-ID: <8a0c36780607222051o4ba8dad6hc18c3fc3f80c2b5c@mail.gmail.com>

On 7/22/06, Bari Ari <bari at onelabs.com> wrote:

> >
> The chipset dev boards come with serial ports and several other debug
> connectors. The dev boards don't easily get into public hands though.

Thats what I was gussing was the answer but hoping otherwise.
By the time we get them the mfgs consider all the debugging done.

-- 
Richard A. Smith



From stuge-linuxbios at cdy.org  Sun Jul 23 07:54:32 2006
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Sun, 23 Jul 2006 07:54:32 +0200
Subject: [LinuxBIOS] USB Host to Host Debug Dongle/Cable
In-Reply-To: <8a0c36780607221915k4e0ef142r178521c120f44482@mail.gmail.com>
References: <44C13AA0.3020108@onelabs.com> <44C143C5.2040301@lanl.gov>
	<8a0c36780607221915k4e0ef142r178521c120f44482@mail.gmail.com>
Message-ID: <20060723055432.14077.qmail@cdy.org>

On Sat, Jul 22, 2006 at 09:15:02PM -0500, Richard Smith wrote:
> What concerns me is a topic that Stefan already brought up. 
> Talking to the USB bridge on the target.  AFAICT you have to have
> ram working to use an [OUE]HCI controller.  You set up the base
> address on a 4k RAM boundary, then the frame counter, then stuff
> the data your want to send in ram and hit the go bit.

Isn't the PCI register space and BAR contents decoded by the EHCI
controller to hardware registers?

"Only" PCI bus access is required for the EHCI debug mode if I
understand correctly, I don't even think it has to be completely
configured on the PCI bus. Appendix C of the EHCI 1.0 spec covers
the debug port.
http://www.intel.com/technology/usb/download/ehci-r10.pdf

While it seems that the connected device must be a Debug Class device
it would be quite possible to make a device compliant with the Debug
Class spec only on the target side and then have a regular serial
port on the other (host/remote) end.

I think a simple-as-possible circuit for a USB2 high-speed device
with a serial port is all that is needed.

Note that the debug port is an optional implementation feature of the
EHCI spec. Intel ICH6 implements it. Check your system with:

# lspci -vs $(lspci|grep EHCI|cut -f1 -d' ')
00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) USB2 EHCI Controller (rev 03) (prog-if 20 [EHCI])
        Subsystem: IBM Unknown device 0566
        Flags: bus master, medium devsel, latency 0, IRQ 5
        Memory at b0000000 (32-bit, non-prefetchable) [size=1K]
        Capabilities: [50] Power Management version 2
        Capabilities: [58] Debug port

The last line is the winner.

I just added a EHCI Debug Port wiki page to collect whatever we come
up with in this thread, and primed it with some of this info.
http://wiki.linuxbios.org/index.php/EHCI_Debug_Port


//Peter



From stepan at coresystems.de  Sun Jul 23 14:42:00 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sun, 23 Jul 2006 14:42:00 +0200
Subject: [LinuxBIOS] USB Host to Host Debug Dongle/Cable
In-Reply-To: <8a0c36780607221915k4e0ef142r178521c120f44482@mail.gmail.com>
References: <44C13AA0.3020108@onelabs.com> <44C143C5.2040301@lanl.gov>
	<8a0c36780607221915k4e0ef142r178521c120f44482@mail.gmail.com>
Message-ID: <20060723124200.GA7133@coresystems.de>

* Richard Smith <smithbone at gmail.com> [060723 04:15]:
> I see having the target send control packets with the serial bytes in
> them.  Are any of our debug prints greater than say 50 characters or
> so?  Max control packet is 64 bytes and both sides must support that
> since they are hosts.
 
Wait., USB2 Debug Mode has a maximum packet size of 8 bytes (64 _bits_)
Which is why it does not need RAM to operate:

Some general restrictions and operational differences result from the use
of the debug port rather than the standard host controller interface.
The main operational difference is packet/transfer size. The debug port
has a maximum packet size of eight bytes. Since this is smaller than the
USB2 High Speed control endpoint packet size of sixty-four bytes, this
also means that control transfers have a maximum transfer size of eight
bytes as well. Because of this limitation, the debug port driver cannot
use standard means to enumerate and configure debug devices.

> I see having the target just spit OUTs with the debug data in them.
 
Do you have a sample implementation?

> The debug host computer would need to put the USB bridge into some
> sort of raw mode where you would just read the packets and dump them
> to the screen.  Perhaps we could make some sort of software serial
> device driver that could be opened by minicom or some other terminal
> software.

Yes, this would definitely be the preferred method. The question is:
Does the end point really have to be in a special mode (debug mode as
well?)

> What concerns me is a topic that Stefan already brought up.  Talking
> to the USB bridge on the target.  AFAICT you have to have ram working
> to use an [OUE]HCI controller.

This applies to OHCI and UHCI. The "Debug mode" is a special operating
mode that needs support from the used EHCI controller. The EHCI
controllers used in the Intel ICH-x chips (for x>=5) support this, at
least. Presumably most others do so as well (AMD8111 has no working EHCI
at all iirc)

The downside of this is, like the SuperIO sequence needed to make serial
output working you probably need a (somewhat) southbridge specific sequence 
to enable this debug mode. (somewhat would mean: probably one per
vendor/generation)

> How are we going to do that when RAM is not up?
 
Not at all. USB 1.x chipsets are out of this scope. All we can look at
is 8byte bursts that are written to the USB2 debug registers in PCI
space. This is the whole delicacy of USB2 debug mode as far as I
understand it.

> So even if USB can be made to fly I don't think it will serve our needs.
 
I believe with above it should do the job.

> Stefan mentioned that a simple pci serial port adapter wouldn't really
> work since you have to go through the serial bus to find it.
 
And this was a wild guess. These adapters are available for below 10$.
Whoever can try this, please do. I would assume that this needs some
special initialization sequence at least as they are not connected via
the SuperIO chip, or are they? 

> What about making a PCI card that ignored spec and always positively
> decoded port 80 or 90 or what ever we picked.  Then you could stick it
> in and data would come out whenever outs to that port happened.

a port 80 card "with a memory" or a serial interface on the other side?
Sounds good. And works on all machines that have slots. This way port80
codes would not have a distinct meaning but be bytes written to 
the console

It seems to be on the horizon that there is not "1 final solution" to
this problem but rather "the most simple or cheapest solution for this or 
that purpose"

> I like Bari's idea of a DIMM module that sat on the SMbus. Thats cool.
>  Getting the SMbus to work sometimes is a pain though.

yes. port 80 monitoring would be easier.

> If most new motherboards comming out now don't have serial ports on
> them then how are the mfg's debugging the boards?  JTAG?  If so then I
> think we better start learning how to do JTAG.  Of course the mfgs may
> drop the jtag interface on a production run.

The problem as far as I can tell is that JTAG needs an extensive per
system adaption on the client side that is usually only available for
windows. Benefit is that we can single step, reflash and read memory and
a console with the same cable for less than 100$ (the software is where
the money is here.

The de facto standard open source tools are available here:
http://openwince.sourceforge.net/jtag/

but: they have not been updated since 2003 

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From little.martin at inode.at  Sun Jul 23 16:52:58 2006
From: little.martin at inode.at (Morly)
Date: Sun, 23 Jul 2006 16:52:58 +0200
Subject: [LinuxBIOS] ibase mb740
Message-ID: <44C38D4A.5050601@inode.at>

Hello,
does anybody know if the

IBASE MB740, Motherboard, Mini-ITX, Sockel for AMD
url: http://www.ibase-i.com.tw/mb740.htm

is compatible with linuxbios?

thanks,
morly




From smithbone at gmail.com  Sun Jul 23 18:23:57 2006
From: smithbone at gmail.com (Richard Smith)
Date: Sun, 23 Jul 2006 11:23:57 -0500
Subject: [LinuxBIOS] USB Host to Host Debug Dongle/Cable
In-Reply-To: <20060723124200.GA7133@coresystems.de>
References: <44C13AA0.3020108@onelabs.com> <44C143C5.2040301@lanl.gov>
	<8a0c36780607221915k4e0ef142r178521c120f44482@mail.gmail.com>
	<20060723124200.GA7133@coresystems.de>
Message-ID: <8a0c36780607230923s494cc1can99b96e2480753ecf@mail.gmail.com>

On 7/23/06, Stefan Reinauer <stepan at coresystems.de> wrote:
> * Richard Smith <smithbone at gmail.com> [060723 04:15]:
> > I see having the target send control packets with the serial bytes in
> > them.  Are any of our debug prints greater than say 50 characters or
> > so?  Max control packet is 64 bytes and both sides must support that
> > since they are hosts.
>
> Wait., USB2 Debug Mode has a maximum packet size of 8 bytes (64 _bits_)
> Which is why it does not need RAM to operate:

I should have clarified.  I was discounting the debug port (because
its optional) until its shown that its a common feature on 2.0
Bridges.

Neither of the the bridges on my laptop (NEC) or my desktop (VIA) show
a debug implementation.

> > I see having the target just spit OUTs with the debug data in them.
>
> Do you have a sample implementation?
>

No.. Its just a guess from the work I've done with my embedded USB
stack I have on another product.  The interface there is _much_
simpler all I have is a data FIFO and a few bits to tell me its done.
If I stuff data into the FIFO and hit write then out it goes.

I was looking at the specs to see what it would take to do something
similar with a (OUE)HCI but I stopped going much further when I saw
that I would need working RAM.

> Yes, this would definitely be the preferred method. The question is:
> Does the end point really have to be in a special mode (debug mode as
> well?)

I was thinking you  might need to bypass some of the timeouts and such.

> The problem as far as I can tell is that JTAG needs an extensive per
> system adaption on the client side that is usually only available for
> windows. Benefit is that we can single step, reflash and read memory and
> a console with the same cable for less than 100$ (the software is where
> the money is here.

> The de facto standard open source tools are available here:
> http://openwince.sourceforge.net/jtag/

They still work though.  I have a parallel port wiggler interface
thats a copy of an Altera byteblaster.  I had to make a small patch
(posted to OLPC) to fix up the compile but after that I was able to
dump a scan chain on one of my Altera boards just fine.

Not that that helps much.  Since like you said all the magic is in
knowing what to send down to the part.

-- 
Richard A. Smith



From bari at onelabs.com  Sun Jul 23 19:15:56 2006
From: bari at onelabs.com (Bari Ari)
Date: Sun, 23 Jul 2006 12:15:56 -0500
Subject: [LinuxBIOS] USB Host to Host Debug Dongle/Cable
In-Reply-To: <20060723124200.GA7133@coresystems.de>
References: <44C13AA0.3020108@onelabs.com>
	<44C143C5.2040301@lanl.gov>	<8a0c36780607221915k4e0ef142r178521c120f44482@mail.gmail.com>
	<20060723124200.GA7133@coresystems.de>
Message-ID: <44C3AECC.4080609@onelabs.com>

Stefan Reinauer wrote:
> * Richard Smith <smithbone at gmail.com> [060723 04:15]:
>   
>> Stefan mentioned that a simple pci serial port adapter wouldn't really
>> work since you have to go through the serial bus to find it.
>>     
>  
> And this was a wild guess. These adapters are available for below 10$.
> Whoever can try this, please do. I would assume that this needs some
> special initialization sequence at least as they are not connected via
> the SuperIO chip, or are they? 
>
>   
>> What about making a PCI card that ignored spec and always positively
>> decoded port 80 or 90 or what ever we picked.  Then you could stick it
>> in and data would come out whenever outs to that port happened.
>>     
>
> a port 80 card "with a memory" or a serial interface on the other side?
> Sounds good. And works on all machines that have slots. This way port80
> codes would not have a distinct meaning but be bytes written to 
> the console
>
> It seems to be on the horizon that there is not "1 final solution" to
> this problem but rather "the most simple or cheapest solution for this or 
> that purpose"
>
>   
PCIe is the direction in the PC world. PCI will still be around for 
years mainly for MIPS/ARM SOC based network devices, routers, bridges etc.

PCIe Serial Cards
http://www.serialgear.com/PCI-Express-Cards.html

One-port (9-pin) serial (16550 UART) x1 PCI Express card
http://www.siig.com/product.asp?pid=1020&catid=14

I haven't come across a PCIe Minicard to serial adapter yet.

-Bari



From rminnich at lanl.gov  Sun Jul 23 21:07:06 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Sun, 23 Jul 2006 13:07:06 -0600
Subject: [LinuxBIOS] USB Host to Host Debug Dongle/Cable
In-Reply-To: <20060723124200.GA7133@coresystems.de>
References: <44C13AA0.3020108@onelabs.com>
	<44C143C5.2040301@lanl.gov>	<8a0c36780607221915k4e0ef142r178521c120f44482@mail.gmail.com>
	<20060723124200.GA7133@coresystems.de>
Message-ID: <44C3C8DA.2050707@lanl.gov>

let's bring our demo USB systems to linuxbios summit. I'm serious.

thanks

ron



From stuge-linuxbios at cdy.org  Mon Jul 24 00:12:44 2006
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Mon, 24 Jul 2006 00:12:44 +0200
Subject: [LinuxBIOS] USB Host to Host Debug Dongle/Cable
In-Reply-To: <8a0c36780607230923s494cc1can99b96e2480753ecf@mail.gmail.com>
	<20060723124200.GA7133@coresystems.de>
References: <44C13AA0.3020108@onelabs.com> <44C143C5.2040301@lanl.gov>
	<8a0c36780607221915k4e0ef142r178521c120f44482@mail.gmail.com>
	<20060723124200.GA7133@coresystems.de>
	<8a0c36780607230923s494cc1can99b96e2480753ecf@mail.gmail.com>
	<44C13AA0.3020108@onelabs.com> <44C143C5.2040301@lanl.gov>
	<8a0c36780607221915k4e0ef142r178521c120f44482@mail.gmail.com>
	<20060723124200.GA7133@coresystems.de>
Message-ID: <20060723221244.13687.qmail@cdy.org>

On Sun, Jul 23, 2006 at 02:42:00PM +0200, Stefan Reinauer wrote:
> the debug port driver cannot use standard means to enumerate and
> configure debug devices.

Right. It only supports a single debug class device. And hardware
handles the enumeration and configuration in the target.


> Does the [host] end point really have to be in a special mode (debug
> mode as well?)

Not at all. The debug class spec only sets requirements for the
device edge connected to the target (aka remote) system.


> The downside of this is, like the SuperIO sequence needed to make
> serial output working you probably need a (somewhat) southbridge
> specific sequence to enable this debug mode.
> (somewhat would mean: probably one per vendor/generation)

Actually no. How to find the debug port registers in the EHCI PCI
configuration space is standardized by the EHCI spec.


> Not at all. USB 1.x chipsets are out of this scope. All we can look
> at is 8byte bursts that are written to the USB2 debug registers in
> PCI space. This is the whole delicacy of USB2 debug mode as far as
> I understand it.

Yep. Maybe even 1 byte packets would be best.


> > So even if USB can be made to fly I don't think it will serve our
> > needs.
>  
> I believe with above it should do the job.

Me too.


> It seems to be on the horizon that there is not "1 final solution"
> to this problem but rather "the most simple or cheapest solution
> for this or that purpose"

Options are nice. Especially since the debug port is optional.


On Sun, Jul 23, 2006 at 11:23:57AM -0500, Richard Smith wrote:
> I should have clarified.  I was discounting the debug port (because
> its optional) until its shown that its a common feature on 2.0
> Bridges.
> 
> Neither of the the bridges on my laptop (NEC) or my desktop (VIA)
> show a debug implementation.

Please add PCI ids and chip names on
http://wiki.linuxbios.org/index.php/EHCI_Debug_Port
or send me a quick message so I can do it.


> The interface there is _much_ simpler all I have is a data FIFO and
> a few bits to tell me its done.
> If I stuff data into the FIFO and hit write then out it goes.

The debug port works the same way. A few bytes control/status and 8
bytes data buffer.


> I was looking at the specs to see what it would take to do
> something similar with a (OUE)HCI but I stopped going much further
> when I saw that I would need working RAM.

Only EHCI.


> > Yes, this would definitely be the preferred method. The question
> > is: Does the end point really have to be in a special mode (debug
> > mode as well?)
> 
> I was thinking you  might need to bypass some of the timeouts and such.

All timing is handled by EHCI hardware. All the "debug port driver"
has to do is to touch the registers and away the transactions go.


//Peter



From wspraul at q-ag.de  Mon Jul 24 00:37:09 2006
From: wspraul at q-ag.de (Wolfgang Spraul)
Date: Mon, 24 Jul 2006 00:37:09 +0200
Subject: [LinuxBIOS] newbie: flashrom cannot find flash device
Message-ID: <44C3FA15.6040407@q-ag.de>

Hi there -
I'm trying to use LinuxBIOS to help me out with a problem I have with a 
recently acquired Panasonic R5 notebook: Panasonic decided to disable 
Intel Virtualization Support in the BIOS startup code (WRMSR instruction 
to set the lock bit in the CPU's Feature Control MSR) without giving me 
the option to override this in the BIOS menus or offering BIOS updates.

So my plan now is this: 'Download' my BIOS (PhoenixBIOS V1.00L13), 
disassemble & modify the WRMSR instruction, re-flash it onto the board 
(hopefully the BIOS instructions themselves are not compressed or 
encrypted).

First of all the latest (svn) flashrom does not detect my flash device. 
 From prior posts on this mailing lists I deduced I may have an 'Intel 
firmware hub'? No idea what that is...
flashrom -V output and lspci -V follow below.

My questions:
1) Is there a chance I can use flashrom to read/write my BIOS code. What 
is missing? Can anybody point me in any direction from the flashrom -V 
output below? Should I open the notebook to try to find any chip label?
2) Has anybody ever 'patched' an off-the-shelf PhoenixBIOS? Is that a 
realistic proposition at all, or will it be impossible because the 
binary is compressed/encrypted/signed/whatever?

Thanks for your help,
Wolfgang Spraul

--- flashrom -V output
Calibrating delay loop... Setting up microsecond timing loop
302M loops per second
ok
No LinuxBIOS table found.
Trying Am29F040B, 512 KB
probe_29f040b: id1 0x4e, id2 0x41
Trying Am29F016D, 2048 KB
probe_29f040b: id1 0xaa, id2 0x55
Trying At29C040A, 512 KB
probe_jedec: id1 0x4e, id2 0x41
Trying Mx29f002, 256 KB
probe_29f002: id1 0xf8, id2 0x57
Trying SST29EE020A, 256 KB
probe_jedec: id1 0xf8, id2 0x57
Trying SST28SF040A, 512 KB
probe_28sf040: id1 0x4e, id2 0x41
Trying SST39SF020A, 256 KB
probe_jedec: id1 0xf8, id2 0x57
Trying SST39VF020, 256 KB
probe_jedec: id1 0xf8, id2 0x57
Trying SST49LF040B, 512 KB
probe_jedec: id1 0x4e, id2 0x41
Trying SST49LF040, 512 KB
probe_jedec: id1 0x4e, id2 0x41
Trying SST49LF080A, 1024 KB
probe_jedec: id1 0xaa, id2 0x55
Trying SST49LF002A/B, 256 KB
probe_jedec: id1 0xf8, id2 0x57
Trying SST49LF003A/B, 384 KB
probe_jedec: id1 0x83, id2 0xd6
Trying SST49LF004A/B, 512 KB
probe_jedec: id1 0x4e, id2 0x41
Trying SST49LF008A, 1024 KB
probe_jedec: id1 0xaa, id2 0x55
Trying Pm49FL002, 256 KB
probe_jedec: id1 0xf8, id2 0x57
Trying Pm49FL004, 512 KB
probe_jedec: id1 0x4e, id2 0x41
Trying W29C011, 128 KB
probe_jedec: id1 0x99, id2 0x8a
Trying W29C020C, 256 KB
probe_jedec: id1 0xf8, id2 0x57
Trying W49F002U, 256 KB
probe_jedec: id1 0xf8, id2 0x57
Trying W49V002A, 256 KB
probe_jedec: id1 0xf8, id2 0x57
Trying W49V002FA, 256 KB
probe_jedec: id1 0xf8, id2 0x57
Trying W39V040A, 512 KB
probe_jedec: id1 0x4e, id2 0x41
Trying M29F040B, 512 KB
probe_29f040b: id1 0x4e, id2 0x41
Trying M29F400BT, 512 KB
probe_m29f400bt: id1 0x4e, id2 0x50
Trying 82802ab, 512 KB
probe_82802ab: id1 0x4e, id2 0x41
Trying 82802ac, 1024 KB
probe_82802ab: id1 0xaa, id2 0x55
Trying F49B002UA, 256 KB
probe_jedec: id1 0xf8, id2 0x57
Trying LHF00L04, 1024 KB
probe_lhf00l04: id1 0xaa, id2 0x55
No EEPROM/flash device found.

--- lspci -v output
00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 
945GT Express Memory Controller Hub (rev 03)
    Subsystem: Matsushita Electric Industrial Co., Ltd. Unknown device 8338
    Flags: bus master, fast devsel, latency 0
    Capabilities: [e0] Vendor Specific Information

00:02.0 VGA compatible controller: Intel Corporation Mobile 
945GM/GMS/940GML Express Integrated Graphics Controller (rev 03) 
(prog-if 00 [VGA])
    Subsystem: Matsushita Electric Industrial Co., Ltd. Unknown device 8338
    Flags: bus master, fast devsel, latency 0, IRQ 5
    Memory at d0200000 (32-bit, non-prefetchable) [size=512K]
    I/O ports at 1800 [size=8]
    Memory at c0000000 (32-bit, prefetchable) [size=256M]
    Memory at d0300000 (32-bit, non-prefetchable) [size=256K]
    Capabilities: [90] Message Signalled Interrupts: 64bit- Queue=0/0 
Enable-
    Capabilities: [d0] Power Management version 2

00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/940GML 
Express Integrated Graphics Controller (rev 03)
    Subsystem: Matsushita Electric Industrial Co., Ltd. Unknown device 8338
    Flags: bus master, fast devsel, latency 0
    Memory at d0280000 (32-bit, non-prefetchable) [size=512K]
    Capabilities: [d0] Power Management version 2

00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High 
Definition Audio Controller (rev 02)
    Subsystem: Matsushita Electric Industrial Co., Ltd. Unknown device 8338
    Flags: bus master, fast devsel, latency 0, IRQ 185
    Memory at d0340000 (64-bit, non-prefetchable) [size=16K]
    Capabilities: [50] Power Management version 2
    Capabilities: [60] Message Signalled Interrupts: 64bit+ Queue=0/0 
Enable-
    Capabilities: [70] Express Unknown type IRQ 0
    Capabilities: [100] Virtual Channel
    Capabilities: [130] Unknown (5)

00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express 
Port 1 (rev 02) (prog-if 00 [Normal decode])
    Flags: bus master, fast devsel, latency 0
    Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
    Capabilities: [40] Express Root Port (Slot+) IRQ 0
    Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 
Enable+
    Capabilities: [90] #0d [0000]
    Capabilities: [a0] Power Management version 2
    Capabilities: [100] Virtual Channel
    Capabilities: [180] Unknown (5)

00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express 
Port 3 (rev 02) (prog-if 00 [Normal decode])
    Flags: bus master, fast devsel, latency 0
    Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
    Memory behind bridge: d0000000-d00fffff
    Capabilities: [40] Express Root Port (Slot+) IRQ 0
    Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 
Enable+
    Capabilities: [90] #0d [0000]
    Capabilities: [a0] Power Management version 2
    Capabilities: [100] Virtual Channel
    Capabilities: [180] Unknown (5)

00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI 
#1 (rev 02) (prog-if 00 [UHCI])
    Subsystem: Matsushita Electric Industrial Co., Ltd. Unknown device 8338
    Flags: bus master, medium devsel, latency 0, IRQ 217
    I/O ports at 1820 [size=32]

00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI 
#2 (rev 02) (prog-if 00 [UHCI])
    Subsystem: Matsushita Electric Industrial Co., Ltd. Unknown device 8338
    Flags: bus master, medium devsel, latency 0, IRQ 225
    I/O ports at 1840 [size=32]

00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI 
#3 (rev 02) (prog-if 00 [UHCI])
    Subsystem: Matsushita Electric Industrial Co., Ltd. Unknown device 8338
    Flags: bus master, medium devsel, latency 0, IRQ 177
    I/O ports at 1860 [size=32]

00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI 
#4 (rev 02) (prog-if 00 [UHCI])
    Subsystem: Matsushita Electric Industrial Co., Ltd. Unknown device 8338
    Flags: bus master, medium devsel, latency 0, IRQ 233
    I/O ports at 1880 [size=32]

00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI 
Controller (rev 02) (prog-if 20 [EHCI])
    Subsystem: Matsushita Electric Industrial Co., Ltd. Unknown device 8338
    Flags: bus master, medium devsel, latency 0, IRQ 217
    Memory at d0544000 (32-bit, non-prefetchable) [size=1K]
    Capabilities: [50] Power Management version 2
    Capabilities: [58] Debug port

00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2) 
(prog-if 01 [Subtractive decode])
    Flags: bus master, fast devsel, latency 0
    Bus: primary=00, secondary=04, subordinate=05, sec-latency=32
    I/O behind bridge: 00002000-00002fff
    Memory behind bridge: d0100000-d01fffff
    Prefetchable memory behind bridge: 0000000030000000-0000000031f00000
    Capabilities: [50] #0d [0000]

00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface 
Bridge (rev 02)
    Subsystem: Matsushita Electric Industrial Co., Ltd. Unknown device 8338
    Flags: bus master, medium devsel, latency 0
    Capabilities: [e0] Vendor Specific Information

00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE 
Controller (rev 02) (prog-if 8a [Master SecP PriP])
    Subsystem: Matsushita Electric Industrial Co., Ltd. Unknown device 8338
    Flags: bus master, medium devsel, latency 0, IRQ 177
    I/O ports at <unassigned>
    I/O ports at <unassigned>
    I/O ports at <unassigned>
    I/O ports at <unassigned>
    I/O ports at 1810 [size=16]

00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller 
(rev 02)
    Subsystem: Matsushita Electric Industrial Co., Ltd. Unknown device 8338
    Flags: medium devsel, IRQ 11
    I/O ports at 18a0 [size=32]

03:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG 
Network Connection (rev 02)
    Subsystem: Intel Corporation Unknown device 1003
    Flags: bus master, fast devsel, latency 0, IRQ 7
    Memory at d0000000 (32-bit, non-prefetchable) [size=4K]
    Capabilities: [c8] Power Management version 2
    Capabilities: [d0] Message Signalled Interrupts: 64bit+ Queue=0/0 
Enable-
    Capabilities: [e0] Express Legacy Endpoint IRQ 0
    Capabilities: [100] Advanced Error Reporting
    Capabilities: [140] Device Serial Number c1-29-2b-ff-ff-02-13-00

04:01.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
RTL-8139/8139C/8139C+ (rev 10)
    Subsystem: Matsushita Electric Industrial Co., Ltd. Unknown device 8338
    Flags: bus master, medium devsel, latency 32, IRQ 225
    I/O ports at 2000 [size=256]
    Memory at d0100000 (32-bit, non-prefetchable) [size=256]
    Capabilities: [50] Power Management version 2

04:05.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev 8d)
    Subsystem: Matsushita Electric Industrial Co., Ltd. Unknown device 8338
    Flags: bus master, medium devsel, latency 168, IRQ 185
    Memory at d0101000 (32-bit, non-prefetchable) [size=4K]
    Bus: primary=04, secondary=05, subordinate=08, sec-latency=176
    Memory window 0: 30000000-31fff000 (prefetchable)
    Memory window 1: 32000000-33fff000
    I/O window 0: 00002400-000024ff
    I/O window 1: 00002800-000028ff
    16-bit legacy interface ports at 0001

04:05.1 Class 0805: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host 
Adapter (rev 13)
    Subsystem: Matsushita Electric Industrial Co., Ltd. Unknown device 8338
    Flags: bus master, medium devsel, latency 32, IRQ 11
    Memory at d0100400 (32-bit, non-prefetchable) [size=256]
    Capabilities: [80] Power Management version 2





From bari at onelabs.com  Mon Jul 24 04:59:25 2006
From: bari at onelabs.com (Bari Ari)
Date: Sun, 23 Jul 2006 21:59:25 -0500
Subject: [LinuxBIOS] newbie: flashrom cannot find flash device
In-Reply-To: <44C3FA15.6040407@q-ag.de>
References: <44C3FA15.6040407@q-ag.de>
Message-ID: <44C4378D.1080606@onelabs.com>

Wolfgang Spraul wrote:
> Hi there -
> I'm trying to use LinuxBIOS to help me out with a problem I have with a 
> recently acquired Panasonic R5 notebook: Panasonic decided to disable 
> Intel Virtualization Support in the BIOS startup code (WRMSR instruction 
> to set the lock bit in the CPU's Feature Control MSR) without giving me 
> the option to override this in the BIOS menus or offering BIOS updates.
>
> So my plan now is this: 'Download' my BIOS (PhoenixBIOS V1.00L13), 
> disassemble & modify the WRMSR instruction, re-flash it onto the board 
> (hopefully the BIOS instructions themselves are not compressed or 
> encrypted).
>
> First of all the latest (svn) flashrom does not detect my flash device. 
>  From prior posts on this mailing lists I deduced I may have an 'Intel 
> firmware hub'? No idea what that is...
> flashrom -V output and lspci -V follow below.
>
> My questions:
> 1) Is there a chance I can use flashrom to read/write my BIOS code. What 
> is missing? Can anybody point me in any direction from the flashrom -V 
> output below? Should I open the notebook to try to find any chip label?
> 2) Has anybody ever 'patched' an off-the-shelf PhoenixBIOS? Is that a 
> realistic proposition at all, or will it be impossible because the 
> binary is compressed/encrypted/signed/whatever?
>   

Guide to Award BIOS Reverse Engineering
http://www.geocities.com/mamanzip/Articles/Award_Bios_RE/Award_Bios_RE_guide.html




From smithbone at gmail.com  Mon Jul 24 06:48:27 2006
From: smithbone at gmail.com (Richard Smith)
Date: Sun, 23 Jul 2006 23:48:27 -0500
Subject: [LinuxBIOS] i440bx framework commited
Message-ID: <8a0c36780607232148k939854ep442ecc5b96ef4c0e@mail.gmail.com>

I fixed up and committed my i440bx mods and the beginnings of support
for the Bitworks IMS board that used this chipset.

Hopefull, someone else can take the time to fix my stupid SPD problem
and we can get this chipset up.

I've not been back to work to test so its compile tested only.  They
worked long ago (up to SPD) when I first created them so I'm guessing
they still boot.  The nrv2b compression is new since then but since
that works on other boards hopefully it dosen't break things.

The commit also adds support for NSC pc87351 superIO.

If you look at auto.c in mainboard/bitworks/IMS you will see that
dump_spd_registers() and sdram/generic_dump_spd.c are commented out.
That's because generic_dump_spd.c expects to find 2 memory controllers
and 440bx only has one so unless you mod generic_dump_spd.c to only
try one controller the compile will fail.  Rather than try to come up
with a fix I just left it as is and you just need to fixup your
install when you use dump_spd_registers() so that generic_dump_spd.c
only does 1 controller.  Again someone else feel free to fix this if
it bothers you.

I should be able to fire up my old hardware sometime later on this
week and verify that the image still boots.

-- 
Richard A. Smith



From smithbone at gmail.com  Mon Jul 24 06:50:32 2006
From: smithbone at gmail.com (Richard Smith)
Date: Sun, 23 Jul 2006 23:50:32 -0500
Subject: [LinuxBIOS] USB Host to Host Debug Dongle/Cable
In-Reply-To: <20060723221244.13687.qmail@cdy.org>
References: <44C13AA0.3020108@onelabs.com> <44C143C5.2040301@lanl.gov>
	<8a0c36780607221915k4e0ef142r178521c120f44482@mail.gmail.com>
	<8a0c36780607230923s494cc1can99b96e2480753ecf@mail.gmail.com>
	<20060723124200.GA7133@coresystems.de>
	<20060723221244.13687.qmail@cdy.org>
Message-ID: <8a0c36780607232150x445cd397wc5ffd3a97095529e@mail.gmail.com>

> Neither of the the bridges on my laptop (NEC) or my desktop (VIA)
> show a debug implementation.

> Please add PCI ids and chip names on
> http://wiki.linuxbios.org/index.php/EHCI_Debug_Port
> or send me a quick message so I can do it.

PCI: 1033:00e0
00:13.2 USB Controller: NEC Corporation USB 2.0 (rev 02) (prog-if 20 [EHCI])
        Subsystem: Compaq Computer Corporation Unknown device 0056
        Flags: bus master, medium devsel, latency 132, IRQ 11
        Memory at f0018c00 (32-bit, non-prefetchable) [size=256]
        Capabilities: [40] Power Management version 2

PCI: 1106:3104
00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82)
(prog-if 20 [EHCI])
        Subsystem: VIA Technologies, Inc. USB 2.0
        Flags: bus master, medium devsel, latency 32, IRQ 17
        Memory at dfffff00 (32-bit, non-prefetchable) [size=256]
        Capabilities: [80] Power Management version 2


-- 
Richard A. Smith



From info at coresystems.de  Mon Jul 24 07:02:43 2006
From: info at coresystems.de (LinuxBIOS information)
Date: Mon, 24 Jul 2006 07:02:43 +0200
Subject: [LinuxBIOS] LinuxBIOS r2347 build changes
Message-ID: <E1G4saZ-0007Ot-Lw@khepri.openbios.org>

Dear LinuxBIOS readers!

This is the automated build check service of LinuxBIOS.

The developer "rsmith" checked in revision 2347 to
the LinuxBIOS source repository and caused the following 
changes:

Change Log:
add framework for i440bx chipsetadd support for NSC pc87351 SuperIOadd Bitworks/IMS manboard configThis is a very basic framework for the i440bx chipset and theBitworks IMS board that uses it.  Most things arestructure only.Known issues:- SMbus reads to the RAM SPD come backall zero.- dump_spd_registers() is commented out since it breaks withthe default setting of generic_dump_spd.c where it wants2 memory controllers.

Build Log:
 Configuration of bitworks:ims has been fixed. Compilation of bitworks:ims has been fixed.

If something broke during this checkin please be a pain 
in rsmith's neck until the issue is fixed.

If this issue is not fixed within 24h the revision will 
be backed out.

   Yours truely,
     LinuxBIOS automatic build system





From costa at gamic.com  Mon Jul 24 10:53:57 2006
From: costa at gamic.com (Marco Costa)
Date: Mon, 24 Jul 2006 10:53:57 +0200
Subject: [LinuxBIOS] ASUS K8N
In-Reply-To: <ec9b26620607211907j1d03f926l6210482fefd56a86@mail.google.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A42070040B4@ssvlexmb2.amd.com>	<uhf6p3-obk.ln1@legba.gamic.com>	<2ea3fae10607211900o15a4f40aj6c51df02cf3d2957@mail.gmail.com>
	<ec9b26620607211907j1d03f926l6210482fefd56a86@mail.google.com>
Message-ID: <ceeep3-vtk.ln1@legba.gamic.com>

Hi David, Yinghai

First of all, thanks for the feedback.

David Hendricks wrote:
> I'm guessing that you are using an nForce3 board for a socket 754
> processor. The MSI K8N-Neo3 has a CK804 with a 754 pin socket, if that
> helps. I believe there was even someone from MSI at the last LinuxBIOS
> summit, so at least they have a clue :-)

It is good to see that companies are looking into open source solutions now. I think that the consumer pressure is building up.

> 
> On 7/21/06, *yhlu* <yinghailu at gmail.com <mailto:yinghailu at gmail.com>> wrote:
> 
>     It is using NVIDIA nForce3 too.

As I noted on Asus site, it lists it as a NForce4 4x (not full Hypertransport, only 800MHz as far as I understand). Is this not supported, then?

> 
>     YH
> 

Regards,

Marco Costa
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060724/0eeb4483/attachment.sig>

From stepan at coresystems.de  Mon Jul 24 11:21:55 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 24 Jul 2006 11:21:55 +0200
Subject: [LinuxBIOS] newbie: flashrom cannot find flash device
In-Reply-To: <44C3FA15.6040407@q-ag.de>
References: <44C3FA15.6040407@q-ag.de>
Message-ID: <20060724092155.GA10968@coresystems.de>

* Wolfgang Spraul <wspraul at q-ag.de> [060724 00:37]:
> 1) Is there a chance I can use flashrom to read/write my BIOS code. What 
> is missing? Can anybody point me in any direction from the flashrom -V 
> output below? Should I open the notebook to try to find any chip label?

:-( It looks like the bios of your machine also locks accesses to the
flash chip with some GPIO line. 

You might need to use the vendor supplied flash tool (or "invesitigate"
the bios image to see how the protection works)

 Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From danmez at gmail.com  Mon Jul 24 17:29:07 2006
From: danmez at gmail.com (Dan Mezynski)
Date: Mon, 24 Jul 2006 11:29:07 -0400
Subject: [LinuxBIOS] Code flow of LinuxBIOS
In-Reply-To: <8b0974ca0607210724v49d7b6e7j46bdf0cbd3137f20@mail.gmail.com>
References: <8b0974ca0607210724v49d7b6e7j46bdf0cbd3137f20@mail.gmail.com>
Message-ID: <7b7e71620607240829p3d5573ceydd3c23b3638b99ba@mail.gmail.com>

Hi,

I am also trying to get a clear understanding of the LB logical flow.  Our
company has a hardware simulator which we will use for initial testing
before trying on real hardware but it shouldn't make a difference to the LB
flow.  There are two flow charts that I've been looking at, you may have
already looked at them, the first is in section 8.3 of the Mangrove project
book under the documentation page of the web site.   The other flow chart is
in documentation/port guides/LinuxBios on AMD 64.  this flowchart has other
infomation and could be used with the first flowchart to fill in some
details.

When we reset the board then single step into it, the flow seems to go first
to crt0.s then C_start.s then to  hardwaremain.c, but I'm not sure this is
true for all boards and I assume certain include files are inserted into the
code for different configurations.

I hope this helps,

Dan

On 7/21/06, Anil B G <bg.anil at gmail.com> wrote:
>
> Hi,
>  I was just trying to understand the code flow of LinuxBIOS on x86
> architecture. I understood that on a power on (cold boot), there is a wait
> for power good.
> Later there is a transition from real mode to protected mode (32 bit).
> The file that makes the transition is entry32.inc of src/cpu/x86/32bit
> directory.
> After this point I was not able to make able to make much progress as to
> which part of the code is executed.
> Any help in this regard will be helpful.
> I did check through the available documentation in documentation directory
> of the source tree, but
> would appreciate if there are any pointers at the code level.
>
> Regards
> Anil
>
> --
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060724/9bb42e99/attachment.html>

From uwe at hermann-uwe.de  Mon Jul 24 17:39:12 2006
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Mon, 24 Jul 2006 17:39:12 +0200
Subject: [LinuxBIOS] LinuxBIOS Debian package.
Message-ID: <20060724153912.GB25437@aragorn>

Hi,

being a Debian developer I wondered wether it would make sense to create
one or more Debian packages for LinuxBIOS. It seems there are no
packages available at the moment - is this correct?

I'm not sure it makes sense to have the src/* and targets/* stuff
packaged (maybe it does), but some things would be nice, I guess.

For example (quick draft):

linuxbios - metapackage which draws in all/most other packages
linuxbios-doc - documentation
linuxbios-utils - standalone utilities, e.g. romcc, flashrom, ...

Maybe also something like linuxbios-src which contains the rest, and
which can be used to compile images(?)

Anyways, let me know if that makes sense or whether there are
problems (e.g. if you'd HAVE TO recompile romcc/flashrom/whatever every
time on your own, it doesn't make sense to package it)...


Cheers, Uwe.
-- 
Uwe Hermann 
http://www.hermann-uwe.de
http://www.it-services-uh.de  | http://www.crazy-hacks.org 
http://www.holsham-traders.de | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060724/e72db5dd/attachment.sig>

From indrek.kruusa at artecdesign.ee  Mon Jul 24 17:17:46 2006
From: indrek.kruusa at artecdesign.ee (Indrek Kruusa)
Date: Mon, 24 Jul 2006 18:17:46 +0300
Subject: [LinuxBIOS] [QUESTION] VSA2 for OLPC
Message-ID: <44C4E49A.9040603@artecdesign.ee>

Hi!

The VSA2 bios for OLPC seems to be quite minimal: 64 KB.

I would be glad to know:
- is there only vsainit and sysmgr inside vsa for olpc?
- does audio, ohci/ehci and video handled by kernel drivers?
- does OLPC target booting without major problems?

It seems to be true but it is better to know for sure ;)

Indrek




From stepan at coresystems.de  Mon Jul 24 18:16:20 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 24 Jul 2006 18:16:20 +0200
Subject: [LinuxBIOS] LinuxBIOS Debian package.
In-Reply-To: <20060724153912.GB25437@aragorn>
References: <20060724153912.GB25437@aragorn>
Message-ID: <20060724161620.GA6068@coresystems.de>

* Uwe Hermann <uwe at hermann-uwe.de> [060724 17:39]:
> being a Debian developer I wondered wether it would make sense to create
> one or more Debian packages for LinuxBIOS. It seems there are no
> packages available at the moment - is this correct?

right.

> I'm not sure it makes sense to have the src/* and targets/* stuff
> packaged (maybe it does), but some things would be nice, I guess.
> 
> For example (quick draft):
> 
> linuxbios - metapackage which draws in all/most other packages

ie. the other two?

> linuxbios-doc - documentation
> linuxbios-utils - standalone utilities, e.g. romcc, flashrom, ...
 
romcc is recompiled each time an image is built (which takes a lot less
time than running romcc)

> Maybe also something like linuxbios-src which contains the rest, and
> which can be used to compile images(?)

I would start out with "linuxbios-utils" as the only package and
pack flashrom, the lxbios tool (see fm). If you want to make it more
generic, you could call it firmware-utils or bios-utils and pack 
openbios' toke and detok with it.

> Anyways, let me know if that makes sense or whether there are
> problems (e.g. if you'd HAVE TO recompile romcc/flashrom/whatever every
> time on your own, it doesn't make sense to package it)...
 
The build process would have to be changed to use a prebuilt romcc, and
I don't think this makes too much sense, as everything works fine as is,
and there's no benefit to doing so.

Also, I would not swamp the repository with a number of packages just
for the sake of doing so (even though this is commonly accepted in debian
development) but look at target users of such a package and their
requirements. Having a flash utility like flashrom integrated definitely 
makes sense. Packing source code in packages in my opinion does not (ok,
the kernel may for some reason be an exception here)

Just my 2ct. We're happy about anything that improves the user range of
LinuxBIOS of course.

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From stuge-linuxbios at cdy.org  Mon Jul 24 18:28:53 2006
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Mon, 24 Jul 2006 18:28:53 +0200
Subject: [LinuxBIOS] LinuxBIOS Debian package.
In-Reply-To: <20060724153912.GB25437@aragorn>
References: <20060724153912.GB25437@aragorn>
Message-ID: <20060724162853.32440.qmail@cdy.org>

On Mon, Jul 24, 2006 at 05:39:12PM +0200, Uwe Hermann wrote:
> It seems there are no packages available at the moment - is this
> correct?

Yep. But not by design.


> I'm not sure it makes sense to have the src/* and targets/* stuff
> packaged (maybe it does), but some things would be nice, I guess.
> 
> For example (quick draft):
> 
> linuxbios - metapackage which draws in all/most other packages

This strikes me as a bad idea since users may get the impression that
apt-get install linuxbios would be all that is required to change
BIOS. While that would be very nice at some point I think we may not
be there quite yet. Ideally we should be able to programmatically
identify which mainboard a system is running on. Is this possible?
A fuctury BIOS checksum -> LB target whitelist perhaps?


> linuxbios-doc - documentation

Maybe more than one doc package since there are a few different kinds
of docs. I'm not familiar with debian package conventions so I don't
know what would be best.


> linuxbios-utils - standalone utilities, e.g. romcc, flashrom, ...

This makes sense, but ideally I think each util should be a separate
package. Again I don't know how well that fits into debian package
convetion.


> Maybe also something like linuxbios-src which contains the rest,
> and which can be used to compile images(?)

There are no real LB relases yet. Versioning would be done based on
snapshot date or svn revision.


//Peter



From rminnich at lanl.gov  Mon Jul 24 18:30:04 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 24 Jul 2006 10:30:04 -0600
Subject: [LinuxBIOS] [QUESTION] VSA2 for OLPC
In-Reply-To: <44C4E49A.9040603@artecdesign.ee>
References: <44C4E49A.9040603@artecdesign.ee>
Message-ID: <44C4F58C.8020701@lanl.gov>

Indrek Kruusa wrote:
> Hi!
> 
> The VSA2 bios for OLPC seems to be quite minimal: 64 KB.
> 
> I would be glad to know:
> - is there only vsainit and sysmgr inside vsa for olpc?
> - does audio, ohci/ehci and video handled by kernel drivers?
> - does OLPC target booting without major problems?
> 
> It seems to be true but it is better to know for sure ;)
> 
> Indrek
> 
> 

I have not tested audio. Yes, the 64K is intentionally small. We wanted 
to have in VSA at all, but could not kill it entirely.

ron



From ward at gnu.org  Mon Jul 24 18:41:24 2006
From: ward at gnu.org (Ward Vandewege)
Date: Mon, 24 Jul 2006 18:41:24 +0200
Subject: [LinuxBIOS] LinuxBIOS Debian package.
In-Reply-To: <20060724161620.GA6068@coresystems.de>
References: <20060724153912.GB25437@aragorn>
	<20060724161620.GA6068@coresystems.de>
Message-ID: <20060724164124.GA22567@localdomain>

On Mon, Jul 24, 2006 at 06:16:20PM +0200, Stefan Reinauer wrote:
> I would start out with "linuxbios-utils" as the only package and
> pack flashrom, the lxbios tool (see fm). If you want to make it more
> generic, you could call it firmware-utils or bios-utils and pack 
> openbios' toke and detok with it.

And also Anton Borisov's bios extraction tools:

 Award BIOS: http://kaos.ru/biosgfx/download/awardeco-0.2.src.tar.gz
 AMI BIOS: http://www.kaos.ru/biosgfx/download/AmiDeco_0.31e.src.tar.gz
 Insyde BIOS: http://www.kaos.ru/biosgfx/download/InsyDeco_0.3.src.tar.gz
 Phoenix BIOS: http://www.kaos.ru/biosgfx/download/PhoenixDeco_0.33.src.tar.gz

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator



From dhendrix at google.com  Mon Jul 24 19:10:12 2006
From: dhendrix at google.com (David Hendricks)
Date: Mon, 24 Jul 2006 10:10:12 -0700
Subject: [LinuxBIOS] ASUS K8N
In-Reply-To: <ceeep3-vtk.ln1@legba.gamic.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A42070040B4@ssvlexmb2.amd.com>
	<uhf6p3-obk.ln1@legba.gamic.com>
	<2ea3fae10607211900o15a4f40aj6c51df02cf3d2957@mail.gmail.com>
	<ec9b26620607211907j1d03f926l6210482fefd56a86@mail.google.com>
	<ceeep3-vtk.ln1@legba.gamic.com>
Message-ID: <ec9b26620607241010l5913ba51y70cc1204879b8f0f@mail.google.com>

A word of warning: Ron seems to have had some problems with the Asus A7M
port due to weirdness with the SMBus. Searching for "FIXME" in the
LinuxBIOSv1/src/mainboard/asus shows "# FIXME are the SMBUS DIMM locations
documented anywhere?"

On 7/24/06, Marco Costa <costa at gamic.com> wrote:
>
> Hi David, Yinghai
>
> First of all, thanks for the feedback.
>
> David Hendricks wrote:
> > I'm guessing that you are using an nForce3 board for a socket 754
> > processor. The MSI K8N-Neo3 has a CK804 with a 754 pin socket, if that
> > helps. I believe there was even someone from MSI at the last LinuxBIOS
> > summit, so at least they have a clue :-)
>
> It is good to see that companies are looking into open source solutions
> now. I think that the consumer pressure is building up.
>
> >
> > On 7/21/06, *yhlu* <yinghailu at gmail.com <mailto:yinghailu at gmail.com>>
> wrote:
> >
> >     It is using NVIDIA nForce3 too.
>
> As I noted on Asus site, it lists it as a NForce4 4x (not full
> Hypertransport, only 800MHz as far as I understand). Is this not supported,
> then?
>
> >
> >     YH
> >
>
> Regards,
>
> Marco Costa
>
>
> --
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060724/79b45333/attachment.html>

From uwe at hermann-uwe.de  Mon Jul 24 19:39:43 2006
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Mon, 24 Jul 2006 19:39:43 +0200
Subject: [LinuxBIOS] LinuxBIOS Debian package.
In-Reply-To: <20060724161620.GA6068@coresystems.de>
References: <20060724153912.GB25437@aragorn>
	<20060724161620.GA6068@coresystems.de>
Message-ID: <20060724173943.GA29640@aragorn>

Hi,

On Mon, Jul 24, 2006 at 06:16:20PM +0200, Stefan Reinauer wrote:
> > linuxbios - metapackage which draws in all/most other packages
> 
> ie. the other two?

Yes, basically. Maybe there will be more, not sure yet.


> > linuxbios-doc - documentation
> > linuxbios-utils - standalone utilities, e.g. romcc, flashrom, ...
>  
> romcc is recompiled each time an image is built (which takes a lot less
> time than running romcc)

Is this a strict requirement? Wouldn't it be possible to compile it
once, and distribute it as /usr/bin/romcc in the Debian package?
Are any compile-time options involved (vs. runtime/commandline options?)


> > Maybe also something like linuxbios-src which contains the rest, and
> > which can be used to compile images(?)
> 
> I would start out with "linuxbios-utils"

Yes, that's definately the easiest one and the most useful, probably.


> as the only package and
> pack flashrom, the lxbios tool (see fm).

lxbios should rather be an extra package as it has a different
"upstream" tarball and author(s). But maybe linuxbios could draw it
in, i.e. linuxbios could be a metapackage which not only depends on
linuxbios-* packages, but also related stuff such as lxbios.
Maybe it should have another name then, though.

Also, I'll have to check the lxbios license, the DISCLAIMER file has some
strange stuff which might pose problems for Debian...


> If you want to make it more
> generic, you could call it firmware-utils or bios-utils and pack 
> openbios' toke and detok with it.

Hm, openbios could be another package (or maybe multiple ones, e.g.
openbios-utils?), or we could have multiple payload packages, e.g.

linuxbios-payload-openbios
linuxbios-payload-etherboot
linuxbios-payload-*

Or linuxbios-payloads which contains all of them?

I'll have to think a bit more about this... this is definately the most
complex project I've ever packaged.


> The build process would have to be changed to use a prebuilt romcc, and
> I don't think this makes too much sense, as everything works fine as is,
> and there's no benefit to doing so.

If there's no reason to build romcc for each compile it would be nice to
only have _one_ binary in /usr/bin, IHMO (see above).


> Also, I would not swamp the repository with a number of packages just
> for the sake of doing so (even though this is commonly accepted in debian
> development) but look at target users of such a package and their
> requirements.

Yes, it should not be too many packages (although it's really not
uncommon in Debian, e.g. there are more than 30 xserver-xorg-*
packages).


> Having a flash utility like flashrom integrated definitely 
> makes sense. Packing source code in packages in my opinion does not (ok,
> the kernel may for some reason be an exception here)

I'm not too comfortable with shipping code either (e.g. in /usr/share,
/usr/src, or something), but I think it's a matter of convenience - users
could have one Debian box for LinuxBIOS work and could apt-get all the
required tools and code to work with/on LinuxBIOS.


Cheers, Uwe.
-- 
Uwe Hermann 
http://www.hermann-uwe.de
http://www.it-services-uh.de  | http://www.crazy-hacks.org 
http://www.holsham-traders.de | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060724/664960c5/attachment.sig>

From uwe at hermann-uwe.de  Mon Jul 24 19:43:42 2006
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Mon, 24 Jul 2006 19:43:42 +0200
Subject: [LinuxBIOS] LinuxBIOS Debian package.
In-Reply-To: <20060724164124.GA22567@localdomain>
References: <20060724153912.GB25437@aragorn>
	<20060724161620.GA6068@coresystems.de>
	<20060724164124.GA22567@localdomain>
Message-ID: <20060724174342.GB29640@aragorn>

Hi,

On Mon, Jul 24, 2006 at 06:41:24PM +0200, Ward Vandewege wrote:
> And also Anton Borisov's bios extraction tools:
> 
>  Award BIOS: http://kaos.ru/biosgfx/download/awardeco-0.2.src.tar.gz
>  AMI BIOS: http://www.kaos.ru/biosgfx/download/AmiDeco_0.31e.src.tar.gz
>  Insyde BIOS: http://www.kaos.ru/biosgfx/download/InsyDeco_0.3.src.tar.gz
>  Phoenix BIOS: http://www.kaos.ru/biosgfx/download/PhoenixDeco_0.33.src.tar.gz

I'll have a look at them - if the license permits I'll package them.


Uwe.
-- 
Uwe Hermann 
http://www.hermann-uwe.de
http://www.it-services-uh.de  | http://www.crazy-hacks.org 
http://www.holsham-traders.de | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060724/9cc07e35/attachment.sig>

From uwe at hermann-uwe.de  Mon Jul 24 19:51:16 2006
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Mon, 24 Jul 2006 19:51:16 +0200
Subject: [LinuxBIOS] LinuxBIOS Debian package.
In-Reply-To: <20060724162853.32440.qmail@cdy.org>
References: <20060724153912.GB25437@aragorn>
	<20060724162853.32440.qmail@cdy.org>
Message-ID: <20060724175116.GC29640@aragorn>

Hi,

On Mon, Jul 24, 2006 at 06:28:53PM +0200, Peter Stuge wrote:
> > linuxbios - metapackage which draws in all/most other packages
> 
> This strikes me as a bad idea since users may get the impression that
> apt-get install linuxbios would be all that is required to change
> BIOS.

Ok, maybe another, clearer name. But installing the package should not
actively _do_ anything, it should merely provide the required tools.


> While that would be very nice at some point I think we may not
> be there quite yet. Ideally we should be able to programmatically
> identify which mainboard a system is running on. Is this possible?
> A fuctury BIOS checksum -> LB target whitelist perhaps?

That might be nice, but I bet it's pretty hard to achieve...

Anyways, I do not want the package to (automatically) flash the BIOS or
similar things - that would surely result in distaster...


> > linuxbios-doc - documentation
> 
> Maybe more than one doc package since there are a few different kinds
> of docs. I'm not familiar with debian package conventions so I don't
> know what would be best.

One -doc package should suffice. It can contain various types of
documentation, that's no problem.


> > linuxbios-utils - standalone utilities, e.g. romcc, flashrom, ...
> 
> This makes sense, but ideally I think each util should be a separate
> package. Again I don't know how well that fits into debian package
> convetion.

It'll be several packages already and one for every executable is
overkill, IMHO. All utilities from the linuxbios source should be
in linuxbios-utils, external utils (lxbios, etc.) can go in extra
packages.


> > Maybe also something like linuxbios-src which contains the rest,
> > and which can be used to compile images(?)
> 
> There are no real LB relases yet. Versioning would be done based on
> snapshot date or svn revision.

Hm, will this change anytime soon? I _could_ base the package on svn
checkouts, but basing it on released tarballs would be nicer.


Cheers, Uwe.
-- 
Uwe Hermann 
http://www.hermann-uwe.de
http://www.it-services-uh.de  | http://www.crazy-hacks.org 
http://www.holsham-traders.de | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060724/d704aba9/attachment.sig>

From stepan at coresystems.de  Mon Jul 24 20:08:11 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 24 Jul 2006 20:08:11 +0200
Subject: [LinuxBIOS] LinuxBIOS Debian package.
In-Reply-To: <20060724173943.GA29640@aragorn>
References: <20060724153912.GB25437@aragorn>
	<20060724161620.GA6068@coresystems.de>
	<20060724173943.GA29640@aragorn>
Message-ID: <20060724180811.GA8388@coresystems.de>

Trying to be provocative.

* Uwe Hermann <uwe at hermann-uwe.de> [060724 19:39]:
> On Mon, Jul 24, 2006 at 06:16:20PM +0200, Stefan Reinauer wrote:
> > > linuxbios - metapackage which draws in all/most other packages
> > 
> > ie. the other two?
> 
> Yes, basically. Maybe there will be more, not sure yet.

Hm. Then I'd really drop this for now until there's some
commensurability. A package count overhead of 50% is pretty much ;)
 
> > romcc is recompiled each time an image is built (which takes a lot less
> > time than running romcc)
> 
> Is this a strict requirement? Wouldn't it be possible to compile it
> once, and distribute it as /usr/bin/romcc in the Debian package?
> Are any compile-time options involved (vs. runtime/commandline options?)
 
Not exactly a strict requirement, but romcc compiles within less than a
second. This is not even 1% of the average compile time of a LinuxBIOS
image. 

Possible yes, but I have not read a reason yet, why we should do such a
change.

In fact, if we find a bug in romcc now and fix it, we can point people to
use revision XX from subversion and they are fine. I dont want to take
the overhead of explaining people they have to update their debian
package or switch the build process to use the "builtin version" for a
build time reduced by less then a second. Even opening my mail client 
takes longer than that.

romcc is a very special tool. I doubt there is too much use for it in
other projects (except _maybe_ uboot, but I doubt even that).

I would think that does not help the debian project except with regard
to staying the distribution with the largest number of packages (and
thus user confusion)
 
> lxbios should rather be an extra package as it has a different
> "upstream" tarball and author(s). But maybe linuxbios could draw it
> in, i.e. linuxbios could be a metapackage which not only depends on
> linuxbios-* packages, but also related stuff such as lxbios.
> Maybe it should have another name then, though.

...

> Also, I'll have to check the lxbios license, the DISCLAIMER file has some
> strange stuff which might pose problems for Debian...

What's wrong? The software is GPL. 
 
> > If you want to make it more
> > generic, you could call it firmware-utils or bios-utils and pack 
> > openbios' toke and detok with it.
> 
> Hm, openbios could be another package (or maybe multiple ones, e.g.
> openbios-utils?), or we could have multiple payload packages, e.g.
> 
> linuxbios-payload-openbios
> linuxbios-payload-etherboot
> linuxbios-payload-*

> Or linuxbios-payloads which contains all of them?

If at all, pack it into one of them.

Each of the payloads is between 20 and 200k. The .deb overhead is
probably more than that for most of the payloads.

Be careful when making this too finegrained. It will make it completely
unmaintainable for you, which will lead to not up to date packages
(which is a big problem in debian in general) and might in the end 
even paralyze progress.

In my opinion linuxbios should not be more than two packages:

bios-utils and linuxbios-images (and I doubt whether we really want an
-images package)

> > The build process would have to be changed to use a prebuilt romcc, and
> > I don't think this makes too much sense, as everything works fine as is,
> > and there's no benefit to doing so.
> 
> If there's no reason to build romcc for each compile it would be nice to
> only have _one_ binary in /usr/bin, IHMO (see above).
 
Again: Why would it be nice? For safing one second? 
 
> I'm not too comfortable with shipping code either (e.g. in /usr/share,
> /usr/src, or something), but I think it's a matter of convenience - users
> could have one Debian box for LinuxBIOS work and could apt-get all the
> required tools and code to work with/on LinuxBIOS.

well, they can now svn co all the code without any extra effort and
extra layer.. Is that less convenient?





-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From ward at gnu.org  Mon Jul 24 22:47:32 2006
From: ward at gnu.org (Ward Vandewege)
Date: Mon, 24 Jul 2006 22:47:32 +0200
Subject: [LinuxBIOS] LinuxBIOS Debian package.
In-Reply-To: <20060724174342.GB29640@aragorn>
References: <20060724153912.GB25437@aragorn>
	<20060724161620.GA6068@coresystems.de>
	<20060724164124.GA22567@localdomain>
	<20060724174342.GB29640@aragorn>
Message-ID: <20060724204732.GA23396@localdomain>

On Mon, Jul 24, 2006 at 07:43:42PM +0200, Uwe Hermann wrote:
> >  Award BIOS: http://kaos.ru/biosgfx/download/awardeco-0.2.src.tar.gz
> >  AMI BIOS: http://www.kaos.ru/biosgfx/download/AmiDeco_0.31e.src.tar.gz
> >  Insyde BIOS: http://www.kaos.ru/biosgfx/download/InsyDeco_0.3.src.tar.gz
> >  Phoenix BIOS: http://www.kaos.ru/biosgfx/download/PhoenixDeco_0.33.src.tar.gz
> 
> I'll have a look at them - if the license permits I'll package them.

Anton may have to clarify the license a bit. He did indicate to me that he
was planning to release these under the GPL, but I'm not sure if all the
source packages contain the proper files.

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator



From Martin.Mayr at uibk.ac.at  Tue Jul 25 08:12:43 2006
From: Martin.Mayr at uibk.ac.at (Martin Mayr)
Date: Tue, 25 Jul 2006 08:12:43 +0200
Subject: [LinuxBIOS] Mainboard
Message-ID: <44C5B65B.2030400@uibk.ac.at>

Hello!
I read a thread about getting linuxbios work on the PC-Chips M810LR
Mainboard
from Antony Stone:
http://www.linuxbios.org/index.php?title=The_PC_CHIPS_M810LR&redirect=no

My question is, if there are any newer boards from pc-chips which are
supported
by linuxbios.
Or are there any other boards like these ones (the opteron boards of tyan
are too large for me, i would prefer micro atx), because I only find
relative
old boards, or the huge ones of tyan.

In another thread I read about the win-ent mb06047/48/49. These boards would
be definitely too expensive for me.

Many thanks in advance,
greetings,
Martin





From indrek.kruusa at artecdesign.ee  Tue Jul 25 09:36:52 2006
From: indrek.kruusa at artecdesign.ee (Indrek Kruusa)
Date: Tue, 25 Jul 2006 10:36:52 +0300
Subject: [LinuxBIOS] [QUESTION] VSA2 for OLPC
In-Reply-To: <44C4F58C.8020701@lanl.gov>
References: <44C4E49A.9040603@artecdesign.ee> <44C4F58C.8020701@lanl.gov>
Message-ID: <44C5CA14.7030802@artecdesign.ee>

Ronald G Minnich wrote:
> Indrek Kruusa wrote:
>> Hi!
>>
>> The VSA2 bios for OLPC seems to be quite minimal: 64 KB.
>>
>> I would be glad to know:
>> - is there only vsainit and sysmgr inside vsa for olpc?
>> - does audio, ohci/ehci and video handled by kernel drivers?
>> - does OLPC target booting without major problems?
>>
>> It seems to be true but it is better to know for sure ;)
>>
>> Indrek
>>
>>
>
> I have not tested audio. Yes, the 64K is intentionally small. We wanted 
> to have in VSA at all, but could not kill it entirely.
>

Do you have any pointer to updated documentation for VSA2? For example 
from VSA2 source I can see where to load source, destination and length 
(esi,edi,ecx) but is there documentation about that?

About VSA2 image: I suppose you have something like this:

4 bytes len(VSA) | vsainit.bin | sysmgr.vsm

- Is this correct?
- How do you compress the image?
- Do you provide VSA2 binary image for download somewhere?

thanks,
Indrek




From rminnich at lanl.gov  Tue Jul 25 15:56:24 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 25 Jul 2006 07:56:24 -0600
Subject: [LinuxBIOS] [QUESTION] VSA2 for OLPC
In-Reply-To: <44C5CA14.7030802@artecdesign.ee>
References: <44C4E49A.9040603@artecdesign.ee> <44C4F58C.8020701@lanl.gov>
	<44C5CA14.7030802@artecdesign.ee>
Message-ID: <44C62308.8020205@lanl.gov>

Indrek Kruusa wrote:
>
> Do you have any pointer to updated documentation for VSA2? For example 
> from VSA2 source I can see where to load source, destination and length 
> (esi,edi,ecx) but is there documentation about that?
> 
> About VSA2 image: I suppose you have something like this:
> 
> 4 bytes len(VSA) | vsainit.bin | sysmgr.vsm
> 
> - Is this correct?

it's basically right. It comes set up that way. Then is compressed with 
nrv2b.

> - Do you provide VSA2 binary image for download somewhere?

from amd


ron



From indrek.kruusa at artecdesign.ee  Tue Jul 25 18:09:44 2006
From: indrek.kruusa at artecdesign.ee (Indrek Kruusa)
Date: Tue, 25 Jul 2006 19:09:44 +0300
Subject: [LinuxBIOS] [QUESTION] VSA2 for OLPC
In-Reply-To: <44C62308.8020205@lanl.gov>
References: <44C4E49A.9040603@artecdesign.ee>
	<44C4F58C.8020701@lanl.gov>	<44C5CA14.7030802@artecdesign.ee>
	<44C62308.8020205@lanl.gov>
Message-ID: <44C64248.7000106@artecdesign.ee>

Ronald G Minnich wrote:
> Indrek Kruusa wrote:
>   
>> Do you have any pointer to updated documentation for VSA2? For example 
>> from VSA2 source I can see where to load source, destination and length 
>> (esi,edi,ecx) but is there documentation about that?
>>
>> About VSA2 image: I suppose you have something like this:
>>
>> 4 bytes len(VSA) | vsainit.bin | sysmgr.vsm
>>
>> - Is this correct?
>>     
>
> it's basically right. It comes set up that way. Then is compressed with 
> nrv2b.
>   

Thanks,
I have got VSA2 loaded with linuxbios and Geode LX. I will send patches 
here if we will have further advancements.

Indrek




From rminnich at lanl.gov  Tue Jul 25 18:11:18 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 25 Jul 2006 10:11:18 -0600
Subject: [LinuxBIOS] [QUESTION] VSA2 for OLPC
In-Reply-To: <44C64248.7000106@artecdesign.ee>
References: <44C4E49A.9040603@artecdesign.ee>
	<44C4F58C.8020701@lanl.gov>	<44C5CA14.7030802@artecdesign.ee>
	<44C62308.8020205@lanl.gov> <44C64248.7000106@artecdesign.ee>
Message-ID: <44C642A6.2090307@lanl.gov>

Indrek Kruusa wrote:
> Ronald G Minnich wrote:
> 
>> Indrek Kruusa wrote:
>>  
>>
>>> Do you have any pointer to updated documentation for VSA2? For 
>>> example from VSA2 source I can see where to load source, destination 
>>> and length (esi,edi,ecx) but is there documentation about that?
>>>
>>> About VSA2 image: I suppose you have something like this:
>>>
>>> 4 bytes len(VSA) | vsainit.bin | sysmgr.vsm
>>>
>>> - Is this correct?
>>>     
>>
>>
>> it's basically right. It comes set up that way. Then is compressed 
>> with nrv2b.
>>   
> 
> 
> Thanks,
> I have got VSA2 loaded with linuxbios and Geode LX. I will send patches 
> here if we will have further advancements.
> 
> Indrek
> 


GEODE LX? thats' great news!

can you tell us your process? Can you supply me with your vsa image?

ron



From indrek.kruusa at artecdesign.ee  Tue Jul 25 18:40:09 2006
From: indrek.kruusa at artecdesign.ee (Indrek Kruusa)
Date: Tue, 25 Jul 2006 19:40:09 +0300
Subject: [LinuxBIOS] [QUESTION] VSA2 for OLPC
In-Reply-To: <44C642A6.2090307@lanl.gov>
References: <44C4E49A.9040603@artecdesign.ee>
	<44C4F58C.8020701@lanl.gov>	<44C5CA14.7030802@artecdesign.ee>
	<44C62308.8020205@lanl.gov> <44C64248.7000106@artecdesign.ee>
	<44C642A6.2090307@lanl.gov>
Message-ID: <44C64969.3020101@artecdesign.ee>

Ronald G Minnich wrote:
> Indrek Kruusa wrote:
>> Ronald G Minnich wrote:
>>
>>> Indrek Kruusa wrote:
>>>  
>>>
>>>> Do you have any pointer to updated documentation for VSA2? For 
>>>> example from VSA2 source I can see where to load source, 
>>>> destination and length (esi,edi,ecx) but is there documentation 
>>>> about that?
>>>>
>>>> About VSA2 image: I suppose you have something like this:
>>>>
>>>> 4 bytes len(VSA) | vsainit.bin | sysmgr.vsm
>>>>
>>>> - Is this correct?
>>>>     
>>>
>>>
>>> it's basically right. It comes set up that way. Then is compressed 
>>> with nrv2b.
>>>   
>>
>>
>> Thanks,
>> I have got VSA2 loaded with linuxbios and Geode LX. I will send 
>> patches here if we will have further advancements.
>>
>> Indrek
>>
>
>
> GEODE LX? thats' great news!
>
> can you tell us your process? Can you supply me with your vsa image?

I suppose at least that VSA loading were successful :) There weren't any 
evil message (serial output attatched).
Is this OK to send vsa image to the list? If yes, then I can send it 
tomorrow.

Indrek

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: serial_linuxbios_2.txt
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060725/f181e391/attachment.txt>

From rminnich at lanl.gov  Tue Jul 25 18:40:02 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 25 Jul 2006 10:40:02 -0600
Subject: [LinuxBIOS] [QUESTION] VSA2 for OLPC
In-Reply-To: <44C64969.3020101@artecdesign.ee>
References: <44C4E49A.9040603@artecdesign.ee>
	<44C4F58C.8020701@lanl.gov>	<44C5CA14.7030802@artecdesign.ee>
	<44C62308.8020205@lanl.gov> <44C64248.7000106@artecdesign.ee>
	<44C642A6.2090307@lanl.gov> <44C64969.3020101@artecdesign.ee>
Message-ID: <44C64962.4020107@lanl.gov>

this is interesting. is this the OLPC linuxbios on a LX?

ron



From indrek.kruusa at artecdesign.ee  Tue Jul 25 18:55:04 2006
From: indrek.kruusa at artecdesign.ee (Indrek Kruusa)
Date: Tue, 25 Jul 2006 19:55:04 +0300
Subject: [LinuxBIOS] [QUESTION] VSA2 for OLPC
In-Reply-To: <44C64962.4020107@lanl.gov>
References: <44C4E49A.9040603@artecdesign.ee>
	<44C4F58C.8020701@lanl.gov>	<44C5CA14.7030802@artecdesign.ee>
	<44C62308.8020205@lanl.gov> <44C64248.7000106@artecdesign.ee>
	<44C642A6.2090307@lanl.gov> <44C64969.3020101@artecdesign.ee>
	<44C64962.4020107@lanl.gov>
Message-ID: <44C64CE8.2050500@artecdesign.ee>

Ronald G Minnich wrote:
> this is interesting. is this the OLPC linuxbios on a LX?

Yes,

[PATCH] GX2/OLPC hacked for Geode LX  -  
http://www.linuxbios.org/pipermail/linuxbios/2006-July/015081.html

This is preliminary work and not nice but why not to share things even 
at that level.

Indrek




From rminnich at lanl.gov  Tue Jul 25 19:04:12 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 25 Jul 2006 11:04:12 -0600
Subject: [LinuxBIOS] [QUESTION] VSA2 for OLPC
In-Reply-To: <44C64CE8.2050500@artecdesign.ee>
References: <44C4E49A.9040603@artecdesign.ee>
	<44C4F58C.8020701@lanl.gov>	<44C5CA14.7030802@artecdesign.ee>
	<44C62308.8020205@lanl.gov> <44C64248.7000106@artecdesign.ee>
	<44C642A6.2090307@lanl.gov> <44C64969.3020101@artecdesign.ee>
	<44C64962.4020107@lanl.gov> <44C64CE8.2050500@artecdesign.ee>
Message-ID: <44C64F0C.1050903@lanl.gov>

Indrek Kruusa wrote:
> Ronald G Minnich wrote:
> 
>> this is interesting. is this the OLPC linuxbios on a LX?
> 
> 
> Yes,
> 
> [PATCH] GX2/OLPC hacked for Geode LX  -  
> http://www.linuxbios.org/pipermail/linuxbios/2006-July/015081.html
> 
> This is preliminary work and not nice but why not to share things even 
> at that level.
> 
> Indrek
> 

my apologies .. you told me this and I forget. Will try to incorporate 
this tonight.

ron



From acassis at gmail.com  Tue Jul 25 21:29:51 2006
From: acassis at gmail.com (Alan Carvalho de Assis)
Date: Tue, 25 Jul 2006 13:29:51 -0600
Subject: [LinuxBIOS] Flashrom support to VIA VT8235
In-Reply-To: <44C520CD.9080406@lanl.gov>
References: <37367b3a0607201651k27262d1do2e41fd6e331d6b5d@mail.gmail.com>
	<44C11EDB.60402@lanl.gov>
	<37367b3a0607211241m3dec5038w4d2e832e6e9712e1@mail.gmail.com>
	<44C12EF4.40205@lanl.gov>
	<37367b3a0607211256o6cb91e4apc89e72e5f8a16994@mail.gmail.com>
	<44C1437F.805@lanl.gov>
	<37367b3a0607221234s13708932id85b96984839975@mail.gmail.com>
	<44C3CB7B.6040802@lanl.gov>
	<37367b3a0607241213ne2de58ctd8b3e8b8c6d2277a@mail.gmail.com>
	<44C520CD.9080406@lanl.gov>
Message-ID: <37367b3a0607251229l37418f61k7ff937008b859d9a@mail.gmail.com>

Hi Ronald,

On 7/24/06, Ronald G Minnich <rminnich at lanl.gov> wrote:
> good news! write enable is working!
>
bad news! flash write enable is not working! :-(

In the datasheet said pins TBL# (pin 8) and WP# (7) need go to high to
enable flash erasing/writing, but enable_flash_write() on vt8235 is
not activating it (I verifyied these pins using oscilloscope).

Then enable_flash_write from vt8235 is not working on vt8237!

> Your problem is that your flash chip driver needs some work. You need to
> look at the spec sheet for the flash part, look at your code, and see
> what's not working.
>
Sure, but I think the problem is because enable_flash_write() is not
unprotecting flash (at hardware)  to erase.

Another idea to solve it?

> But you are on the way!
>

Thank you,

> ron
>

Alan
-- 
------------------------------------------------------------
|                     Alan Carvalho de Assis                |
------------------------------------------------------------
--
N?o importa o que os outros ir?o pensar,
A cura para a infelicidade ? a felicidade



From rminnich at lanl.gov  Tue Jul 25 21:59:59 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 25 Jul 2006 13:59:59 -0600
Subject: [LinuxBIOS] Flashrom support to VIA VT8235
In-Reply-To: <37367b3a0607251229l37418f61k7ff937008b859d9a@mail.gmail.com>
References: <37367b3a0607201651k27262d1do2e41fd6e331d6b5d@mail.gmail.com>	<44C11EDB.60402@lanl.gov>	<37367b3a0607211241m3dec5038w4d2e832e6e9712e1@mail.gmail.com>	<44C12EF4.40205@lanl.gov>	<37367b3a0607211256o6cb91e4apc89e72e5f8a16994@mail.gmail.com>	<44C1437F.805@lanl.gov>	<37367b3a0607221234s13708932id85b96984839975@mail.gmail.com>	<44C3CB7B.6040802@lanl.gov>	<37367b3a0607241213ne2de58ctd8b3e8b8c6d2277a@mail.gmail.com>	<44C520CD.9080406@lanl.gov>
	<37367b3a0607251229l37418f61k7ff937008b859d9a@mail.gmail.com>
Message-ID: <44C6783F.50500@lanl.gov>

Alan Carvalho de Assis wrote:
> Hi Ronald,
> 
> On 7/24/06, Ronald G Minnich <rminnich at lanl.gov> wrote:
> 
>>good news! write enable is working!
>>
> 
> bad news! flash write enable is not working! :-(


if you get a proper id out of a flash, then the write strobe is working. 
So something weird is going on.


YOu can't id a flash without write working.


ron




From stepan at coresystems.de  Tue Jul 25 22:49:24 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Tue, 25 Jul 2006 22:49:24 +0200
Subject: [LinuxBIOS] Flashrom support to VIA VT8235
In-Reply-To: <44C6783F.50500@lanl.gov>
References: <37367b3a0607211241m3dec5038w4d2e832e6e9712e1@mail.gmail.com>
	<44C12EF4.40205@lanl.gov>
	<37367b3a0607211256o6cb91e4apc89e72e5f8a16994@mail.gmail.com>
	<44C1437F.805@lanl.gov>
	<37367b3a0607221234s13708932id85b96984839975@mail.gmail.com>
	<44C3CB7B.6040802@lanl.gov>
	<37367b3a0607241213ne2de58ctd8b3e8b8c6d2277a@mail.gmail.com>
	<44C520CD.9080406@lanl.gov>
	<37367b3a0607251229l37418f61k7ff937008b859d9a@mail.gmail.com>
	<44C6783F.50500@lanl.gov>
Message-ID: <20060725204924.GA12730@coresystems.de>

* Ronald G Minnich <rminnich at lanl.gov> [060725 21:59]:
> Alan Carvalho de Assis wrote:
> > Hi Ronald,
> > 
> > On 7/24/06, Ronald G Minnich <rminnich at lanl.gov> wrote:
> > 
> >>good news! write enable is working!
> >>
> > 
> > bad news! flash write enable is not working! :-(
> 
> 
> if you get a proper id out of a flash, then the write strobe is working. 
> So something weird is going on.
> 
> 
> YOu can't id a flash without write working.
 
Maybe the flash part has its own write mechanism? Quite some do.


-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From rminnich at lanl.gov  Tue Jul 25 22:52:52 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 25 Jul 2006 14:52:52 -0600
Subject: [LinuxBIOS] Flashrom support to VIA VT8235
In-Reply-To: <20060725204924.GA12730@coresystems.de>
References: <37367b3a0607211241m3dec5038w4d2e832e6e9712e1@mail.gmail.com>
	<44C12EF4.40205@lanl.gov>
	<37367b3a0607211256o6cb91e4apc89e72e5f8a16994@mail.gmail.com>
	<44C1437F.805@lanl.gov>
	<37367b3a0607221234s13708932id85b96984839975@mail.gmail.com>
	<44C3CB7B.6040802@lanl.gov>
	<37367b3a0607241213ne2de58ctd8b3e8b8c6d2277a@mail.gmail.com>
	<44C520CD.9080406@lanl.gov>
	<37367b3a0607251229l37418f61k7ff937008b859d9a@mail.gmail.com>
	<44C6783F.50500@lanl.gov> <20060725204924.GA12730@coresystems.de>
Message-ID: <44C684A4.9060808@lanl.gov>

Stefan Reinauer wrote:
> Maybe the flash part has its own write mechanism? Quite some do.
> 
> 


my suspicion -- backed by seeing this a lot -- is that the write strobe 
is fine, and the write code for the part is not working.

i.e. the south is ok, but the flash support code is wrong.


ron



From brendan at worldguard.com.au  Wed Jul 26 10:46:26 2006
From: brendan at worldguard.com.au (Brendan Grieve)
Date: Wed, 26 Jul 2006 16:46:26 +0800
Subject: [LinuxBIOS] Netvista N2200 8363 (Request)
Message-ID: <44C72BE2.6090406@worldguard.com.au>

Hi All,

I've been playing around on and off for the last few years with these 
8363 thin clients made by IBM. They are really brilliant machines and 
are powerful enough to use either diskless (running local apps via NFS), 
as thin clients, or as standalone devices (CF).

They are also x86 (Cyrix chipset) with a Geode VGA. They have VGA out, 
sound out, mic in, 2 USB and a NIC. It also has a built in CF card that 
is seen as hda when used.

More info can be found here:
  
http://www.bluetrait.com/archive/2005/08/07/installing-linux-2200-onto-the-ibm-netvista-n2200-8363/

However an issue with them is that the bios that is supplied with them 
is annoying to say the least. It does not support any boot loaders 
(lilo/grup etc...) but instead loads up an elf uncompressed kernel. For 
reasons I'm not yet sure, the kernel (2.4) needs to be compiled by gcc 
2.95, and requires various patches to get it to work. I've never got 2.6 
working, and never got even 2.4 working with a compiler other than gcc 2.95.

However, with the old kernel, I've gotten a pile of these going and they 
are fantastic. They can play mp3's, play video, and as I test I setup 20 
of them with distcc and used them to assist in compiles. Also they are 
extremely low voltage and could possibly run in a car from the cigarette 
lighter.

I believe that this device is a perfect candidate for LinuxBios. You can 
pick them up dirt cheap (~$10) from ebay, and in fact there are LOTS of 
these just floating around, and a decent bios that will allow one the 
flexibility of loading a newer kernel would be great. You can run them 
diskless as I mentioned before or can install to CF, with the CF seen as 
a drive.

The bios is a 32ping socketed PLCC AM29F040B.

I was wondering if anyone has tried LinuxBios on this and what the 
results were? Would anyone be willing to get it going? I would be happy 
to package one of these up, with a working linux distro on its internal 
CF and mail it (to keep) if it would help. Ideally it would be great if 
it was possible to be able to boot via NFS (PXE would be brilliant) and 
also have the option of direct from the internal CF.

Cheers,
Brendan



From smithbone at gmail.com  Wed Jul 26 16:53:31 2006
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 26 Jul 2006 09:53:31 -0500
Subject: [LinuxBIOS] Netvista N2200 8363 (Request)
In-Reply-To: <44C72BE2.6090406@worldguard.com.au>
References: <44C72BE2.6090406@worldguard.com.au>
Message-ID: <8a0c36780607260753i73ba3b14pdebbc663fa766144@mail.gmail.com>

> (lilo/grup etc...) but instead loads up an elf uncompressed kernel. For
> reasons I'm not yet sure, the kernel (2.4) needs to be compiled by gcc

Most likely for boot speed.  Devices with out a lot of cache take much
longer to decompress the Kernel.

>
> I was wondering if anyone has tried LinuxBios on this and what the
> results were? Would anyone be willing to get it going? I would be happy

Hmm.. Looks a bit troublesome.

I don't see a serial port mentoned anywhere or in the picures.  Is
there a serial port?  or a serial port mod?

Flash part is soldered onto the board but at least its a PLCC so it
will be pretty easy to replace with a a socket.

VGA is handled by VSA but I think others have made that work on some
of the other geode boards.

Are the datasheets for the MediaGX available?

-- 
Richard A. Smith



From danmez at gmail.com  Thu Jul 27 00:17:18 2006
From: danmez at gmail.com (Dan Mezynski)
Date: Wed, 26 Jul 2006 18:17:18 -0400
Subject: [LinuxBIOS] Comes up but cant see CMOS prompt or options
Message-ID: <7b7e71620607261517n2322ecefj661f2311d3bfbf55@mail.gmail.com>

I was able to setup config to include VGA bios and it seems to work but it
happens late in the flow, so a lot of printk messaages are not seen, they
only become visable after calling dev_initialize().

2 questions:
* How can I get it so early printk messages come up?
* Shouldnt there be an option to hit f-10 or some other key to get into
CMOS?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060726/01c20694/attachment.html>

From rminnich at lanl.gov  Thu Jul 27 00:24:33 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 26 Jul 2006 16:24:33 -0600
Subject: [LinuxBIOS] Comes up but cant see CMOS prompt or options
In-Reply-To: <7b7e71620607261517n2322ecefj661f2311d3bfbf55@mail.gmail.com>
References: <7b7e71620607261517n2322ecefj661f2311d3bfbf55@mail.gmail.com>
Message-ID: <44C7EBA1.3070405@lanl.gov>

Dan Mezynski wrote:
> 
> I was able to setup config to include VGA bios and it seems to work but 
> it happens late in the flow, so a lot of printk messaages are not seen, 
> they only become visable after calling dev_initialize(). 

hm. what platform is this?

> 
> 2 questions:
> * How can I get it so early printk messages come up?
> * Shouldnt there be an option to hit f-10 or some other key to get into 
> CMOS?
> 

no. What we're doing on OLPC (and OLPC is the cutting edge) is you can 
get into an ASH prompt if you want, and use normal UNIX tools for that 
kind of thing.

ron



From brendan at worldguard.com.au  Thu Jul 27 07:50:49 2006
From: brendan at worldguard.com.au (Brendan Grieve)
Date: Thu, 27 Jul 2006 13:50:49 +0800
Subject: [LinuxBIOS] Netvista N2200 8363 (Request)
In-Reply-To: <8a0c36780607260753i73ba3b14pdebbc663fa766144@mail.gmail.com>
References: <44C72BE2.6090406@worldguard.com.au>
	<8a0c36780607260753i73ba3b14pdebbc663fa766144@mail.gmail.com>
Message-ID: <44C85439.1040804@worldguard.com.au>

(Resent from the correct email account this time)

Richard Smith wrote:
>> I was wondering if anyone has tried LinuxBios on this and what the
>> results were? Would anyone be willing to get it going? I would be happy
>>     
>
> Hmm.. Looks a bit troublesome.
>
> I don't see a serial port mentoned anywhere or in the picures.  Is
> there a serial port?  or a serial port mod?
>   

There are no serial ports.

> Flash part is soldered onto the board but at least its a PLCC so it
> will be pretty easy to replace with a a socket.
>   

I've had a closer look at the picture on the website and it definitely 
shows it soldered in... which is interesting because every single 8363 
I've ever had has it socketed. The one have to the right of me 
definitely has a socket, else I would already have given this up as 
too-hard ;-)


Brendan



From smithbone at gmail.com  Thu Jul 27 16:27:35 2006
From: smithbone at gmail.com (Richard Smith)
Date: Thu, 27 Jul 2006 09:27:35 -0500
Subject: [LinuxBIOS] Comes up but cant see CMOS prompt or options
In-Reply-To: <7b7e71620607261517n2322ecefj661f2311d3bfbf55@mail.gmail.com>
References: <7b7e71620607261517n2322ecefj661f2311d3bfbf55@mail.gmail.com>
Message-ID: <8a0c36780607270727l15b63f9fwa4ee4e39a826d69c@mail.gmail.com>

On 7/26/06, Dan Mezynski <danmez at gmail.com> wrote:

>  I was able to setup config to include VGA bios and it seems to work but it
> happens late in the flow, so a lot of printk messaages are not seen, they
> only become visable after calling dev_initialize().
>
>  2 questions:
>  * How can I get it so early printk messages come up?

How are you doing video init?  If linuxbios is doing it then it should
be done long before the kernel loads.

>  * Shouldnt there be an option to hit f-10 or some other key to get into
> CMOS?

2 invalid assumptions.   There may be no CMOS or keyboard.

-- 
Richard A. Smith



From smithbone at gmail.com  Thu Jul 27 17:07:21 2006
From: smithbone at gmail.com (Richard Smith)
Date: Thu, 27 Jul 2006 10:07:21 -0500
Subject: [LinuxBIOS] Netvista N2200 8363 (Request)
In-Reply-To: <44C85439.1040804@worldguard.com.au>
References: <44C72BE2.6090406@worldguard.com.au>
	<8a0c36780607260753i73ba3b14pdebbc663fa766144@mail.gmail.com>
	<44C85439.1040804@worldguard.com.au>
Message-ID: <8a0c36780607270807w449a25efwedf0ce410dd7591b@mail.gmail.com>

> >
> > I don't see a serial port mentoned anywhere or in the picures.  Is
> > there a serial port?  or a serial port mod?
> >
>
> There are no serial ports.

With out a serial port the complxity of the port goes up by several
orders of magnitude.

Neet to get the datasheet for the southbridge and see if we can hack a
serial port in there.


-- 
Richard A. Smith



From smithbone at gmail.com  Thu Jul 27 18:12:35 2006
From: smithbone at gmail.com (Richard Smith)
Date: Thu, 27 Jul 2006 11:12:35 -0500
Subject: [LinuxBIOS] AMD JTAG Debug Port
In-Reply-To: <8a0c36780607270911n7a87e06cgfdc626fec14cad6c@mail.gmail.com>
References: <44C86920.7050504@onelabs.com> <44C8CEB6.2080607@lanl.gov>
	<1154014588.17147.1.camel@logarithm.lanl.gov>
	<8a0c36780607270911n7a87e06cgfdc626fec14cad6c@mail.gmail.com>
Message-ID: <8a0c36780607270912w7727de61j5ecdb6a0d0870fc2@mail.gmail.com>

OOps.  Forgot to reply to all

> Actually, the JTAG debugger (for GX2) is not made by AMD. It is made by
> a company called FS2. I don't remember who made the JTAG debugger for
> K8.
>

Yeah supposedly this is TCL code that works with the FS2 and will do
things like read and write MSR's and some other stuff.

--
Richard A. Smith


-- 
Richard A. Smith



From bari at onelabs.com  Thu Jul 27 19:04:19 2006
From: bari at onelabs.com (Bari Ari)
Date: Thu, 27 Jul 2006 12:04:19 -0500
Subject: [LinuxBIOS] Geode JTAG Debug Tool for GX and LX
Message-ID: <44C8F213.3070402@onelabs.com>

System Navigator for AMD Geode? GX and LX Processors
http://www.fs2.com/geodetools.html

-Bari



From bari at onelabs.com  Thu Jul 27 19:39:40 2006
From: bari at onelabs.com (Bari Ari)
Date: Thu, 27 Jul 2006 12:39:40 -0500
Subject: [LinuxBIOS] AMD LinuxBIOS Debug via JTAG
Message-ID: <44C8FA5C.5010104@onelabs.com>

Has anyone worked with the JTAG debug tools from:

International Test Technologies
?Master 4010 for AMD? processor boards

http://www.intertesttech.com/ate/products_4010.htm

They also make a cpu interposers for boards that don't have JTAG or HDT 
connectors. The interposer plugs into the cpu socket and the cpu plugs 
into the interposer socket. They don't seem to have them for the latest 
AMD processors though.

http://www.intertesttech.com/ate/products_interposers.htm

-Bari



From uwe at hermann-uwe.de  Thu Jul 27 22:28:20 2006
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Thu, 27 Jul 2006 22:28:20 +0200
Subject: [LinuxBIOS] LinuxBIOS Debian package.
In-Reply-To: <20060724180811.GA8388@coresystems.de>
References: <20060724153912.GB25437@aragorn>
	<20060724161620.GA6068@coresystems.de>
	<20060724173943.GA29640@aragorn>
	<20060724180811.GA8388@coresystems.de>
Message-ID: <20060727202820.GD21020@aragorn>

Hi,

On Mon, Jul 24, 2006 at 08:08:11PM +0200, Stefan Reinauer wrote:
> Trying to be provocative.

With quite some success, I might add ;)


> > Yes, basically. Maybe there will be more, not sure yet.
> 
> Hm. Then I'd really drop this for now until there's some
> commensurability. A package count overhead of 50% is pretty much ;)

Agreed, I'll try to keep the number of packages reasonably small.


> > Is this a strict requirement? Wouldn't it be possible to compile it
> > once, and distribute it as /usr/bin/romcc in the Debian package?
> > Are any compile-time options involved (vs. runtime/commandline options?)
>  
> Not exactly a strict requirement, but romcc compiles within less than a
> second. This is not even 1% of the average compile time of a LinuxBIOS
> image. 
> 
> Possible yes, but I have not read a reason yet, why we should do such a
> change.

Oh, you would not need to do it in svn, if that matters. I could do the
change in the Debian package only...

I don't have a (very) strong opinion on this, it just feels a bit
strange to compile it every time. I mean, I don't build gcc every time
I want to compile a C program either, so why should I build romcc every time?


> In fact, if we find a bug in romcc now and fix it, we can point people to
> use revision XX from subversion and they are fine. I dont want to take
> the overhead of explaining people they have to update their debian
> package or switch the build process to use the "builtin version" for a
> build time reduced by less then a second. Even opening my mail client 
> takes longer than that.

Well, that's a general problem with packages - they _always_ lag behind
upstream, some more and some less. Using a mixture of upstream stuff
_and_ Debian stuff is probably not a good idea.
So either people use the Debian packages for code+tools+docs, or they
don't and use the svn code directly; nobody should mix both, that'll
result in problems, I guess.

As for romcc - if there's a change in svn, you'll have to tell people
anyways, regardless of whether they use Debian or not, and regardless
of whether Debian ships a /usr/bin/romcc or only the source of it.


> > Also, I'll have to check the lxbios license, the DISCLAIMER file has some
> > strange stuff which might pose problems for Debian...
> 
> What's wrong? The software is GPL. 

GPL is fine of course. What needs checking is whether the other comments
cause problems or not (I don't think they will, though), e.g.:

This work was produced at the University of California, Lawrence Livermore
National Laboratory (UC LLNL) under contract no. W-7405-ENG-48 (Contract 48)
between the U.S. Department of Energy (DOE) and The Regents of the
University of California (University) for the operation of UC LLNL.
The rights of the Federal Government are reserved under Contract 48 subject
to the restrictions agreed upon by the DOE and University as allowed under
DOE Acquisition Letter 97-1.

#############################################################################

OUR NOTICE AND TERMS AND CONDITIONS OF THE GNU GENERAL PUBLIC LICENSE

Our Preamble Notice
-------------------

A.  This notice is required to be provided under our contract with the U.S.
    Department of Energy (DOE).  This work was produced at the University of
    California, Lawrence Livermore National Laboratory under Contract No.
    W-7405-ENG-48 with the DOE.

B.  Neither the United States Government nor the University of California nor
    any of their employees, makes any warranty, express or implied, or
    assumes any liability or responsibility for the accuracy, completeness,
    or usefulness of any information, apparatus, product, or process
    disclosed, or represents that its use would not infringe privately-owned
    rights.

C.  Also, reference herein to any specific commercial products, process, or
    services by trade name, trademark, manufacturer or otherwise does not
    necessarily constitute or imply its endorsement, recommendation, or
    favoring by the United States Government or the University of California.
    The views and opinions of authors expressed herein do not necessarily
    state or reflect those of the United States Government or the University
    of California, and shall not be used for advertising or product
    endorsement purposes.  The precise terms and conditions for copying,
    distribution and modification follows.


> > Or linuxbios-payloads which contains all of them?
> 
> If at all, pack it into one of them.

Agreed.

 
> In my opinion linuxbios should not be more than two packages:
> 
> bios-utils and linuxbios-images (and I doubt whether we really want an
> -images package)

You mean image as in the images which will be flashed? I.e. pre-built binaries,
so that "end-users" would not need to compile anything at all? If that's
(easily) possible that would be a good idea indeed. It'll lower the learning-curve
for LinuxBIOS quite a lot, I think...


Anyways, I have created a small manpage for flashrom (Debian policy requires a
manpage for every binary executable) which will be in the package, feel free
to put it in svn if you want and if it makes sense...

The manpage probably needs some fixing and checking - e.g. I'm not sure I got all
of the authors right etc. Feel free to send me corrections...

Btw, where should I send (smaller) patches which fix some issues I notice while I'm
doing the packaging? This mailing list or the bug tracker?


Cheers, Uwe.
-- 
Uwe Hermann 
http://www.hermann-uwe.de
http://www.it-services-uh.de  | http://www.crazy-hacks.org 
http://www.holsham-traders.de | http://www.unmaintained-free-software.org
-------------- next part --------------
.TH FLASHROM 1 "July 26, 2006"
.SH NAME
flashrom \- the universal LinuxBIOS flash utility
.SH SYNOPSIS
.B flashrom \fR[\fB\-rwvEVflih\fR] [\fB\-c\fR chipname]
         [\fB\-s\fR exclude_start] [\fB\-e\fR exclude_end]
         [\fB-m\fR vendor:part] [file]
.SH DESCRIPTION
.B flashrom
is the universal LinuxBIOS flash utility.
.SH OPTIONS
If no file is specified, then all that happens
is that flash info is dumped and the flash chip is set to writable.

.B "\-r, \-\-read"
Read flash and save contents into file.
.PP
.B "\-w, \-\-write"
Write file into flash (default when file is specified).
.PP
.B "\-v, \-\-verify"
Verify flash against file.
.PP
.B "\-E, \-\-erase"
Erase flash device.
.PP
.B "\-V, \-\-verbose"
More verbose output.
.PP
.B "\-c, \-\-chip" <chipname>
Probe only for specified flash chip.
.PP
.B "\-s, \-\-estart" <addr>
Exclude start position.
.PP
.B "\-e, \-\-eend" <addr>
Exclude end postion.
.PP
.B "\-m, \-\-mainboard" <vendor:part>
Override mainboard settings.
.PP
.B "\-f, \-\-force"
Force write without checking image.
.PP
.B "\-l, \-\-layout"
Read ROM layout from file.
.PP
.B "\-i, \-\-image" <name>
Only flash image name from flash layout.
.PP
.B "\-h, \-\-help"
Show a help text and exit.
.\".PP
.\".B "\-\-version"
.\"Show version information and exit.
.SH BUGS
Please report any bugs at https://openbios.org/roundup/linuxbios/.
.SH LICENCE
.B flashrom
is covered by the GNU General Public License (GPL).
.SH SEE ALSO
.BR romcc (1).
.SH COPYRIGHT
2000 Silicon Integrated System Corporation
.br
2004 Tyan Corp
.br
2005-2006 coresystems GmbH
.br
2003 Niki W. Waibel
.SH AUTHORS
Yhlu <yhlu at tyan.com>
.br
Stefan Reinauer <stepan at coresystems.de>
.br
Niki W. Waibel <niki.waibel at gmx.net>
.PP
This manual page was written by Uwe Hermann <uwe at hermann-uwe.de>,
for the Debian GNU/Linux system (but may be used by others).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060727/6eda6205/attachment.sig>

From samuel.thibault at ens-lyon.org  Thu Jul 27 22:40:50 2006
From: samuel.thibault at ens-lyon.org (Samuel Thibault)
Date: Thu, 27 Jul 2006 22:40:50 +0200
Subject: [LinuxBIOS] LinuxBIOS Debian package.
In-Reply-To: <20060727202820.GD21020@aragorn>
References: <20060724153912.GB25437@aragorn>
	<20060724161620.GA6068@coresystems.de>
	<20060724173943.GA29640@aragorn>
	<20060724180811.GA8388@coresystems.de>
	<20060727202820.GD21020@aragorn>
Message-ID: <20060727204050.GE4066@implementation.ssgrr>

Uwe Hermann, le Thu 27 Jul 2006 22:28:20 +0200, a ?crit :
> > In fact, if we find a bug in romcc now and fix it, we can point people to
> > use revision XX from subversion and they are fine. I dont want to take
> > the overhead of explaining people they have to update their debian
> > package or switch the build process to use the "builtin version" for a
> > build time reduced by less then a second. Even opening my mail client 
> > takes longer than that.
> 
> Well, that's a general problem with packages - they _always_ lag behind
> upstream, some more and some less.

Yes, and since you'll have to fetch updates from cvs, you can choose to
do this frequently.

Samuel



From dhendrix at google.com  Thu Jul 27 22:52:26 2006
From: dhendrix at google.com (David Hendricks)
Date: Thu, 27 Jul 2006 13:52:26 -0700
Subject: [LinuxBIOS] LinuxBIOS Debian package.
In-Reply-To: <20060727204050.GE4066@implementation.ssgrr>
References: <20060724153912.GB25437@aragorn>
	<20060724161620.GA6068@coresystems.de>
	<20060724173943.GA29640@aragorn>
	<20060724180811.GA8388@coresystems.de>
	<20060727202820.GD21020@aragorn>
	<20060727204050.GE4066@implementation.ssgrr>
Message-ID: <ec9b26620607271352t4e3be4c6h8c881777e22d78ac@mail.google.com>

Apologies if I missed this earlier, but did anyone address the issue of
where this package would reside? Uwe, do you have an unofficial repo
somewhere that people could just add to sources.list? Should the repo be
hosted @ coresystems.de? Or is this going into an -experimental (or similar)
branch?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060727/c2d1cf13/attachment.html>

From uwe at hermann-uwe.de  Thu Jul 27 23:04:16 2006
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Thu, 27 Jul 2006 23:04:16 +0200
Subject: [LinuxBIOS] LinuxBIOS Debian package.
In-Reply-To: <20060724204732.GA23396@localdomain>
References: <20060724153912.GB25437@aragorn>
	<20060724161620.GA6068@coresystems.de>
	<20060724164124.GA22567@localdomain>
	<20060724174342.GB29640@aragorn>
	<20060724204732.GA23396@localdomain>
Message-ID: <20060727210416.GG21020@aragorn>

Hi Anton,

(note: CC to LinuxBIOS mailing list)

I've recently started creating LinuxBIOS Debian packages, and I'll
probably also package your BIOS tools if the license permits and if you
don't mind.

Is it correct that all of the *deco tools are GPL'd (it seems so)?
Also, where can I get the latest versions of all the tools, the only
page with download links I found is http://www.kaos.ru/biosgfx/index_2005.html
and the links there are all broken.
The links below from Ward Vandewege do work, however.

Do you plan to merge all of the tools into one big package one day? They
all look and work pretty similar, I guess... If so, I'd also create one
single Debian package. If not, should I have one Debian package for each tool,
or merge them myself into one big "biosdeco" package (or any other name)?
What do you think?


On Mon, Jul 24, 2006 at 10:47:32PM +0200, Ward Vandewege wrote:
> On Mon, Jul 24, 2006 at 07:43:42PM +0200, Uwe Hermann wrote:
> > >  Award BIOS: http://kaos.ru/biosgfx/download/awardeco-0.2.src.tar.gz
> > >  AMI BIOS: http://www.kaos.ru/biosgfx/download/AmiDeco_0.31e.src.tar.gz
> > >  Insyde BIOS: http://www.kaos.ru/biosgfx/download/InsyDeco_0.3.src.tar.gz
> > >  Phoenix BIOS: http://www.kaos.ru/biosgfx/download/PhoenixDeco_0.33.src.tar.gz
> > 
> > I'll have a look at them - if the license permits I'll package them.
> 
> Anton may have to clarify the license a bit. He did indicate to me that he
> was planning to release these under the GPL, but I'm not sure if all the
> source packages contain the proper files.


Cheers, Uwe.
-- 
Uwe Hermann 
http://www.hermann-uwe.de
http://www.it-services-uh.de  | http://www.crazy-hacks.org 
http://www.holsham-traders.de | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060727/f8dd0cd7/attachment.sig>

From danmez at gmail.com  Thu Jul 27 23:51:48 2006
From: danmez at gmail.com (Dan Mezynski)
Date: Thu, 27 Jul 2006 17:51:48 -0400
Subject: [LinuxBIOS] Comes up but cant see CMOS prompt or options
In-Reply-To: <8a0c36780607270727l15b63f9fwa4ee4e39a826d69c@mail.gmail.com>
References: <7b7e71620607261517n2322ecefj661f2311d3bfbf55@mail.gmail.com>
	<8a0c36780607270727l15b63f9fwa4ee4e39a826d69c@mail.gmail.com>
Message-ID: <7b7e71620607271451w5c387d02j11756c4acf13003@mail.gmail.com>

On 7/27/06, Richard Smith <smithbone at gmail.com> wrote:
>
> On 7/26/06, Dan Mezynski <danmez at gmail.com> wrote:
>
> >  I was able to setup config to include VGA bios and it seems to work but
> it
> > happens late in the flow, so a lot of printk messaages are not seen,
> they
> > only become visable after calling dev_initialize().
> >
> >  2 questions:
> >  * How can I get it so early printk messages come up?
>
> How are you doing video init?  If linuxbios is doing it then it should
> be done long before the kernel loads.


After groping around for awhile, with no text output from LB, I came upon
the nice document  on the website under "port guides"/"VGA support" which
detailed the procedure for combining the quartet.rom file with a
vga.romfile and this allowed me to see some text output from the LB
printk_notice
messages, but none of the printk_notice messages come before the call to
dev_initialize() which is called late in the hardwaremain() routine.  BTW
there is a coment in the beginning of hardwaremain() that says:

 /* displayinit MUST PRECEDE ALL PRINTK! */
        console_init();

But this call does not seem to do all that's needed to get
printk(printk_notice) messages to come to the console.

Note that I'm not yet getting Linux booted, I would love to get that far, it
just gets to elfboot then says:
Could not find a bouce buffer...
Cannot Load ELF Image

>  * Shouldnt there be an option to hit f-10 or some other key to get into
> > CMOS?
>
> 2 invalid assumptions.   There may be no CMOS or keyboard.


My goal was to play with the boot order, to boot from CD, to try to get
Linux to boot from LB.  I see that there is a reference to  cmos.layout in
src/config/Config.lb which  shows  option_table.c as dependent on
cmos.layout,  so  if an acceptable way to set boot order etc is to hand edit
the cmos.layout file then that's fine, I just need understand it better.
This file has the following snipet:
#start-bit length  config config-ID    name
.
.
.
416          4       e       7        boot_first
420          4       e       7        boot_second
424          4       e       7        boot_third
But I'm not sure what to do here, any suggestions?  Should I edit this
file?  How do I make the CD or floppy the first boot?  Is there
documentation on this?

Note that the mainboard/.../Options.lb file has HAVE_OPTION_TABLE=1
so I assume this means it's using the cmos.layout file.  Is this true?


--
> Richard A. Smith
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060727/e1911eb8/attachment.html>

From uwe at hermann-uwe.de  Fri Jul 28 00:08:50 2006
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Fri, 28 Jul 2006 00:08:50 +0200
Subject: [LinuxBIOS] LinuxBIOS Debian package.
In-Reply-To: <ec9b26620607271352t4e3be4c6h8c881777e22d78ac@mail.google.com>
References: <20060724153912.GB25437@aragorn>
	<20060724161620.GA6068@coresystems.de>
	<20060724173943.GA29640@aragorn>
	<20060724180811.GA8388@coresystems.de>
	<20060727202820.GD21020@aragorn>
	<20060727204050.GE4066@implementation.ssgrr>
	<ec9b26620607271352t4e3be4c6h8c881777e22d78ac@mail.google.com>
Message-ID: <20060727220850.GB26970@aragorn>

Hi,

On Thu, Jul 27, 2006 at 01:52:26PM -0700, David Hendricks wrote:
> Apologies if I missed this earlier, but did anyone address the issue of
> where this package would reside?

Um, well, in the Debian archive. When all is finished a user does
'apt-get install linuxbios' and that's it.

I could provide some DEBs for beta-testing maybe, but the goal is to get
the package into main Debian...


HTH, Uwe.
-- 
Uwe Hermann 
http://www.hermann-uwe.de
http://www.it-services-uh.de  | http://www.crazy-hacks.org 
http://www.holsham-traders.de | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060728/ece54640/attachment.sig>

From stepan at coresystems.de  Fri Jul 28 01:15:38 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Fri, 28 Jul 2006 01:15:38 +0200
Subject: [LinuxBIOS] Comes up but cant see CMOS prompt or options
In-Reply-To: <7b7e71620607271451w5c387d02j11756c4acf13003@mail.gmail.com>
References: <7b7e71620607261517n2322ecefj661f2311d3bfbf55@mail.gmail.com>
	<8a0c36780607270727l15b63f9fwa4ee4e39a826d69c@mail.gmail.com>
	<7b7e71620607271451w5c387d02j11756c4acf13003@mail.gmail.com>
Message-ID: <20060727231538.GB22232@coresystems.de>

* Dan Mezynski <danmez at gmail.com> [060727 23:51]:
> Note that I'm not yet getting Linux booted, I would love to get that far, it
> just gets to elfboot then says:
> Could not find a bouce buffer...
> Cannot Load ELF Image

Sounds like you are running out of HEAP. 

Ron wrote to this problem in his article:

http://www.linuxjournal.com/article/8310

 The real problem is LinuxBIOS thinks there is no memory. Remember that
in the beginning we set up the CPU with no functions to be called? It
turns out we do need to have some functions called, because part of what
the functions have to do is indicate how much memory there is. We can
look to another Northbridge chip for inspiration. It is pretty close to
the SC520 and avoids the complications of the K8 Northbridge, which are
very complex.


Regards,
Stefan


-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From smithbone at gmail.com  Fri Jul 28 01:42:43 2006
From: smithbone at gmail.com (Richard Smith)
Date: Thu, 27 Jul 2006 18:42:43 -0500
Subject: [LinuxBIOS] Comes up but cant see CMOS prompt or options
In-Reply-To: <7b7e71620607271451w5c387d02j11756c4acf13003@mail.gmail.com>
References: <7b7e71620607261517n2322ecefj661f2311d3bfbf55@mail.gmail.com>
	<8a0c36780607270727l15b63f9fwa4ee4e39a826d69c@mail.gmail.com>
	<7b7e71620607271451w5c387d02j11756c4acf13003@mail.gmail.com>
Message-ID: <8a0c36780607271642n642f0e60r7852294babb48f68@mail.gmail.com>

> After groping around for awhile, with no text output from LB, I came upon
> the nice document  on the website under "port guides"/"VGA support" which
> detailed the procedure for combining the quartet.rom file with a vga.rom
> file and this allowed me to see some text output from the LB printk_notice
> messages, but none of the printk_notice messages come before the call to
> dev_initialize() which is called late in the hardwaremain() routine.  BTW
> there is a coment in the beginning of hardwaremain() that says:
>
>  /* displayinit MUST PRECEDE ALL PRINTK! */
>         console_init();

Ah.. You are talking linuxbios printk.  Sorry I thought you were
talking kernel printk.  The reference to early printk confused me.

Are you getting messges on the serial port?  Its not clear to me.

> But this call does not seem to do all that's needed to get
> printk(printk_notice) messages to come to the console.

You are talking video console here not serial console right?

> My goal was to play with the boot order, to boot from CD, to try to get
> Linux to boot from LB.  I see that there is a reference to  cmos.layout in
> src/config/Config.lb which  shows  option_table.c as dependent on
> cmos.layout,  so  if an acceptable way to set boot order etc is to hand edit
> the cmos.layout file then that's fine, I just need understand it better.
> This file has the following snipet:
> #start-bit length  config config-ID    name

Yes. Typically everything in linuxbios is pre-set in the config files(s).

> 416          4       e       7        boot_first
> 420          4       e       7        boot_second
> 424          4       e       7        boot_third
> But I'm not sure what to do here, any suggestions?  Should I edit this file?
>  How do I make the CD or floppy the first boot?  Is there documentation on
> this?

Doubtfull.  Docs are scarce round these parts.  The place to look
would be in the FILO code.  Stefan (I think it was Stefan) reciently
added the capability to have some GRUBlike options on booting.

Sorry I can't be more descriptive but I've not played with it yet.

> Note that the mainboard/.../Options.lb file has HAVE_OPTION_TABLE=1
> so I assume this means it's using the cmos.layout file.  Is this true?
>

Yes.  However, we don't do much with that table.
grepping the source for HAVE_OPTION_TABLE shows its used in
mc146818rtc.c and by the Intel 82801ca southbridge code for checking
if the previous boot failed and falling back to the good image.

So unless FILO is using those options then I don't think they do anything.

-- 
Richard A. Smith



From stepan at coresystems.de  Fri Jul 28 02:07:06 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Fri, 28 Jul 2006 02:07:06 +0200
Subject: [LinuxBIOS] Comes up but cant see CMOS prompt or options
In-Reply-To: <8a0c36780607271642n642f0e60r7852294babb48f68@mail.gmail.com>
References: <7b7e71620607261517n2322ecefj661f2311d3bfbf55@mail.gmail.com>
	<8a0c36780607270727l15b63f9fwa4ee4e39a826d69c@mail.gmail.com>
	<7b7e71620607271451w5c387d02j11756c4acf13003@mail.gmail.com>
	<8a0c36780607271642n642f0e60r7852294babb48f68@mail.gmail.com>
Message-ID: <20060728000706.GB24515@coresystems.de>

* Richard Smith <smithbone at gmail.com> [060728 01:42]:
> > 416          4       e       7        boot_first
> > 420          4       e       7        boot_second
> > 424          4       e       7        boot_third
> > But I'm not sure what to do here, any suggestions?  Should I edit this file?
> >  How do I make the CD or floppy the first boot?  Is there documentation on
> > this?
> 
> Doubtfull.  Docs are scarce round these parts.  The place to look
> would be in the FILO code.  Stefan (I think it was Stefan) reciently
> added the capability to have some GRUBlike options on booting.
 
yep. that was me.

> Sorry I can't be more descriptive but I've not played with it yet.
[..]
> So unless FILO is using those options then I don't think they do anything.
 
FILO does not use them. I thought to remember Etherboot does (as it
allows several targets in one a la tg3--ide_disk.zelf) but I might be
wrong.

cd booting is one of the necessary features for FILO, especially parsing
isolinux.cfg files but it needs a little bit restructuring and I never
got around to do it yet. If someone wants to have a look, please do!

Maybe parsing CMOS variables would go well with that.

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From rminnich at lanl.gov  Fri Jul 28 05:00:23 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Thu, 27 Jul 2006 21:00:23 -0600
Subject: [LinuxBIOS] Comes up but cant see CMOS prompt or options
In-Reply-To: <20060728000706.GB24515@coresystems.de>
References: <7b7e71620607261517n2322ecefj661f2311d3bfbf55@mail.gmail.com>	<8a0c36780607270727l15b63f9fwa4ee4e39a826d69c@mail.gmail.com>	<7b7e71620607271451w5c387d02j11756c4acf13003@mail.gmail.com>	<8a0c36780607271642n642f0e60r7852294babb48f68@mail.gmail.com>
	<20060728000706.GB24515@coresystems.de>
Message-ID: <44C97DC7.9070008@lanl.gov>

Stefan Reinauer wrote:

> Maybe parsing CMOS variables would go well with that.
> 

now that we have linux in flash, we're going to have cmos in /sys

ron



From info at coresystems.de  Fri Jul 28 18:43:24 2006
From: info at coresystems.de (LinuxBIOS information)
Date: Fri, 28 Jul 2006 18:43:24 +0200
Subject: [LinuxBIOS] LinuxBIOS r2350 build changes
Message-ID: <E1G6VQq-0002In-6M@khepri.openbios.org>

Dear LinuxBIOS readers!

This is the automated build check service of LinuxBIOS.

The developer "rminnich" checked in revision 2350 to
the LinuxBIOS source repository and caused the following 
changes:

Change Log:
This patch adds support for the AMD LX cpu.There is one global change to pci_ids.h. The rest are changes for LX. Iran abuild and it is ok.  Not all artec design changes are included assome of them would adversely affect other mainboards. Indrek will needto test.Signed-off-by: Ron MinnichSigned-off-by: Indrek Kruusa, indrek.kruusa at artecdesign.ee, artecdesign.

Build Log:
 Configuration of artecgroup:dbe61 has been fixed. Compilation of artecgroup:dbe61 is still broken.

If something broke during this checkin please be a pain 
in rminnich's neck until the issue is fixed.

If this issue is not fixed within 24h the revision will 
be backed out.

   Yours truely,
     LinuxBIOS automatic build system





From rminnich at lanl.gov  Fri Jul 28 19:43:11 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Fri, 28 Jul 2006 11:43:11 -0600
Subject: [LinuxBIOS] amd LX code committed
Message-ID: <44CA4CAF.7010408@lanl.gov>

Thanks to the fine work if Indrek Kruusa, a tentative version of AMD LX 
support was committed today. I intend to test later today.

This is really great news. Thanks to Indrek for his fine work.

The first example mainboard is named artecdesign/dbe61

It will not build for you, as you need a gcc-3.4 compiler; I intend to 
test with 4.0 to see if that will work.

thanks

ron



From dpw at email.cs.arizona.edu  Sat Jul 29 04:41:07 2006
From: dpw at email.cs.arizona.edu (Don Waugaman)
Date: Fri, 28 Jul 2006 19:41:07 -0700
Subject: [LinuxBIOS] LinuxBIOS on ASUS P2B-L
Message-ID: <1154140868.9333.47.camel@cslewis>

Hi all,

I'm working on putting LinuxBIOS on an old ASUS P2B-L that I'd like to
convert into an "instant-on" server for home use.  It has an Intel 440BX
Host Bridge with Intel PIIX4e hard disk controller, and a Winbond
W83977TF SuperIO chip.  I downloaded the manuals for these various
chips, so I think I might have a shot at getting them working correctly
as long as I can get some debug output on the serial port.

Since this will be a server, I don't need any video support, though I'd
like to keep the card in the machine uninitialized for when I have to
boot the factory BIOS.  I've configured grub and the kernel to use the
serial port as the console, which works OK.  My plan is to use FILO as
the LinuxBIOS payload.

I've installed a BIOS Savior in the machine and flashed it with another
copy of the factory BIOS, which works OK, so (barring checks in the
utility's code) I should be able to use the ASUS AFLASH program rather
than flashrom.

First, I tried to build a FILO payload with serial console only and
USE_GRUB=1, which didn't work - it looked like it was still trying to
use the VGA console for some functions.  It worked OK when I commented
out the USE_GRUB line, but I'd still like to try the former
configuration - any FILO experts have any tips on how to squash the VGA
functions once and for all?

Then I grabbed the SVN trees for both v1 and v2.  I copied the
bitworks/ims mainboard and target directories, as they seemed to be
using the 440bx code, and I'm slogging through changing the various
bitworks & ims entries in the code to asus & p2bl entries.  So far, so
good, though I feel somewhat like I'm in a maze of twisty little
passages, all alike.

My main question is:  The W83977TF has support under v1, but not v2 -
any tips on porting from one to the other?  Also, once I have the
superIO initialization code installed, is there some way to get some
kind of debug output before  RAM initialization?  I'm not sure where to
put my own debugging output into the code - just a "hello, I'm here" is
all I need for starters.  I'd be happy for pointers to some docs which
might answer some of these questions - I perused some of what I could
find in the SVN tree and wiki, but ended up just trying to jump right in
instead.

Another big question would be - should I continue ahead with v2, or go
back to v1?  I noticed that v1 had the 440bx support as well, but it
looked like v2's configuration setup was a lot easier to deal with, so I
started there.  Would it be worth it to learn how v1 does things for
this project?

The other outstanding issue coming down the pike is that the machine has
all ECC RAM.  Is ECC supported by v1 or v2, and if not by either, which
would make it easiest to add support?  I'm assuming v2, but I'll try v1
if that would be easier.

Many thanks,

Don





From rminnich at lanl.gov  Sat Jul 29 05:32:49 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Fri, 28 Jul 2006 21:32:49 -0600
Subject: [LinuxBIOS] LinuxBIOS on ASUS P2B-L
In-Reply-To: <1154140868.9333.47.camel@cslewis>
References: <1154140868.9333.47.camel@cslewis>
Message-ID: <44CAD6E1.4050108@lanl.gov>

stick with v2.

For a writeup on how to do a port, check out my two linux journal 
articles -- I am told they can be helpful.

Yes, it's complex. Sorry, that is one thing we want to make easier with v3.

ron



From smithbone at gmail.com  Sat Jul 29 15:24:26 2006
From: smithbone at gmail.com (Richard Smith)
Date: Sat, 29 Jul 2006 08:24:26 -0500
Subject: [LinuxBIOS] LinuxBIOS on ASUS P2B-L
In-Reply-To: <1154140868.9333.47.camel@cslewis>
References: <1154140868.9333.47.camel@cslewis>
Message-ID: <8a0c36780607290624p2dfe09edw5e07256627fb920d@mail.gmail.com>

On 7/28/06, Don Waugaman <dpw at email.cs.arizona.edu> wrote:
> Hi all,
>
> I'm working on putting LinuxBIOS on an old ASUS P2B-L that I'd like to
> convert into an "instant-on" server for home use.  It has an Intel 440BX

Excellent Looks like we are finally going to get the 440bx stuff working.
ASUS however is a bit problematic.  They hide the SMbus with a GPIO or
something.  More below.

> Then I grabbed the SVN trees for both v1 and v2.  I copied the
> bitworks/ims mainboard and target directories, as they seemed to be
> using the 440bx code, and I'm slogging through changing the various
> bitworks & ims entries in the code to asus & p2bl entries.  So far, so
> good, though I feel somewhat like I'm in a maze of twisty little
> passages, all alike.

The learing curve is steep.  Stick with it.

You are in luck.  I've actually got booting code for my ASUS P2b. Both
V1 and V2.  In V1 you have to hammer in the RAM settings because like
I said the SMbus is either not in the same location as the 440bx
reference design or its hidden with a GPIO.  We will proballly have to
do a bit of sluthing work under a factory bios system and Linux to
find out what GPIO does the magic.

In V2 its exactly the same as the Bitworks IMS suff with the superIO
changed.  Current issue is that again SMbus stuff is not working.

> My main question is:  The W83977TF has support under v1, but not v2 -
> any tips on porting from one to the other?

I've done this already.  I'll push the code up in a few hours or so.
Its on a machine I don't have local access to right now.  Its pretty
easy though just find an existing SuperIO in V2 copy over the
structure and replace the names and  guts of the functions with the
stuff for the new SuperIO.  The NSC chip that the Bitoworks IMS uses
would be a good example.

> kind of debug output before  RAM initialization?  I'm not sure where to
> put my own debugging output into the code - just a "hello, I'm here" is

After I push up the p2b stuff, you can look at it.  Its  got some
debug output.  The file you want to look at is auto.c.  Thats the
first part of your mainboard config that is run.

> looked like v2's configuration setup was a lot easier to deal with, so I
> started there.  Would it be worth it to learn how v1 does things for
> this project?

V2 totally.  The only thing we are going to need V1 for is reference
of a working set of code.

> The other outstanding issue coming down the pike is that the machine has
> all ECC RAM.  Is ECC supported by v1 or v2, and if not by either, which
> would make it easiest to add support?  I'm assuming v2, but I'll try v1
> if that would be easier.

Neither of the codebases support ECC for the 440BX.  ECC is supported
by other chips in V2 though so we do have examples.
Can you run it in non-ECC (or scrape up some non-ECC Dimms) mode while
we debug and get some base functionality up?

-- 
Richard A. Smith



From smithbone at gmail.com  Sat Jul 29 19:53:21 2006
From: smithbone at gmail.com (Richard Smith)
Date: Sat, 29 Jul 2006 12:53:21 -0500
Subject: [LinuxBIOS] LinuxBIOS on ASUS P2B-L
In-Reply-To: <8a0c36780607290624p2dfe09edw5e07256627fb920d@mail.gmail.com>
References: <1154140868.9333.47.camel@cslewis>
	<8a0c36780607290624p2dfe09edw5e07256627fb920d@mail.gmail.com>
Message-ID: <8a0c36780607291053r2f431e0yfeac04575bf87089@mail.gmail.com>

> You are in luck.  I've actually got booting code for my ASUS P2b. Both
>
> > My main question is:  The W83977TF has support under v1, but not v2 -
> > any tips on porting from one to the other?
>
> I've done this already.  I'll push the code up in a few hours or so.
> Its on a machine I don't have local access to right now.

I just committed my framework for the Asus P2B.  Hopefully it works
for you.  It should come up and try to dump the contents of the SPD on
the RAM. But like I said its broken even without the Asus magic.  I'm
going to try and work on that today and see if I can discover
something.

So step one for P2B is to work with the board booted under factory
BIOS and see if we can figure out what GPIO is used to enable the
memory SMbus.

2.6 kernels know how to dump the SPD for a i440bx so see if you can do
that.  If that works then we just need to start comparing a
northbridge dump of the Asus vs a non-asus 440bx and see if any of the
GPIO are different.

-- 
Richard A. Smith



From info at coresystems.de  Sat Jul 29 20:17:51 2006
From: info at coresystems.de (LinuxBIOS information)
Date: Sat, 29 Jul 2006 20:17:51 +0200
Subject: [LinuxBIOS] LinuxBIOS r2351 build changes
Message-ID: <E1G6tNn-0006DP-1e@khepri.openbios.org>

Dear LinuxBIOS readers!

This is the automated build check service of LinuxBIOS.

The developer "rsmith" checked in revision 2351 to
the LinuxBIOS source repository and caused the following 
changes:

Change Log:
- Add support _framework_ for the Asus p2b.- New superIO winbond/w83977tf- Add single memory controller SBbus debug routineinto a file private to the i440bxThis adds support the start of support for an Asus p2bmainboard.  Current limitations are the same as for theBitworks IMS board.  Reads from the SMbus don't work.Moving dump_spd_registers() into its own private copysolves the problem of having to go hack on the version thatincluded in src/sdram to only do one memory controller.

Build Log:
 Compilation of artecgroup:dbe61 is still broken. Configuration of asus:p2b has been fixed. Compilation of asus:p2b has been fixed.

If something broke during this checkin please be a pain 
in rsmith's neck until the issue is fixed.

If this issue is not fixed within 24h the revision will 
be backed out.

   Yours truely,
     LinuxBIOS automatic build system





From info at coresystems.de  Sat Jul 29 20:58:25 2006
From: info at coresystems.de (LinuxBIOS information)
Date: Sat, 29 Jul 2006 20:58:25 +0200
Subject: [LinuxBIOS] LinuxBIOS r2352 build changes
Message-ID: <E1G6u13-00070I-45@khepri.openbios.org>

Dear LinuxBIOS readers!

This is the automated build check service of LinuxBIOS.

The developer "rsmith" checked in revision 2352 to
the LinuxBIOS source repository and caused the following 
changes:

Change Log:
- fixup Bitworks/IMS to use private copy of SMbus debug routinesRe-enable the SPD dump routine in this Bitworks/IMS code and makeit work like the Asus/p2b.  This avoids having to hack thesdram/generic_dump_spd.c for a single mem controller.

Build Log:
 Compilation of artecgroup:dbe61 is still broken.

If something broke during this checkin please be a pain 
in rsmith's neck until the issue is fixed.

If this issue is not fixed within 24h the revision will 
be backed out.

   Yours truely,
     LinuxBIOS automatic build system





From c-d.hailfinger.devel.2006 at gmx.net  Sat Jul 29 21:13:20 2006
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel U. Hailfinger)
Date: Sat, 29 Jul 2006 21:13:20 +0200
Subject: [LinuxBIOS] Winbond W39V040BPZ support in flash_rom?
Message-ID: <20060729191320.292640@gmx.net>

Hi,

my Asrock K8NF4G-SATA2 has a Winbond W39V040BPZ 4 Mbit LPC flash chip, but flash_rom doesn't find the chip.
Data sheet for the flash chip is available at http://winbond-usa.com/products/winbond_products/pdfs/Memory/W39V040Bd.pdf


# flashrom -V
Calibrating delay loop... Setting up microsecond timing loop
510M loops per second
ok
No LinuxBIOS table found.
Trying Am29F040B, 512 KB
probe_29f040b: id1 0xff, id2 0xff
Trying Am29F016D, 2048 KB
probe_29f040b: id1 0xff, id2 0xff
Trying At29C040A, 512 KB
probe_jedec: id1 0xff, id2 0xff
Trying Mx29f002, 256 KB
probe_29f002: id1 0xc, id2 0x92
Trying SST29EE020A, 256 KB
probe_jedec: id1 0xc, id2 0x92
Trying SST28SF040A, 512 KB
probe_28sf040: id1 0xff, id2 0xff
Trying SST39SF020A, 256 KB
probe_jedec: id1 0xc, id2 0x92
Trying SST39VF020, 256 KB
probe_jedec: id1 0xc, id2 0x92
Trying SST49LF040B, 512 KB
probe_jedec: id1 0xff, id2 0xff
Trying SST49LF040, 512 KB
probe_jedec: id1 0xff, id2 0xff
Trying SST49LF080A, 1024 KB
probe_jedec: id1 0xff, id2 0xff
Trying SST49LF002A/B, 256 KB
probe_jedec: id1 0xc, id2 0x92
Trying SST49LF003A/B, 384 KB
probe_jedec: id1 0x65, id2 0xf5
Trying SST49LF004A/B, 512 KB
probe_jedec: id1 0xff, id2 0xff
Trying SST49LF008A, 1024 KB
probe_jedec: id1 0xff, id2 0xff
Trying Pm49FL002, 256 KB
probe_jedec: id1 0xc, id2 0x92
Trying Pm49FL004, 512 KB
probe_jedec: id1 0xff, id2 0xff
Trying W29C011, 128 KB
probe_jedec: id1 0xff, id2 0xff
Trying W29C020C, 256 KB
probe_jedec: id1 0xc, id2 0x92
Trying W49F002U, 256 KB
probe_jedec: id1 0xc, id2 0x92
Trying W49V002A, 256 KB
probe_jedec: id1 0xc, id2 0x92
Trying W49V002FA, 256 KB
probe_jedec: id1 0xc, id2 0x92
Trying W39V040A, 512 KB
probe_jedec: id1 0xff, id2 0xff
Trying M29F040B, 512 KB
probe_29f040b: id1 0xff, id2 0xff
Trying M29F400BT, 512 KB
probe_m29f400bt: id1 0xff, id2 0xff
Trying 82802ab, 512 KB
probe_82802ab: id1 0xff, id2 0xff
Trying 82802ac, 1024 KB
probe_82802ab: id1 0xff, id2 0xff
Trying F49B002UA, 256 KB
probe_jedec: id1 0xc, id2 0x92
Trying LHF00L04, 1024 KB
probe_lhf00l04: id1 0xff, id2 0xff
No EEPROM/flash device found.


lspci excerpt follows:
00:0a.0 ISA bridge: nVidia Corporation MCP51 LPC Bridge (rev a2)
        Subsystem: ASRock Incorporation Unknown device 0261
        Flags: bus master, 66MHz, fast devsel, latency 0

00:0a.1 SMBus: nVidia Corporation MCP51 SMBus (rev a2)
        Subsystem: ASRock Incorporation Unknown device 0264
        Flags: 66MHz, fast devsel, IRQ 7
        I/O ports at 5000 [size=64]
        I/O ports at 6000 [size=64]
        Capabilities: [44] Power Management version 2


Any chance to get support for that flash chip on my board?

Regards,
Carl-Daniel
-- 


Echte DSL-Flatrate dauerhaft f?r 0,- Euro*. Nur noch kurze Zeit!
"Feel free" mit GMX DSL: http://www.gmx.net/de/go/dsl



From stepan at coresystems.de  Sat Jul 29 22:14:54 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sat, 29 Jul 2006 22:14:54 +0200
Subject: [LinuxBIOS] Winbond W39V040BPZ support in flash_rom?
In-Reply-To: <20060729191320.292640@gmx.net>
References: <20060729191320.292640@gmx.net>
Message-ID: <20060729201454.GA30947@coresystems.de>

The LPC device is not recognized.

Can you try to add your LPC device to the table in
flash_enable.c:enables[]

You have to find out the correct device ID since there are several IDs
for the LPC device you posted:
        0260  MCP51 LPC Bridge
        0261  MCP51 LPC Bridge
        0262  MCP51 LPC Bridge
        0263  MCP51 LPC Bridge

I'd start out using the enable_flash_ck804() function to enable flash
access on that system because the flash enable mechanism is often
similar across generations of LPC devices from one manufacturer.

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From smithbone at gmail.com  Sun Jul 30 02:33:26 2006
From: smithbone at gmail.com (Richard Smith)
Date: Sat, 29 Jul 2006 19:33:26 -0500
Subject: [LinuxBIOS] i440bx SPD reads are now functional
Message-ID: <8a0c36780607291733r118c88eel9e31f97a03362909@mail.gmail.com>

With all the interest in the i440bx I pulled out my old hardware and
debugged the SMbus reads.

I can now dump the contents of the SPD on my RAM.  Yah!!  Only took a
year or so.

Hopefully the rest can knock out pretty quickly.  I'll do some more
work tomorrow.

I have discoverd a some _very_ frustrating issues.  And I believe I've
reported one of these before.

Issue 1:

The dependency chain of the builds is not correct.  I spent close to 2
hours trying to figure out why my code was not working when the
problem was that my code was not getting recompiled by romcc.

The SPD code is done in a header file.  Pehaps this was the 1st
mistake but I copied it from the way another project did it.

If you make changes to that header file they are not picked up
properly.  So some work on dependency info may be in order.

Issue 2:

The build output of LinxBIOS is _way_ too noisy.  Its extremely
difficult to try and see if the code you are working on actually got
recompiled.

We need to work on reducing the noise level.

-- 
Richard A. Smith



From info at coresystems.de  Sun Jul 30 03:00:27 2006
From: info at coresystems.de (LinuxBIOS information)
Date: Sun, 30 Jul 2006 03:00:27 +0200
Subject: [LinuxBIOS] LinuxBIOS r2353 build changes
Message-ID: <E1G6zfP-0005zn-2J@khepri.openbios.org>

Dear LinuxBIOS readers!

This is the automated build check service of LinuxBIOS.

The developer "rsmith" checked in revision 2353 to
the LinuxBIOS source repository and caused the following 
changes:

Change Log:
- Fix some copy bugs and thinkos in the i440bx SMbusread code.  SBbus reads to RAM now work. Yah!- Rename the register constants to something I can look atmore easily.- Make the logic flow match the flow from V1 assembly- #if 0 out other SMbus functions that are still broken.

Build Log:
 Compilation of artecgroup:dbe61 is still broken.

If something broke during this checkin please be a pain 
in rsmith's neck until the issue is fixed.

If this issue is not fixed within 24h the revision will 
be backed out.

   Yours truely,
     LinuxBIOS automatic build system





From stepan at coresystems.de  Sun Jul 30 12:40:39 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sun, 30 Jul 2006 12:40:39 +0200
Subject: [LinuxBIOS] i440bx SPD reads are now functional
In-Reply-To: <8a0c36780607291733r118c88eel9e31f97a03362909@mail.gmail.com>
References: <8a0c36780607291733r118c88eel9e31f97a03362909@mail.gmail.com>
Message-ID: <20060730104038.GC19363@coresystems.de>

* Richard Smith <smithbone at gmail.com> [060730 02:33]:
> Issue 1:
> 
> The dependency chain of the builds is not correct.  I spent close to 2
> hours trying to figure out why my code was not working when the
> problem was that my code was not getting recompiled by romcc.
> 
> The SPD code is done in a header file.  Pehaps this was the 1st
> mistake but I copied it from the way another project did it.
> 
> If you make changes to that header file they are not picked up
> properly.  So some work on dependency info may be in order.
 
yes, in the build process auto.inc is only depending on auto.c but in
the real world this is not true. To fix this we would probably need to 
create dependencies with gcc -MM (can we use gcc, or would romcc have to
do this? Eric?) I did this dynamically for the flashrom utility a while
ago, but for all of LinuxBIOS this would be a major task.

> The build output of LinxBIOS is _way_ too noisy.  Its extremely
> difficult to try and see if the code you are working on actually got
> recompiled.
 
> We need to work on reducing the noise level.

One thing that desperately needs to happen is to pack all the
preprocessor macros into a .h file and include it, be it by replacing
all of them with a single --include preproc.h.

This has been wasting many hours of my time when the config mechanism
decided to calculate some negative offsets that would end up with a
compiler line including -DFOO=0x-fff3 leading to really crappy error
messages.

The way it is now its a complete waste of time to even look at the
compiler warnings. Which has by accident annoyed other people on this
list.

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From smithbone at gmail.com  Sun Jul 30 21:29:15 2006
From: smithbone at gmail.com (Richard Smith)
Date: Sun, 30 Jul 2006 14:29:15 -0500
Subject: [LinuxBIOS] i440bx SPD reads are now functional
In-Reply-To: <20060730104038.GC19363@coresystems.de>
References: <8a0c36780607291733r118c88eel9e31f97a03362909@mail.gmail.com>
	<20060730104038.GC19363@coresystems.de>
Message-ID: <8a0c36780607301229x1bd9af67jab37b3ba51aea360@mail.gmail.com>

 > yes, in the build process auto.inc is only depending on auto.c but in
> the real world this is not true. To fix this we would probably need to
> create dependencies with gcc -MM (can we use gcc, or would romcc have to
> do this? Eric?) I did this dynamically for the flashrom utility a while
> ago, but for all of LinuxBIOS this would be a major task.

Currently I'm just 'rm'ing auto.inc and auto.c (auto.* actually) in
the target as part of my build process.  Perhaps thats a good short
term fix?  Re-generate auto.c every time?

> One thing that desperately needs to happen is to pack all the
> preprocessor macros into a .h file and include it, be it by replacing
> all of them with a single --include preproc.h.
>

I've done a bit of work on this.  I've tweaked the generated config.py
so that outputs all the variables into a file called _board_options.h
as #define VAR VALUE.

The problem is that some of those variable strings need to be
interperted by the shell to get the right values.  And several of them
will not pass the compiler as is.

Currently I don't see any method of figureing out what variables are
ok for adding to the _board_options.h file.

I was thinking of extending the options.lb file to include a "scope"
parameter that indicates if the variable is ok for inclusion in to the
_board_options.h file or if it needs to go to the shell and make
system.

Any other ideas or perhaps something simpler?

-- 
Richard A. Smith



From stepan at coresystems.de  Sun Jul 30 23:43:19 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sun, 30 Jul 2006 23:43:19 +0200
Subject: [LinuxBIOS] i440bx SPD reads are now functional
In-Reply-To: <8a0c36780607301229x1bd9af67jab37b3ba51aea360@mail.gmail.com>
References: <8a0c36780607291733r118c88eel9e31f97a03362909@mail.gmail.com>
	<20060730104038.GC19363@coresystems.de>
	<8a0c36780607301229x1bd9af67jab37b3ba51aea360@mail.gmail.com>
Message-ID: <20060730214319.GA25226@coresystems.de>

* Richard Smith <smithbone at gmail.com> [060730 21:29]:
> Currently I'm just 'rm'ing auto.inc and auto.c (auto.* actually) in
> the target as part of my build process.  Perhaps thats a good short
> term fix?  Re-generate auto.c every time?
 
Do you have a patch?

> I've done a bit of work on this.  I've tweaked the generated config.py
> so that outputs all the variables into a file called _board_options.h
> as #define VAR VALUE.
> 
> The problem is that some of those variable strings need to be
> interperted by the shell to get the right values.  And several of them
> will not pass the compiler as is.

Can those be evaluated by the python config script during creation of
the script? or into an extra file "dynamic_options.h" during build time?

I guess you are talking about

- gcc version
- assembler version
- ld version
- build time

did i miss anything?

> I was thinking of extending the options.lb file to include a "scope"
> parameter that indicates if the variable is ok for inclusion in to the
> _board_options.h file or if it needs to go to the shell and make
> system.
> 
> Any other ideas or perhaps something simpler?

If we're talking about the above and nothing that is _board_ or _build_
specific (but only environment specific), lets add an extra include file
that is generated at build time (as opposed to configuration time) that
probes the build environment and adds those defines. 

They are only needed for philosophic reasons anyways: mailinglist
support aka "is your compiler broken" and "have I flashed the latest
version". This is not "configuration".


-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From smithbone at gmail.com  Mon Jul 31 05:46:07 2006
From: smithbone at gmail.com (Richard Smith)
Date: Sun, 30 Jul 2006 22:46:07 -0500
Subject: [LinuxBIOS] i440bx SPD reads are now functional
In-Reply-To: <20060730214319.GA25226@coresystems.de>
References: <8a0c36780607291733r118c88eel9e31f97a03362909@mail.gmail.com>
	<20060730104038.GC19363@coresystems.de>
	<8a0c36780607301229x1bd9af67jab37b3ba51aea360@mail.gmail.com>
	<20060730214319.GA25226@coresystems.de>
Message-ID: <8a0c36780607302046t2e572bcdo1629c78e5c06e6a5@mail.gmail.com>

> > the target as part of my build process.  Perhaps thats a good short
> > term fix?  Re-generate auto.c every time?
>
> Do you have a patch?

All it does is create the file which is pretty easy.  Nothing is done
with it.   So the patch would not be worth much.  I'll post up
something after I work out the shell variables thing.

> Can those be evaluated by the python config script during creation of
> the script? or into an extra file "dynamic_options.h" during build time?

Probably but I still need some sort of marker that indicates that this
particular variable needs post processing.  All the variables are in 2
lists and the current code just iterates the list kicking them out.
But now we have to be a bit smarter about what variable is what.

> I guess you are talking about
>
> - gcc version
> - assembler version
> - ld version
> - build time
>
> did i miss anything?

export ARCH:=i386
export CROSS_COMPILE:=
export CC:=$(CROSS_COMPILE)gcc -m32
export HOSTCC:=gcc
export OBJCOPY:=$(CROSS_COMPILE)objcopy --gap-fill 0xff

All of these need to be quoted at minimum to not cause compile errors.
  OBJCOPY needs to continue to get stuck into the makefile properly.

> If we're talking about the above and nothing that is _board_ or _build_
> specific (but only environment specific), lets add an extra include file
> that is generated at build time (as opposed to configuration time) that
> probes the build environment and adds those defines.

I'll see what I can come up with.

-- 
Richard A. Smith



From smithbone at gmail.com  Mon Jul 31 05:57:44 2006
From: smithbone at gmail.com (Richard Smith)
Date: Sun, 30 Jul 2006 22:57:44 -0500
Subject: [LinuxBIOS] i44bx notes
Message-ID: <8a0c36780607302057q734f5bdar41e90f85f96e2d21@mail.gmail.com>

I spent a bit of time reviewing the 440bx code I checked in.  Now that
the current blocker has been removed I should be able to make the
chipset work.

Seems I've made at least 2 poor decisions though.

1.  I named both the northbridge and the southbridge i440bx.  While I
don't think it s a huge problem.  The southbridge code needs to be
changed to piix4 since thats really what the part is.  I'll hopefully
be able to do that soon.

2.  I seemed to have based the framework on one of the VIA chips.  But
looking at things now I see a much better choice would have been the
Intel e7501.  Hopefully I can find some time to work on this a bit
this week.

But anybody else feel free to do this as well if you don't feel like
waiting on me.  Just post up that you want to do it and I'll send you
what my thoughts are.

-- 
Richard A. Smith



From indrek.kruusa at artecdesign.ee  Mon Jul 31 10:40:10 2006
From: indrek.kruusa at artecdesign.ee (Indrek Kruusa)
Date: Mon, 31 Jul 2006 11:40:10 +0300
Subject: [LinuxBIOS] amd LX code committed
In-Reply-To: <44CA4CAF.7010408@lanl.gov>
References: <44CA4CAF.7010408@lanl.gov>
Message-ID: <44CDC1EA.3030307@artecdesign.ee>

Ronald G Minnich wrote:
>
> The first example mainboard is named artecdesign/dbe61
:) It is artecgroup/dbe61. Anyway, thank you Ronald! I didn't hope that 
my nasty patch will make the way into official tree. This is excellent!

The compilation is currently broken though and the whole thing is far 
from the final LX support. E.g. what we should do with CS5536 code which 
currently includes GX2 definitions? Should we implement CPU_MODEL in 
src/config/Options.lb and #if GX2/LX includes based on this? Is there 
similar plans or solutions for v3?

I have to clarify that my changes were based on the awesome work from 
Heiki Kask. We continue working on the Geode LX support in LinuxBIOS 
together with Andrei Birjukov.


thanks,
Indrek




From dfeustel at mindspring.com  Sun Jul 30 16:47:51 2006
From: dfeustel at mindspring.com (dfeustel at mindspring.com)
Date: Sun, 30 Jul 2006 09:47:51 -0500 (CDT)
Subject: [LinuxBIOS] LinuxBios Virtualization Support
Message-ID: <0J38001TP13QUFU7@vms042.mailsrvcs.net>

FAQ Question?

Does the Linux Bios support enabling/disabling Intel/AMD
virtualization support for the operating system to be loaded
at boot? I.E. will hardware suppored virtualization for xen work?
(I think this capability may be dependent upon the motherboard being used).

Thanks,
Dave Feustel



From stepan at coresystems.de  Mon Jul 31 11:16:55 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 31 Jul 2006 11:16:55 +0200
Subject: [LinuxBIOS] i440bx SPD reads are now functional
In-Reply-To: <8a0c36780607302046t2e572bcdo1629c78e5c06e6a5@mail.gmail.com>
References: <8a0c36780607291733r118c88eel9e31f97a03362909@mail.gmail.com>
	<20060730104038.GC19363@coresystems.de>
	<8a0c36780607301229x1bd9af67jab37b3ba51aea360@mail.gmail.com>
	<20060730214319.GA25226@coresystems.de>
	<8a0c36780607302046t2e572bcdo1629c78e5c06e6a5@mail.gmail.com>
Message-ID: <20060731091655.GA2571@coresystems.de>

* Richard Smith <smithbone at gmail.com> [060731 05:46]:
> >Can those be evaluated by the python config script during creation of
> >the script? or into an extra file "dynamic_options.h" during build time?
> 
> Probably but I still need some sort of marker that indicates that this
> particular variable needs post processing.  All the variables are in 2
> lists and the current code just iterates the list kicking them out.
> But now we have to be a bit smarter about what variable is what.
 
Wow. great idea! The complexity this might introduce scares me a bit
though.

I think this can be made totally simple and stupid. 

dogma 1: build environment is not a linuxbios _configuration_ issue.
dogma 2: linuxbios configuration variables can not use shell at all.

> >I guess you are talking about
> >
> >- gcc version
> >- assembler version
> >- ld version
> >- build time
> >
> >did i miss anything?
> 
> export ARCH:=i386

Where's the problem with ARCH?

> export CROSS_COMPILE:=
> export CC:=$(CROSS_COMPILE)gcc -m32
> export HOSTCC:=gcc
> export OBJCOPY:=$(CROSS_COMPILE)objcopy --gap-fill 0xff
 
> All of these need to be quoted at minimum to not cause compile errors.
>  OBJCOPY needs to continue to get stuck into the makefile properly.
 
But none of them is needed within the code of LinuxBIOS, only in the
Makefile. I would suggest completely taking them out of the
configuration part and put them into the Makefile only. 

Like other projects do this, if someone wants another compiler, it can
be overridden when calling make. But this should be nothing for
LinuxBIOS to care about internally. Nor?

  Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From stepan at coresystems.de  Mon Jul 31 11:21:33 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 31 Jul 2006 11:21:33 +0200
Subject: [LinuxBIOS] i44bx notes
In-Reply-To: <8a0c36780607302057q734f5bdar41e90f85f96e2d21@mail.gmail.com>
References: <8a0c36780607302057q734f5bdar41e90f85f96e2d21@mail.gmail.com>
Message-ID: <20060731092133.GB2571@coresystems.de>

* Richard Smith <smithbone at gmail.com> [060731 05:57]:
> 1.  I named both the northbridge and the southbridge i440bx.  While I
> don't think it s a huge problem.  The southbridge code needs to be
> changed to piix4 since thats really what the part is.  I'll hopefully
> be able to do that soon.

or i82371ab - the intel ich parts have been using those numbers as well.
be it good or bad, but we might want to keep it consistent in one
direction or the other

 Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From rminnich at lanl.gov  Mon Jul 31 15:27:41 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 31 Jul 2006 07:27:41 -0600
Subject: [LinuxBIOS] amd LX code committed
In-Reply-To: <44CDC1EA.3030307@artecdesign.ee>
References: <44CA4CAF.7010408@lanl.gov> <44CDC1EA.3030307@artecdesign.ee>
Message-ID: <44CE054D.1000009@lanl.gov>

Indrek Kruusa wrote:

> The compilation is currently broken though and the whole thing is far 
> from the final LX support. E.g. what we should do with CS5536 code which 
> currently includes GX2 definitions? Should we implement CPU_MODEL in 
> src/config/Options.lb and #if GX2/LX includes based on this? Is there 
> similar plans or solutions for v3?

I don't want to drop that kind of stuff everywhere. I just need to 
understand why you did what you did, then I can try to make it work in 
linuxbios.

thanks

ron



From c-d.hailfinger.devel.2006 at gmx.net  Mon Jul 31 16:45:11 2006
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel U. Hailfinger)
Date: Mon, 31 Jul 2006 16:45:11 +0200
Subject: [LinuxBIOS] Winbond W39V040BPZ support in flash_rom?
In-Reply-To: <20060729201454.GA30947@coresystems.de>
References: <20060729191320.292640@gmx.net>
	<20060729201454.GA30947@coresystems.de>
Message-ID: <20060731144511.25800@gmx.net>

With the following (whitespace-damaged) patch

Index: flash.h
===================================================================
--- flash.h     (Revision 2350)
+++ flash.h     (Arbeitskopie)
@@ -59,6 +59,7 @@
 #define W_29C011          0xC1 /* Winbond w29c011 device code */
 #define W_29C020C         0x45 /* Winbond w29c020c device code */
 #define W_39V040A         0x3D /* Winbond w39v040a device code */
+#define W_39V040B         0x54 /* Winbond w39v040b device code */
 #define W_49F002U         0x0B /* Winbond w49F002u device code */
 #define W_49V002A         0xB0  /* Winbond W49V002A device code */
 #define W_49V002FA        0x32  /* Winbond W49V002FA device code */
Index: flash_enable.c
===================================================================
--- flash_enable.c      (Revision 2350)
+++ flash_enable.c      (Arbeitskopie)
@@ -396,6 +396,7 @@
        {0x1022, 0x7468, "AMD8111", enable_flash_amd8111},
        // this fallthrough looks broken.
         {0x10de, 0x0050, "NVIDIA CK804", enable_flash_ck804}, // LPC
+        {0x10de, 0x0261, "NVIDIA C51", enable_flash_ck804},
         {0x10de, 0x0051, "NVIDIA CK804", enable_flash_ck804}, // Pro
         {0x10de, 0x00d3, "NVIDIA CK804", enable_flash_ck804}, // Slave, should not be here, to fix known bug for A01.
        {0x1002, 0x4377, "ATI SB400", enable_flash_sb400}, // ATI Technologies Inc IXP SB400 PCI-ISA Bridge (rev 80)
Index: flashchips.c
===================================================================
--- flashchips.c        (Revision 2350)
+++ flashchips.c        (Arbeitskopie)
@@ -88,6 +88,8 @@
         probe_jedec,   erase_chip_jedec, write_49f002, NULL},
        {"W39V040A",    WINBOND_ID,     W_39V040A,      NULL, 512, 64*1024,
         probe_jedec,   erase_chip_jedec, write_39sf020, NULL},
+       {"W39V040B",    WINBOND_ID,     W_39V040B,      NULL, 512, 64*1024,
+        probe_jedec,   erase_chip_jedec, write_39sf020, NULL},
        {"M29F040B",    ST_ID,          ST_M29F040B,    NULL, 512, 64 * 1024,
         probe_29f040b, erase_29f040b,  write_29f040b,  NULL},
        {"M29F400BT",   ST_ID,          ST_M29F400BT,   NULL, 512, 64 * 1024,


I get this result:
# LinuxBIOSv2/util/flashrom/flashrom 
Calibrating delay loop... ok
No LinuxBIOS table found.
Enabling flash write on NVIDIA C51...OK
W39V040B found at physical address: 0xfff80000
Flash part is W39V040B
OK, only ENABLING flash write, but NOT FLASHING.

There is one small problem: I depend on this board very much since my laptop is in repair. So I can't test whether writing would work. The only difference between W39V040B (new) and W39V040A (supported) ist that W39V040B is a LPC chip instead of FWH. I don't know whether that matters for flashing.

Regards,
Carl-Daniel
-- 


Echte DSL-Flatrate dauerhaft f?r 0,- Euro*. Nur noch kurze Zeit!
"Feel free" mit GMX DSL: http://www.gmx.net/de/go/dsl



From stuge-linuxbios at cdy.org  Mon Jul 31 17:17:56 2006
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Mon, 31 Jul 2006 17:17:56 +0200
Subject: [LinuxBIOS] Winbond W39V040BPZ support in flash_rom?
In-Reply-To: <20060731144511.25800@gmx.net>
References: <20060729191320.292640@gmx.net>
	<20060729201454.GA30947@coresystems.de>
	<20060731144511.25800@gmx.net>
Message-ID: <20060731151756.28690.qmail@cdy.org>

On Mon, Jul 31, 2006 at 04:45:11PM +0200, Carl-Daniel U. Hailfinger wrote:
> There is one small problem: I depend on this board very much since my
> laptop is in repair. So I can't test whether writing would work. The
> only difference between W39V040B (new) and W39V040A (supported) ist
> that W39V040B is a LPC chip instead of FWH. I don't know whether that
> matters for flashing.

It shouldn't. FWH is also LPC, but with some added IO functionality.


//Peter



From yinghai.lu at amd.com  Mon Jul 31 19:23:57 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Mon, 31 Jul 2006 10:23:57 -0700
Subject: [LinuxBIOS] LinuxBios Virtualization Support
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A42070040E5@ssvlexmb2.amd.com>

According to my understanding, if your AMD CPU is rev F later, you
already got AMD-V support, so you can use Xen.

The way for LinuxBIOS system to use xen is

Linuxbios + (FILO or Etherboot or none) + tiny kernel in Flash (or HD,
or Network) with kexec support + kexec util to load final multi boot
image xen.gz and dom0 kernel ....

YH

-----Original Message-----
From: linuxbios-bounces at linuxbios.org
[mailto:linuxbios-bounces at linuxbios.org] On Behalf Of
dfeustel at mindspring.com
Sent: Sunday, July 30, 2006 7:48 AM
To: linuxbios at linuxbios.org
Subject: [LinuxBIOS] LinuxBios Virtualization Support

FAQ Question?

Does the Linux Bios support enabling/disabling Intel/AMD
virtualization support for the operating system to be loaded
at boot? I.E. will hardware suppored virtualization for xen work?
(I think this capability may be dependent upon the motherboard being
used).

Thanks,
Dave Feustel

-- 
linuxbios mailing list
linuxbios at linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios







From uwe at hermann-uwe.de  Mon Jul 31 20:04:14 2006
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Mon, 31 Jul 2006 20:04:14 +0200
Subject: [LinuxBIOS] GA-6BXC - first try.
Message-ID: <20060731180409.GA13592@aragorn>

Hi,

I've finally received my replacement BIOS - the good news is that my
motherboard still works (as does the replacement BIOS).

However, I seem to have some problems with LinuxBIOS (or I haven't read
enough docs, yet).

Here's what I did:

1. Checkout LinuxBIOSv2 as of today
2. cd util/flashrom
3. make
4. cd ../../targets
5. ./buildtarget bitworks/ims
6. cd bitworks/ims/ims
7. make
8. Replace (while system is running) the BIOS with a
   Winbond W49F002U-12B chip.
9. sudo ../../../util/flashrom/flashrom -w linuxbios.rom

Calibrating delay loop... ok
No LinuxBIOS table found.
No EEPROM/flash device found.


I also tried with an AM29F040B-90PC, with the same result...
Did I miss anything? Anyways, I'm off reading more docs.


Uwe.
-- 
Uwe Hermann 
http://www.hermann-uwe.de
http://www.it-services-uh.de  | http://www.crazy-hacks.org 
http://www.holsham-traders.de | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060731/bfbd5adb/attachment.sig>

From smithbone at gmail.com  Mon Jul 31 20:46:22 2006
From: smithbone at gmail.com (Richard Smith)
Date: Mon, 31 Jul 2006 13:46:22 -0500
Subject: [LinuxBIOS] GA-6BXC - first try.
In-Reply-To: <20060731180409.GA13592@aragorn>
References: <20060731180409.GA13592@aragorn>
Message-ID: <8a0c36780607311146g28ed8afyc0b04737ce0c0565@mail.gmail.com>

> 5. ./buildtarget bitworks/ims
> 6. cd bitworks/ims/ims
> 7. make

IMS uses a NSC pc87351 for the super IO.

Make sure you change the SuperIO to match your board.  Or you won't
get any output.

Remember that if it "works" all you are going to get is a dump of the
SPD, some messages on copying and jumping to RAM and then it will
crash.  Everthing else is  on the ToDo list. :)

> 9. sudo ../../../util/flashrom/flashrom -w linuxbios.rom
>
> Calibrating delay loop... ok
> No LinuxBIOS table found.
> No EEPROM/flash device found.
>
> I also tried with an AM29F040B-90PC, with the same result...
> Did I miss anything? Anyways, I'm off reading more docs.

I'm spoiled.  We have EEPROM/flash programmers.  So I've actually
never used flashrom.  But 29f04b have been suported for a while.

Try it with the -v option so we can see what the return values are
from the device check.

-- 
Richard A. Smith



From vernon at mauery.com  Mon Jul 31 22:12:26 2006
From: vernon at mauery.com (Vernon Mauery)
Date: Mon, 31 Jul 2006 12:12:26 -0800
Subject: [LinuxBIOS] linuxBIOS on a Thinkpad 570e
Message-ID: <200607311312.26692.vernon@mauery.com>

with google I found an old page that has since been removed from the linuxbios
website that had the beginnings of a story about putting linuxbios on a 
thinkpad
T22.  I guess the story never got finished?

I have a thinkpad 570e with the latest bios from IBM (1999) and wanted to
replace its hard drive with a compact flash card.  So I found a CF->IDE
converter, bought a CF card and tried to boot it.  But the bios doesn't
recognize the CF card as an IDE device.  A newer thinkpad T40 does find the 
card
and boot from it just fine.  So I know the card works as a disk.  But the BIOS
on the 570e is too old and stupid to find it.  So currently, I am using 
isolinux
to boot from a CD, load the kernel/initrd and then mount the CF card as /.

So I am coming to this list in hopes that I can find a way to update my bios 
so
that it will recognize the CF card as a bootable device.



--Vernon
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dmi
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060731/d2194b18/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: lspci
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060731/d2194b18/attachment-0001.ksh>