Re: Redboot jumb patch

[Gary Thomas <gary at chez-thomas dot org>]

On Tue, 2002-08-06 at 06:44, Andrew Lunn wrote:
> > In fact, the EBSA code should probably be removed.  The code in the
> > ARM architecture HAL is supposed to be generic for all ARM platforms.
> 
> Feel free to remove it. We don't run Linux on our EBSA devices, so i
> would not even know if you broke it!
>  

OK.

> > The rest of your changes follow pretty much what I said before - that
> > there is CDL to handle this.  You've added a central switch for doing
> > the enable/disable, which I think is fine.
> > 
> > The AAED change should use 'active_if', not 'requires'
> 
> OK. Minor change. Please can you do this?
>  

Sure.  Do you want me to make these changes & commit?  [Do you have 
commit access yet?]

> > Also, please use "-u" for your diffs, at least the ones you post.  We've
> > all gotten used to reading that form and trying to decipher any other
> > form is unfamiliar and thus prone to errors.
> 
> I could say the same of -u diffs. I find context diffs much easier to
> read :-)

Indeed; as I said, it's what one is familiar with!

> 
> > As for verification - this is a common problem.  Since we no longer
> > have access to the Red Hat test farm (which had pretty much one of 
> > every board type) to test against, we'll have to just make sure that
> > any affected platforms can still build and hope that the community
> > provides feedback when things break.  Of course, if you have access
> > to a particular platform, it should be checked as much as possible.
> 
> What involved in getting such a thing up and running. How much of the
> software was public domain? Even if we cannot get the whole system
> going, just being able to build the images would be a big step
> forward. I guess have a complete test farm in one place is not likely,
> but maybe we could have a number of smaller test farms at contributers
> premises who have spare boards laying around.
> 

I'm not sure what the state of this is.  I agree that it would be nice
to be able to set up such testing "cells".  The biggest problem with
such an environment is providing a way to reliably reset a remote board.
In the Cambridge lab, it was done mostly using X-10 remote control
devices to power-cycle the boards (which I thought was awful, but it was
used because it was _mostly_ reliable).  I'd much prefer some other 
means, but that just makes the process of duplicating the "farm" that 
much more difficult.  Anyway, it's something to explore for the future.