Macho Hacking vs Product Development

Andy Green andy at openmoko.com
Sun Mar 9 21:31:50 CET 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:
> Andy Green wrote:
>> Why do we still have charging logic in U-Boot at all?
> 
> So far, all this is about the maximum supply current we can draw.
> Whether we charge or not doesn't really matter.

Charging obviously affects the maximum current we choose to draw, but I
take the point.  I think of it as "charging logic" because that was the
last work I did on it and the basis I was thinking about for a wider
solution there.


I just had to do various exciting things like clean out the cat litter
and I had a chance to think at a bit more length about what is bothering
me about this sequence of events today.  Earlier in the thread that
wasn't on the list, I proposed this (about the PMU and charging overall):

''We need to stop on that and write up the full behaviour in English
that we are aiming for, then implement it in one step.  Currently there
is no actual definition of all the corner cases and behaviours we aim
for, which is why we stepped into this 100mA mantrap already.''

For a commercial project, the system side at least of GTA02 (and 01
before it evidently) are pretty woefully specified.  The plan is to rely
on the coders on the ground making decisions that result in the "right"
things happening.  Generally we are fairly good at doing the right
thing, but because there are more things to look after than there are
hands to do it, and different hands have different ways to come at it,
one way or another the right thing sometimes isn't done, or stuff is
done without a holistic overview.

Your reply (quoting me):

''
> It's usually not a good sign when we can't articulate
> what it is we are trying to achieve :-)  ...and are about
> to commit it to write-once memory.

Duh. Code speaks louder than words ;-)''

Well that is right: because you didn't post what you have done to the
list, I won't see it, it is just directly committed as you insist to do
without review: a fait accompli without other input as if it was your
private project and other opinions are worthless anyway.

At the same time, the idea of drawing up a specification for what we try
to achieve as an end result is undermined.  Both of these things bother
me because they turn their back on the advantages of both really open
development and basically the company development process being
something other than random surges of one man hacking -- as it is, it
seems to implicitly assume what you are doing and the choices you made
are already perfect all the time, and that would be a dangerous conceit.
 (As you know I post all my patches here for review).  I have a great
reference on the value of review I will write up elsewhere.


At least until now we didn't take care of PMU events happening inside
U-Boot, for example with a battery in we swap USB power sources in
U-Boot we will not react.  (If you did eat PMU events in your patch, you
need to take care that Linux will no longer see the initial interrupt
sources.)  Did we take care of the situation that we started with a 1A
charger and then swapped to a laptop port in U-Boot?  I dunno because I
have never seen any of your patches, and we didn't plan for it.  Maybe
it is fine this time, next time too, but it isn't really the point.

>> Are we planning on having charging logic in this minimal bootloader that
>> is to replace U-Boot?
> 
> I hope not :-)

Almost everything we are doing in U-Boot is waste because we will
abandon it soon, NOR U-Boot especially so.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFH1Ek2OjLpvpq7dMoRAjeMAJ46VZR+WWdeFsJ97WtL0kV5s+5LNQCgjXmn
iFlWdmmQ+nGVsumjQCuRhEo=
=7FIe
-----END PGP SIGNATURE-----




More information about the openmoko-kernel mailing list