From: Michael Sparmann <theseven_at_gmx.net>
Date: Tue, 26 Oct 2010 21:40:39 +0200

It has been proposed multiple times to promote the iPod Nano 2G to
stable for the upcoming release. Now that the release is close, I'd like
to get some more opinions on this.


The following known issues remain:

1. Due to the large sector size (2048 bytes) there have been lots of
stack overflows. All known ones have been 'fixed' by increasing stack
sizes, but we should probably try to get rid of on-stack sector buffers
in the future.

2. Due to the nature of the FTL (flash translation layer) and possibly
some bugs in the Apple bootloader, there's a risk that the whole data
flash contents (including the firmware partiton) get erased after an
unclean shutdown. This is easy to recover from but extremely annoying.
However, this kind of problems has suddenly disappeared some time ago,
even though nobody knows exactly why. Let's hope this doesn't come back
one day.

3. The way we're doing audio DMA is a bit weird. Due to insane latency
requirements of the hardware we need to split PCM chunks into multiple
pieces to implement really low-latency double buffering in the PCM
driver. While this appears to be working perfectly for playing audio
files, there might be some pops/clicks in audio played from plugins
which use smaller chunk sizes. Apple apparently has a better way to do
this, but nobody has figured it out yet. Those latency requirements are
also preventing us from changing CPU clock PLL factors on the fly, which
in the end reduces battery runtime. However, our battery runtime seems
to be about on par with Apple's.

4. If the USB HID is enabled (which is disabled currently), there are
USB lockups when the HID and MSC are transferring data at the same time.
The cause is still unknown. With the HID disabled, this also appears to
happen sometimes, but very vary rarely. I've seen it like a total of
three times in several months of development. So IMHO this isn't a blocker.

5. Flash (and thus USB MSC) transfer speeds are still quite slow, at
least on some devices. We're talking about ~1.5MB/s instead of ~6MB/s
with the apple firmware here. This is due to the fact that NAND write
operations are currently only parallelized on flash chip types that
support multibank writes, not on chips that support cached writes
instead. It used to be fast on my iPod (about the same speed as the OF
and about twice the speed of disk mode), but recently it became slow
again. I haven't figured out the exact cause yet, if it's just my device
or if the code generally won't do multibank writes any more. I don't
want to try fixing this so close before a release, so we're at the risk
of possibly releasing a version which is slow on all devices.

6. There have been reports that the display contrast on at least one of
the LCD types used in this series is worse than in the OF, making
colours appear a bit greyish. As I don't have an affected device, I
can't test or try to fix this.

7. There are still some patches in the queue, for example LCD sleep and
hardware keyclick support, which would be nice to have but won't be
committed for 3.7.

8. Before starting playback for the first time, the iPod seems to use a
few mA more current than normal, probably because the Wolfson codec
isn't initialized correctly yet. As this stops when PCM is started the
first time, it shouldn't have a major impact on battery runtime.

9. Are there any other issues Nano2G users are experiencing currently?
If yes, please speak up now.


Are there any things that are considered blockers, or can I promote it
to stable when we release?

Regards,

TheSeven


Received on 2010-10-26