Areas of Work
This page lists the various areas of the project that require some work, and who (if at all) is working on fixing it.
Infrastructure
Build System
- we need a clean/known base as a compiler
- At the moment, we're mostly using the 4.0.2 release from gnuarm.com, which is fairly old
- independence of system-provided header files
- We should be mostly there now. But testing this and verifying our independence of system headers would be great
Operating System
- Decide which RTOS to use on the Calypso
- we don't want to use FreeRTOS
- OS should have clear abstraction of core (ARM7TDM), SoC and board level features
- OS should cleanly compile to a library that we can link with all our other code
- While we only work on the GSM stack, no OS is needed. But as soon as UI comes around, that changes.
Development Tools
- try to make JTAG (C155) work with OpenOCD
- steve-m made some experiments, but halting the ARM core only seems to be possible via the undocumented ICEPick unit
Host Software
- osmocon support for the native ROM loader in the Calypso, the CalypsoRomloader, like it is found on most non-Compal phones
- "non-secure" variant (done, steve-m)
- "secure variant" on Calypso/Calypso? plus (basic reverse engineering done)
Target Software
Drivers
- charger detection, battery charging (roh)
- SIM card reader (dexter)
- Color display driver for C155 (done, steve-m)
- backlight driver
- vibrator driver
- buzzer driver for C123
- C155 ringtone chip driver for SPMA100 chip
- Fix the I2C driver to use the b/w LCD without any sleep/delay loops
- done (sigwinch)
GSM Stuff
- TRF6151, TPU, TSP, AGC, AFC (laforge)
- Layer1, particularly the synchronous part (laforge, spaar)
- Layer2 (zecke, laforge)
- Layer3 (eversberg)
- Playing with the Voice part using the dsp misc task (spaar?)
General Infrastructure
- Flash-based log-structured filesystem (prom)
Bootloader
- Put together a bootloader (prom)
- Define linkage situations (prom)
UI related
- proportional fonts in at least two sizes, as small as possible
- monospaced fonts waste too much scarce screen real estate
- cache the frame buffer in RAM and sync when needed
- once we have a scheduler and tasks, run screen refresh as low-priority task
- hardware independent API to support C123, C155 (and later other) displays
- software should not care if it is using color or b/w display
- some kind of fixed screen layout masks, where
- a data structure defines a screen mask
- the application can easily update the content without having to deal with formatting/positioning
- UI widgets like
- lists that can be scrolled through
- menus build of a tree of such lists

