Subject: Re: Simtec Announcement
To: Vincent Sanders <vince@kyllikki.org>
From: Chris Gilbert <chris@dokein.co.uk>
List: port-cats
Date: 03/09/2004 21:47:04
On Tue, 9 Mar 2004 12:15:54 +0000
Vincent Sanders <vince@kyllikki.org> wrote:
> On Tue, Mar 09, 2004 at 09:44:13AM -0000, chris@dokein.co.uk 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