Rockbox mail archiveSubject: Re: Make iPod Nano 2G stable for 3.7?
Re: Make iPod Nano 2G stable for 3.7?
From: Alex Parker <parker.alex.e_at_gmail.com>
Date: Thu, 28 Oct 2010 09:56:35 +0200
On 26 October 2010 21:40, Michael Sparmann <theseven_at_gmx.net> wrote:
> 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.
Not a major issue IMO, reasonable for a release anyway.
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.
While it'd be nice to know why, if it is fixed then great :)
> 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.
I don't think battery should be a stable blocker unless it is 10 minutes or
something, and if we are already as good as Apple then great.
> 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.
USB hasn't been a blocker for other ipods, although we have set them to
reboot to the OF on connect on previous releases were it was unstable. If
this is very rare (and I can't remember seeing other reports of it), then no
> 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.
Nice to fix, but not a blocker IMO.
> 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.
If it is readable so affected people can see to change the contrast, then
not a blocker IMO.
> 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.
Not a blocker IMO.
> 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?
None of the above seem absolute show stoppers to me, so if as the maintainer
you think it meets the stable requirements, then I'm happy to go with that.
It'd be nice if a few more people spoke up though (hint hint!).
Received on 2010-10-28