> Now Andrew if we could track down a collection of Tadpole VME bus based
> boards wearing the M68K family of processors..
> (Ignore that remark fellow Coreboot participants, that's a side-remark to
> Andrew G.
Now if I could only find a spare VME chasis to put this here TP43M in,
I could have
Hello!
Yes indeed, I did look at the page.
But I am miffed over the passing of General Software. The fellow who
launched it, escaped from Micro$~ft to create a version of DOS that was
real-time friendly. And then they buried that product hoping to capitalize
on the growing embedded BIOS market...
On Tue, Sep 01, 2009 at 03:00:44PM +0200, Arnaud Maye wrote:
> The DSDT been dumped from the legacy BIOS using acpidump and this is
> what I am including in the build process to test. Actually I've based my
> code on the mainboard\intel\eagleheigths.
As others have mentioned, using the stock D
On 01.09.2009 22:15, Rudolf Marek wrote:
>> On 01.09.2009 15:00, Arnaud Maye wrote:
>>> I've been implementing the ACPI for the ep80579 and so far it is not
>>> going very well. Linux refuses to boot unless I use acpi=off or
>>> acpi=ht as boot parameters. acpi=ht seems to display my ACPI ioports
>
Hi
On 01.09.2009 15:00, Arnaud Maye wrote:
I've been implementing the ACPI for the ep80579 and so far it is not
going very well. Linux refuses to boot unless I use acpi=off or
acpi=ht as boot parameters. acpi=ht seems to display my ACPI ioports
in proc/ioports as expected ( the ioports addresse
ron minnich wrote:
On Fri, Aug 28, 2009 at 8:34 AM, Marc Jones wrote:
http://www.bizjournals.com/seattle/stories/2008/09/01/daily3.html?ana=from_rss
http://en.wikipedia.org/wiki/Phoenix_Technologies
interesting, the consolidation continues. Do you think they killed the
product or are still re
On Tue, Sep 1, 2009 at 7:00 AM, Arnaud Maye wrote:
> Hello Myles, Kevin and others
>
> I've been implementing the ACPI for the ep80579 and so far it is not going
> very well. Linux refuses to boot unless I use acpi=off or acpi=ht as boot
> parameters. acpi=ht seems to display my ACPI ioports in pro
Is there some way to find out the "correct" maximum speed, as on Hyper
Transport?
Yes there is but it is fixed for the known SB/NB combinations so we don't need
this yet. Also for each mode a set of fine tunes is necessary.
Acked-by: Stefan Reinauer
Ok thanks.
I forgot to Signed-off-by:
Author: ruik
Date: 2009-09-01 17:29:12 +0200 (Tue, 01 Sep 2009)
New Revision: 4625
Modified:
trunk/coreboot-v2/src/southbridge/via/vt8237r/vt8237_ctrl.c
Log:
As more users of Asus M2V-MX SE emerged. Here is long pending patch I wanted to
write. It boots the SB/NB V-link performance to full dupl
Stefan Reinauer wrote:
> Ah right.. I misunderstood the API.
No problem.
> Shouldn't the code for Darwin be only compiled into the Darwin
> executable, and the code for Linux only on Linux systems?
>
> Doing a check every time the program runs when it can be checked at
> compile time seems a bi
Hi Arnaud,
On 01.09.2009 15:00, Arnaud Maye wrote:
> I've been implementing the ACPI for the ep80579 and so far it is not
> going very well. Linux refuses to boot unless I use acpi=off or
> acpi=ht as boot parameters. acpi=ht seems to display my ACPI ioports
> in proc/ioports as expected ( the iop
Gregg Levine wrote:
> On Tue, Sep 1, 2009 at 6:29 AM, Stefan Reinauer wrote:
>
>> Hi,
>>
>> As a weekend project I had been porting coreboot utilities to Mac OS X.
>>
>> I put up a new set of installer images, source code and patches to
>>
>> http://www.coresystems.de/~stepan/OSX/
>>
>> The orde
Hello Myles, Kevin and others
I've been implementing the ACPI for the ep80579 and so far it is not
going very well. Linux refuses to boot unless I use acpi=off or acpi=ht
as boot parameters. acpi=ht seems to display my ACPI ioports in
proc/ioports as expected ( the ioports addresses are all ma
On Tue, Sep 1, 2009 at 6:29 AM, Stefan Reinauer wrote:
> Hi,
>
> As a weekend project I had been porting coreboot utilities to Mac OS X.
>
> I put up a new set of installer images, source code and patches to
>
> http://www.coresystems.de/~stepan/OSX/
>
> The order of installation should be:
> - Dir
Hi,
As a weekend project I had been porting coreboot utilities to Mac OS X.
I put up a new set of installer images, source code and patches to
http://www.coresystems.de/~stepan/OSX/
The order of installation should be:
- DirectIO 1.1
- pciutils 3.1.4
- coreboot-utils 1.0
All packages are both
Author: stepan
Date: 2009-09-01 12:03:01 +0200 (Tue, 01 Sep 2009)
New Revision: 4624
Added:
trunk/util/msrtool/darwin.c
Modified:
trunk/util/msrtool/Makefile.in
trunk/util/msrtool/configure
trunk/util/msrtool/msrtool.c
trunk/util/msrtool/msrtool.h
trunk/util/msrtool/sys.c
Log:
po
Author: stepan
Date: 2009-09-01 11:57:55 +0200 (Tue, 01 Sep 2009)
New Revision: 4623
Modified:
trunk/util/superiotool/Makefile
trunk/util/superiotool/superiotool.h
Log:
* Add OSX/Darwin support
* Add DESTDIR support
Signed-off-by: Stefan Reinauer
Acked-by: Peter Stuge
Modified: trunk/
Author: stepan
Date: 2009-09-01 11:54:21 +0200 (Tue, 01 Sep 2009)
New Revision: 4622
Modified:
trunk/util/nvramtool/Makefile
trunk/util/nvramtool/common.h
trunk/util/nvramtool/nvramtool.spec
Log:
nvramtool:
* Add OSX/Darwin support
* Add $DESTDIR support
* Clean up make install/spec
Si
Author: stepan
Date: 2009-09-01 11:52:14 +0200 (Tue, 01 Sep 2009)
New Revision: 4621
Modified:
trunk/util/inteltool/Makefile
trunk/util/inteltool/cpu.c
trunk/util/inteltool/inteltool.c
trunk/util/inteltool/inteltool.h
Log:
Clean up Mac OS X support of inteltool
Signed-off-by: Stefan R
19 matches
Mail list logo
