Hi guys,
On Oct 13, 2010, at 3:53 PM, Carl-Daniel Hailfinger wrote:
>
> Side note: It would be really cool if we could get full video coverage
> this time. If Adrian Glaubitz is there again with a video camera, we
> could ask him. Rudolf, I think you also brought someone who had a video
> camera.
]> > At 1600x1200, 16-bit color is almost perfect. But the same
]> > resolution with 32-bit color results in a display that jumps so
]> > much it cannot be read. Why would 32-bit color make a difference?
]>
]
]Twice the bandwidth needed to get the graphics data out of RAM.
]
]
]> > I am thinking
On 10/14/10 3:27 PM, Uwe Hermann wrote:
>> Maybe we should drop those flags from Kconfig completely and just set the
>> right ROMCCFLAGS in the socket's makefile to remove any confusion about the
>> meaning of thos flags.
> It's worth considering IMHO, yes. Or, actually, since sooner or later
>
I see that this removes the DCACHE_RAM_BASE from the src/cpu/intel hierarchy,
but there are also intel mainboards that define this value, apparently
needlessly. Should this patch include those also?
Thanks,
wt
On Thursday, October 14, 2010 04:02:34 pm Uwe Hermann wrote:
> See patch.
>
>
> Uwe
Uwe Hermann wrote:
> Drop unused DCACHE_RAM_BASE from intel/car/cache_as_ram.inc-using sockets.
>
> This CAR implementation hardcodes the Cache-as-RAM base address to:
>
> 0xd - CacheSize
>
> so the DCACHE_RAM_BASE is never actually used for this implementation
> and these sockets.
>
> Si
Hi,
I tried the instructions for getting serialICE installed, but ran into
two problems (patch attached solved both problems):
1) the configure script failed to detect lua, fixed by adding
--extra-ldflags="-lm" to the build.sh file. The output of the lua test
(with redirect to dev/null rem
Hello,
I have attached a patch which adds support to serial ice for the Truxton
dev kit mainboard using the EP80579 processor. This patch copies code
from the coreboot project to initialize the serial port. The affected
code is from the sourthbridge/intel/i3100/i3100_early_lpc.c and
superi
Hi Warren,
the patch is tested on real board. I'm porting coreboot to a K8 board
with RS780+SB700 chipset, the RS780 is linked in CPU's HT chain 1,
after patching I get the correct HT_SPEED register value.
On 10/11/10, Warren Turkal wrote:
> From a pure style perspective, the code looks ok. Have
Author: uwe
Date: Fri Oct 15 01:40:10 2010
New Revision: 5952
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5952
Log:
Cosmetics in ioapic.c (trivial, no functional changes).
Signed-off-by: Uwe Hermann
Acked-by: Uwe Hermann
Modified:
trunk/src/arch/i386/lib/ioapic.c
Modified: tr
On 10/14/2010 06:27 PM, Uwe Hermann wrote:
On Thu, Oct 14, 2010 at 08:58:35AM -0700, Stefan Reinauer wrote:
On 14.10.2010, at 05:38, Joseph Smith wrote:
Anyways why can't cpu specific features be implemented at the model level and
not at the socket level???
Because SSE, SSE2 and MMX are n
I used to be familiar with that code and I find a 1600 line patch a
little daunting. Who's testing which board?
If a board can not be tested, I think it ought to be left alone or
removed. Otherwise you risk leaving a board in a broken state, which
someone else will discover at a later date.
ron
See patch.
Uwe.
--
http://hermann-uwe.de | http://sigrok.org
http://randomprojects.org | http://unmaintained-free-software.org
Drop unused DCACHE_RAM_BASE from intel/car/cache_as_ram.inc-using sockets.
This CAR implementation hardcodes the Cache-as-RAM base address to:
0xd - CacheSiz
On Thu, Oct 14, 2010 at 08:58:35AM -0700, Stefan Reinauer wrote:
> On 14.10.2010, at 05:38, Joseph Smith wrote:
> >>
> > Anyways why can't cpu specific features be implemented at the model level
> > and not at the socket level???
>
> Because SSE, SSE2 and MMX are not CPU specific features in th
> Op donderdag 14 oktober 2010 23:23:39 schreef u:
> > Maybe we should define it to be 0xFF. In the future, I would think
> > that these values will move into Kconfig, and I think it will make
> > that conversion easier if we already know which values are bogus.
>
> That sounds reasonable and bui
Op donderdag 14 oktober 2010 23:23:39 schreef u:
> Maybe we should define it to be 0xFF. In the future, I would think
> that these values will move into Kconfig, and I think it will make
> that conversion easier if we already know which values are bogus.
That sounds reasonable and builds ok so it
On Thu, Oct 14, 2010 at 3:02 PM, Nils wrote:
> Hello Myles,
> Thanks for the review.
>
> Op donderdag 14 oktober 2010 18:53:43 schreef u:
>> Your patch is rather long. It would be easier to review if you split
>> out the white space & comment fixes, then the usage of msr names
>> instead of magic
Hello Myles,
Thanks for the review.
Op donderdag 14 oktober 2010 18:53:43 schreef u:
> Your patch is rather long. It would be easier to review if you split
> out the white space & comment fixes, then the usage of msr names
> instead of magic values. It looks like this would make your patch
> muc
(Please remember to trim the quoted text when replying.)
Nasa wrote:
> > > If my goal is the fastest boot time possible, while still
> > > supporting the basic system, would going to a Linux payload be the
> > > way to go?
> >
> > Maybe, but maybe not. If you are using flash media which does not
On Thu, 2010-10-14 at 18:02 +0200, Patrick Georgi wrote:
Am 14.10.2010 17:58, schrieb Stefan Reinauer:
> ...
> The reason models and sockets behave this way is that a mainboard
> > selects a socket and the socket selects all models that fit into
> > that socket. There is no other use for sockets th
On Wed, Oct 13, 2010 at 2:51 PM, Nils wrote:
>
> ***Ping***
>
> It would be nice if someone finds the time to ack/commit or comment my patch.
Your patch is rather long. It would be easier to review if you split
out the white space & comment fixes, then the usage of msr names
instead of magic val
On Thu, Oct 14, 2010 at 5:38 AM, Joseph Smith wrote:
> Anyways why can't cpu specific features be implemented at the model level
> and not at the socket level???
As a meta-comment, it's not always obvious, but many of these things
are done for a reason.
I'm glad you asked as Stefan gave a clear
Am 14.10.2010 17:58, schrieb Stefan Reinauer:
> Maybe we should drop those flags from Kconfig completely and just set
> the right ROMCCFLAGS in the socket's makefile to remove any confusion
> about the meaning of thos flags.
Making the CPUs define what they _don't_ support and derive the
remaining
On 14.10.2010, at 05:38, Joseph Smith wrote:
>>
> Anyways why can't cpu specific features be implemented at the model level and
> not at the socket level???
Because SSE, SSE2 and MMX are not CPU specific features in this context. SSE
and MMX determine how many registrers are available for romc
On Wed, Oct 13, 2010 at 4:05 PM, fengwei zhang wrote:
> Hi,
>
> I am new to coreboot. Do you guys know where printk() statement go in
> coreboot source code?
>
> e.g. printk(BIOS_DEBUG, "%s\n", msg);
LXR can be helpful for browsing the code. printk is a macro defined
in console.h
http://lxr.lin
Scott Duplichan wrote:
> At 1600x1200, 16-bit color is almost perfect. But the same
> resolution with 32-bit color results in a display that jumps so
> much it cannot be read. Why would 32-bit color make a difference?
Twice the bandwidth needed to get the graphics data out of RAM.
> I a
On 10/14/2010 08:35 AM, Joseph Smith wrote:
On 10/13/2010 03:00 PM, Uwe Hermann wrote:
Hi,
patch is committed with Peter's ack in r5949 as it's not really directly
related to this discussion and also boot-tested by me on MSI MS-6178
as mentioned in the patch description.
On Wed, Oct 13, 2010 a
On 10/13/2010 03:00 PM, Uwe Hermann wrote:
Hi,
patch is committed with Peter's ack in r5949 as it's not really directly
related to this discussion and also boot-tested by me on MSI MS-6178
as mentioned in the patch description.
On Wed, Oct 13, 2010 at 09:50:52AM -0400, Joseph Smith wrote:
On 1
- "Peter Stuge" wrote:
> Nasa wrote:
> > > Did you pick a particular CPU for the board, or did the CPU come
> > > already installed when you bought the board?
> ..
> > I choose the CPU (a number of years ago) which is an Intel Core 2
> > Duo Mobile 1.66GHz.
>
> Ok. I don't know if this CPU
28 matches
Mail list logo
