Re: Simtec Announcement

[Chris Gilbert <chris%dokein.co.uk@localhost>]

On Tue, 9 Mar 2004 12:15:54 +0000
Vincent Sanders <vince%kyllikki.org@localhost> wrote:

> On Tue, Mar 09, 2004 at 09:44:13AM -0000, chris%dokein.co.uk@localhost wrote:
> > Hi Vince,
> > 
> > > If you own a CATS board please visit
> > > http://www.simtec.co.uk/products/EB110ATX/resources.html and read
> > > the Product Change Notification.
> > 
> > Could this be the cause of the long reported bug:
> > http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=10502
> > which many people had put down to broken hardware...
> > 
> 
> This is more likely to be related to the footbridge 21285 revision
> 3(AA) errata where bus mastered DMA fifos can get jammed. More modern
> boards have revision 4(AB) bridges which have this issue fixed.

ah, I'm guessing that's the issue then, as multiple disk accesses still
locked up the system. Is there a software workaround for this? (sorry I
looked over the errata, and it kind of lost me)

Actually I note some mention of the cache zero'ing area not being
properly functional on rev 3, so we need to change that behaviour to be
dependant on rev of the footbridge.

> But perhaps thsi will help I cant say for sure.
> 
> > I'll change the jumpers and see if I can repro the issue.
> > 
> 
> Thanks, do let me know I will add this to the FAQ
> 
> > Is it worth adding a check for these jumpers being wrong to the
> > kernel boot up code, so it's visible to users running cats boxen
> > headless?  (is it easy to detect in software?)
> > 
> 
> ABLE has clear indications if there's an issue (5 lines of text with
> stars :-) its somewhat difficult to detect this post startup other
> than the PCI SDRAM BAR will not work properly. Historically with AA
> revision footbridges and all existing Operating systems the issue
> didn't bite hard so wasn't noticed.

Only if you're running it a serial console, it doesn't give any
indication on a graphical console.  However looking at the changes I
suspect that I can make the kernel spot the different class id, and give
a hint/suggestion.

> > > Recently there has been some discussion about ABLE our next
> > > generation boot loader. I would just like to make clear that there
> > > is *no* GPL code in ABLE and only minimal BSD code (headers for
> > > the ffs filesystem). ABLE is an underived original work not based
> > > on any other code base. Sorry to have to stress that but otherwise
> > > someone might get the wrong idea.
> > >
> > > It has been mentioned ABLE is more "Linux" in its approach. I hope
> > > this isn't the general perception! ABLE is intended to be its own
> > > interface, it is a boot loader not an OS after all. Perhaps this
> > > idea has come about because of the naming of partition aliases?
> > > they are just names, usually the (hd0) aliases would be used. If a
> > > (wd0a) type set of names would be useful please let me know and I
> > > will look at including that naming scheme in addition.
> > 
> > I suspect that it is the perception due to the change from wdxx to
> > hdx. Possibly the issues with earlier ABLE not working well with
> > NetBSD as well.
> > 
> 
> Well hopefully these issues have gone away, I will consider a way to
> have a config option to add BSD style aliases so you will all feel at
> home ;-)
> 
> > > I would encourage all users to upgrade to ABLE 1.95 to gain access
> > > to the new features it offers, it is also being actively
> > > maintained unlike cyclone which is beginning to show its age.
> > 
> > Certainly I've been using 1.93 beta firmware on my -current cats
> > box, it's fixed most of the issues I've had with earlier ABLE
> > builds.  I'll update my -current cats box this evening.  If people
> > want to try ELF kernels they should find the options in the GENERIC
> > kernel to build ELF kernels.
> 
> You should find the ELF loading improved, even loads debug segments
> now

I'll have to have a play with it.  Certainly I can boot ELF kernels
quite happily now (and command params are passed in, with the kernel
loaded off disk)

> > 
> > Long term I'd like to move to ELF kernels, as it would avoid the
> > issues with converting from ELF to a.out.
> > 
> 
> As soon as the EB7500ATX port is completed tehre are several other new
> boards which might be good targets for NetBSD.

I've got a basic port working, but I'm waiting answers from you guys 8)

Thanks,
Chris