This is the mail archive of the
mailing list for the eCos project.
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.