need estimates for gta01 specific bugs

[Werner Almesberger]

[ Copying openmoko-uboot and openmoko-kernel, to keep people in
  the loop. ]

Wolfgang Spraul wrote:
> still working on the GTA01 specific bugs list.

;-)

> Please, no perfectionism here, I am just trying to understand the  
> relative workload. Some bugs are obviously harder to fix than others,  
> that's the information I need to know.

Yeah. Many of these bugs have a "research" component in them which
is very hard to estimate.

> P#806 Standby voltage set to 2.1V, not 1.8V as datasheet says.
> This one definitely wants looking into.

Maybe a day or two, since this isn't only software (which is easy)
but also needs some background research. I.e., the value, if it's
indeed so high, may have been chosen for a reason.

> P#95 verify charger current and battery temperature reading correctness

That's a tricky one, which also seems to involve hardware. May be
possible to resolve in a day, may take a week (in which case we
should probably just declare defeat :-)

> P#193 Information about current charging status when AC is online

This one is closely related to P#95. Reviewing and handling the
patch should take only a few hours. For the rest, see P#95.

> P#255 battery voltage scale is not correct

Not sure about this one. As Harald has decribed, this is basically
the mapping of an conceptually incorrect measurement (i.e., the
battery voltage is everything but linear) to a largely unknown
mixture of power consumers. So it may be possible to obtain some
improvement within a day or two, but it's hard to predict how good
it would be. I don't think it's worth the effort to try to make
this actually a great estimate, also considering how piss-poor our
battery life is anyway :-)

> P#795 battemp values obviously bogus

Might take a day to measure and calibrate. Note that the finding
may be that the battery temperature measurements are irreperably
wrong.

> P#796 Use obviously bogus value for off-scale high battemp value

Maybe an hour.

> P#900 Power cycles on and off while charging
> May be hard to reproduce and narrow down.

Something between an hour (if you can reproduce it) and forever
(if you can't) ;-)

> P#282 microSD Problem for RiDATA cards

This one may already be solved. If it is, then it'll take maybe an
hour to verify (after acquiring the corresponding card). If not,
this is something that's hard to fix, taking days at best.

> P#799 data abort while reading from SD Cards

This is a regression. So, first step is to reproduce it, which
should take hours. Then finding out where it happened and why,
which should take a couple of days.

> P#194 s3c2410fb 8bit mode corrupt
> This should probably be combined with the QVGA work.

Seems to be solved ?

> P#899 8 seconds power button timeout no longer working

Pilot error. Solved.

> P#149 lm4857 not i2c address compliant
> Should be done when merging the driver upstream.

That's mainly a discussion of what is acceptable for upstream. A
few hours spread out over a week maybe.

> P#191 set CPU voltage to 1.8V on 200MHz or less
> Low priority. Also needs evaluation of whether clock speed reduction
> is actually technically sound. Should probably be considered as part
> of a general power management review and cleanup.

Yeah, this is part of the power management cluster I mentioned.
Probably useless to try to tackle in isolation. The background
work may take a week, beginning with the definition of some usage
scenarios.
 
> P#82 implement and test cpufreq interface to S3C2410 PLL / SLOWCLK
> Not urgent.

Seems to be the "wait and see" kind. Note: haven't heard from Ben
in a very long while.

> P#207 DFU mode should only be enabled when in "911 key" mode

Half a day to do it dirty (just ignore/reject DFU in normal operation),
a few days to do it cleanly (only advertize DFU if in the boot menu),
but I'm not even sure this is a valid request. It identifies a real
problem (DFU trampling over all kinds of other operations), but I'm
not sure we actually want to require manual intervention. So if this
is implemented, it should probably be made run-time configurable
through the environment.

See also ...

> P#604 DFU at bootdelay conflicts with normal boot nand read

... hah, someone who explicitly doesn't want manual intervention :-)
(I actually had not noticed that when I added my comment to this
bug.) Basically part of the "avoid DFU races" bug cluster, adding
a few hours to P#207.

> P#209 u-boot DFU needs to block console access while in DFU mode

More of the same, some more hours.

Regarding those "clusters": anyone who fixes one of the bugs in
such a cluster should try to fix all of them. Not only is it much
quicker to do them at once than doing them bit by bit, but they
are also related in terms of underlying technology and usage
policy, so any isolated solution for one bug will likely conflict
with the others.

- Werner