Note new patch attached, in response to comments.
On 8/27/07, Peter Stuge <[EMAIL PROTECTED]> wrote:
> > Index: include/lar.h
> > ===
> > --- include/lar.h (revision 464)
> > +++ include/lar.h (working copy)
> > @@ -54,7 +54,
On Mon, Aug 27, 2007 at 11:34:21PM +0100, Matthew Bloch wrote:
> Okay so now I'll try to flash the new one:
>
> mnas:~/LinuxBIOSv2/targets/via/epia-m/epia-m# flashrom linuxbios.rom
Add -w to actually write.
We should add a message to flashrom in case no action option is
specified. (-v, -r or -w)
Corey Osgood wrote:
> You'd need an RD1-PL IIRC, and they're sold out every place I know of,
> and IOSS has stopped manufacturing them. You can check the compatibility
> list at ioss.com.tw to be sure. This might be helpful as well:
> http://www.linuxbios.org/pipermail/linuxbios/2007-April/019809.h
Peter Stuge wrote:
>> +for(i = 0, entry = (void *)0; ;i++) {
>> +char filename[64];
>> +void *newentry;
>> +sprintf(filename, "normal/payload%d", i);
>> +archive.len = *(u32 *)0xfff4;
>> +archive.start =(void *)(0UL-archive.len);
>
Matthew Bloch wrote:
> Corey Osgood wrote:
>
>> Yeah, that's definitely the best practice. There's really no option for
>> recovery if something goes wrong, except to hotswap and flash the chip
>> in another system.
>>
>
> Hm, I do have another epia-m in a soon-to-be-redundant server in Lon
On Mon, Aug 27, 2007 at 10:25:42AM -0700, ron minnich wrote:
> LAR is a very capable format. With two simple extensions, we can
> use LAR to replace all that we are using ELF for now.
Awesome!
Some comments on the patch, most are trivial:
> Index: include/lar.h
> ==
Janek Kozicki schrieb:
> This is a bit OT, but related to A8N-E motherboard.
>
> Does anybody know if quad-core barcelona processor will fit into this
> motherboard? Socket 939.
>
>
I thought there was only a single board out there for that obscure AMD
quad core. and it not the A8n-E, I would
Corey Osgood wrote:
> Yeah, that's definitely the best practice. There's really no option for
> recovery if something goes wrong, except to hotswap and flash the chip
> in another system.
Hm, I do have another epia-m in a soon-to-be-redundant server in London
and this gave me hope:
http://www.vi
Matthew Bloch wrote:
> Corey Osgood wrote:
>
>> Matthew Bloch wrote:
>>
>>> Corey Osgood wrote:
>>> [snip]
>>>
>>>
This is exactly as it says. In src/mainboard/via/epia-m/Config.lb, there
should be an XIP_ROM_SIZE and XIP_ROM_BASE, the base must be a multiple
of the
Corey Osgood wrote:
> Matthew Bloch wrote:
>> Corey Osgood wrote:
>> [snip]
>>
>>> This is exactly as it says. In src/mainboard/via/epia-m/Config.lb, there
>>> should be an XIP_ROM_SIZE and XIP_ROM_BASE, the base must be a multiple
>>> of the size. I had a bit of trouble working around this mysel
Matthew Bloch wrote:
> Corey Osgood wrote:
> [snip]
>
>> This is exactly as it says. In src/mainboard/via/epia-m/Config.lb, there
>> should be an XIP_ROM_SIZE and XIP_ROM_BASE, the base must be a multiple
>> of the size. I had a bit of trouble working around this myself at one
>> point, I think
Corey Osgood wrote:
[snip]
> This is exactly as it says. In src/mainboard/via/epia-m/Config.lb, there
> should be an XIP_ROM_SIZE and XIP_ROM_BASE, the base must be a multiple
> of the size. I had a bit of trouble working around this myself at one
> point, I think I determined that I just couldn't
Matthew Bloch wrote:
> Hi there,
>
> I am trying to build a LinuxBIOS setup to turn an Epia-M board into a
> NAS server and am stuck on the configuration.
>
> FILO is built and tested (with grub).
>
> I've now checked out LinuxBIOSv2, and am trying to use this configuration:
>
> mnas:~/LinuxBIOSv2/
Steffen D. wrote:
> Dear Mailinglist,
>
> im trying to build a bios for GeodeLX cpu. I have a development board
> from LogicPC. Afaik this is the same board that was used for the
> development for OLCP.
> I try it with the svn version Linuxbios-3. I have made a image with make
> menuconfig an
Stefan Reinauer wrote:
> Carl-Daniel Hailfinger wrote:
>
>> Hi,
>>
>> since we're aiming for broader coverage in LinuxBIOS and related tools,
>> I think we should publish a "Call for Action" which urges interested
>> people to give us dumps of their board configuration etc.
>>
>>
>>
> We
Hi there,
I am trying to build a LinuxBIOS setup to turn an Epia-M board into a
NAS server and am stuck on the configuration.
FILO is built and tested (with grub).
I've now checked out LinuxBIOSv2, and am trying to use this configuration:
mnas:~/LinuxBIOSv2/targets/via/epia-m/epia-m# cat ../Con
On Mon, Aug 27, 2007 at 01:41:54PM +0200, Carl-Daniel Hailfinger wrote:
> This patch makes ITE SuperI/O probing/dumping a little bit more generic,
> fixes minor codingstyle issues and prepares the table for supporting
> more chips of the ITE IT87xx SuperI/O family.
Tested on my two ITE-powered boa
This is a bit OT, but related to A8N-E motherboard.
Does anybody know if quad-core barcelona processor will fit into this
motherboard? Socket 939.
--
Janek Kozicki |
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.
On 8/22/07, Uwe Hermann <[EMAIL PROTECTED]> wrote:
>
> Looks correct, but using "stages" _and_ "phases" will confuse the hell
> out of everyone. I vote for only using stage 0-2, just drop the phases
> terminology completely. Or maybe something like "which consists of
> multiple steps"?
oh, no, I
On 8/27/07, Carl-Daniel Hailfinger <[EMAIL PROTECTED]> wrote:
> Streaming decompress for lzma (in the byte-wise decompress meaning)
> needs quite a big buffer, so it is not attractive. However, if you mean
> segment-wise decompress (if segments are compressed individually), that
> would work fine.
On 27.08.2007 19:25, ron minnich wrote:
> don't get too scared about the subject line.
>
> LAR is a very capable format. With two simple extensions, we can use
> LAR to replace all that we are using ELF for now. This change can
> really make life better:
> 1. we can use streaming decompress instea
don't get too scared about the subject line.
LAR is a very capable format. With two simple extensions, we can use
LAR to replace all that we are using ELF for now. This change can
really make life better:
1. we can use streaming decompress instead of the current "uncompress
elf to memory and then
Carl-Daniel Hailfinger wrote:
> Hi,
>
> since we're aiming for broader coverage in LinuxBIOS and related tools,
> I think we should publish a "Call for Action" which urges interested
> people to give us dumps of their board configuration etc.
>
>
We had such calls before, and people would send i
Hi,
since we're aiming for broader coverage in LinuxBIOS and related tools,
I think we should publish a "Call for Action" which urges interested
people to give us dumps of their board configuration etc.
Example of such a call (for flashrom only, though):
http://lists.us.dell.com/pipermail/firmwar
Dear Mailinglist,
im trying to build a bios for GeodeLX cpu. I have a development board
from LogicPC. Afaik this is the same board that was used for the
development for OLCP.
I try it with the svn version Linuxbios-3. I have made a image with make
menuconfig and configured everything cleary for
This patch makes ITE SuperI/O probing/dumping a little bit more generic,
fixes minor codingstyle issues and prepares the table for supporting
more chips of the ITE IT87xx SuperI/O family.
Signed-off-by: Carl-Daniel Hailfinger <[EMAIL PROTECTED]>
--- LinuxBIOSv2/util/probe_superio/probe_superio.c
* Uwe Hermann <[EMAIL PROTECTED]> [070827 10:16]:
> Hi,
>
> here's my proposal for moving (via 'svn mv') common utilities which are
> not specific to a certain version of LinuxBIOS into the global util/
> (they are now in the v2 util/).
>
>
> Todo
>
> abuild -- needs discussion; wil
* Uwe Hermann <[EMAIL PROTECTED]> [070827 10:05]:
> Not sure; do we want _all_ utilities replicated in all versions of
> LinuxBIOS? I'd say we move all common utilities into util/
> (will send a proposal later), and only replicate very few, often-needed
> utilities in the respective v2/v3 trees? Co
Hi,
here's my proposal for moving (via 'svn mv') common utilities which are
not specific to a certain version of LinuxBIOS into the global util/
(they are now in the v2 util/).
Todo
abuild -- needs discussion; will it work for v3 eventually?
ADLO -- is/should be version-in
Dear LinuxBIOS readers!
This is the automated build check service of LinuxBIOS.
The developer "stepan" checked in revision 2749 to
the LinuxBIOS source repository and caused the following
changes:
Change Log:
This patch rewrites probe_superio almost completely.
Common code sequences have been f
On Mon, Aug 27, 2007 at 09:30:15AM +0200, Stefan Reinauer wrote:
> Carl-Daniel Hailfinger wrote:
> >> This is a really nice patch, on the long run we can make probe_superio
> >> (though I would rename it to 'superio-detect' personally) a
> >> general-purpose tool for detecting and investigating Sup
Carl-Daniel Hailfinger wrote:
>> This is a really nice patch, on the long run we can make probe_superio
>> (though I would rename it to 'superio-detect' personally) a
>> general-purpose tool for detecting and investigating Super I/Os.
>>
>
> Can you commit? I'll send a followup patch to fix th
Author: stepan
Date: 2007-08-27 09:28:28 +0200 (Mon, 27 Aug 2007)
New Revision: 2749
Modified:
trunk/LinuxBIOSv2/util/probe_superio/probe_superio.c
Log:
This patch rewrites probe_superio almost completely.
Common code sequences have been factored out, the code has been made
more generic, has be
33 matches
Mail list logo
