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?
Yes.
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.
Stefan