On Mon, Feb 22, 2010 at 2:13 PM, Joseph Smith wrote:
>
>
>
> Hello Keith, looks like you are on your way. Are you sure your CPU's are
> 6b1 and 6b4?
>
> I have this 6b4 on my board and it is a mobile FCBGA PIII:
> http://processorfinder.intel.com/details.aspx?sSpec=SL69K
>
> Anyways a few of us a
I think the memcpy/memset and decompressing are slow because of the Icache.
Only one instruction executes repeatedly in the asm code. It doesn't have to
access the instructions in the ROM every time. The memcpy/memset are easy to
narrow down to a single instruction. But ulzma() can not. So I don
On Mon, Feb 22, 2010 at 4:03 PM, Stefan Reinauer wrote:
> Does anyone have the hardware?
>
I doubt anyone does. The question here is, if no one can test it, are
we better off making a change we can not test, or removing the
support. If there is hardware so old that we can not test, i'm more
comf
On 2/23/10 12:45 AM, ron minnich wrote:
> There's a way to test this?
>
>
Not for me... it's 2 boards out of 20+
But we did the same conversion for i945 and i830 before, so it's
generally a good idea.
The smarter thing would be to convert the board to CAR, but if I had to
choose between those
There's a way to test this?
ron
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
See patch
wow this code could use an indent,... but I just exchanged all the ctrl->d0
by PCI_DEV(0, 0, 0) which took off a significant amount of register pressure
while compiling with romcc.
Enough to keep the code working with the unified assert.h I posted today.
Signed-off-by: Stefan Reinauer
On Sun, 21 Feb 2010 23:49:15 -0500, Keith Hui wrote:
> Greetings.
>
> I just tried the CVS coreboot v2 on my Asus P2B-LS motherboard. It's also
> partially working as it is similar to the already partially supported
P2B-F
> and P3B-F, which is encouraging. There are two other boards in this
se
On Sun, Feb 21, 2010 at 9:49 PM, Keith Hui wrote:
> Greetings.
>
> I just tried the CVS coreboot v2 on my Asus P2B-LS motherboard. It's also
> partially working as it is similar to the already partially supported P2B-F
> and P3B-F, which is encouraging. There are two other boards in this series,
>
On 22.02.2010 18:49, Stefan Reinauer wrote:
> On 2/22/10 5:59 PM, Peter Stuge wrote:
>
>> ron minnich wrote:
>>
>>
I still try to fancy what that panic room is. Is it the gdb
handler for the case that gdb is enabled?
>>> in my ideal world, the panic ro
On 2/22/10 5:59 PM, Peter Stuge wrote:
> ron minnich wrote:
>
>>> I still try to fancy what that panic room is. Is it the gdb
>>> handler for the case that gdb is enabled?
>>>
>> in my ideal world, the panic room is SerialICE.
>>
> That's a nice idea.
>
> I think interesting suggesti
On 2/22/10 5:29 PM, ron minnich wrote:
> I'm glad this works, but I am afraid I have a concern about it.
>
> I've become opposed to inline assembly on several principles in the
> last few years:
>
I have another one:
- no assembly outside of cpu/ and arch/i386
--
coreboot mailing list: coreboo
On 2/22/10 4:45 PM, Uwe Hermann wrote:
>> --- src/southbridge/intel/i82801gx/i82801gx_pcie.c (revision 5133)
>> +++ src/southbridge/intel/i82801gx/i82801gx_pcie.c (working copy)
>> @@ -75,7 +75,7 @@
>> reg16 |= (1 << 6);
>> pci_write_config16(dev, 0x50, reg16);
>>
>> -#if EVEN_MORE_
ron minnich wrote:
> > I still try to fancy what that panic room is. Is it the gdb
> > handler for the case that gdb is enabled?
>
> in my ideal world, the panic room is SerialICE.
That's a nice idea.
I think interesting suggestions for panic room go from debugging
(SerialICE, gdb) to monitor (c
On 2/22/10 3:57 PM, Uwe Hermann wrote:
>> So folks, if you agree that we should clean up coreboot and make it
>> easier for people, send me an Acked-by: for the above idea.
>>
>> Signed-off-by: Stefan Reinauer
>>
> Acked-by: Uwe Hermann
>
>
Awesome, thanks a lot!
> However, there are som
On Mon, Feb 22, 2010 at 05:33:14AM +0100, repository service wrote:
> Modified: trunk/src/arch/i386/include/arch/byteorder.h
> ==
> --- trunk/src/arch/i386/include/arch/byteorder.h Sun Feb 21 07:45:43
> 2010(r
On Mon, Feb 22, 2010 at 7:02 AM, Stefan Reinauer wrote:
> I still try to fancy what that panic room is. Is it the gdb handler for
> the case that gdb is enabled?
in my ideal world, the panic room is SerialICE. I just had a talk with
someone over the weekend (name not mentioned to protect the inn
Author: uwe
Date: Mon Feb 22 17:41:49 2010
New Revision: 5146
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5146
Log:
Random cosmetic fixes (trivial).
- Fix typos.
- Whitespace and consistency fixes.
- Make "menuconfig" help easily readable in 80x25 terminals / xterms.
- Use full/c
On Mon, Feb 22, 2010 at 8:34 AM, Patrick Georgi wrote:
> The other issue is that in an .s file, we're bound to function calling
> conventions. with __asm__, we can really include code.
I understand. But I work with a very nice operating system that has
never had a need for __asm__, so I question
On Sun, Feb 21, 2010 at 8:48 PM, Bao, Zheng wrote:
>
> Index: src/lib/memcpy.c
> ===
> --- src/lib/memcpy.c (revision 5133)
> +++ src/lib/memcpy.c (working copy)
> @@ -3,10 +3,14 @@
> {
> const char *src = vsrc;
>
Am 22.02.2010 17:31, schrieb ron minnich:
> The complex ways in which we have to convince gcc to do __asm__
> correctly make me wonder if we shouldn't start
> putting assembly into assembly into .s files, not .c files. If we have
> this much trouble with __asm__, how much are we really
> gaining wh
2010/2/21 Rudolf Marek :
> This patch adds clobber regs into the play as assembly trashes random
> registers.
> I was bitten by this while doing MSR I/O because ECX got corrupted. I
> attempted
> to create nice barrier for GCC while changing the stack location too.
The complex ways in which we
On Mon, Feb 22, 2010 at 6:57 AM, Uwe Hermann wrote:
> My main worry with this kind of stuff is that we get a certain degree of
> code duplication. As you correctly noted some of that just _looks_
> duplicated as the i82801xx driver is incomplete. But there's also stuff
> which _is_ generic for mo
On Sun, Feb 21, 2010 at 08:11:51AM +0100, Stefan Reinauer wrote:
> This is a general cleanup patch
> - drop include/part and move files to include/
> - get rid lots of warnings
> - make resource allocator happy with w83627thg
> - trivial cbmem resume fix
> - fix payload and log level settings in a
On Mon, 22 Feb 2010 15:54:08 +0100, Stefan Reinauer
wrote:
> On 2/22/10 1:56 PM, Joseph Smith wrote:
>> I use die in raminit for memory compatibility checks. If the memory is
> not
>> compatible, there is no use moving on...so we die().
>>
>>
> I agree... to some extent...
>
> The file I poste
On 2/22/10 1:33 PM, Peter Stuge wrote:
> Stefan Reinauer wrote:
>
>> Also, do we want to die() on an assert?
>>
> Ideally I would like coreboot to be so structured that an assert just
> leads to the current "task" being aborted, and then we try to
> continue as best as possible.
>
Yes. I
On Sat, Feb 20, 2010 at 11:32:45PM +0100, Stefan Reinauer wrote:
> Hi there,
>
> the intel southbridge drivers are a mess.
Ack.
> Why? Because it is simply unmaintainable. The unified driver is not
> unified, it's rather incomplete enough so nobody noticed. The ICH4 and
> ICH4M are very simila
On 2/22/10 1:25 PM, Peter Stuge wrote:
> repository service wrote:
>
>> +++ trunk/src/cpu/x86/smm/smihandler.c Mon Feb 22 10:32:33 2010
>> (r5141)
>>
> ..
>
>> @@ -145,8 +146,12 @@
>> /* Call chipset specific SMI handlers. This would be the place to
>> * add a CP
Author: stepan
Date: Mon Feb 22 15:55:16 2010
New Revision: 5145
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5145
Log:
Fix SMM handler comment. Thanks for noticing, Peter!
Signed-off-by: Stefan Reinauer
Acked-by: Stefan Reinauer
Modified:
trunk/src/cpu/x86/smm/smihandler.c
Mod
On 2/22/10 1:56 PM, Joseph Smith wrote:
> I use die in raminit for memory compatibility checks. If the memory is not
> compatible, there is no use moving on...so we die().
>
>
I agree... to some extent...
The file I posted does not change the explicit die() calls though but
only the implicit di
On Sat, 20 Feb 2010 17:39:03 -0500, Joseph Smith
wrote:
> On 02/20/2010 05:32 PM, Stefan Reinauer wrote:
>> Hi there,
>>
>> the intel southbridge drivers are a mess.
>>
>> I suggest to do the following:
>>
>> cd coreboot/src/southbridge
>> svn mv i82801ca i82801cx
>> svn mv i82801dbm i82801dx
>
Hi,
attached patch provides a working fallback/normal switch mechanism. It
only works with "tiny bootblock" style builds and allows for more
bootblock-level decision code to be added to the tree (eg. select based
on GPIO, CPUID, etc.), without duplicating that stuff in every single of
our mainboar
Author: oxygene
Date: Mon Feb 22 13:58:01 2010
New Revision: 5144
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5144
Log:
- Make walkcbfs capable of loading files other than the first
- Look more closely for files, which should make the code robust
against defective CBFS images, as lo
On Mon, 22 Feb 2010 12:42:48 +0100, Stefan Reinauer
wrote:
> Hi,
>
> I rewrote the ASSERT() and BUG() implementations (src/include/assert.h)
> from scratch.
> The old one used different messages for preram and ram stages and would
> not print any warnings if CONFIG_DEBUG was disabled.
> In the
Patrick Georgi wrote:
> This patch:
> - makes walkcbfs capable of loading files other than the first
> - look more closely for files, which should make the code robust
> against defective CBFS images, as long as the bootblock works
>
> With this, I managed to boot both fallback and normal with t
Hi,
there were still a couple of bugs in walkcbfs, but I got them now.
This patch:
- makes walkcbfs capable of loading files other than the first
- look more closely for files, which should make the code robust
against defective CBFS images, as long as the bootblock works
With this, I managed
Stefan Reinauer wrote:
> Also, do we want to die() on an assert?
Ideally I would like coreboot to be so structured that an assert just
leads to the current "task" being aborted, and then we try to
continue as best as possible.
It would be great to also have a panic room, but I agree that it
shoul
repository service wrote:
> +++ trunk/src/cpu/x86/smm/smihandler.cMon Feb 22 10:32:33 2010
> (r5141)
..
> @@ -145,8 +146,12 @@
> /* Call chipset specific SMI handlers. This would be the place to
>* add a CPU or northbridge specific SMI handler, too
>*/
> -
> -
Hi,
I rewrote the ASSERT() and BUG() implementations (src/include/assert.h)
from scratch.
The old one used different messages for preram and ram stages and would
not print any warnings if CONFIG_DEBUG was disabled.
In the case of CONFIG_DEBUG the code would die().
I wonder if that's the behavior
Author: stepan
Date: Mon Feb 22 12:27:33 2010
New Revision: 5143
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5143
Log:
drop empty x86emu Makefile
Deleted:
trunk/util/x86emu/Makefile
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Author: stepan
Date: Mon Feb 22 12:26:06 2010
New Revision: 5142
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5142
Log:
Inteltool: Add i830/Tolapai/Ich4 support
Signed-off-by: Stefan Reinauer
Acked-by: Stefan Reinauer
Modified:
trunk/util/inteltool/cpu.c
trunk/util/inteltool/
Author: stepan
Date: Mon Feb 22 10:32:33 2010
New Revision: 5141
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5141
Log:
mini update SMM:
- allow northbridge and cpu handlers, too
- support for older rev 2 cpus
Signed-off-by: Stefan Reinauer
Acked-by: Stefan Reinauer
Modified:
tr
Dear coreboot readers!
This is the automatic build system of coreboot.
The developer "stepan" checked in revision 5138 to
the coreboot repository. This caused the following
changes:
Change Log:
fix builds...
Signed-off-by: Stefan Reinauer
Acked-by: Stefan Reinauer
Build Log:
Compilation of
Author: stepan
Date: Mon Feb 22 10:28:15 2010
New Revision: 5140
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5140
Log:
drop two warnings (trivial)
Signed-off-by: Stefan Reinauer
Acked-by: Stefan Reinauer
Modified:
trunk/src/northbridge/intel/i82830/northbridge.c
Modified: trun
Author: stepan
Date: Mon Feb 22 10:27:26 2010
New Revision: 5139
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5139
Log:
CONFIG_ was missing.
Signed-off-by: Stefan Reinauer
Acked-by: Stefan Reinauer
Modified:
trunk/src/mainboard/intel/eagleheights/fadt.c
Modified: trunk/src/mainb
Author: stepan
Date: Mon Feb 22 10:15:13 2010
New Revision: 5138
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5138
Log:
fix builds...
Signed-off-by: Stefan Reinauer
Acked-by: Stefan Reinauer
Modified:
trunk/src/mainboard/amd/serengeti_cheetah_fam10/romstage.c
trunk/src/mainboa
45 matches
Mail list logo
