[coreboot] [PATCH] Convert all Intel i810 boards to CAR
stefan.reinauer at coresystems.de
Fri Oct 15 06:14:19 CEST 2010
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
> many chipsets will convert to TINYBOOTBLOCK and CAR (at least that's the
> plan I think), romcc will only ever be used for the bootblock, right?
> And that's pretty tiny hopefully and should work just fine with 386
> as romcc option? Do we actually really have any measurable advantages
> from using romcc options other than 386 in that case?
Yes. Since newer systems (might) require considerably more
initialization in the tiny bootblock stage (enabling ROM for example,
possibly more to come, like watchdogs, ECs, HT enumeration..) there is
value in having more registers available on those platforms. So we
shouldn't cut off the path to having them available. They definitely
have not much value in Kconfig though. If something doesn't have to be
an option, we should try to wipe it from Kconfig to keep that simple.
> Same for RAM test -- it's not a memtest86 replacement, just a quick
> "Did I screw up RAM init" test, which doesn't get run very often after
> the RAM init code is finished / working. Does the RAM test speed really
> matter much here? Shall we just use 386 for ROMCC everywhere (and not
> use SSE2 for ramtest) and get rid of the MMX/SSE/SSE2 config options?
Since the code is already there and tested I would strongly suggest to
not wipe it. We're also using a simplified version of the ram test on
some platforms to determine whether ram initialization was successful
(as opposed to actually testing for ram integrity errors). Since this
code is running on every boot (checking a considerably smaller amount of
RAM, obviously) we should not deliberately slow it down.
More information about the coreboot