Carl-Daniel Hailfinger wrote:
On 02.10.2009 11:54, Patrick Georgi wrote:
We need to have access to CMOS before CAR or raminit, or anything
interesting happens, really. And I'm not sure if our code supports
this everywhere already.
IMHO access to CMOS before CAR is unnecessarily
Carl-Daniel Hailfinger wrote:
IMHO access to CMOS before CAR is unnecessarily painful
Why?
//Peter
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
On 03.10.2009 18:08, Stefan Reinauer wrote:
Carl-Daniel Hailfinger wrote:
On 02.10.2009 11:54, Patrick Georgi wrote:
We need to have access to CMOS before CAR or raminit, or anything
interesting happens, really. And I'm not sure if our code supports
this everywhere already.
On 03.10.2009 18:34, Peter Stuge wrote:
Carl-Daniel Hailfinger wrote:
IMHO access to CMOS before CAR is unnecessarily painful
Why?
Because you either introduce a dependency on ROMCC or you need
additional assembler code. mmxstack/xmmstack+GCC is not an option here
because a
Carl-Daniel Hailfinger wrote:
IMHO access to CMOS before CAR is unnecessarily painful
Why?
Because you either introduce a dependency on ROMCC or you need
additional assembler code.
I love Patrick's idea about generating macros from cmos.layout. With
that, the additional assembler code
Am Samstag, den 03.10.2009, 20:03 +0200 schrieb Peter Stuge:
Because you either introduce a dependency on ROMCC or you need
additional assembler code.
I love Patrick's idea about generating macros from cmos.layout. With
that, the additional assembler code would amount to maybe 15
Patrick Georgi wrote:
What I don't know is, do we require any chipset setup to _reach_
CMOS?
It's not generally in the CPU, so some setup may be needed. On the
other hand, maybe 70/71 are decoded correctly on power up, just like
flash access?
//Peter
--
coreboot mailing list:
Peter Stuge wrote:
Patrick Georgi wrote:
What I don't know is, do we require any chipset setup to _reach_
CMOS?
It's not generally in the CPU, so some setup may be needed. On the
other hand, maybe 70/71 are decoded correctly on power up, just like
flash access?
It's not like there is a spec
Am 02.10.2009 01:58, schrieb Kevin O'Connor:
Proprietary BIOS have a cmos variable for a similar purpose - 0x0f
(RESET CODE). Coreboot could probably use the same variable -
defining one variable for all boards is probably simpler than having
to define it on every board.
That's not the issue,
On 02.10.2009 11:54, Patrick Georgi wrote:
We need to have access to CMOS before CAR or raminit, or anything
interesting happens, really. And I'm not sure if our code supports
this everywhere already.
IMHO access to CMOS before CAR is unnecessarily painful and I'd like to
keep that out of the
Am Mittwoch, den 30.09.2009, 16:07 -0700 schrieb ron minnich:
Yes, I'm sorry, we keep board support, but stop worrying about huge
SPI anbd weird accessing of it.
As for fallback: we really need to bring it back at some point. I'm
speaking as someone whose life was saved because I did not
On 01.10.2009 09:09, Patrick Georgi wrote:
Am Mittwoch, den 30.09.2009, 16:07 -0700 schrieb ron minnich:
CBFS will give us a normal/fallback setup that people can understand.
It will, but right now, CBFS is worse off than old-style.
[...]
My plan for it, pending any better
On 01.10.2009 09:44, Carl-Daniel Hailfinger wrote:
On 01.10.2009 09:09, Patrick Georgi wrote:
We need early rom mapping and CMOS access for all boards. So far, only
the boards with failover layout are somewhat guaranteed to have code for
that.
Early ROM mapping: Yes. Early CMOS
Am Donnerstag, den 01.10.2009, 09:44 +0200 schrieb Carl-Daniel
Hailfinger:
- move everything but the decision stuff out of the bootblock (so it
essentially becomes immutable across updates)
This means we either need a CBFS walker in ASM or compile it with ROMCC.
I have a CBFS walker
On 01.10.2009 10:17, Patrick Georgi wrote:
Am Donnerstag, den 01.10.2009, 09:44 +0200 schrieb Carl-Daniel
Hailfinger:
- move everything but the decision stuff out of the bootblock (so it
essentially becomes immutable across updates)
This means we either need a CBFS walker in
On Thu, Oct 01, 2009 at 09:09:50AM +0200, Patrick Georgi wrote:
My plan for it, pending any better solution:
- unify the decision stuff into a single place
- move everything but the decision stuff out of the bootblock (so it
essentially becomes immutable across updates)
- extend kconfig so
16 matches
Mail list logo
