Ok, thank you all for the replies, links and diagrams. But there are
still some ambiguities in memory read/write after reset which is done
by BIOS chip and then the memory controller !!
Immediately after reset all memory read/write cycles are claimed by
BIOS chip ultimately. The first question is
On 7/8/10 8:09 PM, Myles Watson wrote:
> On Thu, Jul 8, 2010 at 11:56 AM, Patrick Georgi
> wrote:
>> Am 08.07.2010 19:50, schrieb Myles Watson:
>>> BOOTBLOCK_NORMAL allows the user to use CMOS values to select which
>>> image to boot. This patch:
>>>
>>> - makes BOOTBLOCK_NORMAL depend on USE_O
Stefan Reinauer wrote:
> Even though the normal/fallback mechanism uses CMOS, it does not
> require an option table.
> Are there advantages in changing this?
One advantage would be that any use of NVRAM always implies having an
option table, which I think makes sense. Somewhere it needs to be
spec
On Fri, Jul 9, 2010 at 7:10 AM, Peter Stuge wrote:
> Stefan Reinauer wrote:
>> Even though the normal/fallback mechanism uses CMOS, it does not
>> require an option table.
>> Are there advantages in changing this?
>
> One advantage would be that any use of NVRAM always implies having an
> option t
Author: myles
Date: Fri Jul 9 16:24:23 2010
New Revision: 5662
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5662
Log:
Trivial fix to make CONFIG_BOOTBLOCK_NORMAL switch compile again.
Signed-off-by: Myles Watson
Acked-by: Myles Watson
Modified:
trunk/src/arch/i386/init/bootblo
On 7/9/10 3:36 PM, Myles Watson wrote:
> On Fri, Jul 9, 2010 at 7:10 AM, Peter Stuge wrote:
>> Stefan Reinauer wrote:
>>> Even though the normal/fallback mechanism uses CMOS, it does not
>>> require an option table.
>>> Are there advantages in changing this?
>> One advantage would be that any use
On Fri, Jul 9, 2010 at 9:55 AM, Stefan Reinauer
wrote:
> On 7/9/10 3:36 PM, Myles Watson wrote:
>> On Fri, Jul 9, 2010 at 7:10 AM, Peter Stuge wrote:
>>> Stefan Reinauer wrote:
Even though the normal/fallback mechanism uses CMOS, it does not
require an option table.
Are there adva
Anyone can ack / test please?
KTHXBYE
Rudolf
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
On Fri, 2010-07-09 at 18:09 +0200, Rudolf Marek wrote:
> Anyone can ack / test please?
>
> KTHXBYE
>
> Rudolf
>
>
Tested with my m2v-mx-se and TX is confirmed to work.
Still, when using the qemu target it fails to compile, so I think we
should also test it using abuild to see how many boards
On 7/9/10 6:01 PM, Myles Watson wrote:
> On Fri, Jul 9, 2010 at 9:55 AM, Stefan Reinauer
> wrote:
>> On 7/9/10 3:36 PM, Myles Watson wrote:
>>> On Fri, Jul 9, 2010 at 7:10 AM, Peter Stuge wrote:
Stefan Reinauer wrote:
> Even though the normal/fallback mechanism uses CMOS, it does not
>
Before you commit, I have some suggestions:
I don't think it should default to yes.
+config CONSOLE_NE2K
+ bool "Network console over NE2000 compatible Ethernet adapter"
+ default y
+ help
A little trivial white space cleanup before you commit.
Warning: trailing whitespace in
> 0. Maybe we should hard code the Normal / Fallback ("BOOT_BYTE") into
> the cmos.layout parser tool so anyone who tries to use that byte gets a
> decent error.
It seems more flexible to use the value from cmos.layout unless there isn't
one, then hard code it. But I agree we don't want it to be p
See patch
become more standard with libpayload headers. PATH_MAX belongs in limits.h,
tiny curses can use standard includes now.
Signed-off-by: Stefan Reinauer
Index: include/limits.h
===
--- include/limits.h(revision 0)
+++ i
See attached patch:
Signed-off-by: Cristi M
--
Cristi Măgherușan, alumnus System/Network Engineer
Technical University of Cluj-Napoca, Romania
http://cc.utcluj.ro +40264 401247
From 36e59905aea9bc7ed4ee450adc1a9eda75b915a5 Mon Sep 17 00:00:00 2001
From: Cristi M
Date: Fri, 9 Jul 2010 20:51:
Author: myles
Date: Fri Jul 9 20:06:23 2010
New Revision: 5663
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5663
Log:
Trivial -Werror fix.
Signed-off-by: Cristi M
Acked-by: Myles Watson
Modified:
trunk/src/northbridge/amd/amdk8/raminit_f.c
Modified: trunk/src/northbridge/amd/
Am 09.07.2010 19:34, schrieb Stefan Reinauer:
> See patch
>
Acked-by: Patrick Georgi
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
On Fri, Jul 9, 2010 at 11:55 AM, Cristi Magherusan
wrote:
>
> See attached patch:
>
> Signed-off-by: Cristi M
Rev 5663.
Thanks,
Myles
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Stefan Reinauer wrote:
> 1. Should Fallback always ignore CMOS? I think it would make more sense
> if Normal and Fallback were the same and both would write a decent set
> of CMOS defaults in the case of a bad checksum.
NAK if this means that testing coreboot and later booting factory
BIOS again w
On 7/9/10 8:35 PM, Peter Stuge wrote:
> Stefan Reinauer wrote:
>> 1. Should Fallback always ignore CMOS? I think it would make more sense
>> if Normal and Fallback were the same and both would write a decent set
>> of CMOS defaults in the case of a bad checksum.
> NAK if this means that testing co
Author: stepan
Date: Fri Jul 9 20:52:17 2010
New Revision: 5664
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5664
Log:
become more standard with libpayload headers. PATH_MAX belongs in limits.h,
tiny curses can use standard includes now.
Signed-off-by: Stefan Reinauer
Acked-by: Pat
Stefan Reinauer wrote:
> >> if Normal and Fallback were the same and both would write a
> >> decent set of CMOS defaults in the case of a bad checksum.
> > NAK if this means that testing coreboot and later booting factory
> > BIOS again will throw an error and lose/change the NVRAM contents.
>
> I
> This is another way to express what I think is important; a way to
> disable NVRAM options that guarantees that coreboot will never write
> to NVRAM.
It's implemented: Don't use fallback/normal & set USE_OPTION_TABLE to false.
Thanks,
Myles
--
coreboot mailing list: coreboot@coreboot.org
htt
Myles Watson wrote:
> > This is another way to express what I think is important; a way to
> > disable NVRAM options that guarantees that coreboot will never write
> > to NVRAM.
>
> It's implemented: Don't use fallback/normal & set USE_OPTION_TABLE to
> false.
Fantastic. I probably knew this alre
> > It's implemented: Don't use fallback/normal & set USE_OPTION_TABLE to
> > false.
>
> Fantastic. I probably knew this already, sorry for forgetting.
No problem.
> It
> would be nice to never mention fallback anywhere unless there is
> also a normal, but that's another issue.
Yes. It's always
Hey Anders,
I can help out with coding and testing support for the GA-6VX7-4X. Do
you have a patch with the code you have done already, so we don't
duplicate efforts? I've got datasheets for the north and south
bridges, so it shouldn't be too difficult to include support for this
board. Let me know
Hi
Grate, I'll send so the patch in a day or two.
At the moment it sets up most of the config before ram init, the SMBus code
is about half done.
-Anders
--
From: "David Borg"
Sent: Saturday, July 10, 2010 1:16 AM
To:
Cc:
Subject: Re: [corebo
26 matches
Mail list logo
