Re: [coreboot] unstable AMD Fam10h boot

2009-09-05 Thread Stefan Reinauer
ron minnich wrote:
 So, what I'm trying to say:
 - we have a problem on fam10h
 - it seems to be a non-smp-safe function doing a config cycle
 - there are two ways to eliminate the problem
   o write a fam10 version of that function that will use MMCONF (will
 work on all later CPUs)
   o modify old function by adding a lock  (i.e. stick with legacy
 mechanism for older CPUs)
   

Another idea would be to get rid of SMP setup in CAR stage. It sounds
highly funky to me anyways.

- Why are we doing this anyways?
   o Is there a reason?
   o No other SMP system except K10 does this.

* How many ms do we benefit from that? (Honest question). Any at all?

Stefan




-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot


Re: [coreboot] unstable AMD Fam10h boot

2009-09-05 Thread ron minnich
On Sat, Sep 5, 2009 at 10:36 AM, Stefan Reinauerste...@coresystems.de wrote:

 Another idea would be to get rid of SMP setup in CAR stage. It sounds
 highly funky to me anyways.

 - Why are we doing this anyways?
   o Is there a reason?
   o No other SMP system except K10 does this.

 * How many ms do we benefit from that? (Honest question). Any at all?

This may fix one problem, but it does not fix the general problem:
using cf8/cfc is not going to be safe on multiple cores, from my
understanding.

ron

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot


Re: [coreboot] unstable AMD Fam10h boot

2009-09-05 Thread Ward Vandewege
On Sat, Sep 05, 2009 at 10:46:57AM -0700, ron minnich wrote:
 On Sat, Sep 5, 2009 at 10:36 AM, Stefan Reinauerste...@coresystems.de wrote:
 
  Another idea would be to get rid of SMP setup in CAR stage. It sounds
  highly funky to me anyways.
 
  - Why are we doing this anyways?
    o Is there a reason?
    o No other SMP system except K10 does this.
 
  * How many ms do we benefit from that? (Honest question). Any at all?
 
 This may fix one problem, but it does not fix the general problem:
 using cf8/cfc is not going to be safe on multiple cores, from my
 understanding.

Not to complicate matters even further, but since we are talking about
locking - will any of this improve the 'many cores talking to serial at once'
problem?

Thanks,
Ward.

-- 
Ward Vandewege w...@fsf.org
Free Software Foundation - Senior Systems Administrator

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot


[coreboot] DOS booting using V3

2009-09-05 Thread Gregg C Levine

Hello!
Can it boot what I am calling original DOS? I have access to DOS 6.22  
and of course DOS 3.3. And also the thing promoted by General  
Software. Which is also called DOS and is largely code and binary- 
level compatible.




This is from an iPod Touch.

--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot


Re: [coreboot] unstable AMD Fam10h boot

2009-09-05 Thread ron minnich
there's at least three problems here :-)
1. do we want to do SMP of any kind in CAR? I think not, but I'd like
to hear Marc's opinion
2. There are techniques from the oldest days of PCI (cf8/cfc) that we
use that don't work well in a multicore world.
 MMCONF, it seems, can help here. Using MMCONF for config cycles
may only work for newer CPUs,
 but we really ought to move to something that doesn't require a
shared resource such as cf8/cfc for more modern
 CPUs.
3. we need smp style locking code for printk.

Any more :-)

ron

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot