Stefan Reinauer <[EMAIL PROTECTED]> writes: > * Eric W. Biederman <[EMAIL PROTECTED]> [031119 00:16]: > > So it might make sense to set everything up in a very early pass before > > memory reset. Reset the system, and then let the existing resets will > > not trigger. > > > > Either that or Stefans delayed scheme. At this point I am not certain > > which will be easier to maintain. If we do implement the delayed reset > > I want to move the memory clear code up into the generic framework so we > > don't have to clear memory twice. But if we can get the resets over with > > before we initialize memory we are in better shape. That plus something > > like the kernels quirk interface to handle the various know bits of buggy > > hardware and we should be ok. > > Would cache-as-ram be an alternative for AMD64 cpus to move the pretty > complex ht code to a point as early as possible?
If I can get a commit from a cpu vendor to support it. > Romcc really does a > great job, but IIRC the current ht speed code is where it is now because > it is really hard to do before there is memory. In part at the time I was just using the 8 general purpose registers. So we have a little more room. It is also where it is because that is a very good general purpose place to put it. I have found an instruction that will allow me to extract or insert a bit field into one of the xmm registers. Which may also help. > I also suspect AMD doing a better job in keeping cache as ram > initialization code the same over different cpu steppings than Intel > managed with their P-IV. Well I wrote that code not Intel. Which was essentially the problem. It is a support nightmare to have someone plug in a new processor and have it totally fail because the cache acts differently. I have never tried hard on the AMD processors but the limited attempt I made had problems because of the additional complexity of TOP_MEM and the io range registers. I like the idea. I just rest easier at night with romcc because I know so new thing won't cause me to rewrite everything. Eric _______________________________________________ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
