Re: [coreboot] r643 - in coreboot-v3/mainboard/amd: . db800

[Peter Stuge]

On Fri, Mar 14, 2008 at 10:15:03PM +0100, [e-mail] wrote:
> +config BOARD_AMD_DB800
> bool "DB800"
> select ARCH_X86
> select CPU_AMD_GEODELX
> select OPTION_TABLE
> select NORTHBRIDGE_AMD_GEODELX
> select SOUTHBRIDGE_AMD_CS5536
> select SUPERIO_WINBOND_W83627HF
> select PIRQ_TABLE
> help
>  AMD DB800 Geode LX development board.
> /config/("northbridge/amd/geodelx/apic");
> /config/("northbridge/amd/geodelx/domain");
> 	/config/("northbridge/amd/geodelx/pci");
> 	/config/("southbridge/amd/cs5536/dts");
> 	/config/("superio/winbond/w83627hf/dts");

Can we reduce this redundancy?

Also, does anyone have ideas for cmos.layout for v3? OPTION_TABLE is
includes the code for that, correct? (Bad name.) I want to be able to
disconnect v3 completely from NVRAM and make it an optional feature.

//Peter

r643 - in coreboot-v3/mainboard/amd: . db800

[Carl-Daniel Hailfinger]

On 14.03.2008 23:01, Peter Stuge wrote:
> On Fri, Mar 14, 2008 at 10:15:03PM +0100, [e-mail] wrote:
> > +config BOARD_AMD_DB800
> > bool "DB800"
> > select ARCH_X86
> > select CPU_AMD_GEODELX
> > select OPTION_TABLE
> > select NORTHBRIDGE_AMD_GEODELX
> > select SOUTHBRIDGE_AMD_CS5536
> > select SUPERIO_WINBOND_W83627HF
> > select PIRQ_TABLE
> > help
> >  AMD DB800 Geode LX development board.
> > /config/("northbridge/amd/geodelx/apic");
> > /config/("northbridge/amd/geodelx/domain");
> > 	/config/("northbridge/amd/geodelx/pci");
> > 	/config/("southbridge/amd/cs5536/dts");
> > 	/config/("superio/winbond/w83627hf/dts");
>
> Can we reduce this redundancy?

A common reference board dts which can be extended would certainly be
nice. No idea whether the dtc supports it, though. Maybe that would be
an interesting GSoC project.
> Also, does anyone have ideas for cmos.layout for v3? OPTION_TABLE is
> includes the code for that, correct? (Bad name.) I want to be able to
> disconnect v3 completely from NVRAM and make it an optional feature.

How do you determine a successful last boot without NVRAM? However, I
also looked at our v3 code which decides the normal/fallback question
and I fail to see a clear and reasonable concept behind it. No offense
intended, but I don't see any reason in v3 to decide normal/fallback
based on some NVRAM setting. If normal/initram fails, there is no reason
we can't simply call fallback/initram and continue. Same with most other
settings unless I'm mistaken.

Regards,
Carl-Daniel