GTA02 u-boot and kernel status
Wolfgang Spraul
wolfgang at openmoko.com
Wed Mar 5 02:41:34 CET 2008
How about the screen flickering?
Wolfgang
On Mar 5, 2008, at 3:44 AM, Werner Almesberger wrote:
> Here's a quick status update on open issues and problems I know of in
> the lower reaches of the system (in no particular order):
>
> - we currently don't use the MAC addresses assigned to each machine
>
> - for BT, there is already a process for using a different set of
> MAC addresses, provided to us (by the maker of the module ?).
> We can use this for now, and phase in our own MAC addresses at
> a later point in time, through a rootfs/package update.
>
> - for EoUSB, this will require an environment update, which we can
> make as simple as running a script (which in turn can be put into
> a package). EoUSB uses randomized MAC addresses by default, so we
> don't break existing functionality by not using ours.
>
> - WLAN, where MAC addresses are probably most visible, is not
> affected by any of this
>
> Suggested resolution: no action before MP. Think about phasing in
> use of our own MAC addresses when the more pressing issues are
> under control.
>
> - the LCM sometimes stays dark when we bring up u-boot. This one is
> a bit nasty because it's confusing if the machine just doesn't
> respond. (Even though the hardware is perfectly healthy.)
>
> Furthermore, since this happens in u-boot, also the "safe" u-boot
> in NOR is affected. As a work-around, the NOR setup just cycles the
> LCM backlight again. This has so far never failed to bring the
> backlight to life, so the common recovery path (i.e., boot from
> NOR) is not affected by this problem.
>
> AFAIK, nobody is working on this at the moment, and it may take a
> bit of time to figure out what's really happening. (The apparent
> cause is that the overvoltage/overcurrent protection of the LED
> boost converter trips. I think Andy may have details on this.)
>
> Suggested resolution: since it may take a while to determine the
> exact root cause, it's probably better to defer this to a u-boot
> upgrade we strongly recommend for any new devices (similar to what
> we did for GTA01).
>
> - the PMUs driving the LEDs seem to have a bunch of issues, including
> failure to survive suspend, failure to light up, and failure to turn
> off completely.
>
> Also this one may take a bit to sort out. It's nothing too horrible,
> since we don't make much use of the LEDs yet.
>
> Suggested resolution: defer this to a strongly recommended kernel
> upgrade for new devices.
>
> - JFFS2 suffers gradual corruption
>
> The corruption manifests itself mainly in an increasing number of
> complaints from JFFS2, but it may also be possible that it causes
> a performance degradation or data loss/corruption (although I
> haven't observed any of the latter).
>
> I believe this is a mismatch between mkfs.jffs2 parameters and the
> actual NAND geometry, but I don't have a good way to predictably
> reproduce this yet (and thus couldn't tell if an attempt at solving
> it is really effective or not).
>
> Suggested resolution: I'll give this one more try later today, and
> when I get back home. In the worst case, this may not get resolved
> before we have to provide an image to the factory. Since we'll want
> to do a complete application update for new devices anyway, that
> update could take the form of a new rootfs (maybe this is the plan
> anyway ?), which would then have the correct settings.
>
> (Related to this is also the use of hardware-accelerated ECCs. I've
> turned them off until the corruption is resolved, just to make sure
> we don't add yet another potentially destablizing factor. HW ECCs
> are probably perfectly fine, though, so we'll also have a
> performance win once all this is solved.)
>
> - initial power settings
>
> So far, we don't have a comprehensive strategy for determining how
> the available power sources affect if and how we can start the
> system. And in particular, the dreaded 500mA USB issue still
> exists.
>
> Matt and I have discussed an algorithm that should take care of all
> this and Matt's working on it now. (Well, I hope not _right_now_,
> since it's already kinda late ;-)
>
> Suggested resolution: get this fixed this week. If there are
> unexpected major difficulties, I'd just revert the 500mA change,
> which achieves the goal of letting us boot from USB power alone
> only sometimes anyway, and we'll do a proper fix in the u-boot
> update for new devices.
>
> - PMU interrupts may not work
>
> The I2C unbusy change may have introduced a condition that would
> make the PMU unable to bring the system out of suspend. The fix
> should be trivial, but I have to bring my test machine back to a
> state where it resumes at all, then I can verify if a fix is needed
> at all, and if it works.
>
> Suggested resolution: fix this later today. In case of undue
> difficulties, that would be yet another item for a later kernel
> update.
>
> - GPIOs still float
>
> We've identified lots of improperly configured GPIOs, but we
> haven't actually fixed them. I haven't observed them causing any
> actual problems, but then floating inputs are unpredictable. (And
> we have seen floating inputs make serious trouble in other areas.)
>
> I actually think that the way how the initialization of GPIOs is
> currently implemented makes any changes there unnecessarily
> difficult and can easily lead to new bugs. So I think we should
> first bring this into a more programmer-friendly form, and then
> make the necessary changes.
>
> Suggested resolution: get this done for the great update.
>
> - AUX can crash u-boot booting from NAND
>
> This is the NOR-kills-NAND equivalent of the NAND-kills-NOR problem
> fixed recently. I need to have a closer look a the details of
> exception handling. As far as I remember, it should be possible to
> just remap the exception vector table, but the kernel may need some
> adjusting for this as well.
>
> Since u-boot for NOR and NAND will initially be identical, this
> problem will not exist in devices we ship from the factory.
>
> Suggested resolution: fix this for good in the great update.
>
> So I think we should plan to have a complete system software overhaul
> along with the UI update that's already planned. Most of the issues
> are more annoying than truly critical. What's more important is that
> none point to yet undiscovered major hardware issues or break
> recovery from NOR.
>
> I don't particularly like the JFFS2 corruption, so I hope we can make
> progress there before MP.
>
> I'll have a peek at Andy's whiteboard later today to see if he's got
> some more monsters lined up.
>
> - Werner
>
More information about the openmoko-kernel
mailing list