This is the mail archive of the mailing list for the eCos project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Redboot jumb patch

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!


> > 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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]